Your Code Is Now a Product: EU Product Liability Reform and the Freelance Developer

Your Code Is Now a Product: EU Product Liability Reform and the Freelance Developer | Articles | Tobias Weiss

The code you shipped last month can make you personally liable for damages in 2036. That is not an exaggeration — it is the arithmetic of a law most developers have never read, set to change on 9 December 2026.

On that date, Germany's Product Liability Act (Produkthaftungsgesetz) gets its first comprehensive reform since 1989, transposing the EU's new Product Liability Directive 2024/2853. The headline change is deceptively simple: software is now legally a "product". Freelance developers are not exempt. The person who developed the software is, by definition, its "Hersteller" (producer).

I have read the German government draft (RegE, 17 December 2025) so you don't have to. Here is what actually changes, which European and German specifics matter, and the ten consequences that matter for freelance programmers. This is an informed summary, not legal advice — but it points to the exact provisions you should copy into a law-yer's inbox.

What is actually happening

The EU adopted Directive (EU) 2024/2853 on 23 October 2024, replacing the 1985 Product Liability Directive. Member states must transpose it by 9 December 2026. The German implementation — officially "Gesetz zur Modernisierung des Produkthaftungsrechts" — passed cabinet in December 2025 (BR-Drs. 775/25) and is working its way through the Bundestag as the deadline approaches.

Three new features separate this from the 1985 regime:

Software explicitly counts as a product — no matter how it is delivered: installed, embedded, SaaS, or a library another product integrates.
Destroyed or corrupted data is now a compensable damage category — the one most likely to hit ordinary software bugs.
Evidence disclosure and presumptions rebalance the proof burden — courts can order you to hand over relevant evidence, and the defect/causation can be presumed if you do not.

The transition rule matters enormously: products placed on the market or put into service up to and including 8 December 2026 stay under the old law. Everything you ship from 9 December 2026 onwards is judged by the new rules.

What a "product" now means

The new §2 of the draft defines products as movable things, electricity, digital manufacturing files — and software, with one carve-out:

Software, with the exception of free and open-source software that is developed or made available outside a commercial activity.

So: your commercial client work, your SaaS, your plugins, your embedded frontends — all products. Hobby OSS with no commercial activity is outside the scope. If you are paid to maintain an OSS project, the carve-out may cease to apply — a nuance worth checking with counsel.

Who is the "Hersteller"?

§3 is where freelancers should get uncomfortable:

A producer is anyone who develops a product or has it developed. Anyone who presents themselves as producer through name, brand or mark also counts.

There is no "it's the client's product" escape hatch. If you wrote the software, you developed it — you are a producer, strict liability without any fault requirement. The end user does not need a contract with you to sue you directly.

Two related provisions widen the net:

Component liability (§4): if your library, module, or connected service is integrated into a product and causes its defect, you and the final producer are jointly and severally liable (§15). A "connected service" is a digital service so integrated that the product cannot function without it — think the backend your app depends on.
Substantial modification (§5): whoever essentially changes a product after it was placed on the market, without the producer's consent, and then puts it into circulation, becomes the producer of the modified product. Fork a product, rebrand it, ship it as "your" solution — that role is yours.

What damages are covered now

Damage	Old law	New §1
Death / physical injury	Yes	Yes, incl. medically recognised psychological harm
Property damage	Yes (private property)	Yes, property used exclusively for professional purposes excluded
Destroyed/corrupted data	No	Yes, if not used exclusively professionally

The data category is new and, for software, the practical risk: a bug that wipes user data now directly triggers liability under §1(1)(3), with data defined via the EU Data Governance Act (Reg. 2022/868). Note the draft's property wording is broader than the directive: only property used exclusively for professional purposes is out — mixed-use and even mostly-business property may be in. The Directive's "normally intended for private use" test does not appear in the German draft.

The claimant side also limits the blast radius: only natural persons claim, and damage to business-only property/data of a company is excluded. A pure B2B internal tool where only the company's data is affected largely escapes this strict regime — but the moment consumers or their private data are in play, the whole law applies.

When is software "defective"?

§7 keeps the classic test — a product is defective if it does not provide the safety one is entitled to expect — but the assessment now explicitly includes:

cybersecurity requirements (including safety-relevant ones),
the product's ability to keep learning or acquiring new features after being placed on the market,
foreseeable effects of other products used or connected with it,
product recalls and regulatory measures.

The decisive clock question is answered in §8: the defect is assessed at the moment the product was placed on the market or, if the producer kept control, when it left his control. Control exists if you can provide software updates yourself. And §9(2) removes the state-of-the-art/development-risk defence where the defect stems from a connected service, software updates, the lack of security updates needed to maintain safety, or a substantial modification.

Translated for a developer: if you still hold the keys — you operate the SaaS, you ship updates — you are judged on the current security state. A known CVE you never patched is a defect, and the "nobody knew better at the time" defence is gone for update-related failures.

The proof rules you should fear

Two sections introduce what is effectively US-style discovery into German product liability:

§19: on a sufficiently plausible claim, a court can order you to disclose relevant evidence in your control — documentation, repositories, CI logs, test reports — limited to what is necessary and proportionate, with trade-secret protections (GeschGehG applies).
§20: if you disobey a disclosure order, the defect is presumed. The same happens if the product breaches binding safety requirements or an obvious malfunction caused the damage. If it is disproportionately difficult for the claimant to prove defect or causation given technical complexity, they only need to show it is likely.

Keep records as if a court might order them produced — because, with plausibility shown, it can.

The time horizon

3-year limitation (§16) from knowledge of defect, damage and debtor.
10-year extinction (§17) from the day the product was placed on the market or put into service — for software, effectively forever in product-terms; 25 years for latent personal injuries.

A project you stopped maintaining in 2027 can hit your insurance in 2037.

Ten consequences for freelance programmers

You are a producer, not a "mere contractor". Client work, SaaS, plugins — your code is a product and you can be sued directly by consumers, with no contract between you.
Data loss claims are the new normal. The §1(3) data-damage category is the one most likely to hit ordinary application bugs. Test data integrity and backup paths like a liability engineer.
Component + joint liability. If your library is integrated elsewhere, you are jointly liable with the final producer — for claims that come to you, not the client.
Avoid white-label traps. Rebrand or substantially modify an existing product and you may become its producer under §5.
Security-maintenance is a liability task. If you can ship updates, a known-but-unpatched CVE is a defect, and the development-risk defence does not apply.
The insurance gap is real. Typical professional indemnity (Vermögensschaden-Haftpflicht) covers contractual and financial losses — it often excludes strict product liability for third-party bodily injury and property damage. Check whether you need separate product liability cover (Produkthaftpflicht).
Contracts manage recourse, not external claims. §18 makes the liability mandatory — you cannot exclude it towards the injured party. Use contracts with clients to state who is the producer, what you deliver, and to allocate internal recourse (indemnities), but know that a consumer's claim ignores all of it.
Documentation is your defence material. The §9(1)(3) state-of-the-art defence requires proving you could not have known. That requires evidence of what you did know — decision logs, security reviews, CVE triage records.
Discovery orders are real. Prepare so a §19 order does not bury you in a presumption under §20: sane repo hygiene, retained release records, published security notes.
Re-check every 1–2 years. The RegE is not the final statute; the Bundestag can change the wording (the property-damage scope, for example, is a live debate). Re-read the final law when it is published and at each contract renewal.

The developer's bottom line

The reform does not criminalise shipping software — it makes the economics explicit: someone has to bear the risk of a defective product, and by default that someone is whoever developed it. For a freelancer the honest response is not a panic, but a config file: clarify producer roles in every contract, treat security patching as a contractual obligation with a paper trail, and fix the insurance gap before a claim finds it. The moving part is now — because everything you place on the market after 9 December 2026 runs on the new rules for the next ten years.

This article summarises the German government draft (RegE, 17 Dec 2025, BR-Drs. 775/25) and Directive (EU) 2024/2853. It is general information, not legal advice — the final enacted statute takes precedence.

Cart

Wishlist

Your wishlist is empty