Slashdot Mirror
Would Vendor Liability for Bugs Kill OSS?
Glyn Moody writes "Bruce Schneier has written an interesting column for Wired suggesting that vendors should be made liable for bugs in their software. But where would this leave open source developers? Would what seems like a great idea actually be the death of free software?"
It wouldn't kill OSS if the liability was limited to the purchase price. That's plenty of liability to keep commercial vendors interested in fixing flaws, and it doesn't hurt the little guy.
I wouldn't contribute to OSS if I'd be exposing myself to a lawsuit because some dipshit found a creative way to exploit my code. They're the guilty party, not me.
"Bruce Schneier has written an interesting column for Wired suggesting that vendors should be made liable for bugs in their software. But where would this leave Microsoft? Would what seems like a great idea actually be the death of proprietary software?"
This would not only kill OSS, but the whole software industry would go bankrupt in no time.
As usual, regulation increases the barrier to entry for a business. By making software vendors liable for bugs, they make it difficult for OSS and small shareware developers to compete. Keep in mind that the question is not whether the OSS developer will be found liable, but whether they will be sued in the first place. The legal fees alone are enough to hamper or even kill small scale software development.
The simple fact is that this is too hard to police anyway. Where did the bug occur? Was it in the program, or some library it called? Now we have to establish whether the programmer could reasonably have known there was a security update to the linked library. Just proving where the fault occurred would be a huge legal SNAFU. Sure, such a thing would kill OSS first but it would effectively destroy the computing world. Only a luddite could seriously believe that this is a good idea.
The only proper way to handle this is through contract - not an implied one, but an explicit document which clearly describes the areas and extent of liability. There is a market for this kind of software, and it exists already. This is the only reasonable solution - get a contract, and if you don't, caveat emptor.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Here's a tip, Mr. Schneier: analogies can be good for illustrating a point, but going on for 2 pages about your anaology without actually using it to make a point is just dumb.
My guess, since the story was posted at 2AM, is that he had a deadline to meet and wrote this piece of crap in 15 minutes while drunk.
Don't blame me; I'm never given mod points.
If you want things to really hurt, multiply the purchase price by 10 or so. That would actually constitute a penalty to distribute buggy software for commercial vendors while still not impacting those who give the software away for free.
Large software products will never be entirely bug-free. To keep things reasonable, there should be a standard time-to-fix so commercial vendors also have a fair chance of cleaning up after a mistake.
To Terminate, or not to Terminate, that's the question - SCSIROB
The prices are for the full product. Upgrade editions count as the full product for liability
something similar can be sorted out for large installations, bulk licenses, etc.
Just thinking out loud
"It is a greater offense to steal men's labor, than their clothes"
Just make the fine equal to some percentage of the retail price for the product multiplied by the total number of users...
The article is horribly misrepresented, here. The core of the article is about the security principle of aligning capability with interest -- that is, when you want something done, you find out who can do it and take steps to interest them (offer them money, the potential of something free, a fine if they *don't* do something, etc.).
Near the end, Bruce mentions the concept of "software liability" as an example of how interest can be aligned with capability. Bad on Bruce for not defining how he uses the term, but bad on the submitter for not researching it before sending in this FUD. Anyone who has followed what Bruce has done knows that he's a huge supporter of OSS.
When Bruce talks about software liability, he's talking about making software makers liable for their marketing claims about security, not for "bugs found in software". OSS would be safe, as long as those project don't say "we're secure" when they aren't.
And on this point, I agree: if I buy a security product that claims "secure file storage", and I find out that they implement this single-DES encryption -- and espeicially if my data is compromised as a result -- the vendor should be liable. They made a false claim!
We may not imagine how our lives could be more frustrating and complex—but Congress can. – Cullen Hightower
How did we get to this state of affairs?
Whether or not a software vendor should be held liable for bugs in their software depends on what they promised to the customer. They should be held liable for no more and no less than that. It's the same as with a vendor of any product, not just software products.
If you go to solutions provider X, and hand them a list of your requirements, and they agree to provide a solution that satisfies those requirements, and you both sign a contract that embodies that agreement, then of course they should be held liable if they fail to meet their burden under the terms of the contract.
If you buy a box of software from Vendor Y that says that its purpose is to enable you to write letters to your grandma, that is an implicit contract, since you are exchanging your money for the product's functionality. Depending on where you live, you might have legal recourse, if the product fails to live up to its stated purpose.
The obvious escape from this, which all software vendors take, is to not state that the software enables you to do anything specific, and to explicitly disclaim fitness of use, for any purpose, in the software EULA. They can then say that the name "Grandma Writer(tm)" was merely meant to convey that the product is so easy to use, that even your grandma could use it, and not that it is guaranteed to facilitate communications between you and your grandma.
So, for example, if you download gcc and your airplane crashes because gcc generated incorrect code for your embedded processor, then you're shit out of luck if you want to sue the core gcc dev team. The license agreement for gcc explicitly states that the software is not guaranteed for any purpose whatsoever, so use it at your own risk. By accepting the licence, you shoulder the responsibility for any damage that results from your use of the software.
In the case of the Vendor Y, the EULA is to cover the vendor's ass, so they can make some profit, instead of spending all their time and money in court. In the case of gcc, the license is to cover the developers' collective ass, so they can continue to develop gcc, instead of spending all their time and money in court.
Vendors: Do what you promised you were going to do. You have a contract with the user. Live up to it. But don't expect users to rush to buy your product if you don't actually promise that it will do anything.
Users: Vendors are responsible only for what they agree to be responsible for. If you need the software to do more than that, then renegotiate your contract, certify it yourself, or get a third party to certify it. The vendor is passing the buck, and it's up to you to either walk away, pass it on or accept the responsibility. You are the solutions provider here. You have to decide who's going to be first against the wall when the revolution comes.
A republic cannot succeed till it contains a certain body of men imbued with the principles of justice and honour.