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?"
If I paid $$$$$ and it's broken, I get really upset. If I paid $0, and it's broken, I accept that it's my responsibleity to bring it from being wirth $0 to worth something.
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
Very often, if not usually, there is no vendor with free sofware, so vendor liability wouldn't affect it at all (it might make commercial software more attractive, since there would be someone to sue for bugs, OTOH, it would make it less attractive to make commercial software.) With free software, very often the user acquires it from someone other than the creator, and gives no consideration of any kind to either the distributor or the creator to acquire or use the software. Often, a contract is created, if at all, only when the person who acquired the software decides to distribute the software, and even then, the consideration (in terms of limitations accepted by the new distributor) is in exchange for the right to distribute, not the right to possess or use, the software.
I don't think there's been a single issue which has come up with the gov't where they've agreed to some type of compromise, only to return to their prior behavior within a fairly short period of time (and the gov't hasn't yanked their leash to bring them back to the table).
I'm not anti-Microsoft. They've been a good source of income for a long period of time.
But facts are facts.
Until then, this is factors beyond a pipe dream.
But does the coverage make any distinction between a game-ending bug and a conceptual bug? By this I mean bugs that cause the program to perform differently than the program was being marked as and bugs that are only causes by deliberate/incredibly unique settings/actions? The first should be held as legit bugs while the latter seems hard to argue for. If the bug only expresses itself when you setup a special case that is never seen in the real world, is it really a bug? After all, ALL computer programs have bugs, even the simplest of programs. Even Hello, World! (which almost always depends on system libraries to display, and as such inherit any bugs that they contain).
The simple answer to this is to allow for software to be given away on a "no liability" way. FOSS could be allowed to exist since those that are creating the software are not making money to how many copies they "sell". Those that produce software for a living, like MS, would still be held accountable for their products. But then, IE would not be covered since it is "given away".
There probably is no simple answer to this. Either allow things like FOSS to exist and limit the liability that all software producers have, or open them up to real liability and kill FOSS.
Space for rent, inquire within
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"
But since legal liability tends to chase those with the deepest pockets, I can see where the commercial closed source software vendor would face the greatest exposure to expensive litigation from "bug liability". Distributed development processes that are not centrally owned by one company (i.e., open source) could very well be the only way to get anything new written without facing expensive litigation.
Not that I think any of this is a remote possibility, but it could very well cause the opposite of what TFA speculates.
Momentarily, the need for the construction of new light will no longer exist.
Just make the fine equal to some percentage of the retail price for the product multiplied by the total number of users...
Plus, most free software is in a perpetual beta version 0.99.9.999 and very rarely in a version 1.0+... You can hardly blame a developer if you have been using the not-ready-to-be-released version. Does that mean Microsoft would sell Windows Vista Beta v 0.99 too though...?
After 3 days without programming, life becomes meaningless
- The Tao of Programming
No way. There are far more of us who develop custom in-house software than people who write stuff that gets sold. You might severely hurt the software-as-a-product industry, but wouldn't touch the software-as-office-automation economy.
Dewey, what part of this looks like authorities should be involved?
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
What if you write an api or even a program and some commercial vendor uses your code. THe bug was found in your code and the vendor gets sued.
How do you know vendor X wont come after you to pay for their court costs?
Also businesses would purchase liability insurance. Mabye their agreement with the insurance company is to sue others and use that money to help pay the insurance company so they can maximumize profit by minimizing losses when they got to court.
Also many vendors would go out of business and if your in IT you would need to compete with many exemployees from these vendors. Last businesses might let you go as the price of software goes through the roof and the IT department needs to stay within budget by cutting costs by firing people.
ITs a no win situation for everyone but the lawyers of course.
bugfree software can exists but the software engineers(not programmers) who design such customized products charge twice as much for their labor. No one wants to pay $700 for an OS. Thats how much it would cost if you double the price of WindowsXP
http://saveie6.com/
where is it even in the market place for consumers to have a choice in the matter? You got some serious assumptions you are putting out there as fact, so let's see some proof to it. Where is normal joe surfer software (the OS, some normal userland apps, etc) for sale that comes with a warranty instead of an end user license that says "nothing is our fault" and "this software provided as is, might not be suitable for a dang thing, hope U R feelin lucky"??
bad car analogy time
This is like the car companies saying there was "no market" for electric cars, even though they never put any out there to begin with, and the leased all electrics went like hotcakes and the leasees BEGGED to be able to buy them, yet most got crushed in still fine working order.
You put a good OS and browser and a few more apps out there with a guarantee and warranty that YES indeedy you can use this on the internet and not get hosed and pwned and your printer will work and etc,and see what happens.
People are already dropping serious coin on fixes all the time, so why wouldn't they drop coin on stuff that doesn't need much fixin to begin with?
The rest of industry (I mean A to Z, the *rest of industry*) has come to grips with building to such a quality level that the rate of recall and fixes under warranty is under control, they can still "do business" and "make money" at it. None of their stuff is 100% perfect,none of it, but they got to the point it is plenty good enough, because they got REQUIRED to provide a certain minimal level warranty, even though when it was finally imposed on them they all cried crocodile tears and claimed it wouldn't work and put them all out of business, it just wasn't possible, OMGBBQ we'd have to charge so much money no one will buy our stuff! And other such whines like we hear now from the digital bits vendors. The other industries managed *just fine*.
Software is the last major industry allowed to push snakeoil under the "caveat emptor" rules, way past time that got changed.
And I think for most consumers it would work like this:you charge us serious cash, we want a warranty, you want to give it away as betaware for freebies or cost of media and duplication or download, we'll take it for free and maybe pay a very low reasonable amount of periodic bug fixes.
But charging serious folding cash then no warranty with your "full stable release" stuff is the problem, it is not the solution.
As it is now, we have no consumer choice, pay money for bugs, or download stuff for free with bugs, where is the "very little bugs to begin with at a reasonable price" stuff? I would bet that is what *most* people would eventually go to if it was there to choose from.
licenses. If your software is licensed including the requirement that you don't modify it and don't duplicate it, then a responsibility should be implied that they take care of said software.
If the responsibility of upkeep becomes too much, a vendor can always abandon the software.
Microsoft can't be expected to fix windows '95 bugs forever, but on the other hand, people have paid for a working product that they should expect to be able to use forever. Seems to make sense to me that when they abandon upkeep, they should lose the responsibility over that product as well as the ownership, it becomes public.
A law making it so could replace much of the copyright law system. We could use the same concept with products, music and books, once they are out of production, out of print or unatainable by commercial means, they lose their exclusive license to the product and anyone can distribute it.
I graduated from software engineering and find that the problem is simple. Nobody wants to pay for engineered software. Most people pirate windows as it is, and that's at the cost of a couple hundred dollars. Throw software engineering into the mix, to make it free of bugs, and it would probably cost $2000. There are places where software engineering is done, but that generally only occurs where peoples lives or billions of dollars are at stake. I wouldn't pay $2000 for a home OS, because it wouldn't be worth my money. Plus, how do you control the varaiables. Building a home OS, you want it to be able to run any program the user clicks, yet, this is counter productive, because you have no idea what that program is going to do, or how it is going to interact with your system. Having never run that program on you OS, how are you supposed to sign off, saying that the OS won't crash when running that program. You could be pretty sure, but you couldn't be 100% sure. This is even more true for drivers and such, where much closer contact with the hardware is needed. There are places where people would rather just pay for something cheap, and have it work 80% of the time, rather than pay 15 times as much to have it work 100% of the time.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
We have something like this with our mainframe that holds all our financial data. Thing is super reliable, I'm not aware of it ever crashing or losing data ever. However, cost aside, there's another major downside: We can't screw with it at all. Software isntallation isn't permitted, configuration changes aren't permitted. The support contract basically specifies that we will leave it the hell alone, and any changes have to go through IBM first.
Now it makes sense, you cannot predict the interactions between new programs. If we were just allowed to mess around with it, as we do with desktop computers, sooner or later we'd install soemthing that would conflict with something else and cause problems. The software can only be verified if it's a known system, so they just don't allow any new software to be added without prior approval and a lengthy and expensive verification procedure.
That's fine for the financials DB, but I'm not putting up with that for my desktop. I need to be able to install software on no prior notice from any source. Yes, this can lead to problems, but I'l take those problems to have the flexability I do.
So yes, you cna have a rock solid system if you are willing to pay a lot for it, deal with slow development, and accept a very restrictive environment. If those aren't ok, then you takes your chances. Open, comoddity systems CAN be very stable, I've seen servers go years with no OS or app crashes, but they cannot be gaurenteed to be so.
Most software is non-critical, and the software that is critical (flight control systems) are developed with security and reliability in mind
Just becasue the failure of some software doesn't maim or kill people, or is not the direct cause of millions of dollars in losses, doesn't mean that consumers shouldn't be warranted against defects. Commercial software is notoriously lax in comparison to most other consumer goods--for example, about all Microsoft warrants against is damaged physical media. The law is significantly more stringent for minimum warranties on physical goods, even "non-critical" items. Your car isn't just warranted against safety-related problems for example (to bring up that tired "if Windows was a car" analogy, if Windows were a car it would not be covered under warranty if an engine flaw caused it to stall every 10 minuts because there are no performace guaranteed). The least they can do is give you a refund for the cost of the software.
There has to be a reasonable balance, and right now the software industry is "unbalanced". End users certainly don't demand "ciritcal-systems" reliability from their home computer's productivity applications--they just want value for their dollar. If I go to Home Depot and buy an electric drill that falls apart due to poor design or manufacture I expect I should be able to take it back because it cannot properly drill holes or drive screws. On average commercial software is more expensive than a drill, however I have a much harder time returning it for refund because it crashes my computer when I try to use it for the purpose it was meant for (say, I cannot e-file my taxes with the tax program or something, when it says right on the box it can do the job). It's not like we want millions in liability coverage included.
Does this jeopardise Free software? I don't think it does at all. If you download free install packages, and especially if you download source for free then compile it yourself, I can't see how any warranty at all can be justified--you take your chances because you get more than what you paid for (which was just your time). However, I'd expect a modest level of warranty for functional deficiencies for SuSE or Red Hat for their commercially distrubuted versions of Linux and other apps, just the same as I do from Microsoft. Is a full refund of purchase price on brand new merchandise really too much to ask for?
In cases where a consultant or systems integrator has made use of open tools, it it they--NOT the original code contributors--who should hold responsible, since it was the consultant who had the job of selecting, modifying and deploying the system (they should review for fitness of purpose). Basically this is the case already--where I work we are responsible for making sure our systems perform as expected, even though our software runs on a Microsoft platform and it is sometimes Microsoft's defects that are the root cause. The reason we are liable is because we made the decision to use the Windows platform and we were responsible for testing and making sure defects in 3rd party software were not critical.
Another poster mentioned the case of collapsing suspended walkways at a luxury hotel in the early 80s. The engineering firm and supplier of the walkway supporting rods were held liable and paid dearly. In the equivalent software situation the liable parties might be the IBM consultant or the designer/developer of a purpose-built, custom software component. Suing Linus Torvalds because a defective system failed due to a Linux kernel bug would be like suing the company that mined and processed the steel to make the rods--because it is one component in a complex assembly of diverse components and should've been adequately tested.
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.
I see many here saying that only those that sell software should be liable, while those that give it away for free should not. If such a law were passed, you can bet that FOSS would be killed off in the corporate world, as corporations would gadly rather work with software vendors that can be held liable than those that cannot, as the former have something to lose for having bugs while the latter is free to produce bug-infested crapware. It makes no differnce if the "free" software is actually good; corps would feel safer using software produced by someone that could be held liable.
And as I said in another post, large commercial vendors would survive, as they'd simply buy software liability insurance (ala medical malpractice insurance). Smaller vendors would be hurt if they couldn't afford such insurance.
So FOSS is hurt (corps won't use it because FOSS "vendors" can't be held liable for bugs), small commercial vendors are hurt (since they can't afford software liability insurance), and large commercial vendors thrive since FOSS and small vendors are eliminated.
-- "I never gave these stories much credence." - HAL 9000
Would OSS be so popular if customers were able to hold (closed source) vendors accountable for their bugs?
This is nonsense. You are obviously not a developer.
This discussion misses one central point:
[1] It is possible to develop good software.
[2] Quality costs money.
[3] If software is priced (high) to reflect its cost and quality, it will be pirated, and the developers will not cover their expenses.
[4] There is a ceiling to the cost of software, and it is the equivalent of the nuisance value of duplicating the CD.
Not everyone can afford a Porsche, yet Porsche continues to stay in business. Those who can't afford a Porsche, don't whine that Porsches should be free.
You want the software equivalent of a Porsche? Show me how the developer can be fairly compensated and then maybe we can entertain this silly notion of liability.
Slashdot entertains. Windows pays the mortgage.
Should self-proclaimed security experts, like Bruce Schneider, be liable for bad security advice?
That is, if Mr. Schneider tells people that a certain thing is secure, and then it turns out to not be secure, should he be liable for it? For example, if he had told me to use MD5 ten years ago, could I sue him now that MD5 has been discovered to be "insecure"?
It would kill *ALL* general purpose comnputing.
The only safe language to code in would be assembly, and you'd have to write all the code yourself, unless you wanted to be liable for the output of the compiler or the libraries you linked to.
Shared libraries and loadable modules couldn't be trusted, since if your application had them, someone else could substitute a different library or module, and your code would never know the difference. If you added checking mechanisms to *for sure* know the difference yourself, you'd have to trust the FS.
All applications would have to be embedded applications, since you couldn't trust an OS vendor - what would happen if the system call behaviour was changed by the OS vendor? What if it wasn't by the OS vendor - what if the OS vendor trusted third party companies to write drivers?
What about firmware? The OS trust the firmware to load it! What if the firmware changes, or isn't exactly the firmware you expected?
What about the hardware? What if the instruction set on the CPU changes? You'd have to tie your software to particular hardware; historically, for example, 6502 processors were mask-programmed, and had "in between" op codes - they'd do something, but what the side effects were depended on the chip stepping. Your code could work in testing, but not in production unless you guaranteed the same chip lot, since it might be working as a result of a serendipitous error that was fixed in the next chip.
Down this road, you'd only ever have software sold by people who made the OS sold by the people who wrote the firmware sold by people who built the hardware... and maybe the components of the hardware themselves.
So basically you'd have... what... nothing left, but IBM from the 1950's?
-- Terry
....Holding software vendors accountable for bugs in the software they sell/support would do wonders for improving the quality of software in general......
It would also do wonders for the cost of software. So you would hold the developer of some stupid game, or even a word processor to your vaunted "professional" standards of expensive testing? Give me a break! Nobody has yet AFAIK come up with a foolproof mathematical way to certify that any program of even moderate complexity is bug free. The only way to be reasonably, but never absolutely sure there are no bugs is to test, test, test and then test some more. That gets very expensive. To make such an expensive testing a legal requirement for all software and to certify so called engineers, who may have more degrees than a thermometer as the only ones to be allowed to write "normal" software is ridiculous. When MS Word crashes or Windows BSOD, so what? Nobody gets hurt and if you save your work often, there is usually little economic loss.
All this would do is make more work for lawyers and make software as relatively expensive as small private airplanes, the exorbitant cost of which is largely due to liability issues. Keep regulators and lawyers out of this, but let buyers of life critical systems pay for the testing of such software.
Don't make it a requirement that any and every software meets any particular, government mandated standards. I have heard of a lot of extremely stupid, unworkable ideas in my lifetime, but this one is one of the worst to surface in a long time.
All theory is gray