Logo oslms

Teil 1: Grundlegende Aspekte

1. Allgemein zum Copyleft der GPL

Als „Copyleft“ bezeichnet man Lizenzregeln, mit denen erreicht werden soll, dass die Nutzungsfreiheit einer Open Source Software in all ihren Entwicklungsstadien erhalten bleibt. Sie schreiben daher vor, dass die jeweilige Software in all ihren Fassungen nur unter der Ausgangslizenz verbreitet und geteilt werden darf. Sie sagen sinngemäß: „Sie dürfen diese Software nutzen und verändern. Wenn Sie jedoch eine veränderte Fassung („Bearbeitung“, „modification“) in Umlauf bringen, verbreiten oder teilen, müssen Sie Ihre Version ebenfalls unter der Lizenz zur Nutzung freigeben, die für den bearbeiteten Code gilt (mit anderen Worten: die GPL).“ Diese Verpflichtung impliziert, dass Entwickler von Bearbeitungen ihre Versionen nicht unter Regeln verbreiten dürfen, die gegenüber der Ausgangslizenz Einschränkungen der Rechte oder Verschärfungen der Pflichten vorsehen. 

Wie weit gehend und in welchen Fällen das Copyleft Nachnutzer an die Ausgangslizenz bindet, hängt von seiner konkreten Ausgestaltung ab (also dem Wortlaut der jeweiligen Lizenzklausel). Es gibt Lizenzen mit eingeschränktem Copyleft-Effekt, die nur in manchen Konstellationen und bei bestimmten Code-Kombinationen greifen. Bei der Mozilla Public Licence (MPL) beispielsweise greift die Lizenzbindung nicht, wenn Modifikationen in eigenständigen Dateien gespeichert vertrieben werden. Wird also der Code einer Modifikation oder eines Patches o. ä. nicht mit dem Ausgangscode vermischt, ist der Bearbeiter nicht an dessen Lizenz gebunden und muss bei der Verbreitung seines Beitrags nicht die MPL verwenden. Die GPL ist diesbezüglich strenger und weniger präzise. Sie besagt im Wesentlichen, dass jede Art von modification nur unter der Ausgangslizenz (GPL) verbreitet werden darf. Präzisierungen bzgl. der insofern allentscheidenden Frage, was eine modification ist, enthält die Lizenz aber nur sehr spärlich. Vor allem in Grenzfällen besteht daher erheblicher Interpretationsspielraum. Dieses Problem hat rechtspraktisch eine große Bedeutung: Verstößt ein Nachnutzer gegen das Copyleft, weil er die Regel „falsch“ interpretiert, verliert er seine Nutzungsrechte am GPL-Code. Jeder Vertrieb von Bearbeitungen, der nicht unter der GPL erfolgt, ist eine Urheber­rechtsverletzung, die Schadensersatzansprüche und andere Sanktionen nach sich ziehen kann. 

Nach einem weit verbreiteten Irrtum besagt die Copyleft-Regelung, dass jegliche Anpassung, Modifikation, Bearbeitung des Programms veröffentlicht werden muss. Der Auslöser für dieses Missverständnis ist wohl die Idee, dass die Nutznießer des freien Codes ihre Beiträge ebenfalls wieder an die Gemeinschaft zurückgeben und freigeben müssen. Eine Veröffentlichungspflicht sehen jedoch auch die strengsten Copyleft-Lizenzen nicht vor. Copyleft bedeutet nicht, dass der Bearbeiter veröffentlichen muss. Es bedeutet vielmehr, dass wenn der Bearbeiter seine Fassung/seine Modifikation teilt oder veröffentlicht, er an die Ausgangslizenz gebunden ist. Es handelt sich also nicht um eine Pflicht zur Veröffentlichung, sondern um eine Pflicht zur Vergabe einer bestimmten Lizenz, wenn veröffentlicht oder geteilt wird. 


2. Wirksamwerden des Copylefts aus der GPL

Copyleft und andere wichtige Vertriebspflichten (z. B. zur Bereitstellung des Quellcodes) werden also erst und nur dann wirksam, wenn das Programm geteilt, verbreitet, veröffentlicht wird. In der GPLv2 werden die Weitergabe­vorgänge pauschal als Distribution bezeichnet. Die Copyleft-Klausel findet sich in Ziff. 2b). Sie lautet: 

“You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.”


In der GPLv3 wurden die Begriffe geändert. Handlungen der Weitergabe werden als propagate bzw. convey bezeichnet (s. die Definitionen in Ziff. 0). Nachstehend soll zur Vereinfachung pauschalisierend der Begriff Distribution zur Bezeichnung von Weitergabevorgängen verwendet werden, die die Vertriebspflichten in Open-Source-Lizenzen auslösen. Soweit Unterschiede zwischen GPLv2 und v3 bestehen, wird hierauf hingewiesen.

Generell wird mit dem Begriff der Distribution eine Überlassung von Programmcode an einen Dritten (eine Person oder ein Unternehmen) umschrieben. Diese Überlassung kann darin liegen, dass die Software auf einem Server bereitgestellt wird, von dem sie von Dritten heruntergeladen werden kann oder durch individuelle Überlassungsvorgänge, z.B. durch Vertrieb von Datenträgern oder Übersendung per E-Mail. 

Keine Distribution liegt dagegen vor, wenn eine Software nur intern, also innerhalb eines Unternehmens oder einer Behörde verwendet wird. 

Zudem sieht eine weit verbreitete Ansicht in der Online-Bereitstellung von Software als Service, also etwa bei Webservices, SaaS, Cloud Computing oder ASP, keine Distribution. Hiernach müssen also die Lizenzpflichten, v. a. die Offenlegungspflicht des Sourcecodes, bei diesen Nutzungsformen nicht eingehalten werden. In dieser Frage ist zwischen GPLv2 und GPLv3 zu unterscheiden. Ob die Nutzung als Service dazu führt, dass der Sourcecode der Software und ihrer derivative works offengelegt werden müssen, ist in Bezug auf die GPLv2 umstritten. Nach der GPLv3 ist dies dagegen eindeutig zu verneinen1.

Die wohl herrschende Rechtsauffassung sieht dies bei der GPLv2 genauso2. In der Bereitstellung einer Software als Dienst liege keine Distribution, da hierbei keine Kopien verteilt oder zugänglich gemacht werden. Vielmehr kann der Nutzer lediglich mit der Software interagieren und dessen Funktionen nutzen. Jedenfalls nach US-Rechtsverständnis liege hierin keine Distribution, so dass die Lizenzpflichten nicht eingehalten werden müssten. Die herrschende Auffassung geht von einem ASP-loophole aus, wie es auch in der GPLv3 enthalten ist (dort aber bewusst vorgesehen wurde).

Gegner dieser Auffassung argumentieren, dass zumindest nach deutschem Recht auch das Online-Bereithalten (die „öffentliche Zugänglichmachung“) lizenzpflichtig sei und dass die Einräumung der Nutzungsrechte in der GPL untrennbar an die Einhaltung (und damit die Wirksamkeit) der Vertriebspflichten geknüpft sei3

Angesichts dieser konträren Auffassungen – die beide mit guten Argumenten vertreten werden können – ist eine eindeutige Antwort in Bezug auf Software, die unter der GPLv2 steht, nicht möglich. Nachstehend wird mit der herrschenden Auffassung in der „Open Source-Gemeinde“ davon ausgegangen, dass die Bereitstellung einer Software als Service ebenso wenig eine Distribution im Sinne der GPLv2 darstellt, wie eine conveyance nach der GPLv3. Mit anderen Worten wird hier davon ausgegangen, dass das Copyleft und die Vertriebspflichten beider GPL-Versionen nicht ausgelöst werden, wenn eine GPL-Software Dritten lediglich zur Nutzung als Service zugänglich gemacht wird.


3. Copyleft beim gemeinsamen Vertrieb verbundener GPL-Software und anderen Komponenten

Die Copyleft-Verpflichtung gilt für den Vertrieb aller abgeleiteten Werke („derivatives“). Was ein Derivat ist, ist eine äußerst schwierige und im Detail umstrittene Frage. Besonders problematisch ist die Auslegung des GPL-Copylefts in Bezug auf die Distribution von Code-Kombinationen und von mittelbar abhängigen Programmen.

Grundsätzlich gilt, dass direkte Veränderungen von GPL-Code nur unter der GPL vertrieben werden dürfen. Hiermit gemeint sind Patches, Updates und andere Code-Modifikationen jeglicher Art. Anders ausgedrückt: Modifizierter GPL-Code und Programme, in denen GPL-Code verwendet wird, dürfen nur unter der GPL vertrieben werden. Das gilt beispielsweise immer auch dann, wenn GPL-Dateien und anderer Code zu einem einheitlichen Executable verbunden werden und dies verbreitet wird.

Abgesehen von diesen eindeutigen Fällen ist die Beurteilung schwierig und vom Einzelfall abhängig. Dies gilt v. a. für weniger unmittelbare Verbindungen von Software-Modulen. Beispielsweise ist fraglich, ob und unter welchen Umständen eine mit einer GPL-Applikation interagierende Software-Bibliothek – also an sich zwei eigenständige Programme – unter die GPL gestellt werden muss, wenn beide gemeinsam vertrieben werden. 

Hier gilt als abstrakte Faustregel: Gemeinsam mit GPL-Code vertriebener Programmcode wird nur dann vom Copy­left erfasst, wenn er aus inhaltlicher-funktionaler Sicht ein abgeleitetes Programm ist und in formaler Sicht nicht isoliert vertrieben wird, sondern mit dem GPL-Code zu einem Ganzen „vermengt“ wird. Anders ausgedrückt: Der hinzugefügte Code bzw. das hinzugefügte Modul darf nicht mit GPL-Code vermischt überlassen werden (sondern muss z. B. in ­eigenen Dateien oder Containern gespeichert sein) und er darf nicht auf dem GPL-Code basieren (hiervon abge­leitet sein). Entscheidend sind damit einerseits der technische Bezug der Komponenten zueinander und anderer­seits, wie sie im Rahmen des Vertriebs miteinander verbunden werden. 

Von folgender Faustformel geht die herrschende Rechtsliteratur aus:

Schwierigkeiten bereitet dabei insbesondere das Merkmal der inhaltlich-funktionalen Abhängigkeit. Dieser Aspekt wird zwar in der GPL angesprochen – und ist daher entscheidungsrelevant – wird aber in keiner Weise präzisiert. So ist beispielsweise bis heute die hoch umstrittene Frage offen, ob Kernel-Module für Linux nur unter der GPL vertrieben werden dürfen. 

Als abstrakte Faustregel gilt: Sind zwei Programme als funktionale, voneinander abhängige Einheiten anzusehen, spricht dies dafür, dass sie voneinander abgeleitet sind5. Handelt es sich dagegen um multifunktionale Standardkomponenten (wie es bei (Java-)Bibliotheken häufig der Fall ist), ist indiziert, dass sie nicht voneinander abgeleitet sind. Eine konkrete Einschätzung kann aber letztlich nur im Einzelfall unter genauer Betrachtung aller relevanter Umstände getroffen werden.


4. Fallgruppen Copyleft

Basierend auf diesen Grundlagen haben Fachjuristen (Rechtsprechung gibt es kaum!) einige typische Konstella­tionen Fallgruppen zugeordnet. 

1. Vertrieb von GPL- und anderen Software-Modulen in einem ­Executable

Da jedenfalls keine formale Eigenständigkeit der Module

2. Integration von GPL-Code-Fragmenten in anderen Sourcecode

Da jedenfalls keine formale Eigenständigkeit des Codes

3. Patches, Forkes, Updates etc. einer GPL-Software

Typische Bearbeitung, das Ergebnis ist ein derivative work im eigentlichen Sinn

4. Plugins

Einzelfallfrage, die nach den o. g. Kriterien geprüft werden muss (Handelt es sich um ein „eigenständiges“ Programm, etwa weil es gene­rische Funktionen ausführt und/oder mit verschiedenen Anwendun­gen funktioniert? Werden Plugin und Anwendung formal separiert ­vertrieben? Enthält das Plugin Code der GPL-Anwendung)6

5. Anbindung von Anwendungen über ­Systemaufrufe (Pipes, Sockets, Queues)

Führt für sich genommen nicht dazu, dass die Anwendung als ­derivative des Betriebssystems anzusehen ist. Achtung aber bei nicht-­separiertem Vertrieb (s. 1.). 

6. Anbindung über Schnittstellen

Führt für sich genommen nicht dazu, dass die Anwendung als ­derivative des Betriebssystems anzusehen ist. Achtung aber bei nicht-­separiertem Vertrieb (s. 1.). 

7. Programmbibliotheken

Hängt von der Art der Einbindung ab. Wird eine GPL-Bibliothek statisch verlinkt, entsteht beim Kompilieren ein einzelnes Executable. Dies darf nur unter der GPL vertrieben werden, weil zumindest keine formale Trennung des Codes gegeben ist. Bei dynamischer Verlinkung werden library und Applikation erst beim Nutzer kompiliert. Wenn die Bibliothek auch technisch eigenständig ist, ist ein Vertrieb unter unterschiedlichen Lizenzen zulässig. Letzteres ist umstritten (anders z. B.: Die FSF zur GPL)7.

8. Nutzung von Tools, Output von ­GPL-Applikationen (z. B. Daten)

Der Output, die Arbeitsergebnisse, von Programmen, die unter der GPL stehen, wird vom Copyleft in aller Regel nicht erfasst.8 Das gilt ­genauso für Daten, die bei der Programmbenutzung ­erzeugt werden, wie für ­Texte, die mit einer Textverarbeitung ­geschrieben werden. Auch mit ­einem GPL-Compiler kompilierter Code ist kein „abgeleitetes Werk“. Eine seltene Ausnahme kann hier vorliegen, wenn ein Compiler eigenen Code in die Kompilate einfügt. Solche (wie z. B. Bison) stehen ­jedoch in der Regel unter einer speziellen Lizenz, die den Copyleft-Effekt aufgrund des in die Output-Files übertragenen Codes ausschließt.


5. GPL-Pflichten und Verträge zwischen Anbietern und Kunden

Die Pflichten aus der GPL – sofern sie denn ausgelöst werden – können durch Verträge mit Dritten (z. B. Kunden­verträge) nicht ausgeschlossen oder eingeschränkt werden10. Dies verbietet sie ausdrücklich. 

Siehe z. B. Ziff. 6 Satz 2 GPLv2:

“You may not impose any further restrictions on the recipients’ exercise of the rights granted herein.”


Ein Beispiel: Ein Entwickler will ein Open-Source-LMS anbieten, das er für bestimmte Nutzungszwecke modifiziert hat. Das LMS steht unter der GPLv2. Der Entwickler hat an dem Ausgangsprogramm nicht sämtliche Rechte. Der Kunde erhält die Rechte zur Nutzung des Systems – abgesehen von dessen hinzugefügtem Programmcode – daher nicht vom Entwickler, sondern von den Rechteinhabern am Ausgangsprogramm. Sie werden durch die und unter den Bedingungen der GPL eingeräumt. Die GPL verpflichtet den Entwickler (als Distributor), all seinen Kunden den Quellcode an seiner modifizierten Version zu überlassen und diese ebenfalls unter der GPL zu lizenzieren. Ein Vertrag mit einem Kunden, in dem dieser beispielsweise darauf verzichten soll, dass er die modifizierte Version nach der GPL verwenden kann oder ohne Überlassung des Quellcodes würde zu einer Einschränkung der Nutzungsbefugnisse und -freiheiten führen, die die GPL gewährt. Die Vorgaben der Lizenz würden verletzt. Nach Ziff. 4 der GPLv2 verliert der Entwickler hierdurch seine Nutzungsrechte und kann – von den Rechteinhabern am Open-­Source-LMS – rechtlich in Anspruch genommen werden.

Ein anderes Ergebnis würde gleichermaßen dem Grundgedanken von Copyleft-Lizenzen widersprechen wie dem Willen der Rechteinhaber. Wäre dies möglich, könnte sich der Bearbeiter ohne Weiteres nach Gutdünken über die Lizenzpflichten hinwegsetzen, die sie zur Bedingung für die Nachnutzung aufgestellt haben. Das Copyleft-Prinzip und Open-Source-Lizenzen im Allgemeinen wären damit rechtlich wirkungslos. 


6. Lizenzkompatibilität

Lizenzkompatibilität besteht, wenn bei der Kombination mehrerer Softwarekomponenten zu einem einheitlichen Ganzen sämtliche Lizenzpflichten eingehalten werden können11. Zwei Lizenzen sind kompatibel, wenn sie keine Pflichten enthalten, die die Einhaltung der Pflichten aus der jeweils anderen Lizenz unmöglich machen würde. Vor allem Copyleft-Lizenzen sind meist zueinander inkompatibel. Sogar die GPLv2 ist nicht mit der GPLv3 kompatibel. GPLv2- und GPLv3-Code können also nicht gemeinsam vertrieben werden, wenn hierdurch das Copyleft ausgelöst würde12. Beide Lizenzen sagen sinngemäß: „Wenn Du die Software mit anderer Software kombinierst, darfst Du die Kombination nur unter dieser Lizenz vertreiben.“ Da sich beide Lizenzen unterscheiden, verstößt man unweigerlich gegen eine der Lizenzen, wenn man die andere einhält. Stelle ich die Kombination des Codes unter die GPLv2 kann sie nicht gleichzeitig unter der GPLv3 stehen. Ich verstoße so also gegen die GPLv3.

Die Free Software Foundation (FSF) bietet auf ihren Webseiten viele Informationen zur Kompatibilität der GNU-­Lizenzen untereinander13 als auch zu anderen Lizenzen14. 

Als Faustregel gilt: 

Bedenke: Lizenzen verändern sich. Eine Version kann mit einer anderen Lizenz kompatibel, eine andere Version inkompatibel sein. Es genügt also z. B. nicht zu schauen, ob die Apache Public License (APL) mit „der GPL“ kompatibel ist. Zu untersuchen sind die jeweils konkret involvierten Lizenzversionen, also in diesem Beispiel etwa, ob die APL 2.0 mit der GPLv3 kompatibel ist. 


Fußnoten:

Copyright © 2020 · Impressum | Datenschutz