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.
  • Die GPL enthält das Wort linken nicht, daher kann ein Unterschied zwischen statischem und dynamischem Linken nur dann entstehen wenn dabei eine andere rechtliche Gesamtsituation entstünde. Bei einer technisch identischen (oder nahezu identischen) Situation, ist eine andere rechtliche Gesamtsituation unwahrscheinlich.
  • Beim dynamischen Linken unter Linux (z.B. gegen libc) werden (anders als bei Solaris) Teile der betreffenden Biliothek in das resultierende Binary kopiert. Technisch gesehen ist daher in diesem Fall kein erkennbarer Unterschied zwischen statischem und dynamischem Linken.
  • Das Buch macht keine erkenbare Unterscheidung zwischen einem GPL Programm, das gegen eine Nicht-GPL-Bibliothek linkt und einem Nicht-GPL-Programm das gegen eine GPL-Bibliothek linkt.
  • Das Buch leider auch nicht darauf ein, daß eine unabhängige Biliothek, nur weil sie von einem anderen Werk benutzt wird, nicht ein abgeleitetes Werk des sie benutzenden Werkes werden kann.
  • »GPL-kompatible« Lizenzen

    Auf Seite 77 im zweiten Teil Ziffer 2 GPL (Till Jaeger) wird auf GPL-kompatible Lizenzen eingegangen ohne zu belegen warum eine bestimmte Lizenz »kompatibel« zur GPL sein soll. Die dort gemachten Aussagen beruhen jedoch offenbar auf der Annahme, die Definitionen in der GPL zu abgeleiteten Werken seien zulässig.

    Würde man dieser Annahme folgen, dann wären aber nicht einmal die BSD Lizenz und die GPL kompatibel zueinander, denn die BSD Lizenz gestattet keine Umlizenzierung des unter der BSD Lizenz stehenden Werkes während die GPL verlangt, daß das resultierende Werk als Ganzes unter die GPL zu stellen sei.

    Die Gültigkeit dieser Forderung der GPL geht im US-Fall von der Zulässigkeit der Umdefinition des US-Copyrights aus. Die Zulässigkeit dieser Forderung ist aber nicht gegeben, da die GPL nach US-Recht kein Vertrag sondern eine Lizenz darstellt. Daher stellen Kombinationen eines GPL Werkes mit einem erkennbaren anderen Werk unter einer anderen Lizenz (oder Teilen davon) immer ein zulässiges Sammelwerk dar.

    In Europa wird die GPL als Vertrag gesehen der nach den Regeln für Allgemeine Geschäftsbedingungen zu interpretieren ist. Da der Absatz der GPL, der Ziffer 2c) folgt aber mehrdeutig formuliert ist, ist er so zu interpretieren wie es für den Lizenznehmer am günstigsten ist. Das ist in diesem Fall die Annahme eines zulässigen Sammelwerkes.

    Daher stellen sowohl in Europa als auch in den USA, Kombinationen eines GPL Werkes mit einem erkennbaren anderen Werk unter einer anderen Lizenz (oder Teilen davon) ein zulässiges Sammelwerk dar, sofern sich die zulässigen Forderungen der beteiligten Lizenzen unter der Annahme eines Sammelwerkes nicht widersprechen. Unter diesen Randbedingungen kommen wir zu folgender Einschätzung für die Kompatibilität zur GPLv2:

    Beispiele für GPLv2-inkompatible Lizenzen:
  • GPLv3
  • Eclipse Public License
  • CPL
  • Die GPLv3 enthält Forderungen die im Widerspruch zur GPLv2 stehen und die GPLv3 versucht die Erstellung von Sammelwerken zu verbieten. Da der Versuch zur Verhinderung von Sammelwerken aber in den Bereich der durch den Rechteinhaber lizenzierbaren Rechte fällt, ist er mit großer Wahrscheinlichkeit zulässig. Dann wäre allerdings die GPLv3 auch inkompatibel zur BSD-Lizenz.
    Beispiele für GPLv2-kompatible Lizenzen:
  • BSD-Lizenz
  • MIT-Lizenz
  • Apache Lizenz-2.0
  • MPL
  • CDDL
  • Public Domain
  • Die GPLv2 verlangt, daß jedes Werk, das von einem unter GPL stehendem Werk abgeleitet ist, "insgesamt" unter die GPL zu stehen ist. Da die BSD-Lizenz eine Änderung der Lizenz des unter der BSD-Lizenz publizierten Codes nicht gestattet und da es als allgemein akzeptiert gilt das BSD-Code mit GPL-Code vermischt werden darf, kann dies nur nur erfolgen, wenn dabei angenommen wird das bei der Vermischung von BSD- und GPL-Werken immer ein Sammelwerk gebildet wird.

    In einem Sammelwerk gelten die Bestimmungen der GPL nur für den unter der GPL stehenden Anteil. Dies gilt speziell auch für das Verbot der Einführung von über die Regelungen der GPL hinausgehenden Beschränkungen. Daher ist es in einem Sammelwerk unerheblich ob die Bestimmungen einer anderen beteiligten Lizenz nicht die Forderungen der GPL erfüllen. Relevant für die Zulässigkeit des Sammelwerks ist nur ob sich die Kombination der Forderungen der beteiligten Lizenzen erfüllen läßt.

    Unter diesen Randbedungungen fällt dann auf, daß bei der Vermischung von MPL-Code bzw. CDDL-Code mit GPL-Code nur ein unbedeutender Unterschied zur Vermischung von BSD-Code mit GPL-Code verbleibt:

    MPL-Code bzw. CDDL-Code muß in eigenständigen Dateien verbleiben, während BSD-Code in eine gemeinsame Datei mit dem GPL-Code kopiert werden darf, sofern dabei der BSD-Header mitkopiert wird.

    Die Definition des Source Codes in Ziffer 3 Absatz 2 GPL

    Auf Seite 85 im zweiten Teil Ziffer 3 GPL (Olaf Koglin) wird auf eine wichtige Tatsache aufmerksam gemacht, die häufig fehlinterpretiert wird. Auch wir weisen daher nochmals darauf hin, daß die in GPL Ziffer 3 genannten Skripte unter einer beliebigen Lizenz stehen können, solange sie nur eine freie Weitergabe gestattet.

    Verbot von Erwerberbeschränkungen (further Restrictions)

    Auf Seite 106 im zweiten Teil Ziffer 6 GPL (Carsten Schulz) wird behauptet, die Regelungen in der ursrprünglichen Fassung der BSD-Lizenz würden zusätzliche Beschränkungen zur GPL einführen. Dies trifft aber in dieser Form nicht zu, denn sowohl die ursprüngliche, wie auch die aktuelle Fassung der BSD-Lizenz gestatten es dem Lizenznehmer nicht die Lizenz zu ändern. Eine Verbindung von BSD-Code und GPL-Code ist daher (unabhängig davon ob die ursrprüngliche Fassung oder die aktuelle Fassung der BSD-Lizenz verwendet wird) nur in Form eines Sammelwerks möglich. Bei einem Sammelwerks wirkt sich die benannte Klausel aus Ziffer 6 der GPL nur auf den GPL-Anteil des Sammelwerks aus und hat keine Wirkung auf den BSD-Anteil.

    Die Schlußfolgerung daraus ist, daß wenn es überhaupt rechtlich zulässig ist BSD-Code mit GPL-Code zu vermischen, dann ist dies mit der ursrprünglichen Fassung der BSD-Lizenz und der aktuellen Fassung gleichermaßen möglich.

    Sondervereinbarungen

    Auf Seite 132 im zweiten Teil Ziffer 10 GPL (Till Kreutzer) wird unbelegt behauptet, die BSD-Lizenz gestatte eine Umlizenzierung. Dies ist offensichtlich falsch, denn die Umlizenzierung stellt nach dem Urheberrecht eine aussließlich dem Urheberrechtsinhaber zugebilligte Handlung dar. Das Recht zur Umlizenzierung könnte zwar durch den Urheberrechtsinhaber an andere weitergegeben werden, doch fehlt im BSD-Lizenz-Text eine solche Rechteeinräumung. Die BSD-Lizenz gestattet auch keine Unterlizenzierung, daher bekommt jeder Lizenznehmer seine Rechte (wie bei der GPL) immer direkt vom urspünglichen Urheberrechtsinhaber. Als Folge bleibt die Umlizenzierung von BSD-Code eine Handlung, der im Einzelfall durch den Rechteinhaber zugestimmt werden müßte.

    Eine Mail von Theo de Raadt vom 12. September 2007 belegt, daß zumindest eine nicht zu vernachlässigende Anzahl von BSD-Autoren gibt, die einer Umlizenzierung zur GPL ihre Zustimmung verweigern. Nach dem Erscheinen dieser Mail wurden alle GPL-Header aus Dateien im Linux Kern entfernt die ihren Ursprung in einem der *BSD-UNIX Varianten haben und bei denen der Bearbeiter für die Linux-Portierung nicht auch zugleich der Hauptautor des betreffenden Codes ist. Wie man daraus erkennen kann, wird die fehlende Brechtigung zur Umlizenzierung von BSD-Code inzwischen auch vom Linux-Kernel-Projekt anerkannt.

    Das Buch Die GPL kommentiert und erklärt stammt vom März 2005. Wir gehen daher davon aus, daß die Autoren dieses Buches den Behauptungen der FSF vertraut haben ohne eigene Rechtsrecherchen anzustellen.


    Das gesamte Buch Die GPL kommentiert und erklärt befindet sich auf dem O'Reilly Server.