Open Source: Ärger wegen plötzlicher Lizenzänderungen



zerbrochene Buchstaben OSS

Open Source Software (OSS) ist überall und ist für die moderne Software-Entwicklung unverzichtbar geworden. Open Source wird getrieben von Communities: Die Projekte, welche den gesamten Quellcode frei zur Verfügung stellen, werden teils von einzelnen Entwicklern am Leben gehalten, teils durch eine breite Community unterstützt, und teils von einzelnen Firmen als Geschäftsmodell genutzt. Auch bei größeren Projekt-Communities finden sich einige Projekte, welche von einzelnen Firmen dominiert werden.

Open-Source bedeutet jedoch nicht, dass die Nutzung des Codes ohne jegliche Einschränkung erlaubt ist: Die Nutzung ist an Bedingungen geknüpft, welche vom Copyright-Halter vorgegeben werden. Völlig bedingungslose Nutzung existiert nur bei gemeinfreier Software („Public Domain“). Der erste BITKOM-Leitfaden zum Thema Open-Source-Software gibt folgende korrekte Beschreibung: „Die Verwertung, Vervielfältigung und Bearbeitung ist nicht vorbehaltlos gestattet, denn bei der Open Source Software wird vielfach die Einräumung von Nutzungsrechten von bestimmten Voraussetzungen abhängig gemacht…“. Die Bedingungen der einzelnen Lizenzen sind so vielfältig wie Open Source Projekte selbst: Von der Nennung des ursprünglichen Autors oder Copyright-Halters, der Beibehaltung der ursprünglichen Lizenz, dem Kauf eines Buches, der Nutzung nur für „Gutes“, bis zum Zwang, die gesamte erstellte Software wieder unter der ursprünglichen Lizenz als Open Source zu veröffentlichen finden sich tausende verschiedener Bedingungen.
Wenn einzelnen Firmen ihren Code als Open Source veröffentlichen, so ist dies in der Regel kein altruistisches Verhalten, sondern es sind weiterführende Absichten damit verbunden: Beispielsweise einen größeren Marktanteil zu erobern, zusätzliche Services zu verkaufen, oder an einer kommerziellen Premium-Version mit zusätzlichen Features Geld zu verdienen.

Wenn einzelnen Firmen ihren Code als Open Source veröffentlichen, so ist dies in der Regel kein altruistisches Verhalten, sondern es sind weiterführende Absichten damit verbunden: Beispielsweise einen größeren Marktanteil zu erobern, zusätzliche Services zu verkaufen, oder an einer kommerziellen Premium-Version mit zusätzlichen Features Geld zu verdienen.

In letzter Zeit lässt sich beobachten, dass einige der von wenigen oder nur einer Firma unterstützten Open Source Projekte beim Wechsel auf ein neues Release ihre Lizenzbedingungen von einer eher permissiven Lizenz, d.h. einer Lizenz ohne bedeutende Einschränkungen, zu einer restriktiveren Lizenz geändert haben. Hervorzuheben sind hier Elastic (ein auf Apache Lucene gestützter Echtzeit-Suchserver), Redis (eine In-Memory Datenbank), MongoDB (Datenbank) oder Grafana (grafische Darstellung von Daten). Alle änderten ihre Nutzungsbedingungen zu restriktiveren Lizenzmodellen. Dies hat die Community überrascht und verärgert. Die Gründe erscheinen ähnlich: Cloud Anbieter. Der Grund liegt wohl darin, dass angeblich einige Cloud-Anbieter den Open-Source-Code der Datenbank für gehostete kommerzielle Versionen ihrer Datenbanken verwenden, ohne dabei nach den Regeln der Open-Source-Community zu spielen.

Open Source lebt vom gegenseitigen Austausch. In einer Stellungnahme von Redis heißt es dazu: „Cloud-Anbieter tragen nur sehr wenig (wenn überhaupt) zu solchen Open-Source-Projekten bei. Im Gegensatz würden sie Hunderte Millionen Dollar an Umsätzen mit ihnen erzielen, was der Open-Source-Community Schäden verursache und einige Unternehmen sogar aus dem Markt verdränge.“

Redis hatte zuerst einige Module auf ein Common-Clauses-Lizenzmodell umgestellt, kurze Zeit später passte das Unternehmen das Modell an und führte die Redis Source Available License (RSAL) ein. Auch MongoDB entschied sich für einen Wechsel auf die Server Side Public License (SSPL). Schließlich wechselte Elastic von der Apache-2-Lizenz ebenfalls zur SSPL. Hauptgrund für den Ärger über Redis in der Open-Source-Community ist, dass Redis durch diesen Lizenzwechsel einen kommerziellen Vertrieb der entsprechend lizenzierten Module durch Dritte verbietet. Zur Begründung wird auf Cloud-Anbieter verwiesen, die sich Vorteile aus Open-Source-Projekten verschafften.

Einen weiteren Grund für einen Lizenzwechsel liefert Grafana, welches von Apache zur AGPL wechselts: Der Lizenzwechsel soll laut dem Unternehmen die faire Verwendung der Open-Source-Software sicherstellen. Die AGPL erlaubt weiterhin die freie Verwendung und Weiterentwicklung der Produkte. Im Vergleich zur GPL schließt sie das sogenannte ASP-Schlupfloch, durch die Unternehmen den Sourcecode für rein gehostete Versionen der Software nicht freigeben müssten. Auch Anaconda führte vor kurzem eine kommerzielle Lizenz für diejenigen Nutzer ein welche die Software „sehr intensiv“ nutzen. Mit „intensiver kommerzieller Nutzung“ sind diejenigen Nutzer gemeint, die das Repository im großen Stil spiegeln oder deren CI/CD- und Bereitstellungssysteme regelmäßig tausende von Paket-Download-Anfragen an das Repository stellen. Dazu der Mit-Gründer Peter Wang: „Zu diesem Zeitpunkt trägt Anaconda allein die Kosten für die Paketierung, das Testen und die monatlichen Bandbreitenkosten im Petabyte-Bereich. Ich vertraue darauf, dass unsere kommerziellen Nutzer verstehen, dass es für uns nicht länger vertretbar ist, diesen Service zum Nulltarif anzubieten.“

Was bedeutet dies für die Nutzung von Open Source? Bei der Auswahl eines Open Source Paketes empfehlen wir daher nicht nur auf die Funktionalität und die Aktualität zu achten, sondern auch auf die das Projekt pflegende Community: Hängt ein Open Source Projekt nur von einem oder wenigen Entwicklern ab, oder wird es hauptsächlich von einem einzigen Unternehmen getrieben, ist das Risiko einer unerwarteten und den eigenen Geschäftsinteressen entgegenstehenden Lizenzänderung ungleich höher, als wenn eine breite Community das Projekt unterstützt. Eine weitere Möglichkeit ist, sich selbst in die Community einzubringen und diejenigen für einen selbst maßgeblichen Projekte aktiv zu unterstützen, und damit zu versuchen sich einen gewissen Einfluss auf das Projekt zu sichern.


Comments are closed.