Commercial integration creates a separate supply-chain inquiry
A commercial product can contain software originating in a free and open-source project. That fact does not automatically make every project contributor responsible for the product, nor does an upstream exclusion automatically remove the finished-product manufacturer's role. The investigation must distinguish the project's activity, any commercial distribution and the manufacturer's integration of a particular artefact into the product that allegedly caused harm.
The component and supply-chain liability framework treats this as an actor and integration inquiry. Article 2(2) of Directive (EU) 2024/2853 excludes free and open-source software developed or supplied outside the course of a commercial activity. Applying that exclusion requires facts about the relevant activity. An open licence, a zero-price download and incorporation into a sold device are related facts, but they do not answer the same question.
Map the handoff from project release to installed component
Start with the upstream release, then identify any vendor distribution, fork, patch set or repackaged component used by the manufacturer. Record the entity responsible for each step. The installed code may differ materially from the public project release while retaining its name. A contributor list cannot establish who produced or supplied the particular artefact incorporated into the affected product.
Preserve release identifiers, source provenance, build records and supplier delivery references. Link those records to the finished-product version rather than stopping at the public repository. The important handoff is the point at which the manufacturer or its supplier selected, modified, built and approved the software for the product. That evidence explains commercial integration without requiring an assumption that upstream volunteers authorised the downstream use.
Separate access to code from approval of integration
A project making code available does not thereby approve every use of it in a physical product or safety-critical function. Identify the manufacturer's own selection and integration decisions. Article 4's manufacturer control definition includes specified actions, authorisation or consent and the ability to supply software updates or upgrades. The finished-product manufacturer's control should be assessed through its actual conduct and arrangements.
A commercial integrator may rely on a specialist vendor for packaging, maintenance or configuration. Record whether that vendor changed the software, supplied a distribution or merely advised on installation. The distinction can affect actor analysis. Avoid describing a paid support relationship as automatically proving that the original project, its maintainers and every contributor were all developing or supplying the relevant component commercially.
Establish the safety-relevant difference introduced downstream
A commercial product may disable an upstream safeguard, alter error handling, use an unsupported configuration or expose the component to a new interface. Record those changes separately from any original defect. A public issue report can identify an upstream problem, but the product's actual response may depend on downstream configuration, integration and safeguards. The proposed mechanism must account for both levels.
Article 7 includes foreseeable use, characteristics, instructions and interaction. Explain why the incorporated component allegedly made the complete product unsafe in the relevant circumstances. A licence compliance problem or missing attribution does not itself establish a safety defect under this Directive. Equally, compliance with the licence does not establish that the product's use of the component was safe. Intellectual-property permissions and product safety address different matters.
Link inventory records to the delivered product
A software bill of materials can help identify open-source origins, but its scope needs checking. A development inventory may include packages excluded from the release, while a delivered product may contain an indirect dependency or vendor patch absent from the inventory. Determine whether the record describes the actual build and whether later updates changed it. Treat the inventory as evidence to verify rather than a definitive liability register.
Traceability should connect the release, modifications, build and delivery to the incident-time product. The guide to component traceability in investigations explains how to mark confirmed and inferred links. Where a vendor cannot reproduce an earlier build, preserve the surviving artefacts and explain the gap. The absence of a perfect inventory should not lead to silently substituting a current public release for the code actually supplied.
Preserve the commercial manufacturer's responsibility analysis
Article 8 addresses the finished-product manufacturer and conditional component manufacturer liability. A manufacturer cannot automatically answer a claim about its sold product by saying the underlying code was freely available. The relevant inquiry still concerns defectiveness, control, covered damage and causation. At the same time, commercial integration does not justify an automatic liability conclusion about every upstream developer whose code is present.
The component-specific exemption in Article 11(1)(f) and the non-commercial exclusion address different questions. One concerns the attribution of finished-product defectiveness to design or instructions; the other concerns the Directive's scope for certain software activity. Keep the factual basis for each separate. This makes it possible to examine a commercial product and a non-commercial upstream project without collapsing their distinct positions.
Keep recourse and injured-person rights distinct
Article 14 provides for remedies between liable operators after compensation, in accordance with national law. Article 12(2)'s specific software recourse exception requires both qualifying microenterprise or small-enterprise status and a contractual waiver agreed by the integrating manufacturer. It should not be described as a blanket open-source protection or a rule that all small software suppliers are immune from claims.
Article 15 separately protects the injured person's statutory position against contractual limitation or exclusion. Licence disclaimers and supplier allocation terms therefore need careful legal analysis rather than an assumption that they decide the injured person's claim. A complete handoff account identifies who supplied what, the commercial setting, modifications, integration approvals and remaining uncertainty. It then leaves the applicable national law and substantive liability conditions visible for separate assessment.
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.
- Upstream release, vendor modifications and build provenance
- Commercial distribution and integration arrangements
- Delivered software inventory and approval history
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.
- Directive (EU) 2024/2853, consolidated text: Articles 2, 4, 6, 7, 8, 11, 12, 14, 15 ↗
- Official Journal corrigendum, 7 May 2026: Article 2(1) ↗
Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.