In my previous two blog posts I discussed concerns with the European Cyber Resilience Act (“CRA”) which we believe will harm both the open source community and the innovation economy in Europe. But the CRA needs to be understood as part of a larger legislative framework. In this post we will examine the potential impact of the proposed changes to the European Product Liability Directive (“PLD”) on the open source community and ecosystem.
As in previous discussions I think it is important to note that the intentions of the PLD are good. No one can argue that the time has come to protect consumers from poor software. But at the same time, it is important to ensure that the consumer liability obligations are borne by the economic actors who deliver products and services to consumers, and not by the open source community which enables so much benefit to society by providing free software but does not share in the profits of the delivery.
As I understand it, the purpose of the CRA is to establish which parties are responsible for ensuring the quality of software products, particularly as it relates to cybersecurity. The purpose of the PLD is to establish which parties are liable for defects which cause harm to individuals or their property. So strictly speaking, my assertion in my previous blog posts that the CRA will break the limited liability obligations that underpins free software was incorrect. It is the PLD which is doing that.
The European Commission presented a draft of the revisions to the PLD last September, and it is going through the process of being adopted by the European Parliament and the Council of the European Union. As a Directive, the PLD will be interpreted by each member state of the European Union and applied to updates of the local laws in each country. The specific intent of these revisions are to update the PLD of 1985 to address issues related to the modern digital economy. One of the key features of the PLD is its “no fault liability” model where injured parties can seek redress without demonstrating any error or fault on the part of the product manufacturer. The proposed revision explicitly expands the scope of no fault liability to cover software and artificial intelligence, and adds “loss or corruption of data” as a harm that could be suffered by a consumer.
There are numerous legal summaries of the PLD available, but this one from the law firm Baker Mackenzie provides a nice overview, as does this one from the law firm Cooley.
It has long been understood that product liability could not be completely waived by open source licenses in Europe. Hence, the “…to the extent permissible by law…” statements you see in many licenses. Since at least 1985, there have been strict provisions in Europe that you were always liable for harm caused to natural persons or their personal property as a result of using a defective product. From the perspective of an open source developer, the PLD extends and modernizes this legal framework in the following important ways:
- It explicitly extends the definition of product to include software and artificial intelligence;
- It explicitly extends the definition of harm to include loss or corruption of data;
- The definition of manufacturer (formerly producer) has been extended to cover developers, providers of software, providers of digital services, and online marketplaces;
- It makes it clear that a cybersecurity vulnerability is a product defect, and that failure to update a product to protect against a vulnerability may result in liability;
- It makes it clear that if a component is defective, liability may extend to the manufacturer of the component (e.g. the developer of the open source software), in addition to the manufacturer of the end product;
- Distribution of a product or component in Europe explicitly incurs liability obligations on the part of the distributor, unless they can identify a responsible economic actor in Europe; and
- There is an attempt to exclude open source from the provisions of the Directive, but as previously discussed the “…outside the course of a commercial activity…” language means that the exclusion is not helpful in practice.
Article 7 of the PLD goes to great lengths to identify the economic operators who can be held liable for a defective product, with a particular emphasis on identifying an entity in Europe who can bear the responsibility for a defective product made available in the single market. If you parse Article 7, who get something like the following to determine the party in Europe liable for a defective product:
- If the manufacturer is European, then the manufacturer is liable.
- Otherwise, if the importer or manufacturer’s authorized representative are European, then the importer and/or manufacturer’s authorized representative are liable.
- If none of the above conditions apply, each distributor is liable (each distributor is given 1 month to identify one of the above economic operators to hold the bag)
Note that the manufacturer of a defective component also becomes liable.
Should Open Source Developers be Worried?
I think they should. Particularly if they are located in Europe.
Huge caveat here. I’ve been studying the PLD for a couple of weeks now, and every time I read it I think of more corner cases and more scenarios. If anyone finds fault in my analysis or logic, do please let me know!
Scenario One
Imagine a scenario where a year ago or so a consumer in Europe lost data as a result of using the Wizbang product from BigCo GmbH. The vulnerability in Wizbang was caused by the famous Log4shell bug. As part of its normal build process, BigCo downloaded the Apache Log4j jar file from Maven Central. Under the PLD framework, the Apache Software Foundation (“ASF”) is the manufacturer of the Apache Log4j jar file and Sonatype (the company controlling Maven Central) is the distributor of the Log4j component as they made the Log4j software available to the European market. (The relevant definition reads “…‘making available on the market’ means any supply of a product for distribution, consumption or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge”). Both the ASF and Sonatype are US based organizations.
Under the PLD, BigCo, the ASF, and Sonatype are all ‘economic operators’ involved in the development of the Wizbang defective product. As mentioned above, Article 7 of the PLD lays out the liability obligations for each of the various types of economic operators.
My read of the PLD is that as the European manufacturer of Wizbang and the importer of the Log4j component, BigCo GmbH would be liable to consumers of the defective product. I think the ASF would not be held liable for the defect in Log4j because it does not meet the definition of an economic operator in Europe. I.e. the ASF has no legal presence in Europe. Similarly, Maven Central is a distributor in this context, but the algorithm in Article 7 puts the importer ahead of the distributor in the queue for liability obligations.
Scenario Two
Same as above, but instead the defective open source component is (say) the Eclipse Modeling Framework (EMF), so the component manufacturer is the Eclipse Foundation AISBL, a European-based open source foundation.
My read of the PLD is that as the European manufacturers of the Wizbang product and the EMF component, BigCo GmbH and the Eclipse Foundation would both be jointly and severally liable to consumers of the defective product. If I am correct, this scenario puts European open source projects, communities, and foundations at a disadvantage relative to their international peers.
Summary
The good news is that I can’t think of a scenario where Maven Central, or services like it, become liable as a distributor under the PLD. The components they distribute would be used by a manufacturer and there are several layers of economic operators in front of a component distributor before liability results. The same seems to be true for open source foundations based outside of Europe.
The bad news is that it does appear that the PLD as currently worded would expose European-based open source projects to product liability. I have to assume that this was an unintended consequence.
Proposed Enhancements
I hypothesize that when some people think of open source software components and the open source supply chain, they think of something like a braking system module that is assembled into a passenger car. After all, terminology like “component” and “supply chain” lends itself perfectly to that interpretation. I believe that a closer analogy would be inputs to a chemical process. Don’t think of a “braking component”, think acetate or sulphuric acid. I think this analogy is correct because beyond the sheer malleability of software, it is important to recall that open source software is by definition not restricted to any field of use. Every piece of open source software can (and is) used for any purpose that anyone can find for it. To give just one example, the Eclipse IDE platform was designed to implement desktop developer tools. But over the years it has ended up being used in scientific instruments on the International Space Station, to control medical imaging devices, mission planning for the Mars Rover, operations control of major railway networks, and ground station control software for space satellites. The adopters of open source have rich imaginations indeed.
The point of the above is that it is essential that open source software be excluded from the strict, no-fault liability obligations of the PLD. Not because open source developers are entitled to special treatment, but because the liability truly rests with the organization that placed the open source software into a product, and placed that product into the hands of a consumer. It is the act of using open source software that makes it critical, not the act of publishing or distributing it.
To that end, I feel that the correct enhancement is to strengthen the exclusion of open source in the PLD to make it much clearer than it currently is.
The Gory Details
For those who want to look into the language of the PLD, here are what I noticed as the relevant sections and what they mean. (Emphasis added by me in a few places.)
- (12) Products in the digital age can be tangible or intangible. Software, such as operating systems, firmware, computer programs, applications or AI systems, is increasingly common on the market and plays an increasingly important role for product safety. Software is capable of being placed on the market as a standalone product and may subsequently be integrated into other products as a component, and is capable of causing damage through its execution. In the interest of legal certainty it should therefore be clarified that software is a product for the purposes of applying no-fault liability, irrespective of the mode of its supply or usage, and therefore irrespective of whether the software is stored on a device or accessed through cloud technologies. The source code of software, however, is not to be considered as a product for the purposes of this Directive as this is pure information. The developer or producer of software, including AI system providers within the meaning of [Regulation (EU) …/… (AI Act)], should be treated as a manufacturer.
So Recital 12 makes it clear that software is a product under the PLD and that the developer is the manufacturer.
- (13) In order not to hamper innovation or research, this Directive should not apply to free and open-source software developed or supplied outside the course of a commercial activity. This is in particular the case for software, including its source code and modified versions, that is openly shared and freely accessible, usable, modifiable and redistributable. However where software is supplied in exchange for a price or personal data is used other than exclusively for improving the security, compatibility or interoperability of the software, and is therefore supplied in the course of a commercial activity, the Directive should apply.
Recital 13 provides a carve out for open source. However, it retains the same fatal flaw as the CRA in that the carve out applies only to “software developed or supplied outside the course of a commercial activity”, which is woefully misplaced if it is intended to provide any protection of the open source ecosystem from the scope of this legislation. To see why, please see Maarten Aertsen’s blog post.
- (23) In order to reflect the increasing prevalence of inter-connected products, the assessment of a product’s safety should also take into account the effects of other products on the product in question. The effect on a product’s safety of its ability to learn after deployment should also be taken into account, to reflect the legitimate expectation that a product’s software and underlying algorithms are designed in such a way as to prevent hazardous product behaviour. In order to reflect that in the digital age many products remain within the manufacturer’s control beyond the moment at which they are placed on the market, the moment in time at which a product leaves the manufacturer’s control should also be taken into account in the assessment of a product’s safety. A product can also be found to be defective on account of its cybersecurity vulnerability.
Recital 23 makes it clear that a cybersecurity vulnerability can be considered a product defect, and hence explicitly incur liability.
- (26) The protection of the consumer requires that any manufacturer involved in the production process can be made liable, in so far as their product or a component supplied by them is defective. Where a manufacturer integrates a defective component from another manufacturer into a product, an injured person should be able to seek compensation for the same damage from either the manufacturer of the product or from the manufacturer of the component.
Recital 26 makes it clear that if an open source component is integrated into a product, and that open source component is found to be defective, the developer of that open source component may be liable.
- (38) The possibility for economic operators to avoid liability by proving that a defect came into being after they placed the product on the market or put it into service should also be restricted when a product’s defectiveness consists in the lack of software updates or upgrades necessary to address cybersecurity vulnerabilities and maintain the product’s safety. Such vulnerabilities can affect the product in such a way that it causes damage within the meaning of this Directive. In recognition of manufacturers’ responsibilities under Union law for the safety of products throughout their lifecycle, such as under Regulation (EU) 2017/745 of the European Parliament and of the Council, manufacturers should also be liable for damage caused by their failure to supply software security updates or upgrades that are necessary to address the product’s vulnerabilities in response to evolving cybersecurity risks. Such liability should not apply where the supply or installation of such software is beyond the manufacturer’s control, for example where the owner of the product does not install an update or upgrade supplied for the purpose of ensuring or maintaining the level of safety of the product.
Recital 38 makes it clear that a failure to properly update a product to protect any security vulnerabilities is considered a defect and incur liability on the part of the manufacturer.
- (40) Situations may arise in which two or more parties are liable for the same damage, in particular where a defective component is integrated into a product that causes damage. In such a case, the injured person should be able to seek compensation both from the manufacturer that integrated the defective component into its product and from the manufacturer of the defective component itself. In order to ensure consumer protection, all parties should be held liable jointly and severally in such situations.
Recital 40 makes it clear that the manufacturer of a defective component is liable to the consumer, as well as the manufacturer of the end product.
- (42) The objective of consumer protection would be undermined if it were possible to limit or exclude an economic operator’s liability through contractual provisions. Therefore no contractual derogations should be permitted. For the same reason, it should not be possible for provisions of national law to limit or exclude liability, such as by setting financial ceilings on an economic operator’s liability.
Recital 42 makes it clear that the limitations of liability and no warranty clauses in open source licenses are superseded by the PLD.
