052.2 Lektion 1
Zertifikat: |
Open Source Essentials |
---|---|
Version: |
1.0 |
Thema: |
052 Lizenzen für Open Source Software |
Lernziel: |
052.2 Copyleft Softwarelizenzen |
Lektion: |
1 von 1 |
Einführung
Die Bedeutung von Lizenzen sowohl für die Nutzung, aber auch für die Entwicklung von Software wurde bereits beschrieben. Es wundert daher nicht, dass sich freie Software von Anfang an auch durch neue Ansätze der Lizenzierung auszeichnet: Bedingungen für die uneingeschränkte Nutzung oder die kollaborative Entwicklung von Software müssen juristisch definiert sein, um geschützt und durchgesetzt werden zu können.
Im Bewusstsein, das weltweit in nahezu allen Rechtssystemen fest verankerte Urheberrecht nicht infrage stellen oder gar ersetzen zu können, entstand bereits in den 1980er Jahren ein Ansatz, der die urheberrechtlichen Vorschriften zwar respektiert, aber um neue, vor allem das Prinzip der “Freiheit” betonende Vorschriften ergänzt: Copyleft.
Copyleft und die GNU General Public License (GPL)
Richard Stallman, damals Entwickler am renommierten MIT, hatte 1983 das GNU Project zur Entwicklung eines nach seinen Vorstellungen “freien” Betriebssystems gegründet. Schnell wurde deutlich, dass der vom Projekt entwickelte Code juristisch abgesichert werden musste, um beispielsweise nicht einfach von kommerziellen Anbietern übernommen und damit “unfrei” zu werden.
Stallman gründete darum 1985 die gemeinnützige Free Software Foundation (FSF), die ihren Auftrag auf ihrer Website wie folgt zusamenfasst: “Die Free Software Foundation setzt sich für die Freiheit der Computernutzer ein, indem sie die Entwicklung und Verwendung freier (wie in Freiheit) Software und Dokumentation fördert […].”
Ein entscheidendes Instrument dafür ist eine Lizenz, die einerseits geltendes Recht (v.a. das Urheberrecht) respektiert, andererseits die eigenen Vorstellungen von Freiheit juristisch sauber umsetzt. Das Ergebnis war die erste Version der GNU General Public License (GPLv1) im Jahr 1989. Diese Lizenz und zahlreiche Artikel — wie etwa der 1992 von Stallman verfasste “What is Free Software?” — machen deutlich, um was es den sich nun auch als “Bewegung” verstehenden Entwicklern freier Software geht.
Den programmatischen Kern bilden bis heute die von Stallman in dem genannten Artikel formulierten “vier essentiellen Freiheiten”, deren Zählung mit “0” beginnt:
Die Freiheit, das Programm auszuführen wie man möchte, für jeden Zweck (Freiheit 0)
Die Freiheit, die Funktionsweise des Programms zu untersuchen und eigenen Datenverarbeitungbedürfnissen anzupassen (Freiheit 1). Der Zugang zum Quellcode ist dafür Voraussetzung.
Die Freiheit, das Programm zu redistribuieren und damit Mitmenschen zu helfen (Freiheit 2).
Die Freiheit, das Programm zu verbessern und diese Verbesserungen der Öffentlichkeit freizugeben, damit die gesamte Gesellschaft davon profitiert (Freiheit 3). Der Zugang zum Quellcode ist dafür Voraussetzung.
What is Free Software? (deutsche Übersetzung auf gnu.org)
Anders als Lizenzen kommerzieller Produkte, die Beschränkungen hinsichtlich der Nutzung in den Vordergrund stellen, geht es bei freier Software um ein Maximum an Freiheit für Nutzer und Entwickler.
Die Präambel der GNU GPLv1 fasst das wie folgt zusammen:
Konkret soll die General Public License sicherstellen, dass Sie die Freiheit haben, Kopien freier Software zu verschenken oder zu verkaufen, dass Sie den Quellcode erhalten oder erhalten können, wenn Sie ihn benötigen, dass Sie die Software verändern oder Teile davon in neuen freien Programmen verwenden können; und dass Sie wissen, dass Sie diese Dinge tun können.
Version 1 (inoffizielle deutsche Übersetzung)
Jeder hat also das Recht, Software unter der GPL uneingeschränkt zu nutzen, weiterzugeben, zu verändern (was dadurch möglich ist, dass der Sourcecode zugänglich, d.h. “offen” ist) und wiederum die Änderungen weiterzugeben. Es ist sogar möglich, für die Weitergabe der Software Geld zu verlangen:
Eigentlich ermutigen wir Menschen, die freie Software weitergeben, so viel Geld zu verlangen, wie sie wollen oder können. Wenn eine Lizenz den Benutzern nicht erlaubt, Kopien anzufertigen und diese zu verkaufen, handelt es sich um eine unfreie Lizenz. […] Freie Programme werden manchmal kostenlos und manchmal für einen beträchtlichen Preis weitergegeben. Oft ist ein und dasselbe Programm auf beide Arten an verschiedenen Stellen erhältlich. Das Programm ist unabhängig vom Preis frei, weil die Benutzer die Freiheit haben, es zu benutzen.
Selling Free Software
Wenn aber die Freiheiten so weitreichend sind — inwieweit ist Software unter dieser Lizenz geschützt, beispielsweise vor Übernahme in proprietäre Produkte?
Dies ist die Aufgabe des bereits erwähnten Copyleft-Prinzips, das die GPL bereits in Version 1 anwendet, auch wenn der Begriff noch nicht explizit erscheint:
Sie dürfen das Programm nicht kopieren, modifizieren, unterlizenzieren, vertreiben oder übertragen, außer wie ausdrücklich in dieser General Public License vorgesehen.
Das heißt: All diese Freiheiten sind an die Bedingung geknüpft, dass Nutzer bei allem, was sie mit der Software machen, diese Freiheiten bewahren.
Das Copyleft garantiert also nicht nur Freiheiten, sondern fordert von allen Nutzern, dass sie diese Freiheiten auch anderen gewähren. Das wird dadurch erreicht, dass Software unter einer Copyleft-Lizenz (wie etwa der frühen GPLv1) nur dann verändert und weitergegeben werden darf, wenn man die Veränderungen wiederum unter denselben Bedingungen, also unter derselben Lizenz, veröffentlicht.
Das Ideal freier Software, nämlich die kollektive Nutzung und Weiterentwicklung von Software, steht also über den persönlichen Bedürfnissen, die einzelne gegebenenfalls in Bezug auf die Software haben. Entscheidend ist der Grundsatz der Gegenseitigkeit: Wer Freiheiten nutzt, muss diese auch gewähren. Man bezeichnet Copyleft-Lizenzen daher oft auch als reziprok.
Dieser völlig neue Ansatz einer Softwarelizenz erwies sich bereits in Version 1 der GPL als juristisch solide und praxistauglich, und so hat die GPL in den vergangenen fast 40 Jahren, in denen sich der moderne IT-Markt überhaupt erst entwickelte, nur zwei größere Überarbeitungen erfahren.
GPLv2 und GPLv3
1991 legte die Free Software Foundation Version 2 der GNU General Public License (GPLv2) vor, die sich über viele Jahre als beliebteste Lizenz freier Softwareprojekte etablierte. So steht bis heute beispielsweise der Kern des Betriebssystem Linux unter der GPLv2.
Im Vergleich zu Version 1 geht es bei Version 2 vor allem um exaktere Begriffsbestimmungen zur Vermeidung von Mehrdeutigkeiten. So erläutert Version 2 deutlich ausführlicher, was unter “source code” zu verstehen ist.
Interessant ist darüber hinaus der neue Abschnitt 7, der das Prinzip der Freiheit und damit die Gültigkeit der Lizenz absolut setzt und keine Kompromisse — beispielsweise die Integration weniger freier Teile in die Software — zulässt:
Wenn es Ihnen nicht möglich ist, das Programm unter gleichzeitiger Beachtung der Bedingungen in dieser Lizenz und Ihrer anderweitigen Verpflichtungen zu verbreiten, dann dürfen Sie als Folge das Programm überhaupt nicht verbreiten. Wenn zum Beispiel ein Patent nicht die gebührenfreie Weiterverbreitung des Programms durch diejenigen erlaubt, die das Programm direkt oder indirekt von Ihnen erhalten haben, dann besteht der einzige Weg, sowohl das Patentrecht als auch diese Lizenz zu befolgen, darin, ganz auf die Verbreitung des Programms zu verzichten.
Erst 16 Jahre später, im Jahr 2007, veröffentlicht die FSF eine neue Version der GPL, um einerseits technischen Neuerungen — etwa der Bereitstellung von Software-Services über das Internet — wie auch Fragen der Kompatibilität mit inzwischen auch anderen FOSS-Lizenzen Rechnung zu tragen. Sie bleibt in Bezug auf ihre Kernaussagen jedoch stabil und ergänzt lediglich Details zur weiteren Präzisierung. Schauen wir uns einige dieser Ergänzungen etwas näher an.
Nennt die GPLv2 die Bereitstellung von Software noch allgemein distribution (also “Verteilung” oder “Vertrieb”), so präzisiert die GPLv3 diesen Prozess mit zwei neuen Begriffen: propagation (also “Verbreitung” oder “Propagierung”) und conveying (also “Übertragung” oder “Übermittlung”). Der Grund liegt vor allem darin, dass der Begriff “distribution” weltweit in zahlreichen Gesetzen zum Urheberrecht definiert ist. Um Unklarheiten oder gar Konflikte zu vermeiden, wählt die GPLv3 diese neuen Termini und definiert sie wie folgt:
Ein Werk zu “propagieren” bezeichnet jedwede Handlung mit dem Werk, für die man, wenn unerlaubt begangen, wegen Verletzung anwendbaren Urheberrechts direkt oder indirekt zur Verantwortung gezogen würde, ausgenommen das Ausführen auf einem Computer oder das Modifizieren einer privaten Kopie. Unter das Propagieren eines Werks fallen Kopieren, Weitergeben (mit oder ohne Modifikationen), öffentliches Zugänglichmachen und in manchen Staaten noch weitere Tätigkeiten.
Ein Werk zu “übertragen” bezeichnet jede Art von Propagation, die es Dritten ermöglicht, das Werk zu kopieren oder Kopien zu erhalten. Reine Interaktion mit einem Benutzer über ein Computer-Netzwerk ohne Übergabe einer Kopie ist keine Übertragung.
Mit der deutlich wachsenden Zahl kommerzieller Softwareprodukte, deren Verbreitung durch technische Maßnahmen wie Registrierungscodes oder Hardware-Komponenten (sogenannte Dongles) von den Herstellern eingeschränkt wird, gibt es in den späten 1990er Jahren international einige juristische Vorstöße, die die Umgehung dieser Maßnahmen unter Strafe stellen. Dieses sogenannte Digital Rights Management (DRM), von Gegnern abfällig auch als Digital Restrictions Management bezeichnet, ist der FSF ein Dorn im Auge, widerspricht es doch fundamental der Forderung nach der freien Weitergabe von Software.
Als Reaktion enthält Version 3 der GPL einen Passus, nach dem Software unter der GPL nicht unter Berufung auf gesetzliche Vorgaben zum DRM verändert werden darf. Das bedeutet zugleich, dass eine unter der GPLv3 lizenzierte Software zwar DRM nutzen darf, dass anderen aber auch erlaubt ist, solche Maßnahmen zu umgehen.
Häufig fällt in diesem Zusammenhang auch der Begriff Tivoisierung, der in ersten Entwürfen der GPLv3 noch explizit auftaucht, dann aber nicht in die endgültige Fassung übernommen wird. Das Wort geht auf die Firma TiVo zurück, die in ihrem digitalen Videorekorder zwar GPLv2-lizenzierte Software nutzte, zugleich aber technisch verhinderte, dass veränderte Software auf das Gerät aufgespielt und genutzt werden konnte. Nach Auffassung der FSF widersprach dies den Grundsätzen der GPL, und nach einigen Diskussionen trägt die GPLv3 dem mit einem Absatz zu sogenannten user products Rechnung. Sie legt darin allgemein fest, dass Produkte, die GPLv3-lizenzierte Software nutzen, auch Informationen bereitstellen müssen, wie diese Software verändert werden kann.
Eine weitere Ergänzung betrifft Patente, die die FSF auf Software mit dem Hinweis auf deren Behinderung von Freiheit und Innovation grundsätzlich ablehnt. So heißt es schon in der Präambel der GPLv3:
Schließlich und endlich ist jedes Computerprogramm permanent durch Software-Patente bedroht. Staaten sollten es nicht zulassen, dass Patente die Entwicklung und Anwendung von Software für allgemein einsetzbare Computer einschränken, aber in Staaten, wo dies geschieht, wollen wir die spezielle Gefahr vermeiden, dass Patente dazu verwendet werden, ein freies Programm im Endeffekt proprietär zu machen. Um dies zu verhindern, stellt die GPL sicher, dass Patente nicht verwendet werden können, um das Programm nicht-frei zu machen.
Es folgen im Lizenztext noch einige Passagen, die sowohl die Einbindung von Code unter einem Patent durch eine “nicht-exklusive, weltweite, gebührenfreie Patentlizenz” des Lizenzgebers ermöglichen, um Nutzer solchen Codes vor Streitigkeiten zwischen Patentinhabern und Lizenznehmern zu schützen.
Die GNU Affero General Public License (AGPL)
Mit der zunehmenden Verfügbarkeit und Leistungsfähigkeit des Internet entstehen immer mehr Angebote, bei denen die Software lediglich auf den Servern von Anbietern (Application Service Provider, ASP) installiert ist und deren Dienste von Kunden über das Internet abgerufen werden. Dieser Trend hat den Namen Software as a Service (SaaS).
Hier bot die GPLv2 keine Klarheit, ob und wie in solchen Fällen die Bereitstellung des (möglicherweise vom Anbieter veränderten) Sourcecodes zu erfolgen habe. Version 3 der GPL schließt diese als ASP loophole bekannte Lücke, indem sie in Abschnitt 13 ausdrücklich auf eine weitere Lizenz der FSF aus dem Jahr 2007 verweist — die GNU Affero General Public License Version 3 (GNU AGPLv3). Der Name geht auf die Firma Affero zurück, die noch die ersten beiden Versionen dieser Lizenz entwickelte und veröffentlichte.
Die AGPLv3 entspricht im Grunde der GPLv3, regelt aber im Abschnitt “Remote Network Interaction” explizit das ASP-Problem. Überdies enthalten beide Lizenzen den ausdrücklichen Hinweis, dass sie uneingeschränkt miteinander kombinierbar sind.
Zusammengefasst ist die GNU AGPL also eine zur GPL komplementäre Ergänzung, die das Copyleft auch auf Software anwendet, die nicht mehr in lokalen Installationen, sondern ausschließlich in Form von über Netzwerke übertragenen Services genutzt wird.
Kompatibilität von Copyleft-Lizenzen
Die Entwicklung freier Software lebt davon, auf der Arbeit anderer aufzubauen, d.h. Sourcecode anderer zu integrieren, zu modifizieren und wieder zu teilen. Stehen alle Teile einer veränderten oder neu zusammengestellten Software unter derselben Copyleft-Lizenz, zum Beispiel der GPLv3, so ist dies auch problemlos möglich: Die Lizenz verlangt ja, dass das Ergebnis unter derselben Lizenz weitergegeben wird.
Kompliziert wird es dann, wenn Software aus Teilen besteht, die unter verschiedenen Lizenzen stehen — hier sind mehrere Faktoren zu beachten.
Kombinierte und abgeleitete Werke
Freie Software entsteht unter zum Teil sehr unterschiedlichen Voraussetzungen und reicht von einer einfachen Fehlerkorrektur bis zu komplexen Projekten mit Millionen Codezeilen. Unabhängig vom Umfang unterscheidet man bei Fragen der Lizenzierung grundsätzlich zwei Arten von Werken: abgeleitete (derivative) und kombinierte (combined).
Nehmen wir beispielsweise an, einem Software-Projekt A fehlt noch eine bestimmte Funktionalität. Statt diese nun von Grund auf selbst zu entwickeln, bietet es sich an, ein anderes Projekt B, das genau diese Funktionalität bietet, mit A zu verbinden. Die Software von B müsste dafür nicht einmal verändert werden, sondern könnte einfach zu A ergänzt werden. Es handelt sich also um ein kombiniertes Werk. Falls sowohl A als auch B unter derselben Copyleft-Lizenz stehen, ergeben sich für das zusammengesetzte Werk keine Probleme.
Stehen A und B unter verschiedenen Copyleft-Lizenzen, so ist bereits Vorsicht geboten: Ist die Kombination von A und B bereits ein eigenes Werk? Und, wenn ja, unter welcher Lizenz kann bzw. muss es dann stehen? Oder ist ein Konflikt dadurch zu umgehen, dass beide Teile A und B mit ihrer jeweiligen Lizenz voneinander getrennt bleiben und kein neues Werk konstituieren?
Noch schwieriger wird es bei abgeleiteten Werken, wenn also Projekt A die Funktionalität von B nur dadurch für sich nutzen kann, dass es Code von B unmittelbar in den Code von A übernimmt. Aus dieser Integration entsteht ein neues, abgeleitetes Werk, dessen Teile nicht mehr voneinander zu trennen sind.
Bei einem abgeleiteten Werk kommt das Copyleft ins Spiel. Steht beispielsweise A unter einer Copyleft-Lizenz wie der GPLv3, so muss auch das neue, abgeleitete Werk gemäß dem Grundsatz der Reziprozität unter der GPLv3 stehen. Was aber, wenn B unter einer anderen Lizenz steht? Ist es eine Copyleft-Lizenz und ist diese kompatibel mit der GPLv3? Oder, wenn es sich gar um einen anderen Lizenztyp handelt, darf B auch unter einer anderen Lizenz veröffentlicht, also relizenziert werden? Oder schließen die Lizenzen von A und B sogar kategorisch einander aus?
Es geht hier nicht darum, die Kombinationsmöglichkeiten und eventuelle Lösungen aufzuzählen. Wichtig ist, die Komplexität des Problems darzustellen, das aus der Verbindung sehr unterschiedlicher Fragestellungen resultiert:
Technisch ist zunächst zu klären, wie die verschiedenen Teile der Software (in unserem Beispiel A und B) zusammenarbeiten: Sind sie voneinander zu trennen oder gibt es bei der Ausführung Prozesse, die man eben nicht mehr eindeutig dem einen oder dem anderen Teil zuordnen kann?
Juristisch stellt sich die Frage, in welchem Verhältnis die Lizenzen von A und B zueinander stehen. Sind sie zueinander kompatibel oder nur in Teilen oder nur in eine Richtung? Ist Relizenzierung eine Option?
Wie gesagt, wir können die Komplexität dieser Fragen hier nur andeuten, nicht auflösen. Grundsätzlich sind Entscheidungen ohne fundierte juristische Kenntnisse nicht möglich, weshalb Lizenzentscheidungen bei neuen, insbesondere aber auch bei kombinierten und abgeleiteten Werken frühzeitig, sorgfältig und stets nach eingehender juristischer Beratung gefällt werden sollten.
Schwaches Copyleft
Das Copyleft hat sich in den vergangenen Jahrzehnten als überaus robust erwiesen, insbesondere in Form der GPL in den Versionen 2 und 3. Besondere technische Anforderungen veranlassen die FSF aber durchaus dazu, mit Anpassungen ihrer Lizenzen zu reagieren. Mit der GNU Affero General Public License haben wir bereits ein solches Beispiel kennengelernt. Weitere Beispiele schauen wir uns in den folgenden Abschnitten an.
Die GNU Lesser General Public License (LGPL)
Ein in der Softwareentwicklung häufig angewendetes Verfahren ist die Nutzung kleiner Module für Standardaufgaben, beispielsweise für das Öffnen oder das Speichern von Dateien. Diese Module — oder auch Sammlungen solcher Module — bezeichnet man als Software-Bibliotheken. Es sind meist keine selbständig lauffähigen Anwendungen, sondern Routinen, die die eigentliche Anwendung bei Bedarf integriert. Den Integrationsprozess bezeichnet man als Linking, wobei zwei Verfahren unterschieden werden.
Bei statischen Bibliotheken übernimmt die eigentliche Anwendung (über Hilfsprogramme und Zwischenschritte) Code der Module fest in den Code der Anwendung. Demgegenüber bindet bei dynamischen Bibliotheken die Andwendung ein Modul erst bei Bedarf zur Laufzeit ein und lädt es in den Arbeitsspeicher.
Damit stellt sich in Bezug auf das Copyleft und die Lizenzierung allgemein die Frage: Welche lizenzrechtlichen Implikationen hat das Linking? Macht es diese Form der Übernahme von Code beispielsweise notwendig, dass eine Anwendung, die eine unter GPL stehende Bibliothek nutzt, selbst automatisch der GPL unterliegt? Und gilt dies sowohl für das statische wie auch das dynamische Linking?
Das Verfahren des Linking ist in der Softwareentwicklung so allgegenwärtig und die durch das reziproke Copyleft verbundenen Fragen so virulent, dass die FSF mit der GNU Lesser General Public License (LGPL) frühzeitig auch eine lizenzrechntliche Lösung sucht. So entstehen — jeweils zeitgleich mit den Neufassungen der GPL — auch Aktualisierungen der LGPL. Version 1 verweist auch im Namen noch auf das ursprüngliche Problem: GNU Library General Public License. Erst in den Versionen 2 und 3 ist “Library” durch “Lesser” ersetzt und deutet an, um was es inhatlich geht, nämlich eine pragmatische Abschwächung des Copyleft-Prinzips.
Eine unter der LGPL lizenzierte Bibliothek kann demnach von einer Software genutzt werden, ohne dass diese Software dann automatisch selbst dem Copyleft unterliegt. Insbesondere Softwareprojekte unter sogenannten permissiven Lizenzen profitieren von diesem Kompromiss, schafft er doch Rechtssicherheit für die Verbindung von lizenzrechtlich per se nicht kompatiblen Ansätzen.
Für LGPL-lizenzierte Software gilt allerdings nach wie vor, dass Veränderungen an dieser Software selbst dem Copyleft unterliegen, also ebenfalls unter der LGPL stehen müssen.
Bedingung ist allerdings, dass die LGPL-lizenzierte Bibliothek austauschbar ist, dass der Benutzer der Software also die Möglichkeit hat, die Bibliothek durch eine veränderte Variante zu ersetzen. Dafür müssen entsprechende Voraussetzungen geschaffen werden, also unter anderem Informationen bereitgestellt werden, wie ein solcher Austausch vorgenommen werden kann.
Andere Copyleft-Lizenzen
Auch andere FOSS-Projekte und -Organisationen suchen die für ihre Bedürfnisse besten rechtlichen Rahmenbedingungen und entwickeln eigene Lizenzen. Ein Beispiel ist die 1998 gegründete Mozilla Foundation, heute insbesondere bekannt für die beiden von ihr betreuten Projekte: den Internet-Browser Firefox und den E-Mail-Client Thunderbird.
Version 1 der Mozilla Public License (MPL) erscheint 1998, die heute (Stand 2024) aktuelle Version 2.0 im Jahr 2012.
Wie die LGPL wird die MPL oft auch als Lizenz mit “schwachem Copyleft” bezeichnet. Tatsächlich sucht sie den Ausgleich zwischen den strikten Forderungen des Copyleft und den Integrationsmöglichkeiten auch mit kommerziellen Produkten. Dies erreicht sie unter anderem durch ein als File-Level Copyleft bezeichnetes Prinzip: Nimmt man eine Veränderung an einer Datei vor, die zu einer Software unter der MPL gehört, so kann man diese Datei sogar in eine proprietäre Software integrieren, solange die so veränderte Datei selbst wieder unter MPL steht und damit zugänglich ist.
Ein weiteres Beispiel für eine schwache Copyleft-Lizenz ist die Eclipse Public License (EPL) der Eclipse Foundation. Die aktuelle Version 2.0 aus dem Jahr 2017 ist der MPL sehr ähnlich und wird häufig auch als die “business-freundlichste” Ausgestaltung einer Copyleft-Lizenz bezeichnet. Oft sind die verschiedenen Copyleft-Lizenzen — es gibt noch weitere als die hier genannten — vor allem jedoch aus der historischen Entwicklung und weniger aus deutlichen juristischen Unterschieden zu erklären.
Geführte Übungen
-
Wofür steht die Abkürzung GPL?
-
Warum bezeichnet man Copyleft-Lizenzen auch als reziprok?
-
Welche Copyleft-Lizenz der FSF bietet sich für Software-Bibiotheken an?
-
Welche englischen Begriffe ersetzen den Begriff “distribution” in GPLv3 und warum?
-
Welche der folgenden Copyleft-Lizenzen wurden von der Free Software Foundation herausgegeben?
GPL version 3
AGPL version 1
LGPL version 2
MPL 2.0
EPL version 2
Offene Übungen
-
Welche der folgenden sind Copyleft-Lizenzen?
GPL version 2
3-clause BSD License
LGPL version 3
CC BY-ND
EPL version 2
-
Sind Teile zweier Software-Projekte, die unter verschiedenen Lizenzen mit starkem Copyleft stehen, grundsätzlich zu einem abgeleiteten Werk zu verbinden? Begründen Sie!
-
Welche der folgenden Lizenzen haben ein starkes Copyleft, welche ein schwaches?
Common Development and Distribution License (CDDL) 1.1
GNU AGPLv3
Microsoft Reciprocal License (MS-RL)
IBM Public License (IPL) 1.0
Sleepycat License
-
Beschreiben Sie einige Kompatibilitätsprobleme, die bei der Verbindung von Software unter einer Lizenz mit schwachem Copyleft und Software unter einer Nicht-Copyleft-Lizenz entstehen können!
Zusammenfassung
Diese Lektion behandelt die Eigenschaften von Softwarelizenzen, die dem Grundsatz des Copyleft folgen. In den 1980er Jahren von der Free Software Foundation entwickelt, ist die GNU General Public License (GPL) die derzeit beliebteste Lizenz mit starkem Copyright. Trotz einiger Überarbeitungen bis zur aktuellen Version 3 sind ihre Grundforderungen nahezu unverändert geblieben: Die durch die Lizenz gewährten Freiheiten, die Software uneingeschränkt nutzen, weitergeben und verändern zu können, müssen stets gewahrt bleiben. Das bedeutet: Die veränderte Software darf nur unter denselben Bedingungen (d.h. derselben Lizenz) weitergegeben werden.
Technische Neuerungen wie auch der Wunsch nach Rechtssicherheit bei der Zusammenarbeit mit anderen Projekten veranlassten die FSF zur Entwicklung ergänzender oder alternativer Lizenzen: So trägt die GNU Lesser General Public License (LGPL) dem in der Softwareentwicklung häufig genutzten Verfahren des statischen oder dynamischen Linkens von Software-Bibliotheken Rechnung. Die GNU Affero General Public License (AGPL) reagiert wiederum auf den technischen Umstand, dass Software häufig nur noch in Form von Services über das Netzwerk (v.a. das Internet), also nicht in lokalen Installationen genutzt wird.
Neben der FSF haben auch andere Projekte, beispielsweise die Mozilla Foundation oder die Eclipse Foundation, Copyleft-Lizenzen entwickelt. Auch diese suchen durch ein schwächeres Copyleft einen Kompromiss zwischen der Sicherung der durch die Lizenz gewährten Freiheiten und einer einfacheren Verbindung mit Software unter anderen Lizenzen.
Grundsätzlich ist Lizenzkompatibilität ein wichtiges Thema bei Copyleft-Lizenzen, denn das Prinzip freier, kollaborativer Softwareentwicklung ist mit den durch die jeweilige Lizenz bestimmten rechtlichen Bedingungen in Einklang zu bringen. Bei jeder Form der Kombination von Software unter verschiedenen Lizenzen sind die rechtlichen Bedingungen im Einzelfall genau zu prüfen.
Antworten zu den geführten Übungen
-
Wofür steht die Abkürzung GPL?
General Public License
-
Warum bezeichnet man Copyleft-Lizenzen auch als reziprok?
Das Prinzip des Copyleft verlangt, dass Freiheiten, die durch eine Lizenz gewährt werden, uneingeschränkt auch anderen gewährt werden müssen. Nimmt man zum Beispiel eine Änderung an einer unter der GPL stehenden Software vor, so ist man im Sinne dieser Wechselseitigkeit dazu verpflichtet, diese Änderungen unter denselben Bedingungen anderen zugänglich zu machen.
-
Welche Copyleft-Lizenz der FSF bietet sich für Software-Bibiotheken an?
GNU Lesser General Public License (GNU LGPL)
-
Welche englischen Begriffe ersetzen den Begriff “distribution” in GPLv3 und warum?
Es sind die Begriffe “convey” und “propagate”. Hintergrund ist, dass der Begriff “distribution” fest im internationalen Urheberrecht verankert ist. Um Konflikte oder Missverständnisse zu vermeiden, verzichtet die die GPL in Version 3 auf diesen Begriff.
-
Welche der folgenden Copyleft-Lizenzen wurden von der Free Software Foundation herausgegeben?
GPL version 3
X
AGPL version 1
LGPL version 2
X
MPL 2.0
EPL version 2
Antworten zu den offenen Übungen
-
Welche der folgenden sind Copyleft-Lizenzen?
GPL version 2
X
3-clause BSD License
LGPL version 3
X
CC BY-ND
EPL version 2
X
-
Sind Teile zweier Software-Projekte, die unter verschiedenen Lizenzen mit starkem Copyleft stehen, grundsätzlich zu einem abgeleiteten Werk zu verbinden? Begründen Sie!
Nein. Lizenzen mit starkem Copyleft verlangen in der Regel, dass veränderte Versionen unter derselben Lizenz stehen. Das schließt grundsätzlich auch Relizenzierung aus. Die Verbindung von Lizenzen, die beide diesen Grundsätzen folgen, stellt also einen unauflösbaren Widerspruch dar.
-
Welche der folgenden Lizenzen haben ein starkes Copyleft, welche ein schwaches?
Common Development and Distribution License (CDDL) 1.1
schwach
GNU AGPLv3
stark
Microsoft Reciprocal License (MS-RL)
schwach
IBM Public License (IPL) 1.0
schwach
Sleepycat License
stark
-
Beschreiben Sie einige Kompatibilitätsprobleme, die bei der Verbindung von Software unter einer Lizenz mit schwachem Copyleft und Software unter einer Nicht-Copyleft-Lizenz entstehen können!
Während starkes Copyleft verlangt, dass die Weitergabe der veränderten Software unter derselben Lizenz erfolgt, sind bei schwachem Copyleft die Bedingungen “gelockert”. Dennoch wirft auch hier jede Kombination mit anderen Lizenzen grundsätzliche Fragen der Kompatibilität auf. Bei deren Beantwortung sind wichtige Aspekte zu berücksichtigen: Sind die ursprünglichen Teile der beiden Softwareprojekte in dem neuen Werk klar voneinander getrennt und gegebenfalls weiterhin unterschiedlich zu lizenzieren? Auf welcher Ebene findet die Verbindung der beiden ursprünglichen Softwareprojekte überhaupt statt: Wird Sourcecode direkt übernommen oder wird “nur” dynamisch gegen die andere Software (Bibliothek) gelinkt? Erlaubt einer der beiden Lizenzen grundsätzlich Relizenzierung? Alle Fragen dieser Art können nur nach genauer Analyse der jeweiligen Lizenzen und mit fachjuristischer Expertise beantwortet werden.