=Paper=
{{Paper
|id=Vol-2844/ethics5
|storemode=property
|title=Product Liability Directive and Software Updates of Automated Vehicles
|pdfUrl=https://ceur-ws.org/Vol-2844/ethics5.pdf
|volume=Vol-2844
|authors=Michael Chatzipanagiotis
|dblpUrl=https://dblp.org/rec/conf/setn/Chatzipanagiotis20
}}
==Product Liability Directive and Software Updates of Automated Vehicles==
https://ceur-ws.org/Vol-2844/ethics5.pdf
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