Seit Dezember 2024 gilt eine neue EU-Produkthaftungsrichtlinie – und sie behandelt Software erstmals ausdrücklich als Produkt, egal ob als eigenständige App, eingebettete Firmware oder Cloud-Dienst. Für Hersteller und für Unternehmen, die Software integrieren oder einsetzen, ändert das die Haftungslage spürbar. Wir ordnen ein, wann Software als fehlerhaft gilt, wo die Ausnahme für Open-Source-Software endet und bis wann Deutschland die Regeln umsetzen muss.
Das Wichtigste vorab
Die Richtlinie (EU) 2024/2853 erklärt Software in Artikel 4 ausdrücklich zum Produkt – unabhängig davon, ob sie eigenständig, eingebettet oder als Cloud-Dienst bereitgestellt wird. Nicht-kommerzielle Open-Source-Projekte bleiben ausgenommen; sobald ein Unternehmen dieselbe Software kommerziell nutzt, integriert oder gegen Entgelt anbietet, geht die Haftung auf dieses Unternehmen über. Die EU-Mitgliedstaaten müssen die Richtlinie bis zum 9. Dezember 2026 in nationales Recht umsetzen.
Software gilt jetzt ausdrücklich als Produkt
Die neue Fassung der Produkthaftungsrichtlinie schließt eine Lücke, die im ursprünglichen EU-Produkthaftungsrecht von 1985 naturgemäß fehlte: Software wird jetzt ausdrücklich als Produkt eingeordnet. Das gilt für eigenständige Anwendungen wie Office-Programme oder Apps ebenso wie für Software, die Teil eines physischen Produkts ist – etwa eingebettete Systeme in Autos oder Haushaltsgeräten – und für Cloud-basierte Anwendungen, die online genutzt werden, etwa als SaaS.
Ziel ist ein einheitlicher Verbraucherschutz über physische und digitale Produkte hinweg, mit klar zugewiesenen Herstellerpflichten: Wer Software in Verkehr bringt, muss sicherstellen, dass sie den Sicherheitsstandards entspricht, die vernünftigerweise erwartet werden dürfen. Versäumnisse dabei können zu Haftungsansprüchen führen, unabhängig von individuellem Verschulden – die Richtlinie folgt dem Prinzip der verschuldensunabhängigen Haftung.
Wann gilt Software als fehlerhaft?
Fehlerhaft ist Software, wenn sie nicht die Sicherheit bietet, die ein Verbraucher vernünftigerweise erwarten darf. Bei der Beurteilung zählen unter anderem die Einhaltung gesetzlicher und technischer Normen, die realistischen Sicherheits- und Funktionsversprechen des Herstellers sowie die Fähigkeit der Software, problemlos mit anderen Anwendungen oder Geräten zusammenzuarbeiten.
Eine besondere Herausforderung stellen dynamische Systeme dar – etwa Software mit lernfähigen Algorithmen oder Künstlicher Intelligenz. Weil sich solche Programme nach der Markteinführung weiterentwickeln, können neue Risiken entstehen, die ursprünglich nicht absehbar waren. Genau diese Fälle nimmt die Richtlinie ausdrücklich in den Blick.
Beweislast: Hersteller müssen liefern, nicht nur behaupten
Grundsätzlich muss die geschädigte Person den Schaden und den Produktfehler nachweisen. Die Richtlinie verschiebt diese Last jedoch spürbar: Hersteller müssen im Streitfall relevante Unterlagen offenlegen – technische Spezifikationen, Testberichte, Entwicklungsdokumentation. Verweigern sie diese Offenlegung, wird die Fehlerhaftigkeit der Software zugunsten der klagenden Partei vermutet.
In der Praxis bedeutet das: Qualitätssicherung und Dokumentation sind kein optionales Extra mehr, sondern die eigentliche Verteidigungslinie im Streitfall. Wer vor der Markteinführung gründlich testet und den Entwicklungsprozess nachvollziehbar dokumentiert, steht im Ernstfall deutlich besser da als wer sich auf mündliche Zusicherungen verlässt.
Open Source: ausgenommen, bis sie kommerziell wird
Um Innovation und Zusammenarbeit in der Open-Source-Community nicht zu behindern, nimmt die Richtlinie Software ausdrücklich aus, die nicht im Rahmen einer gewerblichen Tätigkeit entwickelt oder bereitgestellt wird. Das schützt freiwillige Entwickler:innen, Forschungsprojekte und gemeinnützige Organisationen, die ihre Software unentgeltlich zur Verfügung stellen.
Diese Ausnahme ist an die Art der Bereitstellung geknüpft, nicht an die Lizenz. Sobald ein Unternehmen Open-Source-Software in ein eigenes Produkt integriert, gewerblich modifiziert oder gegen Entgelt beziehungsweise im Austausch gegen personenbezogene Daten anbietet, lebt der Produktcharakter wieder auf – und die Haftung geht auf dieses Unternehmen über.
| Konstellation | Wer haftet |
|---|---|
| Freiwillige oder Community veröffentlichen Code unentgeltlich, nicht-gewerblich | Niemand – Ausnahme greift |
| Unternehmen integriert Open-Source-Komponenten in ein eigenes, kommerziell vertriebenes Produkt | Das integrierende Unternehmen |
| Ursprünglich freies Projekt wird gegen Entgelt oder gegen personenbezogene Daten angeboten | Das anbietende Unternehmen |
Was das für Entwickler und integrierende Unternehmen bedeutet
Wer Open-Source-Komponenten selbst entwickelt oder in eigene Produkte integriert, sollte sich frühzeitig auf die neue Beweislast einstellen:
- Dokumentation nachrüsten: technische Spezifikationen, Testberichte und Entwicklungsentscheidungen so ablegen, dass sie im Streitfall vorgelegt werden können.
- Herkunft kennen: welche Open-Source-Komponenten in welcher Version tatsächlich im Einsatz sind – der Gedanke einer Stückliste für Software (SBOM) wird durch die Richtlinie praktisch relevanter.
- Vor der Integration prüfen: Sicherheit, Kompatibilität und Lizenzbedingungen einer Komponente klären, bevor sie Teil eines kommerziell vertriebenen Produkts wird.
- Zuständigkeit klären: intern festlegen, wer für Haftungsfragen rund um eingesetzte Open-Source-Software verantwortlich ist – bevor ein Schadensfall diese Frage aufwirft.
Zeitplan: bis wann die Regeln greifen
Die Richtlinie ist am 8. Dezember 2024 in Kraft getreten. Die EU-Mitgliedstaaten müssen sie bis zum 9. Dezember 2026 in nationales Recht umsetzen; ab diesem Stichtag gilt die neue Haftungsordnung für Produkte, die danach in Verkehr gebracht werden. Bis zur nationalen Umsetzung bleibt Zeit, Dokumentation und Open-Source-Inventar in Ordnung zu bringen – wer damit erst nach Inkrafttreten der deutschen Umsetzung beginnt, startet spät.
Quellen
- Richtlinie (EU) 2024/2853 – EUR-Lex – amtlicher Text, insbesondere Artikel 4 (Produktdefinition) und Erwägungsgrund 14 (Open-Source-Ausnahme).
- Reed Smith: The new EU Product Liability Directive – Implications for software, digital products, and cybersecurity – praxisorientierte Einordnung der Auswirkungen auf Softwarehersteller.
Quellen abgerufen am 7. August 2026. Dieser Beitrag ist keine Rechtsberatung und ersetzt keine eigene Prüfung der aktuellen Rechtslage und der nationalen Umsetzung durch eine Rechtsanwältin oder einen Rechtsanwalt vor konkreten unternehmerischen Entscheidungen.
