Third-Party Libraries and Product Liability: Who Supplied the Defective Component?

EU Directive-level explanationUpdated 16 October 2026By ProductLiability.help editorial desk

Outsourced code does not automatically transfer liability

A third-party software library can be relevant as a defective component under Directive (EU) 2024/2853. Article 8(1)(b) addresses the manufacturer of a defective component where it was integrated or interconnected within the product manufacturer's control and caused the product to be defective. The provision also preserves the finished-product manufacturer's position under the Directive. The component and supply-chain framework connects these relationships to integration and supplier evidence. Identifying an external supplier does not automatically remove the integrator from the analysis.

The software product liability framework still requires a safety defect, covered damage and causation. Library analysis adds a focused actor question: which product or component was supplied by whom, under what conditions, and how did it contribute to the unsafe result? This requires commercial and integration evidence alongside the technical description of a faulty function.

Identify the actual library and supplying actor

A familiar project name can correspond to an upstream release, a commercial distribution, a modified fork or code incorporated into a vendor package. Record the version and origin of the component actually used. The organisation appearing in a package name may not have supplied the modified artefact present in the finished product. A repository contributor list is not itself a list of legally responsible suppliers.

Preserve the procurement or distribution route, relevant licence, vendor correspondence and modification history. Determine whether a supplier developed or produced the component, branded it or simply distributed another product. Article 4's manufacturer and other economic-operator definitions should be applied to the facts. Avoid assigning a legal role solely from an invoice category such as consultant or support provider.

Establish what made the component allegedly defective

A library can return an incorrect result without causing the finished product to fall below the required safety standard. Explain the alleged unsafe characteristic and how the integrator used it. If an application ignored a documented error result, the failure path may differ from a library silently returning an incorrect success value. Both the component and integration need examination.

Article 7's circumstances include presentation, technical characteristics, instructions, foreseeable use and foreseeable interaction. The supported operating range and integration requirements are relevant but not conclusive. A library supplier's technical assumptions should be compared with the use actually made of the component. A finished-product manufacturer also needs assessment for its selection, integration, safeguards and the safety of the resulting product.

Integration within manufacturer control matters

Article 4 defines manufacturer control through specified actions, authorisation or consent and the ability to supply updates or upgrades. Record who selected the library, approved its use and authorised changes. A component deliberately integrated by the product manufacturer presents a different factual relationship from an unauthorised addition by a user after supply. The label third party cannot answer the control question.

Keep release approvals and the artefact connecting the library to the finished product. The dependency reconstruction guide explains why a manifest entry is not always enough. Confirm whether the relevant library was included and executed in the affected configuration. Without that connection, a correct account of a supplier's defective component may still concern a component unrelated to the reported incident.

Non-commercial open source needs a separate assessment

Article 2(2) excludes free and open-source software developed or supplied outside commercial activity. A publicly accessible library is not automatically excluded, and a commercially supplied library is not excluded merely because its licence permits source access. Examine development and supply circumstances rather than relying on a single licensing label.

Recital 15 explains that later commercial integration of software supplied outside commercial activity can support liability of the integrating manufacturer without bringing the non-commercial upstream manufacturer into scope on that basis. Preserve the upstream and downstream relationships separately. This avoids two opposite mistakes: treating every volunteer contributor as a commercial supplier, and treating an open-source origin as immunity for a commercial finished product.

Multiple liable operators and recourse are different questions

Article 12 permits joint and several liability where two or more operators are liable for the same damage under the Directive, without prejudice to national contribution or recourse rules. It does not mean every participant in a software supply chain is automatically liable. First establish the legal conditions applicable to each actor and the same damage.

Article 12(2) also contains a narrowly conditioned limitation on a software-integrating manufacturer's recourse against certain microenterprise or small-enterprise component manufacturers. The conditions include the relevant enterprise status and a contractual waiver of recourse. This is not a general exemption protecting all small developers against injured-person claims. Apply the actual wording and facts before describing its effect on relationships between businesses.

Component manufacturers have a specific possible defence

Article 11(1)(f) addresses a component manufacturer proving that the defectiveness of the product into which the component was integrated or interconnected is attributable to the design of that product or the instructions given by its manufacturer. A supplier cannot establish that defence merely by saying another business integrated the component. The design or instruction explanation needs evidence.

Preserve specifications, change requests and tests showing how the component operated under the instructed conditions. If the library was modified after supply, identify those modifications and their relevance. Distinguish the component's original behaviour from downstream changes, and explain uncertainties where the original artefact is missing. A reliable technical history is essential to evaluating the claimed allocation of responsibility.

Focus evidence on roles, mechanism and harm

Article 9 permits relevant court-controlled disclosure subject to its conditions and safeguards, including proportionality and protection of confidential information. Requests can identify a named component, release and integration decision rather than demand unrestricted access to all supplier code. Article 10 preserves defectiveness, damage and causation as starting proof requirements, with specified rebuttable presumptions.

Classify the alleged harm under Article 6 before discussing compensation. A failed library causing professional data loss is not automatically within the stated data category. Personal injury or damage to other eligible property presents different questions. The completed review should connect the supplying actor, exact component, unsafe integration and covered harm, while keeping inter-business recourse distinct from the injured person's claim.

Records that help the review

Use the following as a practical starting point. Select and preserve records appropriate to the product, incident and applicable procedure.

Incident-time software identity and configuration
Relevant safety assumptions and test evidence
Supply, integration and control chronology

Independent educational information at EU Directive level. National implementing law and procedure require separate review.

Primary sources and legal scope

This page explains the EU Directive framework. Check national implementing law, the corrected temporal scope and relevant procedure before applying it to a case.

Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.