GULP - Knowledge Base: General Public License (GePL): Die neuen Regelungen in der Version 3 und Probleme beim Wechsel

Die neuen Regelungen in Version 3 der GPL

(Juni 2008)

Autor: Rechtsanwalt Dr. Frank A. Koch

Die General Public License (GPL) ist zweifellos eine der erfolgreichsten Formen der Lizenzierung quellcodeoffener Software. Ebenso sicher ist sie aber keine einfache Lizenzform, sondern in ihrer Verwendung in der Praxis im Gegenteil mit einigen nicht immer offensichtlichen Haftungsrisiken verbunden, die rasch ganze Entwicklungsprojekte gefährden oder gar scheitern lassen können. Einige dieser Risiken insbesondere aus der Inkompatibilität von Version 2 und Version 3 der GPL werden nachfolgend knapp zusammengestellt.

Wahlzwang

a) GPL

Entwickler können Software nicht mehr einfach "unter der GPL" anbieten. Früher wurde hierunter schlicht die Version 2 der GPL von 1991 verstanden (GPLv2). Seit dem 29.6.2007 ist nun Version 3 der GPL (GPLv3) verfügbar (www.gnu.org/licenses/gpl-3.0.txt

). Der erste Fallstrick für die Praxis ist, dass Version 3 nicht einfach Version 2 ablöst. Vielmehr existieren beide Versionen nebeneinander. Da sie teilweise gravierende Unterschiede aufweisen (insbesondere bei der freie Festlegung einer Lizenzvergütung), muss sich jeder freie Entwickler (bzw. jedes Software-Haus) entscheiden, unter welcher Version der GPL das Entwicklungsprodukt vertrieben werden soll. Wie bemerkt wurde, ist ein "Rosinenpicken" nicht zulässig. Ebenso dürfen Bearbeitungen von unter Version 2 erstellten Sourcen dürfen nur unter Version 2 verbreitet gemacht werden, nicht unter Version 3.

Schließlich darf unter Version 2 erstellter Source Code und maschinenlesbare Code weiterhin nicht öffentlich (zum Download) zugänglich gemacht werden, sondern nur unter Version 3 erstellter Code. Freilich ist das Eröffnen von Download-Möglichkeiten schon lange Praxis, gerade auch für Software unter Version 2. Dies ist dann unschädlich, wenn die jeweiligen Urheber selbst ihre Software zugänglich machen.

Nr. 6 Absatz 1 e GPLv3 erklärt ergänzend die Code-Übertragung in Peer-to-Peer-Netzen für zulässig. Urheberrechtlich wird hier freilich meist ohnehin Öffentlichkeit gegeben sein und demzufolge ein öffentliches Zugänglichmachen erfolgen.

b) LGPL

Auch für die Lesser General Public License (LGPL), für die ebenfalls seit dem 29.6.2007 eine Version 3 verfügbar ist (www.gnu.org/licenses/lgpl-3.0.txt

) .Die LGPL ist insbesondere auf Quell- und Maschinencodes von Software-Funktionsbibliotheken anwendbar (sog. "Libraries").

c) Anwendbares Lizenzrecht

Ohne die Festlegung auf eine der beiden Versionen von GPL oder LGPL kommt zwar auch ein Software-Entwicklungs- und/oder Überlassungsvertrag mit Kunden/Auftraggebern zustande, jedoch kann dann nur auf den (letztlich von einem Gericht zu beurteilenden) Vertragszweck zurückgegriffen werden, um festzustellen, welche Nutzungsrechte einzuräumen sind und welche Nutzungsbeschränkungen gelten. Dies erhöht die Rechtsunsicherheit in der Praxis deutlich und sollte durch klare Vereinbarungen vermieden werden.

d) AGPL

Völlig neu ist die Regelung für den Vertrieb von Applikationen, die durch Web Services oder Computernetze mit Nutzern interagieren, in der sog. "Affero General Public License" (AGPL, www.affero.org/oagf.html

).

e) FDL

Unverändert ist die GNU Free Documentation License geblieben (Stand Version 1.2 vom November 2002, www.gnu.org/licenses/fdl.txt

)

GPL Version 3 erlaubt freie Lizenzvergütungen

Unter Version 3 der GPL können Lizenzvergütungen für die Software-Nutzung vom Anbieter frei festgelegt werden (Nr. 4 Absatz 2 GPLv3). Unter Version 2 (Nr. 1 Absatz 2) bleibt dies ausgeschlossen und können grundsätzlich nur Kosten für eine Kopieerstellung berechnet werden, nicht aber Nutzungsvergütungen.

Mit Version 3 werden auch Software-Miete und – Leasing zulässig, ebenso das Application Service Providing.

Außerdem dürfen Support und Gewährleistung gegen Vergütung angeboten werden. Im deutschen Recht muss freilich vom Entwickler/Software-Haus bei Software-Kauf oder –Erstellung bzw- -Miete zwingend ohnehin Gewähr geleistet werden. Das entsprechende Leistungsrisiko wird deshalb üblicherweise in die Vergütung "eingepreist". Die Lizenzregelung darf also nicht dahin missverstanden werden, dass Gewähr nur bei besonderer Vereinbarung zu leisten wäre.

Entwicklerhaftung für "viral infizierte" Software

Keinesfalls darf Software, die bisher unter GPLv2 entwickelt und vertrieben wurde, quasi "umdeklariert" und nun unter GPLv3 vertrieben werden. Der Erwerber einer GPLv3-Software will diese i.d.R. gegen Vergütung auf Datenträger verbreiten oder online zugänglich machen können. Für unter der GPLv2 entwickelte Software dürfen aber keine Lizenzgebühren berechnet, sondern nur angefallene Kopierkosten erstattet verlangt werden. Der Erwerber einer GPLv2-Software darf diese also nicht kommerziell verwerten. Dies ist solange das Risiko des Erwerbers, wie für diesen erkennbar ist, dass die vertragliche Software unter Version gebunden ist, hingegen nicht mehr, wenn sie als Version 3 umdeklariert wird, denn hier haftet der umdeklarierende Anbieter voll.

Entscheidend ist hier nicht, welche Lizenz der Software im Zeitpunkt des Vertragsschlusses unterlegt wird, sondern unter welcher Version der Programmcode tatsächlich entwickelt wurde. Version 2-Code bleibt damit auch dann an die Beschränkungen der Version 2 (etwa das Verbot freier Lizenvergütung) gebunden, wenn er (und sei es nur in Teilen) in Code eingefügt wird, der unter Version 3 entwickelt wurde. Dies kann sogar dazu führen, dass das gesamte Software-Package aus Version 2- und Version 3-Teilen voll nur unter Version 2 (!) vertrieben werden darf (sog. "virale Infektion" der Gesamtsoftware durch Version 2; s. GPLv2 Nr. 2 Absatz 1 b und Absatz 2 Satz 2). Nichts anderes gilt selbst dann, wenn das Entwicklungsprodukt überhaupt nicht unter einer Open Source-Lizenz, sondern als proprietäres vertrieben werden soll.

Eine viral infizierte Software weist einen Rechtsmangel auf. Der Erwerber kann Beseitigung dieses Rechtsmangel verlangen. Ist diese, wie meist, nicht möglich, kann der Erwerber vom Vertrag zurücktreten und, wenn der Entwickler den Rechtsmangel zu vertreten hat, Schadensersatz verlangen. Diese Haftung kann der Entwickler in AGB nicht ausschließen, da sie eine vertragswesentliche Pflicht zur Einräumung derjenigen Nutzungsrechte betrifft, die der Erwerber für die vertragsgemäße Benutzung der Software benötigt. Deklariert der Entwickler sein Entwicklungsprodukt außerdem ausdrücklich als "GPLv3"-Software oder "GPLv3-kompatibel", kann hierin bei Software-Kauf die Übernahme einer Beschaffenheitsgarantie zu sehen sein und muss der Entwickler dann sogar unabhängig von einem Verschulden für die Einhaltung dieser Garantie einstehen. Enthält die Software dann auch nur einzelne unter Version 2 entwickelte Routinen, ausführbare Code-Teile oder sonstige Programmelemente und "infizieren" diese die gesamte Software, haftet der Entwickler auch dann voll auf Ersatz, wenn er hiervon keine Kenntnis hatte. Diese Haftung kann ihn besonders hart treffen, umfasst sie doch auch den vom Auftraggeber berechtigterweise erwartbaren, aber wegen der "viralen Infektion" nicht realisierbaren Gewinn.

Hinweis:
Jeder Entwickler tut gut daran, genau zu prüfen, welche Programmteile von ihm wann und unter welcher Lizenz entwickelt wurden und ob auch alle nur hinzuerworbenen Bibliotheksfunktionen unter Version 3 (der LGPL) lizenziert sind. Alle unter Version 2 erstellten Codeteile können dazu führen, dass das gesamte Erstellungsprodukt unter Version 2 gezogen wird und nicht kommerziell verwertet werden darf ("Copyleft"-Bindung, Nr. 2 b GPLv2). Eine Ausnahme greift nur ein, wenn bestimmte Programmteile eigenständige (bzw. eigenständig ladbare) Werke sind. Dies lässt sich nur im jeweiligen Einzelfall prüfen (etwa bezüglich Treiberprogrammen).

Durch geeignete Vertragsgestaltung kann der Entwickler freilich die strenge Copyleft-Bindung der GPL an verwendeten, bei Vertragsabschluss vorhandenen Programmteilen entschärfen, wenn er die Entwicklung nach Weisungen des Auftraggebers durchführt (also nach Dienstvertragsrecht) und der Auftraggeber das Entwicklungsprodukt nur zu eigenen Zwecken (etwa im eigenen Unternehmen) einsetzt, nicht jedoch verbreitet oder veröffentlicht. Hier überträgt der Entwickler nicht Rechte an Entwicklungsprodukten (und ist die GPL schon deshalb nicht anwendbar). Diese Rechte entstehen vielmehr durch die Weisungsbezogenheit direkt beim Auftraggeber. Die Bindung der GPL-Anteile am erstellten Programm wird andererseits nicht verletzt, wenn der Auftraggeber das Programm nur für Eigenzwecke nutzt.

Die entsprechenden Vertragsregelungen müssen freilich genau auf das jeweilige Entwicklungsprojekt zugeschnitten sein. Der Entwickler sollte sich hier außerdem im Entwicklervertrag vorsorglich für den Fall, dass der Auftraggeber später doch zu einem Vertrieb übergeht, vom Auftraggeber von Ersatzansprüchen Dritter haftungsmäßig freistellen lassen. Zugleich sollte der Entwickler Ersatzansprüche des Auftraggebers für den Fall ausschließen, dass dieser durch den nachträglichen Wechsel zum Vertrieb bestehende Nutzungsrechte aus der GPL verliert (Nr. 4 Satz 2 GPLv2; Nr. 8 Absatz 1 Satz 2 GPLv3).

Ausweg "Dual Licensing"

Entwickler können grundsätzlich frei wählen, ob sie eine Entwicklung Version 2 oder Version 3 der (L)GPL (oder einer anderen Open Source-Lizenz) unterstellen (oder auch proprietär anbieten). Bei vergüteten Auftragsentwicklungen ist aber grundsätzlich anzunehmen, dass der Auftraggeber die Entwicklungsprodukte frei verwerten, also insbesondere gegen Vergütung (weiter)vertreiben will. Damit kann der beauftragte Entwickler nur Version 3 wählen, da er unter Version 2 die geschuldeten Nutzungsrechte nicht (bzw. nicht als ausschließliche) einräumen kann.

Der Entwickler muss freilich sorgfältig darauf achten, dass in den unter Version 3 erstellten Code keine Version 2-Codeteile übernommen werden, die den gesamten Code unter Version 2 ziehen würden. Selbst eigentlich als proprietär entwickelter Code wird insgesamt zum quelloffenen Code, wenn er GPL-"Einsprengsel" enthält.

Kein Schutz für Digital-Rights-Management

Unter Version 3 verzichtet jeder Anbieter auf sein Recht, eine mögliche Umgehung bestehender technischer Schutzmaßnahmen zu verbieten (Nr. 3 Absatz 2 GPLv3). Die Implementierung solcher Schutzmaßnahmen als solche ist aber nicht unzulässig. Jedoch ist grundsätzlich in der Programmbeschreibung auf solche Schutzmaßnahmen und ihre Funktion hinzuweisen. Keinesfalls dürfen sie bewirken, dass die freie Nutzung (Kopieren, Installieren auf mehreren Rechnern, etc.) beeinträchtigt wird.

Freie Patentnutzung

Die Inhaber von Patentrechten an neuen Software-Versionen, die Patentschutz genießen, müssen allen Nutzern ein nichtausschließliches, weltweites und kostenfreies Recht zur Patentnutzung einräumen (Nr. 11 Absatz 3 GPLv3), also für Handlungen wie das Ändern, Verbreiten oder öffentliche Zugfänglichmachen des Codes.

Hat die kommerzielle GPL-Version eine Zukunft?

Der besondere Vorteil der Open Source-Lizenzen unter Version 2 liegt für die Mehrzahl der Praktiker darin, unterschiedliche Codes studieren und erarbeitete Änderungen und Weiterentwicklungen gemeinsam zu teilen. So gab und gibt es für Open Source-Programme zwar keine Gewährleistung, aber im Internet kann eine Behebung festgestellter Fehler durch eine Vielzahl konnektierter Entwickler oft wesentlich schneller erfolgen als durch einen kommerziellen Anbieter, der ab und zu Updates herausgíbt. Abzuwarten bleibt, ob diese Erfahrung auf den kommerziellen Software-Vertrieb unter GPL Version 3 übertragbar ist. Wenn der Programmcode nicht mehr vergütungsfrei (zumindest online) verfügbar ist, hat auch eine breite Entwickler-Community keine Möglichkeit mehr, den Programmcode ohne unverhältnismäßigen Aufwand zu inspizieren und gegebenenfalls Modifikationen (etwa Bugfixes) vorzuschlagen. Die Produktentwicklung unter Version 3 nähert sich damit dem traditionellen, proprietären Modell an. Die Fehlerbeseitigung kann sich hier tendenziell deutlich verlangsamen. Der Erwerber wird also kalkulieren müssen, ob er aus dem Kauf von Open Source-Software unter Version 3 erzielbare Kostenvorteile dadurch verlieren könnte, dass er etwa zusätzlich Wartungsleistungen für die vorgesehene Nutzungsdauer kontraktieren muss, um die Nutzbarkeit zu sichern. Die Anbieter sollten also zeigen können, dass die Entscheidung für ihre Open Source-Software kalkulatorisch dennoch günstiger ist als eine Entscheidung für "herkömmliche" proprietäre Software.

Der Autor Dr. Koch ist Rechtsanwalt in München, auf IT-Recht spezialisiert und Verfasser der Publikationen "Computer-Vertragsrecht" (Haufe-Verlag), "Handbuch Software- und Datenbank-Recht" (wiss. Springer-Verlag") und "Internet-Recht" (Oldenbourg-Verlag). Zum Thema Open Source und GPLv3 ausführlich s. Koch, IT-Rechtsberater Hefte 11/2007, S. 261 und 12/2007, S. 285 und Koch, Rechtsrisiko Open Source Software ? Informatik-Spektrum 2004, 55.

Website des Verfassers: www.anwaltskanzlei-koch.de

Kommentare zu diesem Artikel:

""Schließlich darf unter Version 2 erstellter Source Code und maschinenlesbare Code weiterhin nicht öffentlich (zum Download) zugänglich gemacht werden, sondern nur unter Version 3 erstellter Code." Wie bitte? Er MUSS zugaenglich sein, das ist und war immer gerade der Witz bei der Sache... (Juni 2008)"

"Das Thema ist hochinteressant, der Artikel jedoch leider eher schwer verstaendlich geschrieben. Man hat den Eindruck, dass er dazu dienen soll, von der GPLv3 abzuraten. (Juni 2008)"

"OpenSource heißt auch jetzt noch so, und Freeware hat noch nie "kostenlos" bedeuted. Ich biete _meine_ Lösungen grundsätzlich als OpenSource unter der GPL3 an. die Vergütung kann der Kunde frei festlegen (von Null bis ....). Download ist kostenlos. Haftungmängel und Gewährleistung werden in den AGB's geregelt. (Juni 2008)"

Probleme beim Wechsel zur neuen Version 3 der General Public License

Die neuen Regelungen in Version 3 der GPL

Kommentare zu diesem Artikel: