More on Software Liability

I’ve posted here before about the issue of product liability for software, and the somewhat strange current situation, in which software vendors typically do not face any liability for defects in their products.   Anyone who has used a computer for more than, say, ten minutes knows that this is not because software defects are rare.  Among other things, this situation produces an economic externality: the party who is in a position to reduce defects (the vendor) is not the same as the party who will benefit most from a reduction in defects (the user).  The expected result is that the level of defects will be greater than would be optimal for the user.  I am not aware of any evidence that this is not the case.  Making vendors liable for defects would shift their incentives, and probably lead to a better-quality product.

The ACM Queue site has a recent article by Poul-Henning Kamp, which proposes a slightly different approach to the issue of software product liability.  It starts by recalling Ken Thompson’s address, “Reflections on Trusting Trust”, given at his acceptance of the Turing Award from the Association for Computing Machinery in 1983.  In particular, Mr. Kamp refers to this key sentence from Thompson’s speech:

You can’t trust code that you did not totally create yourself.

Of course, we cannot all create our own browsers, office suites, editors, and operating systems.  We don’t, generally speaking, build our own cell phones, cars, or houses, either.  As Kamp points out, the makers of these other products are liable for defects, and that creates a set of incentives that make it reasonable to trust the builder of a house:

The reason for this trust is that shoddy construction has had negative consequences for builders for more than 3,700 years. “If a builder builds a house for someone, and does not construct it properly, and the house which he built falls in and kills its owner, then the builder shall be put to death.” (Hammurabi’s Code, approx. 1700 BC)

The article then makes a modest proposal for the structure of software product liability.  The proposal has three main parts, or clauses.

  • Clause 0. Consult criminal code to see if any intentionally caused damage is already covered.   The objective of introducing civil liablity for software defects is to give the user some protection an legal recourse in the event of unintentional damage.  Most jurisdictions already have laws making intentional damage a criminal offense.
  • Clause 1. If you deliver software with complete and buildable source code and a license that allows disabling any functionality or code by the licensee, then your liability is limited to a refund.   This would obviously apply to free and open-source software, for which source code is provided, and where modifications by the user are permitted.  However, it could also be used for proprietary software, since it just requires that source code be supplied, and that the user can disable any parts that (s)he does not trust.
  • Clause 2. In any other case, you are liable for whatever damage your software causes when used normally.  If the vendor does not want to share the source code with the user, as in Clause 1, then normal product liability rules would apply, and the vendor would be liable for damage  caused by defects.  The precise legal definition of “normal use” would have to be clarified; I suspect one side effect of a rule like this is that software would come with much more definite specifications.

Kamp acknowledges that fairness would require a phase-in of the new rules, to give the vendors a chance to clean up their acts.  The industry can also be expected to scream loudly about any attempt to move in this direction.  But the current state of affairs is really not very satisfactory, and some change is clearly in order.

There is little doubt that my proposal would increase software quality and computer security in the long run, which is exactly what the current situation calls for.

Software is admittedly a complex product, and getting everything right is far from easy.  But a Boeing 747 is a complex product, too.   The software vendors have been getting away with a lot, and perhaps they need some more incentives to do a good job.

Comments are closed.

%d bloggers like this: