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'd like to see any business in the world able to operate like this. You'd shoot simple projects right thru the roof in terms of cost.
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.
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
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
I disagree completely (about liability, not calling yourself an engineer after learning VB at DeVry). Most software is non-critical, and the software that is critical (flight control systems) are developed with security and reliability in mind; except for the few well know software disasters as you've mentioned. This kind of critical software is also very, very expensive, and is limited to the features that the engineers can guarantee to work.
It's all very simple, customers do not want secure or reliable software. The refuse to pay more for it, they refuse to wait for it to be built, they refuse to give up features for it. We can all debate this and that in regards to bugs and security, but until someone is willing to pay for it, it really is just idle chatter.
The lawyers will have a field day on this as they love to lie and makeup about losses ( eg. emotional damages and psychological harm, etc).
Lawsuits are lottery tickets that are ruining society and nothing more.
If a customer needs something that absolutely positively can not crash they could purchase a package(twice as much as a comparable one) and specify it in a contract to not crash. Infact such software companies exist and use strict methodolies and languages like lisp with real computer science graduates. Mostly they design medical, aerospace, and factory control apps. But hey you get what you pay for.
The problem is no one wants to pay $700 for an OS and $500 for a word processor. ITs just cost inhibitive so instead they just want to have the ability to sue thinking they can have this great stability at the same price. Its not going to happen
http://saveie6.com/
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/
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.
Here's a better idea, then:
Under such a scheme, open source/free/libre software would have zero liability (as it should be) because the customer would have access to the source code, and therefore would be able to (assuming sufficient skill) fix it themselves (or get someone to fix it for them). Closed source software would be liable unless there was a satisfactory workaround or the company could prove that they made a fix available within a timely manner of the bug being reported.
The logic is this: most bugs do not take years or even days to track down. Most bugs can be fixed in minutes. Most companies want to do a full bake cycle on fixes to make sure they don't break anything else. This sort of law would simply require that they make the interim build available to the person running into the bug so that they can get past it. It would also require that bugs continue to be repaired after a product is replaced with a newer version.
This protects against liability for unknown bugs, but sets limits on how long a company can drag their heels at fixing frequently-seen bugs, provides the customer a way out for obscure bugs that only three people in the world care about, and prevents abuses like companies abandoning products with major known bugs or requiring customers to pay for the next version to get critical bug fixes.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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.
"... where is the "very little bugs to begin with at a reasonable price" stuff? ..."
Linux.
Cars change ever so slightly, because bugs in cars kill people. If software were like cars, there would be a new version of an application every 10 years, and it would have 3 minor improvements and some cosmetic changes. A word processor would come out next year with bold text, 4 years later, italics.
Also, most software runs on general purpose computers, which the software vendor has no control over. This makes it much harder. OS X has an easier time, because Apple controls the hardware, but you pay extra for that (most people would rather buy a $399 Dell). Plenty of software is virtually bug free, such as the software that runs your DVD player, but the hardware is completely controlled, the software is very simple in features, and they add new features, very, very slowly.
I'm working on a large application right now for a client, it serves 1600 people and is important to the company. We have many known bugs but the most of them don't stop a user from using the system, but some will cause the application to crash. I always let the client know about all the known bugs and the level of reliability of the product. It is them that decides when the application is rolled out, not me. I guarantee that it will be rolled out with all these bugs and more, and in a months time the users will be complaining about them. But we wont' fix them then, we will be working on new features that will add more bugs. And when we say that the product isn't ready, they will say roll it out anyways. I don't blame them, because their users may complain about bugs, but the simply won't wait or pay for the bugs to be fixed.
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.
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.
Making a false claim is already actionable - it's called fraud. No additional regulations are required.
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
.....And I think for most consumers it would work like this:you charge us serious cash, we want a warranty.....
How much money would a 99% crash or error proof OS, such as Windows or OSX cost? How long would a MS or Apple have to test and how much would it cost? With material products, there are mathematical methods by which it is possible to predict performance and reliability. Only a limited amount of testing is needed of prototypes and production goods. This is NOT the case with software which is NOT a material good. There are no mathematical methods that can ensure a bug free program, such as there are for designing a bridge that will not collapse under most foreseen or unforeseen circumstances. The only real way to determine whether software is reasonably good and reliable is through extensive testing, which is labor intensive and therefore very expensive. To mandate a software maker to guarantee something that by its very nature CANNOT be guaranteed by design, but only by tedious and expensive testing is a dumb idea, to put it mildly.
All theory is gray
The logic is this: most bugs do not take years or even days to track down. Most bugs can be fixed in minutes
And all those bugs have already been fixed. Those which are left are those which are hard to track down, require substantial code rewrites to be fixed, or are seen as harmless by the software creator.
Go to any larger project and search their bug database and you will find hundreds if not thousands of open bugs.