Wunschzettel für GPL Version 3
Florian WeimerHeute hat die Free Software Foundation (FSF) mit dem öffentlichen Teil des Verfahrens begonnen, das in eine neue Fassung der GNU General Public License (GPL) münden soll. Dieser Artikel beschreibt eine Reihe von Anforderungen. Auch wenn einiges sicherlich Geschmackssache ist, soll diese Liste mir dabei helfen, bei den zweifelsohne folgenden turbulenten Diskussionen nicht zu sehr von dem, was noch sinnvoll ist, abzukommen.
Stetigkeit
Laut der Free Software Foundation
sind die folgenden vier Freiheiten wesentlich für freie Software:
das Ausführen der Software
das Studieren und Verändern
ihre Weitergabe
die Weitergabe der geänderten Fassung
Neben dem politischen Aspekt hat das für den Nutzer wichtige Vorteile: Eine komplexe Verwaltung der erworbenen Lizenzen entfällt völlig. Die beständige Rechtsunsicherheit durch äußerst verwickelte Verträge (Darf man mehrere Sicherheitskopien auf Band anfertigen? Wenn zwei Teilzeitkräfte sich einen Arbeitsplatz, braucht man dann zwei Lizenzen?) ist wesentlich entschärft, weil das unveränderte Kopieren und das Ausführen von vorneherein pauschal erlaubt ist. Zudem gibt freie Software dem Nutzer einen wesentlich größeren Handlungsspielraum, was eigene Änderungen entlang nicht vom ursprünglichen Hersteller vorgesehener Bahnen anbelangt. Diese Aspekte sollen aber an dieser Stelle nicht im Mittelpunkt stehen.
Ein Computerprogramm ist ab seiner Entstehung durch Urheberrechte geschützt. Der Programmierer muß daher ausdrücklich normalerweise durch das Urheberrecht nur ihm erlaubte Handlungen auch anderen gestatten. Üblicherweise geschieht dies durch eine Lizenz, mit der dem Nutzer diese Rechte eingeräumt werden. Üblich ist auch, gewisse Bedingungen an die Übertragung zu knüpfen (zum Beispiel Haftungsausschlüsse, unabhängig von ihrer Wirksamkeit). Eine solche Lizenz ist die GNU General Public License (GPL).
Bei der GPL handelt es sich um eine sogenannte Copyleft-Lizenz. Das bedeutet, daß die Lizenz versucht, das gewöhnliche Urheberrecht (“Copyright”) ins Gegenteil zu verkehren. Üblicherweise nutzen Autoren das Urheberrecht, um den Nutzern ihrer Werke Einschränkungen aufzuerlegen. Bei der GPL wird dagegen versucht zu verhindern, daß dem Nutzer Rechte genommen werden. Jeder, der ein Programm (oder ein anderes Werk) erhält, das der GPL unterliegt, soll über dieses Werk im Rahmen der vier Freiheiten verfügen dürfen. Das bedeutet, daß Programmierer weniger Freiheiten haben – sie können ihre Benutzer nicht unterjochen, sobald sie Programme Dritter in ihr Programm einbauen, die der GPL unterliegen.
Diese Aspekte der GPL sollten nicht aufgegeben werden, sondern fortbestehen. Mag sein, daß Copyleft nicht nach jedermanns Geschmack ist. Lizenzen ohne Copyleft-Komponente sind aber wesentlich weniger delikat, und es gibt bereits eine große Auswahl. Bewährte Copyleft-Lizenzen sind dagegen seltener.
Komplexität
Die GPL in der jetzigen Fassung zählt schon heute zu den umfangreicheren Lizenzen, auch wenn die Rechtsabteilungen einiger großer Unternehmen inzwischen noch komplexere Lizenzen erstellt haben. Komplexe Lizenzen haben den Nachteil, daß sie für Anwender und Programmierer (aber auch für Juristen) schwerer verständlich sind und daher nicht immer deutlich wird, welche Auswirkung einzelne Bestimmungen konkret haben.
Auf jeden sollte die Komplexität der neuen Fassung der GPL die der alten nicht wesentlich übersteigen. Wenn es sich herausstellt, daß sich bestimmte Ziele nur sehr aufwendig umsetzen lassen, ist im Zweifelsfall die einfachere Lizenz vorzuziehen.
Die eigenen vier Wände
Nach landläufiger Interpretation hat die aktuelle GPL-Version zur Folge, daß Nutzer mit unter der GPL veröffentlichten Programmen anstellen dürfen, was sie wollen, solange sie nichts verbreiten. Das entspricht einer Faustregel, die aus meiner Sicht zwingend für den effizienten Einsatz von Software ist: Was ich in meinen eigenen vier Wänden mit der Software anstelle, geht niemanden etwas an, weder den ursprünglichen Urheber, noch die allgemeine Öffentlichkeit.
Diese Faustregel ist wichtig, weil nur sie das spielerische Experimentieren mit Weiterentwicklungen gestattet. Wenn man sich – wie bei proprietärer Software nur allzu üblich – beim Verbinden von Programm X und Programm Y überlegen muß, was für Lizenzen man kaufen muß, wird das ganze schnell nervtötend.
Diese Anforderungen widersprechen auf den ersten Blick dem Copyleft-Gedanken der GPL, aber in diesen Fällen wird ausdrücklich nichts weiterverbreitet, so daß die entsprechenden Bestimmungen der GPL nicht greifen. Nach allem, was öffentlich bekannt ist, ist dieses Schlupfloch beabsichtigt, auch wenn die aktuelle GPL-Fassung in dieser Hinsicht etwas unklar ist.
Keine Schaffung neuer Urheberrechte
Es soll nicht versucht werden, mit der neuen GPL den Anwendungsbereich des Urheberrechts auszudehnen – oder Grundsätze wie “fair use” oder den Erschöpfungsgrundsatz bzw. die “first sale doctrine” auszuhöhlen. Das Ziel der GPL besteht ja gerade darin, Nutzern zu mehr Rechte zu verhelfen. Wenn dazu neue Urheberrechte mehr oder weniger geschaffen werden müssen, deutet das sehr stark darauf hin, daß Copyleft vielleicht doch nicht funktioniert.
Die Verlockung zur Ausdehnung der Urheberrechte ist deswegen besonders groß, weil in den letzten Jahren die Schnittstellen zwischen den Computerprogrammen wesentlich flexibler geworden sind. Wenn ein Programm ein anderes, das der GPL unterliegt, nur über eine solche wohldefinierte Schnittstelle nutzt, nicht aber den eigentlichen Programmtext einbindet, liegt bei wörtlicher Auslegung kein abgeleitetes Werk vor. Das erste Programm unterläge somit nicht der GPL-Pflicht, und Copyleft wäre ausgehebelt. Die FSF postuliert daher seit geraumer Zeit eine Art “interface copyright”, das ist aber ein sehr gefährlicher Weg. Letztlich wollen wir unbeschränkte Interoperabilität – alles andere greift zu sehr in die Nutzerfreiheiten ein.
Quellcode für alle Nutzer
Im Zusammenhang mit sogenannten “web services” tauchen immer wieder “application service providers” auf, die Nutzern Zugriff auf einen Dienst anbieten, ohne daß spezielle Software auf den Rechnern der Nutzer erforderlich wäre. Mit der gegenwärtigen GPL bedeutet dies, daß die Nutzer keinen Zugriff auf den Quellcode erlangen, selbst wenn der Anbieter GPL-Software einsetzt: Da sie das Programm nie erhalten, haben sie absolut keine Ansprüche. Das wird teilweise als wesentliche Schwäche der GPL angesehen.
Ein Beispiel für eine Erweiterung der GNU General Public License um eine Klausel, die dieser Entwicklung entgegenwirken soll, bietet die Afferro GPL:
2. […] c) If the Program as you received it is intended to interact with users through a computer network and if, in the version you received, any user interacting with the Program was given the opportunity to request transmission to that user of the Program's complete source code, you must not remove that facility from your modified version of the Program or work based on the Program, and must offer an equivalent opportunity for all users interacting with your Program through a computer network to request immediate transmission by HTTP of the complete source code of your modified version or other derivative work.
Auch wenn ich nur allzu gut die Intention hinter einer solchen Klausel verstehen kann, ist das sehr problematisch. Letztlich läuft es auf eine Art “client access license” hinaus, bei der ich genau protokollieren muß, wer auf welche Weise auf die von mir betriebenen Dienste zugreifen kann. Externen Nutzern muß ich dann Zugriff auf den Quellcode geben. Im Prinzip ist das alles kein Problem, aber man will nicht auf jedem Server auch noch zusätzlich einen Webserver installieren (schon aus Sicherheitsgründen). Wenn der Quellcode getrennt bereitgestellt wird, gibt es das Problem, Produktivcode und veröffentlichten Quellcode synchron zu halten. Alles in allem sind das keine unüberwindbaren Hürden, aber es fragt sich doch, ob diese Schritte wirklich nötig sind.
Patente
Patente bedeuten für Copyleft-Lizenzen wie die GPL ein grundsätzliches Problem: Der Benutzer eines Programms muß nicht nur die notwendigen Nutzungsrechte vom Urheber erhalten haben, er benötigt auch eine Erlaubnis, die einschlägigen Patente nutzen zu dürfen. Selbst wenn alle Urheber zustimmen, bedeutet dies, daß die Nutzung eines Programms, das unter der GPL veröffentlicht wurde, trotzdem nicht erlaubt sein kann. Sogar ein Miturheber könnte versuchen, über Patente die Copyleft-Verpflichtung auszuhebeln, und den Benutzern (und seinen Koautoren) die Rechte zu nehmen, die sie laut Lizenz eigentlich haben müßten.
Ob in Deutschland das Ausführen von Computerprogrammen eine Patentverletzung bedeuten kann, ist allerdings fraglich. Zwar wurden viele sogenannte Softwarepatente (manchmal auch „Patente auf computerimplementierbare Erfindungen“ genannt) von europäischen Patentämtern erteilt, es ist aber offen, bis zu welchem Grad die Ämter bei der Fortschreibung der Patentierungspraxis über geltendes Recht hinaus als Ersatz-Gesetzgeber fungieren können.
Ein wesentlicher Aspekt bei freier Software ist jedoch ihre Weitergabe. Sie ist in den Zeiten des Internets problemlos international möglich, ebenso wie die Zusammenarbeit zur Weiterentwicklung eines Programms. Damit spielt die Rechtslage in Europa keine entscheidende Rolle. Da die Vereinigten Staaten und Japan eine rechtlich besser abgesicherte Patentierungspraxis besitzen, die auch völlig technikfreie Patente abdeckt (nicht nur bloß den Grenzfall Programm), ist freie Software zumindest dort der Bedrohung durch Patente ausgesetzt – und mittelbar in der ganzen Welt.
Schon bei der Fertigstellung der jetzigen GPL-Version im Jahr 1991 war diese Entwicklung absehbar, weshalb eine entsprechende Klausel eingefügt wurde:
If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License.
Die beabsichtigte Wirkung soll sein, daß Firmen, die Programme verbreiten, die der GPL unterliegen, keine außergerichtliche Einigung verwenden können, die ihnen selbst zwar die Nutzung des Patents und damit die Weiterverbreitung erlaubt, nicht aber ihren Empfängern. Sie sind gezwungen, entweder die Verbreitung aufzugeben, oder die Wirkung des Patents auf die Software in irgend einer Weise erfolgreich zu untergraben, zum Beispiel durch das Erwerben einer Generallizenz, durch eine erfolgreiche Nichtigkeitsklage oder durch Weiterentwicklung der Software bis zu dem Punkt, an dem sie die strittigen Patente nicht mehr verletzt.
Andere Lizenzen, die zwischenzeitlich erstellt worden, versuchen einen Schritt weiterzugehen, indem sie das Urheberrecht gegen Patente ausspielen. Zum Beispiel enthält die Mozilla Public License folgenden Passus:
If You initiate litigation by asserting a patent infringement claim (excluding declatory judgment actions) against Initial Developer or a Contributor […] the rights granted […] to You under Sections 2.1 and/or 2.2 automatically terminate […]
Hier decken die genannten Abschnitte decken auch die Urheberrechte ab. Dies soll vor Patentklagen abschrecken, weil dem Kläger unterstellt wird, daß er an den Urheberrechten des Beklagten weiterhin Interesse hat.
Möglicherweise können solche Mechanismen in die neue GPL-Version übernommen werden, um eine bessere Verteidigung gegenüber Patenten zu erzielen. Das Terrain ist aber noch vergleichsweise unsicher, so daß nicht klar ist, welche Wirkung solche Klauseln am Ende haben werden.
Letztlich ist aber nichts, was man in eine Lizenz schreiben kann, eine Garantie für Immunität gegenüber Patenten. Das wesentliche Problem bei Patenten ist, daß auch völlig unbeteiligte Dritte die eingangs erwähnten Freiheiten untergraben können. In der Praxis ist das bei Softwarepatenten sogar der Regelfall. Da es davon inzwischen so viele gibt, die von der Industrie notgedrungen bei der Entwicklung nicht beachtet werden, verletzt jeder, der ein größeres Programm entwickelt, ausführt und weitergibt, zwangsläufig einige Patente. Wenn man nun seine eigenen gegen die Konkurrenz durchsetzte, sähe man sich sofort entsprechenden Gegenforderungen ausgesetzt. (Nicht ohne Grund wird dieser Zustand mit der “Mutually Assured Destruction” durch Atomwaffen während des Kalten Krieges verglichen.) Forderungen aufgrund von Softwarepatenten werden daher nur von Firmen erhoben, die selbst keine Produkte herstellen oder die aus anderen Gründen schon kurz vor dem Zusammenbruch stehen. Das bedeutet aber, daß sie an der Software, dem eigentlichen Zankapfel, kein wirkliches Interesse haben – und auch nicht über andere Produkte für Gegenklagen verwundbar sind.
Kompatibilität
Falls ein Autor ein Programm, das der GPL unterliegt, ändert, erwirbt er im Regelfall Urheberrechte an diesen Änderungen und kann den Umfang der Nutzungsrechte Dritter an diesen Änderungen selbst festlegen. Falls diese Rechte nur restriktiv vergeben werden, läßt sich auf diese Weise natürlich das Copyleft-Prinzip (die Bewahrung der vier Freiheiten) aushebeln. Deswegen gibt es in der aktuellen Version folgenden Passus:
You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
Obwohl sie zur Umsetzung des Copyleft-Prinzips notwendig ist, führt diese Klausel zu sehr ärgerliche praktischen Problemen. Programme unter der GPL lassen sich nicht mit Code erweitern, der Lizenzen unterliegt, die mit der GPL zwar eng verwandt, aber nicht identisch sind.
Lange Zeit war das Hauptproblem die sogenannte “advertising clause” der BSD-Lizenz:
All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of California, Berkeley and its contributors."
Formal ist das eine weitere Einschränkung gegenüber der GPL und daher nicht verträglich mit der GPL. Obwohl die Werbeklausel zurückgezogen wurde (Universität von Kalifornien, Berkeley, Juli 1999), lebt eine ähnliche Klausel in den Quellen der verbreiteten Kryptographiebibliothek OpenSSL weiter. Wenn eine GPL-Anwendung mit OpenSSL verknüpft werden soll, ist deswegen jedes Mal eine Ausnahmegenehmigung der Autoren der GPL-Anwendung erforderlich. Wenn man verstärkt kryptographische Verfahren einsetzen will (zum Beispiel um die Privatsphäre der Nutzer zu schützen), ist dies ein gewisses Hindernis.
Die Verträglichkeitsfrage tritt ebenso bei zahlreichen Lizenzen auf, die sich bemühen, die Wirkung von Patenten einzudämmen. Gerade in diesem empfindlichen Bereich wäre eine größere Kompatibilität äußerst wünschenswert – insbesondere mit der Apache License Version 2.0 (Apache Software Foundation, Januar 2004) – bei der dies besonders bedauerlich ist, weil die Verträglichkeit darüberhinaus gegeben ist.
Bezüglich der “advertising clause” wird sich aus historischen Gründen wahrscheinlich keine Regelung finden lassen. In anderen Fällen ließe sich ein Prozeß einrichten, mit dem bestimmte, dem Wortlaut nach unverträgliche Lizenzen, doch noch vereinen lassen.
Klarere Regeln für Änderungen
Die gegenwärtige GPL-Version verlangt bei Änderungen folgendes:
You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
Das Problem mit dieser Klausel: Es hält sich niemand an sie. Zwar werden die Umstände der Änderungen bei einigen Projekten in sogenannten ChangeLog-Dateien festgehalten (oder in Kommentaren in einer Versionsverwaltung), aber es ist völlig unklar, ob damit die Anforderungen an Änderungen erfüllt werden. Schließlich tragen die geänderten Dateien selbst nicht diese Hinweise. Und zu allem Überfluß sind solche detaillierten Änderungsverzeichnisse nicht einmal gängige Praxis.
Mit Hinblick auf einen gesicherten urheberrechtlichen Zustand des Programms wäre es auch wünschenswert, die einzelnen Autoren möglichst genau zu benennen. Die zitierte Klausel wird mitunter so interpretiert, daß dies nicht notwendig sei und völlig anonyme Änderungen möglich sind. Hier wäre eine Klarstellung wünschenswert, und zwar in der Lizenz selbst. Denn nur wenn der rechtliche Zustand klar ist und sich die relevanten Urheber bereits mit einer weitergehenden Nutzung ihrer Werke einverstanden erklärt haben, kann Programmcode aus verschiedenen Projekten gefahrlos kombiniert werden.
Torsten Jerzembeck machte mich darauf aufmerksam, daß die GPL nicht explizit fordert, daß bestehende urheberrechtliche Hinweise erhalten bleiben. Ich lege die Lizenz zwar so aus, daß sie nicht entfernt werden dürfen, aber ich kann die Kritik an der Gestaltung in der Lizenz nachvollziehen. Eine Klärung dieser Angelegenheit sollte zudem nicht schwierig sein.
Ein fairer Prozeß
Vor allen diesen technischen Details hoffe ich, daß der Weiterentwicklungsprozeß nicht in eine große Schlammschlacht ausartet – zwischen der Free Software Foundation, ihr prinzipiell nahestehenden Organisationen wie Debian und Elementen, die im Copyleft-Prinzip den Untergang der abendländischen Kultur sehen. Es wird immer ein Grüppchen geben, daß sich mit der neuen GPL-Version partout nicht arrangieren kann, aber der allgemeine Frieden sollte doch gewahrt werden.
Revisions
2006-01-16 18:30: veröffentlicht