zurück zum Artikel

Neue Versionen von GPL und LGPL

Wissen | Hintergrund

Nach einem halben Jahr Diskussion hat die FSF den zweiten Entwurf der GPLv3 und den ersten Entwurf einer neuen LGPL3 vorgestellt. Was hat sich geändert und wo herrscht noch Diskussionsbedarf bei den wichtigsten Open-Source-Lizenzen?

Die größte Gemeinschaftsarbeit, die jemals an einer Softwarelizenz vorgenommen wurde, trägt erste Früchte. Seitdem die Free Software Foundation (FSF) im Januar einen ersten Diskussionsentwurf [1] für Version 3 der GNU General Public License (GPL) vorgelegt hat, hat die Free Software Foundation (FSF [2]) ein halbes Jahr, drei Konferenzen und über 1000 Änderungsvorschläge später den zweiten Entwurf [3] fertiggestellt. Alle denkbaren juristischen und technischen Aspekte waren in zahlreichen Telefonkonferenzen von drei Komitees und gut einem Dutzend Unterkomitees diskutiert worden, Wünsche vorgetragen und unterschiedliche Rechtsvorstellungen ausgetauscht.

Dass der Mammutprozess auch effektive Ergebnisse zu Tage bringt, zeigt der neue Entwurf. Der Text ist an vielen Stellen vollständig umgekrempelt, enthält neue Ideen und berücksichtigt zahlreiche Anregungen. Letztlich liegt die Entscheidungsgewalt bei den Hauptakteuren in der Free Software Foundation (FSF [4]), nämlich ihrem Gründer Richard Stallman und dessen juristischen Adlatus, Juraprofessor Eben Moglen. Dennoch wurden zahlreiche Kritikpunkte von außen aufgegriffen, und der neue Entwurf zeigt etwas von einem Kompromiss zwischen den Interessen der Entwickler, der Softwarewirtschaft und der Anwender.

Besonders kontrovers diskutierte man die Themen DRM und Softwarepatente. Es verwundert daher nicht, dass sich hier substanzielle Änderungen ergeben haben. So bezieht die Präambel der GPLv3 nicht mehr pauschal gegen "Digital Restriction Management" Position, sondern bezieht sich konkret auf die Unvereinbarkeit von Trusted Computing – also die Beschränkung durch Hardware, neue Software aufzuspielen – mit Freier Software. Das erscheint durchaus sinnvoll, da viele Aspekte von DRM, etwa die Abrechnung bei der Nutzung von Musik oder Filmen, keinen unmittelbaren Bezug zur Nutzung von Freier Software haben. Soll hingegen GPL-Software so mit DRM-Systemen vertrieben werden, dass das DRM die freie Nutzbarkeit der Software im Sinne der GPL beschränkt, so verbietet Ziffer 3 des neuen Entwurfs diesen Vertrieb an sich.

Allerdings enthält der zweite Absatz von Ziffer 3 noch Regelungen mit dem Ziel, die Umgehung von technischen Schutzmaßnahmen zu ermöglichen, die mit Hilfe von Freier Software realisiert werden. Um dies an einem Beispiel zu verdeutlichen: Wer ein DRM-System mit Hilfe von GPL-Programmen erstellt, soll gleichzeitig auf das Recht verzichten, die Umgehung der technischen Schutzmaßnahme durch Änderung dieser Software zu verbieten. Hintergrund dieser Klausel sind die Regelungen im DMCA und der europäischen Richtlinie zum Urheberrecht in der Informationsgesellschaft, die rechtlich die Umgehung von technischen Schutzmaßnahmen verbieten. Hier fürchtet die FSF eine Beschneidung der Änderungsfreiheit von Freier Software.

Es ist aber zweifelhaft, ob durch die geplante GPL-Klausel auch wirklich Weiterentwicklungen ermöglicht werden können, die als Umgehung technischer Schutzmaßnahmen anzusehen sind. Denn eine solche Umgehung können nicht die Hersteller der DRM-Systeme verbieten, sondern die Inhaber der Rechte an Musik, Filmen und anderen urheberrechtlich geschützten Werken. Diese verpflichtet die GPL aber nicht, sodass die Klausel ins Leere zu laufen droht. Ob diese Frage auch praktische Relevanz erhält, steht hingegen auf einem anderen Blatt: Es dürfte nicht sehr wahrscheinlich sein, dass die Verwerterindustrie ihre DRM-Systeme in größerem Umfang mit GPL-Programmen realisiert und dabei jedermann den Sourcecode zur Verfügung stellt.

Viel Kritik an den Klauseln zu Softwarepatenten kam aus Reihen der IT-Industrie, die die pauschale Ablehnung ebenso zu weitgehend empfand wie die Regelung einer Patentlizenz für die Nutzer von GPL-Programmen. Der neue Entwurf spricht sich zwar weiterhin gegen Softwarepatente aus, erwähnt aber explizit nur noch "software on general-purpose computers", also Softwarepatente im Bereich von Universalrechnern. Softwarepatente im Rahmen von Steuerungs- und Regelungssystemen, beispielsweise in Kraftfahrzeugen, sind damit offenbar von der Pauschalkritik ausgenommen.

Eine interessante Änderung hat auch Ziffer 11 des GPL-Entwurfs erfahren: Während der erste Entwurf noch vorgesehen hatte, dass die Inhaber von Patentrechten, die ein GPL-Programm vertreiben, eine einfache Patentlizenz an die Nutzer erteilen, so verfolgt der zweite Entwurf ein neues Konzept. Anstatt einer Lizenzierung der Patente ist lediglich ein Verzicht auf die Geltendmachung von Patentrechten vorgesehen. Damit soll den Bedenken Rechnung getragen werden, wonach eine einfache Patentlizenz über die Nutzung des konkreten GPL-Programms hinausgehen könnte und damit übermäßig in die Rechte des Patentinhabers eingreift. Zwar sollen "implizite Lizenzen" (durch das Einfügen von patentiertem Code in eine GPL-Software) von der Regelung unberührt bleiben, aber es ist fraglich, ob neben der konkreten Regelung der Ziffer 11 noch eine stillschweigende Patentlizenz durch die Copyleft-Regelung angenommen werden kann.

Problematisch wird damit jedoch der Fall eines Patentverkaufs. Während eine echte Lizenz solch einen Verkauf "überlebt" und auch gegenüber dem Käufer eines Patents gilt, wirkt ein Verzicht auf die Geltendmachung von Patentrechten nur schuldrechtlich, das heißt der Käufer des Patents wäre nicht mehr an diesen Verzicht gebunden und könnte Patentverletzungen verfolgen. Daher dürfte es um diese Regelung sicherlich noch weitere Diskussionen geben.

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 [5] 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 [6])


URL dieses Artikels:
http://www.heise.de/-221961

Links in diesem Artikel:
[1] https://www.heise.de/ct/artikel/GPLv3-Entwurf-einer-neuen-Lizenz-fuer-Open-Source-Software-221895.html
[2] http://www.fsf.org
[3] http://gplv3.fsf.org/gpl-draft-2006-07-27.html
[4] http://www.fsf.org
[5] http://gplv3.fsf.org/lgpl-draft-2006-07-27.html
[6] mailto:odi@heiseopen.de