Github, die GPL und die Wirren der Open-Source-Lizenzen

Die General Public License (GNU GPL) war lange der Eckpfeiler der Open-Source-Bewegung – zumindest konnte man diesen Eindruck gewinnen. Bei genauerem Hinsehen bestand die Open-Source-Welt seit jeher aus vielen Lizenzen, die GNU GPL war nur ein kleiner Teil davon. Doch in den letzten Jahren ist immer deutlicher erkennbar, dass viele Entwickler aus verschiedenen Gründen einen offenen Hass für diese Lizenzen aufgebaut haben.

Erstaunlich ist, wie wenig heutzutage über die Lizenz diskutiert wird. Für mich ist das Thema durch Github wieder relevant geworden. Als Quelltext-Hoster ist Github momentan ein Zentrum der Open-Source-Bewegung, doch zugleich findet sich dort mehr zweckwidrig als zweckdienlich lizenzierte Software. Github hat versucht, das zu ändern und eine Lizenzauswahl eingeführt. Ich halte das für eine sehr schlechte Idee – besonders weil es das Thema GPL und alle Folgefragen wieder aufrollt.

Hier geht es daher um die Geschichte der Open-Source-Lizenzen, was sich zu verändern scheint – und darum, was wir tun können, um die Situation zu verbessern.

GPL: Was bisher passierte

Bevor die General Public License in der Version 3 (GPLv3) veröffentlicht wurde, war die GPLv2 die am weitesten verbreitete Copyleft-Lizenz. Copyleft und GNU GPL galten als eine Einheit. Die General Public License ist eine sehr restriktive Lizenz, da sie nicht lediglich eine handvoll Bedingungen festschreibt und den Rest erlaubt, sondern Rechte nach Art einer Whitelist aufführt. Aus diesem Grund wurde die Kompatibilität der GPL stets diskutiert. Bei der Frage der GPL-Kompatibilität geht es darum, eine Lizenz per Downgrade mit der GPL kompatibel zu machen. Bei den meisten Lizenzen war das möglich, aber einige Lizenzen enthalten Klauseln, die es unmöglich machen. Weit bekannt ist das Beispiel der Apache License 2.0, die durch zusätzliche Restriktionen für Patente als GPL-inkompatibel angesehen wurde, ähnlich einige Versionen der Mozilla Public License.

Als 2007 dann eine neue Version der GPL erarbeitet wurde, gewann die Frage der GPL-Kompatibilität ein weiteres Mal an Komplexität: Durch die Funktionsweise der GPL-Lizenzen sind verschiedene Versionen untereinander nicht kompatibel. Das ist nicht sonderlich überraschend. Sieht man sich aber an, wie das Ökosystem eigentlich funktionieren sollte und wie tatsächlich lizenziert wird, hat es enorme Auswirkungen.

Denn es gibt eine Menge Code, der je nach Betrachtungsweise entweder unter GPLv2 oder GPLv3 steht. Der Grund ist, dass Code bei GPL unter einer bestimmten Version oder „jeder späteren Version” (any later version) lizenziert werden kann. Und wie wird definiert, wie eine spätere Version aussieht? Durch die GPL selbst. Wenn ein Entwickler festlegt, dass für eine Software eine bestimmte Lizenzversion „oder jede spätere Version” gelten soll, haben Nachnutzer die Wahl: Sie können den Bedingungen der jeweiligen Version oder denen der späteren folgen.

Drei Lager in der GPL-Welt

Momentan gibt es daher drei Lager: Das erste, das bei der GPLv2 geblieben ist. Das zweite, das auf die GPLv3 hochgestuft hat. Und das dritte, in dem je nach Kontext entweder die GPLv2 oder GPLv3 genutzt wird. Ärger über die GPLv3 war am stärksten bei Linux und Busybox zu vernehmen: Beide entschieden, dass die einzig anwendbare Lizenz die GPLv2 ist. Auf der anderen Seite wurde ein Großteil des GNU-Codes vor ein paar Jahren auf GPLv3 überführt.

Das Ergebnis ist, dass GNU und Linux inzwischen in verschiedenen Welten leben. Ironischerweise steht „GNU/Linux” jetzt für einen Lizenzkonflikt. Da die meisten der GNU-Projekte unter der GPLv3 stehen und Linux immer bei GPLv2 bleiben wird, kann es kein Codesharing mehr zwischen diesen Projekten geben.

Das vermutlich größte Problem mit GPLv3 für Unternehmen ist ein Bestandteil der Lizenz, der als „Anti-Tivoisierung” bekannt ist. Ein zusätzlicher Abschnitt mit Bedingungen für den Fall, dass Software Teil eines Geräts im Consumer-Bereich wird. Im Kern wird gefordert, dass modifizierte Software auf einem unmodifizierten Gerät laufen muss. Die Lizenz verlangt, dass die Signaturschlüssel offengelegt sind und die Bedienungsanleitung Informationen darüber enthält, wie modifizierte Software installiert werden kann. Und es muss sichergestellt sein, dass modifizierte Software überhaupt auf dem Gerät läuft. Immerhin verlangt die Lizenz nicht, dass der Hersteller die Garantie dann aufrechterhalten muss.

Im Allgemeinen sind die Lizenzbedingungen damit ein großes Problem für Unternehmen. Apple zum Beispiel verkauft mit dem iPad und iPhone Geräte mit einem gesicherten Bootloader. Somit wäre es Apple unmöglich, den GPLv3-Bedingungen nachzukommen, ohne die Sicherheitssysteme komplett entfallen zu lassen. Es betrifft aber nicht nur Apple: In keinem Appstore wird man Software unter der GPLv3 finden. Die Lizenzbeschränkungen sind bei Googles Play-Store und ähnlichen Vertriebssystemen ebenfalls inkompatibel zur GPLv3.

Die Anti-GPL-Bewegung

Neben diesen Entwicklungen in der GPL-Umwelt gibt es weitere. Nicht alle hatten vergleichbaren Einfluss, aber sie haben dazu geführt, dass die GPL von vielen Entwicklern in anderem Licht gesehen wird. Android und weitere Projekte versuchen mittlerweile, das ganze System der GPL loszuwerden. Android geht dabei sehr weit und bietet einen GPL-freien Userspace an. In den Lizenzinformationen wird im Grundsatz die Apache License 2.0 bevorzugt, ausgenommen davon sind etwa Kernelmodule.

Warum also gibt es plötzlich so viel Angst vor GPL? Zum Teil liegt es daran, dass GPL schon immer eine radikale Lizenz war, vor allem weil eine Rückübertragung der Rechte fehlt. Es gibt etwa eine Klausel, die als „GPLv2-Todesstrafe” bekannt ist. Sie besagt, dass jedem, der die Lizenzregeln verletzt, automatisch die Lizenz entzogen bleibt, solange nicht ausdrücklich eine neue vergeben wurde. Ohne verbindlichen Rechteinhaber aber hieße das, man müsste jeden, der am Code mitgewirkt hat, nach einer neuen Lizenz fragen.

Darüber hinaus ist mittlerweile deutlich geworden, dass einige sogar der Meinung sind, man könne der Free Software Foundation nicht trauen. Es gibt hier zwei Fraktionen: Erstens diejenigen, die an die Ideologie Richard Stallmans glauben; zweitens diejenigen, die die GPLv2-Lizenz in Ordnung finden, aber nicht mit der Richtung einverstanden sind, in die sie sich entwickelt. Linus Torvalds ist eindeutig ein Vertreter der letzteren Fraktion. Sie existiert, weil die Free Software Foundation stark in ihrer eigenen Welt gefangen ist, in der Cloud Computing Teufelszeug ist, Smartphones nichts anderes als Ortungsgeräte und Android etwas ist, dass durch die GPL verhindert werden muss. Es gibt GPL-Unterstützer, die nicht die aktuelle Sichtweise der Free Software Foundation unterstützen. Selbst einige GNU-Projekte widersprechen den Zielen von GNU und der Free Software Foundation. Das Projekt GnuTLS etwa hat sich im Dezember 2012 von GNU gelöst.

Code ohne Lizenz

Nach einer – nicht wissenschaftlichen – Untersuchung durch Aaron Williamson vom Software Freedom Law Center sind nur bei 15 Prozent aller Repositories Lizenzdateien enthalten; nur etwa 25 Prozent erwähnen die Lizenz in der Readme-Datei. Williamson untersuchte dafür 28 Prozent der ältesten Github-Repositories – nur ein Drittel aller Projekte hatte eine Copyleft-Lizenz. In diesen Repositories stand die klare Mehrheit entweder unter MIT/BSD- oder Apache-2-Lizenz.

Das sind keine zufriedenstellenden Ergebnisse: Der Trend, Code ohne Lizenzerklärungen ins Netz zu stellen, ist bedenklich und wirft Fragen auf. Er zeigt aber weniger, dass Entwickler nichts von Lizenzen wissen als vielmehr, dass sie sie für unwichtig und vernachlässigbar halten. Deshalb sehe ich Githubs neues Lizenzauswahl-Werkzeug als problematisch an. Beim Erstellen eines neuen Verzeichnisses erscheint jetzt ein Lizenzwahl-Dialog; nur ohne Erklärung, was die Lizenz bedeutet. „Apache v2 License”, „GPLv2” und „MIT” werden hervorgehoben. Zwei dieser Lizenzen aber – Apache und GPLv2 – sind nicht untereinander kompatibel.

Screenshot: Lizenzauswahl bei Github

Wenn aber Entwickler zuvor keine Zeit damit verbracht haben, eine Lizenz zum Repository hinzuzufügen, dann wird es jetzt dazu führen, dass sie nicht über die Konsequenzen ihrer Wahl nachdenken. Angesichts all der verschiedenen Versionen von GPL und den rechtlichen Implikationen, die mit ihnen einhergehen, fürchte ich, dass das neue Lizenzauswahl-Werkzeug die Lage nur schlechter machen wird.

Wirren der Lizenzkompatibilität

Wenn die GPL ins Spiel kommt, hört der Spaß beim Lizenzieren auf: Zu viele Dinge und Wechselwirkungen sind zu beachten. Bedenkt man die unterschiedlichen Interpretationen der Lizenz, wird es noch schlimmer.

Das aber ist nicht nur ein Problem der GPL: Auch die Apache-Softwarelizenz ist ein ziemlicher Brocken. Ich bin mir sicher, dass nicht jeder, der Code unter die Lizenz gestellt hat, die Implikationen kennt. Die MIT-Lizenz dagegen umfasst gerade einmal zwei Paragraphen und einen Gewährleistungs-Auschluss, doch hier sind die Wechselwirkungen mit verschiedenen Jurisdiktionen nicht jedem klar.

Die implizite Annahme ist, dass irgendwie amerikanisches Recht Anwendung findet. Was nicht immer der Fall ist: Open-Source-Entwicklung ist international und nicht jedes Land ist gleich. Deutschland und Österreich etwa haben wenige Bestimmungen zum eigentlichen Urheberrecht und keine Mechanismen, um es zu übertragen. Stattdessen werden Nutzungsrechte übertragen, die der Rechteinhaber unterlizenzieren kann. Da das in den Lizenzerklärungen nicht vorkommt, frage ich mich manchmal, ob mir aus solchen Formalitäten noch einmal jemand einen Strick drehen kann.

Lizenzen für die Mashup-Generation

Ich glaube, zur Zeit passiert etwas Neues in meiner Generation. Und das ist vermutlich der wichtigste Grund, warum es mit der GPL bergab geht: Meine Generation will ein eingeschränkteres Urheberrecht als bisher und kürzere Schutzfristen. Interessanterweise möchte Richard Stallman genau das nicht. Ihm ist schmerzhaft bewusst, dass auch Copyleft auf Copyright basiert und daher nur mit einem starken Copyright im Rücken durchgesetzt werden kann.

Wer Software unter BSD- oder MIT-Lizenz stellt, den würde es vermutlich nicht stören, wenn das Urheberrecht abgeschafft oder stark eingeschränkt werden würde. Richard Stallmans Welt würde zusammenbrechen. Er meinte etwa, dass sich die Piratenpartei als Bumerang für die Freie-Software-Bewegung herausstellen werde.

Die neue Generation aber hat eine veränderte Sichtweise auf sharing und auf Geld. Sie will das Teilen von Inhalten und Software einfach machen, aber gleichzeitig eine unabhängige Monetarisierung ermöglichen. Es ist die Generation, die Remixe bei Youtube hochlädt, die kommentierte Walkthroughs für Computerspiele erstellt und auf viele andere Weisen mit den Inhalten anderer zu arbeiten gelernt hat.

Ein Erste-Hilfe-Kasten für Lizenzen

Wir sollten darüber nachdenken, unsere Softwarelizenz-Umwelt zu vereinfachen – weil wir sonst nicht abschätzen können, was in ein paar Jahren auf uns zukommt. Die Implikationen von Softwarelizenzen zu verdeutlichen und Hilfe zu geben, um die für die jeweiligen Ziele geeignete Lizenz auszuwählen – das wäre ein interessantes Vorhaben. Dazu würden zum Beispiel Grafiken gehören, die auf Kompatibilitätsprobleme hinweisen; die klarmachen, wie sich fehlende Erklärungen von Mitwirkenden an Software auswirken; und was passiert, wenn Rechteinhaber sterben oder nicht mehr auffindbar sind.

Ich bin sicher, dass ein guter User-Experience-Designer es schaffen würde, die Lizenzgrundlagen in 10 Minuten einfach erfahrbar zu machen. Die Informationen müssten von einem Rechtsanwalt und Mitgliedern der Community kontrolliert werden, um die Folgen für das Ökosystem fundiert einzuschätzen. Im Moment glaube ich jedenfalls, dass die Lizenzauswahl bei Github eine sehr schlechte Lösung für das Problem ist, dass Code ohne Lizenz veröffentlicht wird. Womöglich ist sie sogar schädlich, solange die Auswirkungen der jeweiligen Lizenzen nicht klar sind.

Dieser Artikel ist eine gekürzte Fassung von Armin Ronachers Posting „Licensing in a Post Copyright World”. Übersetzung: Anne-Christin Mook. Lizenz: CC BY-NC-SA.