GPLv2 vs. GPLv3: warum viele wichtige Projekte bei der alten Version geblieben sind

Bild von Innova Labs auf Pixabay

Als ich mich vor einer Weile hingesetzt habe, um für meine beiden kleinen GNOME Apps eine Lizenz auszuwählen, dachte ich zuerst, das wäre eine Formsache. Ein paar Zeilen in die Readme, eine Kopie des Lizenztextes ins Repo, fertig.

Ich wurde schnell eines Besseren belehrt. Wer sich ernsthaft mit den Unterschieden zwischen der GNU General Public License in Version 2 und Version 3 auseinandersetzt, merkt rasch, dass hier eine der grundlegendsten Debatten der gesamten freien Softwarebewegung geführt wird. Eine Debatte, die bis heute nicht entschieden ist.

Am Ende habe ich mich für Boot Mate, meinen Autostart Manager, und für Cargo, meinen Dual Pane Dateitransfer, bewusst für die GPLv2 entschieden. Nicht aus Bequemlichkeit, sondern aus Überzeugung.

In diesem Artikel will ich aber nicht diese Apps in den Mittelpunkt stellen, sondern die eigentliche Frage dahinter: Warum um alles in der Welt blieben so viele der wichtigsten Projekte der Linuxwelt bei der älteren Version stehen, obwohl die Free Software Foundation mit der GPLv3 eine aktualisierte und aus ihrer Sicht bessere Lizenz geschrieben hat?

Die Geschichte dahinter, in Kürze

Die GPLv2 wurde 1991 von Richard Stallman veröffentlicht und war über anderthalb Jahrzehnte der Goldstandard des Copyleft. Wer freie Software schrieb und wollte, dass ihre Freiheit auch bei Weiterverteilungen erhalten bleibt, griff zur GPLv2.

Linus Torvalds tat es mit dem Linux Kernel, die GNU Werkzeuge lagen darunter, MySQL, Samba, GIMP, unzählige kleinere Projekte ebenfalls. Mit der Zeit zeigten sich aber Lücken, die im Jahr 1991 schlicht nicht absehbar gewesen waren.

Die wohl bekannteste davon betraf ein Gerät namens TiVo, einen amerikanischen Festplattenrekorder, der auf einem Linux Kernel basierte. TiVo hielt sich formal an die GPLv2, veröffentlichte den Quellcode brav, baute dann aber eine Hardwareprüfung ein, die dafür sorgte, dass modifizierte Versionen der Software auf dem Gerät schlicht nicht mehr starteten.

Man durfte den Code lesen, verändern, neu kompilieren, nur eben nicht im eigenen Gerät benutzen. Für Stallman und die FSF war das ein klarer Verstoss gegen den Geist der GPL, auch wenn der Buchstabe nicht verletzt wurde. Die Antwort war ein mehrjähriger Entwurfsprozess, an dessen Ende im Juni 2007 die GPLv3 stand.

Diese neue Version wollte drei Hauptprobleme angehen. Erstens die gerade geschilderte Tivoisierung, also das Aushebeln der Freiheit durch Hardwareschranken.

Zweitens die Bedrohung durch Softwarepatente, die nach dem Novell Microsoft Deal von 2006 vielen Entwicklerinnen und Entwicklern schlaflose Nächte bereitete. Drittens eine bessere Kompatibilität mit anderen freien Lizenzen wie der Apache License 2.0. Alles gut gemeint, alles nachvollziehbar, alles auf den ersten Blick ein Fortschritt.

Linus Torvalds und der pragmatische Graben

Und doch kam es anders. Der prominenteste Widerstand gegen die GPLv3 kam ausgerechnet vom Gesicht der Linuxwelt schlechthin. Linus Torvalds lehnte die neue Version in scharfen Worten ab und machte bereits früh klar, dass der Kernel nicht umziehen würde.

Seine Argumentation lässt sich in zwei Stossrichtungen zusammenfassen. Die eine ist formal. Torvalds hatte den Kernel von Anfang an unter "GPL version 2 only" gestellt, ohne die oft verwendete Klausel "or any later version". Das bedeutet, der Kernel kann nicht einfach per Entscheid auf eine neuere Lizenz gehoben werden. Jede einzelne der zehntausenden Codebeitragenden müsste zustimmen, und das ist in der Praxis unmöglich.

Diese bewusste Entscheidung hat Torvalds immer wieder als rational begründet. Er wollte seine Lizenzwahl nicht in fremde Hände legen, nicht von einer Organisation abhängig machen, deren zukünftige Texte er noch gar nicht kenne. Wer "or any later version" schreibe, unterzeichne de facto einen Blankoscheck.

Die andere Stossrichtung ist inhaltlich. Torvalds teilt die Diagnose der Tivoisierung schlicht nicht. Aus seiner Sicht deckt der Kernel die Software ab, nicht die Hardware drum herum. Wenn ein Hersteller seine Geräte so baut, dass darauf nur signierte Images laufen, dann ist das aus Kernelperspektive keine Sache, in die er sich einmischen will.

Andere Kernelentwickler wie Alan Cox sahen das anders und waren offener für die GPLv3, aber die Mehrheit folgte Torvalds. Das Resultat ist bis heute sichtbar. Der Linux Kernel bleibt unter GPLv2 only, und damit steht er in einer ziemlich problematischen Nachbarschaft: Er ist inkompatibel mit reinem GPLv3 Code. Paradoxerweise können Kernelteile also nicht einfach mit Code aus GNU Projekten kombiniert werden, die auf GPLv3 umgestellt haben. Der alte Witz, dass das Gesamtsystem eigentlich GNU plus Linux heisst, wurde plötzlich zu einer Art Lizenzwitz mit bitterem Nachgeschmack.

BusyBox, das Schlüsselprojekt der eingebetteten Welt

Ein zweites Beispiel, das in der Debatte oft zitiert wird, ist BusyBox. Das Paket bündelt unzählige Unixwerkzeuge in einer einzigen kleinen Binärdatei und läuft heute in praktisch jedem Router, Fernseher und NAS Gerät mit Linuxkern. BusyBox war ursprünglich unter "GPLv2 or later" veröffentlicht worden.

Als Version 3 in den Raum gestellt wurde, brach innerhalb des Projekts eine lange und am Ende sehr unfreundliche Debatte aus. Der damalige Maintainer Rob Landley entschied, BusyBox ausdrücklich auf GPLv2 only zu begrenzen. Sein Argument war im Kern ein ökonomisches und ein technisches zugleich. Ökonomisch, weil die eingebettete Industrie, die BusyBox massenhaft einsetzt, mit der Antitivoisierungsklausel der GPLv3 ein erhebliches Problem hätte und im Zweifel einfach komplett auf freie Alternativen verzichten oder eigene Tools schreiben würde. Technisch, weil Landley den Wert sah, einen einheitlichen Pool aus GPLv2 Code zu pflegen, der mit dem Kernel und vielen anderen Kernkomponenten problemlos zusammenspielt.

Dass Bruce Perens, der BusyBox Jahre zuvor gestartet hatte, sich lautstark gegen diese Beschränkung wehrte, änderte nichts am Ergebnis.

Git, QEMU und weitere Erben der GPLv2

Auch Git, das moderne Versionsverwaltungssystem, das Torvalds ursprünglich für die Kernelentwicklung geschrieben hatte, ist GPLv2 only. Das ist konsequent, weil Git in genau jenem Umfeld entstanden ist und dasselbe Lizenzmodell übernommen hat.

Interessanterweise gilt dasselbe für QEMU, die verbreitete Virtualisierungs und Emulationssoftware. QEMU steht unter GPLv2 only, aus einem sehr pragmatischen Grund. Das Projekt schöpft regelmässig aus dem Linux Kernel, um Treiber in Emulationen umzubauen, und wäre bei einer Lizenz mit Or Later Klausel irgendwann zwischen den Stühlen gelandet. Wenn plötzlich GPLv3 only Code aus den GNU Werkzeugen dazukäme, könnte aus der Mischung eine Binärdatei entstehen, die unter keiner einheitlichen Lizenz mehr ausgeliefert werden dürfte. GPLv2 only ist in diesem Kontext nicht ideologische Sturheit, sondern saubere technische Hygiene.

MySQL, später als MariaDB fortgeführt, änderte seine Lizenzangabe in ähnlicher Weise von "GPLv2 or later" auf "GPLv2 only". Auch dahinter stand ein kommerzielles Interesse. Die damalige "MySQL AB" wollte nicht, dass Drittanbieter ihre Fortsätze plötzlich unter einer neuen Lizenz weitervertreiben konnten, die das Geschäftsmodell der Firma betreffen würde.

WordPress bewegt sich in einer Zwischenwelt. Das Kernprojekt ist als "GPLv2 or later" lizenziert, was formell eine Nutzung unter GPLv3 erlauben würde. In der Praxis verhält sich das Ökosystem aber wie eine GPLv2 Welt, weil viele grosse Plugins, Themes und Tools bewusst nur v2 angeben und damit die Bewegungsfreiheit des Gesamtsystems de facto auf die alte Version festzurren.

Die harten technischen Folgen

Ein Punkt, der in öffentlichen Debatten oft untergeht, ist die direkte Inkompatibilität der beiden Lizenzversionen. Wer Code hat, der strikt unter GPLv2 only steht, darf diesen nicht mit Code kombinieren, der strikt unter GPLv3 steht. Beide verlangen, dass das Gesamtwerk unter den eigenen Bedingungen weitergegeben wird, und beide Bedingungen lassen sich nicht gleichzeitig erfüllen.

Die praktische Folge ist ein Graben durch die freie Softwarelandschaft, der sich seit 2007 nicht mehr geschlossen hat. Bibliotheken wie GNU LibreDWG stehen heute unter GPLv3 und sind damit für GPLv2 only Projekte wie LibreCAD oder FreeCAD unerreichbar. Für mich als Aussenstehender wirkt das fast schon tragisch, weil eigentlich beide Seiten für dieselbe Sache kämpfen und sich am Ende gegenseitig den Zugriff auf gemeinsame Werke verbauen.

Dazu kommt die pure Komplexität. Die GPLv2 ist in sich ein vergleichsweise kompaktes Dokument, das sich in einer ruhigen Stunde vollständig lesen und in weiten Teilen auch ohne Jurastudium verstehen lässt. Die GPLv3 ist deutlich länger, juristisch ausgefeilter und an vielen Stellen so präzise formuliert, dass Entwicklerinnen und Entwickler erst eine gute halbe Stunde brauchen, bis sie sicher wissen, ob ihr konkreter Anwendungsfall betroffen ist oder nicht. In einer Welt, in der man Menschen schnell von einer Lizenz überzeugen muss, ist ein einfacher Text ein enormer Vorteil.

Philosophie auf der einen, Pragmatismus auf der anderen Seite

Unter all diesen technischen und rechtlichen Überlegungen liegt ein philosophischer Gegensatz, den man nicht wegdiskutieren kann. Auf der einen Seite steht die Free Software Foundation mit ihrer Idealvorstellung, dass jede Form von Kontrolle, die eine Nutzerin oder einen Nutzer daran hindert, Software wirklich zu verändern und zu nutzen, bekämpft werden muss.

Hardwareprüfungen, Fernabschaltungen, eingebaute Selbstzerstörungen von modifizierter Software, all das gilt aus dieser Sicht als moderner Versuch, die Freiheit auf dem Umweg über den Chip wieder abzuschaffen. Auf der anderen Seite steht ein eher ingenieurgetriebenes Lager, das mit dem Begriff Tivoisierung wenig anfangen kann und darin eher eine ideologische Aufladung sieht. Wer in diesem Lager argumentiert, sagt typischerweise: Software ist Software, Hardware ist Hardware, und wer seine eigene Hardware baut, darf entscheiden, was darauf läuft. Beide Positionen haben ihren Kern. Beide lassen sich nicht einfach auf "gut" und "böse" herunterbrechen.

Ich persönlich stehe irgendwo in der Mitte. Ich teile die Sorge der FSF, dass Hardwareschranken die Idee freier Software langfristig aushöhlen könnten. Gleichzeitig teile ich auch den Pragmatismus der Kernelseite, dass eine Lizenz mit möglichst wenigen Bedingungen einfacher zu verstehen, einfacher durchzusetzen und einfacher in andere Projekte hineinzutragen ist. Genau deshalb liegen meine beiden Projekte, Boot Mate und Cargo, bewusst unter GPLv2.

Sie sind Desktopwerkzeuge, keine eingebetteten Systeme, und die ganze Diskussion um Hardwareschranken spielt für sie keine Rolle. Was für sie zählt, ist die Bindung an den grossen, gemeinsamen Pool aus GPLv2 Code, in dem der Kernel, BusyBox, Git und unzählige andere Projekte liegen. Mit der Entscheidung für die ältere Version kaufe ich mir nicht Stillstand ein, sondern Verbindung.

Warum die alte Version nicht alt ist

Wer aus der Perspektive von 2026 auf die Situation schaut, könnte denken, die GPLv2 sei ein Relikt und die GPLv3 die moderne Alternative. Das stimmt aber nur auf dem Papier. In der gelebten Praxis trägt die GPLv2 noch immer einen enormen Teil der freien Softwarewelt. Der meistgenutzte Kernel der Welt steht darunter. Die meistgenutzten eingebetteten Tools stehen darunter. Das am weitesten verbreitete Versionsverwaltungssystem steht darunter. Die verbreitetste freie Datenbank, sei es als MySQL oder als MariaDB, steht darunter. Wer all diese Projekte als rückständig oder philosophisch defekt bezeichnen wollte, müsste praktisch die Geschichte der letzten beiden Jahrzehnte komplett umschreiben.

Die spannendere Leseart lautet, dass die GPLv2 nicht stehengeblieben ist, sondern zu einer gemeinsamen Basisschicht geworden ist, auf der sich Menschen aus sehr unterschiedlichen Lagern einigen konnten. Idealistinnen und Idealisten fanden in ihr genug Copyleft, um ihre Werke zu schützen. Pragmatiker und Pragmatikerinnen fanden in ihr genug Einfachheit, um sie auch in hochregulierten Kontexten durchzuboxen. Unternehmen fanden in ihr genug Rechtssicherheit, um ihre Geschäftsmodelle darauf aufzubauen. Die GPLv3 löst theoretisch einige Probleme der GPLv2, aber sie löst sie um den Preis einer Spaltung, die bis heute nicht verheilt ist.

Wenn ich heute ein neues Projekt starte, schaue ich zuerst, in welchen Kontext es sich einfügen soll. Für eine klassische Desktop App im Linuxumfeld bleibt die GPLv2 für mich die naheliegende Wahl. Für ein Projekt, das eng mit der GNU Welt verzahnt ist, wäre GPLv3 konsequenter. Für ein Netzwerkwerk, das hauptsächlich als Dienst läuft, wäre sogar die AGPL die passende Variante. Die Frage ist also nicht, welche Lizenz die bessere ist, sondern welche Lizenz zu dem passt, was ich eigentlich erreichen will.

Und genau das ist wahrscheinlich die wichtigste Lehre aus der ganzen Debatte um Version 2 und Version 3. Es gibt keine universell beste Copyleft Lizenz. Es gibt nur Lizenzen, die zu bestimmten Projekten, bestimmten Communities und bestimmten Geschichten passen. Dass die GPLv2 in so vielen zentralen Projekten stehengeblieben ist, ist kein Zeichen von Starrsinn. Es ist ein Zeichen dafür, dass sie ihre Aufgabe in diesen Projekten immer noch gut erfüllt.