Diese Klausel behandelt, wie zukünftige Versionen der Lizenz gehandhabt werden und besagt, dass die Free Software Foundation (FSF) neue Versionen der GPL veröffentlichen kann, die im Geiste der aktuellen Version ähnlich sein werden, aber Änderungen zur Bewältigung neuer rechtlicher und technologischer Fragen enthalten können. Dies stellt auch den Schutz freier Software vor möglichen Fehltritten der Free Software Foundation (FSF) selbst sicher da beispielsweise niemand eine gültige GPLv4 ohne Copyleft erklären könnte. Es wird immer wieder argumentiert, dass die GPLv3 grundlegend anders ist als die GPLv2. Aber am Besten liest man sie einfach selbst, um festzustellen, dass die Vorwürfe unbegründet sind – sie ist im Geiste tatsächlich ähnlich. Wir für unseren Teil empfehlen daher für unsere eigenen Projekte, die “or later”-Variante zu wählen.
Die Verwendung von GPL-2.0-only hat in der Vergangenheit erhebliche Kompatibilitätsprobleme mit anderen Lizenzen geschaffen, die die Integration und Verteilung kombinierter Werke behinderten. Beispielsweise ist Software, die unter GPL-2.0-only lizenziert ist, nicht mit der Apache-2.0-Lizenz kompatibel, was die Kombination von zahlreichen Code-Basen bis heute verhindert. Und einige Projekte mussten viel Zeit und Arbeit investieren, um die Lizenzierung zu ändern, um eine bessere Lizenzkompatibilität zu erreichen und Integrationsbarrieren zu reduzieren. Diese Probleme können zu Fragmentierung und geringerer Flexibilität im Open-Source-Ökosystem führen.
Die GPLv2 hat gezeigt, dass diese Anpassungsfähigkeit notwendig sein kann, da das Festhalten an GPL-2.0-only keinen wesentlichen Nutzen brachte aber zu Kompatibilitätsproblemen führte. Daher ergibt es Sinn, wann immer möglich die “or later” Option zu wählen. Dieser Ansatz bewahrt nicht nur den Geist der Lizenz, sondern bietet auch eine Absicherung gegen potenzielle zukünftige Herausforderungen, ähnlich einem gut vorbereiteten Notfallplan.
Die “or later”-Klausel der GPL-3.0-or-later-Lizenzierung ist wichtig, da sie die Weiterentwicklung der Lizenz ermöglicht, um mit sich ändernden Umständen Schritt halten zu können und fortlaufenden Schutz und Freiheit für Softwarebenutzer und -entwickler zu gewährleisten. Diese Klausel ist wie ein Sicherheitsnetz, das erlaubt, sich an zukünftige Änderungen in der rechtlichen und technologischen Landschaft anzupassen und eine Zusammenarbeit verschiedenster Parteien auch in Zukunft zu ermöglichen.
Dies gilt auch für Klausel 9 der GPLv2. ↩︎
Lizenzen wie die General Public License (GPL) sind in der Regel besser für das Open-Source-Ökosystem, als freizügigere Lizenzen wie Apache 2 oder MIT. Eine Copyleft-Lizenz verlangt in der Regel, dass alle Änderungen oder abgeleitete Werke wieder geteilt werden, wodurch der Kreislauf von Nehmen und Geben gefördert wird. Verbesserungen kommen so der gesamten Gemeinschaft zugute, anstatt über die Lizenz eine Ausnutzung von Open-Source-Code ohne Gegenleistung zu ermöglichen (looking at you, Amazon Web Services).
Lizenzen wie die GNU Affero General Public License (AGPL) halten manche Unternehmen davon ab, ein Open-Source-Projekt zu nutzen, da sie den Quellcode ihrer eigenen Änderungen daran nicht veröffentlichen wollen. Leider verbieten oftmals sogar Unternehmensrichtlinien die Nutzung von Copyleft-Projekten, selbst wenn niemand plant, etwas an der Software zu ändern. Besonders “enterprizy” Rechtsabteilungen großer Organisationen bevorzugen daher oftmals Software mit Lizenzen wie MIT, um es sich einfach zu machen und vermeintliche Risiken zu vermeiden.
Im Hinblick auf Lizenzänderungen entsteht der Eindruck, dass viele Start-ups Open Source nicht wegen der damit verbundenen Freiheit nutzen, sondern diese lediglich als Argument für die Akzeptanz in eben diesen genannten Unternehmensökosystemen. Sie vermeiden also, Lizenzen wie die (A)GPLv3 zu wählen, um die Unternehmensakzeptanz zu erhöhen. Währenddessen generieren sie zu wenige Einnahmen und bekommen auch keine Beiträge und Entwicklungen von Nutzern zurück. Auch nicht von denjenigen, die es sich definitiv leisten könnten, etwas beizutragen. Dies geht solang gut, wie das Projekt durch Risikokapital weiterfinanziert wird. Nachdem man über diesen Weg eine breite Verbreitung gefunden hat, beschwert man sich.
Während die Open-Source-Beiträge von Unternehmen wie HashiCorp beeindruckend sind, ist die Gesamtsituation komplex. Es gibt einen Grund, warum Linux unter der GPL immer noch existiert, stetig wächst und viele dennoch Geld damit verdienen, während die Unternehmen hinter weit verbreiteten Open-Source-Projekten oft finanziell scheitern und riesige Geldmengen verbrennen. Es lohnt sich gegebenenfalls für Einzelpersonen und Eigentümer für den Fall des Aufkaufs, aber es schadet Nutzern und Ökosystemen, die sich auf etwas verlassen haben.
Man sollte nicht überrascht sein, wenn Lizenzen wie MIT große Unternehmen und Nutzer anziehen, denen das Projekt oder die Gemeinschaft dahinter egal sind. Das macht es später natürlich schwierig, eine faire Zusammenarbeit (einschließlich finanzieller Ressourcen) mit eben diesen zu finden. Setzt man stattdessen auf eine echte Copyleft-Lizenz und nimmt in Kauf, dass nicht jede Großorganisation damit umgehen kann, fällt der Fokus auf organisches Wachstum mit Menschen leichter, denen das Projekt am Herzen liegt.
Alternativ muss man auf die Konsequenz vorbereitet sein, dass Amazon oder andere Hyperscaler eine große Anzahl von Kunden anziehen, die das Projekt nutzen, ohne etwas zurückzugeben. Letztendlich halten diese sich einfach an die Regeln und signalisieren beispielsweise mit der MIT-Lizenz, dass dies “schon in Ordnung” ist.
Wenn man diesen Weg dennoch beschreiten will, sollte man von Anfang an andere Einkommensquellen als reine Software-as-a-Service-Angebote etablieren. Man muss dabei realistisch sein: Mit dem eigenen SaaS-Produkt wird man gegen ein SaaS von Amazon oder anderen Hyperscalern – oder sogar mit dem gut ausgebildeten internen Betriebsteam einer Organisation – niemals dauerhaft konkurrieren können. Dienstleistungen, die Nutzer beim Betrieb im eigenen Haus unterstützen oder bezahlte Weiterentwicklung auch mit Open Source ermöglichen (z.B. Priorisierung von Features gegen Bezahlung), sind die bessere Wahl.
]]>