Lizenzkompatibilität - License compatibility
Lizenzkompatibilität ist ein rechtlicher Rahmen, der die gemeinsame Verteilung von Softwareteilen mit unterschiedlichen Softwarelizenzen ermöglicht . Die Notwendigkeit eines solchen Frameworks entsteht, weil die verschiedenen Lizenzen widersprüchliche Anforderungen enthalten können, die es unmöglich machen, Quellcode aus separat lizenzierter Software legal zu kombinieren , um ein neues Programm zu erstellen und zu veröffentlichen. Proprietäre Lizenzen sind im Allgemeinen programmspezifisch und inkompatibel; Autoren müssen verhandeln, um Code zu kombinieren. Copyleft-Lizenzen sind bewusst inkompatibel mit proprietären Lizenzen, um zu verhindern, dass Copyleft-Software unter einer proprietären Lizenz neu lizenziert und in proprietäre Software umgewandelt wird. Viele Copyleft-Lizenzen erlauben ausdrücklich die Neulizenzierung unter einigen anderen Copyleft-Lizenzen. Permissive Lizenzen sind (mit kleinen Ausnahmen) mit allem kompatibel, einschließlich proprietärer Lizenzen; es gibt daher keine Garantie dafür, dass alle abgeleiteten Werke unter einer permissiven Lizenz bleiben.
Definitionen
Die Lizenzkompatibilität kann um die Konzepte „kollektives/kombiniertes/aggregiertes Werk“ und „ abgeleitetes Werk “ herum definiert werden . Die erste Lizenzkompatibilitätsdefinition für „ kollektive Werke “ erlaubt die Nutzung unterschiedlich lizenzierter Werke in einem kombinierten Kontext:
die Eigenschaft von zwei (oder mehr) Lizenzen, nach denen die unter diesen Lizenzen vertriebenen Codes zusammengestellt werden können , um eine größere vertreibbare Software zu erstellen . [Betonung hinzugefügt]
— Philippe Laurent, The GPLv3 and Compatibility Issues, EOLE 2008
Eine stärkere Definition beinhaltet die Möglichkeit, die Lizenz zu ändern. Das prominenteste Beispiel ist die Forderung der Copyleft-Lizenz , dass das aus Code unter verschiedenen Lizenzen kombinierte "abgeleitete Werk" als Ganzes auf die Copyleft-Lizenz angewendet wird.
Lizenzkompatibilität: Das Merkmal einer Lizenz, wonach der unter dieser Lizenz vertriebene Code in eine größere Software integriert werden kann, die unter einer anderen Lizenz vertrieben wird . [Betonung hinzugefügt]
— Philippe Laurent, The GPLv3 and Compatibility Issues, EOLE 2008
Arten von kombinierten Arbeiten
Ein kombiniertes Werk besteht aus mehreren unterschiedlich lizenzierten Teilen (Vermeidung einer Neulizenzierung ). Um ein kombiniertes Werk zu erreichen, das Copyleft-lizenzierte Komponenten enthält (die eine virale Eigenschaft haben, die möglicherweise zu einem abgeleiteten Werk führt ), muss eine ordnungsgemäße Isolierung/Trennung aufrechterhalten werden.
Bei einzeln lizenzierten Quellcodedateien können mehrere nicht-reziproke Lizenzen (wie freizügige Lizenzen oder eigener proprietärer Code) getrennt werden, während das kombinierte kompilierte Programm erneut lizenziert werden könnte (dies ist jedoch nicht erforderlich). Für Copyleft/Reziproke-Lizenzen (wie die GPL) ist eine solche Quellcode-Dateitrennung zu schwach, da sie dann eine Neulizenzierung des gesamten Werkes unter der reziproken Lizenz als Derivat erfordern.
Ein etwas stärkerer Ansatz ist die Trennung in der Linking-Phase mit binärem Objektcode ( statisches Linken ), wobei alle Komponenten des resultierenden Programms Teil desselben Prozesses und Adressraums sind . Dies befriedigt kombinierte "schwache Copyleft/Standard-Reziprok"-Werke (wie LGPL-lizenzierte), aber nicht "starke Copyleft/stark-Reziprok"-Kombinationen. Obwohl allgemein akzeptiert wird, dass das Verlinken ( statisches und sogar dynamisches Verlinken ) eine Ableitung eines starken Copyleft-Werks darstellt, gibt es alternative Interpretationen.
Bei kombinierten Arbeiten mit "strong copyleft"-Modulen ist eine stärkere Isolation erforderlich. Dies kann dadurch erreicht werden, dass die Programme durch einen eigenen Prozess getrennt werden und die Kommunikation nur über binäre ABIs oder andere indirekte Mittel erlaubt wird . Beispiele sind die Kernel-Space- to- User-Space- Trennung von Android über Bionic oder Linux-Distributionen , die proprietäre Binär-Blobs enthalten, obwohl sie einen starken Copyleft- Kernel haben .
Während für manche Domains Einigkeit besteht, ob eine Isolierung geeignet ist, gibt es Domains umstritten und bisher nicht gerichtlich geprüft. Zum Beispiel verklagte die SFC 2015 VMware in einem anhaltenden Streit, ob ladbare Kernelmodule (LKMs) abgeleitete Werke des GPL-dierten Linux-Kernels sind oder nicht.
Kompatibilität von FOSS-Lizenzen
Lizenzen, die für freie und Open-Source-Software (FOSS) gemeinsam sind, sind nicht unbedingt miteinander kompatibel, und dies kann es rechtlich unmöglich machen, Open-Source- Code zu mischen (oder zu verknüpfen ) , wenn die Komponenten unterschiedliche Lizenzen haben. Beispielsweise darf Software, die Code, der unter Version 1.1 der Mozilla Public License (MPL) veröffentlicht wurde, mit Code unter der GNU General Public License (GPL) kombiniert, nicht verbreitet werden, ohne gegen eine der Lizenzbedingungen zu verstoßen; dies obwohl beide Lizenzen sowohl von der Open Source Initiative als auch von der Free Software Foundation genehmigt wurden .
Die Lizenzkompatibilität zwischen einer Copyleft-Lizenz und einer anderen Lizenz ist oft nur eine Einweg-Kompatibilität, wodurch die Copyleft-Lizenz (GPL und die meisten anderen Copyleft-Lizenzen) mit proprietären kommerziellen Lizenzen sowie mit vielen nicht-proprietären Lizenzen inkompatibel ist. Diese Eigenschaft der "Einwegkompatibilität" wurde von der Apache Foundation kritisiert , die unter der freizügigeren Apache-Lizenz lizenziert , da solche Nicht-Copyleft-Lizenzen oft weniger kompliziert sind und eine bessere Lizenzkompatibilität ermöglichen.
Ein Beispiel für eine Lizenz mit ausgezeichneter Kompatibilität mit anderen FOSS-Lizenzen ist die Artistic License 2.0 aufgrund ihrer Neulizenzierungsklausel , die die Weiterverteilung des Quellcodes unter jeder anderen FOSS-Lizenz erlaubt.
Sie dürfen Ihre modifizierte Version als Quelle verteilen (entweder kostenlos oder gegen eine Vertriebspartnergebühr und mit oder ohne eine kompilierte Form der modifizierten Version) [...] vorausgesetzt, Sie tun mindestens EINES der folgenden: […]
(c) jedem, der eine Kopie der modifizierten Version erhält, erlauben, das Quellformular der modifizierten Version anderen unter . zur Verfügung zu stellen
(i) die Originallizenz oder
(ii) eine Lizenz , die es dem Lizenznehmer erlaubt, die Modifizierte Version unter Verwendung derselben Lizenzbedingungen frei zu kopieren, zu modifizieren und weiterzugeben, die für die Kopie gelten, die der Lizenznehmer erhalten hat, und erfordert, dass die Quellform der Modifizierten Version und aller abgeleiteten Werke daraus frei zugänglich gemacht werden, indem Lizenzgebühren verboten, aber Vertriebsgebühren erlaubt sind. [Betonung hinzugefügt]
Die Common Development and Distribution License (CDDL) – eine schwache Copyleft- Lizenz zwischen der GPL- Lizenz und BSD / MIT- permissiven Lizenzen – versucht, Lizenzkompatibilitätsprobleme zu beheben, indem sie ohne erneute Lizenzierung das Mischen von CDDL-lizenziertem Quellcode zulässt Dateien mit Quellcodedateien unter anderen Lizenzen, indem Sie sicherstellen, dass die resultierende Binärdatei unter einer anderen Lizenz lizenziert und verkauft werden kann, solange der Quellcode noch unter CDDL verfügbar ist.
GPL-Kompatibilität
Um die Verbreitung von Lizenzen und Lizenzinkompatibilitäten im FOSS- Ökosystem zu minimieren , argumentieren einige Organisationen (z. B. die Free Software Foundation) und Einzelpersonen (David A. Wheeler), dass die Kompatibilität mit der weit verbreiteten GPL ein wichtiges Merkmal von Softwarelizenzen ist. Viele der gebräuchlichsten Lizenzen für freie Software, insbesondere die permissiven Lizenzen , wie die ursprüngliche MIT/X-Lizenz , BSD-Lizenzen (in der Form mit drei und zwei Klauseln, jedoch nicht in der ursprünglichen Form mit vier Klauseln), MPL 2.0 , und LGPL sind GPL-kompatibel . Das heißt, ihr Code kann ohne Konflikt mit einem Programm unter der GPL kombiniert werden, und die neue Kombination würde die GPL auf das Ganze anwenden (aber die andere Lizenz würde nicht gelten).
Copyleft-Lizenzen und GPL
Copyleft- Softwarelizenzen sind von Natur aus nicht GPL-kompatibel; selbst die GPLv2-Lizenz ist nicht mit GPLv3 oder LGPLv3 kompatibel. Wenn Sie versuchen, Code, der unter einer der späteren GPL-Lizenzen veröffentlicht wurde, mit GPLv2-Code zu kombinieren, würden Sie gegen Abschnitt 6 der GPLv2 verstoßen, der die Ursache der Inkompatibilität ist. Code unter den neueren Lizenzen kann jedoch mit Code kombiniert werden, der unter GPL Version 2 oder höher lizenziert ist. Bei der meisten unter GPLv2 veröffentlichten Software können Sie auch die Bedingungen neuerer Versionen der GPL verwenden, und einige haben Ausnahmeklauseln, die es ermöglichen, sie mit Software zu kombinieren, die unter anderen Lizenzen oder Lizenzversionen steht. Der Linux - Kernel ist eine bemerkenswerte Ausnahme , das ausschließlich unter den Bedingungen der GPLv2 verteilt wird.
GFDL und GPL
Die von der Free Software Foundation empfohlene GNU Free Documentation License ist nicht mit der GPL-Lizenz kompatibel, und unter der GFDL lizenzierter Text kann nicht in GPL-Software integriert werden. Daher beschloss das Debian- Projekt in einer Resolution von 2006, die Dokumentation unter der GPL zu lizenzieren. Die FLOSS Manuals Foundation folgte Debian im Jahr 2007. 2009 wechselte die Wikimedia Foundation von der GFDL zu einer Creative Commons CC-BY-SA-Lizenz als Hauptlizenz für ihre Projekte.
CDDL und GPL
Ein weiterer Fall, bei dem die GPL-Kompatibilität problematisch ist, ist das CDDL- lizenzierte ZFS- Dateisystem mit dem GPLv2-lizenzierten Linux-Kernel . Obwohl es sich bei beiden um freie Software unter einer Copyleft-Lizenz handelt, wird ZFS nicht mit den meisten Linux-Distributionen wie Debian (aber mit FreeBSD ) vertrieben, da die CDDL von der Free Software Foundation und einigen Parteien als inkompatibel mit dem GPL-edierten Linux-Kernel angesehen wird mit Beziehungen zur FSF. Die rechtliche Auslegung – ob und wann diese Kombination ein kombiniertes Werk oder abgeleitetes Werk des GPLed-Kernels darstellt – ist mehrdeutig und umstritten. Im Jahr 2015 tauchte die Frage zur Kompatibilität von CDDL zu GPL erneut auf, als die Linux-Distribution Ubuntu ankündigte, dass sie OpenZFS standardmäßig enthalten würde. Im Jahr 2016 gab Ubuntu bekannt, dass eine rechtliche Überprüfung zu dem Schluss kam, dass es rechtlich sicher ist, ZFS als Binärkernelmodul in Linux zu verwenden. Andere akzeptierten die Schlussfolgerung von Ubuntu; So argumentierte beispielsweise der Anwalt James EJ Bottomley, dass „eine überzeugende Schadenstheorie“ nicht entwickelt werden könne, was es unmöglich mache, den Fall vor Gericht zu bringen. Eben Moglen , Co-Autor der GPLv3 und Gründer der SFLC , argumentierte, dass zwar die Buchstaben der GPL verletzt werden könnten, aber der Geist beider Lizenzen eingehalten werde, was vor Gericht die relevante Frage wäre. Auf der anderen Seite argumentierten Bradley M. Kuhn und Karen M. Sandler von der Software Freedom Conservancy , dass Ubuntu beide Lizenzen verletzen würde, da ein binäres ZFS-Modul eine Ableitung des Linux-Kernels wäre, und kündigten ihre Absicht an, dies zu erreichen Klarheit in dieser Frage, auch vor Gericht.
CC BY-SA und GPLv3
Am 8. Oktober 2015 kam Creative Commons zu dem Schluss, dass CC BY-SA 4.0 inbound-kompatibel mit der GPLv3 ist.
Kompatibilität mit Creative Commons-Lizenzen
Die Creative Commons-Lizenzen werden häufig für Inhalte verwendet, aber nicht alle Kombinationen der sieben empfohlenen und unterstützten Lizenzen sind miteinander kompatibel. Darüber hinaus ist dies oft nur eine unidirektionale Kompatibilität, die erfordert, dass ein vollständiges Werk unter der restriktivsten Lizenz der Mutterwerke lizenziert wird.
 
|
|
|
 
|
 
|
|
|---|---|---|---|---|---|
|
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
JSON-Lizenz
JSON- Entwickler Douglas Crockford formulierte, inspiriert von den Worten des damaligen Präsidenten Bush, die „Evil-Doers“-JSON-Lizenz („Die Software soll zum Guten, nicht zum Bösen verwendet werden.“), um die JSON-Bibliotheken als Open-Source aber auch zu zwingt ( Troll ) Unternehmensanwälte (oder diejenigen, die übermäßig pedantisch sind), eine Lizenz vom Staat zu bezahlen. Die subjektive und moralische Lizenzklausel führte zu Lizenzinkompatibilitätsproblemen mit anderen Open-Source-Lizenzen und führte dazu, dass die JSON-Lizenz keine freie und Open-Source-Lizenz war.
Erneute Lizenzierung für Kompatibilität
Manchmal enden Projekte mit inkompatiblen Lizenzen, und der einzige gangbare Weg, das Problem zu lösen, ist die Neulizenzierung der inkompatiblen Teile. Die Neulizenzierung wird erreicht, indem alle beteiligten Entwickler und andere Parteien kontaktiert und deren Zustimmung zur geänderten Lizenz eingeholt wird. Während in der freien und Open-Source- Domäne eine 100%ige Übereinstimmung oft unmöglich ist, geht das Mozilla -Relizenzierungsprojekt aufgrund der vielen beteiligten Mitwirkenden davon aus, dass 95% für die Neulizenzierung der gesamten Codebasis ausreichen. Andere in der FOSS-Domäne, wie Eric S. Raymond , kamen zu anderen Schlussfolgerungen bezüglich der Anforderungen für die Neulizenzierung einer gesamten Codebasis.
Beispiele für die Neulizenzierung
Ein frühes Beispiel für ein Projekt, das aus Gründen der Lizenzinkompatibilität erfolgreich neu lizenziert wurde, ist das Mozilla- Projekt und ihr Firefox- Browser . Der Quellcode von Netscape ‚s Communicator 4.0 Browser wurde ursprünglich im Jahr 1998 unter dem freiNetsCape Public License / Mozilla Public License wurde aber von der Free Software Foundation (FSF) und kritisiert OSI für unvereinbar mit dem GNU General Public License (GPL). Um 2001 herum hat Time Warner in Ausübung seiner Rechte unter der Netscape Public License und auf Ersuchen der Mozilla Foundation den gesamten Code in Mozilla, der unter der Netscape Public License stand (einschließlich des Codes anderer Mitwirkender), an eine MPL 1.1/GPL neu lizenziert 2.0/ LGPL 2.1 Tri-Lizenz , wodurch GPL-Kompatibilität erreicht wird.
Die Vorbis- Bibliothek wurde ursprünglich als LGPL lizenziert , aber 2001 wurde die Lizenz mit Unterstützung von Richard Stallman in die weniger restriktive BSD-Lizenz geändert , um die Einführung der Bibliothek zu beschleunigen.
Das VLC- Projekt hat aufgrund von Lizenzinkompatibilität eine komplizierte Lizenzhistorie, und im Jahr 2007 entschied sich das Projekt aus Gründen der Lizenzkompatibilität, kein Upgrade auf die gerade veröffentlichte GPLv3 durchzuführen . Im Oktober 2011, nachdem der VLC Anfang 2011 aus dem Apple App Store entfernt worden war , hat das VLC-Projekt die VLC-Bibliothek von der GPLv2 auf die LGPLv2 umlizenziert, um eine bessere Kompatibilität zu erreichen. Im Juli 2013 wurde die Software unter der Mozilla Public License neu lizenziert , die VLC-Anwendung würde dann erneut an den iOS App Store übermittelt .
Die GNU Free Documentation License Version 1.2 der Free Software Foundation ist nicht kompatibel mit der weit verbreiteten Creative Commons Attribution-ShareAlike- Lizenz, was beispielsweise für Wikipedia ein Problem war . Auf Ersuchen der Wikimedia Foundation fügte die FSF daher der Version 1.3 der GFDL einen zeitlich begrenzten Abschnitt hinzu, der es bestimmten Arten von Websites, die die GFDL verwenden, ermöglichte, ihre Arbeit zusätzlich unter der CC BY-SA-Lizenz anzubieten. Im Anschluss daran im Juni 2009 die Wikimedia Foundation migriert ihre Projekte ( Wikipedia , etc.) durch duale Lizenzierung auf die Creative Commons Attribution-ShareAlike als Haupt Lizenz, zusätzlich zu dem bisher verwendeten GFDL , um eine verbesserte Kompatibilität Lizenz zu haben , mit das größere Ökosystem für kostenlose Inhalte .
Ein weiterer interessanter Fall war die Umlizenzierung von GPLv2-lizenzierten Linux-Kernel- Header-Dateien durch Google an die BSD-Lizenz für ihre Android- Bibliothek Bionic . Google behauptete, dass die Header-Dateien frei von urheberrechtlich geschützten Werken seien, was sie auf nicht urheberrechtlich geschützte "Fakten" reduzierte und daher nicht unter die GPL fällt. Diese Interpretation wurde von Raymond Nimmer, einem Juraprofessor am Law Center der University of Houston, in Frage gestellt . Apps und Treiber von Android, die immer mehr Android-Funktionen bereitstellen, wurden nach und nach von permissiven zu proprietären Lizenzen umlizenziert.
Im Jahr 2014 änderte das FreeCAD- Projekt aufgrund von GPLv3/GPLv2-Inkompatibilitäten seine Lizenz von GPL auf LGPLv2. Ebenfalls im Jahr 2014 wurde Gang Garrison 2 von GPLv3 auf MPL umlizenziert, um die Bibliothekskompatibilität zu verbessern.
Das mobile Betriebssystem KaiOS wurde vom Betriebssystem Firefox OS/Boot to Gecko abgeleitet , das unter der freizügigen MPL 2.0 veröffentlicht wurde . Es verteilt sich nicht selbst unter derselben Lizenz, daher ist es jetzt vermutlich neu lizenziert und proprietär (aber immer noch größtenteils Open Source). KaiOS verwendet auch den GPL- Linux-Kernel, der auch in Android verwendet wird.
Siehe auch
- Lizenzverbreitung
- Vergleich von freien und Open-Source-Softwarelizenzen (auch Lizenzkompatibilität)
- Rückwärtskompatibilität
- Aufwärtskompatibilität