What's (Still) Wrong With UCITA 261
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.
MS EULA (Score:5, Insightful)
Free projects should just copy Microsoft's license which, by the time it is done excluding things, provides nothing to the end user.
Re:MS EULA (Score:2)
The new UCITA appears to remove "help-yourself deactivation" for software providers, but how about the "We need root in order to warrant this software," argument?
Oh No...Responsibility!!!! (Score:2, Insightful)
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...
Re:Oh No...Responsibility!!!! (Score:5, Insightful)
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.
Re:Oh No...Responsibility!!!! (Score:2)
While these idead may actually sound good to YOU, these are 'Open Source Community concepts' that you are suggesting be put into law in America and that's not a good idea. If Jill gives Joe a program for free that she tells him is supposed to make webpages but ends up being specifically for formatting his harddrive, now we dont have a civil case. He shoulda paid for it? Are you suggesting a government body to read/decode sourcecode and make legal determiniations? While I agree, if I write and distribute a program, I am partially responsible for what it does (read: virus for example). The state of it being open source or not does not change my responsibility and does not help in accountability any more than a brand name nowadays.
This seems like a lot of talk about - how to best get back at the big corporations without legislating laws that can be used against my free software projects. Punishing capitalistic practices...charging what you can get...is the biggest barrier to these kinds of 'changes'. Good luck changing america's basic economic ideals.
The real problem with UCITA.... (Score:3, Insightful)
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.
Re:Oh No...Responsibility!!!! (Score:3, Insightful)
This law is NOT about the major distributors, it is about OPPRESSION --it is about keeping the best and brightest from being able to create something and SHARE it. In the end, that will FORCE us to buy stuff instead of taking the risk of downloading free software. I use Linux and several free apps and I do this by accepting the RISK of the software that is why I have to have a risk mitigation plan in place before I put the free software into production. I get to use both MS and Linux, both require a risk mitigation plan and MS is more likely to fail. I have never been able to recoop any money spent on the time it has taken me to fix my NT blue screen of death.
This law is effectively an attempt to force free software industry to become a FOR PROFIT ONLY or NOTHING AT ALL industry and this is constitutionally WRONG because it is taking away the freedom to create, share and communicate openly with other people.
Do you remember the days when hacking was cool? The days when if you found a security breach in an administrator's network and could call that admin and say, "Dude I found this gaping hole in your network."...and the admin would ask, "do you know how to fix it?" or "thanks I didn't know about that?" That was the days before the media got involved and the security task forces got involved. Realize WE CANNOT do that anymore and what has suffered? computer SECURITY because we cannot talk and share things anymore. If we allow this law to be passed it WILL in time take our communication away too that is its intent.
2 Ending questions:
1. do you hold MS financially liable when your server farm goes down because of something that MS forgot to fix? Hell no you don't, you are Eternally greatful that your shit works again.
2. Has MS been held financially liable for any thing that has blown up in their OS? Not to my knowledge, the only financial liablity they have is from trying to create a monopoly which will only grow stronger if this law if passed that takes away the openess of our community.
Re:Oh No...Responsibility!!!! (Score:2)
If I have power over you, I should be held responsible for how I use that power. If I get rid of that power, by giving you the ability to take matters into your own hands, didn't I just get rid of my responsibility too?
Re:Oh No...Responsibility!!!! (Score:4, Insightful)
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.
Re:Oh No...Responsibility!!!! (Score:2)
By that rationale, companies like Apple should have no problem providing a warranty for the OS. After all, they design (or pick) the hardware that goes into every computer. Apple has been touting this as an advantage for years.
Re:Oh No...Responsibility!!!! (Score:2)
Under their previous offerings this could cause some real issues (thus the extension manager and programs like Conflict Catcher were born). There probably should be something similar for Win2K, although Win2K is way more fault-tolerant than the older MacOSes.
I'm not sure how Linux avoids the issue, except that it rarely has full-featured drivers for the latest hardware.
Re:All products have compatibility issues (Score:2)
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?...)
Get a receipt, get a warranty (Score:2)
warranties!? (Score:3, Insightful)
Software can never be without problems.
Just imagine half the population putting lawsuits! Law will have to be outsourced mebbe!
Re:warranties!? (Score:2, Interesting)
Thats the problem... The customers shouldn't be required to take this shit. If you make a product available you should be responsible for it. Everyone else is.
We all know software is more complex than a microwave for example but there must still be basic resposibilities either way.
The cost that those resposibilities has should be considered when the price is set on the produt.
Re:warranties!? (Score:2, Informative)
I thought so too, but I just got some software that had a "limited warranty" on it. It came with my 3Com 802.11b card, and I was a little shocked when I found there was a "Software" section on the limited warranty card. The software did also come with a EULA, but the warranty actually said the software was guaranteed to provide reasonable functionality to the user (which is pretty basic, but at least they "guarantee" it). It's not much, but it's better than nothing.
Re:warranties!? (Score:2, Interesting)
Software used to come with warranties. When I first started work, the mainframe software had bugs but the supplier was contracted to fix (or provide work arounds) for any problems we encountered. Granted, we had to pay for this and the time to fix (and thus the priority given by the supplier) depended on the severity of impact to our business.
Most suppliers now make you wait, and pay, for the next version upgrade in order to get bugs fixed. So what would be wrong, both for closed and open source, software suppliers to provide a waranty to fix (genuine) bugs in a timely manner. To a great extent the open source community already does this. It often does not take long between a (serious) bug or security problem being reported and a fix being published.
Re:warranties!? (Score:5, Insightful)
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.
Mandatory warranties bad for Open Source (Score:3, Interesting)
Warrenty Example (Score:3, Funny)
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
Re:Warranty Example (Score:2)
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?)
Clear Solution (Score:5, Interesting)
Amend the UCITA so that all software sold is required either:
Re:Clear Solution (Score:2)
The warranty should read something like:
By using this product you certify yourself as an authoritative source of warranty for this product. Should you encounter problems, you are required to fix them in accordance with your expectations of the warranty.
Help people help themselves.
Re:Clear Solution (Score:3, Insightful)
Open Source provides access to the engine for you, but also a boatload of mechanics who would be more than happy to fix your problem for due remuneration.
Commercial software is buying a car with a welded hood and no source of solutions save the dealer. And I believe we all know how much we can trust most car dealers. (see any buyers guide for vehicles)
Re:Clear Solution (Score:2)
I assume you are aware that a number of higher end (umm ... luxury ;) ) vehicles these days effectively DO have welded hoods. The maintainable parts of the engine are locked away in compartments which require special tools to access - the type you can only get hold of it you agree to a dealer contract with the manufacturer.
Despite this, there are still millions of people who drive BMWs, and Windows.
Tool Makers... (Score:2)
Re:Clear Solution (Score:2)
There's a good (abbreviated, here) Rolls story about a (big) chopper full of engineers going out into the desert because a fellow broke his axle out there. So the engineers flew out and fixed it on the spot. When the fellow got back and called to ask how much is was for the repairs, Rolls asked "What broke?" The man said "The axle". The Rolls rep said "Oh, I'm sorry, you must be mistaken. The axle on a Rolls Royce would never break." >click
Cavaliers do not have the same level of service, IMHO.
Re:Proven reputation of reliability (Score:2)
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.
Re:Clear Solution (Score:2)
Re:Clear Solution (Score:2)
Sell warranties and products separate (Score:2, Interesting)
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.
Re:Sell warranties and products separate (Score:2)
Let's see if I'm Microsoft, I'll charge $300 for a non-warranty version and $300,000 for a warranty version on a warranty that lasts all of three years. Big companies are basically forced to use warranty one on critical computers because when they call for tech support they are told to buy the warranty version.
I do like the option previously commented:
1) Stand behind your product (Warranty)
or
2) Let me fix it when it fucking breaks (Open Source)
Some of this makes sense (Score:3, Insightful)
"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.
Warranty (Score:5, Insightful)
> 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.
Re:Warranty (Score:3, Insightful)
No disagreement with your other comments about distributors of collections of software making clear the extent to which they are standing behind them.
<soapbox>
It seems to me that there's a certain amount of special pleading going on here from open-source advocates. On the one hand, claims are made for its superior quality and lower cost of ownership, but at the same time there's a strong tendency to devolve responsibility for checking that the quality is adequate to the people and organisations who decide to use it. And, as we've seen with some embarassing incidents recently, there's also a tendency to assume that the many-eyes checking has already been done - by other people.
I like the idea that software should be covered by the "fitness for ordinary use" criterion that applies to most other products and services; I don't see it as self-evident that open source software should automatically be given special treatment.
</soapbox>
--
Hey, where's my karma gone?
Fix it like this. (Score:2, Interesting)
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!
Re:Fix it like this. (Score:3, Insightful)
Re:Fix it like this. (Score:2)
Idemnify authors of public domain information (Score:4, Interesting)
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
Why do people fear responsibility? (Score:2)
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.
Re:Why do people fear responsibility? (Score:2)
So, do you want your money back? How do you want someone to accept financial liability for software that you never paid them for?
Re: (Score:2)
warrenty (Score:2, Insightful)
It's possible to make bug free software (Score:2, Interesting)
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!
Warranty solution (Score:2)
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.
if they can sue for fast food ... (Score:4, Insightful)
Re:if they can sue for fast food ... (Score:2)
Yes, but Microsoft also has $38 billion in cash to say "We can afford enough lawyers to sink a fleet of battleships. We can buy off anyone neccessary to make sure this case goes nowhere".
Maran
Free software warranties - the solution (Score:3, Insightful)
Easy. Let the warranty state that if the users are not satisfied with the free software product, they will get their money back.
I agree with UCITA (Score:5, Insightful)
Ring clarifies 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. But a Red Hat boxed set selling at Wal-Mart for $60 would fall under UCITA's warranty provisions.
"If you're packaging that as a commercial product, then you're in the business that every other software purveyor is in," Ring says. In Ring's way of thinking, you then should abide by the same warranty rules as the rest of the industry.
END QUOTE
What is wrong with this? I thought this was a major part of RedHat's business strategy -- to put together a solid, enterprise-class distribution, and market it and sell it as such. If they are going to charge more than the media cost for it, as well as have support contracts and such, they should absolutely provide industry standard warranties for the software included. If they feel that's unfair, then the message they are conveying about Free software becomes highly Microsoftian. (in other words; if you refuse to apply industry-standard warranties on your so-called enterprise software just because it is OSS, what is that saying about OSS?)
Note that for those of us who download images or buy linux distros for media cost, these warranties (of course) do not apply, as the UCITA chairman states.
All in all, I believe the guidelines UCITA is presenting are just fine. If RedHat wants to play with the big fish, it must be held accountable by the same standards, regardless of how its software was developed.
I've been using RedHat Linux consistently since the 4.x days, and personally think it is a great distro. However, if I was choosing the platform for an important new server for my business, I would go the Sun route if RedHat refused to subscribe to standard software warranties, regardless of any initial price differences (which, as we all know, are insignificant in the long run, especially relative to admin costs).
Just my chunk of change, please go ahead and correct me wherever I'm wrong, this issue is totally new to me.
Re:I agree with UCITA (Score:3, Interesting)
This is exactly why software warranties and software liability exclusions for OSS are problems. I even wrote a journel entry on this topic. [slashdot.org] Giving an exclusion to Red Hat or Mandrake or whoever for software warranties or software liability does not actually help Red Hat or Mandrake or whoever.
My conclusion? Don't require software warranties or liability at all. The problem with bad software is not that it's not warranted. It's that there's no reason for the monopolist to produce better software. I think that competition will be dramatically more effective at producing good software than legislated warranties. Creating a law simply means that the vendor has to spend a little bit of effort to find the loophole in the law that will let them to continue to produce crappy software with little recourse for the consumer. Create competition, on the other hand, and the vendor now has motivation to actually produce good software or the consumer is going to go somewhere else.
A law is NOT the way to handle this. Let's not create a law (with loopholes) until after a competitive market (*) has proven insufficient.
(*) The existance of an illegal monopoly means that we do not currently have a competitive market.
$.02
Re:I agree with UCITA (Score:2)
If I want to make a piece of horribly bug-ridden software and sell it, I should be allowed to-- and absolutely no one should buy it.
Re:I agree with UCITA (Score:2)
No. They'll also be spending time trying to figure out how they can get around the law without actually having to redesign their software. And as soon as they figure it out, they'll modify their EULA, which is much more maleable than their software.
Nice strawman. I don't care about what happens to RedHat. I care about what happens to ME. I have a couple of small programs that I released under GPL with no warranty. If the onus of warranting software and providing product liability suddenly falls to me, I will not be able to release my software. I can't afford the amount of protection needed to be able to warrant it or defend against liability. I suspect that an enormous amount of opensource/free software authors would be in the same boat. Which means that all of opensource/free software is threatened by a legal requirement for software warranties and liability.
Legislated liability and warranties are a bad idea. Restoring a competitive market place is a better idea. You may even end up with software warranties as a result (see this post [slashdot.org]).
Re:I agree with UCITA (Score:2)
I fully agree. If RH thinks it cannot provide warranty for the all packages then it should only include those packages that it feels comfortable to provide warranty for. I'd accept that RH distributed some software without warranty on the same media but that should be added extra only. IMO UCITA should explicitly disallow advertising of included software if that software isn't covered by the warranty--or at least require that such software would be highly visibly marked as no-warranty-stuff. Otherwise they could give warranty for something like "cat" or "echo" and advertise other software on the media (like gcc, mozilla and openoffice) and provide no warranty of any kind for those.
Minimum warranty for any software should be money back. This way any free (as in beer) software could be distributed practically without warranty. One thing to consider is that if the full distribution costs $50 and a single package inside it is broken (say evolution) should the customer get back $50 or something less because only one feature is broken and the rest is fully functional?
One interesting guestion is how long should the warranty be at the bare minimum? Until the shrink wrap is broken? Up to 100 hours of usage? 90 days?
Re:I agree with UCITA (Score:2)
The problem is the idea that there should necessarily be industry-standard warranties for all commercial products. Standard warranties are good for when the user can't do anything about the quality of the product. With Open Source/Free Software, the user can change the product himself, or hire a third-party to do it. With proprietary, closed-source products, this is not an option; the user is beholder is beholden to the vendor.
The answer is obvious when you just keep in mind what industry-standard warranties are actually good for.
Warranties are bad for EVERYONE. (Score:3, Interesting)
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.
Re:Warranties are bad for EVERYONE. (Score:2)
Re:Warranties are bad for EVERYONE. (Score:2)
No?
Next please.
Re:Warranties are bad for EVERYONE. (Score:2)
What's silly is that this is so easy to solve... (Score:2)
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?
Source Reasoning (Score:2)
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
Re:Source Reasoning (Score:2)
Exactly right. The pe(rson|eople) who can fix the source should be responsible for fixing it for paying customers.
With proprietary software, that's the company's responsibility. If the source is available, but only the company is allowed to change it, then it's still the company's responsibility. If the source is freely modifiable, then it's anyone's/everyone's responsibility, no matter who was paid for the software.
In other words, if someone controls modification of the software through IP laws (copyright, patent, trademark, trade secret, whatever), then that entity has the responsibility to fix it. If they give up this control over the software, then they also give up the responsibility to warranty it, because anyone can then fix it legally.
The fox guarding the henhouse. (Score:2, Insightful)
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.
Buying Over Internet (Score:2)
Maybe this is the separator.. (Score:2)
Sell a license, sell a licensed product... (Score:2)
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.
Here's a thought... (Score:2)
Re:Here's a thought... (Score:2)
If the warranty only applies to the latest version, then you'll see big software companies bringing out new versions every few months, so that the warranties will be voided by the new version before many of the significant bugs/security holes are found. Is this really what you want?
Re:Here's a thought... (Score:2)
Re:Here's a thought... (Score:2)
I was assuming that the upgrades were free, like your original post. Yeah, even then the TCO would be horrible due to the work of testing, installing, and integrating the new versions so often.
But my concern was the security more than the TCO - a lot of security holes are not found immediately upon release, and if the warranty on the previous version is voided when a new version is available, then there would be much less incentive for the manufacturer to fix security holes in previous versions.
The reason I'm thinking about this model is that it fits very well with the "subscription with automatic upgrades" model that seems to be on its way.
Finding a new vendor is an option only if there is an alternative vendor whose product is similar enough that it doesn't add huge re-training and support costs to the TCO. Works for some products...doesn't for others...
Warranty only for sold open-source products? (Score:2)
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
the Source for warentee disclaimers (Score:2)
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.
Cost of doing business... (Score:2)
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
A rant about inconsistency (Score:2)
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 [go.com]... What a price, indeed.
Software Product Descriptions (Score:2)
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.
Re:Software Product Descriptions (Score:2)
If VA Linux had done that, maybe they wouldn't be trading for 63 cents, down from $200.
What about alpha/beta releases? (Score:2)
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.
Oklahoma Warranty and source code vs. binary (Score:2)
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
What industry-standard warranties are good for (Score:2)
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.
Re:Provide Warranties (Score:2, Funny)
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!!
Re:Why can't they provide a warrenty? (Score:2, Interesting)
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.
Re:Good! (Score:2)
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.
Re:Good! (Score:2, Interesting)
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.
Re:Good! (Score:2)
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?
Re:Good! (Score:2)
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.
Re:Good! (Score:2)
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?
Re:Good! (Score:2)
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.
Re:Good! (Score:2)
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).
Re:Good! (Score:2)
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.
Re:Good! (Score:2)
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.
Re:Good! (Score:2)
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.
Re:Uniform state laws?!?!?!? (Score:2)
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.
Who marked this as "Flamebait" ??? (Score:2)
Just because you don't argee with him, doesn't mean you should mod him down.
Re:the shoe on the other foot (Score:3, Insightful)
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.
Whoa, You missed the boat (Score:3, Insightful)
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.
Re:the shoe on the other foot (Score:2, Interesting)
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...
Re:the shoe on the other foot (Score:2)
Re:the shoe on the other foot (Score:2)
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.
What are you breaking your software on purpose? (Score:2)
Re:Exemptions should be called for... (Score:2)
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.
Good points-- but there are additional questions (Score:2)
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.