Lizenzen und Kompatibilität

Das Urheberrecht schützt automatisch jede schöpferische Ausdrucksform (Schaltpläne, PCB‑Layouts, CAD‑Modelle, Firmware‑Quellcode, Handbücher usw.). Ohne ausdrückliche Erlaubnis ist jede Nutzung außer den eng definierten Ausnahmefällen (wie z.B. Zitat oder Verwendung in der Lehre) verboten.

Eine Lizenz ist das juristische Werkzeug, mit dem der Urheber (bzw. der Inhaber des Verwertungsrechts) festlegt, wie und unter welchen Bedingungen Dritte das Werk nutzen, verändern und weiterverbreiten dürfen.

Ein Open‑Source‑Hardware‑Projekt besteht typischerweise aus vier Bausteinen, die jeweils urheberrechtlich geschützt sind:

• Hardware‑Design – Das technische Layout und die Fertigungsdaten (Schaltpläne, PCB‑Layouts, CAD‑Modelle, Stücklisten).

• Software / Firmware – Quellcode, Binärdateien, Treiber, Bibliotheken und sonstige für die Hardware notwendige Programme.

• Dokumentation – Bau‑ und Bedienungsanleitungen, Tutorials, Handbücher, Bilder, Videos, Diagramme und sonstige erläuternde Materialien.

• Marken – Logos, Produktnamen, Qualitätssiegel oder andere Kennzeichen, die unter dem Markenrecht geschützt sind.

Da diese drei Elemente unterschiedliche Anforderungen an Lizenzen haben empfiehlt es sich, für jedes Element eine eigene, jedoch auf die anderen beiden Elemente abgestimmte Lizenz zu wählen:

• Hardware: explizite Hardwarelizenz (CERN OHL 2.0 P/W/S; Solderpad, TAPR)

• Software: Eine von vielen Softwarelizenzen (GPL 3.0, LGPL, Apache, MIT, BSD, …)

• Dokumentation: Creative Commons Lizenz (CC0, CC-BY, CC-BY-SA)

Lizenzkategorien

Für Open Source Hardware – wie auch für Open Source Software – gibt es drei Kategorien von Lizenzen. Sie definieren, wie frei die Soft- oder Hardware verwendet, verändert und weitergegeben werden dar.

Permissive Lizenzen

Das sind die Lizenzen mit dem höchsten Freiheitsgrad. Nutzer dürfen die Soft- oder Hardware nutzen, verändern, kombinieren und in beliebiger Form weitergeben – also auch verkaufen. Sie sind nicht verpflichtet, etwaige Änderungen auch zu veröffentlichen oder an andere zu lizenzieren. Bekannte permissive Lizenzen sind Apache 2, MIT oder BSD 3 (für Software) bzw. CERN-OHL-P oder Solderpad 2.1 (Hardware).

Stark reziproke Lizenzen (starkes Copyleft)

Die sog. Copyleft-Lizenzen sind der Gegensatz zu permissiven Lizenzen: Nutzer dürfen zwar die Soft- oder Hardware nutzen, verändern, kombinieren und weitergeben. Sie müssen dies aber immer unter der ursprünglichen Lizenz tun – auch ihre eigenen Beiträge oder Änderungen. Die Lizenzbedingungen werden quasi an alle „Nachkommen vererbt.“ Das hat zum Ziel, einen möglichst großen Fundus offener Soft- oder Hardware aufzubauen, beißt sich jedoch häufig mit kommerzieller Nutzung. Unter Umständen zwingen reziproke Lizenzen dazu, das ganze Projekte unter eine stark reziproke Lizenz zu stellen, auch wenn nur ein stark reziprok lizenziertes Bauteil integriert wird (siehe unten Lizenzkompatibilitäten). Bekannte Copyleft-Lizenzen sind GPL 3 (Software) bzw. CERN-OHL- S oder TAPR (Hardware).

Schwach reziproke Lizenzen (schwaches Copyleft)

Schwache Copyleft-Lizenzen sind ein Kompromiss zwischen starkem Copyleft und permissiven Lizenzen. Sie erlauben in Grenzen, dass Änderungen oder Ergänzungen an der ursprünglichen Open Source nicht offengelegt oder dass nur Ergänzungen am Kern einer Technologie veröffentlicht werden müssen. Hier gibt es unterschiedliche Abstufungen: die Mozilla Public License wird z.B. als sehr schwach, die LGPL 3 als „nur“ schwach reziprok beurteilt. Bekannte schwach reziproke Lizenzen sind LGPL 3 oder MPL (Software) bzw. CERN-OHL-W (Hardware).

Kompatibilität von Lizenzen

Lizenz‑Kompatibilität beschreibt die Möglichkeit, zwei (oder mehr) urheberrechtlich geschützte Bausteine – etwa ein Hardwarelayout, eine Firmwarebibliothek oder eine Dokumentation – gemeinsam zu veröffentlichen oder zu verbreiten, ohne dass die jeweiligen Lizenzbedingungen einander widersprechen. Für Softwarelizenzen gibt es inzwischen zahlreiche, gut gepflegte Kompatibilitätsübersichten; für Hardwarelizenzen fehlt bislang ein vergleichbarer Standard – die folgende Grafik ist daher selbst erstellt.

Die Frage dabei ist, inwiefern ein Modul unter der Lizenz A in ein Gesamtvorhaben unter der Lizenz B integriert werden kann und darf. Grüne Felder bedeuten, dass eine Integration problemlos möglich ist, bei roten Feldern ist dies unmöglich, da sich die beiden Lizenzen widersprechen. Bei gelben Feldern ist die Situation komplex, meist mit dem Ergebnis, dass eine Integration zwar möglich ist, allerdings für das Modul oder gar das Gesamtvorhaben eine Lizenzänderung – meist eine Lizenzverschärfung hin zu stärker reziproken Lizenzen – notwendig ist.

Bei der Integration ist vorab zu unterscheiden, ob das Modul A integriert wird, z.B. indem es in Designfiles oder die Dokumentation vollständig integriert wird – oder ob es ein unabhängiges Bauteil bleibt mit eigenständigen Designfiles, Dokumentation usw. – so als ob man es als unabhängige Komponente zugekauft hätte.

Im Fall „unabhängige Komponente“ kann eigentlich fast immer kombiniert werden – so wie man auch ein kommerzielles, proprietär lizenziertes Bauteil „aus dem Laden“ immer mit verbauen könnte. Lediglich die CERN-OHL-S-Lizenz erlaubt bei unabhängigen Komponenten nur reine Hardware. Sobald eine Komponente Software mit enthält, gilt sie nicht mehr als unabhängige Komponente.

Erläuterungen:

1) Die TAPR OHL verlangt, alle Modifikationen ebenfalls unter TAPR zu stellen, die CERN-OHL-S Lizenz verlangt das Gleiche. Keine der beiden Lizenzen erlaubt Relizenzierung zur anderen. Das schließt sich gegenseitig aus.

2) Wird eine CERN-OHL-S-Komponente in ein anders lizenziertes Design integriert, muss das gesamte kombinierte Werk unter CERN-OHL-S gestellt werden.

3) TARP bzw. CERN-OHL-W verlangen nur, dass Modifikationen und Dokumentation unter die gleiche Lizenz gestellt werden. Der Rest des Projekts kann weiter unter seiner jeweiligen Lizenz bleiben.

4) Das W -Modul selbst muss unter W bleiben, auch Modifikationen am W-Modul. Der „Rest“ des Projekts kann seine Lizenz behalten.

5) TAPR verlangt, dass Modifikationen und Dokumentation unter TAPR stehen. Da P bzw. Solderpad permissiv sind, können P-/Solderpad-Teile unter TAPR relizenziert werden. Das Gesamtprojekt bleibt ein TAPR-Projekt.

6) TARP verlangt nur, dass Modifikationen und die Dokumentation des TAPR-Moduls unter die gleiche Lizenz gestellt werden. Der „Rest“ des Projektes kann weiter unter Solderpad- oder P-Lizenz bleiben. Es entsteht aber kein permissives Gesamtprojekt.

Bei inkompatiblen Lizenzen stehen im Wesentlichen zwei Wege offen:

1. Das problematische Bauteil durch ein gleichwertiges mit einer kompatiblen Lizenz ersetzen. Oder, wenn möglich, das problematische Bauteil selbst neu entwerfen und bauen, dann kann man die Lizenz selbst bestimmen.

2. Mit dem Rechteinhaber des betroffenen Bausteins verhandeln, um eine Lizenzänderung oder die Erteilung einer zusätzlichen, kompatiblen Lizenz zu erreichen.

In Ausnahmefällen kann auch eine Dual‑Licensing‑Strategie sinnvoll sein. Dabei wird beispielsweise ein stark reziprokes Werk zusätzlich unter einer permissiven Lizenz anbieten, um die Integration in Projekte mit unterschiedlichen Lizenzanforderungen zu ermöglichen.

Ansonsten bleibt noch die Strategie der rationalen Ignoranz: wie wahrscheinlich ist es, dass ein der Offenheit verpflichteter Lizenzinhaber einen sich ganz ähnlich der Offenheit verpflichtenden Nutzer tatsächlich für juristische Feinheiten der kollidierenden Lizenzen zu verklagen? Eine CERN-OHL-S- und eine TAPR-Lizenz sind zwar inkompatibel, aber in der Zielrichtung gleich: sie wollen beide gleichermaßen ein starkes Copyleft für die Hardware.

Lizenzmodell

Wer ein Werk veröffentlichen will, braucht eine eindeutige Lizenz.

• Der Urheber legt fest, welche Rechte (Vervielfältigung, Bearbeitung, Verbreitung, kommerzielle Nutzung u. a.) eingeräumt werden.

• Eine Lizenz kann exklusiv sein (nur ein Lizenznehmer) oder nicht‑exklusiv (Mehrfachnutzung möglich).

• Ohne Lizenz gilt: keine Nutzungsrechte.

Ein zentrales Instrument für die rechtssichere Nutzung, Weiterverbreitung und Abänderung von Open Hardware ist die Wahl einer passenden Lizenz. Es ist empfohlen, Standardlizenzen zu verwenden, um das Verständnis und die Einhaltung der Lizenzbedingungen zu erleichtern sowie Inkompatibilitäten zu verhindern. Eine gute Quelle dafür ist die Liste der durch OSI anerkannten Lizenzen:

https://opensource.org/licenses

Für Open-Source-Hardware existieren eigene Standardlizenzen, die sich in ihrer Logik an Open-Source-Software orientieren. Dazu gebräuchlichsten sind die CERN Open Hardware License (in den Varianten OHL-P, OHL-W und OHL-S), die TAPR Open Hardware License und die Solderpad License.

Die CERN-OHL-P (Permissive) ist eine offene Lizenz mit geringen Einschränkungen. Sie erlaubt eine freie Nutzung, Veränderung und Kommerzialisierung. Bei der Veränderung des Hardwaredesigns besteht keine Verpflichtung, die Änderungen öffentlich zu veröffentlichen. Allerdings müssen bei der Weitergabe der Hardware (z. B. Verkauf) die geänderten Baupläne und Dokumentation an den Empfänger bereitgestellt werden.

Das Design kann unter diesen Bedingungen proprietär weiterentwickelt werden, sofern die Lizenzbedingungen bei der Verteilung eingehalten werden. CERN-OHL-P-lizenzierte Hardware kann in andere Systeme integriert werden, wobei die ursprünglichen CERN-OHL-P-Teile unter dieser Lizenz bleiben, das Gesamtsystem aber andere Lizenzen annehmen kann.

Die CERN-OHL-W (Weak) kombiniert Offenheit mit der Möglichkeit, bestimmte Komponenten proprietär zu halten (sogenanntes ‚Weak Copyleft'). Änderungen an den spezifischen, lizenzierten Dateien müssen unter CERN-OHL-W veröffentlicht werden.

Diese Lizenz ermöglicht es, eigene Hardware-Module in ein größeres, proprietäres Gesamtsystem zu integrieren. Die Änderungen am Modul bleiben offen, während da übergeordnete System proprietär bleiben darf. Dies ist ideal für Unternehmen, die ihre Kernkomponenten offenlegen wollen, aber das Endprodukt schützen möchten.

Die CERN-OHL-S (Strong) verfolgt eine strikte Copyleft-Strategie. Sie stellt sicher, dass das Design und alle abgeleiteten Werke offen bleiben. Alle Änderungen oder Weiterentwicklungen des Designs müssen ebenfalls unter CERN-OHL-S veröffentlicht werden.

Wird die Hardware mit anderen Komponenten zu einem neuen Produkt kombiniert und dieses vertrieben, muss das gesamte veränderte Design unter CERN-OHL-S lizenziert werden. Dies verhindert, dass Open-Hardware-Designs in geschlossene, proprietäre Systeme ‚eingesperrt' werden.

Die TAPR OHL 1.0 ist eine der älteren Open-Hardware-Lizenzen. Sie erlaubt die Nutzung, Veränderung und Kommerzialisierung von Hardware-Designs. Sie verpflichtet jedoch zur Beibehaltung von Urheber- und Lizenzhinweisen, zur transparenten Kennzeichnung von Änderungen und zur Bereitstellung der vollständigen Dokumentation für mindestens drei Jahre nach der letzten Verteilung. Auch sie erlaubt die Einbettung in geschlossene Systeme.

Die Solderpad License (basierend auf der Apache 2.0 Lizenz) ist analog zur CERN-OHL-P aufgebaut und erlaubt eine freie Nutzung mit minimalen Einschränkungen. Sie ist besonders beliebt in der Industrie, da sie auf der Apache-Lizenz aufbaut. Vor allem in für Prozessordesign relevanten Bereichen wie dem akademischen RISC-V-/PULP-Ökosystems ist die Solderpad 2.0 Lizenz der de-facto-Standard.

Wie bei anderen permissiven Lizenzen besteht keine Verpflichtung, Änderungen öffentlich zu teilen; bei Weitergabe der Hardware müssen jedoch die ursprünglichen, unter einer permissiven Lizenz veröffentlichten Baupläne dem Empfänger zur Verfügung gestellt werden. Ein wesentlicher Bestandteil ist der Patent-Grant: Der Lizenzgeber gewährt allen Lizenznehmern eine Patentlizenz für das Design. Dies gilt weltweit, unbefristet und gebührenfrei, solange die Urheber- und Lizenzhinweise erhalten bleiben. (Hinweis: Auch die CERN-OHL 2.0 enthält einen solchen Patent-Grant).

Für die meisten Open-Hardware-Projekte werden heutzutage CERN-OHLs in der Version 2 genutzt. Zahlen für OSHWA-zertifizierte Hardware zeigen, dass davon etwas mehr als die Hälfte die streng reziproke Variante CERN-OHL-S nutzt, weitere 15% die schwach reziproke CERN-OHL-W. Der Rest, knapp 30%, nutzen die permissive Version CERN-OHL-P. Auch auf GitHub sind die meisten sind die Verhältnisse ähnlich: knapp 80% CERN-lizenzierte Projekte (davon S: 45%, W: 20%, P: 35%) stehen ca. 20% Solderpad-Projekten und weniger als 1% TAPR-Projekten gegenüber.

Empfehlung: für die meisten Projekte ist eine der drei CERN-Lizenzen sinnvoll. Diese sind auch untereinander kompatibel. Solderpad ist dann zu erwägen, wenn im Bereich Prozessordesign gearbeitet wird. Die TAPR-Lizenz hingegen ist ein Auslaufmodell, sie wird kaum noch genutzt und kann mit weitestgehend gleichem Ergebnis durch die CERN-OHL-S ersetzt werden.