Zum Inhalt

Rechtliche Aspekte

Schutzrechte

Geistiges Eigentum, worunter auch Software oder Designs und Pläne für Hardware fallen, sind in der EU und vielen anderen Ländern geschützt. Prinzipiell kann dieser Schutz auf vier Wegen erfolgen:

1) Urheberrecht

2) Patentrecht

3) Geheimhaltung

4) Einzelvertragliche Regeln

Die Punkte c) und über weite Strecken auch d) sollen hier außen vor bleiben, weil sie dem Grundgedanken von Open Source widersprechen und eher für die proprietäre, kommerzielle Verwertung interessant sind.

Urheberrecht

Das Urheberrecht ist die wichtigste Grundlage für den Schutz und die Lizenzierung von Open Source. Es gilt für sämtliche schöpferischen Ausdrucksformen. Für Hardware gehören dazu Schaltpläne, PCB‑Layouts, CAD‑Modelle, Stücklisten, Firmware‑Quellcode sowie alle begleitenden Dokumente (Handbücher, Tutorials, Bilder, Videos). Der Schutz entsteht automatisch mit der Schöpfung des Werkes; eine gesonderte Registrierung ist nicht erforderlich. Es ist an sich nicht übertragbar und gilt bis 70 Jahre nach Tod des Urhebers.

Das Nutzungsrecht an den Werken kann hingegen frei übertragen werden. Allerdings beschränkt sich der Schutz auf die konkrete Ausgestaltung des Werkes: wenn eine Grundidee neu formuliert oder eine Software zwar in gleicher Art, aber neu programmiert wird (neuer Sourcecode), wirkt der Schutz nicht mehr. Ebenso umgeht die Umformulierung eines Textes, auch wenn die Aussage gleich bleibt, den Urheberrechtsschutz.

Dennoch beruhen alle Nutzungskonzepte und Lizenzen für Open Source Soft- oder Hardware auf dem urheberrechtlichen Schutz.

Patentrecht

Ein weiterer Weg OSH zu schützen, ist das Patent. Ein erteiltes Patent bietet rechtlich den stärksten Schutz gegen unerlaubte Verwendung – jedoch nur für 20 Jahre. Allerdings dürfen nur Erfindungen patentiert werden, nicht alle schöpferischen Werke. Patentierbar sind nur technische Erfindungen, die neu, aus erfinderischer Tätigkeit resultieren, technischer Natur und gewerblich anwendbar sind. Das schließt viele Entwicklungen und die allermeiste Software von vornherein aus. Außerdem müssen Patente beantragt werden und sind mit Kosten verbunden.

Für OSH bieten Patente kaum Mehrwert, weil bei Open Source nicht die Nutzung verboten, sondern gerade erlaubt werden soll. Falls schon ein Patent besteht, kann dieses nach Veröffentlichung aufgegeben werden, weil den jährlichen Gebühren kein Nutzen z.B. durch Lizenzeinnahmen mehr gegenübersteht. Eine Veröffentlich als Open Source verhindert auch effektiv, dass ein Dritter missbräuchlich die eigene Erfindung zum Patent anmeldet (weil veröffentlicht und damit nicht mehr neu).

Marken- und Designschutz – Hinweise

Eine Marke (Wort‑, Bild‑ oder Kombinationsmarke) schützt die Kennzeichnung von Produkten oder Dienstleistungen. Sie gibt dem Inhaber das ausschließliche Recht, die Marke im geschäftlichen Verkehr zu nutzen und Dritten die unberechtigte Nutzung zu untersagen.

Warum ist das für OSH wichtig?

  • Produkt‑ und Projektidentität: Logos, Projektnamen oder Qualitätssiegel werden häufig als Marken eingetragen, um die Herkunft und den Ruf der Hardware zu sichern.

  • Rechtssicherheit: Vor der Veröffentlichung muss geklärt sein, ob das Projekt eigene Marken nutzt (schützt die eigene Identität) oder Marken Dritter (z. B. von Kooperationspartnern, Lieferanten oder bekannten Open‑Source‑Projekten) enthält.

  • Lizenz‑ und Nutzungserlaubnis: Ohne ausdrückliche Erlaubnis dürfen fremde Marken weder im Quell‑/Design‑Material noch in der Dokumentation verwendet werden – sonst besteht Gefahr von Unterlassungs‑ und Schadensersatzansprüchen.

Ein eingetragenes Design (in Deutschland: Geschmacksmuster, EU: Community Design) schützt die ästhetische Erscheinungsform eines Produkts – also die sichtbare Gestaltung von Linien, Konturen, Farben, Oberflächen­strukturen und Gesamtformen. Der Schutz greift unabhängig davon, ob das Design funktional ist, er bezieht sich ausschließlich auf die optische Wahrnehmung.

Warum ist das für OSH wichtig?

  • Identität & Wiedererkennungswert: Ein unverwechselbares Gehäuse kann das Projekt stark branden; ein eingetragenes Design bietet hier rechtlichen Schutz.

  • Kompatibilität mit Open‑Source‑Lizenzen: Viele Open‑Hardware‑Lizenzen (z. B. CERN‑OHL) erlauben weder die Weitergabe noch die Modifikation eines geschützten Designs, solange das Design nicht explizit lizenziert wird.

  • Risiko von Nachahmern: Ohne Design‑Schutz können Dritte das äußere Erscheinungsbild kopieren, selbst wenn die zugrundeliegende Schaltung offen ist.

Nutzungsrecht

In Deutschland liegt das Nutzungsrecht grundsätzlich beim Urheber. Für im Rahmen eines Arbeitsverhältnisses erstellte Werke gilt in der Regel die Arbeit‑für‑den‑Arbeitgeber‑Regel: Das Nutzungsrecht geht auf die Einrichtung (Universität, Forschungseinrichtung, Unternehmen) über, sofern kein abweichender Vertrag besteht.

Klärung der Rechteinhaberschaft

Nur der Inhaber des Nutzungsrechts ist befugt, das Werk unter einer Open‑Source‑Hardware‑Lizenz zu veröffentlichen. Deshalb müssen vor der Freigabe folgende Punkte geprüft werden:

  1. Arbeits‑ und Kooperationsverträge : Liegt ein klassisches Anstellungsverhältnis vor, ist die Einrichtung (Arbeitgeber) der Rechteinhaber und darf die Lizenz erteilen.

  2. Externe Beiträge (Gast‑Wissenschaftler*innen, Industriepartner, Community‑Contributor) benötigen eine ausdrückliche Rechte‑Übertragung. Dafür sind etablierte Verfahren empfehlenswert:

    • Developer Certificate of Origin[^4] (DCO) – Der Beitragende bestätigt per Commit‑Message‑Footer, dass er die erforderlichen Rechte besitzt und die Lizenzierung erlaubt.

    • Contributor License Agreement (CLA) – Ein kurzer Vertrag, in dem der Contributor dem Rechteinhaber (z. B. der Universität) das notwendige Verwertungsrecht überträgt oder eine Lizenzgewährung erklärt.

Durch die Kombination aus eindeutig dokumentierter Urheberschaft und einer geprüften, vertraglich gesicherten Verwertungsrechtslage (DCO/CLA bzw. vertragliche Regelung) ist sichergestellt, dass die anschließend angewandte Open‑Source‑Hardware‑Lizenz rechtlich wirksam und problemlos durchsetzbar ist.

Dokumentation bei der Publikation

Damit die Zuordnung von Urheberschaft und Verwertungsrecht transparent ist, muss bei der Publikation die Autorenschaft dokumentiert sein. Die gängige Praxis ist das Anlegen eines Autorenregisters im Projekt‑Root, etwa einer Datei AUTHORS.md. Darin werden für jede mitwirkende Person Name, E‑Mail‑Adresse und optional ORCID‑ID oder sonstige eindeutige Kennung festgehalten. Dieses Register dient sowohl internen Verantwortlichkeiten (Nachweis, wer das Werk geschaffen hat) als auch externen Nutzer*innen, die die Namensnennungspflicht der Lizenz erfüllen müssen.

Produkthaftung

Wenn eine Hardware nicht richtig funktioniert, können echte Schäden entstehen - wirtschaftliche Schäden oder auch Personenschäden. Viele Open Source Projekte sind frei und kostenlos verfügbar. Da keine Einnahmen erzielt werden, wollen die Entwickler:innen natürlich auch nicht haften.

Deshalb findet sich in allen Open Source Lizenzen ein möglichst weitgreifender Ausschluss dieser Haftung. Die sogenannte Produkthaftung hingegen ist per Gesetz geregelt und kann nicht ausgeschlossen werden. Das wird durch das Produkthaftungsgesetz geregelt. Das stammt im Kern noch aus den 1980er Jahren und wurde angepasst: die EU hat im Oktober 2024 eine neue Produkthaftungsrichtlinie verabschiedet (RL 2024/2853), die bis Ende 2026 in deutsches Recht überführt wird. 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. 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ür kann (Vorsatz, einfache oder grobe Fahrlässigkeit). Er muss immer haften.

Neu ist nun, dass auch digitale Produkte wie z.B. eine Software als Produkte im Sinne des Gesetzes gelten, was bis dato nicht so war. Auch werden nun Schäden an immateriellen Dingen wie z.B. Daten mit erfasst.

Es gibt aber Grenzen. Der Hersteller haftet nicht für fehlerhafte 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.

Für nicht-kommerzielle Anbieter und Anbieter kostenloser Hard- und Software sind jedoch Ausnahmen vorgesehen.

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

Open Source Soft- und Hardware lebt davon, dass 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: man haftet nicht, wenn man

  • ein „Nicht-Produkt“ in den Verkehr bringt

oder

  • ein Produkt nicht selbst in den Verkehr bringt

oder

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

Ausführlichere Informationen finden sich in einer separaten Handreichung zum Thema Produkthaftung, in der auch für Forschungseinrichtungen typische Beispiele behandelt werden. [LINK]