Warum wir das Buch kommentieren

Das Buch bietet für den aufmerksamen Leser viele wichtige Hintergrundinformationen. Es ist kapitelweise von fünf Autoren (Till Jaeger / Olaf Koglin / Till Kreutzer / Axel Metzger / Carsten Schulz) verfaßt worden, die es leider versäumt haben den Zusammenhang zwischen den Aussagen in den einzelnen Kapiteln herzustellen und die es auch versäumt haben, wichtige Zusammenhänge zu übergeordneten nichtjuristischen Quellen (z.B. der OpenSource Definition herzustellen.

Das Herstellen der fehlenden Zusammenhänge innerhalb des Buches wäre Aufgabe des Lektorats gewesen. Warum diese Zusammenhänge fehlen können wir nicht beurteilen. Die Kenntnis der globalen Zusammenhänge (z.B. zur OpenSource Definition) kann man von reinen Juristen ohne Bezug zur OSS Gemeinschaft nicht erwarten. Wären diese Zusammenhänge jedoch in das Buch eingearbeitet worden, dann hätten einige der im Buch offengelassene Fragen beantwortet werden können. Da die FSF darauf besteht, daß die GNU General Public License (GPL version 2) eine anerkannte OpenSource Lizenz ist, muß die GPL die Bedingungen der OpenSource Definition erfüllen und alle Interpretationsversuche, bei denen die GPL diese Bedingungen nicht einhalten würde, müssen folglich verworfen werden.

Wir versuchen hier daher die fehlenden Zusammenhänge innerhalb des Buches aufzuzeigen und hoffen damit den Nutzen des Buches zu erweitern.

Lizenzhoheit der GPL - welche Version ist maßgeblich?

Auf Seite 6 im ersten Teil Die allgemeine rechtliche Situation wird korrekt darauf hingewiesen, daß ein Vertrag nur zustandekommt, wenn beide Vertragsparteien sich über den Inhalt des Vertrags im Klaren sind und der Annahme des Vertrages in erkennbarer Weise zugestimmt haben. Auf Seite 10 wird dann aber kein Zweifel daran gelassen, ob eine Klausel in der GPL nach der der Autor auch eine Nutzung des Werkes unter Any later Version möglich ist.

Wir sind der Ansicht, daß nur der Autor im Einzelfall entscheiden kann, ob eine Nachfolgeversion der GPL den Autor nicht in unzulässiger Weise benachteiligt. Wir sind daher der Ansicht, daß eine Nutzung des Werkes unter einer Nachfolgeversion der GPLv2 nur dann zulässig ist, wenn das Werk oder eine erneuerte Version des Werkes mit dem Zusatz or any later Version deutlich nach dem Erscheinen der Nachfolgeversion erfolgte. Ein Werk das unter GPLv2 or any later Version herausgegeben wurde, kann daher zur Zeit nicht unter GPLv4 genutzt werden und auch eine Nutzung unter GPLv3 ist nur dann zulässig, wenn das Werk mit erkennbarem zeitlichen Abstand zum Erscheinen der GPlv3 im Juni 2007 erfolgte und daher davon auszugehen ist, daß der Autor zum Zeitpunkt der Veröffentlichung des Werkes Kenntnis vom Inhalt der GPLv3 hatte.

Muss ich meinen gemeinsam mit GPL-Software vertriebenen Code unter die GPL stellen?

Auf Seite 17 im ersten Teil Rechte und Pflichten wird darauf hingewiesen, daß ein Software-Werk, welches durch Modifikation eines Werkes unter GPL entstanden ist, unter die GPL zu stellen ist. Ein eigenständiges Werk, das nicht auf einem GPL-Werk aufbaut, muß jedoch nicht unter die GPL gestellt werden. Dies gilt insbesondere auch dann, wenn es sich bei dem eigenständigen Werk um eine Biliothek handelt, die von einem GPL-Werk verwendet wird und gemeinsam mit dem GPL-Werk vertrieben wird.

Die GPL ist eine anerkannte OpenSource Lizenz, denn sie hält die Anforderungen aus der OpenSource Definition ein, die in Ziffer 9 verbietet Einfluß auf andere Werke zu nehmen die gemeinsam mit einem Werk verteilt werden. Weil die GPL konform zur OpenSource Definition ist, ist es unzulässig ein gemeinsames Werk ausschließlich deshalb zu vermuten, weil ein gemeinsamer Vertrieb mit einem GPL-Werk durchgeführt wird. Anders als im ersten Absatz auf Seite 17 dargestellt, kann die Art des Vertriebs also in Folge der OSS Konformität der GPL keinen Einfluß auf die Bewertung haben.

Die interessante Aussage des ersten Absatz auf Seite 17 ist daher, daß das Buch Die GPL kommentiert und erklärt die Aussage des Buches von Lawrence Rosen, nach der jedes beliebige nicht triviale Programm auch GPL-Biliotheken nutzen darf ohne selbst unter die GPL gestellt werden zu müssen, voll bestätigt.

»Das Programm« und »auf dem Programm basierende Werke«

Ab Seite 36 im zweiten Teil Ziffer 0 GPL (Carsten Schulz) wird unter Anderem erklärt, daß es schwer einzugrenzen ist, was als eine Bearbeitung anzusehen ist. Hier hilft es die Aussagen der FSF (nach denen die GPL als US-Lizenz und nicht als Vertrag einzuordnen ist) zu betrachten. Daß die GPL kein Vertrag nach US-Recht ist, resultiert auch unabhängig von den Aussagen der FSF auch aus den Regeln des US-Rechts. Ein Vertrag nach US-Recht muß wechselseitige Abmachungen enthalten während die GPL nur einseite Festlegungen und Zusagen des Lizenzgebers enthält. Nach US-Copyright darf aber eine Lizenz (da sie eine einseitige Festsetzung ist) nicht die Definition eines abgeleiteten Werkes umdefinieren. Siehe US-Copyright Ziffer 106 und Thomas F. Gordon über generelle Lizenzkompatibilität. Wir haben also in den USA nicht die Definitionen aus der GPL, sondern die eindeutigeren Defintionen des Gesetzes zu beachten. In Europa werden (wie wir im Folgenden beschreiben) die unklaren Definitionen der GPL durch die Festlegungen zu den allgemeinen Geschäftsbedingungen eingeschränkt.

Allgemeine Geschäftsbedingungen

Ab Seite 47 im zweiten Teil Ziffer 2 GPL (Olaf Koglin) wird erklärt, daß die GPL (weil sie eine einseitige Festlegung darstellt) den besonderen Vorschriften für Allgemeine Geschäftsbdingungen unterliegt. Das bedeutet, daß immer dann wenn sich durch mißverständliche Klauseln Unklarkeiten ergeben, die für den Lizenznehmer günstigere mögliche Bedeutung zu wählen ist.

Pflichten bei der Weitergabe - das »Copyleft«

Ab Seite 63 im zweiten Teil Ziffer 2 GPL (Till Jaeger) wird unter Anderem Erklärt, daß eine Weitergabe eines modifizierten Werkes nur dann zulässig ist, wenn die Software insgesamt unter der GPL lizenziert ist. Unter den dort beschriebenen Randbedingungen ist es jedoch unter der Annahme, daß ein resultierendes Gesamtwerk immer ein abgeleitetes Werk des GPL-Anteils ist, nicht zulässig ein Werk unter BSD Lizenz (oder Teile davon) einem GPL-Werk hinzuzufügen. Die BSD-Lizenz gestattet keine Umlizenzierung, daher ist es nicht möglich importierten BSD-Code unter die GPL zu stellen. Wir werden weiter unten klären, ob bzw. unter welchen Randbedingungen es möglich ist, die Forderung eine Software "insgesamt" unter GPL zu stehen, zu erfüllen obwohl Teile des Werkes zweifelsfrei und nicht änderbar unter der BSD-Lizenz stehen. Wir werden im Folgenden auch erklären in welchem Umfang die Forderung der GPL, keine zusätzlichen Beschränkungen zuzulassen, zulässig ist.

»Derivative Work« - viraler Effekt?

Ab Seite 64 im zweiten Teil Ziffer 2 GPL (Till Jaeger) wird unter Anderem Erklärt, daß eine gemeinsame Weitergabe eines GPL Werkes mit einem anderen Werk unter einer anderen Lizenz eine GPL-Verletzung darstellen kann. Hier wurde offensichtlich die Berücksichtigung der OpenSource Definition vergessen, denn die GPL ist eine konforme OSS Lizenz und stellt daher solche Forderungen nicht. Nur wenn das andere Werk (welches nicht unter der GPL steht) tatsächlich auf einem GPL-Werk aufbauend entwickelt wurde, wäre dieses andere Werk als abgeleitetes Werk zu betrachen und dies gilt dann selbstverständlich unabhängig von der Verbreitungsart. Der Code einer Biliothek, die von einem GPL Werk nur benutzt wird, baut aber definitiv nicht auf dem GPL-Werk auf und ist daher eindeutig als eigenständiges Werk zu sehen, daß selbstverstandlich auch zusammen mit einem GPL-Werk vertrieben werden darf ohne dadurch unter die GPL zu geraten.

Allgemeine Grundlagen - Wann ist ein Softwaremodul ein »derived work«?

Auf Seite 67 im zweiten Teil Ziffer 2 GPL (Till Jaeger) wird unter Randziffer 22 und 23 unter Anderem Erklärt, daß es nicht genügt, wenn Softwarebestandeteile inhaltlich selbstständig sind. Diese Behauptung steht aber im Widerspruch zur OpenSource Definition und daher ist die möglicherweise widersprüchliche Formulierung in der GPL so auszulegen, daß die GPL eine OSS-konforme Lizenz bleibt. Auch die Tatsache, daß die GPL den Festlegungen zu den allgemeinen Geschäftsbedingungen unterliegt, macht klar, daß auch nach dieser Regel die für den Lizenznehmer günstigere Regel zu verwenden ist und das ist in diesem Fall die Auslegung unter der eigenständige aber gemeinsam vertriebene Software nicht Zwangläufig der GPL unterliegt.

Kernelmodule

Auf Seite 70 im zweiten Teil Ziffer 2 GPL (Till Jaeger) wird am Beispiel des Dateisystems AFS erklärt, warum AFS ein eigenständiges Werk ist das nicht als abgeleitetes Werk vom Linux Kern anzusehen ist. Die dort vorgebrachten Begründungen treffen auch auf das Dateisystem ZFS zu. Dies dürfte eine für die Linux Kernel-Entwicklung wichtige Feststellung sein.

Headerfiles

Auf Seite 73 im zweiten Teil Ziffer 2 GPL (Till Jaeger) wird behauptet, daß eine andere Situation entstünde wenn Headerfiles separat verteilt werden. Dies berücksichtigt wieder nicht die Tatsache, daß die GPL eine anerkannte OSS Lizenz ist die die OpenSource Definition einhält und daher alles was getrennt vertrieben werden darf, selbstverständlich auch gemeinsam vertrieben werden darf.

Inlinefunktionen

Auf Seite 74 im zweiten Teil Ziffer 2 GPL (Till Jaeger) wird auf Inlinefunktionen in Headerdateien eingegangen. Da diese Funktionen typischerweise klein gegen das sie nutzende Werk sind, greift in Europa das Recht zum wissenschaftlichen Kleinzitat und in den USA das Recht auf fair use.

Programmbibliotheken

Ab Seite 75 im zweiten Teil Ziffer 2 GPL (Till Jaeger) finden sich diverse gedankliche Fehler bei der Interpretation der technischen Situation und den daraus gezogenen Schlußfolgerungen.