Product Liability Directive and Software Updates of Automated Vehicles Michael Chatzipanagiotis Department of Law University of Cyprus Nicosia, Cyprus mchatz07@ucy.ac.cy ABSTRACT Software is an integral part of AV and needs to be regularly updated, often via a wireless network (over-the-air/ OTA updates) The EU Product Liability Directive (Directive 85/374/EEC - PLD) [5]. However, software updates may also affect the safe and secure provides for strict liability of producers for defective products. functioning of the vehicle, which can result in personal injury and This paper examines its applicability de lege lata and de lege damage to property. ferenda to software updates of automated vehicles. It is concluded Hence, issues of product liability arise. We shall examine such that to regard software updates as ‘products’ under the PLD issues under the EU Product Liability Directive (PLD) [6]. 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 2 General Characteristics of the PLD causation, and the calculation of time bars. Applying the PLD to software updates seems to create more problems than the ones the According to recitals (2) and (7) of the PLD, the objective of the Directive is meant to solve. Therefore, it is submitted that the PLD PLD is the fair apportionment of the risks inherent in modern is inapplicable both de lege lata and de legel ferenda to software technological production. It is a full-harmonization directive, updates. It is simpler and more logical to consider software which means that EU member States are not allowed to establish updates of automated vehicles as a maintenance service. more victim-friendly provisions on strict liability for defective products. KEYWORDS 3 ‘Product’ Product Liability Directive, EU law, Automated vehicles, Liability, The PLD applies to ‘products’, which it defines as mainly tangible, Product Liability 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 1 Automated Vehicles views have been suggested, but we will mention here only the Automated vehicles (AV) are most probably the future of the car most wide-spread. The rather prevailing view is that software is industry and driving. They are expected to dramatically decrease covered, as long as it is embedded into a tangible object [8, 9]. accidents and make roads safer, given that 94% of grave accidents Another view holds that bespoke or custom-made software is not are due to human error, while at the same time significantly covered, since the PLD aims at regulating mass-produced items reduce traffic congestion, driving down costs and CO2 emissions [10]. Both views have been criticised as arbitrary and reflecting [1]. outdated concepts, unsuitable for modern needs [11]. Especially AV are the result of combining and integrating multiple considering devices that operate on cloud-based software, these sensors into a single system, which helps the vehicle adjust its distinctions make little sense, if at all [12]. Nevertheless, under road behaviour to the environment in which it is moving [2]. They both distinctions, it appears that software used for the operation combine sensors and software to control, navigate, and drive the of an AV would be considered a ‘product’ under the PLD. vehicle [3]. There are six levels of automation ranging from L0 (no Things become more complicated as to updates of software. automation at all) to L5 (full self-driving capacity) [4]. Currently There are two main options here. One would be to think that a there are mainly L2 vehicles in operation, which enable only software update remains a piece of software and if software is partial automation in strictly defined conditions, while the driver covered, then so are its updates; this option would deem every retains control of the vehicle for most of the time. L5 vehicles are piece of update as a separate ‘product’. The other option would be not expected to become operational in the near future. AV of L2 to consider software updates as services to the basic software, i.e. and higher employ AI systems, which result in gradual a kind of maintenance of the basic software, which enables its modification of these systems in a way that cannot be predicted unproblematic function in the future; in this respect, software in advance. updates are not a ‘product’. WAIEL2020, September 3, 2020, Athens, Greece Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). There is also an intermediate option, according to which there – a mere denial of suppliers that they are not the producer is must be a distinction between software updates, which are insufficient. services, and software upgrades, which are separate ‘products’; the All these persons may be held jointly and severally liable (Art. difference being that upgrades add functionalities to the previous 5 PLD). software versions [13]. A similar distinction would be the Regarding software updates, the manufacturer of the vehicle necessity of regulatory approvals: motor vehicles and their will be a producer as to the software incorporated in the vehicle, components are subject to safety approvals, including any even if it has been developed by a third party, which will be also important alterations to their original form [14]. If a regulatory a ‘producer’. AV importers will also be liable, potentially car approval is needed following a modification of the software used sellers too. Hence, all these persons could be liable in the case of in the vehicle, then such modification would amount to a new a software update. ‘product’. However, for software updates developed by third parties and To consider software updates as ‘products’ would face serious installed by the user, it is highly doubtful whether the producer of practical difficulties, because updates are designed to merge and the AV and the developer of the basic software are liable de lege interact with the rest of the software, operating as a whole with lata, or should be liable de lege ferenda. The answer thereto it. Thus, it may be challenging to distinguish the update from the depends on what is exactly a ‘product’ and when it is put into rest of the software. The distinction between updates and circulation. If each piece of software update is a separate product, upgrades makes more sense. However, it risks permitting the then its developer is liable since its release. If such developer is software developer to determine at will whether it will be subject other than the original producer of the AV or the basic AV to the Directive’s ambit or not, by characterizing a piece of software, then the latter would not be liable. The rationale for the software as an update or an upgrade. The criterion of functionality liability of the end-product producer for defects of components is may not always be easy to implement, because minor that the end product incorporates all components, under the functionalities may be added as part of an update too. The supervision and responsibility of that producer. In case of question will then be what is a ‘minor’ and what is a ‘major’ software updates developed by third parties, such rationale is no functionality. Such definitional challenges create legal longer valid. uncertainty. As a result, odd results may be caused as to the notion of In addition, updates are often transmitted wirelessly to the AV ‘producer’ of software updates. 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 5 Time of Placement into Circulation category of maintenance service, lying outside the Directive’s Art. 7(b) PLD entails that liability is imposed only for defects that scope. existed at the time the product was put into circulation. A product Nevertheless, to finally decide which option is more is put into circulation when it is taken out of the manufacturing appropriate, we have to first examine the rest of the PLD’s process operated by the producer and enters a marketing process provisions, which interact with the notion of ‘product’. In the in the form in which it is offered to the public in order to be used course of such examination, we will deem, for the sake of or consumed [15]. argument, software updates as a separate ‘product’. 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 4 ‘Producer’ consider the software update a sperate ‘product’, there will be no Art. 3(1) PLD includes in the definition of ‘producers’ the liability for software updates. manufacturer of the end product, the component manufacturer, However, the extension of liability combined with the strict the producer of any raw material, as well as any persons who, by nature of such liability risks creating a serious counter-incentive putting their name, trade mark or other distinguishing feature on for producers to release updates, which could render AV quickly products present themselves as their producers. Furthermore, the obsolete and thus undermine the promise of enhanced safety that importer of the product in the EU is also deemed a ‘producer’ [Art. these vehicles are supposed to bring. The same goes for security 3(2) PLD]. updates. As a result, to consider a software update as a distinct Where the producer of the product cannot be identified, each ‘product’ may have an adverse impact on safety and security. 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 6 ‘Defect’ same applies, in the case of an imported product, if this product does not indicate the identity of the importer referred to in Art. 6.1 PLD Provisions 3(2) PLD, even if the name of the producer is indicated [Art. 3(3) According to Art. 6(1) PLD, a product is ‘defective’, when it does PLD]. Suppliers, against whom proceedings are brought by an not provide the safety which a person is entitled to expect, taking injured person, has to inform the latter, on their own initiative all circumstances into account, including (a) the presentation of and promptly, of the identity of the producer or their own supplier 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 reasonable. Nevertheless, this may not always be valid. For put into circulation. As already mentioned, the time that the example, there may be a major security vulnerability, which product was put into circulation is critical, since ‘producers’ are would be reasonable to expect to be fixed as soon as possible; yet only liable for defects that existed at that time. Hence, the PLD fixing such vulnerability may not be possible, without affecting lays down no duty to warn on dangers after the product has been other functionalities of the basic software. put into circulation or to recall defective products. Things get more complicated, if we consider the evolving Recital (6) PLD clarifies that the defectiveness of the product is behaviour of AV in view of their self-learning abilities. Each AV determined by reference to the lack of the safety which the public may exhibit different behaviour under similar circumstances, so at large is entitled to expect. Therefore, the safety-expectations that different users may have different expectations based on their are determined objectively, which means that reference is not experience. In addition, such differences may render made to the expectations of the specific user [16]. In addition, the inappropriate the application of the CJEU’s ruling on the Boston PLD establishes a duty to put into circulation products that are Scientific Medizintechnik case [20]. 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 7 ‘Damage’ product’s characteristics, taking into account the kind and the ‘Damage’ is defined in Art. 9 PLD. It includes physical injury and extent of the risks connected to the use of the product, the property damage. Nevertheless, the latter is actionable only under possibility that such risks materialize, the cost of additional safety certain requirements: no damage to the defective product itself is measures and the benefits from the use of the product [16, 18]. covered, while damage to other property items requires that (a) Nonetheless, the compatibility of the risk-utility test with the the damage exceeds 500€, (b) the damaged item is of a type Directive’s liability system is disputed [12]. ordinarily intended for private use or consumption, and (c) the At the same time, recital (6) PLD makes clear that safety is item was used by the injured person mainly for his/her own assessed by excluding any misuse of the product not reasonable private use or consumption. Non-material damages can be under the circumstances. Consequently, the reasonable safety awarded according to the applicable national provisions. expectations of the user encompass cases of foreseeable product A first major challenge is to identify what would be damage to misuse. Producers must consider foreseeable product misuse both the defective product itself, which is not covered. The distinction when designing the product and when issuing instructions and between the component and the product is highly disputed in warnings [9, 19]. cases of complex products [10]. It is unclear whether this would Moreover, the CJEU has ruled in the Boston Scientific cover the basic software and the AV as such. It appears reasonable Medizintechnik case that, where it is found that products to deem that the defective update and the basic software are one belonging to the same group or forming part of the same ‘product’, but things are less clear as to the AV as such. It can be production series have a potential defect, an individual product of argued that since software is an integral part of the AV, the such series may be classified as defective without there being any update, the software and the AV are the same ‘product’. The need to establish that this product has such a defect [20]. 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. 6.2 Consequences for software updates Another question is whether data are ‘property items’. One Applying these principles to software updates is challenging. might argue that a ‘property item’ refers only to tangible products Updates form part of a wider system of systems, i.e. they are part and data are intangible. However, it would be more correct to of the basic software, which is part of the AV. Identifying the interpret the term widely. A property item is any piece of property reasonable user expectations as to updates themselves may be that has monetary value as such, irrespective of its tangibility. In hardly possible, given the highly complex nature of software used modern economy, there can be no doubt that data as such have in AV and its interaction with other pieces of software, including value, given that they are the object of distinct economic other updates. Besides, users may often be unaware of the updates transactions. Besides, traditional property items, such as vinyl installed in their system. discs and CDs, have been digitalized and are sold online as if they Nevertheless, two main indications could be used. First, any were tangible objects. documentation accompanying the release of the update, such as Third, it is to be examined whether damage related to personal release notes, instructions and warnings - although these may be data is covered, e.g. a security flaw in a piece of software leads to hardly understandable to the average users to shape their loss or theft of personal data of the driver, stored in his/her mobile expectations. Second, any problems experienced by users or phone, which is connected to the infotainment system of the AV. vulnerabilities identified by third parties and made public, which One might argue that personal data protection is regulated users would reasonably expect to be remedied. In this respect, exclusively in the General Data Protection Regulation (GDPR) there is an interesting interaction between safety expectations of [21]. However, the GDPR applies to the processing of personal users and the risk-utility test. The safety expectations may not be data [Art. 2(1) GDPR] and regulates the liability of the controller able to be met under a risk-utility analysis. One could argue that, and the processor of personal data (Art. 82 GDPR). The software in such cases, the expectations of the users would not be developer may not qualify as a controller or processor, as it may not be involved in any processing of personal data. In such cases According to the CJEU [23], under the principle of procedural the GDPR will be inapplicable. But even if the GPDR is applicable, autonomy and subject to the principles of equivalency and there is nothing indicating that it constitutes an exclusive remedy effectiveness, evidentiary issues are governed by the national law – on the contrary, there are significant indications that the GDPR of each MS. The CJEU underlines the principle of effectiveness, does not regulate exclusively issues of personal data, e.g. the which requires that national procedural rules do not render wording of Arts 77(1), 78(1) and 79(1) “without prejudice to any practically impossible or excessively difficult the exercise of rights available administrative or non-judicial remedy”. At the same conferred by EU law. Yet, such rules must not undermine the time however, it is doubtful whether loss or theft of personal data apportionment of the burden of proof established in the is damage to ‘a property item’ or ‘physical injury’. It would be PLD. Thus, circumstantial evidence may be allowed in certain more appropriate to consider such cases as an infringement of cases, to establish such relationship, and alleviate the plaintiff’s personality, for which non-material damage under the applicable burden of proof. However, this is allowed only on a case-by-case national law is due, per Art. 9 PLD. 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 8 Defenses specific facts, pre-identified by the legislature or supreme judicial In the cases of software updates, the most significant defences body, are proven. under the PLD are that the defect did not exist when the product The provisions of the PLD on the burden of proof have was put into circulation [Art. 7(b)], that the state of scientific and received criticism as being excessive for claimants, especially in technical knowledge at the time when he put the product into cases of complex products. However, such difficulties have been circulation was not such as to enable the existence of the defect to mitigated mainly by the practice of courts in many MS by granting be discovered [state of the art defence - Art. 7(e)] and that there evidentiary facilitations under specific circumstances [24]. 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 10 Time Bars industrial sector in which the producer is operating, but, Concerning time bars, the PLD establishes a limitation period of unreservedly, at the state of scientific and technical knowledge, three years from the day on which the plaintiff became aware, or including the most advanced level of such knowledge, at the time should reasonably have become aware, of the damage, the defect when the product in question was put into circulation [22]. and the identity of the producer [Art. 10(1)]. In any case, the Second, this defence is judged objectively, taking into account the producer’s liability is extinguished upon the expiry of a 10-year state of knowledge of which the producer is presumed to have period from the date on which the producer put into circulation been informed. Nevertheless, it is implicit in the wording of the actual product which caused the damage, unless the injured Article 7(e) that the relevant scientific and technical knowledge person has in the meantime instituted proceedings against the must have been accessible at the time when the product in producer (Art. 11). question was put into circulation. Therefore, in order to have a The 10-year period is mainly justified by the fact that strict defence under Article 7(e) PLD, the producer of a defective liability puts a higher burden on producers than fault-based product must prove either that the objective state of scientific and liability; therefore, the liability period is limited in order not to technical knowledge, including the most advanced level of such discourage technological innovation and to allow insurance cover knowledge at the time when the product in question was put into [24]. Nevertheless, it has been criticized as too short for some circulation did not enable the discovery of the defect; or that such categories of products [9], to which AV could be added. In the knowledge was not accessible at the time when the product in long-run, the 10-year limitation period entails that manufacturers question was put into circulation. Concerning software updates, will not be liable for defects of older vehicle models. the developer/ producer would have to prove that the defect was If software updates are deemed separate products, then there not discoverable at all, at the time of the update release. will be a separate ten-year period running for each one of them. Impracticability of being discovered, e.g. due to the complexity of Whether this would lead to an extension of the liability of the end the software code, will not suffice. Thus, the occasions of manufacturer or at least the developer of the basic software is successful invoking the defence will be rather rare. uncertain. Should software updates have been developed by third As to the user’s contributory negligence, it may relate to parties, the answer appears to be rather negative. Yet, things are inappropriate installation, e.g. installation while the vehicle is in less clear if the updates come from the manufacturer itself or motion, while the producer warns that the vehicle must not be, entities cooperating with it. Besides, to distinguish cases of third- inappropriate settings or even installation of third-party software party developers would be fair from one aspect, but could that is incompatible with the installed update. incentivize producers to outsource production and release of updates to escape liability. 9 Burden of Proof The injured person is required to prove the damage, the defect and Conclusion the causal link between defect and damage (Art. 4). To regard software updates as ‘products’ under the PLD entails 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. many legal and practical challenges. They relate to the notion of [22] ECJ judgment of 29 May 1997, case C-300/95, Commission v UK, ‘product’, the time of placement into circulation, the notion of ECLI:EU:C:1997:255. ‘defect’, the burden of proof especially as to causation and the [23] CJEU judgment of 21 June 2017, case C-621/15 - W and Others, ECLI:EU:C:2017:484. calculation of time bars. Applying the Directive to software [24] European Commission, Report from the Commission on the Application of updates seems to create more problems than solutions. Directive 85/374 on Liability for Defective Products, COM (2000) 893 final (31 Jan. 2001) 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-autonomous- cars-work. [3] Union of Concerned Scientists. 2017. Self-Driving Cars Explained (January 26, 2017). Retrieved November 16, 2020 from https://www.ucsusa.org/clean- vehicles/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/study- emerging-issues-data-ownership-interoperability-re-usability-and-access- data-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