Neue Versionen von GPL und LGPL

Wissen | Hintergrund

Seite 2: Neue Versionen von GPL und LGPL

Die Regelungen zur Lizenzkompatibilität und zur Definition des zur Verfügung zu stellenden Sourcecodes haben an Klarheit gewonnen. Auch wenn diese Definition nunmehr eine ganze Seite einnimmt und sicherlich noch Kürzungspotenzial hat, stellt sie doch klar, inwieweit Schlüssel bei der Verwendung von Kryptotechnik zur Verfügung gestellt werden müssen. Hier hatte Linux-Initiator Linus Torvalds befürchtet, dass die GPL auch zur Offenlegung der Keys von privaten Verschlüsselungstechniken zwingen könnte. Der neue Entwurf stellt klar, dass ein Schlüssel nur dann zum Sourcecode gehört, wenn er für die Installation oder Ausführung einer veränderten Programmversion erforderlich ist. Für verschlüsselten Output einer GPL-Software muss jedoch kein Schlüssel an Dritte weitergegeben werden.

Die Regelung zur Kompatibilität der GPL mit anderen Open Source-Lizenzen hat man sprachlich überarbeitet. Hier ist jetzt von "additional terms", also zusätzlichen Lizenzbedingungen, die Rede, die dei GPLv3 wiederum in "zusätzliche Gestattungen" und "zusätzliche Bedingungen" unterteilt. Mit "zusätzlichen Gestattungen" sind Lizenzen gemeint, die wie die BSD-Lizenz oder die LGPL keine oder eine abgeschwächte Copyleft-Klausel enthalten und damit hinter den Pflichten aus der GPL zurückbleiben. Code unter solchen Lizenzen lässt sich GPL-Programmen verwenden, wenn das Gesamtprogramm unter der GPL genutzt werden darf.

Die Gestattung "zusätzlicher Bedingungen" soll die Kombination mit Code unter Lizenzen ermöglichen, die zwar über die GPL hinausgehende Pflichten enthalten, die aber als nicht so restriktiv angesehen werden, dass die gemeinsame Nutzung ausgeschlossen sein müsste. Dies betrifft etwa bestimmte markenrechtliche Verbote oder abweichende Haftungs- und Gewährleistungsausschlüsse. Der neue Entwurf enthält nunmehr eine Auffangklausel für solche Verbote oder Gestattungen, die die GPL ebenso enthält, die aber anders formuliert sind. Außerdem müssen abweichende Lizenzbedingungen im Sourcecode zentral aufgeführt werden.

Neu im zweiten Entwurf ist eine "Konzernklausel" in Ziffer 10. Danach muss bei Asset Deals und Unternehmensübernahmen dem Rechtsnachfolger von Softwarekopien auch der entsprechende Sourcecode zur Verfügung gestellt werden. das soll vermeiden, dass bei rein unternehmensinternen Programmänderungen, die noch nicht als Vertriebshandlungen anzusehen sind und daher auch keine Lizenzpflichten mit sich bringen, der Zugriff auf den Sourcecode verhindert werden kann.

Von praktischem Interesse für Distributoren ist eine neue Alternative für den Vertrieb der Software im Objectcode. Mussten sie bislang die Quelltexte direkt mitliefern oder mindestens drei Jahre lang den Sourcecode auf Anforderung auf einem Datenträger übersenden, soll künftig auch die Bereitstellung im Internet ausreichen. Das kommt insbesondere Anbietern entgegen, die sich den Verwaltungsaufwand für das Erstellen und Versenden von Datenträgern ersparen möchten. Gleichzeitig hat man die Idee aufgegeben, dass der Distributor für die Übersendung des Datenträgers das Zehnfache der Erstellungskosten verlangen darf. Nach zahlreichen Beschwerden von Programmierern wurde wieder die Regelung aus der GPL2 aufgenommen, wonach die Erstellungskosten nur einfach berechnet werden können.

Eher nebenbei und ohne ausführlichere Anmerkungen wurde ein heißes Eisen angefasst: Die Regelung über das Copyleft, das heißt die Frage, was als von einem GPL-Programm abgeleitetes Werk ("derivative work") ebenfalls der GPL unterliegt. Die Erläuterungen in Ziffer 5 des ersten Entwurfs zu dem, was als "derivative work" anzusehen ist, sind weitgehend gestrichen, was der Interpretation über die Weite des Copylefts neuen Spielraum eröffnet.

Dabei kommt ein neuer Aspekt hinzu: Wenn eigenständige Bestandteile spezifisch für die Kombination mit einem GPL-Programm vorgesehen sind, müssen diese auch der GPL unterstellt werden. Sicherlich wird die Copyleft-Klausel damit nicht weniger Diskussionen über ihren Geltungsumfang nach sich ziehen als dies bei der GPL2 der Fall war. Letztlich ist dies bei einer solch schwierigen Abgrenzung auch kaum anders möglich.

Das erste, was an dem gleichzeitig vorgestellten ersten Entwurf der LGPL3 auffällt, ist die Länge – oder, genauer gesagt, die Kürze des Textes. Der beträgt nunmehr gerade ein gutes Viertel des ursprünglichen Textes. Dies liegt im Wesentlichen daran, dass die LGPL nunmehr auf die GPL verweist und deren Bestimmungen "inkorporiert". Damit fallen die Standardklauseln weg und es sind nur noch die Besonderheiten der Copyleft-Klausel für Bibliotheken zu regeln.

Die LGPL ist jetzt als "zusätzliche Gestattung" im Sinne der Ziffer 7 GPL definiert. Allerdings erschöpfen sich die Neuerungen nicht in der Übernahme der geplanten Änderungen für die GPL. Während die LGPL2 stark auf die klassische Verlinkung in einem ausführbaren Binary ausgerichtet war, berücksichtigt der Entwurf für die LGPL3 auch objektorientierte Programmierung wie etwa bei Java-Klassen und vermeidet damit Auslegungsprobleme.

Der GPL3-Prozess ist noch nicht beendet. Im Herbst soll der dritte Entwurf veröffentlicht werden und Anfang nächsten Jahres dann die fertige GPL3. Bis dahin bleibt noch viel Arbeit für die beteiligten Kreise. Allerdings zeigen die neuen Entwürfe, dass die FSF auf einem guten Weg ist. Ob letztlich eine neue Lizenzversion dabei entsteht, die wirklich von der Mehrheit der Entwickler als eine bessere Alternative zur GPL2 akzeptiert werden kann, muss die Zukunft noch zeigen. Bislang besteht jedenfalls die berechtigte Hoffnung. (odi)