Slashdot Mirror
Software Product Liability?
ben writes "Reuters just ran a story about the increasing number of calls for liability on the part of software developers, with a not-too-suprising focus on Microsoft and its uber-fallible IIS webserver. Given that many other engineering disciplines have some sort of accreditation and licensing body to enforce codes of professional ethics, I'm curious what impact the demand for such a creature in the software industry could have on Open Source developers, especially the part-time hobbyist ones. That is, establishment of some sort of Software Developer's license means the developer is potentially liable for whatever havoc his bugs may wreak, and traditionally the only environment with legal resources adequate to deal with such liability has been the megalithic corporate one."
This is a serious question that always seems to be glazed over by the open source advocates. Most seem to see it only as a method of attacking MS.
Well, if liabilities become a reality, EULA's won't protect the company, otherwise every company just puts a clause in it and the liabilities cease to exist. The law would be required to allow very few, if any, exceptions.
If the open source community has to face this, what will happen? The next time there's an error (such as the recent Bind exploit) do the lawsuits begin?
Couple of quotes in the article I like:
The products are even less buggy than others, in terms of per capita usage, Microsoft Chief Executive Steve Ballmer has said.
So does that mean that because more people use Microsoft software they can have more bugs in it? This sort of statistic is like using "Revenue over number of employees named Frank" as an accounting measure for companies!
And the other one:
Mundie said. "Microsoft can't control that process. If the printer driver tanks the system, who do you hold liable?"
Now *that* explains what caused all those holes in my locked down IIS server!
Go out and get sailing!
Being liable is clearly a problem if you release your software for free (i use both meanings here). I think software companies should be liable if their software is not free. When you agree to give up money or "freedom" for software, It is my opinion that you should get a quality of service granted in exchange.
This should usually be handled by the invisible hand of competition, but huge software companies are so well-established that they can afford to give up on quality. I think that such a measure would protect the consumer from such abuses.
This is just an idea, it's certainly flawed and incomplete. Does anyone care to contribute?
Trollem mirabilem hanc subnotationis exigiutas non caperet
The NIST commissioned a study (sorry, 1.4Mb
If you don't want to download the report, there's a brief summary in RISKS Digest 22.11, on comp.risks. If you do download the report, the final numbers are on p.174
Sheesh, evil *and* a jerk. -- Jade
- Non-Comercial For which money is not charged
- Commercial for which money is charged
- Licensed Commercial For which Money is charged, but for which no sale is made.
Commercial software would include the obligation of support, although the require period of time is open to debate. I would advocate 5 years, although this could be set to several classes, such as 1 year, 3 year, 5 year, and 7 year. Each with a degree of obligation of support, liability, etc.Non Commercial would not be subject to the warranty, and so would cover open source, donation ware, shareware, etc.
Shareware, etc. would probably have to be sorted out as software where no payment is required.
I advocate that any software not sold but merely licensed must have complete liability coverage and support for the duration of the License.
"It is a greater offense to steal men's labor, than their clothes"
I think the premise of code = free speech was defeated in the DMCA case in NY. Remember, code in executable form was considered a breach. Any other form was okay...
What is sold as a product is not speech. If the courts have not been uniformly easy on code which expresses scientific ideas, written in an academic context, then certainly commercial software will not (and I think should not) enjoy protection as speech.
What would have to happen to change the current setting where commercial practice (and law) considers all software to be 'without warranty' is another matter.
The obvious reason that SW is presently very much a 'caveat emptor' instance is that most nontrivial software products are both comple and can be run in such a wide array of hardware and software environments that solid analysis of potential failures is clearly infeasible.
Linux is Linux, if One need clarify their dist: <Dist>/GNU Linux
bsds are of course just BSD
lets consider two facts..
1) RedHat/Mandrake/Suse/Caledra has been the big push of open source for the business world... without them Linux would be dead in the business world...
2) companies in (1) released products for sale (you buy them) and they sometimes have security bugs (a lot of them has a recent exploit in SSH recently)..
3) companies who uses products by companies in (1) who get 'rooted will sue the companies in (1)
4) companies in (1) will die (they have lot less $$$ then MSFT)..
5) bad for Linux...
-- Note: These Comments are Generated by ME! Not You! ME!
If, however, I am the head engineer for a project, and it fails, my head should roll. This goes for things I would manufacture and sell.
If I putz around with some code, and share it, no big deal. As soon as I am in the software BUSINESS, and sell that code, however, I have a responsibility to the folks who use that code.
Most folks who write stuff in their spare time, write it first and foremost for their own use. Since they made the effort, many folks decide to share it with the world. Of course it won't be polished, but at least they try not to hurt themselves with it, so it follows they wouldn't be hurting others with it either.
Software vendors make software for a profit. And do a shitty job of it. They SHOULD be held accountable for their inferior shit that hurts individuals and businesses with lost productivity and data.
... is really pointless. The argument is: an architect designs a house that doesn't blow over, or a bridge that handles the traffic load without collapsing. However, in these cases, anyone who does something out of the ordinary with the house (fills it with water, tries to open the inside door without opening the screen door), would be laughed at if they called it a design flaw.
Take the usual punching bag for example: IIS. IIS, when used properly, works quite well. You might argue about the functionality/performance/cost compared to [insert favorite httpd], but pass over those arguments for now.
Security is a common complaint for IIS. However, if a person broke into your house by going in through a weak point (a window, the chimney, etc), you wouldn't blame the architect.
Zealots might say that backdoors in software are like using doors without locks. But this is ignoring the fact that software is often not an integration of existing, proven solutions, but an exploration of ways to attack a problem. Also, these failings are plain to the layman, whereas software bugs are often obscure to the guru. You simply cannot have the expectation that software will *NEVER* crash.
An architect has a given set of solutions for common problems (building codes, pre-existing designs, etc). If they can't solve a problem with an existing, proven solution (or a mild derivation of such), they probably wouldn't take on the job. Programmers do not have this luxury. We are inventing these solutions on the fly -- and we will make mistakes.
You can't always limit liability. For example, you can't sell a car and say that you are not liable for design defects. You are, no matter how many EULAs you write. The same could apply to software.
Hi, long time listener, first time caller and all that.
I think the question (ultimately) may come down to where the finger gets pointed. I saw a post reference to certifications for programmers, which KIND of goes to my point. Then, I read the post on gun companies getting sued for the actions of their customers. Getting closer. THEN, I read the post by "The Eric Conspiracy" about Doctors, Engineers, Lawyers, etc, and what they are liable for. This is what I was thinking.
In a corporate networked environment (I am narrowing it down here, I know, but bear with me), who IMPLEMENTS buggy software? How about the Sysadmin? Maybe not his or her IDEA, but they actually implement it. It ain't Joe Blow at his workstation who uses it. You are the one that put it out there for him.
"Hey, our software was tested at M$ (or wherever) and found to run ok. What's YOUR problem?" If it hoses your network, or you get rooted, or whatever, it happened on YOUR system! Your firewall, your OS mix, your internal and external apps.
I know this sounds far fetched, but look at Enron. They played fast and free with almost everything they did, and Arthur Anderson went along with it. Now, since AA got convicted, the Enron stockholders are going after THEM instead of Enron. Responsibility was neatly deflected from one to the other because it was EASY to.
If you implement software onto your network, my guess is that EVERYONE that had ANYTHING to do with making it will be pointing to you as the (ahem) "root" of the problem. After all, it happened on your watch. And, odds are, YOU have some certifications! Tsk, tsk, you should have KNOWN better!
Paranoid? Probably. Hopefully, anyway. But look at everything that has happened from day one on this planet. When something either goes wrong finally, or has gone wrong for long enough that people complain, the finger of blame always swings over to the easiest target.
"the only environment with legal resources adequate to deal with such liability has been the megalithic corporate one."
For "deal with" substitute "avoid"
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
I think mandatory licensing for developers is stupid. Last thing anyone needs is a new bureaucratic office dedicated to extracting fees from developers.
But warranties are a different matter. If you market your software as a commercial product, then it should have the same warranties as any other commercial product. This is common courtesy. It's also known as being ethical and moral.
If you claim that your software is suitable to be marketed by actually marketing it, then you need to back that up by NOT disclaiming merchantibility. If I buy a toaster and it doesn't work as a toaster, it has a warranty that says I can get it repaired or return it for a refund. Commercial software should be the same. If I spend $199 on a word processor and it fails to process words I want recourse. If a patch is available then I want to be able to get that patch without having to pay for it. If no patch is available, then I want my money back. Is this so hard to understand?
But before you all get your panties in a twist and start crying out that warranties will kill off Open Source, remember that this only applies to commercially sold software. No one expects merchantibility for freely downloaded software. Second, the warranty should reside with the seller, not the developer. So Redhat can sell your software and you are off the hook, because it is Redhat that is claiming the software is merchantable and not you.
(liability is a different matter. I believe that every competent business should have liability insurance. But I don't see any problem with disclaiming liability so long as the recipient knows of the disclaimer before using the software)
My current software has a warranty disclaimer. That's okay because I am not selling my software. If you wish to purchase my software, you will get a warranty with it. This warranty will cover replacement or repair of the software for one year.
A Government Is a Body of People, Usually Notably Ungoverned
This will probably be viewed as a troll but I feel I have to say it:
The problem with software is that when a virus/cracker compromises your system, any resulting damage can not logically be attributed to the software developer.
Nobody is out there expressly trying to break and/or compromise Firestone tires. They were sued because the tires malfunctioned of their own accord.
If IIS blew up on it's own and erased your disk you would have a legitimate case. As soon as a third party maliciously tries to compromise it, the case is off.
If someone broke into your house would you sue the lock maker? Likewise, if someone deflates your tires you have no case against Firestone.
If you can show me one case where code in IIS itself was responsible for damage (i.e. damage occurred while the code was running normally without any provocation) then I'm all for this, otherwise (as much as I hate to stick up for MS) you can't possibly blame them for Code Red etc.
The real solution is just to get a better product; if you are having a problem with break-ins buy a better lock, don't just try to shift blame for your bad purchase decisions on someone else.
I'm a firm believer that, in general, ALL SOFTWARE (including Linux, BSD, and Windows) is full of show-stopper bugs, with a probability in proportion to the number of lines of code raised to some power. If one piece of software seems more secure, it's just because the bugs haven't been found yet. And this will get worse as time goes by.
(How the bugs are handled after they are found is another story, perhaps we should be focusing on that instead.)
Microsoft has lots of smart people working for them. Free Software has many smart people looking at the code. Yet, most of this code has bugs. When I write a 10-line Perl script, it has bugs (for instance, what does it do in a full disk situation? What does it do when run by root? What does it do if a Perl library is missing or upgraded?).
Making software writers/distributers liable for bugs is simply impractical. Software is simply not like a bridge or a toaster. Software is incredibly complex, and it runs on machines that are also highly complex, connected to other machines with equal complexity. All the interactions can't possibly be comprehended.
And just what is a bug? If the program malfunctions under certain unforseen circumstances, but when it was written it met all the specs, is that a bug? If you use a formal system to "prove" correctness, are the rules correct? Did anybody make a typo setting it up? Is the program that does the check itself bug-free?
I can understand that if Microsoft promises you a secure webserver, and it's found not secure, you feel Microsoft is to blame. But perhaps a "secure webserver" cannot exist. Even if it did, once installed, it would interact with other software to create a security hole (example: Apache + PHP + anonymous uploads into the web-accessible area + MySQL running as root).
If a law for software liability were passed, it would instantly kill all but a few software companies. Free Software would wither or go underground because no programmer would want to touch it. You would get zero support for your software, unless your setup was 100% EXACTLY the same as the one the corps will support. This would probably be enforced with some draconian DRM. Our lives would get worse.
Of course you say, they could make an exception for Free Software. But what would the criteria be? Exception for no-cost? No, that would mean you can't charge for Free Software beyond the cost of media. No more PayPal buttons on your web site, no corporate sponsorship. And Microsoft would just turn IIS into a free download. Exception for source-code-included? That would be better for little guy (no more binary-only distro though), but Microsoft could just invent a very-high-level language where MS Word is 5 lines, and distribute that along with it. They would find some other way to get around it. Any liability exception would be unfair to someone.
If anybody should be liable, it's the person or company who chose and installed a particular system. This entity put together the components, so this entity is responsible for knowing they all work together without bugs. But like I mentioned before, I don't think this is possible. And even just one small change or upgrade and you don't know any more if your system is still secure.
In 40-50 or more years, the software industry might stabilize to the point where all basic computer tasks are performed using well-known, publically available, stable components and formal systems, and then you could use the term "engineering" and you could conceivably have more predictable software. But I don't really think we're anywhere near that point now. Computer science is still in its infancy.
I'm not optimistic!
Say instead of being a software engineer, I was an enginner who built bridges. Can you image a boss coming up to me and saying:
"I need a bridge built in this location to move some things across the river. We will lose out to our cometitors if this takes any longer than three months, you have two and a half. Tell me tomorrow how much steel you need ordered and I will have the iron workers (actually guys off the street who could spell iron) to start putting it together."
Would you go across a bridge built like that? I wouldn't if I had a choice in the matter. How different is this from many software projects? Not very. Management doesn't care about the software quality since they don't understand it anyway, the coders are passivly taught not to care either because it costs more to write well architected, well tested code. Code can be solid if effort is placed on writing solid code. There will still be bugs, but nothing like is prevelent today in commercial software. Think of all the VB monkeys that managers consider real programmers. (Not that there are good VB programmers, but by and large...)
Welcome to the world of software. As long as the current market drivers are in place, nothing will change.
-Pete
Soccer Goal Plans
Maybe not. But if I were building a bank and the architect forgot something like a lock on the vault, I would feel justifiably aggrieved.
What's needed here is some concept of due diligence or reasonable expectations. As you say, it is impractical to expect software to be perfectly secure or robust. It is simply not viable with the nature of the beast, and with the methods known today, to provide such a product.
However, there are some tests that should be routine in any shop. If a software company allows its coders to write in a style that lets in buffer overflows, a common and well-known class of bug that is easily preventable with just about any development tools available today, then that should be treated as negligence. This is very different from expecting someone to write encryption algorithms today that can't be broken in 50 years with all the unpredictable advances in computing power and mathematics that may bring.
This is really no different to any other engineering discipline. I wouldn't expect someone architecting a bank to make the safe unbreakable in the face of the military weapons of 2050. I would expect them to put a lock on the front door and install an alarm system that did something useful in the event of a break-in.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
No, no, no, no, no! We *can* control it. We *can* build fault tolerant systems. We *can* take our time to ensure that our application will only respond to valid input/requests/etc. If you build the OS, make sure that nothing using your OS has a chance of crashing it. If you build a webserver, make sure that feeding it crap in the URL will not cause it to respond "The root password is 'imadip'".
What happened to the idea of a program having a well defined set of inputs and only causing it to respond to those inputs? And if something goes wrong, where are people getting off trying to blame it on the user be it a person or another program using that well defined interface? Argh.
Word did not crash Windows. The printer driver didn't crash Windows. The stupid user who pressed the wrong things in the wrong order didn't crash Windows. Windows just crapped itself.
OK, So I'm an Architect, and just finished working on a bank to boot.
You are right that there is a reasonable level of liability and quality expected within my design for the bank.
If the bank was to get robbed via force, I wouldn't be liable, for it was never represented by me, or required by my client, for the bank to be 100% robber-proof.
My design was required by my client to meet their needs for security and safety, so it's more important that the vault is secure and that someone can't easily hold hostages within the bank than it is to make it so that someone can't walk in with a shotgun and run out with a few thousand dollars. It's impractical to make the bank 100% robber-proof.
Now if a flaw in my design allowed someone from the Togo's next door to open a hole in the wall, and gain immediate and complete access to the vault- well then I would be liable, and rightly so. If I designed a bank with hidden corners and nooks where one could hold up and defend the bank in a hostage situation, and someone was gravely injured because of it, then I would be held liable. My design failed. I was negligent.
See there is a scale to this, a level of reasonable liability and requirements.
As an Architect, I am liable for everything I do, just like a lawyer or doctor or engineer. And just like a doctor or lawyer, I must complete tests and a certain amount of training to gain licensing to call myself an Architect and sign drawings as such.
Now any kid could design a house. That doesn't mean the roof won't leak and that it will survive an earthquake. That's the point of licensing in Architecture; I gain the legal right to sign drawings (a requirement for anything bigger than a house) and the legal right to call myself an Architect (that's right, all you 'software architects' our there are technically breaking the law- it would be like calling yourself a 'software doctor'- no one takes this seriously, but still that's the law) at the cost of accepting the liability for the work I do and the advice I give.
Now the software most Architects use is horrible. It doesn't perform as advertised, costs a fortune, and the licensing is draconian. It's frightening and sad. Now if it crashed now and then ok that's reasonable because there is no such thing as %100 stable software, just like there is no such thing as a %100 robber-proof banks.
However when there are GLARING deficiencies in a design, I believe that the people should be held liable for their work. In every other industry and business this is the case.
I don't think requiring licensing or liability for software development would have the 'sky-is-falling' response most of you geeks are saying it would. I think it would provide a much better, and respectable, industry in general.
To compare this to Open Source software; just because I design a house and freely publish the plans doesn't mean I am liable for every house that SOMEONE ELSE builds from my plans. If you bought my plans, and built the house I designed; well it's on your head to make certain the roof don't leak. But if you hire me to sign those drawings, or design the house or oversee it's construction then it's my legal and moral duty as an architect to make certain that the roof don't leak. See the difference?
(I am over-simplifying this; I know. But I'm proving a point here)
So if I download Debian, and compile it myself, the Debian project is not responsible for how I did it, nor has any control over how I did it, so therefore they shouldn't really be held responsible for my actions.
But if I hired someone to do it for me, or bought an off-the-shelf copy from Microsoft, and it has GLARING design deficiencies that cause it to fail in it's advertised abilities, well, I should be able to at the very least get my money back.
Software Developers should be ashamed that they don't hold themselves accountable for their own products.
> If government offices informed Microsoft that in one year they would no longer buy software that limited the liability of the designer
Actually, if any goverment wants to buy Microsoft software with liablity, it can be easily arranged: Microsoft will find third party insurance company, add appropriate price tag to the box, and sell it to anybody.
Will one want to buy MS Word for $10,000? I can easily imagine this price if the seller has to pay mega-dollar liability in case Word crashes while editing super important goverment document.
Ever seen a rich WYSIWYG-editor that never crashes?
Want software prices to sky-rocket like medical expenses in US (one of the biggest contributors is doctor's own insurance)?
MSDOS: 20+ years without remote hole in the default install
Let me make a suggestion: If you produce a closed source product where you release only the executables then you should be held liable for any damage the product causes. If, on the other hand, you release the complete source code for your product then caveat emptor. In the later case the user/purchaser has all the information necessary to (a) evaluate the safety and security of the product and (b) make any modifications necessary to bring the product up to their standards. If they don't have the wit or the will to do so then they're on their own.