Commercial Software and Product Liability

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

Commercial supply does not require a licence fee

Commercial software can fall within Directive (EU) 2024/2853 even when users do not pay for a download. Article 4 defines making available on the market by reference to supply in commercial activity, whether for payment or free of charge. The relevant inquiry concerns the supply circumstances, the software product and the actor's role. A zero price field cannot resolve that analysis by itself.

The software product liability framework still requires defectiveness, covered damage and causation. Commercial status is a scope and actor question rather than proof that a product was unsafe. It should be documented alongside the product history, not used as a shortcut from a business model to an assumed compensation obligation for every customer complaint.

Map the actual supply arrangement

Identify who develops or produces the software, who presents it under a brand and who supplies it to the user. A reseller, development contractor and branded publisher may have different roles. Article 4's manufacturer definition includes specified development, production and branding relationships. Article 8 then identifies economic operators potentially liable under its conditions. Job titles and website labels do not replace those provisions.

Keep licensing terms, invoices where available, publisher information and the distribution route. If software is included in a wider hardware or service package, record that arrangement instead of treating the absence of a separate software charge as proof of non-commercial activity. An application supplied to support a commercial product can have a relevant market relationship without being separately itemised on the customer's receipt.

Free access and non-commercial open source differ

Article 2(2) excludes free and open-source software developed or supplied outside commercial activity. That wording requires more than checking whether source code is public. The facts concerning development or supply and commercial context matter. A commercially packaged product can include code originating in a non-commercial project without making the final supplier's activity identical to the upstream contributor's activity.

Preserve the licence and actual relationships. Avoid assuming that every contributor is a commercial manufacturer or that every company using open-source code is exempt. Recitals 14 and 15 explain the distinction between non-commercial upstream development and later commercial integration. The liability of a finished-product manufacturer needs assessment on its own facts, even where the original developer falls outside the Directive's scope.

Contracts cannot answer every injured-person question

A licence may allocate risk, limit particular contractual remedies or describe permitted use. Such terms are relevant records, but Article 15 prevents liability under the Directive being limited or excluded in relation to the injured person by contractual provision or national law. The interpretation and effect of particular terms still require the applicable legal framework and national law.

Distinguish an injured person's statutory claim from contribution or recourse between businesses. Suppliers can have contractual relationships that require separate examination after the injured-person liability question. Article 12 addresses multiple liable operators and a specific conditional recourse rule for some small software component manufacturers. That provision should not be converted into a blanket rule that small developers cannot face claims by injured people.

Enterprise supply does not make every loss covered

Commercial software is often used in business, but the Directive's compensation framework concerns harm suffered by natural persons and its defined damage categories. A company's lost revenue or production is not automatically covered merely because a commercially supplied program malfunctioned. Contractual or other national remedies may be important, but they require separate legal grounds.

Article 6 excludes property used exclusively professionally from its property category and excludes data used professionally from its data category. A worker's personal injury is a different loss from the employer's damaged business records. A sole trader may need a careful factual account of property use and data use rather than an assumption that all losses share one classification.

The commercial product still needs a safety assessment

An application can be poorly documented, inefficient or inconsistent with a customer's expectations without necessarily being legally defective under Article 7. Conversely, compliance with an agreed specification does not establish that all legally expected safety was provided. Assess design, instructions, foreseeable use, integration and applicable safety requirements against the alleged failure mechanism.

The distinction between bugs and legal defectiveness is useful when business incident reports emphasise service quality. Ask which safety function failed, how the program contributed to covered harm and what competing explanations remain. A contractual service credit or refund does not itself prove or disprove those elements of a separate product liability claim.

Preserve commercial and technical records together

A technical inventory without supply records can leave the relevant actor uncertain. Supply records without the affected release can leave the alleged defect uncertain. Preserve both: publisher identity, supply dates, release artefacts, configuration, integration approval and incident evidence. Where a distributor repackaged the product, record its changes instead of assuming that the original publisher supplied the exact final configuration.

Article 9 provides conditional court-controlled disclosure of relevant evidence, with proportionality and confidentiality safeguards. Commercial sensitivity does not make every relevant record inaccessible, while the Directive does not grant unrestricted access to a company's complete repositories. A request should explain the connection between a specific record category and an issue such as release identity, integration or the alleged unsafe mechanism.

Apply the correct time framework

The corrected Article 2(1) concerns products placed on the market or put into service after 8 December 2026. Article 22's 9 December 2026 national transposition deadline has a different purpose. Do not use the date a contract was renewed or an accident reported as a substitute without examining the actual product supply and legal significance of later changes.

Article 10 retains the starting burden of proving defectiveness, damage and causation, subject to specified rebuttable presumptions. Establishing commercial supply helps address scope but does not supply those remaining elements. A sound review ends with a documented actor and product chronology, a clear harm classification and a testable account of the alleged unsafe behaviour, rather than a conclusion drawn from price or licensing terminology alone.

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.