1 Satzfahne EuCML_2023_050501_1 30. 9. 2023
Guillem Izquierdo Grau*
An Appraisal of the Proposal for a Directive on Liability for Defective
Products
Some Considerations on the Liability of the Software or Artificial Intelligence System Developer
I. Introduction
On 28 September 2022, the European Commission published
the Proposal for a Directive on liability for defective prod-
ucts1 with the intention of replacing the long-standing Direc-
tive 85/374/EEC. The proposed Directive is therefore the
basic document that will be discussed in the European Parlia-
ment and the Council and which, within the next two years,
may result in the adoption of a new Directive on this matter.
Given the current wording, I expect that the text of the
Proposal for a Directive will be subject to significant modifi-
cations during the legislative procedure.
Without going into other new issues included in the Proposal
for a Directive, I can say that the adopted text follows guide-
lines that were already established by the European legislator
when Directive (EU) 2019/771 on certain aspects concerning
contracts for the sale of goods was adopted: the unitary
understanding of goods, and the concentration of liability, on
the producer of the good, albeit with some nuances that will
be addressed throughout the article.
This short contribution focuses on the proposed rules for
liability of online AI system and software developers. That
enquiry is important for two reasons. First, the Proposal for a
Directive broadens the group of parties who may be classed
as the producer, including the software programmer and the
AI system developer. Therefore, pursuant to this approach,
Art. 7 of the Proposal for a Directive recognises that the
victim of damage caused by a defective product can take
action against the producer of the component (see Recital no.
40 of the Proposal for a Directive) and not against the produ-
cer of the good as a whole, if the damage is attributable to
the software or the artificial intelligence system and if the
victim is able to identify it.
Second, this short contribution deals with free and open-
source software and algorithms supplied outside the course
of a commercial activity. The proposed Directive (Recital 13)
chooses to exclude from its scope damage caused by such
software or algorithms when they are not supplied in the
course of a commercial activity. However, where they are
supplied in exchange for a price or for data in the course of a
commercial activity, they will fall within the scope of the
proposed Directive. In order to prevent the former from fall-
ing outside the scope of the future Directive, it is proposed
that they should be considered as refurbished goods. Rema-
nufactured goods undergo preparation or modification to re-
store its performance or functionality within the intended
use, range of performance and maintenance originally con-
ceived at the design stage, or to meet applicable technical
standards or regulatory requirements, with the result of mak-
* Guillem Izquierdo Grau is a Lecturer at the Autonomous University of
Barcelona; e-mail: guillem.izquierdo@uab.cat. This article is published
within the framework of the R&D&I project Conducción autónoma y
seguridad jurídica del transporte/Autonomous Driving and legal cer-
tainty of transport. PI: Eliseo Sierra Noguero.
1 Commission, ‘Proposal for a Directive of the European Parliament and
of the Council on Liability for Defective Products’, COM (2022) 495
final 2022/0302 (COD).
Satzspiegelhöhe: 257.5mm
Höhe der ges. Fahne 2493mm
2 Satzfahne EuCML_2023_050501_1 30. 9. 2023
ing a fully functional product. Therefore, to the extent that
open-source software are freely accessible can alter the prop-
erties of a product, such software could fall within the scope
of the forthcoming directive if it is embedded in a product.
II. Related Products, Components and Services
1. The Concept of Product. The Artificial Intelligence
and Software Can be Considered as Products?
The main reason why it is necessary to adopt a new directive
in this area is the need to adapt the new regulation to the
complex nature of the products that have irrupted onto the
market: the so-called goods with digital elements that can
include AI systems. The distinctive feature of goods of this
type is that, on the one hand, we can distinguish between
tangible movable goods (hardware) and, on the other hand,
digital elements (content and services).2 Moreover, in the
digital era not all products are tangible, as digital products or
services (operating systems, computer programs, applications
or AI systems) have been introduced onto the market which
are not necessarily incorporated within a tangible movable
good but which can be downloaded and subsequently incor-
porated into products, outside of the producer’s control (Re-
cital 12 of the Proposal for a Directive).
The problems of classifying goods of this type as a product as
defined by the still current Directive 85/374/EEC are well
known.3 This is why the proposed Directive aims to close the
existing doctrinal debate and include software and digital
services and content within the scope of application of the
future regulation. In this regard, Art. 4.1) of the proposed
Directive defines the concept of product as follows: “all
movables, even if integrated into another movable or into an
immovable. ‘Product’ includes electricity, digital manufactur-
ing files and software”.
The definition of ‘product’ in the proposed Directive is based
on the definition contained in Directive 85/374/EEC. The
core element of the new definition of product is the fact that
it is movable and may be integrated within another movable
or immovable good. Up until this point, the definition in the
proposed Directive contains nothing new. However, the defi-
nition then introduces two new concepts that did not exist in
the definition of product given by Directive 85/374/EEC, in
addition to electricity: digital manufacturing files or copies
(Recital 14 of the Proposal for a Directive) and software.
In my opinion, the definition of product included in the
Proposal for a Directive is confusing because, together with
movables, the definition includes certain types of good that
are intangible. It would have been desirable for the definition
to include, firstly, movables, regardless of whether or not
they contain digital elements, and, secondly, the digital ele-
ments themselves (digital content and services), highlighting
the need for these to be integrated within or interconnected
with tangible movable goods in a way that, without them,
the product could not perform its functions. Furthermore, in
order to build a coherent system that is aligned with the
Directives on non-conformity of goods and digital content or
services, i. e. the twin directives (EU) 2019/770 and 2019/
771, instead of referring to “software”, I believe it would be
2 See Art. 2.1) and 2) Directive (EU) 2019/770 of the European Parlia-
ment and of the Council of 20 May 2019 on certain aspects concerning
contracts for the supply of digital content and digital services [2019] OJ
L136/1 (hereinafter, DCD).
3 Expert Group on Liability and New Technologies – New Technologies
Formation, ‘Liability for Artificial Intelligence and other Emerging Digi-
tal Technologies’ (European Union 2019).
Satzspiegelhöhe: 257.5mm
Höhe der ges. Fahne 2493mm
3 Satzfahne EuCML_2023_050501_1 30. 9. 2023
desirable for reference to be made to digital services, and for
these to be defined by reference to the provisions of Directive
(EU) 2019/770. In this way, the use of the same concepts
would make the European legislation on contractual and
non-contractual liability more coherent.4
From the literal wording of Recital 12 of the Proposal for a
Directive on liability for defective products, it is also clear
that the AI system or algorithm is considered to be software
and, consequently, a product. Therefore, the European legis-
lator ends one of the most important debates5 generated by
Directive 85/374/EEC, which made no reference to this issue,
and the reform is therefore welcome. It is clear from Recital
12 of the Proposal for a Directive on liability for defective
products that the European Commission has in mind soft-
ware that may be initially integrated within products, or
separate software that is subsequently integrated into the
product. In other words, according to Recital 12 of the
Proposal for a Directive, software and AI systems may be
included within the scope of the proposed Directive depend-
ing on whether they are integrated into or interconnected
with products.
Recital 15 of the Proposal for a Directive refers to digital
services. We have already stated that the Proposal for a
Directive does not provide a definition of digital services and
we have taken the view that the future Directive should refer
to digital content or services by reference to the provisions of
Art. 2 DCD. According to the provisions of Recital 15 of the
Proposal for a Directive, in the case of digital services, the
criterion of integration in or interconnection with tangible
products is essential in order to apply the provisions of the
Proposal for a Directive to this type of product. Although
Recital 15 of the proposed Directive states that it should not
apply to digital services as such, it is necessary to extend its
effects to digital services when they are integrated in or inter-
connected with products in such a way that without them,
the product would not be able to perform its functions.
Therefore, in my opinion, the criterion of the integration or
interconnection of software and digital services with products
is decisive for the Proposal for a Directive to be applicable to
damage caused by intangible products.
2. Is Software Digital Content or a Digital Service?
Next, the Proposal for a Directive incorporates the definition
of a digital manufacturing file. This concept is explained in
Recital 14 of the Proposal for a Directive. It is clear from its
wording that the European legislator is referring to files con-
taining the information necessary to produce a tangible good
by means of a device such as a 3D printer. As mentioned in
the previous section, in my opinion, with regard to software,
it would have been more appropriate to define the concept of
product by reference to the provisions of Art. 2(1) and (2) of
Directive (EU) 2019/770, which define what should be un-
derstood by digital content or service. Likewise, the inclusion
of the digital manufacturing files for a movable good within
the concept of product (Recital 14 of the Proposal for a
Directive) leads us to think that perhaps the European legis-
lator also intends digital content to be considered as prod-
ucts, given the difficulties in differentiating between the con-
cepts of “digital content” and “digital service”.6 Therefore, if
4 In the same regard, see Ch Wendehorst, ‘Safety and Liability Related
Aspects of Software’ (European Commission 2021).
5 For all, see K Chagal-Feferkorn, ‘Am I an Algorithm or a Product?
When Products Liability Should Apply to Algorithmic Decision-Makers’
(2019) 30 Stanford Law & Policy Review 61.
6 L Mischau, ‘The Concept of Digital Content and Digital Services in
European Contract Law’ (2022) 11 EUCML 1.
Satzspiegelhöhe: 257.5mm
Höhe der ges. Fahne 2493mm
4 Satzfahne EuCML_2023_050501_1 30. 9. 2023
the legislator’s intention was to consider digital content as a
product, in my opinion it would be appropriate to revise the
current definition of product in the Proposal for a Directive
to include digital content, by reference to the provisions of
Art. 2.1 Directive (EU) 2019/770.
3. Is Software a Product, a Component or a Related
Service?
The Proposal for a Directive on liability for defective prod-
ucts then introduces two new definitions for components and
related services. Furthermore, in order to understand both
concepts, we must again refer to the provisions of Recital 15
of the Proposal for a Directive, which refers to digital services
as components and related services.
I regard the consideration of digital services as related com-
ponents or services to be consistent with the premise of the
Proposal for a Directive, which takes the definition of a
product as defined by Directive 85/374/EEC in the sense that
it recognises the characteristics of mobility and tangibility as
fundamental elements of the definition. However, this pre-
mise is at odds with the will to adapt product liability legisla-
tion to the new market situation in which goods with digital
elements have a growing presence. The importance of soft-
ware is now much greater than when Directive 85/374/EEC
was adopted, and I therefore believe that the consideration of
software as a related component or service should be aban-
doned in order to bring the text into line with the new reality7
and avoid interpreting components as an accessory to the
product as a whole, rather than viewing them as integral part
of the product in its entirety.
III. Liable economic operators
1. The Liability of the Producer. General Ideas
The Proposal for a Directive on liability for defective prod-
ucts states that its legal regime shall be applicable regardless
of the provisions of the Proposal for a Regulation on Artifi-
cial Intelligence.8 Therefore, I can deduce that the European
legislator wishes to regulate this area in its entirety without
reference to other European Union rules.
Article 7 of the Proposal for a Directive on liability for
defective products establishes the parties liable for damage
caused by defective products. From its literal wording, we
can ascertain the premises on which the provision is based.
Firstly, the Proposal for a Directive concentrates liability for
damage on the producer, in the same way as Directive 85/
374/EEC. Next, the provision stresses that when the damage
is caused by a defective component, the producer is liable for
such damage. This is a provision which has no clear prece-
dent in Directive 85/374/EEC9 and which is undoubtedly
consistent with the consideration of the supplier of the soft-
ware or AI system as the producer (Recital 12 of the Pro-
posed for a Directive).
Following the same scheme as Directive 85/374/EEC, Article
11 of the Proposal for a Directive establishes the joint and
several liability of the liable economic operators. The joint
7 M Navarro-Michel, ‘Vehículos automatizados y responsabilidad por
producto defectuoso’ (2020) 7 Revista de Derecho civil 5.
8 European Commission, ‘Proposal for a Regulation of the European
Parliament and of the Council laying down harmonised rules on artifi-
cial intelligence (Artificial Intelligence Act) and amending certain union
legislative acts’ COM (2021) 206 final 2021/0106 (COD).
9 Art. 3 of Directive 85/374/EEC also considers the manufacturer of a
component part to be a producer, but does not state that they are
responsible as in the Proposal for a Directive under consideration.
Satzspiegelhöhe: 257.5mm
Höhe der ges. Fahne 2493mm
5 Satzfahne EuCML_2023_050501_1 30. 9. 2023
and several liability of the actors involved is intended to make
it easier for the victim to make a liability claim, as they know
that by bringing a claim against any liable economic operator
as per Art. 7 of the Proposal for a Directive, they will not
incur in any procedural irregularities (the requirement of
passive joint litigation or lack of passive legitimation) and
that, if the other requirements are met (proof of damage,
product defect and causal link between the two), their claim
will be successful.
2. The Concept of Producer. Hardware Manufacturer
vs Software Manufacturer
A new feature of the Proposed for a Directive (Recital 12 in
fine) is the fact that is assigns the status of manufacturer to
the software or AI system developer, who is known as the
software manufacturer, as opposed to the manufacturer of
the tangible movable product in which the software can be
integrated, the so-called hardware manufacturer. Legal doc-
trine had called for the scope of subjects considered as manu-
facturers to be widened10, in line with the approach of con-
sidering software as a product in the light of the future
directive to be adopted on this matter.
Article 3 of Directive 85/374/EEC already considered the
manufacturer of a component or an integrated part as a
producer, but the Proposal for a Directive has clarified that
the software or AI system developer is a producer, given that,
as a software manufacturer, they were outside the scope of
application of Directive 85/374/EEC. This is a welcome clar-
ification and, therefore, by virtue of the principle of joint and
several liability still enshrined in Art. 11 of the Proposal for a
Directive, given the impossibility of determining which pro-
ducer is liable for the damage caused, the victim may bring
their claim against the software or AI system developer under
the future directive to be adopted on this matter.
3. The Joint and Several Liability of the AI System
Developer and the Producer of the Good
As noted above, the Proposal for a Directive merely states in
Recital 12 that the concept of producer includes the develo-
per of the software and of the AI system integrated in the
product. However, the articles of the proposed Directive
make no reference to the producer of the software beyond
the provision in the second paragraph of Art. 7.1, according
to which the manufacturer of a component is liable for the
damage caused.
The fact that the software or AI system developer is consid-
ered as a producer means they are included in the group of
subjects to whom the Proposal for a Directive on liability for
defective products, following the scheme of Directive 85/374/
EEC, allocates liability. In other words, for the European
legislator, to the extent that the software and the algorithm
are generally interconnected with or integrated into a prod-
uct, it means that the developer of the software and the
algorithm could have intervened in the manufacturing pro-
cess of the good. I consider the fact of the integration or
interconnection of the software to be highly relevant, since
regardless of the contractual relationship between the hard-
ware manufacturer and the software manufacturer, the par-
10 S Navas Navarro, ‘Robot Machines and Civil Liability’ in M Ebers and
S Navas Navarro (eds), Algorithms and Law (Cambridge University
Press 2020); H Eidenmüller, ‘The Rise of Robots and the Law of Hu-
mans’ in H Eidenmüller and G Wagner (eds), Law by Algorithm (Mohr
Siebeck 2021); G Wagner, ‘Robot Liability’ in H Eidenmüller and G
Wagner (eds), Law by Algorithm (Mohr Siebeck 2021).
Satzspiegelhöhe: 257.5mm
Höhe der ges. Fahne 2493mm
6 Satzfahne EuCML_2023_050501_1 30. 9. 2023
ties who manufactured the finished product will be jointly
and severally liable towards the victim.
In my view, the joint and several liability of the producers
will apply when the tangible movable good and the AI system
are presented to the victim as a whole because the two
components are bundled products.11 It would be quite an-
other case if the software were subsequently installed by the
victim or by another producer outside the control of the
original producer. Therefore, to the extent that the damage is
caused by a good that includes an AI system or algorithm,
both the hardware manufacturer and the software manufac-
turer will be liable for the damage caused. Hence, in the case
of goods with integrated or interconnected AI systems, in
order for the claim to be successful it is irrelevant whether the
damage is attributed to the hardware manufacturer or the
algorithm developer, since they will be jointly and severally
liable12.
However, despite the recognition of the joint and several
liability of the producers, some problematic cases may arise:
what happens if the software manufacturer is not part of the
same organisation as the hardware manufacturer? Is it then a
third party? Does it lose its third-party status if the software
or AI system is integrated in or interconnected with the
movable good? What if the software or AI system is available
as a free internet download?
4. Can the Software or Algorithm Developer be a
Third Party?
Traditionally, the concept of third party has been explained
in terms of the subject belonging to the same organisation as
the producer. Thus, the third party is not included within the
scope of the producer, but their intervention, together with
the defect affecting the product, aggravates the damage suf-
fered by the victim. Currently, the software or AI system
developer may belong to the same organisation as the produ-
cer, but this does not necessarily have to be the case. There is
no doubt that if they are part of the producer’s organisation,
they cannot be considered a third party, nor could we be
dealing with a case of vicarious civil liability.13
However, for the purposes of answering the questions raised,
it would be useful, in my opinion, if during the legislative
procedure a definition of finished product could be included
in the Proposal for a Directive.14 Such a definition is not
included in Directive 85/374/EEC either, despite the fact that
this concept appears in various provisions. For example,
Article 3 of Directive 85/374/EEC defines the concept of
producer by referring to the concept of finished product.
However, the reference to a finished product has disappeared
from the text of the Proposal for a Directive.
A finished product is one that is placed on the market with-
out requiring further modifications and without updates
being able to alter this status. To the extent that the finished
and globally conceived product incorporates, on the one
11 Wagner (n 10).
12 Navas (n 10). M2 M communications allow the robot to inform the
user or victim of defects. In addition, access to the black box of such
products can facilitate the victim's burden of proof. This may facilitate
the identification of the liable party.
13 U Pagallo, The Laws of Robots. Crimes, Contracts and Torts (Springer
2013). W Barfield ‘Liability for autonomous and artificially intelligent
robots’ (2018) 9 Paladyn, Journal of Behavioral Robotics 1.
14 A definition can be found in a Proposal for a Directive de lege ferenda.
European Law Institute, ‘ELI Draft of a Revised Product Liability Direc-
tive Draft Legislative Proposal of the European Law Institute’
(accessed 31 August 2023).
Satzspiegelhöhe: 257.5mm
Höhe der ges. Fahne 2493mm
7 Satzfahne EuCML_2023_050501_1 30. 9. 2023
hand, the movable good and, on the other hand, the software
or the AI system, in my view the software or AI system
developer could not be considered a third party, given that
without the software or the AI system the good would not be
capable of performing its functions (Recital 15 of the Propo-
sal for a Directive). Vis-à-vis the victim, what matters is the
concept of the product in its entirety, irrespective of the
contractual relationship between the hardware manufacturer
and the software manufacturer. This conclusion is supported
by the provisions of Recital 40 of the Proposal for a Direc-
tive, which establishes that when several economic operators
are liable for the same damage, the victim may claim liability
from both the producer of the good and the producer of the
component, and that both are directly and jointly and sever-
ally liable.
However, in those cases where the product has been placed
on the market as a finished product, and it is the victim or a
third party outside the organisation that produced the origi-
nal product and outside its control15 who installed software
or an AI system in the product, then, in this case, it must be
considered a third party for the purposes of exonerating the
liability of the original producer of the product (Art. 10.2 of
the Proposal for a Directive). In this case, the software or AI
system developer is not part of the producer's organisation,
nor is the system initially integrated in or interconnected with
the product. Moreover, the change made to the product by
installing the software or the algorithm takes place after-
wards, after the product has been placed on the market as a
finished product.
According to the text of Directive 85/374/EEC, the claim
against the third party had to be processed according to the
civil law rules of the Member States, since the liable party
was not a producer. Now, in light of Art. 7 of the Proposed
for a Directive, the software developer could be considered as
a producer of a refurbished product if the movable good has
been made available on the market as a finished product and
the software has been added at a later stage, outside the
control of the original producer. In this way, the victim's
claim for compensation could be processed in accordance
with the future European directive in this area.
5. Open-source AI Systems: a Possible Case of a
Refurbished Product?
As mentioned above, the software and the algorithm do not
necessarily have to be integrated in or interconnected with a
tangible movable good, but can be installed once the item has
been placed on the market. A typical scenario would be
Open-Source Software (OSS)16. The European Parliament’s
Special Committee on Artificial Intelligence in a Digital Age
(AIDA17) recently published a study18 on the challenges and
15 It is also notable that the Proposal for a Directive does not pay more
consideration to refurbished goods. We only find a reference in Recital
29, which establishes that a new product is a new product if it is
substantially modified when it is outside the producer's control.
16 E J Walsh and A J Tibbetts, ‘Reassessing the Benefits and Risks of Open
Source Software’ (2010) Intellectual Property & Technology Law Jour-
nal 1.
17 AIDA stands for Artificial Intelligence in a Digital Era.
18 A Theben et al, Challenges and limits of an open source approach to
Artificial Intelligence (Policy Department for Economic, Scientific and
Quality of Life Policies 2021). Artificial intelligence systems of this type
of software are based on machine-learning. To the extent that the
algorithm has to work with user data, there is a risk that some organisa-
tions or individuals may misappropriate the information for illicit or
illegitimate purposes that are not covered by the licence. The report also
points to the need to determine the liability resulting from decisions of
the algorithm that cause harm to users.
Satzspiegelhöhe: 257.5mm
Höhe der ges. Fahne 2493mm
8 Satzfahne EuCML_2023_050501_1 30. 9. 2023
limits of AI systems which highlights some of the problems
related to such software.
In light of the text of the Proposal for a Directive on liability
for defective products, I wonder how this type of product
should be treated. Under the pretext of not hampering inno-
vation, Recital 13 assumes that the future Directive does not
apply to open-source software that can be downloaded free
of charge from the internet, provided that it is developed or
supplied outside of a commercial activity. However, the Pro-
posed for a Directive states that these products do fall within
the scope of the Directive when they are provided for a fee or
when the user’s personal data is provided to the software
developer for purposes other than improving the security,
compatibility or interoperability of the software. The Propo-
sal for a Directive therefore equates the performance of a
commercial activity with the provision of software products
when these are provided in exchange for payment or personal
data (Recital 13 of the Proposal for a Directive). Recital 13 of
the Proposal for a Directive reminds us of Recital 24 of the
DCD: payment for the software or AI system can be made in
exchange for a price or the provision of personal data when
these are provided for a purpose other than improving the
security, compatibility or interoperability of the software,
which implies, in the latter case, the onerous nature of the
non-monetary consideration paid by the purchaser of the
product.19
We fail to understand why the Proposal for a Directive gives
privileged treatment to open-source software or AI systems
that can be downloaded free of charge when they are devel-
oped or supplied outside the course of a commercial activity.
Directive 85/374/EEC applies to damage caused by defective
products, but the applicability of the Directive is not depen-
dent on the end user of the product having paid a considera-
tion or the product having been manufactured in the course
of trade or business.20
In my opinion, there is no justifiable reason for such favour-
able treatment of certain software or AI system developers. In
the case of open-source software that can be downloaded free
of charge from the internet, even though the provider or
developer is not acting within the course of a commercial
activity, it is still placing on the market a product that could
cause damage to third parties. The developer or provider of
such software or algorithms does not produce the product as
such, but their software or algorithm can be downloaded by
anyone, even though it has been developed free of charge and
outside the scope of a commercial activity. The future direc-
tive should therefore apply to all movable, tangible and in-
tangible goods such as services and digital content, regardless
of whether the products were produced using industrial,
artisanal or artistic methods. 21
19 On the issues related to the consideration of personal data as considera-
tion in relation to the DCD and Regulation (EU) 2016/679 on the
protection of natural persons with regard to the processing of personal
data (GDPR), see J A C Parrilla, ‘Los datos personales como contra-
prestación en la reforma del TRLGDCU y las tensiones normativas entre
la economía de los datos y la interpretación garantista del RGPD’
(2021) Diario La Ley 82; S Cámara Lapuente, ‘Resolución contractual y
destino de los datos y contenidos generados por los usuarios de servicios
digitales’ in E Arroyo Amayuelas and S Cámara Lapuente (eds), El
derecho privado en el nuevo paradigma digital (Marcial Pons 2020).
20 P Machnikowski (eds), European Product Liability. An Anlalysis of the
State of the Art in the Era of New Technologies (Intersentia 2016).
Although there is a doctrinal controversy around this issue, the Court of
Justice has already ruled on this question in Case C-203/99, Veedfald vs
Arhus Amtskommune.
21 Supra.
Satzspiegelhöhe: 257.5mm
Höhe der ges. Fahne 2493mm
9 Satzfahne EuCML_2023_050501_1 30. 9. 2023
As regards the status of the developer of an open-source soft-
ware or algorithm as the producer, I consider the fact that the
software or algorithm is integrated in the finished product to
be relevant. In this case, according to the approach advocated
in this article, the developer of the algorithm would have to
be considered a producer because their product has been
integrated into a tangible movable good and has been ac-
quired by the user as a whole finished product. Likewise, I
believe that they should also be considered a producer if it is
the hardware manufacturer who integrates the open-source
algorithm into the product or who tells the user that they
must download the open-source software in order for the
product to perform its functions. In my opinion, these cases
do not pose too many problems, given that the product
includes the open-source software when it is placed on the
market.
More problematic would be those cases where the open-
source software is installed by a third party, outside the
control of the original producer, with the digital element
causing substantial alterations to the good in terms of its
functionality, security or interoperability. In my opinion, one
interpretation that can be maintained in these cases is to refer
to the field of refurbished goods. According to the Art. 2.18
of the Proposal for Ecodesign for Sustainable Products Reg-
ulation “refurbishment” means preparing or modifying an
object that is waste or a product to restore its performance or
functionality within the intended use, range of performance
and maintenance originally conceived at the design stage, or
to meet applicable technical standards or regulatory require-
ments, with the result of making a fully functional product.22
Following the approach suggested for these goods, after the
installation of the open-source software by a third party, the
product would be considered as new for the purposes of the
legislation on defective products, and the third party who has
installed the software outside the control of the original
producer, would be liable as the producer (Recital 29 and
Art. 7.4 of the Proposal for a Directive). Therefore, consider-
ing the case of refurbished goods, these cases would not fall
outside the scope of application of the future directive and,
therefore, the victims’ claims for compensation would not
have to be dealt with in accordance with the domestic law of
the Member States.
The option to consider open-source software as a refurbished
product and its developer as a producer assumes that it
would be possible to identify the developer within the Euro-
pean Union. However, this would not necessarily be the case,
and it may be that the supplier or developer of such software
or algorithm is established in a state outside the European
Union. In this case, the victim could bring their claim against
the importer of the product, although there may be no im-
porter based in the European Union either, as the product is
downloaded directly from the internet. Faced with this pro-
blem, various solutions have been proposed by legal doctrine,
such as Market Share Liability23 and the obligation to have a
liable economic operator established in the EU so that the
software or algorithm can be placed on the European market,
in line with Regulation (EU) 2019/1020 of the European
22 E Bracquené et al., ‘Repairability criteria for energy related products.
Study in the BeNeLux context to evaluate the options to extend the
product life time. Final Report’, (accessed 31 August 2023).
Legal doctrine has defined refurbishment as the process through which a
used or defective good reacquires the properties and characteristics of a
new good through sorting, sorting, inspection, disassembly, cleaning,
reprocessing and assembly procedures.
23 Navas (n 10).
Satzspiegelhöhe: 257.5mm
Höhe der ges. Fahne 2493mm
10 Satzfahne EuCML_2023_050501_1 30. 9. 2023
Parliament and of the Council of 20 June 2019 on market
surveillance and compliance of products24.
IV. Conclusions
The Proposal for a Directive on liability for defective prod-
ucts envisages software and algorithms as products. How-
ever, instead of using the term “software”, I advocate refor-
mulating the concept of “product” used in the Proposal for a
Directive in the light of Directives (EU) 2019/770 and 2019/
771 to harmonise the law on contractual liability and lack of
product compliance with the law on non-contractual liability
for defective products.
Although the Proposal for a Directive refers to software as a
related component or service, I understand that this concept
should not be understood as an accessory to the product
conceived as a whole, but as an integral part of the product
that makes up the whole.
The software or algorithm developer or supplier may have
the status of a third party, understood as a person outside the
product manufacturer’s organisation and outside their con-
trol, depending on their relationship with the finished prod-
uct that is placed on the market. If the software or algorithm
is integrated in or interconnected with a tangible movable
good (bundled product), then they may not be considered a
third party, given that the software or algorithm is necessary
for the product to perform its functions and is acquired by
the end users as a finished product that includes both the
hardware and the digital component. However, the software
developer or supplier shall not have third-party status when
the product has been placed on the market as a finished
product without including the digital component and is sub-
sequently installed by a third party or by the user.
The European legislator has decided to leave open-source
software that is acquired free of charge on the internet out-
side the scope of the Proposal for a Directive, a choice I do
not agree with. We advocate considering the developer or
supplier of such software as a producer of a refurbished
product when the product is altered in terms of its function-
ality, security or interoperability through the installation of
the software. In this way, the claim for compensation against
the developer or supplier of this type of software would not
fall outside the scope of application of the future directive
and, therefore, the victim’s claim for compensation could be
pursued on the basis of product liability law. &
24 Wenderhorst (n 4).
Satzspiegelhöhe: 257.5mm
Höhe der ges. Fahne 2493mm