SSPL (Server Side Public License) ist schlecht

Warum SSPL schlecht ist

• Die SSPL (Server Side Public License) ist eine schreckliche Lizenz für alle Nutzer, Unternehmen und die Community im Allgemeinen
• Produkte unter der SSPL-Lizenz sind nicht Open Source und zielen darauf ab, Konkurrenten im Cloud- und Managed-Service-Bereich auszuschalten, die Hosting-Preise zu erhöhen und Open Source zu zerstören
• Das Ziel der SSPL könnte weniger darin bestehen, gegen große Unternehmen zu kämpfen, als vielmehr darin, Geld an Investoren zurückfließen zu lassen

Was ist SSPL

• Die SSPL wurde 2008 von MongoDB, Inc. eingeführt und ist eine Lizenz, die die Nutzung von MongoDB einschränken soll
• Produkte wie Elasticsearch, Kibana und Graylog verwenden inzwischen ebenfalls die SSPL-Lizenz
• Laut Abschnitt 13 muss man, wenn man das Produkt direkt Kunden anbieten möchte, den "Quellcode des Dienstes" öffentlich bereitstellen

Warum SSPL für alle schlecht ist

• Die SSPL wurde als gute Lösung präsentiert, um einige böswillige Cloud-Unternehmen daran zu hindern, Profit zu machen, ohne etwas zur Community beizutragen. Tatsächlich ist sie jedoch eine Bedrohung für Freiheit und eine Lizenz, die Konkurrenten ausschaltet
• Diese Lizenz ist nichts weiter, als ehemals Open-Source-Produkte hinter dem irreführenden Geist von "kostenlos" zu verstecken und in kommerzielle Produkte einzusperren. Vielleicht sollten wir solche Software jetzt als "Freemium"-Software bezeichnen
• MongoDB, Elasticsearch, Kibana und Graylog sind keine Open-Source-Produkte mehr, und diese Unternehmen können nun vollständig bestimmen, wer ihre Produkte Kunden überhaupt anbieten darf. Das läuft auf das Ausschalten von Konkurrenz hinaus
• Sie können nun auch eigene Cloud-Hosting-Lösungen ohne Wettbewerber anbieten und, ohne den Quellcode offenzulegen, zu von ihnen festgelegten Gebühren Wettbewerb und Innovation abwürgen
• Für uns als Kunden bedeutet das, dass wir nicht mehr frei wählen können, welchen Cloud-Anbieter wir nutzen
• Ganz mechanisch werden die Hosting-Preise steigen, und unsere einzige Wahl wird darin bestehen, ein dediziertes Team zu haben, das den Hosting-Teil auf der eigenen Infrastruktur verwaltet. Genau dem wollten wir in den letzten Jahren mit Cloud-Hosting-Lösungen entkommen

Unternehmen, die SSPL verwenden

• Produkte von MongoDB verwenden seit 2018 die SSPL-Lizenz; dahinter steht MongoDB, Inc.
• Produkte von Elasticsearch verwenden seit 2021 die SSPL-Lizenz; dahinter steht Elastic NV
• Produkte von Graylog verwenden seit 2020 die SSPL-Lizenz; dahinter steht GrayLog, Inc.

Einige Fragen, die wir uns selbst stellen sollten

• Wie kann ein Unternehmen, das selbst kein Open Source mehr verwendet, von anderen verlangen, "der Community etwas zurückzugeben"?
• Wie kann ein Unternehmen, das den Quellcode seines eigenen Cloud-Dienstes nicht offenlegt, von anderen verlangen, ihren Quellcode offenzulegen?
• Wie kann ein Unternehmen eine Nicht-Open-Source-Lizenz verwenden und zugleich erklären, Open Source sei Teil seiner DNA?
• Wie viele der mehr als 3000 Mitarbeitenden teilen ihre Arbeit und ihren Quellcode tatsächlich mit der Community? (Spoiler: sehr viel weniger)
• Handelt es sich um ein Technologieunternehmen, das mit der Community teilen will, oder um ein Vertriebsunternehmen, das die Rendite seiner Investoren steigern will?

Falsche Behauptungen über SSPL

• Die Behauptung "Ich bin kein Cloud-Anbieter, also betrifft mich das nicht" verkennt, dass tatsächlich alle von diesem Thema betroffen sind
• Die Behauptung "Diese Unternehmen brauchen Geld zum Überleben" verkennt, dass Geldverdienen mit Open Source nicht das Problem ist, SSPL aber nicht die richtige Lösung darstellt
• Die Behauptung "Konkurrenten existieren weiterhin. Über SSPL kann man verhandeln" bedeutet in Wirklichkeit, dass das marktbeherrschende Unternehmen Preise und Bedingungen seiner Konkurrenten festlegen kann
• Die Behauptung "SSPL ist ein Kampf gegen große Cloud-Akteure und gut für kleine Unternehmen" verkennt, dass SSPL in Wirklichkeit kleine Wettbewerber in den Bankrott treiben und vom Markt verdrängen kann

Ratschläge für Open-Source-Projekte

• Auch wenn SSPL anfangs wie eine gute Lösung erscheinen mag, ist davon abzuraten, diesen Fehler zu machen
• Wenn es Probleme mit einigen Cloud-Anbietern gibt, können wir sie nicht ignorieren, und wir alle müssen gemeinsam dagegen kämpfen. Die Open-Source-Welt zu verlassen, um diesen Kampf zu führen, ist kein guter Weg
• Wenn Rentabilität nötig ist, setzt auf Enterprise-Lizenzen und Premium-Support: "Wenn Sie Support brauchen, haben wir dafür das beste Team."
• Verwendet Copyleft-Lizenzen, damit Unternehmen der Community etwas zurückgeben können: "Wenn ihr unseren Code verändert, teilt ihn mit der Community"
• Wenn ihr euch dennoch für die SSPL-Lizenz entscheidet, dann werdet ihr:
  • viele unabhängige Beitragende und beitragende Mitarbeitende großer Unternehmen verlieren
  • Beitragende verraten, die daran gearbeitet haben, Open-Source-Software zu verbessern
  • die Open-Source-Welt verlassen und Freemium-Software entwickeln
  • euer Produkt mit einem sehr schlechten Ruf verbinden
  • den Nutzen vieler unterschiedlicher Akteure verlieren, die dabei helfen, euer Produkt weltweit bekannt zu machen, wodurch der Bedarf an Premium-Support steigt

[aer0700]

Man kann es wählen, weil es Open Source ist, aber es gibt auch Fälle, in denen es gerade deshalb aus der Auswahl ausgeschlossen wird.
Die Lizenz dürfte wohl entstanden sein, weil AWS MongoDB übernommen und daraus DynamoDB gemacht hat; aus Sicht von Leuten, die Open Source mögen, kann das schon etwas fragwürdig wirken.

[coremaker]

Ein Vergleich mit der AGPL wäre auch interessant.
https://sktelecom.github.io/guide/use/obligation/agpl-3.0/

[xguru]

Wie schon an Domainname und Seitennamen SSPL is BAD zu sehen ist, handelt es sich um eine Website, die mit einer bestimmten Absicht erstellt wurde.
Teilweise sind die Schlussfolgerungen auch ziemlich überzogen. Bitte lesen Sie sie zusammen mit den folgenden Meinungen auf Hacker News.

Meinungen auf Hacker News

• Es gibt eine grundsätzliche Ablehnung von SSPL, zugleich aber auch Verständnis für den Hintergrund. Kritisiert wird auch, dass die Darstellung von Artikel 13 eher sensationsheischend als objektiv analysierend sei.

  • MongoDB und Elastic hätten nicht erwartet, dass AWS ihre Produkte neu verpackt, als Service anbietet und damit zum Konkurrenten wird. Die von Elasticsearch verwendete Apache-Lizenz erlaubte dies zwar, moralisch hätte man es jedoch verhindern sollen, so eine Meinung.
  • AWS hätte auch durch OEM-Verträge oder Partnerschaften eine "Win-win"-Beziehung aufbauen können, habe dies aber nicht getan und damit eine unangenehme Blockadeform wie SSPL ausgelöst, so die Kritik.
  • Es gibt Beschwerden darüber, dass SSPL geschaffen worden sei, um Investoren zufriedenzustellen. Aber auch wenn es sich um Open-Source-Software handelt, verfolgen Unternehmen nicht zwangsläufig gemeinnützige Ziele; daher sei unverständlich, warum Elastic oder MongoDB kritisiert werden, AWS aber nicht.

• SSPL sei schlecht für Nutzer, weil es Monopole fördere, die Beteiligung der Community verringere und sich letztlich auf alle Nutzer auswirke.

• Dass Menschen Geld verdienen wollen, sei selbstverständlich, und man könne sich auch einfach gegen die Nutzung eines SSPL-Projekts entscheiden. Die Sichtweise lautet, dass unter SSPL veröffentlichte Software besser sei als gar keine Software.

• Das aktuelle Ökosystem unterscheide sich stark von dem vor zehn Jahren, und man wünsche sich Wege, auf denen kleine Unternehmen im Wettbewerb überleben und wachsen können. Lizenzen wie die BSL (Business Source License) seien vielleicht nicht perfekt, könnten aber als Versuch gesehen werden, einen gesunden Mittelweg zu finden.

• Es sei merkwürdig, SSPL zu kritisieren, ohne AGPL zu erwähnen. Dabei wird auf Menschen hingewiesen, die freie Software nutzen wollen, aber nicht beitragen möchten.

• Man sollte nicht einseitig urteilen, sondern je nach Einzelfall unterschiedlich herangehen. SSPL könne für manche Unternehmen gut sein, die gegen Cloud-Giganten ums Überleben kämpfen, aber schlecht für andere Unternehmen, die Mitwirkende ausnutzen wollen.

• Es ist untersagt, die Produkte MongoDB, Elasticsearch und Graylog Kunden direkt vorzuschlagen. Das Wort "direkt" in der SSPL lasse Raum für juristische Auseinandersetzungen, was vielen Sorgen bereite.

• Die FSL (Functional Source License) ist eine gute alternative Lizenz, die nach zwei Jahren automatisch in Apache 2.0 oder MIT umgewandelt wird. Sie ist einfach und bietet einen vernünftigen Weg, den Quellcode offenzulegen und zugleich SaaS-Unternehmen funktionsfähig zu halten.

• Eine Korrektur zu der falschen Information, SSPL sei 2008 eingeführt worden. Tatsächlich wurde sie 2018 eingeführt.

• Kritik an einer eindimensionalen Sichtweise auf die Zukunft des Urheberrechts.