Nutze Copyleft-Lizenzen für Open Source oder Lebe mit den Konsequenzen

·3 min·Andreas Haerter·

Eine gute Open-Source-Lizenz ermöglicht die Wiederverwendung von Quellcode, während das Urheberrecht gewahrt bleibt. Man sollte dabei jedoch auch über das sogenannte Copyleft nachdenken, wenn man ein Open-Source-Projekt oder -Unternehmen startet.

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).

Hyperwachstum < Community

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.

Dein SaaS wird nicht mit AWS oder einem internen IT-Team konkurrieren können

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.