Slashdot Mirror
What's (Still) Wrong With UCITA
Grant Gross has an article at NewsForge outlining both changes being proposed by the The National Conference of Commissioners on Uniform State Laws to its version of UCITA (a model intended for adoption by the various state legislatures), and objections raised to the resulting language by Red Hat lawyer Carol Kunze. Among other things, Kunze points out that Free software projects could be effectively discouraged from releasing software if software producers are required to provide warranties -- imagine trying to provide warranties on all the packages available to Debian users, for instance, or every bit of software included with Mandrake Linux.
> required to provide warranties
Free projects should just copy Microsoft's license which, by the time it is done excluding things, provides nothing to the end user.
Among other things, Kunze points out that Free software projects could be effectively discouraged from releasing software if software producers are required to provide warranties -- imagine trying to provide warranties on all the packages available to Debian users, for instance, or every bit of software included with Mandrake Linux.
You want Microsoft to be held financially liable for bugs, yet Free Software should have no warranty if something blows up in the field? Or is this another "Tough Crap...no one made you use free software" instance.
Sounds like the kettle calling the pot black if you ask me...
AFAIK, most software is without warranty. Even windows. Nobody provides warranties. If this comes into force, it will basically kill the software industry, wether open-source or closed source.
Software can never be without problems.
Just imagine half the population putting lawsuits! Law will have to be outsourced mebbe!
My Aurora : http://www.youtube.com/watch?v=o91ZsGwJYyg
FB : https://www.facebook.com/TanveersPhotography
I don't agree with the argument in the article that commercially-packaged Free Software being sold alongside other commercial software should have to abide by the same warranty obligation of commercial software (which is essentially worthless at the 90-day limit EULAs set, but that's beside the point.) Actually, this type of restriction would seem to put a damper on massive bundling of free/cheap software as well as game companies dumping old games in the bargain bins, as warranty obligations can get pretty expensive. This could use a bit of rethinking.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
Perhaps this could work in our favor;
:)
By the time you have read this warrenty, or installed the product, your warrenty is null and void. You could call us, but we won't pick up the phone.
It's almost as good as Microsoft's
Tibbon
tibbon.com
Amend the UCITA so that all software sold is required either:
- to provide a warranty, or
- to provide full open access to the source code so the user may modify it as they see fit.
completely at the pleasure of the software author or vendor."Provided by the management for your protection."
Maybe requiring to have a warranty *option* *available* would be more feasible. Vendors
could sell (or give away) unwarrantied versions,
and sell warrantied versions, for consumers that
demanded them. The price difference would be up to the vendor.
...in particular:
"And software distributed for free would still be required under UCITA to carry a warranty if there's a charge for installation services or an accompanying maintenance contract."
You take money to install/maintain it, you provide a warrantee. I like the sound of that; otherwise you could be any old chump just taking peoples money.
Note also that:
"the new UCITA would exempt from warranty an Open Source product that was sold for the cost of the media it was on, such as a $3 Linux CD set."
Which again makes perfect sense. Where it gets hazy is when 'free' software is sold for a cost above media but obviously below the amount required for maintenance; this will be a tough thing to iron out.
> And software distributed for free would still
> be required under UCITA to carry a warranty if
> there's a charge for installation services or
> an accompanying maintenance contract.
That seems pretty reasonable. If I agree to install open source software to do X and charge you for it and the software doesn't do X I'm in breach.
That doesn't effect open source it effects pay distributions which makes claims. The article says as much, "One is an acknowledgment that a notice license -- such as the GPL or BSD licenses -- is not governed by UCITA, as opposed to contractual licenses".
In any case the worse that UCITA has ever had is "Implied warranty of merchantability. An implied obligation that a computer program will be fit for the ordinary purposes for which it is used. UCITA makes this warranty applicable to all computer programs, thus expanding the scope to software currently governed by common law which does not have this warranty." This is a clarification of the law. For example if SAMBA releases a beta version it wouldn't be covered because beta software's common use is to help find bugs and allow for layored developement in the future release version. If SAMBA released a release version for free it wouldn't be covered. If RedHat said on their box "the new SAMBA 3 will allow you to add a Linux box to a Windows 2000 domain" then SAMBA 3 as shipped by RedHat would need to provide that functionality. If RedHat is bothering to check out SAMBA 3 then they can't make claims about its functionality when the sell the distribution instead they can say, "The package includes a functional version of Samba 3, the Samba 3 group claims this allow you to add a Linux box to a Windows 2000 domain" which is probably a more accurete description of their state of knowledge at the time the distribution is released. The net effect of this is that paid distributions can't engage in false advertising. I don't know any that really do though some are a bit careless in their language. This may be a good thing for Open Source as it will require distributions to clearly describe what they do and what they don't do.
If the limit of one's *LIABILITY* under the warranty was the cost
of the software license - then we'd be OK.
* OpenSource Software authors charge $0 for their code,
so their liability is $0. There is a warranty - but it's
practical impact is zero.
* RedHat et al charge for the cost of putting free software
onto physical media - but the software is still free so
long as it can still be freely redistributed. So their
liability is only for the non-free parts of their distro.
That's also fine by me - it gives them an incentive to
keep their distro's squeaky-clean and freely distributable.
* Microsoft suffer horribly because whenever WORD crashes,
I can demand to be refunded the entire cost of the package.
They'd go bust *very* quickly - which is fine by me!
* Large software companies that produce reasonably reliable
code and charge reasonable amounts of money for it are
under great incentive to write code that (whilst it may
not be 100% bug-free) is sufficiently reliable that they
won't get significant numbers of warranty returns.
Good!
If the limit of liability is the cost of the *damage* done by
bad software then it's not just the OpenSource world that'll
be out of business - it would be hard to imagine *ANY* generic
software such as operating systems, compilers, word processors
surviving the barrage of law suits that would immediately result.
Bring it on I say!
www.sjbaker.org
How can you provide a warranty against bugs when you have teenagers from all over the world making random changes to your codebase on Sourceforge?
1. Give away shoddy free software, written by teenagers from all over the world making random changes to your codebase.
2. Offer paid-for warranty / support
3. Profit!!
Idemnify authors of public domain information against civil legal threat arising from the work itself or derivative works.
That's why the UCB, MIT, and CMU Licenses exist in the first place, rather than the code being placed in the public domain.
If you want to control your code after the fact, fine: accept the liablity associated with doing that, as your cost for the payment of being granted that control. The sole reason most University developed code in these cases is not in the public domain is that a license was required to obtainlegal indemnification.
I don't think this would keep people from releasing under the (L)GPL or Artistic License or MPL, or SCSL, etc., if they felt the control they got by affixing the license was worth the cost.
-- Terry
No one wants to be responsible for anything anymore. That is why we have so many lawyers running around suing people. When something goes wrong someone has to be responsible. It could be the person himself who got in trouble or someone else, yet no one will ever take the responsibility upon themselves.
Slashdotters complain about lawyers suing for this and that all the time, yet they don't want to be responsible for the software they write. Write good software and provide a warranty, or else you are just promoting the lack of responsible ethics this country has.
Outdoor digital photography, mostly in New Engl
how about a money back gaurentee?
but it will cost a lot more...
Take cars for example, it's possible for a big company like GM to create a new car in a couple of weeks. But they have to give a warranty on it, and they have to make certain that the car is safe. So they spend months and months of testing the car in every immaginable way. They have to be sure that the car will be free from serious defects for at least the lenght of the warranty, but more than that for the safety (or they'll have costly recalls!).
You can do the same with software, where I work the testing time is often 3 to 4 times longer than the time it took to develop the program. So you have projects that took 1 month to make but 3 months to test. That's expensive but a bug in calculating interests for example can be a lot more expensive than that if you discover it a couple of years later!
Try it! Library of Babel
When you buy most open source software, what you're actually paying for is the packaging, documentation and distribution of same. You can guarantee this: If the shrink wrap is not broken, the CDs inside are guaranteed to be unbroken and free from scratches. The books inside are guaranteed to not be dog eared.
Other, custom open source software already has a kind of warranty- the contractor is writing it for you. If it doesn't work, he isn't finished yet.
It's easy to guarantee installation. It's installed properly, right? The maintainance contract is in itself a form of warranty.
None of these are ways of weaseling out of ethical obligations. They reflect the realistic expectations of just about everybody involved in computers and open source. Free software isn't a product to be sold, so it in and of itself can not have a real warranty. The things actually sold can realistically be guaranteed. If the stupid politicians want to force geeks to expose themselves to financial liability, then the geeks just have to expose themselves to the same liability that MS has always done: none. Including the source code can be its own insurance. A lot of "liability" can be shifted if the customer has it.
Basically this is a layer of overhead that proprietary guys already have (without adding to their responsibilities) and now they want to saddle open source folks with the expense and distraction while adding to their FUD. Easy to get around, easy to overcome.
I spent a year in Iraq looking for WMD and all I found was this lousy sig.
If lawyers are suing fast food chains for cauing obesity health problems, it is only a matter of time before they latch onto the software industry. MicroSoft has $38 billion in cash tempting them.
Easy. Let the warranty state that if the users are not satisfied with the free software product, they will get their money back.
My opinion? See above.
No of course not since these events could not have been forseen. Or at least not by anyone who does not live in hollywood.
Most software faults occur because of mismatch between products, bad configuration or improper use. Responsible programmers and most are will of course attempt to test their work first but they are only human. They can not be asked to predict every possible situation that may cause their program to fail. If you think otherwise please list them all for you're most popular piece of software.
Most bugs in software can only be getting rid of by testing it in the wild in customers, you youreselve say so. How exaclty should this be done if the testers can sue for any bugs?
You would envision a world where nothing can be released before it has been proven 100% safe. The world would be very boring indeed if this ever happened. But lets agree on a happy medium, a great big yellow sticker on all open source software.
Warning, product when installed will consume space on HD of more then 0 bytes.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
At first I thought that nobody would win with software warranties, but then I realized that Microsoft would. They could weather the legal storm, whereas Linux couldn't.
In reality though, there could be no warranty. It would be so jam-packed with disclaimers it would basically be useless. Bumper to bumper warranty my ass - read the fine print.
My beliefs do not require that you agree with them.
Comment removed based on user account deletion
The solution to this is trivial. If you don't pay for software, you aren't required to be given any warranty. Fair enough? Then free software released to the public and not paid for is under no obligation to provide a warranty.
In the case of RedHat or other vendors of Linux software, they would, of course be responsible for providing a warranty on the software they include in their package. Any liability related to that software being solely born by RedHat, who's making the money, not the original developers/maintainers of the software.
Is this really that hard or unintuitive?
This sig has been temporarily disconnected or is no longer in service
I agree with RedHat, here is my reasoning.
One of the major warranty problems I see in commercial software is the lack of a requirement for a commercial software vendor to fix bugs that impact the customer. With Open Source software, the customer has the ability to fix the problem on their own. (Either themselves, or through contractors.) That is the major difference. Another question, is who really owns GPL'd software? Is it Mr. Public Domain? Ok, let all get together an sue Mr. Public. In Open Source, the customer actually takes over more ownership of the software than in most commercial licenses. Don't believe me? Try to distribute MS Office in mass quantities and see what happens. Then look at Mandrake, a RedHat "core" user.
The rules are different. The end user product is different. It is like leasing a car which must be fixed at a certain dealer vs. buying a car you can take to any mechanic.
-Pete
Soccer Goal Plans
So if I write software today, should I guarentee that it will work will ALL previous versions of Windows with ANY hardware configuration as well as any future versions of both hardware and the OS? I welcome YOU to the real world. You obviously don't write software for a living.
My responsibilities include things like paying bills, for which I need to work for a company that will stay around because they aren't getting sued into oblivion because some customer was stupid enough to open the program's data files in Wordpad and save them back as formatted text. Because that same customer will never admit they did that and if there aren't logfiles showing they did such a thing, you may still have to defend yourself in court, and that costs money.
Does anybody expect that group to write any thing but a set of rules that favores their profession -- ie, the more litigation the better?
these issues have to be looked at, but technical people, and business people -- not just 300 ambulance chasers -- need to be involved.
deserve's got nothing to do with it...
No, fedral laws are laws that must be the same for all states. Uniform state laws are laws that it would be nice if they were the same in every state, but they don't need to be.
Note the difference. If it is fedral law it is the same. State laws allow for differences when either residents disagree, or there is a compelling difference between states.
I belive the fedral goverment has taken far too much power in the name of keeping things the same between states when in fact there is no need to keep the the same, it is just nice.
I understand that the UCITA works only in the US, so does it cover me if (a) I buy software from directly from a website for instance that is base din the USA and I'm in Europe. Or (b) the other way round, me being inthe USA buys software froma website based in Europe? Or does it depend on where I regsiter the software? Or what?
----------------------------------- My Other Sig Is Hilarious -----------------------------------
This person's comment is well-reasoned, and well-stated. There is no reason that this comment should have been modded-down. His first paragraph is a bit argumentative, but the second one is much better and should easily be worth more then the first.
Just because you don't argee with him, doesn't mean you should mod him down.
Obviously if you are able to compile your own code and it blows up then you are responsible. If, however, I have to look at a warranty for a Microsoft solution and one that has been more thoroughly tested and implemented in say Red Hat's version of Linux, then hands down I'll take the Red Hat version. Having to supply a warranty and therefore taking some liability is Microsoft's worse nightmare. Could you imagine being held financially liable for all the failures of IIS (nimda's, Iloveyous and so on)
Its worth noting that in other jurisdictions an "implied warranty of merchantability", to use the phrase common in the USA, cannot be disclaimed. IMHO this is probably one of the reasons that software companies are so reluctant to admit to selling you a product rather than licensing you to use it. If, for example, in the UK they were to sell you a piece of software rather than a license to use it then the sale of goods act would require that it was "of merchantable quality". Selling you a license seems to apply that standard to the license not to the software itself and guess what - "you're allowed to use it, therefore the license we sold you has performed exactly the function we sold it for..."
Maybe the law should require that when puchasing a software license that exchanges a one-time fee for a non-expiring license then that transaction must be treated as a de facto sale of this copy of the software. Instant applicability of implied warranties and, as a side note, also strengthening the applicability of the first sale doctrine and making sure that an EULA cannot limit a customers rights any more severely than in any other sale.
Of course, if that were ever to happen then commercial software users would really be in trouble. The software companies would sell nothing but subscriptions, licenses would last a year at most (assuming the loophole of "not a non-expiring license - it expires in 99 years" is plugged) and every piece of commercial software would contain timebombs.
Unfortunately, for so long as people want what they are selling badly enough the software giants hope to get away with providing it on any terms they want. THAT is why they are so scared of open source and/or free software. Even if we admit the questionable argument that commercially produced software is supposedly "higher quality" (dont see it myself but...) we are already at the stage where mainstream users are finding their relationship with the software companies almost as inconvenient as coping with the supposed shortfalls of open source alternatives. Add just that little bit of extra hassle (like recurring fees, time-limited installations etc...) and the balance could easily tip.
I had a
Doctors continue to be terrible when it comes to disclosing what the drugs they proscribe do and when they will fail to work. I can't get my doctor to say things like, "well there are 9 possibilities here: a with probability 85%, b with probability 4%..... i with probability .0007%". I think the cost of testing is too high to justify checking for anything other than a vs. b so I'm going to test for b and if that fails assume you have a. etc...
Why doesn't every dermitologist have a book with common skin diseases and a description of the possible treatments they could give it to the patient "read chapter 7 to understand the possiblities and we'll talk tomorrow to decide what you want to do". Similarly with Cartiologists, etc...
"So if I write software today, should I guarentee that it will work will ALL previous versions of Windows with ANY hardware configuration as well as any future versions of both hardware and the OS?"
Simply specify which OS version it will work on, and peg it down to that version. As for hardware incompatability, that's just lousy code.
"I welcome YOU to the real world. You obviously don't write software for a living."
Actually I do, and I have yet to write software that doesn't work as expected. I certainly don't release production code untill I absolutely know it will work as expected.
"My responsibilities include things like paying bills, for which I need to work for a company that will stay around because they aren't getting sued into oblivion because some customer was stupid enough to open the program's data files in Wordpad and save them back as formatted text. Because that same customer will never admit they did that and if there aren't logfiles showing they did such a thing, you may still have to defend yourself in court, and that costs money."
If the customer does that then it's their problem just as if I took my car off road it would be my problem. Warranties don't cover misuse. Sure, defense costs money, but a countersuit for legal fees would be in order.
Steve's Computer Service, Hobbs, NM
This is all fine and dandy by me, PROVIDED that the warranty is null and void if you haven't updated the software to the latest version. Onus for that should be entirely on the head of the end user. Then I guess there should be some reasonable period of time where updates are free, so somebody can't release a $10 updated once a week, and claim that your warranty is hosed if you don't pay it. Other than that, I can see this working out.
do not read this line twice.
In other words, the Red Hat's of this world would have to check that distro they're selling at $50 a pop or whatever actually contains working programs.
Debian, on the other hand, who sell nothing would not be forced to provide a warranty. Neither would I, if I just started up my trifling little open-source project and gave the results away for free. Neither would kernel.org, because they give their results away for free as well.
Interestingly, Red Hat wouldn't have to provide a warranty to me either, since I just download the ISOs. They haven't sold me anything.
Sounds eminently reasonable to me. If I pay for something, I want to know it works. If I'm just aquiring stuff for free, I have no right to demand a warranty from anyone.
Cheers,
Ian
I don't know about that. Lots of software I use doesn't have any bugs. Little simple programs meant to do one thing, and to do it well. Give the program some bad data and yeah it'll crash, but thats not a 'bug', that's a dumb user. There is a difference.
No user can reasonably evaluate binaries for suitability [they'll have more than enough trouble with `c`, but at least could do it]. Yet no coder can predict all the crazy cases that users will run. There has to be some shared work.
"and objections raised to the resulting language by Red Hat lawyer Carol Kunze. Among other things, Kunze points out that Free software projects could be effectively discouraged from releasing software if software producers are required to provide warranties -- imagine trying to provide warranties on all the packages available to Debian users, for instance, or every bit of software included with Mandrake Linux."
/. geeks idea of reasonable) support your product then you should not be in business.
This is the cost of doing business. It sounds like RedHat just wants a "free-ride" without all the problems of competing in a free market. I think it would be a far greater travesty to allow legislation to seperate OSS/Free Software from proproetary software solution providers. Business is business and if you can't provide and reasonably (based on a legal definition fo reasonable, not some
Simply specify which OS version it will work on, and peg it down to that version. As for hardware incompatability, that's just lousy code.
Ok, so if the system dies while I'm trying to send commands to the printer, who's fault is that? The print drivers, Windows for facilitating the communication, or our fault? What if it only happens on one users specific computer and even by duplicating the exact system setup, it can't be recreated? I just got my home built W2K system completely stable after spending all sorts of time tweaking BIOS settings that control timings. Those settings are in there because even hardware can have problems being 100% compatible.
How do you expect humans to write perfect code when we can't do anything else perfect? It took quite a while for engineers to get bridge building 100%, and yet sometimes unexpected variables were still recently encountered (Tacoma Narrows). And there's a hell of a lot less variables in building physical structures than writing code that has to run side by side with 20+ other programs and not have problems. When physical structures have problems you can fall back on constants such as gravity. There's no promise that the bytes in memory will be the same every time you run your program.
Your a developer? Has a bug ever been found in your code after it's been shipped?
I think you'll find that this is the intention behind a law to force software to provide warrantees ;)
Just FYI: My dad runs his home PC on Windows 95. Some of his friends use Windows 3.1. They don't suffer continual failures, etc, that we usually attribute to these systems. When you aren't pushing the OS, and are running reliable applications on top of it, you can expect many years of good service, even from w95. Sadly, it is hardware failures and the lack of w95 driver support on new peripherals that are forcing him to consider a sidegrade to a newer version of windows.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
If a printer driver or piece of hardware fails it's not covered under the software warranty. Simple.
Bugs? Not that's laughable. I don't accept bugs, I track down and eradicate bugs, I do weird and unexpected shit just to find bugs, and I test it untill my fingers bleed (metaphorically) to just find bugs. No, my code has no bugs when it ships. It's not that hard, just takes a few things called 'diligence', 'responsibility', and 'knowing what the hell you are doing'.
But, I also learned first to program in assembly (by hand), then higher languages later. Buggy code is just the result of a lazy programmer that doesn't plan ahead and can't handle surprises well.
"How do you expect humans to write perfect code when we can't do anything else perfect?"
All it takes is focus.
"It took quite a while for engineers to get bridge building 100%, and yet sometimes unexpected variables were still recently encountered (Tacoma Narrows)."
Basicaly the Tacoma Narrows failure was more of a problem arising from an aesthetic reason (side panels covering the ugly underside supports which created wind drag that lead to the fault), and the engineer should have known better.
"And there's a hell of a lot less variables in building physical structures than writing code that has to run side by side with 20+ other programs and not have problems."
Side by side or depending on. There's a difference.
"When physical structures have problems you can fall back on constants such as gravity. There's no promise that the bytes in memory will be the same every time you run your program."
If your program is written well then the bytes in memory should be the same every time you run your program. No, they total bytes in memory won't be the same, but your program should handle allocations and referencing the same every time which makes the question of where they bytes are in memory a moot point. In other words... don't hard code memory references.
Steve's Computer Service, Hobbs, NM
If it's an expression, then it's protected by Free Speech guarantees, and is copyrightable. And the concept of warranty doesn't make sense.
If it's a machine, then liability and rental contracts make sense, but speech protection and copyright don't.
When someone speaks an imperative command, you may decide to obey it. But when you do, the expression didn't magically just transform into a machine. You are the machine. Don't ever forget that. "Below every tangled hierarchy lies an inviolate level" -- Douglas Hofstadter.
Keep the warranty and liability discussion limited to machines. It's the user's decision, what commands that machine obeys. If you don't want the risk, then don't run the software. And don't call me an elitist snob for saying that people should be responsible for their computers. Yeah, it's a hard responsibility to take. So what? Why should difficulty somehow get you off the hook?
Medicine is a difficult topic to master as well, and those who have and given the title "Doctor." But that difficulty doesn't mean that people aren't responsible for their own health. Oh wait, that's exactly what some people are saying... What a price, indeed.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
We're talking about changes to UCITA here. But do not forget, UCITA was written by Commercial Software Comapanies for Commercial Software Companies.
... its all up to them) to continue to use their software. Oh and those audit letters, with self help in UCITA they would just shut everything down first and then force you pay whatever they thought was the right amount.
They are trying to make shrinkwrap licenses enforcable with UCITA. They are trying to get provisions to provide self-help (read turning off your software) in cases of licensing disputes. Red Hat is just saying that they don't want shrinkwap licenses like everyone else.
UCITA is designed so that Microsoft can pop up a window to charge your credit card every (year, month, week
Even without self help, UCITA will still fully enable enforcement of shrinkwrap licenses (all of which will disavow warranties), and their randomly changable nature.
UCITA is not about consumer protection, its about complete and total abuse of consumers.
Bugs? Not that's laughable. I don't accept bugs, I track down and eradicate bugs, I do weird and unexpected shit just to find bugs, and I test it untill my fingers bleed (metaphorically) to just find bugs. No, my code has no bugs when it ships. It's not that hard, just takes a few things called 'diligence', 'responsibility', and 'knowing what the hell you are doing'.
My ass. If you're writing code for Windows, chances are you will never know what the hell you are doing. And if you say you do, you're a liar. If you're writing for DOS 5.0 or an embedded system then yes, maybe you can be right. I don't know about Linux programming pitfalls (at least I admit it).
I also learned first to program in assembly (by hand), then higher languages later.
I learned BASIC first and then jumped over to assembly and then to pascal where I've been ever since. Assembly is valuable, especially in tracking down bugs and tracing through CPU instructions, but it really won't help you write better code to begin with.
Buggy code is just the result of a lazy programmer that doesn't plan ahead and can't handle surprises well.
Surprises such as receiving a function result out of the documented range, or surprises such as the boss now wants to quadruple the size and complexity of the entire program and thinks it should only take a week?
Red Hat is arguing against the UCITA, not for it. The UCITA, in case for forget, put legal muscle behind unenforceables such as MS-EULA's saying you give full control of your hardware to microsoft.
The UCITA is heavily ANTI-consumer, and PRO-corporate. It will not benefit consumers, it will injure them. If you recall, RedHat doesnt put crap like this in EULA's, and you can use RedHat software *without* accepting to or agreeing with the GPL or BSD. (Only redistribution requires that)
You say that Red Hat is asking for welfare: bullshit. At worst they are asking for the playing field not to be tilted against them anymore than it already is. We consumers will bear the cost if we dont listen to them.
If you think the UCITA is good for the typical software user, then you are deluded.
Well, then this bill will kill Open Source development because it will allow companies to recoup losses from commercial software companies.
Look, it's fairly simple. Specify the system that the software was tested on and provide a warranty for matching configurations only. Any other configuration voids the warranty.
I'm generalizing, but it would seem that the problem lies more with software companies avoiding the moral responsibility to fix bugs in previously released software, than any attempt at malice. So while UCITA might mean well, we know what road is paved with good intentions.
To celebrate the occasion of my 1000th post, I will post no more forever on Slashdot. Goodbye.
Digital used to put out a document, called the software product description (SPD), and then warrantied that the software would perform as the SPD said.
Users would either get a problem reported as a bug, and fixed, or could get their money back.
Linux should do the same, each distribution should have such a document, stating what Linux does, and warrants against it. If a problem is found, either accept the problem as a bug, and promise a resolution. Or give the money back, that was paid for the distro.
It isn't that far from the current Linux model, in that there is an army of people looking to fix various bugs, IE things that don't work as documented.
"My ass. If you're writing code for Windows, chances are you will never know what the hell you are doing. And if you say you do, you're a liar."
Then you may call me a liar. I always know what the hell I am doing. Unlike others I don't bit-twiddle and otherwise try tricks with any operating system. I let it do it's job, it let's my code do it's job, and everybody get's along.
"If you're writing for DOS 5.0 or an embedded system then yes, maybe you can be right. I don't know about Linux programming pitfalls (at least I admit it)."
There should be any programming pitfalls regarding operating systems if you let the operating system do it's job.
"I learned BASIC first and then jumped over to assembly and then to pascal where I've been ever since. Assembly is valuable, especially in tracking down bugs and tracing through CPU instructions, but it really won't help you write better code to begin with."
Actually it does. It forces you to write tight, clean code. People that have learned only higher level languages have learned to write dirty, bloated, and sloppy code. They never learned how to trace instructions wheather it be in asm, BASIC, or C variants. That's why bugs are rampant.
"Surprises such as receiving a function result out of the documented range, or surprises such as the boss now wants to quadruple the size and complexity of the entire program and thinks it should only take a week?"
Basically, yes. If they ensure that the input to the function is correct instead of letting random input get to it then they can avoid unexpected function returns completely (getting out of range function returns just shows that the programmer doesn't understand the function and should either read up on it or get another job). As for bosses... it just makes life more exciting.
Steve's Computer Service, Hobbs, NM
It is wrong to blame those who choose to hold others to their professional obligations.
The fact that bad doctors continue to practice medicine is the real problem. The problem of frivolous litigation is easy enough to solve by screening cases first.
In my own state, such a panel was removed at the request of the insurance industry because it made it more difficult for them to weasel out of their responsibility. Our review board eliminated 90% of cases before they ever got to trial. They also ensured that any case that got to a jury had been reviewed by doctors not on the payroll of lawyers or insurance companies. If you want to talk about sleaze and burdens upon the medical profession, point your fingers to insurance companies, not lawyers.
Insurance companies love to take your money and will never get it back unless they're FORCED. They don't even want to pay their own defense counsel. They hire special consultants who's only job it is is to find lame excuses not to pay for billable work.
Meanwhile, bad doctors still get to practice. THEY are the ones that increase malpractice insurance premiums.
Would you blame lawyers for the high auto insurance premiums in places such as Los Angeles where the drivers are maniacs?
If you really want to "kill all the lawyers", at least be equitable and start with insurance claims adjusters first.
A Pirate and a Puritan look the same on a balance sheet.
Would the UCITA warranty requirements apply to alpha and beta releases? I haven't seen any mention of this topic, so I'd assume that the law treats all software the same in this respect.
If so, it would effectively stop such releases, since they would be a guaranteed legal and financial disaster. But clearly labelled alpha and beta releases are a very good approach to getting customer feedback, both for bugs and for features that are difficult to understand (or missing).
This is one of the ways in which software is different from most other commercial products. It's fairly rare for companies to provide test versions of products to customers, though it does happen. But it's very common with software.
If the UCITA inhibits alpha and beta releases, the result would be much lower quality software.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Then you may call me a liar. I always know what the hell I am doing. Unlike others I don't bit-twiddle and otherwise try tricks with any operating system. I let it do it's job, it let's my code do it's job, and everybody get's along.
You haven't stated what OS you're developing for. And if you say Windows, you ARE a liar. Windows doesn't consistently do it's job correctly, so unless you're only writing hello world applications for systems that don't have any hardware aside from a name brand video card (other than ATI) then you MUST have bugs, it's that simple. The OS SHOULD just do it's job, but the OS is also responsible for facilitating communication between your program and the hardware of the computer, be it the video card, NIC, printer, etc. and if any one of those things returns something "funny", and you're relying on the value it returns to process the data or make a decision based on the value, then you can have a major problem unless you have at least a 2:1 ratio of functional code vs. error handling code.
Ok, now I know I've dug myself into a hole concerning programming theories here and the ideal way of how code should work, but what you're saying just isn't practical for the most part in the world of marketing driven deadlines that at least I have to live in (you may be different).
I mean the metal turning kind can make any tool for you that BMW can make. Think of it as real open sourse hardware.
Your responsibility. The VCR behaved as it is supposed to - it started taping when receiving the RECORD command that happened to be the same as the TV's ON command. It behaved as expected, even if the operation was not what you desired. If the VCR accidently erased the tape because the TV overloaded the VCR's input or something, you might have a case against the makers TV - it is supposed to provide a certain level of input, but failed to do so.
If I buy a replacement wheel that comes off my car because the car and wheel manufacturers interpreted the specifications differently, who is responsible?
Either the person who installed the wheel and didn't notice that it wasn't fitting correctly, or the manufactorer of the wheel who failed to test the wheel intended for the car with the car modelis responsible. This is different from software in that the wheel is intended to function with the car, and failure to do so indicates a failure on behalf of the manufactorer. Unless you just underinflated your Firestone tires on your Ford Explorer :).
While the second example is closer to a situation you might have on a computer with a combination of software and hardware, it assumes a specific piece of "software" (get it - software - rubber tire - no? ... ok) that is designed specifically to work with a well defined piece of hardware, the car.
A computer is not a well-defined piece of hardware and software - minor differences in the interaction between two well tested pieces of software can cause issues that were unexpected. In my example, Product A was designed to work with Version 1 of Product C - but not tested against Version 2, which fixes some bugs and introduces a new one that Product A accidently exploits.
If the software is poorly tested, then yes, it might be fair to make the vendor responsible. But outside of providing fixes in a reasonable period of time, how much more responsibility do you want them to take? Software warranties should either require vendors to either provide patches or indicate that the product will not work in certain scenarios - they shouldn't make the vendor financially responsible for damages when the damages were caused by a scenario that could not be predicted. Especially when the cause is a specific interaction between multiple components that causes the error and is not directly the fault of any individual component. (Like Blizzard games and my network card, which do not get along together. Blizzard game + My network card = BSOD. Really fun when you die in Diablo II due to a BSOD. At least StarCraft only crashes on exit, and Warcraft III just kills incoming/outgoing connections over the specific port used. But then again, it might not be either companies fault - I think Microsoft's Windows Update uploaded an incorrect driver for my network card. So who do I blame?...)
You are in a maze of twisty little relative jumps, all alike.
"but what you're saying just isn't practical for the most part in the world of marketing driven deadlines that at least I have to live in (you may be different)."
There's the crux of the situation. "marketing driven deadlines" force buggy code out the door for a large majority of programmers. But when the bugs are out there who get's the shit? The programmers. I'm simply one that stands up to the marketers and bosses and tell em their expectations are ridiculous, and it doesn't ship till it works right (usually their stated expectations are followed immediately by my laughter).
Windows does consistenly do it's job correctly. That's the funny part. What doesn't consistently do it's job correctly is all the other crappy software and drivers installed in any users given system. In other words, if Excel tries to screw with the memory I have allocated for my software and causes a system error it's not my problem. It's Microsofts problem with Excel because their programmers didn't do their job correctly and Microsoft shipped out code full of shit. I use Excel as an example because it's notorious for causing system errors to report that 'x' program caused the error even though it's actually Excel taht caused the error. It's so shit laden that it causes memory access and allocation errors within itself, and should be the poster child for enforcable software warranties.
Steve's Computer Service, Hobbs, NM
The Oklahoma warranty that comes with most software clearly states:
If it breaks in half, you get to keep both parts.
Offering a stronger warranty isn't in the best interests of developers, because it adds liability. That's certainly something that would add weight to "Trustworthy Computing" and "Unbreakable" databases. Until legislation (such as the UCITA) specifies what legal warranty a user can expect from paid software, I won't expect to get one.
In any event, I'd expect different treatment for source code than binaries, seeing as how you can fix it if something breaks, or pay someone else who can.
JH
Any connection between your reality and mine is purely coincidental.
Industry-standard warranties are designed to ensure mechantability. This is most applicable when the user doesn't have an option of what how to get support for what he's bought. With Open Source/Free Software, this is not an issue; the user can fix it himself or hire a third-party. If the user wants a warranty, then consider paying for one by buying a RedHat product; however, don't mandate that RedHat always provide one.
In this day and age I'm certainly not a fully free-market advocate, but I certainly don't see a problem with having users simply pay for warranties when they want one. With Open Source/Free Software, they are free to choose their support; there is no reason to tie together the seller with the supporter. This tie is only true for proprietary software, where all of the support companies are beholden to the proprietary vendor.
usually their stated expectations are followed immediately by my laughter
;)
Must be nice to have that kind of job security
What doesn't consistently do it's job correctly is all the other crappy software and drivers installed in any users given system
Drivers are a special case, they technically are part of the system, but just not developed by the people that did the rest of the system. Hardware manufacturers should probably have a closer relationship with MS than most seem to. I know MS has their WHQL but I don't think it's a requirement that drivers be run through that process, but maybe it should be a requirement.
Honestly though it would be nice to see the code for some of the Windows API functions instead of relying on the scant documentation MS provides.
EGO! check out this -> http://slashdot.org/article.pl?sid=02/07/15/004324 7&mode=nested&tid=126
I agree with you about the car warranty analogy. However, I have an interesting question for you and all the /.'ers:
If the commercial product must carry a warranty, what is the commercial product regardig Red Hat Linux?
Arguably it is the entire distribution and not any piece of included software not developed exclusively for this distribution. Or it includes every piece of code included with the distribution.
The problem with the UCITA is that it does not make this clear-- it would require a test case in court and Red Hat really doesn't want to have to be that test case. The question is, would RedHat have to warranty PostgreSQL or just the integration factors of PostgreSQL within the distribution?
Also, what constitutes price of media? If you can freely download the software, but I charge for a support contract, is this different under UCITA than selling the software outright? (Probably, but IANAL, and it might require a test case.)
A lawyer once told me "you don't want to be a test case." In other words, if you want to keep out of trouble, follow an extremely careful interpretation of the law and avoid all gray areas. I think that Red Hat's concern is that they could end up fielding the majority of these test cases.
To play devil's advocate here-- so what if this destroys Red Hat? Maybe we need to move toward a community maintained distribution. After all it would be hard to sue the Debian developers under these laws. Red Hat could adapt and encourage other developers to help with building the next generation distribution based on their earlier work, and if they can't adapt, well, then thy won't make it anyway.
Again, IANAL, and I think it would be interesting to hear others' opinions on how these changes could affect open source software.
LedgerSMB: Open source Accounting/ERP
Unfortunately, if this is a requirement, then the distribution media will need to be encoded to ensure that you must have encountered the notice before being able to access the software.
This is still a bad law. And we are only skimming the surface. (It was reported be 2,000 pages long a year ago. How long is it now?)
I think we've pushed this "anyone can grow up to be president" thing too far.
"Honestly though it would be nice to see the code for some of the Windows API functions instead of relying on the scant documentation MS provides."
It certainly would. There are quite a lot of improvements that could be made, but MS won't improve on them since they (marginally) work as they are.
Steve's Computer Service, Hobbs, NM
If you get a receipt of purchase, you should get a warranty. Otherwise, all bets are off.
MS won't improve on them since they (marginally) work as they are.
;-)
Hey, I though you said they work just fine, it's the applications and drivers that don't work right
Making Free Software developers liable for damages is a truly scary thing. But warranties, even mandatory, for Free Software is a nothingburger.
I will gladly refund the full purchase price for my software to any disatisfied parties. Duh! The purchase price was zero!
Commercial distributions should also have no qualms about including a warranty. It has nothing to do with the number of packages. It has everything to do with the purchase price.
A Government Is a Body of People, Usually Notably Ungoverned
So does a Ford Pinto.
It works as it is, but could use improvement.
Steve's Computer Service, Hobbs, NM
Isn't the "fairness" to different businesses. It's the lawyer friendly addition of more legalease.
In actual application, UCITA attempts to create a "default" license model under which all software is sold. Then it creates mechanisms companies can use to over-ride the defaults. One of these mechanisms happens to be "click-wrapped" agreements. This really just means more legalese for everyone, and which ever companies hire lots of lawyers benefit. (Redhat included)
If the courts really do feel that software companies haven't been responsible, they should hit the co's with fines based on what was charged for faulty product. This is how consumer law has worked for many years. If you sell something and the consumer becomes dissatisfied, you'll probably have to give those dissatisfied a refund.
Perhaps what is really missing in UCITA is a gaurantee that legal liablity for software producers won't exceed price charged, unless extra warranties were offered. Also, that when not sold at retail some risk should remain with the consumer.
If RedHat really is worried about being charged more than they were paid in liability fees, then I commend them for knowing they should be scared, and I hope they get better at stating their case.
If instead, they are worried that they may have to give a refund on copies of their software where customers are legitimately dissatisfied, then I hope they quit whining, and behave like a real business.
I sereously doupt you could make a person libal for gifts.
Yes RedHat is hurt but not as a free software company but as a software vender.
RedHat often releases versions of RedHat that are by the authors own standards "Not ready" as part of RedHats compleate product.
What this means is Microsoft can't dodge responsability and RedHat can't get away with defective releases. Both companys compeate for worst os release ever.
Free software itself won't be effected. Unless RedHat masters FUD as they seem to be getting a grip on it with this issue.
If you give a friend a present your not libal for defects in the present even if you made it.
Oh yeah...
I am not a legal expert of any sort what so ever prioid and to suggest otherwise is Baka.
(Yes I had to throw in the word Baka)
I don't actually exist.
After all, the yankees are not alone in the Uiverse.
Interventionism by George Reisman (Pepperdine University).
It is instructive to never forget that the consumer always bears all costs, since consumers are the only source of wealth.
Bob-
The Ludwig von Mises Institute. The reasoning individuals economics