The Blog

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

Was ist passiert?
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.

Warum die Veränderung?
Open Source existiert 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. Zur Begründung wird auf Cloud-Anbieter verwiesen, die sich Vorteile aus Open-Source-Projekten verschafften.

Was sagen andere OSS-Anbieter, die Lizenzänderung vorgenommen haben?
Einen weiteren Grund für einen Lizenzwechsel liefert Grafana, welches von Apache zur AGPL wechselte: 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.

Was sollten Sie tun und worauf sollten Sie achten?
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.

Über den Autor:
Unsere Leidenschaft ist die Analyse und Visualisierung von Softwarestrukturen: Wir identifizieren versteckte Risiken in Softwaresystemen und unterstützen bei der technischen Due Diligence. Bitsea ist ein Pionier bei der automatisierten strukturierten Prüfung von Softwaresystemen. 2008 in Sankt Augustin gegründet, beraten wir internationale Konzerne und Mittelstand aller Branchen bezüglich Softwarequalität und -Compliance.
Bitsea hat mehr als fünfzehn Jahre Erfahrung in der Beratung zu Open-Source-Software (OSS) und bietet basierend auf ISO 5230 Lösungen im Bereich OSS Compliance an. Wir engagieren uns bei der Bitkom im Arbeitskreis Open Source und sind Partner der OpenChain. Mit innovativen Technologien bewerten und optimieren wir Software und stellen damit langfristig die Zukunftssicherheit von Software-Produkten her.