UK Court Says Software Company Can Be Liable For Buggy Software
from the opening-the-floodgates? dept
For many, many years the debate has raged on whether or not software developers should be liable for bugs in software. Plenty of companies, sick of dealing with buggy software, have felt that developers should be legally liable, just as any other defective product. But many argue back that, with software, that's not really reasonable, since pretty much all software has bugs. That's the nature of software -- and making developers potentially liable for "defective" offerings, because the software has some bugs, opens up so much liability that it could cast a chill across all sorts of software development -- especially in areas where software is especially buggy. And, of course, there's a strong argument that those unintended consequences would do significantly more harm than good, such as driving good developers out of the business, because the liability is just too high.That said, software liability has been a hot topic in Europe lately, and now Slashdot points us to the news that the UK High Court has ruled that a software company can be liable for buggy software. More specifically, the court found that a clause in the license agreement, which said it would not be liable for defects was found to be an unfair contract term.
Of course, it also sounds like there were some special conditions here:
The judge said that the exclusion of liability was unfounded because of the particular way in which the software sale had been conducted. The fact that a full set of operating documents for the software had not been provided and the fact that Kingsway made its purchasing decisions largely based on Red Sky's claims for the software eroded Red Sky's ability to limit its liability, the Court said.So, as the article notes, the issue here may be more about liability arising from the sales process, rather than just general liability, so it hopefully won't have the same sorts of chilling effects that general liability for bugs might have.
"Red Sky's' standard terms were predicated on the fact that a prospective customer would investigate Entirety [the software] and make up its own mind whether or not to purchase based on demonstrations and the Operating Documents which Red Sky had previously supplied," said the ruling. "It did not apply to circumstances in which the customer relied on Red Sky's' advice in deciding to purchase Entirety."
"The exclusions in clause 10.2 [of the terms and conditions] only applied where the Operating Documents as defined in Clause 1.1.6 were supplied to the customer before the contract was signed," it said. "In this case such documents were not supplied by Red Sky to Kingsway. Therefore, Clause 10.2 and the exclusions derived there from did not apply."
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: buggy software, liability, software, uk
Reader Comments
Subscribe: RSS
View by: Time | Thread
Can anyone point to any physical thing that's completely perfect without any defects? Cars fail to start and sometimes crash due to defects, TVs stop working, laptop batteries explode, etc, etc, etc. There is simply no perfection in anything we do.
This exact same argument was used when tort laws were expanded back in the 1800s and 1900s. Somehow the manufacturing sector survived being held financially responsible for their defects. The software industry will somehow survive it too.
[ link to this | view in chronology ]
Re: #1
If it is correct, might it just work for that one input? Better test a few more to make sure. What if those are the only right ones? Better test a few more. What if this hardware configuration is the only one that will work? Better test all of this on a few more machines. What if an OS patch breaks this, or a recent patch makes it work? Better test it against all possible patches. What if some other software breaks it? Better test against all possible combinations of software that could be on this machine. So far, we need to check our program against all possible input on all possible hardware with all possible OSs and patches with any other software available to guarantee that our program will work...
[ link to this | view in chronology ]
Re: Re: #1
Cars, for instance, are inflexible; you have huge companies that come out with several models a year that you have to accept exactly as is. If you start swapping out parts, then the manufacturer doesn't have liability.
With software, you can have thousands of different components in different states, which means that it is incredibly flexible and modular. They can all be created or modified very closely to the individual's specifications and then installed on the environment you choose, because of the beauty that is digitization.
Giving up all those advantages is a lot like what record companies are trying to do by treating mp3s like CDs.
[ link to this | view in chronology ]
Re: Re: #1
And if the error/defect actually exists with the vendor's part, you would be dismissed from the lawsuit.
"This machine is then being controlled by the software you built, which is built using libraries others built that you can't control"
And if the error/defect actually exists within some third parties libraries you would be dismissed from the lawsuit.
"your program is sharing time with other programs that may interfere with your ability to run your program successfully"
And if the error/defect actually exists because of some interference created by a third party you would be dismissed from the lawsuit.
All of your "arguments" above merely assume that the software has no defect and the complained of defect comes from something else. As I pointed out, that only means you would not be liable as your software has no defects in it. You got anything else?
"you can't be certain that the answer that your system gives is correct until after shipping it"
Isn't that true of anything we build? Toyota was pretty certain of its braking system when it first shipped. History proved that belief incorrect. Your argument supports everything I said.
".... Better test a few more to make sure. What if those are the only right ones? Better test a few more...."
The automotive industry is still working on how much and on how to test, but yet it's still liable when its defects cause crashes.
You got anything else?
[ link to this | view in chronology ]
Re: Re: Re: #1
And if the error/defect actually exists with the vendor's part, you would be dismissed from the lawsuit.
"This machine is then being controlled by the software you built, which is built using libraries others built that you can't control"
And if the error/defect actually exists within some third parties libraries you would be dismissed from the lawsuit.
"your program is sharing time with other programs that may interfere with your ability to run your program successfully"
And if the error/defect actually exists because of some interference created by a third party you would be dismissed from the lawsuit.
All of your "arguments" above merely assume that the software has no defect and the complained of defect comes from something else. As I pointed out, that only means you would not be liable as your software has no defects in it. You got anything else?
Great, so we'll just have thousands of lawsuits with hundreds of plaintiffs and spend hundreds of hours looking through proprietary code to trace the source of the defect. That is a very efficient way of allocating resources for progress and innovation. Not. We desperately need less work for lawyers, not more. Time and money spent in a courtroom is a necessary evil, but nevertheless a deadweight on society.
You also seem to be discounting the unintended effects of a system like this. Microsoft, for example, has many, many different parts of their OSes to increase speed, modularity, updateability, etc. It is designed to allow any number of third-party programs to run on it, and to run on any number of different hardware configurations. Do you think Microsoft would just shrug when they heard about this new liability and spend extra effort making sure they coded well? Or would they eliminate all that choice and spend a year testing a closed system with very few customizable options to limit their liability, like cars do? A component may not work simply because it wasn't designed to work in a given situation that you choose...so they would simply prevent their software from working with anybody else' software.
The automotive industry is still working on how much and on how to test, but yet it's still liable when its defects cause crashes.
Automobiles are closed systems that have to work given a small number of scenarios. What you want to do is place liability on Toyota for making sure their cars work with any modification, in any physical constraint(maybe it's supposed to drive on Mars), and continue to do so as Toyota updates each component quickly and piece-by-piece as they ensure that every possible permutation of evolving components continues to work correctly.
Software is not the same thing, because it is created differently to exploit it's advantages. If there is liability, it needs to be contractually defined as a requirement, or this idea is just terrible.
[ link to this | view in chronology ]
Re: Re: Re: #1
Also, a Toyota has very few use cases. You accelerate, brake, and turn. It is reasonable to test all of these features. You interact with it via 2 (or 3) pedals, a steering wheel, and a few other components, and they have a very specific range of inputs. There are no elements outside of Toyota's control, except other cars and weather.
Contrast that with software.
Software can have hundreds of use cases, especially enterprise software. It can have any input and can be controlled in any number of ways. There is very little that is in the programmer's control. You dismiss this as testing needing to be improved, but it is not that simple. Security is a basic requirement of all software, but what if it is broken? Is it the hacker who should be liable, or the person who made hackable software? The hacker was just using the program in a way the developer didn't envision (which is not a crime) and it followed his directions. That's the beauty of all software, it does exactly what you tell it to. Of course, it also does exactly what you tell it to. Why should the hacker be punished? It was the developer who didn't specify that that particular operation was not allowed.
Note: There are cases where software vendors should be liable, just not quite as often as you seem to think. Selling someone an "enterprise database system" that is a pretty skin on top of code ripped from OO.org's Calc program is obviously fraud. But that and other related issues should be false advertising, not bugs, assuming that the bugs don't prevent primary functionality (ie, selling WoW with a bug that prevents the game from connecting to the server).
[ link to this | view in chronology ]
Re: Re: #1
Having seen my share of nightmarish kludge, a big part of me wishes there were some sort of enforceable liability (or, at work, "accountability") for code released into the wild.
However I have complete faith that the courts, which cannot reach consensus on the concept of copyright infringement, would be impotent at determining and defining standards for determining the root-cause of a catastrophic, system/data destroying crash.
AC replying to #1 illustrates the reality of programming in today's environment pretty well.
[ link to this | view in chronology ]
Re: Re: #1
You can't fix these problems because you haven't got access to the source code.
In the end proprietary s/w will collapse under it's own weight. A stricter liability regime, linked to the EULA and sales practices will hopefully hasten its demise.
[ link to this | view in chronology ]
Re: Re: Re: #1
I want to use perl's regex evaluator. To make sure it works, I need to look at perl's source code (in C) and determine it works correctly to use it. If memory serves, this is a rather long parser written using lex, which is ,more or less, it's own language based off of C that is translated into a program that examines text. So, to use a single statement in perl, I need to know C and lex well enough to verify that they work as advertised. But what is lex has a bug? I'd better look at lex too, but at least it is in C so I don't need to know another language. However, there is another problem. What if the compiler has a bug in it? I'd better brush up on my assembly too, which is specific to each family of processor. And since I can't trust the assembler, I need to check the reference manual to make sure the assembly-to-binary conversions are correct too. Open source is a good thing, generally, but that does not make bugs obsolete.
[ link to this | view in chronology ]
Re:
Any software program you run has a bug.
Allowing software companies to be attacked on every nit picking bug is insane and that is the fear software developers have.
Should software developers for x-ray machines been held liable because they didn't plan on technicians typing at the computers clock speed when inputting commands which caused a radiation overdose?
Do we need large specific documents that say "This software has been approved with systems installed with this OS, with this hardware (RAM speed and manufacturer, CPU of specific clock speeds, steps and manufactures, etc), and patches of this date, etc, etc, etc. Otherwise use at your own risk" ?
[ link to this | view in chronology ]
Re: Re:
So... we will all buy Macs?
[ link to this | view in chronology ]
Re: Re: Re:
[ link to this | view in chronology ]
Re: Liability
So then it might not be as simple as "here is your purchase money back", but "my business went under because of your buggy $400.00 software, with millions of dollars of lost revenues and profit, and now you have got to make good on that loss".
[ link to this | view in chronology ]
Software
1) All software code can be reduced by at least 1 line.
2) All software code contains bugs.
Then we can deduce that all software can be reduced to 1 line of code which doesn't work.
; P
[ link to this | view in chronology ]
Re: Software
[ link to this | view in chronology ]
Re: Re: Software
TFTFY
[ link to this | view in chronology ]
[ link to this | view in chronology ]
As with most software...
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
That would be fine if your computer were running only code from a single developer (or company).
However in reality, at any one time, a typical (e.g.) windows PC will be running 10, 20 or more different processes, typically most written by different vendors.
With all that code from the different vendors all crammed onto the same CPU, sharing the same resources, stepping on each other's toes, how on earth can you hold an individual developer responsible if some other vendor's code does something unexpected? Or if particular combinations of code perform in unexpected but undesirable ways.
And that's even without the issue that you typically write your code at a 'high level' calling on libraries written by others. As a developer you have no control over the reliability of the libraries you use (OK, you could test them to some extent, but you could never test them completely).
[ link to this | view in chronology ]
Thank goodness.
Maybe this will finally stoke the flames so I can finally get something stable and works for ME.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
its the end of world and we know it
so does anyone buy software any more?
[ link to this | view in chronology ]
What About
How about medical device software?
[ link to this | view in chronology ]
Re: What About
IMHO, the arguement that software is special or different is just specious. Software engineering, exercising greater care, doing more careful and comprehensive testing just cost too much time and money, especially when you have already trained your customer base to live with the flaws at a given price point.
GF we should deliver a better product, if we have to sell less or at a higher price. Where is the fun in that?
[ link to this | view in chronology ]
Re: Re: What About
Exactly. People are willing to pay for a car that has been carefully engineered and tested so that everything works right (and are liable if it does not). Generally people would not be willing to pay as much as they would have to for the same level of quality in software. It is possible to do, but very expensive. Also, in general publishers aren't liable for any damages if software goes wrong.
[ link to this | view in chronology ]
Get ready for a shit storm of class action law suits. If this were in the US there would be commercials every 5 seconds:
"Have you or a loved one been effected by bad software? Have you ever blamed your self for not reading the manual? At the law offices of Sleazinski and Shitforbrains we know how hard it is to deal with tech support. Thats why were hear for you, just call and complain. We assure you that no Indians named "Bob" will have to elevate your tramua..."
[ link to this | view in chronology ]
Torn on this issue...
I'm dealing with a software vendor now that has an intermittent issue/bug that so far has eluded being able to reproduce it. They don't want to take the time to invesigate, always blame the environment, but when you ask them if they can enable any sort of logging/debugging code they tell me straight to my face that there is no such option (which might explain why the software is so damn buggy in the first place).
So they don't have any way to track what is happening with the internals of the program so when it does fail they can clue into the root cause and yet won't do anything until you can give them 3 steps to reproduce problem.
Of course, the one I love is that no one else is having the problem. You then ask how they track unresolved or intermittent issues and they tell you they don't have a system in place.
Frankly - for these guys a set of hard legal standards would get them to improve their game. But then again so would competition but for this particular solution we are pretty much stuck with them.
Freedom
[ link to this | view in chronology ]
Re: Torn on this issue...
This does bring up a good point though: Usually the only ones who can really tell whether or not the problem is actually caused by a software bug in their software are the software developers themselves. If admitting this would cost them a ton of money, they might not look for bugs quite as hard anymore...
In your situation, you can't show that the problem is their fault (and therefore they are liable) without their help.
[ link to this | view in chronology ]
Re: Re: Torn on this issue...
[ link to this | view in chronology ]
Software liability already exists
For Software-as-a-Service providers with service-level-agreements with their customers, failure to achieve the contracted level of service is grounds for a civil suit.
Generally speaking, when you see those huge price differences between general purpose software and "enterprise" software? The latter often has a "right to sue" built in to the price (not always, but in the cases where it isn't, the price difference often isn't quite so large, either).
An interesting way to tackle this in general may be to allow vendors to mitigate or eliminate their liability by providing the source code to their product, allowing prospective customers to perform their own due diligence.
[ link to this | view in chronology ]
Re: Software liability already exists
[ link to this | view in chronology ]
Is there a reasonable expectation for glitch free code?
-In the case of medical equipment where the machines are configured exactly the same and people's lives depend on it, yes! for Firefox or even MS Word, probably not
Is glitch free operation guaranteed?
-If a company guaranteed glitch free operation, then there is no question about it, they are liable.
We should treat software similar to physical products, manufacturers are held liable for injuries and deaths due to their equipment, and they are held liable when they are contractually responsible. If your toy breaks and there is no warranty/guarantee, though luck. If it breaks and it has a warranty/guarantee then return it for a refund or replacement. If your 2 year old chokes on a small piece of that toy because it was poorly designed and marketed for 2 year olds, then sue. If your child chokes on a small toy that was sold for adults and included choking hazzard warnings, then I'm sorry but not the company's fault. Apply that same idea to software and we'll be fine.
[ link to this | view in chronology ]
Bjarne's take
of building reasonably reliable systems out of unreliable parts. The snag is that often we do not know exactly how we did it." -- Bjarne Stroustrup, creator of C++
[ link to this | view in chronology ]
what's the standard?
[ link to this | view in chronology ]
No one sues if something goes wrong because the companies know these new systems save them money in the long run, even if the system makes the odd error.
Companies that produce buggy systems quickly disappear as word travels very quickily.
Any company knows if it sues one supplier (for bugs in one of these new systems) it will no longer be able to buy from any supplier or will pay much more for these systems (as the suppliers will factor in the cost of possible litigation with that company).
[ link to this | view in chronology ]
Software producers have got off easy for far too long and should be held liable when their software doesn't function.
Over the years I've had numerous games and other software that simply DID NOT function at all out of the box. If the first thing I need to do after buying software is trawl through Google to find a way to make it work, something is very wrong.
[ link to this | view in chronology ]
Re: UltimateGuitar.com - Online Guitar tab & chord resource.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Liabilities of an IT Profetional
It is important to set some limits to the liability, for example, an error factor below or equal to 5% should be allowable, meaning, if the software presents a 3% of transactions with errors, the error must be fixed but the Software Company should not be punished with fees or monetary charges, as long as the error in the application that produced this transactions is completelly fixed, but if the application presents 15% of transactions with errors, the Software company should pay for the monetary damage they inflicted and of course repair the error on the application. If the error is produced by 3rd party software, like the database engine, the Provider of the DB Engine should be made liable for this errors, of course read carefully the licence agreement and the support and warranties offered by your providers before buying the software, even if you are an experienced Developer and even if you used before the same software, minor changes on this terms could mean that you are completelly alone when a major error shows his face that will surelly replicate thru all your servers.
I also believe that if someone pays attention to this, Microsoft could and SHOULD be suited there for their many bugs in their software. I hope some Law Firm takes the case.
[ link to this | view in chronology ]
Re: Liabilities of an IT Profetional
[ link to this | view in chronology ]