Article 4(1) of the directive defines a product as «any movable item» and specifies that the definition «includes electricity, files for digital fabrication, raw materials and software». Paragraph 3 adds the concept of a related service: a digital service integrated into or interconnected with a product «in such a way that its absence prevents the product from performing one or more of its functions» — the cloud backend without which the application does not work falls within this definition.

• Open source: the directive does not apply to free and open-source software «developed or supplied in the course of a non-commercial activity» (Art. 2, para. 2). The commercial distribution of open source, however, is not excluded.
• Temporal dividing line: the new rules apply to products «placed on the market or put into service after 9 December 2026» (Art. 2, para. 1). Software already on the market remains under the previous regime of Directive 85/374/EEC, repealed with effect from the same date (Art. 21).

The general criterion is safety, not quality: a product is defective «if it does not provide the safety that a consumer can legitimately expect or that is required by Union or national law» (art. 7, c. 1). Software with disappointing performance, a questionable UX or features inferior to a competitor is not, for that reason, a defective product: the directive itself states it — a product «is not considered defective for the sole reason» that a better one exists or will be released, «including updates and improvements to it» (art. 7, c. 3).

Among the circumstances that the judge must assess (art. 7, c. 2), three directly concern developers:

The order of liable parties is established by Article 8: the manufacturer of the product is liable; the manufacturer of the defective component integrated under the control of the former is liable — and third-party software integrated into a product is a component (Art. 4, p. 4); for non-EU manufacturers, liability cascades to the importer, authorised representative, or logistics provider. Whoever substantially modifies a product outside the manufacturer's control and places it back on the market becomes its manufacturer in turn (Art. 8, para. 2).

For those who develop on commission or supply components, two provisions are worth more than many contractual clauses:

• The instructions defence (Art. 11, para. 1, let. f): the component manufacturer is not liable if the defect is due to «the design of the product into which it was integrated» or «the instructions given by the product manufacturer». Translated into practical terms: documenting the requirements and instructions received from the client is not bureaucracy — it is a legal defence. Meeting minutes, signed specifications, tracked decisions: that material may one day be worth more than the code itself.
• The clause for small software houses (Art. 12, para. 2): whoever integrates a software component has no right of recourse against the component manufacturer if the latter was a micro or small enterprise and the waiver of recourse was «contractually agreed». The directive itself provides that this protection can be negotiated: if you are a small company supplying components to a larger integrator, this clause must be understood before signing.

Here the directive is stricter than newspaper headlines suggest. Article 6 limits recoverable damage to three categories:

• death or personal injury, «including psychologically recognised damage from a medical point of view»;
• damage to or destruction of property, but with the explicit exclusion of the defective product itself and of «goods used exclusively for professional purposes»;
• destruction or corruption of data, but only data «not used for professional purposes».

The consequence for B2B is significant: damage to the customer's data and business assets does not fall under product liability — it remains a matter of contract, where liability and caps can be negotiated. What always applies is damage to the person: the end user, the consumer, the patient. This is why those handling data or functions that affect natural persons (the healthcare sector being the textbook example) must make these calculations more carefully than anyone else.

On the contractual front, the boundary is clear: towards the injured party, product liability «shall not be limited or excluded […] by contractual provision» (Art. 15). What remains negotiable, however, is the allocation between economic operators, as illustrated by the waiver of recourse clause in Art. 12, para. 2. As for timeframes: the right is time-barred after 3 years from when the injured party becomes aware of the damage, the defect and the liable party (Art. 16), with a cap of 10 years from the placing on the market — which however restarts in the event of a substantial modification of the product — and 25 years for long-latency injuries (Art. 17).

The last point for us is not a slogan: it is the account we ran on MedicHub, and it is the reason why today we design every software, ours or our clients', with maintenance and documentation as part of the product, not as an add-on. No supplier can «make you compliant» by contract: the responsibility remains with whoever places the product on the market. What a good supplier can do is deliver software that is built, documented and maintained in a way that holds up under this framework.