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.
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."
> 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.
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
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.
The difference is this. If you're going to release a product, keep the source secret and not allow the user to help themselves or provide reliable updates on a timely scale you should be responsible.
Open source software has nothing to gain from releasal (well maybe a lil fame and recognition) but no financial reward. It is important to note that software should be allowed to be given away with warranties proportionate to what you paid for it. You pay nothing you get nothing. In the case of microsoft you're paying 500+ dollars for the software and it doesnt work right. The total cost for a legit ms office installation for the small-business man is almost 1500 dollars for windows xp pro, office xp pro and other productivity tools such as quickbooks and quicken. This is MORE then the hardware cost which is currently supported under warranty for 12 months and with driver updates for as long as there are devices in use. i've got ati cards with current drivers for xp that were made in 90something.
With that said with the support based business models of redhat software etc SHOULD be liable for support they provide.
If redhat comes in and sets up an opensource installation for $ they should be allowed to setup reasonable restrictions on the user and at the same time be responsible when things break.
The excuse "the user must of screwed it up" doesnt go very far with me.
This would give the major distributions that use this revenue model incentives to contribute to auto-updating programs and better out-of-the-box setups such that _their_ installers could do the job faster better and cheaper.
In the true opensource for the community and the greater good of all sense there should be _NO_ liabilities for anything for any reason whatsoever.
BUT when you make money off something you are providing a promised service for a fee. You should be accountable that said service works as advertises and doesnt constantly break down modify its agreement with you or spy on you!
Punitive damages should be awarded to any company that gets rooted/exploited etc from a professionally setup system. This would increase the revenue from big businesses getting what they need from their products. The line just get joe in the IT department to setup the oracle/iis server should go away for large corporations and they should be (incentively) forced to contract to the software vendor for the product.
In this case opensource software gets revenue, support and businesses get the liability protection they so desire but currently cant get.
In conclusion. If theres money to be lost by microsoft, redhat or whoever they will be given a very powerful incentive to make better updating software and keep installations running correctly. But at the same time if you didnt pay for it dont expect any support liability protection or guarantees. The idea of some idiot mcse running companies servers really needs to go. Liability protection WOULD make this happen and make better software at the same time.
$0.02.
P.S. Dont bother flaming this reply with some stupid non-witty response I wont care. However if you want to reply in an informed and intelligent matter I will respond.
AFAIK, most software is without warranty
Currently, yes. Although if you sell it as a commercial good then there's usually the implied warrantee of it being usable for its marketed purpose.
Most EULA's disclaim any and all warrantees, which may or may not be legal depending on the state laws and legal system.
The change the UCITA brings is that there is a stronger implied warrantee - not only that software is good for its marketed purpose, but that it is non-damaging and reasonably bug free (note - IANAL, so I may be reading more into the UCITA than there is actually there). You can disclaim these warrantees (see above), but that requires an explicit agreement between the consumer and the vendor, in the form of an EULA or click wrap installer.
The Open Source world doesn't have either right now, at least by and large. And a lot of people in the OSS movement disagree with the concepts of an EULA and/or click-wrap licensing on an ethical standpoint. UCITA would require them to either change their standpoint or potentially get sued for thousands or millions of dollars.
As a developer I'm not sure where I stand on the issue. On one hand, I do believe that software should be held to the same standards as most other goods. If you tell me that TurboTax 2002 is a tax software program, then I expect it to do a reasonable job at filing my taxes and to not wipe my hard drive (disclaimer - I've never had a problem with TurboTax. Put the lawyers down). On the other hand, software is freaking complex, and the US is over litigious. Who knows what a judge and jury may decide is covered by the implied warrantee and what isn't, and certainly liability has the potential for killing OSS development dead within the US. Not a good thing.
The real problem with software is that it interacts with other software in a complex and often difficult to understand way. For example, if I discover that Product A managed to corrupt my hard drive and erase all my work, should the manufactorer of Product A be liable?
However, what if the reason Product A corrupted my hard drive was because Product B overwrote some of the libraries that Product A uses, causing an incompatibility. Now who is liable? The maker of Product A or Product B?
But for added fun, let's say that the libraries were part of Product C that both Product A and Product B use. And Product B overwrote Product A's libraries because it had a newer version of the software that supposedly had bug fixes in it. Now who is liable? Manufactorer A, B, or C?
For added fun, let's assume that the incompatibility was actually caused due to a bug in the BIOS, that caused data corruption when sending data to the harddrive. Now who's liable? A, B, C, or D - the manufactorer of the BIOS?
But we're not done yet. It turns out that the command the BIOS sends to the harddrive is invalid, and should cause the hard drive to signal an error back to the BIOS. But because of buggy firmware, it instead writes random data to a random location. So a combination of A, B, C, D, and a hard drive with buggy firmware by E is what caused the data corruption. So when A, B, C, D, and then E - the buggy harddrive - combine, your data can be corrupted.
So - who's responsible? Is A responsible - they bug tested their software with Version 1 of Product C. But Product B installed Version 2 of Product C. So is Product A or Product B the actual culprit? Or is Version 2 of Product C responsible? But then again, Product C only caused a bug in the BIOS - which gave a command to the harddrive that should have caused an error but instead caused data to be written in the wrong fashion.
The real problem with software is that frequently bugs can come up when there are weird combinations of hardware and software that cause software to enter into states that the manufactorer never expected. Plus when you throw viruses and programs that alter the way fundamental components of the OS interact (think drivers, debuggers, or special programs like display "enhancers" or firewalls), the total number of combinations that might cause damage rise incredibly, and it become infeasable to anticipate and test every combination.
Especially when it works in the test lab with 100% accuracy, because the test lab does not have the fatal combination of software and hardware that eventually causes damage. So even though every manufactorer tested their component to work assuming everything else was working properly, when one thing turns out to generate a slightly wrong command, a whole chain of incompatibilies can result. Making software warranties a huge blame game.
Software warranties are really only feasable for a given configuration, with the user understanding that installing new software or hardware and making certain configuration changes will void the warranty. Which makes them next to useless anyway. And if the software manufactorer releases a patch to fix a known issue, are they liable for the issue anymore if people do not install the patch within a reasonable amount of time?
Responsibility is fine, but sometimes responsibility just means providing a fix and telling people of known issues. It is impossible to warrant against every possible condition. This is why most warranties specifically disclaim liability if the owner uses the device in a fashion that is unintended - the manufactorer cannot warrant the device "work" in a scenario that it is not supposed to be used in.
You are in a maze of twisty little relative jumps, all alike.