Die anstehende Modernisierung des Produkthaftungsrechts zieht eine klare Linie: Nicht‑kommerzielle Open-Source-Projekte sollen von verschuldensunabhängiger Produkthaftung ausgenommen werden, wohl aber Unternehmen, die Open Source geschäftlich in ihre Produkte integrieren. Für Management und Open-Source-Entwickler stellt sich damit weniger die Frage „Haften wir?“, sondern „Wer haftet in welcher Rolle entlang der Wertschöpfungskette – und wie steuern wir dieses Risiko?“
Dabei zeigt sich bei genauem Blick ein spürbares Risiko für die Opensource-Landschaft – denn was “Open-Source” ist, ist nun einmal gesetzlich nicht definiert. Und der Gesetzgeber scheint da sehr eigene Vorstellungen zu haben, jedenfalls wenn es ums Geld geht.
Open Source in der Systematik der neuen Produkthaftung
Die EU‑Produkthaftungsrichtlinie (EU) 2024/2853 erklärt Software in ihrer gesamten Breite – lokal installiert, heruntergeladen, cloudbasiert, SaaS – zum Produkt; der deutsche Regierungsentwurf übernimmt diese Linie vollständig. Gleichzeitig nimmt Art. 2 Abs. 2 ProdHaftRL „freie und quelloffene Software, die außerhalb einer Geschäftstätigkeit entwickelt oder bereitgestellt wird“, vom Anwendungsbereich aus; das ProdHaftG‑E spiegelt dies in § 2 Abs.1 Nr. 3 mit einem ausdrücklichen Open‑Source‑Verweis.
Dogmatisch unterscheidet der Gesetzgeber damit zwischen zwei Ebenen: der originären Entwicklung und Bereitstellung von OSS (typischerweise Community‑getrieben, nicht gewinnorientiert) und ihrer Integration in marktreife, entgeltlich oder datenbasiert verwertete Produkte. Innovation und freiwilliges Engagement sollen nicht unter eine Gefährdungshaftung gezogen werden; gleichzeitig soll sich ein gewerblich handelnder Integrator nicht hinter der fehlenden Gewinnorientierung der ursprünglichen OSS‑Community verstecken können.
Wann ist Open Source von der Produkthaftung ausgenommen?
Die Privilegierung knüpft materiell an zwei Kriterien an: “Open Source” und “außerhalb einer Geschäftstätigkeit”.
- Open Source: Gemeint ist freie und quelloffene Software, deren Quellcode offen zugänglich ist und die Nutzer frei verwenden, verändern und weitergeben können – im Einklang mit klassischen OSS‑Lizenzen.
- Außerhalb einer Geschäftstätigkeit: Weder Entwicklung noch Bereitstellung dürfen im Rahmen eines geschäftlichen Handelns erfolgen; keine Rolle spielt dabei, ob Entgelt verlangt wird oder nicht, sofern keine geschäftliche Verfolgung von Erwerbszwecken vorliegt. Das wirkt eingängig, auf den ersten Blick, ist aber im Tiefgang mit erheblichen Unsicherheiten verbunden (dazu gleich mehr).
Die Richtlinie und der Regierungsentwurf nennen ausdrücklich Beispiele, wann eine Geschäftstätigkeit anzunehmen ist: Bereitstellung gegen Entgelt, auch gegen personenbezogene Daten zu anderen Zwecken als rein sicherheitsbezogener Verbesserung, Vertrieb im Paket mit Hardware oder kommerziellen Diensten (dazu im Regierungsentwurf S. 27). Non‑Profit‑Organisationen, Stiftungen und akademische Einrichtungen bleiben privilegiert, solange sie OSS nicht als Teil kommerzieller Angebote oder Datenverwertungsmodelle bereitstellen.
Die Leitidee ist klar: Der „Hobbyentwickler“, die Community oder die universitäre Arbeitsgruppe sollen nicht verschuldensunabhängig für Schäden aus fehlerhafter OSS haften, selbst wenn ihre Software später von Dritten produktiv in sicherheitsrelevanten Kontexten genutzt wird. Die Haftung wird in solchen Fällen bewusst auf denjenigen verlagert, der die Bedingungen der Marktbeteiligung beherrscht: den gewerblichen Integrator.
Keine Definition von Opensource
Schade ist, was der Gesetzgeber sich auf Seite 27 des Regierungsentwurfs vorstellt: „Kennzeichnend für freie und Open-Source Software ist nach Erwägungsgrund 14 der ProdHaftRL, dass der Quellcode offen geteilt wird und die Nutzer frei auf die Software zugreifen und sie frei nutzen, verändern und weitergeben können, auch in veränderter Form.“ Das steht im zitierten Erwägungsgrund nicht, vielmehr wird dort nur die Bedeutung von solcher Software hervorgehoben. Und sowohl die Richtlinie (Art. 2 Abs. 2) als auch der Gesetzentwurf (§ 2 Abs.1 Nr.3) setzen den Begriff voraus, ohne ihn zu definieren. Auch wenn man sich also offenkundig an die gängige Definition anlehnt, wurde hier eine notwendige Chance verpasst.
Damit sind „Opensource-Software“ ebenso wie „geschäftliche Tätigkeit“ der Rechtsprechung überlassen. Insbesondere beim Entgelt, dass “ausschließlich zur Verbesserung der Sicherheit, Kompatibilität oder Interoperabilität der Software verwendet werden” darf, ergeben sich Probleme. Die GPLv3 etwa erlaubt Entgelt ganz ausdrücklich an mehreren Stellen, zentral in Abschnitt 4 („Conveying Verbatim Copies“) – die spezielle Ausnahme der Finanzierung von Infrastruktur sieht der Gesetzgeber aber in seinen Begründungen gar nicht vor. Dieser Streit wird sich über die Jahre ausweiten: Dem Gesetzgeber geht es offenkundig darum, keine kommerziellen, also nach Gewinn strebenden Projekte zu privilegieren. Er hatte nun die Option, dies funktional zu definieren (was dann immer Lücken lässt, wie man hier sieht), oder thematisch abzugrenzen. Die Ängstlichkeit bei Letzterem wird sich noch bitter rächen, denn auch OSS-Projekte müssen gewinnorientiert arbeiten, sie investieren nur anders. Dass explizit das Betreiben der notwendigen Infrastruktur als finanzieller Aspekt nicht abgebildet wird, dürfte problematisch sein.
Integration von OSS in kommerzielle Produkte: Haftung beim Integrator
Wird Open-Source-Software im Rahmen einer Geschäftstätigkeit in ein Produkt integriert, gilt der Integrator als Hersteller der Gesamtsoftware bzw. des Gesamtprodukts – mit allen Pflichten und Risiken der Produkthaftung. Dies gilt unabhängig davon, ob der integrierte OSS‑Code ursprünglich außerhalb jeglicher Geschäftstätigkeit bereitgestellt wurde; die Privilegierung schützt nur den originären Open‑Source‑Anbieter, nicht denjenigen, der diesen Code für ein kommerzielles Produkt nutzt. Praktisch bedeutet das:
- Der Integrator haftet verschuldensunabhängig für durch OSS‑Fehler verursachte Personen‑, Sach- und bestimmte Datenschäden, wenn OSS eine Produktkomponente darstellt.
- Der Endhersteller bleibt regelmäßig Anspruchsgegner der Geschädigten, selbst wenn OSS nur eine von mehreren Softwarekomponenten ist; interne Regressansprüche gegen kommerzielle Zulieferer bleiben möglich, gegen nicht‑kommerzielle OSS‑Communities dagegen prinzipiell nicht.
- Soweit OSS sich über Updates, Forks oder Konfiguration sicherheitsrelevant verändert, sind diese Änderungen dem Integrator bzw. Endhersteller als eigene Risikoverantwortung zuzurechnen, insbesondere wenn das Unternehmen „Kontrolle“ über das Produkt behält.
Diese Konzeption wird in der Begründung des Regierungsentwurfs ausdrücklich hervorgehoben: Wer OSS in einem kommerziellen Kontext produktiv macht, soll auch das Risiko ihrer Fehler tragen, weil er am besten in der Lage ist, Auswahl, Integration, Test und Monitoring zu steuern.
Grenzfälle: Wann wird Open Source selbst „geschäftlich“?
Für Open-Source-Entwickler mit Mischrollen – etwa Startups, die aus einem Community‑Projekt hervorgehen, oder Stiftungen mit Service‑Units – stellt sich die von mir oben aufgeworfene Frage, wann die Schwelle zur Geschäftstätigkeit überschritten ist. Entscheidend ist nicht das Label „Open Source“, sondern die funktionale Einbindung, wobei folgende Szenarien auf Basis des Gesetzestextes für mich absehbar sind:
- Selbsthosting von OSS mit entgeltlicher Support‑, Hosting‑ oder Integrationsdienstleistung kann dazu führen, dass die Bereitstellung als Teil einer Geschäftstätigkeit qualifiziert wird.
- Werden OSS‑Pakete mit proprietären Erweiterungen als „Enterprise‑Edition“ vertrieben, ist für diese Pakete unzweifelhaft eine Geschäftstätigkeit gegeben; für das weiterhin frei und nicht‑kommerziell bereitgestellte Community‑Release bleibt die Privilegierung grundsätzlich bestehen.
- Persönliche oder institutionelle Querfinanzierungen (Sponsoring, Grants) allein lösen noch keine Geschäftstätigkeit aus, solange die Software nicht als Teil eines entgeltlichen oder datenbasierten Angebots bereitgestellt wird; die Richtlinie will gerade solche Fördermodelle nicht sanktionieren.
Hier zeichnet sich ein gewisser Auslegungs- und Abgrenzungsbedarf ab, den die bisher existierende Literatur auch bereits anspricht: Die Grenze zwischen „außerhalb einer Geschäftstätigkeit“ und „kommerzialisierter OSS‑Distribution“ verläuft nicht entlang technischer, sondern entlang ökonomischer und organisatorischer Kriterien. Dass dabei erhebliche rechtliche Unsicherheiten in Zukunft bestehen, ist der schlechten Arbeit des Gesetzgebers geschuldet.
Offenlegung und Dokumentation
Auch wenn nicht‑kommerzielle OSS‑Anbieter grundsätzlich nicht dem Produkthaftungsregime unterfallen, können sie mittelbar in Verfahren hineingezogen werden, etwa als Dritte in Beweisaufnahme. Die neuen Offenlegungs- und Vermutungsregeln richten sich primär an Hersteller und Integratoren, die dem Anwendungsbereich unterfallen; Gerichte können von ihnen Dokumentation zu Softwarearchitektur, Update‑Praxis und Sicherheitskonzepten anfordern.
Für Unternehmen mit intensiver OSS‑Nutzung steigt damit der Druck, Transparenz über verwendete Komponenten, Versionen und Änderungen herstellen zu können – typischerweise über Software‑Bill‑of‑Materials‑Konzepte und interne Compliance‑Prozesse. OSS‑Communities sind zwar nicht im selben Maß adressiert, profitieren aber mittelbar von guter technischer Dokumentation und Release‑Governance, weil sie die Qualitätssicherung für Integratoren erleichtert und die Akzeptanz von OSS in sicherheitskritischen Bereichen stärkt.
Risikosteuerung in der Praxis
Die Reform des Produkthaftungsrechts markiert damit keinen zwingenden Bruch mit der Open‑Source‑Idee, sondern eine Neujustierung der Verantwortung: Nicht‑kommerzielle Entwickler werden bewusst vor unkalkulierbaren Gefährdungshaftungsrisiken geschützt, während Unternehmen, die aus OSS marktfähige Produkte schaffen, die volle Verantwortung für deren Sicherheit tragen.
Für beide Seiten ist es strategisch klug, diesen Rollenschnitt zu akzeptieren und die eigene Governance, Dokumentation und Kommunikation daran auszurichten. Aus Unternehmens- und Community‑Sicht lassen sich die praktischen Implikationen der Reform in wenigen Kernthemen bündeln. Wie könnten nun, je nach Rolle, zentrale To‑do-Agendas aussehen?
Unternehmen
- Systematische Erfassung und Bewertung der OSS‑Komponenten im Produktportfolio, einschließlich ihrer Herkunft, Lizenzen, Sicherheits‑Historie und Update‑Pfad.
- Etablierung eines OSS‑Governance‑Frameworks, das Auswahl, Integration, Test, Vulnerability‑Management und Updates klar regelt, insbesondere bei sicherheitsrelevanten Funktionen.
- Vertragsrechtliche Absicherung im Verhältnis zu kommerziellen Zulieferern (z. B. „OSS‑curated“ Distributoren, Managed‑Service‑Provider), inklusive Freistellungen, Auditrechten und Supportpflichten.
- Abstimmung mit AI‑Act‑, Cyber‑Resilience‑ und Produktsicherheits‑Compliance, um sicherzustellen, dass OSS‑Komponenten die regulatorisch geforderten Sicherheitsniveaus unterstützen und nicht unterlaufen.
OSS‑Projekte
- Klare Trennung zwischen Community‑Bereitstellung „außerhalb einer Geschäftstätigkeit“ und etwaigen kommerziellen Aktivitäten von Projekt‑nahen Unternehmen oder Service‑Einheiten.
- Transparente Hinweise auf den Charakter der Bereitstellung (nicht‑kommerziell, keine Produktgarantie, keine Markteignungszusicherung) und auf Verantwortlichkeit von Integratoren im kommerziellen Kontext.
- Pflege von technischen Best Practices (Code‑Review, Security‑Fixes, Versionierung), um die Attraktivität für Integratoren zu erhöhen und die faktische Sicherheit zu verbessern, auch wenn keine verschuldensunabhängige Haftung droht.
- Vorsichtige Positionierung bei Angebote wie „Enterprise‑Support“ oder „Commercial Add‑Ons“, die in einen geschäftlichen Kontext hineinführen und damit die Privilegierung gefährden können.
Erreichbarkeit:Per Mail, Rückruf, Threema oder Whatsapp.
Unsere Anwaltskanzlei im Raum Aachen ist spezialisiert auf Strafverteidigung, Cybercrime, Wirtschaftsstrafrecht samt Steuerstrafrecht sowie IT-Recht.
- Verbot verkleideter Telekommunikationsanlagen und der „Smarte Futterautomat“ - 15. Januar 2026
- Terrorgram-Studie zu “Teenage Terrorists” - 14. Januar 2026
- Phishing-Angriff auf Apple Pay: Bank muss mangels starker Kundenauthentifizierung erstatten - 14. Januar 2026
