Entscheidungshilfe Produkthaftung

Wenn eine Soft- oder Hardware nicht richtig funktioniert, können auch echte Schäden entstehen - wirtschaftliche Schäden oder auch Personenschäden. Wenn das mit einer gekauften Soft- oder Hardware passiert, hätte natürlich jeder es gern, dass jemand dafür haftet und einen entsprechenden Schadenersatz leistet. Die Hersteller wiederum wollen nicht oder nur in möglichst geringem Umfang haften, weil Schadenersatz vor allem Kosten sind.

Die Haftung für mögliche Schäden hat verschiedene rechtliche Grundlagen: die vertragliche Haftung aus dem Kaufvertrag, die gesetzliche Gewährleistung, die deliktische Haftung (das ist abhängig vom Verschuldensgrad) und die Produkthaftung.

Viele Open Source Hard- oder Software Projekte sind frei und kostenlos verfügbar. Da keine Einnahmen erzielt werden, wollen die Erschaffer natürlich auch nicht haften. Deshalb findet sich in allen Open Source Lizenzen ein möglichst weitgreifender Ausschluss dieser Haftung. Das funktioniert für die ersten drei Haftungsgrundlagen bis zu einem gewissen Grad. Das zu erläutern würde den Rahmen hier aber sprengen.

Die sogenannte Produkthaftung hingegen ist per Gesetz geregelt und kann nicht durch den Hersteller ausgeschlossen werden – weder einseitig in AGBs noch durch eine Vereinbarung mit dem Nutzer. Sie gilt immer. Sie ist in Deutschland durch das Produkthaftungsgesetz geregelt. EU-weit gelten vergleichbare Regeln, die in EU-Richtlinien vereinheitlicht werden.

Aktuell (Anfang 2026) ist eine Zwischenphase: die EU hat im Oktober 2024 eine neue Produkthaftungsrichtlinie verabschiedet (RL 2024/2853), die bis Ende 2026 in deutsches Recht überführt werden muss. Deutschland gilt (noch) ein auf der älteren Produkthaftungsrichtlinie von 1985 basierendes Gesetz. Die folgenden Ausführungen gründen auf der neuen Richtlinie.

Produkthaftung heißt, dass wenn durch den Fehler eines Produktes ein Schaden an einer Person oder Sache entsteht, der Hersteller haften muss. Nach der neuen Produkthaftungsrichtlinie sind auch Schäden an immateriellen Dingen wie z.B. Daten mit erfasst. Allerdings sind nur Schäden relevant, die Personen entstanden sind (Personenschaden, Sachschaden, Datenschaden). Unternehmen, Organisation oder staatliche Stellen können ihre Schäden hingegen nicht über das Produkthaftungsrecht einklagen, dies geht nur über andere Haftungsmechanismen (die aber vertraglich ausgeschlossen werden können).

Dabei ist völlig egal, was für ein Fehler das ist (Fehler in der Konstruktion, der Fabrikation oder der Anleitung) oder ob der Hersteller etwas dafürkann (Vorsatz, einfache oder grobe Fahrlässigkeit). Er muss immer haften.

Es gibt aber Grenzen. Der Hersteller haftet nicht für bei fehlerhafter Nutzung, bei offenkundigem Missbrauch, für Mängel, die erst beim Nutzer entstanden sind, für Mängel die er bei Herstellung des Produkts nach dem damaligen Stand von Wissenschaft und Technik gar nicht erkennen konnte und für Mängel, die auf zwingend einzuhaltenden rechtlichen Vorgaben beruhen. Allerdings kann der Hersteller durchaus haften, wenn die Fehler des Nutzers auf eine falsche oder mangelhafte Bedienungsanleitung zurückgeht oder wenn aus irgendwelchen Gründen der fehlerhafte Gebrauch vorhersehbar war.

Allerdings sind für nicht-kommerzielle Anbieter und Anbieter kostenloser Hard- und Software Ausnahmen vorgesehen. Diese sind für Open Source Projekte von besonderer Bedeutung und sollen näher beleuchtet werden.

Keine Haftung, wenn die Soft- oder Hardware kein Produkt ist

Open Source Soft- und Hardware lebt davon, daß der Nutzer bzw. Lizenznehmer die Soft- oder Hardware selber herstellt: wenn die Software selbst kompiliert wurde oder die Hardware selbst aus einem Hardwaredesign erstellt wurde, dann sind die Erschaffer nicht mehr in der Haftung. Allerdings ist die genaue Grenze zwischen Konzept und Produkt mangels Urteilen dazu nicht eindeutig geregelt.

Keine Haftung, wenn das Produkt nicht selbst in den Verkehr gebracht wurde

Wenn das Produkt durch einen Dritten in den Verkehr gebracht wird, dann haftet auch nur dieser. Wenn mehrere daran beteiligt sind, die z.B. jeweils Komponenten herstellen, dann haftet jeder für seinen Teil.

Keine Haftung, wenn das Produkt nicht im Rahmen einer Geschäftstätigkeit erstellt wurde

Besonders auf die Bedürfnisse von Open Source Projekten trifft die Ausnahme für fehlende Geschäftstätigkeit zu. Dabei ist allerdings zu beachten: fehlende Geschäftstätigkeit heißt nicht einfach nicht-kommerziell. Wenn man sich Unkosten ersetzen lässt oder regelmäßig mit eng verbundener Auftragsforschung Geld einnimmt oder im Dual Licensing einen Teil der Produkte gegen Geld abgibt – dann sind das alles Indizien für eine Geschäftstätigkeit – und damit für eine Haftung. Auch hier gilt (leider), dass die Grenzen vom Einzelfall abhängen und keine eindeutigen Aussagen zu treffen sind.

Diese drei Ausschlusskriterien gelten jedes für sich allein. Wenn Sie

ein „Nicht-Produkt“ in den Verkehr bringen

oder

ein Produkt nicht selbst in den Verkehr bringen

oder

ein Produkt außerhalb einer Geschäftstätigkeit in den Verkehr bringen

- in jedem dieser Fälle sind Sie von der Haftung nach dem Produkthaftungsgesetz befreit, auch wenn die beiden jeweils anderen Ausschlusskriterien nicht zutreffen.

Was ist auf dieser Basis für Open Source Soft- und Hardwareprojekten zu beachten bzw. zu prüfen?

Software gilt als Produkt

Software und weitere digitale Produkte wie z.B. Designdateien für Hardware werden (mit unwesentlichen Ausnahmen) nun auch als Produkt betrachtet. Das ist eine ganz wesentliche Abweichung von der bisherigen Praxis, wo Software allein kein Produkt darstellte.

Ist Ihre Soft-/Hardware ein Produkt im Sinne der Richtlinie?

Prüfen Sie, in welcher Form Sie eine Open Source Soft- und Hardware verfügbar machen, um noch nicht als Produkt zu gelten. Hier gibt es noch keine ganz verlässlichen „roten Linien“, weil die Richtlinie noch neu und damit solche Fragen noch nie zu Gericht gegangen sind.

Eine von Juristen vertretene Auffassung ist, dass der Sourcecode für eine Software noch kein Produkt darstellt, eine fertig kompilierte Version (quasi eine installationsbereite Setup-Datei) hingegen schon. Für Hardware wird die Grenze bei den CAD-Dateien gezogen: die Konstruktionsdateien / 3D-Modelle aus einem CAD-Programm werden noch nicht als Produkt angesehen, die (gerätespezifischen) Ansteuerungsdaten für einen 3D-Drucker oder ein vergleichbares Gerät (sog. Slicerdaten) hingegen schon.

Sind Sie der „In-Verkehr-Bringer“?

In der Produkthaftung haftet nur der In-Verkehr-Bringer. Das sind Sie ganz klar, wenn Sie ein digitales Produkt (z.B. eine fertige, installationsbereite Software) online anbieten oder ein physisches Produkt (eine schon gefertigte OSH) bereitstellen. Wenn Sie aber z.B. eine Bauanleitung für eine OSH aus am Markt verfügbaren Komponenten anbieten, sind Sie das nicht mehr – sondern die jeweiligen Anbieter dieser Komponenten.

Handeln Sie im Rahmen einer Geschäftstätigkeit?

Stellen Sie Ihre Open Source Soft- oder Hardware im Rahmen einer Geschäftstätigkeit bereit? Das ist ebenfalls eine komplexe und für den Nicht-Juristen etwas schwammige Aussage. Sie ist auch nicht klar im Gesetz geregelt (nur Einzelfälle), sondern Juristen argumentieren z.B. mit Verweis auf den sog. Blue Guide und den Cyber Resilience Act der EU (VO 2024/2847).

Der erste Punkt ist: Geschäftstätigkeit hängt nur in eine Richtung mit kommerzieller, gewerblicher Aktivität zusammen. Wenn Sie gewerblich aktiv sind, dann ist das klar eine Geschäftstätigkeit. Wenn Sie hingegen nicht kommerziell tätig sind, weil das Open Source Projekt kostenlos und in einer gemeinnützigen Forschungseinrichtung angesiedelt ist, heißt das leider noch lange nicht, dass das keine Geschäftstätigkeit ist.

Sie müssen das Open Source Projekt mit begleitenden Aktivitäten als Gesamtheit betrachten. Gründe, die dafürsprechen, dass ein Open Source Projekt im Rahmen einer Geschäftstätigkeit erfolgt, sind u.a. die folgenden:

Produkte, die im Rahmen von Sponsoring geliefert werden (Sponsoring ist, anders als eine Spende, mit einer Gegenleistung verknüpft – z.B. eine werbliche Erwähnung oder sonstige, meist immaterielle Vorteile für den Sponsor.)
Produkte, die zwar kostenlos sind, für die aber mit Daten „bezahlt“ wird
Wenn kommerziell Support-Services angeboten werden (Kommerziell heißt hier, dass ein Entgelt nicht nur die tatsächlichen Kosten deckt. Zur Frage der Kosten siehe auch im Prüfschema im Anhang.)
Dual Licensing: wenn für bestimmte Nutzergruppen Lizenzen kostenpflichtig sind (siehe auch Entscheidungshilfe Open Business Models)

Die folgenden Situationen hingegen stellen allein noch kein Indiz für eine Geschäftstätigkeit dar bzw. sprechen gegen eine Geschäftstätigkeit im Sinne des Produkthaftungsgesetzes:

Spendenfinanzierung, solange die Spenden nur die Kosten decken und keine Gewinnerzielungsabsicht besteht
Drittmittelfinanzierung der Entwicklung einer Open Source Soft- oder Hardware
Regelmäßige Veröffentlichungen zum Open Source Projekt oder diesem zugrunde liegenden Themen
Open Source Projekte von gemeinnützigen Organisationen, die sicherstellen, dass alle Einnahmen nach Abzug der Kosten für diese gemeinnützigen Zwecke verwendet werden
Integration in andere Produkte: wenn jemand anderes Ihre Open Source Soft- oder Hardware als Komponente in sein Produkt integriert, dann haften Sie nicht, wenn Sie nicht im Rahmen einer Geschäftstätigkeit agieren
Wie hoch ist das Risiko?

Zuletzt: Produkthaftung ist ein zivilrechtlicher Anspruch. Damit Sie haften, braucht es jemanden, der Sie in Haftung nehmen will. Es ist also sinnvoll durchzudenken, wie hoch Ihr Risiko bzw. das Ihrer Organisation ist: wie wahrscheinlich ist es, dass Sie in Haftung genommen werden und wie hoch wäre in diesem Fall der möglicherweise eintretende Schaden für Sie bzw. Ihre Organisation.

Auf dieser Basis können Sie dann überlegen, welche Vorkehrungen Sie treffen wollen.

Diese Fragestellungen werden ausführlicher im folgenden Prüfschema beleuchtet. Im Anhang finden sich typsiche Szenarien für Forschungseinrichtungen und wie diese im Lichte der Produkthaftung beurteilt werden.

Prüfschema zur Produkthaftung

Um zu beurteilen, ob Sie unter die gesetzliche Produkthaftung fallen, müssen Sie prüfen, ob Ihr Vorhaben wie oben beschrieben unter eines der drei Ausschlusskriterien fällt:

Ist Ihre Soft- oder Hardware ein Produkt im Sinne des Gesetzes?
Wer bringt Ihre Soft- oder Hardware in den Verkehr?
Wird Ihre Soft- oder Hardware im Rahmen einer Geschäftstätigkeit entwickelt bzw. in den Verkehr gebracht?
Außerdem sollten Sie Ihr individuelles Risiko prüfen, für Ihre Soft- oder Hardware tatsächlich aus Produkthaftung haftbar gemacht zu werden.

Dabei reicht es bei den ersten drei Kriterien aus, wenn eines erfüllt ist, damit Ihre OSS/OSH nicht unter die Produkthaftung fällt: kein Produkt im Sinne des Gesetzes sein ODER Sie haben die OSS/OSH nicht in den Verkehr gebracht ODER das Ganze ist nicht im Rahmen einer Geschäftstätigkeit erfolgt. Dazu kommt noch die Wahrscheinlichkeit bzw. das Risiko, tatsächlich haftbar gemacht zu werden.

Deshalb werden die folgenden Punkte im Folgenden näher beleuchtet. Leider ist die Beurteilung dieser Kriterien keine exakte Wissenschaft, sondern mit Unwägbarkeiten verbunden. Unwägbarkeit heißt hier, dass ein Begriff in einem Gesetz nicht absolut zweifelsfrei definiert wird, sondern – um das Gesetz handhabbar zu halten – breit definiert ist. Ob in einem bestimmten Fall der Begriff zutrifft oder nicht, hängt – wie die Juristen gern sagen – immer von den Umständen des Einzelfalls ab. Natürlich geschieht das nicht im luftleeren Raum: es werden Präzedenzfälle aus früheren Urteilen herangezogen, es wird Bezug genommen auf die Verwendung des Begriffs an anderer, ähnlicher Stelle oder es wird juristische Fachliteratur oder Kommentare zu Hilfe genommen.

Vieles von dem geschieht verbindlich erst im Rahmen eines Urteils – idealerweise das eines höheren Gerichts, dessen Urteile dann auch Leitwirkung für andere Gerichte haben.

Zwei der obigen Ausschlusskriterien haben eine solche Unwägbarkeit:

Der Begriff des Produkts ist für digitale Produkte im Rahmen der Produkthaftung bisher nicht genau definiert. Es gibt eine verbreitete Meinung unter Juristen, dass dazu gehört, dass ein Produkt ohne weitere manuelle Schritte direkt benutzbar ist. Dass man eine Software also nicht noch kompilieren oder ein Hardware-Design nicht noch in Slicer-Dateien für einen 3D-Drucker umwandeln muss. Aber diese Meinung ist nicht völlig unwidersprochen und noch nicht durch Urteile unterlegt. Es wird von heute (Mai 2026) wohl auch noch einige Jahre dauern, bis dazu höchstrichterliche Urteile mit hoffentlich größerer Klarheit vorliegen.

Der Begriff der Geschäftstätigkeit ist für den gewerblichen Bereich klar und unstrittig. Schwieriger wird es im Forschungsumfeld. Ist das regelmäßige Einwerben von Drittmitteln für Ihr Open Source Thema schon eine Geschäftstätigkeit? Ist das Anbieten oder Durchführen von Auftragsforschung oder Dienstleistungen im Themenbereich Ihres Open Source Projektes schon „schädlich“? Diese Fragen sind bisher im Kontext Produkthaftung noch nicht höchstrichterlich behandelt worden, vor allem deshalb, weil Produkthaftung bisher nur physische Produkte betraf, die höchst selten von Forschungseinrichtungen erstellt und in Verkehr gebracht werden. Das wird sich mit dem neuen Produkthaftungsrecht ändern, da nun auch digitale Produkte betroffen sind. Auch hier wird es sicher einige Jahre dauern, bis mehr Klarheit besteht. Aber das erfordert, dass in einem konkreten Fall zwei Parteien den Streit vor Gericht und dann noch durch mehrere Instanzen tragen.

Nicht zuletzt haben Sie die Unwägbarkeit, ob Ihre OSS/OSH tatsächlich konkret einen Schaden verursacht, ob der Geschädigte Sie dafür auch in Haftung nehmen will und wie gut seine Chancen auf Erfolg dabei sind.

Ist es ein Produkt im Sinne des Gesetzes?

Keine Produkthaftung ohne Produkt. Das ist einfach für physische Produkte: wenn etwas gebrauchsfertig ist, dann ist es ein Produkt. Allerdings sind in der Neufassung der Produkthaftung auch Software und digitale Produkte berücksichtigt. Hier wird es komplizierter, weil die genaue Ausgestaltung des Begriffs Produkt hier noch nicht geklärt ist. Dies wird in den kommenden Jahren durch Gerichte erfolgen, bis dahin bestehen hier Unsicherheiten.

Im Kern lässt sich die Produkteigenschaft nach folgendem Entscheidungsbaum beurteilen. Rote Kästen als Endpunkt bedeuten: Ihre Soft- oder Hardware ist ein Produkt und es fällt, sofern keine anderen Ausschlusskriterien zutreffen, unter die Produkthaftung. Grün bedeutet, Ihre Soft- oder Hardware ist kein Produkt und fällt nicht unter die Produkthaftung. Gelbe Kästen sind aktuell unklar bzw. risikobehaftet, eine Entscheidung „Produkt oder nicht“ ist heute (noch) nicht zweifelsfrei möglich.

Flowchart

Teilweise werden fremde Produkte durch OSS/OSH-Projekte nur verändert. Hier muss geprüft werden, ob dies eine erhebliche Modifikation darstellt und ob Sie für diese Modifikation in Produkthaftung genommen werden könnten:

Stufe 1: Handelt es sich nach dem branchenspezifischen Produktsicherheitsrecht um eine wesentliche Veränderung?

Ja: Wesentliche Änderung liegt vor; zu Stufe 3 springen.

Bei Medizinprodukten: Wiederaufbereitung; Änderung der Zweckbestimmung; Auswirkungen auf Konformität des Produkts
Bei Verbraucherprodukten: Art. 13 Abs. 3 GPSR
Bei KI: Art. 3 Nr. 23 KI-VO

Nein: Ob Änderung trotzdem wesentlich ist --> Stufe 2

Stufe 2: Handelt es sich nach den Umständen des Einzelfalls um eine wesentliche Änderung?

Frage 1: Wird ursprüngliche Leistung/Zweck oder die ursprüngliche Art des Produkts verändert, ohne dass dies in der ursprünglichen Risikobewertung des Herstellers vorgesehen war? - Ja: --> Frage 2 beantworten - Nein: Keine wesentliche Änderung --> keine Produkthaftung für Modifikation

Frage 2: Ändert sich durch die Änderung die Art der Gefahr, wird eine neue Gefahr geschaffen oder das Risikoniveau erhöht? - Ja: --> Zu Schritt 3 übergehen - Nein: Keine wesentliche Änderung à keine Produkthaftung für Modifikation

Stufe 3: Einverständnis des ursprünglichen Herstellers?

Ja: Keine Produkthaftung für die wesentliche Änderung (ursprünglicher Hersteller haftet alleine)
Nein: Wesentliche Änderung; Produkthaftung für Modifikation (Keine Haftung, wenn nachgewiesen werden kann, dass der Schaden mit einem Produktteil zusammenhängt, der von der Änderung nicht betroffen ist)

Sind Sie der „In-Verkehr-Bringer“?

In-Verkehr-Bringer ist, wer ein fertiges Produkt erstmals für andere verfügbar macht – es also aktiv bereitstellt, damit andere es nutzen können. Das kann ein Download-Angebot sein, ein Versand, eine Übergabe oder auch das Einstellen in einen App-Store. Entscheidend ist der aktive Schritt: Man stellt etwas Fertiges, Nutzbares nach außen zur Verfügung.

Wenn mehrere Beteiligte jeweils Komponenten zu einem Gesamtprodukt beisteuern, haftet jeder nur für seinen eigenen Teil – also für die Komponente, die er selbst in Verkehr gebracht hat. Wer hingegen ein fremdes Produkt unverändert weitergibt oder weiterverkauft, kann dadurch selbst zum In-Verkehr-Bringer werden.

Gerade für Open-Source-Entwicklerinnen und -Entwickler gibt es einige Möglichkeiten, gar nicht erst in die Rolle des In-Verkehr-Bringers zu geraten: Wer eine Bauanleitung veröffentlicht, die auf frei am Markt verfügbare Komponenten verweist, bringt selbst nichts in Verkehr. Die Haftung liegt bei den jeweiligen Anbietern dieser Komponenten. Ähnlich verhält es sich, wenn man Konstruktionsdateien oder Quellcode bereitstellt und der Nutzer daraus selbst das fertige Produkt erzeugt – etwa indem er die Software selbst kompiliert oder die Hardware selbst fertigt. In diesem Fall ist der Nutzer derjenige, der das Produkt herstellt und ggf. in Verkehr bringt, nicht der Entwickler.

Der Kerngedanke ist also: Je mehr Eigenleistung der Nutzer erbringen muss, um vom bereitgestellten Material zu einem nutzbaren Produkt zu kommen, desto eher ist man als Entwickler raus aus der Haftung. Wer hingegen eine fertige, sofort einsetzbare Lösung anbietet – eine installationsbereite Software, ein fertiges Gerät – der bringt klar ein Produkt in Verkehr.

Handeln Sie im Rahmen einer Geschäftstätigkeit?

Die Frage der Geschäftstätigkeit ist bezogen auf die Produkthaftung nicht trivial, weil nicht einfach zu beantworten. Das liegt auch daran, dass sie nicht vollständig in der Produkthaftungsrichtlinie geregelt ist (nur Einzelfälle). Juristen argumentieren deshalb z.B. mit Verweis auf den sog. Blue Guide der EU und den Cyber Resilience Act der EU (VO 2024/2847).

Völlig eindeutig liegt Geschäftstätigkeit vor, wenn Sie OSS/OSH im Rahmen einer kommerziellen, gewerblichen Aktivität bereitstellen. Wenn Sie als gewerbliches Unternehmen OSS/OSH anbieten und über begleitende Services Geld verdienen, dann ist es eine Geschäftstätigkeit. Genauso, wie wenn Sie als Unternehmen zu ihren Produkten eine kostenlose Open-Source-Steuerungssoftware oder ein Open-Hardware-Bauteil anbieten.

Diffiziler wird es, wenn Sie nicht generell kommerziell tätig sind, weil das Open-Source-Projekt kostenlos und in einer gemeinnützigen Forschungseinrichtung angesiedelt ist. Hier können Sie trotzdem in den Bereich der Geschäftstätigkeit. Deshalb im Folgenden eine Liste von Indizien, die für oder gegen eine Geschäftstätigkeit sprechen. Allerdings gilt auch hier die Einschränkung: das ist nicht eindeutig und 100% verlässlich, weil bisher passende Rechtsprechung fehlt.

Indiz	Geschäftstätigkeit?	Ausnahmen /Sonderfälle
Produkt wird nur gegen einen Preis zur Verfügung gestellt	Ja	Es ist dabei unerheblich, ob der Kunde selbst zahlt oder ob ein Dritter (z.B. eine staatliche Stelle) für den Kunden bezahlt.
Produkt wird nur gegen personenbezogene Daten zur Verfügung gestellt	Ja	Keine Geschäftstätigkeit, wenn Nutzung personenbezogener Daten ausschließlich zur Verbesserung der Sicherheit, Kompatibilität oder Interoperabilität der Software dient.
Dual Licensing (unterschiedliche Lizenzen für unterschiedliche Nutzergruppen, eine oder mehrere Lizenzen nur gegen Bezahlung)	Ja
Direkte oder indirekte Gewinnbeteiligung an Vertrieb durch einen Dritten, etwa vertraglich vereinbarte Rückflüsse (z.B. durch Know-How-Lizenz)	Ja
Kontrolle eines bzw. Beteiligung an Drittunternehmen, welches durch Vertrieb des Produkts oder zusammenhängender Dienstleistungen Gewinn erwirtschaftet	Ja	Für Geschäftstätigkeit ist wohl selbst eine Minderheitsbeteiligung ausreichend.
Produkte wird im Rahmen einer Sponsoring-Kampagne geliefert	Ja
Angebot von Support-Services (technische Unterstützungsdienstleistungen)	Ja	Keine Geschäftstätigkeit, wenn kein Entgelt verlangt oder Entgelt lediglich der Deckung der Kosten dient.
Angebot von anderen Dienstleistungen im Zusammenhang mit Produkt, etwa Ergebnisinterpretation	Ja	Keine Geschäftstätigkeit, wenn kein Entgelt verlangt oder Entgelt lediglich der Deckung der Kosten dient.
Organisation in Form eines Unternehmens	Ja	Genügt wohl alleine nicht, um Geschäftstätigkeit zu begründen, kann aber ein schwaches Indiz sein.
Bereitstellung einer freien und quelloffenen Software in offenen Speicherorten	Neutral	Kann nach dem EU Blue Guide ein schwaches Indiz für Geschäftstätigkeit sein (strittig).
Integration in andere Produkte	Neutral	Hersteller von Komponenten haftet ebenfalls nur dann, wenn er diese im Rahmen einer Geschäftstätigkeit vertreibt.
Produkt quelloffener Software mit digitalen Elementen wird von den Herstellern finanziell unterstützt oder Hersteller tragen zur Entwicklung eines solchen Produkts bei	Neutral
Regelmäßige Veröffentlichungen	Neutral
Regelmäßigkeit der Bereitstellung, die Eigenschaften des Produkts und die Absichten des Lieferanten	Neutral	Diese Indizien können im Einzelfall für oder gegen eine Geschäftstätigkeit angebracht werden.
Organisation als NPO (Gemeinnützige Organisation)	Neutral	Jedenfalls spricht gegen eine Geschäftstätigkeit, wenn die NPO so angelegt ist, dass sichergestellt ist, dass alle Einnahmen nach Abzug der Kosten zur Verwirklichung der gemeinnützigen Ziele verwendet werden.
Gelegentliche Lieferungen von Produkten durch karitative Organisation	Nein
Gelegentliche Lieferungen von Produkten durch Hobbyist	Nein
Eigener Angestellter bietet unabhängig, etwa nebenberuflich oder im Rahmen einer Tätigkeit bei einem Drittunternehmen, entgeltliche Dienstleistungen in Zusammenhang mit Produkt an	Nein	Es kann Geschäftstätigkeit vorliegen, wenn man durch Rückflüsse oder vertragliche Vereinbarungen/Lizenzen trotzdem mittelbar oder unmittelbar Gewinn erzielt.
Unabhängiges Drittunternehmen bietet entgeltliche Dienstleistungen für das Produkt an	Nein	Es kann Geschäftstätigkeit vorliegen, wenn man durch Rückflüsse oder vertragliche Vereinbarungen/Lizenzen trotzdem mittelbar oder unmittelbar Gewinn erzielt.
Spendenfinanzierung	Nein	Stellt ausnahmsweise Geschäftstätigkeit dar, wenn angenommene Spenden die mit Konzeption, Entwicklung und Bereitstellung des Produkts verbundenen Kosten übersteigen.
Drittmittelfinanzierte Produktentwicklung	Nein	Umstände sowie Art und Weise der Finanzierung der Produktentwicklung sind unerheblich.

Zur Frage der Kosten und des Gewinns:

Oben wurde mehrfach darauf verwiesen, dass Einnahmen eher unschädlich sind, solange sie nur höchstens die unmittelbar entstehenden Kosten decken und damit keinen Gewinn im kaufmännischen Sinn erzeugen. Kosten bedeutet hier, dass wie in einer Vollkostenrechnung, wie sie in vielen Forschungseinrichtungen bekannt und geregelt ist, alle unmittelbar für die Herstellung einer Leistung oder eines Produktes anfallenden und zuordenbaren Kosten berücksichtigt werden können. Dies sind

Personalkosten (aber nicht pauschal halbe oder volle Stellen, sondern die konkret notwendigen Personenstunden oder -tage),
Sachkosten wie z.B. Verbrauchsmaterial, Bauteile oder Energiekosten,
Anlagenkosten in Form von Abschreibungen (anteiliges Umlegen der Beschaffungskosten auf die Nutzung), sowie
Verwaltungs- und sonstige Nebenkosten, in der Regel durch Umlagen auf Mitarbeiterkosten oder andere Größen (landläufig auch Overheads genannt).

Nicht berücksichtigt werden dürfen dabei die kalkulatorischen Gewinne, die die Vollkostenrechnung üblicherweise verlangt. Wer einen – wenn auch noch so niedrigen – Gewinn einkalkuliert, handelt mit größerer Wahrscheinlichkeit im Rahmen einer Geschäftstätigkeit.

Wie hoch ist Ihr individuelles Risiko?

Wir wollen mit diesem Text nicht „die Pferde scheu machen“. Produkthaftung als zivilrechtlicher Anspruch braucht immer jemanden, der einen konkreten Schaden hat und Sie dafür aktiv in Haftung nehmen will. Ihr individuelles Risiko aus der Produkthaftung hängt von mehreren, sehr individuellen Faktoren ab.

Dabei ist auch zu berücksichtigen, dass die Produkthaftung Schäden an oder von Personen betrachtet. Unternehmen, Organisationen oder Behörden hingegen können keine Ansprüche aus der Produkthaftung ableiten. Das senkt die Wahrscheinlichkeit, dass Sie in uneindeutigen Fällen in Haftung genommen werden, erheblich: Unternehmen und Behörden sind viel eher dazu bereit, Haftungsfragen vor Gericht zu klären, teilweise sind sie durch die Sorgfaltspflicht sogar dazu verpflichtet. Privatpersonen sind meist viel zurückhaltender, weil sie die hohen Anwalts- und Gerichtskosten im Falle des Unterliegens vor Gericht selbst tragen müssen.

Wie wahrscheinlich ist es, dass ein Schaden entsteht?

Diese Wahrscheinlichkeit ist abhängig von der Qualität und der Qualitätskontrolle, die Sie in Ihrem OSS-/OSH-Projekt pflegen: ein gutes, umfangreich und in möglichst vielen Konstellationen getestetes Produkt hat seltener eine Fehlfunktion. Diesen Faktor können Sie und Ihre Mitstreiter gut beeinflussen.

Außerdem hängt diese Wahrscheinlichkeit von der typischen Nutzung ihrer OSS/OSH ab. Eine Spielsoftware verursacht eher selten einen „richtigen“ Schaden, bei einer Software zur Produktionssteuerung ist das schon viel wahrscheinlicher. Natürlich gibt es auch unterschiedlich nutzbare Produkte wie z.B. Graphiksoftware, die gewerblich, aber auch privat genutzt wird.

Die Schadenswahrscheinlichkeit hängt dabei nicht nur vom Produkt selbst, sondern auch der Qualität und Verständlichkeit der Dokumentation und einer Bedienungsanleitung ab, weil damit Fehler bei der Fertigstellung (insb. bei OSH) und im Betrieb reduziert werden.

Wie hoch wird ein möglicher Schaden wahrscheinlich ausfallen?

Je nach Art und Nutzungsweise Ihrer OSS/OSH sind unterschiedliche Schäden möglich. Das kann von einer verschwendeten Stunde Arbeitszeit bis hin zu schweren gesundheitlichen Schäden reichen. Glücklicherweise haben die meisten Open Source Produkte nicht das Potential für so schwere Schäden. Bei OSS ist das Schadenspotential vermutlich geringer als bei OSH.

Hier empfiehlt es sich, wenn Sie das nicht sowieso getan haben, einmal mögliche Anwendungen, dabei möglicherweise auftretende Fehlfunktionen und deren Auswirkungen in Ruhe gedanklich durchzuspielen. Ein gutes Verständnis davon, was Ihre Nutzer mit Ihrer OSS/OSH typsicherweise tun, hilft dabei natürlich.

Wie wahrscheinlich ist es, dass ein Geschädigter Sie im Schadensfall erfolgreich in Anspruch nimmt / verklagt?

Auch wenn ein Schaden eingetreten ist, bedeutet das noch nicht, dass Sie tatsächlich haften müssen. Dazu muss der Geschädigte erst einmal einen Anspruch stellen – direkt an Sie oder über ein Gericht. Das ist mit Aufwand verbunden: der Schaden muss detailliert dargestellt und beziffert werden, es muss ggf. belegt werden, dass ein Mangel Ihres Produkts den Schaden verursacht hat und nicht z.B. eine Fehlbedienung. In unklaren Fällen oder wenn Sie den Anspruch ablehnen, muss ein unter Umständen langwieriger, teurer Gerichtsweg beschritten werden. Dazu ist nicht jeder Geschädigte bereit oder in der Lage.

Abhängig von Höhe und Schwere des Schadens, aber auch vielleicht weil es sich bei Ihrem Projekt um ein Open Source Projekt handelt, verzichten Geschädigte auf Ihre Ansprüche. Das ist wahrscheinlicher bei reinen Sachschäden. Sobald Personenschäden dazu kommen, sind oft allerdings auch Kranken- oder Unfallversicherungen mit im Spiel, die solche Ansprüche mit größter Wahrscheinlichkeit auch durchzusetzen versuchen.

Alles in allem müssen sie diese drei Punkte gemeinsam abwägen. Erst in der Gesamtschau können Sie Ihr Risiko abschätzen, haften zu müssen. Bei einer sehr kleinen Wahrscheinlichkeit dafür in Haftung genommen zu werden, brauchen Sie sich dann um die obenstehenden Ausschlusskriterien keine großen Gedanken mehr machen. Oder Sie können dort bestehende Risiken, z.B. ob Ihre Software-Code nun als Produkt gilt oder ob bestimmte Aktivitäten eine Geschäftstätigkeit darstellen, zumindest viel leichter akzeptieren.

Ist die Wahrscheinlichkeit haften zu müssen hingegen groß, sollten Sie sich sehr sicher sein, was die Ausschlusskriterien betrifft. Und Sie sollten entsprechend vorsorgen. Das sind in erster Linie natürlich Bestrebungen, das Haftungsrisiko zu verkleinern – das Produkt sicherer machen und das Schadenspotential reduzieren: Dazu kann aber auch das Abschließen einer geeigneten Produkthaftpflichtversicherung gehören.

Zusammenfassung und Praxisempfehlung

Die Analyse unter dem neuen Produkthaftungsrecht zeigt, dass die Produkthaftung für digitale Inhalte stark an deren funktionale Wirkung gebunden ist. Software wird erst dann als Produkt erfasst, wenn sie in lauffähigen Maschinencode übersetzt; digitale Konstruktionsunterlagen nur dann, wenn sie in maschinenlesbare Formate (z. B. G-Code für 3D-Drucker) gebracht wurden. Reiner Source-Code oder unbearbeitete 3D-Modelle sollten hingegen als bloße Informationen nicht der Produkthaftung unterliegen.

Aus dieser Differenzierung lassen sich für Open-Source-Entwickler und -Hersteller mehrere praktische Empfehlungen ableiten:

Haftung bewusst begrenzen: Projekte sollten, soweit möglich, zunächst in Form von nicht-kompiliertem Source-Code oder rohen 3D-Modellen bereitgestellt werden, die noch kein Produkt darstellen. Die Umwandlung in ausführbaren Code oder gerätespezifische Ansteuerungsdateien (G-Code) erfolgt dann beim Nutzer, der diese Transformationsschritte in eigener Verantwortung durchführt.
Dokumentationen und Anleitungen sorgfältig und risikobewusst gestalten: Sollen zusätzlich Anleitungen bereitgestellt werden, ist unbedingt auf automatisierte Skripte oder Schritt-für-Schritt-Anleitungen, die den Weg zum funktionsfähigen Endprodukt praktisch vollständig vorzeichnen, zu verzichten, da andernfalls ein Umgehungstatbestand vorliegen könnte, der Produkthaftung wieder eröffnet.
Bewusste Open-Source-Strategie entwickeln: Insbesondere bei Open-Source-Projekten sollte eine klare Strategie entwickelt werden, ob Projekte als bloße Information oder funktionales digitales Element vertrieben werden sollen. Gerade bei Dual-Licensing-Modellen, Sponsoring- oder entgeltlichen Support-Strukturen ist es ratsam, auf die Bereitstellung von unmittelbar lauffähigem Code oder druckerspezifische Ansteuerungsdateien zu verzichten, weil hier eine Geschäftstätigkeit angenommen werden kann und folglich eine verschuldensunabhängige Produkthaftung droht.
Berücksichtigung der Besonderheiten bei Python-Code und Software Library Code: Python-Code und anderer Quellcode, der ausnahmsweise nicht kompiliert werden muss, um lauffähig zu werden, stellt stets ein Produkt dar; eine Bereitstellung von Software Library Code kann eine Komponentenherstellerhaftung begründen.
Regelmäßige Risikoprüfung: Da die Details der Produkteigenschaft – gerade bei CAD-Dateien bzw. 3D-Modellen – noch nicht geklärt sind, empfiehlt sich eine regelmäßige Überprüfung der Rechtslage und eventuelle Anpassung der eigenen Projektstruktur.

Die neue Produkthaftungsrichtlinie eröffnet für OSS und OSH Handlungsspielräume zur gezielten Risikosteuerung, sofern die Bereitstellung ausschließlich auf Informationsebene erfolgt. Durch eine sorgfältige Gestaltung von Bereitstellung, Dokumentation und Nutzungsanweisungen lässt sich das Risiko einer verschuldensunabhängigen Produkthaftung maßgeblich reduzieren, ohne gegen das unionsrechtliche Umgehungsverbot zu verstoßen.

Anhang: für Forschungseinrichtungen typische Szenarien

Produkteigenschaft

Führen folgende Szenarien zu dem Schluss, dass die betreffende Open Source Hardware bzw. Software ein Produkt im Sinne der Produkthaftungsrichtlinie ist?

Ein Elektronikdesign (Schaltung, Platinenentwurf/-layout) wird als CAD-Datei (oder was auch immer in dem Bereich üblich ist) zur Verfügung gestellt. Die Beschaffung der Bauteile und die Platinenfertigung übernimmt der Nutzer.	Hier ist die Rechtslage unklar. Teilweise wird die Meinung vertreten, dass schon CAD-Dateien ein Produkt darstellen. Teilweise wird die Auffassung vertreten, dass die Datei unmittelbar die Steuerung der Maschine erlauben muss: damit wäre es kein Produkt. Anleitungen und Teilelisten ändern an der Beurteilung nichts.
Wie (1), nur dass noch eine ausführliche Anleitung zur Beschaffung von Bauteilen, Platine und Bestückung beigefügt ist.
Wie (2), nur dass ein Manufacturing File für die Platinenherstellung mitgeliefert wird.	Manufacturing Files bestehen aus mehreren Arten von Dateien: Gerber-Dateien, Bohrdaten (Excellon), Pick-and-Place-Datei und Stückliste. Diese können in unterschiedlichem Maß automatische Prozesse steuern, so dass mehr für ein Produkt spricht als dagegen.
Ein OSH-Projekt, welches eine ausführliche, für einen normalen Fachmann ausreichende Montageanleitung inklusive Teileliste und Spezifikationen bereitstellt. Dabei ist nur noch die Beschaffung handelsüblicher Komponenten (keine eigene Fertigung) und deren Montage erforderlich.	Kein Produkt
Welche Art von Datei für 3D-gedruckte OSH-Projekte stellt noch kein Produkt dar? CAD-Dateien, die eine Änderung des Designs bzw. Modells erlauben Mesh-Dateien / Druckvorlage, die als Input für Slicer dienen (.STL, .OBJ, .3MF) Slicer-Ausgaben / druckerspezifische Ansteuerungsdateien (.gcode)	Auch hier ist die Rechtslage unklar. Teilweise wird die Meinung vertreten, dass schon CAD-Dateien ein Produkt darstellen (also a – c). Teilweise wird die Auffassung vertreten, dass die Datei unmittelbar die Steuerung der Maschine erlauben muss. Hier wären nur die unter c genannten Dateien als Produkt zu sehen.
(5) Software in Form von Source Code Source Code mit ausführlicher Anleitung zum Kompilieren Software Library Code Kompilierte Anwendung Source Code, der aber keine Kompilierung mehr nötig hat, wie z.B. Python-Code	ist kein Produkt, weil nicht allein lauffähig, weil nicht kompiliert wie a), allerdings ggf. Wertung als Umgehungstatbestand ist kein Produkt, weil nicht alleine lauffähig (Library). Wenn allerdings als kompilierte Komponente in einem lauffähigen Programm verwendet, kann dies zur Haftung für diese Komponente führen. Produkt sehr wahrscheinlich Produkt

Geschäftstätigkeit

Führen die folgenden Szenarien zu dem Schluss, dass die eigentliche Open Source Hardware bzw. Software im Rahmen einer Geschäftstätigkeit im Sinne der Produkthaftungsrichtlinie entstanden ist?

Eine Open Source Hardware bzw. Software wird für bestimmte Nutzergruppen auch als kommerzielle Lizenz angeboten, während andere Nutzergruppen eine klassische Open Source Lizenz nutzen dürfen.	Ja, Geschäftstätigkeit Anders sieht es aus, wenn für kommerzielle und nichtkommerzielle Nutzer unterschiedliche Software bereitgestellt wird. Die Unterschiede sollten allerdings nicht nur kosmetischer Natur sein.
Eine Forschungseinrichtung erbringt im Zusammenhang mit einer Open Source Hardware bzw. Software gelegentlich Dienstleistungen wie z.B. Hilfe bei Implementierung, Planungsunterstützung oder Ergebnisinterpretation etc.	Eher keine Geschäftstätigkeit, wenn rein kostendeckend angeboten Ja, Geschäftstätigkeit, wenn Gewinn erzielt wird
Eine Forschungseinrichtung nutzt gelegentlich eine eigene Open Source Hardware bzw. Software, um gemeinsam mit einem Unternehmen in einem Verbundvorhaben (ZIM, Industrielle Gemeinschaftsforschung etc.) an neuen Produkten für das Unternehmen zu forschen.	Eher keine Geschäftstätigkeit. Gehaftet werden müsste nur für die im Rahmen des Forschungsprojektes bereitgestellte OSS/OSH (abhängig von den vertraglichen Regelungen innerhalb des Verbundvorhabens). Für außerhalb des Projektes bereitgestellte OSS/OSH hat dies jedoch keine Auswirkungen bzgl. der Frage Geschäftstätigkeit.
Eine Forschungseinrichtung nutzt die Kompetenzen (Wissen, Algorithmen, Daten), die zur eigenen Open Source Hardware bzw. Software geführt haben, auch, um ohne direkten Einsatz dieser Open Source Hardware bzw. Software Dienstleistungen zu erbringen.	Keine Geschäftstätigkeit
Eine Forschungseinrichtung nutzt die Kompetenzen (Wissen, Algorithmen, Daten), die zur eigenen Open Source Hardware bzw. Software geführt haben, auch, um ohne direkten Einsatz dieser Open Source Hardware bzw. Software gemeinsam mit einem Unternehmen in einem Verbundvorhaben (ZIM, Industrielle Gemeinschaftsforschung etc.) an neuen Produkten für das Unternehmen zu forschen.	Keine Geschäftstätigkeit
Falls die obigen Szenarien eine Geschäftstätigkeit vermuten lassen, kann dieses „geheilt“ werden, wenn die Dienstleistungen durch eine dritte Rechtsperson erfolgen: den Wissenschaftler als Privatperson im Rahmen einer Nebentätigkeit ein im Eigentum Dritter befindliches Unternehmen, welches den Wissenschaftler im Rahmen einer Nebentätigkeit beschäftigt ein im Eigentum Dritter befindliches Unternehmen, in welchem der Wissenschaftler andere die Dienstleistung erbringende Mitarbeiter anleitet und unterstützt	a), b) und c) führen dazu, dass keine Geschäftstätigkeit vorliegt
wie b) & c), nur dass Rückflüsse vom Unternehmen an die Forschungseinrichtung gehen, z.B. als eine Art Know-how-Lizenz (aber keine kommerzielle Lizenz für die Open Source Hardware bzw. Software) wie b) & c), nur dass die Forschungseinrichtung am Unternehmen eine Minderheitsbeteiligung hält	d) und e) hingegen ändern nichts am Status der Geschäftstätigkeit, da die Forschungseinrichtung unmittelbar oder mittelbar von den Gewinnen profitiert
wie b) & c), nur dass die Forschungseinrichtung das Unternehmen mittelbar kontrolliert (der prototypische „Verein der Freunde und Förderer der Forschungseinrichtung“, dem dann ganz oder teilweise das Unternehmen gehört)	f) ändert vermutlich auch eher nichts am Status der Geschäftstätigkeit. Zumal könnte hier auch ein Umgehungstatbestand unterstellt werden. Alles in allem kein eindeutiger Fall.
Eine Forschungseinrichtung entwickelt die eigene Open Source Hardware bzw. Software signifikant weiter (allein oder mit Unternehmen) und gibt diese Weiterentwicklungen ohne die eigene Open Source Hardware bzw. Software gegen Entgelt ab.	Wenn die OSS/OSH nicht in der Weiterentwicklung erhalten ist, spricht das gegen eine Geschäftstätigkeit bezogen auf die OSS/OSH. Wenn die die OSS/OSH hingegen Bestandteil ist, führt das wahrscheinlich dazu, dass auch für die ursprüngliche OSS/OSH eine Geschäftstätigkeit angenommen wird.