Abbildung 1: Spagat: Die Eclipse Public License macht beim Copyleft teils strenge, teils milde Vorgaben.

Open-Source- und Freie-Software-Lizenzen gibt es zuhauf. Die teils komplizierten Regelwerke passen aber nicht von Haus aus beliebig zusammen. Einige stoßen sich offensichtlich ab, bei anderen komplizieren neue Versionen die Situation. Die GPL ist mit der neuen Version 3 ein solcher Fall.

Die wunderbare Vielfalt – einerseits bereichert sie das Leben, andererseits macht sie Entscheidungen schwer. So auch bei der Wahl von Softwarelizenzen und hier insbesondere bei den freien Lizenzen. Der scheinbar undurchdringliche Wildwuchs beim üppigen Angebot an Lizenzen für Nutzung und Verbreitung von Programmen beschränkt sich bei genauem Hinsehen aber auf eine Handvoll Varianten.

Seit die Juristen das Internet entdeckt haben und dem Begriff Landverteilung eine neue Dimension geben, wechseln sich die Schlagworte monatlich ab. Zurzeit ist die Lizenzkompatibilität in aller Juristen Munde. Das lange Wort steht für die Möglichkeit, Code, den man unter bestimmten Bedingungen erhalten hat, zusammen mit eventuellen Bearbeitungen unter anderen Bedingungen zu nutzen oder weiterzugeben.

Lizenzvielfalt

Ob und inwieweit Bearbeitungen unter derselben Lizenz stehen müssen wie der Ursprungscode, ist eine Frage des so genannten Copyleft, also der Bestimmungen, die diese Frage innerhalb der Lizenzbedingungen regeln. Hier ist noch nach strengem und beschränktem Copyleft zu unterscheiden. Beispiele für strenges Copyleft (Abbildung 1) sind die GPL [1] oder die Eclipse Public License (EPL) [2]. Beispiele für beschränktes Copyleft (Abbildung 2) sind die MPL, also die Mozilla Public License [3], oder die LGPL, die Lesser General Public License [4]. Außerdem gibt es noch Lizenzen ganz ohne Copyleft, also ohne Verpflichtung, bearbeiteten oder erweiterten Code unter der Ausgangslizenz zu veröffentlichen. Vertreter dieser Art sind die BSD-artigen Lizenzen [5].

Einen Spagat zwischen Strenge und Milde versucht die bereits erwähnte Eclipse Public License, die aus IBMs Common Public License [6] hervorgegangen ist. Beide sehen kein Copyleft für den Fall vor, dass unabhängige Softwaremodule oder zusätzlicher, nicht abgeleiteter Code einfließt. Das erlaubt fast uneingeschränkte Erweiterung und Bearbeitung der Codebasis durch eigenen Code beziehungsweise das Einpflegen von Code, der selbst nur schwachem oder keinem Copyleft unterliegt.

Abbildung 1: Spagat: Die Eclipse Public License macht beim Copyleft teils strenge, teils milde Vorgaben.

Abbildung 2: Die Mozilla Public License gilt als Beispiel für ein beschränktes Copyleft.

Knackpunkt: Copyleft

Das Copyleft macht also den “viralen Charakter” der GPL aus und ist der Knackpunkt der Lizenzkompatibilität: Sehen zwei Softwarelizenzen vor, dass Bearbeitungen wiederum unter der jeweiligen Ausgangslizenz zu veröffentlichen sind, besteht Inkompatibilität. Es können also nur Bestandteile mit beschränktem oder ohne Copyleft in Code einfließen, der unter strengem Copyleft liegt, und nicht umgekehrt.

So erlaubt es die MPL, eingebaute Bestandteile mit proprietärem Code zusammen als “Larger Work” zu veröffentlichen, die LGPL gestattet, die GNU-C-Library in anderweitig lizenzierten (selbstständigen) Programmen zu nutzen. Die Copyleft-Unverträglichkeit tritt in der Regel aber nur bei erfolgter Bearbeitung und Veröffentlichung auf; für die bloße Nutzung stellen die Lizenzen üblicherweise keine besonderen Regeln auf.

Eine andere Frage der Lizenzkompatibilität ist die Veröffentlichungspflicht der Quellen, wie sie die GPL zwingend vorsieht. Diese Verpflichtung war es übrigens, die eine Kombination mit der Apache License [7], die keinem Copyleft unterliegt und eine Quellenveröffentlichung nicht verpflichtend vorsieht, verhindert hat. Nach einigem Hin und Her gilt die Apache License nun als kompatibel zur GPLv3 [8] – allerdings nur einseitig. Das bedeutet, dass AL-Code in GPL-Code einfließen kann, jedoch nicht umgekehrt. Das Ergebnis muss also ein GPL-Programm sein – der virale Effekt schlägt wieder zu.

Vertragsmuster GPL

Die GPL ist kein Gesetz, sondern ein Vertragsmuster, das – auch nach der Intention der FSF – Parteien als Vertragstext benutzen dürfen. Die GPL gilt also nicht wie ein Gesetz kraft Erlass, sondern nur, wenn vereinbart. Nur im Einzelfall, etwa wenn die Ursprungslizenz, unter der ein Nutzer oder Programmierer die Software erhalten hat, es vorschreibt, muss er diese Lizenz wiederum für eine Rechteübertragung verwenden. Auch der Erwerber der Nutzungsrechte erhält diese unter den Bedingungen der GPL.

Das Prinzip war über lange Jahre hinweg klar, jetzt kommt eine neue Version der GPL ins Spiel. Welche gilt? Zunächst jene, die drinsteht. Maßgeblich ist an erster Stelle die Angabe im Quellcode eines einzelnen Programms beziehungsweise die Angabe in einer einzelnen Quellcode-Datei. Steht in der License.txt oder im Code die GPLv3, darf der Code nur unter deren Bedingungen weitergeben werden, steht dort die alte Version, empfiehlt es sich, diese zu nutzen.

Neuling GPLv3

Nach Auffassung der FSF soll das Ersetzen der GPLv2 [9] durch die Bedingungen der GPLv3 [8] möglich und erlaubt sein. Ob diese Einschätzung mit der Rechtslage übereinstimmt, ist zweifelhaft, handelt es sich doch bei den geänderten Vertragsbedingungen um eine neue Lizenz. Für die gilt, was für alle anderen Bedingungen gilt: Programme oder Quellen dürfen nur dann unter eigenen Bedingungen weitergegeben werden, wenn die Ursprungslizenz oder der Urheberrechtsinhaber dies erlaubt.

Ist die Ursprungslizenz die GPLv2, gibt es drei Ansatzpunkte für die Lizenzportierung: Der erste ist die Versionsklausel in der Lizenz selbst. Nach Ziffer 9 der GPLv2 soll – wenn der Lizenztext die Versionsangabe “or any later version” oder gar keine enthält – diese Version durch jede Folgeversion ersetzbar sein. Dabei behält die FSF, die sich als Hüterin der GPL sieht, die Kompetenz für den Erlass der Folgeversionen vor. Zwar sehen viele Juristen diesen Any-later-version-Vorbehalt aus dem Recht der Allgemeinen Geschäftsbedingungen heraus als unbedenklich an, dennoch steht einer Rechtsbindung ein wesentlicher Grundsatz des deutschen Rechts entgegen: Willenserklärungen sind nur dann wirksam, wenn sie hinreichend konkret bestimmbar sind.

Konkrete Zukunftsplanung

Ein Programmierer, der sein Programm unter der GPLv2 veröffentlicht, kann aber zum Zeitpunkt dieser Erklärung gar nicht abschätzen, was die FSF in künftige Versionen der GPL hineinschreibt. Das bloße Versprechen, es werde schon der Intention der GPL entsprechen, reicht dabei nicht aus. Der konkrete Umfang der Rechte, die der Programmautor dem Erwerber zum Zeitpunkt der Übertragung einräumt, ist auch nur zu diesem konkreten Zeitpunkt durch die Parteien bestimmbar.

Das entspricht auch dem Grundsatz, dass Verträge zwischen Parteien nur durch übereinstimmende (Willens-)Erklärungen dieser Parteien aufhebbar oder änderbar sind. Eine nachträgliche Inhaltsänderung nur durch den Willen Dritter ist nach deutschem Recht nicht vorgesehen.

Selbst dynamische Leistungspflichten wie Zahlungen zu einem nach Vertragsschluss geltenden Markt- oder Börsenwert oder ein an den Lebenshaltungsindex gekoppelter Mietpreis sind nur rechtswirksam, wenn sie zum Zeitpunkt des Vertragsschlusses hinreichend konkret bestimmbar sind. Der Passus “Jede spätere Version der GPL” ist nicht hinreichend konkret bestimmbar. Die FSF kann dem Urheber eines Programms nicht nachträglich vorschreiben, zu welchen Bedingungen er einer Nutzung oder Weitergabe seines Code zustimmt.

Vertragsinhalt

Der zweite Ansatzpunkt für den Lizenzaustausch ist der Inhalt des Lizenzvertrags. Wenn die neue Version nicht mehr Rechte einräumt als die alte und auch nicht mehr verbietet, dann wäre eine Weitergabe der Rechte möglich. Entscheidend für die rechtliche Beurteilung eines Vertrags ist sein Inhalt, nicht die Bezeichnung. Weil die FSF die Urheberrechte, zumindest aber die Verwertungsrechte am GPL-Text ausübt, kann sie sogar entscheiden, dass der neue Versionstext den alten ersetzen darf.

Entscheidend ist jedenfalls der Umfang der eingeräumten Rechte und der enthaltenen Verbote. Ist dieser Umfang nicht derselbe, wirkt der – im positiven Sinne – virale Effekt der GPLv2 gegenüber der GPLv3 ebenso wie gegenüber jeder anderen Lizenz: die oder keine! Dabei kommt es, zumindest nach deutschem Recht, nicht darauf an, ob die Lizenzbedingungen ein Verbot oder eine Rechtseinräumung unterscheidet. Ob ein GPL-Verwender ein Verbot der Durchsetzung von Patentansprüchen unterschreibt oder nach den Vertragsbedingungen eine uneingeschränkte, unwiderrufliche Vorab-Genehmigung zur Patentnutzung erklärt, macht keinen Unterschied.

Nummer sicher: GPLv2

Für den Entwickler ist dabei von entscheidender Bedeutung, welcher Lizenz der Code unterliegt, auf dem er aufsetzt. Ist es die GPLv2, steht er auf der sicheren Seite, denn sie ist gesellschaftlich und rechtlich [10] seit Langem anerkannt, andererseits kann GPLv2-Code später jederzeit unter die GPLv3-Lizenz gestellt werden – wenn deren Rechtsgültigkeit bestätigt ist. Also nimmt der vorsichtige Entwickler GPLv2-Code und veröffentlicht eigene Entwicklungen ebenfalls unter der GPLv2 mit dem Zusatz “or any later version”.

Ist es die GPLv3, kann der Entwickler nur diese weiterlizenzieren. Dann kommt alles auf eine künftige gerichtliche Bestätigung dieser Textpassage an. Erklären die Gerichte sie für rechtswirksam, ist alles gut und die Nutzungsrechte sind einschließlich des Weiterveröffentlichungs- und Bearbeitungsrechts in der Folgekette übertragen. Halten die Gerichte die GPLv3-Umlizenzierung für unwirksam, fehlt eine Rechtsgrundlage für Bearbeitung und Weitergabe. Alle abgeleiteten Entwicklungen wären dann keine freie Software und müssten erst wieder mühsam nachträglich und durch übereinstimmende Erklärungen aller beteiligten Entwickler als freie Software nachlizenziert werden.

Dual Licensing

Dual Licensing ist ein Begriff für etwas, das nicht existiert. Tatsächlich geht es in jedem Fall um zwei unterschiedliche Nutzungsverträge, die sich gegenseitig ausschließen. Ein Urheber oder Rechteinhaber gibt ein Programm weiter; dem einen zu diesen Bedingungen, dem anderen zu völlig unterschiedlichen.

Dieser Wortlaut erweckt den Eindruck, der Erwerber des Programms könne sich frei entscheiden, zu welchen (Lizenz-)Bedingungen er das Programm weitergibt. Das ist falsch. Nur der Urheber selbst darf entscheiden, unter welchen Bedingungen die Übertragung erfolgt. Allenfalls darf der unveränderte Quellcode weitergegeben werden. Der Empfänger kann sich dann entscheiden, welche Form des Lizenzvertrags für ihn die richtige ist.

Beim Dual Licensing besteht immer die Gefahr eines Forks, also einer Parallelentwicklung, bei der Code nicht mehr zwischen einem freien und einem nicht-freien Zweig der Entwicklung portierbar ist. Folgt man der Annahme, dass freie Software-Entwicklung zu besserem Code führt, ist der unfreie Zweig eines Dual-Licensing-Modells zum Scheitern verurteilt – wann es dazu kommt, ist nur eine Frage der Zeit.

Abbildung 3: Entschiedend für die weitere Lizenzierung ist die Quelle, auf der eine Software aufsetzt.

Fazit

Wer sichergehen will, nutzt GPLv2-Code und setzt auch für eigene Entwicklungen (noch) keine spätere Lizenzversion ein. Die GPLv2 ist das Maß der Dinge und gewinnt dank des positiven viralen Effekts. Bis zu einer Bekräftigung durch die Gerichte besteht sogar Grund für die Annahme, dass die GPLv2 die GPLv3 infiziert. Wer freie Software entwickelt, sollte dem strengen Copyleft und seiner Wirkung vertrauen, die letztlich zu besserem und sichererem Code führt, selbst wenn die Rechte an Eigenentwicklungen aus der Hand zu geben sind. (uba)