Product Liability Directive and Software Updates of Automated Vehicles

Abstract

The EU Product Liability Directive (Directive 85/374/EEC - PLD) provides for strict liability of producers for defective products. This paper examines its applicability de lege lata and de lege ferenda to software updates of automated vehicles. It is concluded that to regard software updates as 'products' under the PLD entails many legal and practical challenges. These relate to the notion of 'product', the time that the update is put into circulation, the notion of 'defect', the burden of proof especially as to causation, and the calculation of time bars. Applying the PLD to software updates seems to create more problems than the ones the Directive is meant to solve. Therefore, it is submitted that the PLD is inapplicable both de lege lata and de legel ferenda to software updates. It is simpler and more logical to consider software updates of automated vehicles as a maintenance service.

-

Automated vehicles (AV) are most probably the future of the car industry and driving. They are expected to dramatically decrease accidents and make roads safer, given that 94% of grave accidents are due to human error, while at the same time significantly reduce traffic congestion, driving down costs and CO2 emissions [ 1 ].

AV are the result of combining and integrating multiple sensors into a single system, which helps the vehicle adjust its road behaviour to the environment in which it is moving [ 2 ]. They combine sensors and software to control, navigate, and drive the vehicle [ 3 ]. There are six levels of automation ranging from L0 (no automation at all) to L5 (full self-driving capacity) [ 4 ]. Currently there are mainly L2 vehicles in operation, which enable only partial automation in strictly defined conditions, while the driver retains control of the vehicle for most of the time. L5 vehicles are not expected to become operational in the near future. AV of L2 and higher employ AI systems, which result in gradual modification of these systems in a way that cannot be predicted in advance. 2

General Characteristics of the PLD

According to recitals (2) and (7) of the PLD, the objective of the PLD is the fair apportionment of the risks inherent in modern technological production. It is a full-harmonization directive, which means that EU member States are not allowed to establish more victim-friendly provisions on strict liability for defective products.

3 ‘Product’

The PLD applies to ‘products’, which it defines as mainly tangible, movable objects. ‘Products’ are distinguished from ‘services’, which are not covered by the Directive [ 7 ].

It is disputed whether software is covered by the PLD. Various views have been suggested, but we will mention here only the most wide-spread. The rather prevailing view is that software is covered, as long as it is embedded into a tangible object [ 8, 9 ]. Another view holds that bespoke or custom-made software is not covered, since the PLD aims at regulating mass-produced items [ 10 ]. Both views have been criticised as arbitrary and reflecting outdated concepts, unsuitable for modern needs [ 11 ]. Especially considering devices that operate on cloud-based software, these distinctions make little sense, if at all [ 12 ]. Nevertheless, under both distinctions, it appears that software used for the operation of an AV would be considered a ‘product’ under the PLD.

Things become more complicated as to updates of software. There are two main options here. One would be to think that a software update remains a piece of software and if software is covered, then so are its updates; this option would deem every piece of update as a separate ‘product’. The other option would be to consider software updates as services to the basic software, i.e. a kind of maintenance of the basic software, which enables its unproblematic function in the future; in this respect, software updates are not a ‘product’.

There is also an intermediate option, according to which there must be a distinction between software updates, which are services, and software upgrades, which are separate ‘products’; the difference being that upgrades add functionalities to the previous software versions [ 13 ]. A similar distinction would be the necessity of regulatory approvals: motor vehicles and their components are subject to safety approvals, including any important alterations to their original form [ 14 ]. If a regulatory approval is needed following a modification of the software used in the vehicle, then such modification would amount to a new ‘product’.

To consider software updates as ‘products’ would face serious practical difficulties, because updates are designed to merge and interact with the rest of the software, operating as a whole with it. Thus, it may be challenging to distinguish the update from the rest of the software. The distinction between updates and upgrades makes more sense. However, it risks permitting the software developer to determine at will whether it will be subject to the Directive’s ambit or not, by characterizing a piece of software as an update or an upgrade. The criterion of functionality may not always be easy to implement, because minor functionalities may be added as part of an update too. The question will then be what is a ‘minor’ and what is a ‘major’ functionality. Such definitional challenges create legal uncertainty.

In addition, updates are often transmitted wirelessly to the AV system [ 5 ]. In such cases, the requirement of incorporation into a tangible object will not be fulfilled.

Therefore, it will be preferable to consider updates as a category of maintenance service, lying outside the Directive’s scope.

Nevertheless, to finally decide which option is more appropriate, we have to first examine the rest of the PLD’s provisions, which interact with the notion of ‘product’. In the course of such examination, we will deem, for the sake of argument, software updates as a separate ‘product’.

4 ‘Producer’

Art. 3(1) PLD includes in the definition of ‘producers’ the manufacturer of the end product, the component manufacturer, the producer of any raw material, as well as any persons who, by putting their name, trade mark or other distinguishing feature on products present themselves as their producers. Furthermore, the importer of the product in the EU is also deemed a ‘producer’ [Art. 3(2) PLD].

Where the producer of the product cannot be identified, each supplier of the product is treated as its producer, unless it informs the injured person, within a reasonable time, of the identity of the producer or of the person who supplied it with the product. The same applies, in the case of an imported product, if this product does not indicate the identity of the importer referred to in Art. 3(2) PLD, even if the name of the producer is indicated [Art. 3(3) PLD]. Suppliers, against whom proceedings are brought by an injured person, has to inform the latter, on their own initiative and promptly, of the identity of the producer or their own supplier – a mere denial of suppliers that they are not the producer is insufficient.

All these persons may be held jointly and severally liable (Art. 5 PLD).

Regarding software updates, the manufacturer of the vehicle will be a producer as to the software incorporated in the vehicle, even if it has been developed by a third party, which will be also a ‘producer’. AV importers will also be liable, potentially car sellers too. Hence, all these persons could be liable in the case of a software update.

However, for software updates developed by third parties and installed by the user, it is highly doubtful whether the producer of the AV and the developer of the basic software are liable de lege lata, or should be liable de lege ferenda. The answer thereto depends on what is exactly a ‘product’ and when it is put into circulation. If each piece of software update is a separate product, then its developer is liable since its release. If such developer is other than the original producer of the AV or the basic AV software, then the latter would not be liable. The rationale for the liability of the end-product producer for defects of components is that the end product incorporates all components, under the supervision and responsibility of that producer. In case of software updates developed by third parties, such rationale is no longer valid.

As a result, odd results may be caused as to the notion of ‘producer’ of software updates. 5

Time of Placement into Circulation

Art. 7(b) PLD entails that liability is imposed only for defects that existed at the time the product was put into circulation. A product is put into circulation when it is taken out of the manufacturing process operated by the producer and enters a marketing process in the form in which it is offered to the public in order to be used or consumed [ 15 ].

Software updates are put into circulation at the time of their release. However, their release most often occurs after the AV and its operating software have been put into circulation. Unless we consider the software update a sperate ‘product’, there will be no liability for software updates.

However, the extension of liability combined with the strict nature of such liability risks creating a serious counter-incentive for producers to release updates, which could render AV quickly obsolete and thus undermine the promise of enhanced safety that these vehicles are supposed to bring. The same goes for security updates. As a result, to consider a software update as a distinct ‘product’ may have an adverse impact on safety and security.

6 ‘Defect’

6.1 PLD Provisions

According to Art. 6(1) PLD, a product is ‘defective’, when it does not provide the safety which a person is entitled to expect, taking all circumstances into account, including (a) the presentation of the product, (b) the use to which it could reasonably be expected that the product would be put, (c) the time when the product was put into circulation. As already mentioned, the time that the product was put into circulation is critical, since ‘producers’ are only liable for defects that existed at that time. Hence, the PLD lays down no duty to warn on dangers after the product has been put into circulation or to recall defective products.

Recital (6) PLD clarifies that the defectiveness of the product is determined by reference to the lack of the safety which the public at large is entitled to expect. Therefore, the safety-expectations are determined objectively, which means that reference is not made to the expectations of the specific user [ 16 ]. In addition, the PLD establishes a duty to put into circulation products that are reasonably safe, taking into account all the circumstances – not products that are absolutely safe [ 17 ]. In this regard, some national courts have referred to a risk-benefit analysis of the product’s characteristics, taking into account the kind and the extent of the risks connected to the use of the product, the possibility that such risks materialize, the cost of additional safety measures and the benefits from the use of the product [ 16, 18 ]. Nonetheless, the compatibility of the risk-utility test with the Directive’s liability system is disputed [ 12 ].

At the same time, recital (6) PLD makes clear that safety is assessed by excluding any misuse of the product not reasonable under the circumstances. Consequently, the reasonable safety expectations of the user encompass cases of foreseeable product misuse. Producers must consider foreseeable product misuse both when designing the product and when issuing instructions and warnings [ 9, 19 ].

Moreover, the CJEU has ruled in the Boston Scientific Medizintechnik case that, where it is found that products belonging to the same group or forming part of the same production series have a potential defect, an individual product of such series may be classified as defective without there being any need to establish that this product has such a defect [ 20 ].

6.2 Consequences for software updates

Applying these principles to software updates is challenging. Updates form part of a wider system of systems, i.e. they are part of the basic software, which is part of the AV. Identifying the reasonable user expectations as to updates themselves may be hardly possible, given the highly complex nature of software used in AV and its interaction with other pieces of software, including other updates. Besides, users may often be unaware of the updates installed in their system.

Nevertheless, two main indications could be used. First, any documentation accompanying the release of the update, such as release notes, instructions and warnings - although these may be hardly understandable to the average users to shape their expectations. Second, any problems experienced by users or vulnerabilities identified by third parties and made public, which users would reasonably expect to be remedied. In this respect, there is an interesting interaction between safety expectations of users and the risk-utility test. The safety expectations may not be able to be met under a risk-utility analysis. One could argue that, in such cases, the expectations of the users would not be reasonable. Nevertheless, this may not always be valid. For example, there may be a major security vulnerability, which would be reasonable to expect to be fixed as soon as possible; yet fixing such vulnerability may not be possible, without affecting other functionalities of the basic software.

Things get more complicated, if we consider the evolving behaviour of AV in view of their self-learning abilities. Each AV may exhibit different behaviour under similar circumstances, so that different users may have different expectations based on their experience. In addition, such differences may render inappropriate the application of the CJEU’s ruling on the Boston Scientific Medizintechnik case [ 20 ]. 7 ‘Damage’ ‘Damage’ is defined in Art. 9 PLD. It includes physical injury and property damage. Nevertheless, the latter is actionable only under certain requirements: no damage to the defective product itself is covered, while damage to other property items requires that (a) the damage exceeds 500€, (b) the damaged item is of a type ordinarily intended for private use or consumption, and (c) the item was used by the injured person mainly for his/her own private use or consumption. Non-material damages can be awarded according to the applicable national provisions.

A first major challenge is to identify what would be damage to the defective product itself, which is not covered. The distinction between the component and the product is highly disputed in cases of complex products [ 10 ]. It is unclear whether this would cover the basic software and the AV as such. It appears reasonable to deem that the defective update and the basic software are one ‘product’, but things are less clear as to the AV as such. It can be argued that since software is an integral part of the AV, the update, the software and the AV are the same ‘product’. The opposing view would be that software could be uninstalled and re-installed just like e.g. a defective tire, so that there are two distinct products.

Another question is whether data are ‘property items’. One might argue that a ‘property item’ refers only to tangible products and data are intangible. However, it would be more correct to interpret the term widely. A property item is any piece of property that has monetary value as such, irrespective of its tangibility. In modern economy, there can be no doubt that data as such have value, given that they are the object of distinct economic transactions. Besides, traditional property items, such as vinyl discs and CDs, have been digitalized and are sold online as if they were tangible objects.

Third, it is to be examined whether damage related to personal data is covered, e.g. a security flaw in a piece of software leads to loss or theft of personal data of the driver, stored in his/her mobile phone, which is connected to the infotainment system of the AV. One might argue that personal data protection is regulated exclusively in the General Data Protection Regulation (GDPR) [ 21 ]. However, the GDPR applies to the processing of personal data [Art. 2(1) GDPR] and regulates the liability of the controller and the processor of personal data (Art. 82 GDPR). The software developer may not qualify as a controller or processor, as it may not be involved in any processing of personal data. In such cases the GDPR will be inapplicable. But even if the GPDR is applicable, there is nothing indicating that it constitutes an exclusive remedy – on the contrary, there are significant indications that the GDPR does not regulate exclusively issues of personal data, e.g. the wording of Arts 77(1), 78(1) and 79(1) “without prejudice to any available administrative or non-judicial remedy”. At the same time however, it is doubtful whether loss or theft of personal data is damage to ‘a property item’ or ‘physical injury’. It would be more appropriate to consider such cases as an infringement of personality, for which non-material damage under the applicable national law is due, per Art. 9 PLD. 8

Defenses

In the cases of software updates, the most significant defences under the PLD are that the defect did not exist when the product was put into circulation [Art. 7(b)], that the state of scientific and technical knowledge at the time when he put the product into circulation was not such as to enable the existence of the defect to be discovered [state of the art defence - Art. 7(e)] and that there was contributory negligence of the user [Art. 8(2)].

The ECJ has clarified that Article 7(e) is not specifically directed at the practices and safety standards in use in the industrial sector in which the producer is operating, but, unreservedly, at the state of scientific and technical knowledge, including the most advanced level of such knowledge, at the time when the product in question was put into circulation [ 22 ]. Second, this defence is judged objectively, taking into account the state of knowledge of which the producer is presumed to have been informed. Nevertheless, it is implicit in the wording of Article 7(e) that the relevant scientific and technical knowledge must have been accessible at the time when the product in question was put into circulation. Therefore, in order to have a defence under Article 7(e) PLD, the producer of a defective product must prove either that the objective state of scientific and technical knowledge, including the most advanced level of such knowledge at the time when the product in question was put into circulation did not enable the discovery of the defect; or that such knowledge was not accessible at the time when the product in question was put into circulation. Concerning software updates, the developer/ producer would have to prove that the defect was not discoverable at all, at the time of the update release. Impracticability of being discovered, e.g. due to the complexity of the software code, will not suffice. Thus, the occasions of successful invoking the defence will be rather rare.

As to the user’s contributory negligence, it may relate to inappropriate installation, e.g. installation while the vehicle is in motion, while the producer warns that the vehicle must not be, inappropriate settings or even installation of third-party software that is incompatible with the installed update. 9

Burden of Proof

The injured person is required to prove the damage, the defect and the causal link between defect and damage (Art. 4).

According to the CJEU [ 23 ], under the principle of procedural autonomy and subject to the principles of equivalency and effectiveness, evidentiary issues are governed by the national law of each MS. The CJEU underlines the principle of effectiveness, which requires that national procedural rules do not render practically impossible or excessively difficult the exercise of rights conferred by EU law. Yet, such rules must not undermine the apportionment of the burden of proof established in the PLD. Thus, circumstantial evidence may be allowed in certain cases, to establish such relationship, and alleviate the plaintiff’s burden of proof. However, this is allowed only on a case-by-case basis and provided that the burden of proof is not practically reversed. It would be a violation of the Directive’s rules, if a presumption of a causal link could be automatically created when specific facts, pre-identified by the legislature or supreme judicial body, are proven.

The provisions of the PLD on the burden of proof have received criticism as being excessive for claimants, especially in cases of complex products. However, such difficulties have been mitigated mainly by the practice of courts in many MS by granting evidentiary facilitations under specific circumstances [ 24 ]. 10

Time Bars

Concerning time bars, the PLD establishes a limitation period of three years from the day on which the plaintiff became aware, or should reasonably have become aware, of the damage, the defect and the identity of the producer [Art. 10(1)]. In any case, the producer’s liability is extinguished upon the expiry of a 10-year period from the date on which the producer put into circulation the actual product which caused the damage, unless the injured person has in the meantime instituted proceedings against the producer (Art. 11).

The 10-year period is mainly justified by the fact that strict liability puts a higher burden on producers than fault-based liability; therefore, the liability period is limited in order not to discourage technological innovation and to allow insurance cover [ 24 ]. Nevertheless, it has been criticized as too short for some categories of products [ 9 ], to which AV could be added. In the long-run, the 10-year limitation period entails that manufacturers will not be liable for defects of older vehicle models.

If software updates are deemed separate products, then there will be a separate ten-year period running for each one of them. Whether this would lead to an extension of the liability of the end manufacturer or at least the developer of the basic software is uncertain. Should software updates have been developed by third parties, the answer appears to be rather negative. Yet, things are less clear if the updates come from the manufacturer itself or entities cooperating with it. Besides, to distinguish cases of thirdparty developers would be fair from one aspect, but could incentivize producers to outsource production and release of updates to escape liability.

Conclusion

To regard software updates as ‘products’ under the PLD entails many legal and practical challenges. They relate to the notion of ‘product’, the time of placement into circulation, the notion of ‘defect’, the burden of proof especially as to causation and the calculation of time bars. Applying the Directive to software updates seems to create more problems than solutions.

Therefore, it is submitted that the PLD is inapplicable both de lege lata and de lege ferenda to software updates. It is simpler and more logical to consider software updates of automated vehicles as a maintenance service.

References

[1] NHTSA. Automated vehicles for safety . Retrieved November 16 , 2020 from https://www.nhtsa.gov/technology-innovation/automated-vehicles-safety.

[2] Christian Gilbertsen . 2017 . Here's how the sensors in autonomous cars work (March 27, 2017 ). Retrieved November 16 , 2020 from http://www.thedrive.com/tech/8657/heres -how-the-sensors-in-autonomouscars-work.

[3] Union of Concerned Scientists . 2017 . Self-Driving Cars Explained (January 26, 2017 ). Retrieved November 16 , 2020 from https://www.ucsusa.org/cleanvehicles/how -self-driving-cars-work# . W2xOmSQzapo

[4] SAE International . 2018 . Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles . Retrieved November 16 , 2020 from https://www.sae.org/standards/content/j3016_ 201806 /.

[5] Tesla . Software updates . Retrieved November 16 , 2020 from https://www.tesla.com/support/software-updates

[6] Council Directive 85 /374/EEC of 25 July 1985 on the approximation of the laws, regulations and administrative provisions of the Member States concerning liability for defective products , OJ L 210 7 Aug . 1985 , pp. 29 - 33 .

[7] CJEU, judgment of 21 December 2011 , case C- 495 /10 Dutrueux and Caisse primaire d'assurance maladie du Jura , ECLI:EU:C: 2011 : 869 .

[8] Martina Barbero et al. 2018 . Study on emerging issues of data ownership, interoperability, (re-)usability and access to data, and liability, Final Report prepared for the European Commission by Deloitte et al ., Retrieved November 16 , 2020 from https://ec.europa. eu/digital-single-market/en/news/studyemerging-issues-data-ownership-interoperability-re-usability-and-accessdata-and .

[9] Peter Rott . 2018 . Rechtspolitischer Handlungsbedarf im Haftungsrecht, insbesondere für digitale Anwendungen . Retrieved November 16 , 2020 from https://www.vzbv.de/sites/default/files/downloads/2018/05/04/gutachten_han dlungsbedarf_im_haftungsrecht.pdf.

[10] Duncan Fairgrieve and Richard Goldberg. 2020 . Product Liability, 3rd ed., Oxford University Press, Oxford.

[11] Beta Computers (Europe) Ltd v Adobe Systems (Europe) Ltd , 1996 S.C.L.R. 587 , 594 per Lord Penrose .

[12] Minutes of Meeting of the Expert Group on "Liability and New Technologies - Product Liability Formation . 2018 (September 18 , 2018 ). Retrieved November 16 , 2020 from https://ec.europa.eu/transparency/regexpert/index.cfm?do=groupDetail.group MeetingDoc&docid= 24945 .

[13] Minutes of Meeting of the Expert Group on "Liability and New Technologies - Product Liability Formation . 2019 (February 18 , 2019 ). Retrieved November 16 , 2020 from https://ec.europa.eu/transparency/regexpert/index.cfm?do=groupDetail.group MeetingDoc&docid= 31014

[14] Regulation (EU) 2018 / 858 of the European Parliament and of the Council of 30 May 2018 on the approval and market surveillance of motor vehicles and their trailers, and of systems, components and separate technical units intended for such vehicles , OJ L 151/1.

[15] CJEU , Judgment of 9 Febr . 2006 , C- 127 /04 O' Byrne, ECLI :EU:C: 2006 : 93 .

[16] Bundesgerichtshof , judgment of 16 June 2009 (Airbag), NJW 2009 , 2952 (Ger.).

[17] Rachel Mulheron . 2016 . Principles of Tort Law, Defective Products - Online Content , Oxford University Press, Oxford. Retrieved November 16 , 2020 from https://www.cambridge.org/files/6614/7610/6091/Defective_products_Mulhero n.pdf.

[18] Wilkes v DePuy International Limited [2016] EWHC 3096 (Eng .).

[19] Martin Ebers . 2017 . Autonomes Fahren: Produkt und Produzentenhaftung . In: Autonomes Fahren Bernd H. Oppermann and Jutta Stender-Vorwachs (Eds). C.H.Beck , Munich, 93 - 125 .

[20] CJEU judgment of 5 March 2015 , joined Cases C- 503 /13 and C- 504 /13 Boston Scientific Medizintechnik GmbH, ECLI:EU:C: 2015 : 148 .

[21] Regulation (EU) 2016 / 679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data , and repealing Directive 95 /46/EC ( General Data Protection Regulation) , OJ L 119 , 4 .5. 2016 , pp. 1 - 88 .

[22] ECJ judgment of 29 May 1997 , case C- 300 /95, Commission v UK, ECLI:EU:C: 1997 : 255 .

[23] CJEU judgment of 21 June 2017 , case C- 621 /15 - W and Others, ECLI:EU:C: 2017 : 484 .

[24] European Commission , Report from the Commission on the Application of Directive 85 /374 on Liability for Defective Products, COM ( 2000 ) 893 final ( 31 Jan . 2001 )