Robert Carolina

Victims of defective products are not required to demonstrate the “fault” of a product manufacturer. It’s enough to demonstrate the existence of a defect in the product that causes harm. Under European laws, “a product is defective when it does not provide the safety which a person is entitled to expect taking all circumstances into account…” [1] at Art.6; [2] at s.3.

 

Product strict liability has always been a source of concern for manufacturers (and importers, who are subject to the same liability). They are obviously concerned about liability in the absence of fault. Unlike many other forms of liability (like warranty), manufacturers are practically unable to limit this liability to victims who sue alone or collectively in a class action.

Two important conditions must exist before a victim can succeed on a strict liability claim:

1) There must be a “product” which is defective
2) A victim harmed by a defective product can only use this legal theory to claim compensation for death or personal injury (or damage to non-commercial property under the laws of the EU). Economic harm, business interruption, loss of business revenue, etc, are not recoverable under this theory.

These two conditions made strict liability a niche topic or an intellectual curiosity for most lawyers working in the fields of software development and cyber security and meant that it was traditionally overlooked in these fields. For decades we have taken comfort in the widely shared legal opinion that software, as such, does not fit within the definition of “product” under European or American laws. Even if software was to be viewed as a product, we reasoned, opportunities for defective software design to cause death or personal injury seemed exceedingly rare.

One long-understood risk of strict liability concerns defective software control systems as a component in safety-critical hardware. The manufacturer of the resulting defective hardware is subject to strict liability claims, irrespective of the source of the defect.

This risk can be illustrated with the example of the Therac-25 radiation therapy machine. Between 1985-87, six patients treated using the Therac-25 were exposed to massive radiation overdoses (100x intended dose). Three of these patients died as a result of the overdoses. The design of the machine’s system control software is widely cited as a cause of the overdose incidents, which were thankfully rare. [3]

Under a strict liability analysis, the Therac-25 device as a whole is a “product”. If the machine failed to provide the “safety which a person is entitled to expect,” such a product would be defective and the manufacturer strictly liable for personal injury or death. The fact that the flaw originated in control software would be irrelevant.

For decades, my legal colleagues and I rested comfortable in the belief that software errors (including software security flaws) rarely killed anyone. Today, by contrast, the IoT presents a rapidly growing set of opportunities for “death by software”. A net-connected software-controlled product (e.g., an autonomous vehicle, an industrial control system, a pacemaker, a vehicle using fly-by-wire) that fails to deliver appropriate safety, is defective whether the safety is compromised through the design of electrical, mechanical, software, or security, systems.

Thus strict liability applies to products whether safety is compromised through errors in algorithmic decision-making (e.g., an autonomous vehicle decides to swerve into oncoming traffic after misreading road markings) or security errors (e.g., a broken authentication scheme permits a remote hacker to divert the same vehicle into oncoming traffic).

While the hardware product manufacturer (or importer) is clearly subject to the risk of strict liability, what about those in the upstream supply chain? What if, for example, the manufacturer of the Therac-25 had purchased their control software from a third party as a component, or the autonomous vehicle manufacturer adopts and installs a defective authentication package embodied in third-party software?

Under current law, defective component “product” manufacturers face strict liability. A manufacturer of defective brakes, for example, is strictly liable for personal injury caused by automobiles which become defective because the defective brakes are installed.

Software (on its own) is not currently thought to be a product in this area of law. The author of a defective software component probably cannot face a strict liability claim from an injured victim – even if the software caused the hardware product to harm the victim.

This may be about to change.

More than three decades have passed since the 1985 adoption of the European Directive on product strict liability [1]. The reliance society places on software and online services has become a central feature of everyday life. European policy makers have noticed, and the tide of product liability policy appears to be shifting.

The European Commission completed a comprehensive evaluation of European product liability law in 2018. The term “software” features prominently, and repeatedly, in the 108-page report [4]. The Commission openly questions the extent to which “digital products” (e.g., software as a product, SaaS, PaaS, IaaS, data services, etc.) should be redefined as “products” and thus subjected to strict liability analysis when defects cause death or personal injury [5].

A Commission Expert Group on liability and new technologies is currently examining possible changes to the law. Expanding the definition of “product” is central to this review.

We seem to be accelerating towards a world in which cyber security failures in the IoT will create increasing risk to life and limb. Manufacturers of tangible IoT products already face strict liability if their product is unsafe – including cases where safety is compromised by poor cyber security. It appears that software developers, SaaS providers, and other cloud service providers, may soon be required to step up to this same stringent standard of responsibility throughout Europe. We hope they’ll be prepared for the challenge.

Works Cited:

[1] European Economic Community, Council Directive of 25 July 1985 on the approximation of the laws, regulations and administrative provisions of the Member States concerning liability for defective products (85/374/EEC), vol. L210, 1985, p. 29.
[2] Consumer Protection Act 1987.
[3] N. Leveson, “Medical Devices: The Therac-25,” in Safeware: System Safety and Computers, Addison-Wesley, 1995.
[4] European Commission, Evaluation of Council Directive 85/374/EEC of 25 July 1985 on the approximation of the liability for defective products, Brussels, 2018.
[5] European Commission, Liability for emerging digital technologies, Brussels, 2018.

Robert Carolina
Executive Director, Institute for Cyber Security Innovation
Senior Visiting Fellow, Information Security Group
Royal Holloway University of London

April 15, 2019