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."
``What if they blame your software, when in reality it's the fault of some other software used in conjunction with it?''
In MicroSoft's case that's hard, though. If I exploit a buffer-overrun in IIS or the infamous chat control, the fault is certainly in the software that has the buffer-overrun vulnerability. If a ``printer driver tanks the system'' (from the Reuters article), then obviously the system isn't very stable. Part of an Operating System's task is to ensure that one program doesn't interfere with others, and if a printer driver can affect the whole system, apparently the OS is flawed (there are those who would disagree with this point, but I for one expect my operating system to be stable).
Please correct me if I got my facts wrong.
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
Most seem to see it only as a method of attacking MS.
I think that's a bit unfair, since people (in general) pay MS, but not the author of free software.
That does raise a tricky issue though; would a company that resells free software be liable for it?
- 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"
$60B/year sounds reasonable: 100 Million users, with an average wage of $10/hour = 60 hours/person/year wasted, Or about one and a half hours per week for your average person.
This is less bad than traffic jams, and somewhat worse than income tax forms.
But, so what? Would America benefit for bug-free software? Would spending $300 billion so that ATMs didn't crash, Microsoft Expedia always worked, Verizon's DSL billing was perfect, really be a good use of resources (even if we could do those things?)
We expect stuff to fail. Let the free market decide what level of error we will tolerate (e.g. I can deal 1 crash per year on my home machines, my parents don't mind 1 crash per day! - we have different needs and price points.)
I don't know who wrote this but it's a standard article of faith(sic) in the IT industry.
The only case I can think of in which a vendor provides a meaningful statement that a system operates with a particular fitness for purpose would be systems evaluated under Common Criteria orTSEC
And these systems differ from the vast majority of operating software systems in that:
So the current state of the art is "software is too complex to guarantee performance", this is codified in commercial code and practice. What this means for now is that entitities which use software cover themselves with insurance. (I have no idea what it costs to insure a commercial web-presence.)
I think changing things to hold producers of commercial software and systems would be a good step. I can't see however how this would happen without forcing considerable change in the practice of software design and development.
Either tehcnology and QA need to change, or software systems would need to become simple. Given the current set of assumptions it is effectively impossible to perform an analysis of any non-trivial code and determine that it is safe in the expected execution environment(s).
Simplicity sounds great on paper. At present there isn't a market for simple software that works with high assurance. (Look at the tiny marketshare for the BSD's). Even the systems that run over unix-like / oss show a degree of bloat that continues to push reliability out the window.
Prudence and solid engineering practice in operations dictate that we use the simpler / more robust tools in key locations. So BSD or secured versions of linux get deployed as firewalls etc, and critical application and database servers are run with various redundancies (clustering / failover etc), which effectively throws hardware at solving the software 'problem'
Which is just another name for insurance.
Linux is Linux, if One need clarify their dist: <Dist>/GNU Linux
bsds are of course just BSD
I wouldn't count the EULAs out just yet. The latest victory for them is the Blacksnow v Mythic Entertainment lawsuit that was mentioned here previously. (For those who can't remember and don't want to reread stuff, Blacksnow had people using macros and other aids to build characters fast within Mythic's Dark Age of Camelot MMORPG, and selling the characters and items for real world cash).
Mythic got a judge to rule that the arbitration clause in the EULA is legal and enforcable, and they (of course) expect that arbitration to conclude that the prohibition against item-selling is legal as well.
Yet another precedent of EULA enforcability and legality. Just one more reason to READ THE DAMN EULA.
If you can't read the EULA before you purchase the product, don't buy the product. If you do, tough shit if you can't get your money back. The product was obviously more important to you than protecting your rights.
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.
This would vastly reduce the number of software firms and the availability of low-priced specialty 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
Unbelievable.
Do you have any idea how close you are to reality?
I'm a structural engineer, and. yes, that is an apt description of the conditions under which it means to be a true engineer.
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.
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.
The problem with Firestone tires is that when road conditions compromise your tires, any resulting damage can no logically be attributed to the tire manufacturer.
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 Firestone tires blew up on their own and flipped your SUV over you would have a legitimate case. As soon as you subject the tires to actual road conditions, the case is off.
Your contention is that Microsoft software is not fit for any actual use?
The question is whether the *law* will impose some kind of strict liability, which cannot be disclaimed, on software as is the case w/certain other products.
When an SUV rolls over someone dies.
When children's clothing chokes a child, someone dies.
When a doctor screws up a surgery, someone dies.
When IIS is hacked, L331 H4XOR OWNZORZ JOO.
If you had to prove code is solid, functional programming languages like LISP and ML would certainly make a come back. So it's not all bad. :)
Right now it's almost impossible to get good information on the quality of software. Heck there are even laws preventing it (like Oracles and Microsofts "no external benchmarking" BS).
How to do this right is a real problem. I would think though that one of the recognized bodies could set up some rules for the levels. (1. will not kill user, 2. will not format hard drive before use, 3. will not format the hard drive in standard use, etc..:) And the government would require software to carry a level that they promise the software will live up to.. even if it's no guarantees (the lowest level).
It just seems to me that software users need to be informed better what they can expect and then they will make the right decisions and over time their expectations/demands will increase.
DescSuit
Seriously though, there is no way you can fix "all" bugs, so releasing ANY software will just open you up to various lawsuits.
There is also a matter of who will be allowed to sue. For example, someone discovers a flaw, sues Microsoft, gets paid lots of $$$, Microsoft fixes the bug, posts a patch on their site, and a month later some other nut gets effected by the same bug. Should Microsoft pay that other nut as well just because they didn't upgrade? Many software problems are fixed soon after they're discovered, yet a vast majority of the people never bother to patch. (that's why these internet worms can spread, etc.)
Another issue is that many problems arise from improper use of the software. Most buffer overflow is definitely "improper use"... it is a security hole? Sure! But is it "regular" use? No! Software is designed with some proper use in mind, if you start to improperly use it, then sorry to say, the software wasn't designed for it. (well, granted, buffer overflow shouldn't be allowed, but just making a point).
In general the liability strategy will degrade software reliability, since a company will do a lot of in-house testing, etc., not releasing it into the public in fear of being sued. Now, no matter how many QA testers Microsoft or anybody has, they will NOT find all the problems in their software (60 million lines of code in WinXP???), AND they'll find a LOT less bugs than the general public. I know it's not nice to use your users as beta testers, but that's how software becomes reliable. People find bugs, complain, company fixes bug, and software becomes better and more reliable for everybody.
Then there is this whole thing about it being next to impossible to prove the correctness of a program...
"If anything can go wrong, it will." - Murphy
I was in architecture for 4 years before I moved to IT. Atchitects are responsible for every build they built until they die. I believe they're estates can be sued if a building falls down. Point is, Software is getting more and more important to money, wellbeing, and the market today. Wouldn't we want venders and even coders to be accountable for they're work. Open Source work its great but its not exempt from accountability...unless you just keep your code to yourself.
I guess I wouldn't buy plans for my house from a guys on the street corner, so I guess I wouldn't secure my computer systems with open source written by some kid in his basement. Only problem in that is the kid probly writes better code the Microsoft.
-- Disclaimer: I can't really back up anything I post on
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.
When buggy commercial software is rushed to market, and it's failure costs it's users money, the manufacturers of the software, like any other product, should be held liable. Companies like Microsoft and Oracle would whine and complain, but consider if cars failed as often as Microsoft's products. Having car buyers accept a licence agreement wouldn't exempt the big 3 from liability.
The Uncoveror: It's the real news.
While this doesn't translate directly to the Free software world, the idea that the damages are limited to the amount paid in the first place is useful (and obviously workable, or this wouldn't be a standard feature of so many contracts). The issue over functionality is trickier - in the Free Software world, often people add features just because they think they're neat - and often they turn out to be. Where liability exists you need to worry about the extra liability you are taking on as a result of adding all these extra features, though.
Companies could supply software for (nearly) free without worrying too much about liability. Once the income from software sales becomes a signficant part of your turnover though, you start needing to ensure that the software is properly designed and adequately tested (of course thorough testing is no substitute for good design).
I'm unsure about how well this kind of measure would survive a transplant from a contract to a license agreement (since I'm not a lawyer).
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...
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.
Actually, I work in support for a software company, and we had a customer report a problem with our software. We eventually tracked it down to a hard disk problem that was returning bad data. The customer actually had the nerve to say that it was our problem, and that if we couldn't handle the bad data, then we were poor programmers.
Now tell me, if the hard drive is going bad and intermittently returns bad data, including the the executable code itself, how are you supposed to deal with that?!? Do you write the code in multiply redundant code blocks, and tweak the machine code so that if the starting offset is set to a random location, including in the middle of a valid instruction, that your code can still recover?
Building code that can respond to all valid inputs with valid outputs, AND can respond to any and all invalid inputs with appropriate errors and or nothing (i.e. ignore the bad input), is one thing. Building a piece of software that can run, even in the presense of faulty hardware, is quite another.
I mean, what the hell do customers want?!? Is my company's software supposed to patch any and all seciruty holes in the OS as well? Fix their broken hardware, divine the corrupted data coming in from peripherals and disk drives? How about foretell the stock market for the next decade, and give them the phone numbers of hot chicks that will do them for free?
Well, Yes, actually.
For some problem domains. e.g. Aircraft Avionics, Spaceflight Avionics (where Radiation and single-event-upsets (SEUs) are a fact of life that will cause glitches.
But of course, such military/safety-critical-spec software costs a hell of a lot more than a standard piece of COTS. Using Ada and other high-grade techniques can actually save money in manufacture, but it still costs heaps to test.
It's a matter of requirements - what does the customer need? If crashing once a week is acceptable, providing the cost is less than $X then provide that. If crashing anytime is unnacceptable, then they should be prepared to pay maybe six times that.
Note: I know whereof I speak - I've been chief architect for a Naval Combat System, lead a team on spaceflight avionics software development. And one system I had a small part in at one time had a hardware problem that caused unpredictable jumps to random locations in memory. It still worked - just slowly as 95% of the time was spent in error-recovery. Adequate to ensure no-one died as the result. But we fixed it before delivery anyway, was a problem caused by a 3rd party CPU design flaw.
Zoe Brain - Rocket Scientist