Kompatibilität von Open-Source-Lizenzen¶
Dieser Teil gibt einen kurzen Überblick über die Kompatibilität verschiedener Open-Source-Lizenzen, ihrer Bedeutung, mögliche Probleme und wie diese vermieden werden können. Es ist wichtig zu betonen, dass diese Informationen keine Rechtsberatung darstellen und nur als Anregung dienen. Die Nutzung erfolgt auf eigene Gefahr und es wird keine Haftung übernomme
Wann ist die Lizenzkompatibilität wichtig¶
Die Einhaltung der Lizenzkompatibilität ist entscheidend, wenn unterschiedlich lizenzierte Komponenten zusammen vertrieben werden sollen. Für den internen Gebrauch hat dies keine Auswirkungen. Bei der Weiterentwicklung oder Integration von Software unter Lizenz A in ein Projekt unter Lizenz B muss z.B. darauf geachtet werden, dass beide Lizenzen kompatibel sind.
In diesem Zusammenhang ist es wichtig, den Unterschied zwischen einem Gemeinsamen Werk (oder einem “Ganzen”) und einem Getrennten Werk zu verstehen
Getrenntes Werk vs. Gemeinsames Werk:¶
Bei Copyleft-Lizenzen gilt das Prinzip des “getrennten Werks”, bei dem die Lizenzen nicht unbedingt kompatibel sein müssen. Im Gegensatz dazu steht das “gemeinsame Werk”, bei dem die Lizenzen kompatibel sein müssen. Die genauen Bedingungen für ein gemeinsames Werk sind in den Lizenztexten definiert, weshalb eine genaue Lektüre unerlässlich ist. In den folgenden Szenarien wird jedoch in der Regel immer von einem gemeinsamen Werk ausgegangen:
Software, die auf bestehender Software basiert oder diese modifiziert
Direkte gemeinsame Verbreitung von Code (Code ist auf einem Speichermedium zusammengefasst)
Container-Distribution: Alle im Container enthaltenen Komponenten gelten als gemeinsames Werk.
Etwas komplizierter ist es, wenn die Komponenten nur gelinkt werden oder wenn sie gelinkt sind. Mit Linken ist gemeint, dass der Code nicht manuell eingefügt wird, sondern dass dies über Befehle im Code geschieht. Man unterscheidet zwischen statischem Linken, bei dem der Code im letzten Schritt der Kompilierung hinzugefügt wird, und dynamischem Linken, bei dem der Code während der Ausführung der Software hinzugefügt wird. Wie in diesen Fällen die Kompatibilität zu behandeln ist, hängt wiederum stark von den Lizenzen ab und ob die Komponente auch durch andere Komponenten ersetzt werden kann. Grob kann man sich aber merken, dass bei starken Copyleft-Lizenzen eine Verlinkung in der Regel als gemeinsames Werk angesehen wird, bei schwachen Copyleft-Lizenzen auch eine Betrachtung als separates Werk möglich ist (muss im Einzelfall geprüft werden) und permissive Lizenzen in der Regel keine Einschränkungen haben.
Lizenzkompatibilität allgemein¶
Lizenzkompatibilität im Allgemeinen: Liegt ein Sammelwerk vor, führt kein Weg an der Prüfung der Lizenzkompatibilität vorbei, da die Lizenzen verschiedener Codequellen miteinander kompatibel sein müssen. Insbesondere Copyleft-Lizenzen können zu Kompatibilitätsproblemen führen, da sie vorgeben, unter welchen weiteren Lizenzen die Software vertrieben werden darf. Ist eine Copyleft-Lizenz enthalten, muss die Hauptlizenz der Software entweder dieselbe Lizenz sein oder eine Lizenz, in die alle Unterlizenzen integriert werden können. Die strengste Lizenz bestimmt also die Hauptlizenz des Sammelwerkes. Eine Copyleft-Lizenz kann nicht in eine permissive Lizenz integriert werden. Eine grobe Übersicht ist in der folgenden Grafik dargestellt.
 |
|---|
| Grafik zur ersteinschätzung, welche aus welchen Lizenzen die Hauptlizenz der Software gewählt werden kann, wenn Softwarekomponenten mit Copyleft-Lizenzen enthalten sind. |
Eine detaillierte Übersicht für Fälle bei denen verschiedene Softwarebestandteile unter einer Lizenz vereint werden sollen (als “Ganze” vertrieben werden sollen) kann der folgenden Tabelle entnommen werden. In jeder Zeile spiegelt eine Lizenz wieder und zeigt an, in welche diese integriert werden kann, was also die Hauptlizenz sein muss 1,2,3.
 |
|---|
| *Kompatibilitäten wichtiger Open-Source-Lizenzen. Beispiel für die Nutzung: Hat man zum Beispiel ein Software, bei der eine eingebaute Komponente unter GPL 3.0 lizensiert ist (Lizenz A) und plant MIT als Endlizenz (Lizenz B) zu verwenden, so ist das aufgrund von Copyleft nicht möglich. Es muss GPL 3.0 oder AGPL verwendet werden. * |
Worauf ist zu achten¶
Die folgende Checkliste zeigt wichtige zu beachtenede Punkte auf die bei der Verwendung von Open Source Bestandteilen in der eigenen Software wichtig sind:
Code ohne Copyleft-Lizenz (z.B. MIT, BSD, Apache): kein Problem
Code mit starker Copyleft-Lizenz (GPL, AGPL): nicht immer möglich
Rein interne Nutzung innerhalb einer Einrichtung ohne Lizenzpflichten zulässig
Angebot von GPL-3.0-Nutzung im Wege des SaaS ohne Lizenzpflichten zulässig, da das Copyleft nur bei einer Verbreitung von Kopien eingreift.
Die Verwertungsrechte können über den Umweg einer separaten Lizenz erlangt werden. Hierfür müssen die Verwertungsbefugten kontaktiert werden und eine Lizenz für die proprietäre Nutzung und Verwertung angefragt werden
Die Einbindung (im Sinne von: Erstellung eines einheitlichen Programms) von starker Copyleft-lizenzierter Software führt dazu, dass der eigene Code bei der Weiterverbreitung unter die jeweilige Copyleft-Lizenz gestellt werden und damit auch der eigene Code offengelegt werden muss
Eine Software, die mit einer OSS-Lizenz veröffentlicht wurde, kann auf dem Dual Licensing Weg zusätzlich proprietär/kommerziell verwertet werden. Hierfür müssen umfassende Verwertungsrechte vorliegen. Die Übertragung von Rechten, falls diese nicht vollständig vorhanden sind, können z.B. mittels eines Contribution License Agreements (CLA) durchgeführt werden.
Eine ausfürhlichere Checkliste für die Kompatibilitätsprüfung findet sich in der Checkliste zur Kompatibilitätsprüfung bei den Tools.
Diese Zusammenfassung gibt einen klaren Überblick über die Notwendigkeit der Lizenzkompatibilität und die grundlegenden Konzepte bei der Verwendung verschiedener Open-Source-Lizenzen. Es wird jedoch empfohlen, die Lizenztexte im Detail zu lesen oder Experten zu konsultieren, um spezifische Anforderungen zu verstehen.