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.
“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.”
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.
Filed Under: buggy software, liability, software, uk
Comments on “UK Court Says Software Company Can Be Liable For Buggy Software”
“since pretty much all software has bugs. That’s the nature of software“
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.
Re: #1
Software is different because of how it is designed. When you build a car, you either make each part yourself or buy the parts from a vendor who makes it. When building software, you have various vendors making dozens of different parts that should do the same thing, but might not (different video cards, different processors, etc.), all being controlled by an OS in an unknown state of patching with other unknown bits of software installed legitimately (Office, WoW, Firefox, anti-virus, etc) and illegitimately (viruses, DRM, etc). This machine is then being controlled by the software you built, which is built using libraries others built that you can’t control, which are in turn are being controlled by drivers the hardware manufactures wrote that may or may not do things differently, and your program is sharing time with other programs that may interfere with your ability to run your program successfully. And to top it off, in any non-trivial application you can’t be certain that the answer that your system gives is correct until after shipping it.
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…
Re: Re: #1
And as an extension of this, I would say the difference is similiar to the way property is applied differently between digital objects and tangible ones.
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.
Re: Re: #1
“When building software, you have various vendors making dozens of different parts that should do the same thing…“
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?
Re: Re: Re: #1
When building software, you have various vendors making dozens of different parts that should do the same thing…”
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.
Re: Re: Re: #1
How do you prove where the error is? Since obviously someone should be liable, who should it be? The hardware maker? The library programmer? “I didn’t certify that for X use.” Perhaps the person who wrote the other software. “This software may only be run as the only process on the machine to ensure results” will soon be in every other EULA, and it wouldn’t necessarily be unreasonable. The virus writer is in enough trouble if he can be found, but just because he is hard to find doesn’t mean it isn’t his fault. Are you going to determine whose fault it is?
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).
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.
Re: Re: #1
The reason why this is all such a problem is because of the copyright controlled closed source model of development.
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.
Re: Re: Re: #1
How would having access to the source code help? Do you have time to verify it? Let’s look at an example:
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.
Re: Re:
The number of bugs with a program reaches towards infinity.
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” ?
Re: Re: Re:
So… we will all buy Macs?
Re: Re: Re: Re:
truly a horrifying scenario.
Re: Liability
This issue appears to be about liability as was excluded in the sales contract (or not) provided by the signed documents and allow ability by law. In the good old USA and the export of their systems to other parts of the world, “consequential liability” now needs to be clearly excluded in all contract documents, otherwise it is deemed “included”. A take-off from insurance policies.
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”.
Software
If we start with the following premises:
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
Re: Software
Ah, so that explains Windows ME…
Re: Re: Software
“Ah, so that explains Windows…”
TFTFY
I think it depends on the circumstance, under most circumstances it would be quite unreasonable, but if it is a case where it is serious enough that one could make a good case for fraud, it wouldn’t necessary be a bad thing. For example, if you are selling a game, and released it in a state where a sizable percent of people are unable to play (in conditions that the manufacturer said would be able to) because of a bug, and the company does not do anything about it, then liability could be argued. Also if damage from the code does significant damage to PCs, or creates other such issues, from a bug because of a huge oversight, then it is reasonable that the company be responsible.
As with most software...
The problem exists between the chair and the keyboard
Being liable doesn’t mean you must be perfect, just responsible. Who else but the developer could be responsible for bugs in the code? They aren’t acts of god.
Thank goodness.
“Windows ME” is the only operating system I have been able to get to working.
Maybe this will finally stoke the flames so I can finally get something stable and works for ME.
As i understand it, they made specific claims in the sales process about improvements the new system would provide over the existing system and what they delivered did not live up to what the sales people claimed. The judge simply applied the “fit for purpose supplied” test of the sale of goods act. In other words you can’t say buy my software it will be 25% faster than your existing software and then deliver something that does not live up to the claim and hide behind a contract clause.
its the end of world and we know it
and i feel fine
so does anyone buy software any more?
What About
Buggy software used in an automobile that causes the car to have an accident, who would be responsible.
How about medical device software?
Re: What About
In the US, if it is a Class 3 device and “FDA-approved”, currently you are out of luck (Federal preemption). On the other hand, if it is a Class 2 or Class 1 device, it is adminstratively cleared based upon materials submitted by the manufacturer (not “approved” by the FDA) and manufacturers get sued all the time for faulty design, faulty manufacturing, faulty claims, etc.
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?
Re: 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,
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.
See, for the average software company is probably a non issue. What this means for the big players on the other hand….
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…”
Torn on this issue...
I’m really 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
Re: Torn on this issue...
I don’t think liability is really supposed to make up for a lack of competition 🙂
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.
Re: Re: Torn on this issue...
You could probably say goodbye to public bug trackers, if they could be used as evidence that a company knew about a bug but didn’t fix it.
Software liability already exists
For product manufacturers with embedded code (e.g. car and aircraft manufacturers, medical device manufacturers), the manufacturer is just as liable for software defects as they are for hardware defects.
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.
Re: Software liability already exists
One other thing – those “right to sue” software prices also always come with a detailed list of supported configurations. If you aren’t running on supported hardware/OS/database engine/etc, that will be used as a defence by the vendor. “Y’r honour, we never warranted correct operation in that configuration. The plaintiff chose not to follow our operating guidelines and suffered the consequences”.
It really boils down to just a few things:
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.
Bjarne's take
“Software developers have become adept at the difficult art
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++
what's the standard?
Are we talking about real damage with a dollar amount, or are we talking about inconvenience? I mean either of those can shoot a reputation to hell, which is fine, but at what point do you decide to turn up the heat?
I develop bespoke asset protection and safety systems for mining operations.
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).
The issue here is not whether a company should be liable for every single defect in their software. It’s about software being sold, and advertised for a specific purpose and not being fit for that purpose.
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.
UltimateGuitar.com - Online Guitar tab & chord resource.
I will be the first to admit, I’ve watched For The Love of the full lace wigs and lace wigs several times, maybe lace front wigs and lace front wigs too many times, but that’s besides the point.
Thanks for taking the time to discuss this, I feel strongly about it and love learning more on this topic. If possible, as you gain expertise, would you mind updating your blog with more information? It is extremely helpful for me.
Liabilities of an IT Profetional
I believe that the UK Court is completely RIGHT about making liable a Software Company for Buggy Software, every IT Profetional and Software Company must be responsible for the quality of their software. Of course they must take also in cosideration, that to realize the same taks or calculations manually also represent posibilities to commit errors and miscalculations, more frequently.
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.
Re: Liabilities of an IT Profetional
That’s a great plan for making software 10 times as expensive as it is now. And if it applied to open source or free software, that market would pretty much disappear overnight in any country where this was enacted. Who is liable if postgres or CentOS causes monetary damage? Lots of people would just stop distributing that software because they can’t afford the liability.
Re:
>> “Who else but the developer could be responsible for bugs in the code? They aren’t acts of god.”
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).