Die Free Software Foundation hat den Entwurf für die kommende GPL-Version 3 auf ihre Website und zur Diskussion gestellt. Einige Änderungen zur alten Version scheinen kosmetisch, andere überraschen.

Nach etlichen Monaten der Besinnung haben Richard Stallman und seine FSF-Kollegen den Schritt an die Öffentlichkeit gewagt. Auf der FSF-Homepage gibt es den Entwurf der neuen, der nächsten GPL [1] zur Ansicht (Abbildung 1). Die Version 3 (GPLv3) soll nach 15 Jahren die Vorgängerin ablösen. Zu viel hat sich in der Zwischenzeit getan, rechtlich wie technisch, um eine Anpassung noch weiter zu verzögern. Dabei hat sich die alte Version durchaus bewährt: Meist gute Erfahrungen vor Gericht und breite Zustimmung der Entwickler – sie ist die meistbenutzte Softwarelizenz für freie Programme. Die Vorgabe für die neue lautete demnach: behutsam ändern!

Abbildung 1: Seit Mitte Januar 2006 steht der Entwurf für die neue GPL-Version auf der FSF-Website bereit.

Patente und DRM

Die Veränderungen betreffen im Wesentlichen drei Punkte: Softwarepatente, Digital Rights Management (DRM) und Lizenzkompatibilität. Hinzu kommt noch ein erweiterter Abschnitt, der Begriffe erläutert. Die Veränderungen in der Präambel sind rein redaktionell, mit Ausnahme eines neuen Absatzes über das Verhältnis der GPL zum Digital Rights Management. In ihm stellt die FSF klar, dass die GPL-Grundsätze und DRM unvereinbar sind und die Lizenz daher sicherzustellen hat, dass GPL-Software weder mittelbar noch unmittelbar Gegenstand von DRM sein kann.

Die Lizenz spricht dabei statt von Digital Rights Management konsequent von Digital Restrictions Management und erwähnt die Gesetzgebung einiger Länder, die Software verbietet, die es gestattet, DRM zu umgehen – wörtlich: ihm zu entkommen (escape). Diese Formulierung lässt offen, was im Einzelfall gemeint ist: Der Spielraum reicht von jeder Verhinderung, dass sich DRM-Systeme auf dem eigenen Rechner breit machen, bis zum gezielten Bruch geschützter Urheberrechte.

Die Präambel unterstreicht die Ansicht, dass ein “Grundrecht auf Informationsfreiheit” dem User auch das Recht einräumt, Dritte von jedem Einfluss auf eigene Hard- und Software auszuschließen. Dahinter steht offenbar die resignative Einsicht, DRM nicht mehr verhindern zu können. Also scheint sich die GPL nicht mehr gegen Digital Rights Management an sich zu wehren, sondern nur mehr gegen ein DRM, das man nicht umgehen darf.

Solche Verbote und begleitende Strafnormen sind jedoch ein notwendiger Teil jedes effektiven DRM-Ansatzes, also des Versuchs, die Verfügungsgewalt des Benutzers über sein System einzuschränken. Vor diesem Hintergrund ist fraglich, ob der GPL-Abschnitt mehr als ein politisches Statement sein kann.

Per definitionem

Die Abschnitte 0 und 1 des Entwurfs definieren zentrale Begriffe: Die Formulierung “licensed program” ist hiernach extensiv auszulegen, um auch zusammenhängenden Code zu erfassen, der nicht als selbstständiges Programm anzusehen ist, etwa externe Konfigurationsdateien und -skripte. Eigentlich muss man den Begriff auch auf die den Programmen zugrunde liegenden Ideen ausdehnen – das wäre konsequent, um dem erklärten Feind freier Software, den Softwarepatenten, zu begegnen.

Dass der Entwurf nunmehr statt des Begriffs “to distribute” den Terminus “to propagate” benutzt (die beide im Deutschen “verbreiten” bedeuten), erklärt die FSF damit, dass einige Rechtsordnungen den alten Begriff als feststehenden Rechtsterminus verwenden und der neue Missverständnisse ausschließen soll. Gleichzeitig besagt der Entwurf, dass unter diesem Begriff jede Form urheberrechtlicher Verwertung zu verstehen sei, die sich nicht auf die bloße Nutzung oder Bearbeitung für den persönlichen Gebrauch beschränkt.

Korrespondierend zur extensiven Auslegung des Begriffs “program” führt der Entwurf den Begriff “complete corresponding source code” (etwa: vollständige Codebasis) ein. Darunter sollen alle Bestandteile fallen, die der Benutzer benötigt, um ein bestimmtes Programm zum Laufen zu bringen, mit Ausnahme der Programmier- oder Übersetzungssoftware (Compiler, Parser et cetera). Dem steht die Abgrenzung gegenüber, als Objektcode gelte alles, was nicht Quellcode sei. Bytecode ist damit Objektcode.

Missverständnis

Die Verpflichtung, mit der vollständigen Codebasis alles weiterzugeben, was der Benutzer für die Programmerstellung und -funktion benötigt, hat unlängst auch für Missverständnisse auf der Kernel-Mailingliste geführt [2]. Berichte kolportierten, unter der GPLv3 müssten Entwickler unter Umständen ihre privaten PGP-Schlüssel veröffentlichen.

Das verlangt der Entwurf selbstverständlich nicht. Die Verpflichtung, Schlüssel für verschlüsselten Code bereitzustellen, greift nur, um sicherzustellen, dass der Benutzer den Quellcode übersetzen kann oder dass er Schlüssel erhält, die er benötigt, damit Software auf einer bestimmten Maschine läuft – oder um eine Datei lesen zu können, die ein bestimmtes Programm eventuell nach DRM-Manier verschlüsselt.

Interessant ist auch die Definition des Begriffs “covered work”. Dies seien die GPL-Software selbst wie auch jede abgeleitete (derivative) Software. Die Bedingungen, die die GPL für die Weitergabe, also das Vervielfältigen und Verbreiten der Software stellt, sollen nicht gelten, wenn der Empfänger keine Kopien erhält oder sich verschaffen kann. Diese Klausel klärt, dass Unternehmen oder Behörden intern beliebig viele Arbeitsplätze mit solchen Programmen ausstatten dürfen, ohne etwa den Mitarbeitern den Quellcode zugänglich machen zu müssen. Letztlich nichts Neues, aber zumindest eine Klarstellung.

Am Ende der Definitionsabschnitte zeigt der Entwurf, was die FSF unter “Digital Restrictions Management” versteht. Der Abschnitt soll zwei Funktionen erfüllen. Zum einen soll er bei jeder Auslegung der GPL klar machen, dass sie nie als DRM-freundlich interpretierbar ist. Die zweite Funktion versteht sich als geschickter Kunstgriff: Eine Klausel soll rechtsverbindlich klären, dass GPL-Software nicht selbst oder als Teil einer “wirksamen technischen Schutzmaßnahme”, etwa im Sinne des Paragrafen 95a Urheberrechtsgesetzes (UrhG, [3]) gilt.

Das soll zur Konsequenz haben, dass die Umgehung von DRM-Maßnahmen, die auf GPLv3-Code aufsetzen oder solchen nutzen, nicht mehr strafbar sein soll. Das würde zum Beispiel bedeuten, dass jeder etwa einen DVD-Abspielschutz oder den Zugriffszähler eines Programms, das MP3-Files wiedergibt, knacken darf, wenn das Programm GPLv3-Code enthält. Der Gedanke ist nicht schlecht – der Versuch, Strafbestimmungen auszuhebeln, indem gesetzliche Tatbestandsmerkmale vertraglich umdefiniert werden, kann jedoch nur scheitern. Dergleichen lässt zumindest die deutsche Rechtsordnung nicht zu.

Neu: Nutzungsverbot

Als Abkehr von dem bisherigen GPL-Grundsatz uneingeschränkter Freiheit wird erstmals ein Nutzungsverbot ausgesprochen: Nach Ziffer 3 soll das Verbreitungsrecht in dem Fall ausgeschlossen sein, wenn das Programm rechtswidrig in die Privatsphäre des Benutzers eingreift beziehungsweise in sein Recht auf informationelle Selbstbestimmung. Die FSF statuiert damit ein Verbot, DRM-Software zu schreiben.

Der Wortlaut führt nebenbei zu einem Verbot, Spyware, Viren oder andere Malware zu schreiben, und untersagt sogar noch mehr: Weil etwa das Ausfiltern von E-Mails in die Persönlichkeitsrechte der Benutzer eingreifen kann, wäre es per GPLv3 unter Umständen verboten, Greylist-Filterprogramme zu schreiben. Natürlich meint die FSF in erster Line DRM-Software, aber mit dem Verbot einzelner Anwendungsbereiche schießt man leicht übers Ziel hinaus.

Eine wichtige Änderung betrifft die Lizenzkompatibilität, also die Möglichkeit, GPL-Software mit anderer freier Software zu vermischen. Die GPLv3 erlaubt es unter bestimmten Voraussetzungen dezidiert, zusätzlich eingefügte Codebestandteile unter fremde Lizenzen zu stellen und das Ganze zu verbreiten. Der Entwurf unterscheidet dabei zwischen Lizenzbestimmungen, die zusätzliche Rechte einräumen, und solchen, die neben den GPLv3-Bedingungen zusätzliche Pflichten auferlegen. Während Bestimmungen, die zusätzliche Rechte einräumen, uneingeschränkt gestattet sind, zählt der Entwurf erlaubte Beschränkungen einzeln auf. Zulässig sind:

• Bedingungen, die durch bestimmte Copyright-Hinweise,
  Urhebervermer- ke, rechtliche Hinweise oder Versionsangaben
  vorgeschrieben sind.
• Bedingungen, die abweichende Haftungsausschlüsse
  vorsehen.
• Bedingungen, die die Werbung mit bestimmten Firmen- oder
  Markennamen verbieten oder einschränken.
• Bedingungen, die ein funktionierendes Abrufsystem für die
  vollständige Codebasis vorschreiben
  (Download-Now-Funktion).
• Patentklagen-Vergeltungsklauseln.

Diese unter Ziffer 7 aufgeführte Liste sieht der Entwurf als abschließend an.

Zwangslizenz

Ziffer 11 des Entwurfs sieht eine Zwangslizenzierung von Softwarepatenten vor: Wer GPLv3-Software, an der er Patentrechte hält, vertreibt, der gewährt nach dieser Bestimmung gleichzeitig und zwangsläufig jedem Empfänger und Folgempfänger ein einfaches, kostenloses Nutzungsrecht an der patentierten Technologie. Problematisch erscheint, dass sich diese Zwangslizenz auch auf jedes andere Patent erstrecken soll, das der Veröffentlicher zum Zeitpunkt des Vertreibens hält, und sogar auf jene, die ihm künftig erteilt werden.

Weil Verträge über künftige Leistungen erheblichen Bedenken begegnen, wenn diese Leistungen nicht ansatzweise konkret bestimmbar sind, dürfte dieser Teil der Klausel unwirksam sein. Auch die Zwangslizenzierung für Patente, die mit der konkret veröffentlichten Software überhaupt nichts zu tun haben, ist – gerade vor dem Recht der Allgemeinen Geschäftsbedingungen – möglicherweise unzulässig: Paragraf 308 Ziffer 5 des Bürgerlichen Gesetzbuchs (BGB) verbietet solche fingierten Erklärungen [4].

Gerade gegenüber Unternehmern (Patenthaltern) ist diese Vorschrift mittelbar über Paragraf 307 anwendbar, wenn sie den Vertragspartner unangemessen benachteiligt. Es ist zweifelhaft, ob eine solche “vertragliche Zwangsenteignung” angemessen ist. Letzlich bliebe die Entscheidung eines Obergerichts abzuwarten, wenn diese Bestimmung auch in der endgültigen Version enthalten bleibt.

Die Änderung, die mit Sicherheit die größte Aufmerksamkeit auf sich ziehen wird, ist die Vergeltungsklausel für Patentklagen. Es handelt sich dabei nicht um einen Bestandteil der GPL selbst, sondern, wie oben dargelegt, um eine Schnittstelle für entsprechende Zusatzklauseln. Die Voraussetzungen, unter denen ein Entwickler seinen Nutzern sämtliche Rechte an der Software entziehen können soll, sind: Der Benutzer muss eine Patentklage gegen eine beliebige Person eingebracht haben, bei der es sich nicht um eine Widerklage zur Abwehr patentrechtlicher Ansprüche handelt. Oder der Benutzer muss einen Rechsstreit führen gegen eine beliebige Person, deren Gegenstand Code ist, der unter den gleichen zusätzlichen Bedingungen veröffentlicht wurde.

Die Tragweite dieser Bestimmung ist nicht offensichtlich: De facto führt sie jedoch dazu, dass jeder, der eigene (Software-)patentrechtliche Ansprüche geltend macht, Gefahr läuft, die Nutzungsrechte an Codebestandteilen zu verlieren, die unter diesen zusätzlichen Bedingungen in GPLv3-Software eingearbeitet sind. Möglicherweise sogar die Rechte an allen Programmen, deren Lizenz eine derartige Klausel enthält. Darüber hinaus soll diese Konsequenz auch Dritte treffen können, wenn sie dem Kläger nur “nahe stehen”.

Es handelt sich dabei zwar nur um eine Öffnungsklausel und nicht um feste Bestandteile der GPLv3, doch liegt die Vermutung nahe, dass die FSF die Wirksamkeit solcher Strafklauseln testen möchte, um sie – wenn sie vor Gericht halten – in die nächste Version einzuarbeiten. Der Entwurf enthält also, was die Richtungsvorgabe betrifft, weit mehr als ein politisches Statement: Die FSF hat den Fehdehandschuh aufgenommen.

Abbildung 2: Eben Moglen ist Rechtsbeistand der FSF und einer der entscheidenden Köpfe hinter der GPL.

Gemischte Gefühle

Der erste Eindruck, den der Entwurf hinterlässt, ist zwiespältig, gerade vor dem Hintergrund der behutsamen Änderungen. Die neuen Regelungen zur Lizenzkompatibilität definieren erfreulich klare Voraussetzungen für die Frage, ob diese oder jene freie Software zur GPL passt. Dagegen wirken die Bestimmungen zu Softwarepatenten und DRM verhärmt und überzogen.

Abgesehen davon, dass der eine oder andere gewünschte Effekt vermutlich vor Gericht kassiert wird, weil er unangemessene Nachteile für Lizenznehmer der Version 3 bedeutet, scheint die FSF nicht von der Überlegenheit des bisherigen Konzepts und der Dominanz freier Software überzeugt. Aber vielleicht hat sie nur vor allen anderen erkannt, dass jetzt tatsächlich schwerere Geschütze aufzufahren sind, will man als Linux-Benutzer und -Entwickler nicht von der Software-Industrie und den Medienkonzernen überrollt werden. (mhu)