Die Open-Source-Lizenzkriege: Wie HashiCorp, Redis und Elastic die Regeln änderten

Das sich wiederholende Muster

Drei der weltweit am häufigsten genutzten Infrastruktur-Softwareprojekte änderten innerhalb weniger Jahre ihre Lizenzen. HashiCorp änderte Terraform von der Mozilla Public License 2.0 zur Business Source License (BSL) im August 2023. Redis wechselte von BSD zur Server Side Public License (SSPL) im März 2024. Elastic hatte Elasticsearch und Kibana bereits 2021 auf SSPL umgestellt. Alle drei Unternehmen gaben ähnliche Erklärungen: Cloud-Anbieter nutzten ihre Software, um konkurrierende Managed Services aufzubauen, ohne etwas zurückzugeben.

Alle drei sahen sich sofortigen Community-Forks gegenüber. OpenTofu (Terraform) erschien innerhalb weniger Wochen nach HashiCorps Ankündigung, unterstützt von der Linux Foundation. Valkey (Redis) startete im März 2024, ebenfalls unter der Linux Foundation, mit Commits von Ingenieuren von AWS, Google, Oracle und Alibaba. OpenSearch (Elasticsearch) war bereits 2021 gestartet, angeführt von AWS. Das Muster ist konsistent genug, um ein Drehbuch zu bilden – für beide Seiten.

Was die Lizenzänderungen tatsächlich bewirken

Die Business Source License (BSL), entwickelt von MariaDB und übernommen von HashiCorp, erlaubt die kostenlose Nutzung für die meisten Zwecke, verbietet jedoch die Nutzung der Software in einem konkurrierenden kommerziellen Produkt ohne eine kommerzielle Lizenz. Entscheidend ist, dass BSL-lizenzierte Software nach vier Jahren in eine Open-Source-Lizenz (normalerweise Apache 2.0) umgewandelt wird. HashiCorp setzte ein vierjähriges Konvertierungsfenster: Terraform 1.6, veröffentlicht im August 2023, würde im August 2027 zu Apache 2.0 werden.

SSPL, erstellt von MongoDB, ist aggressiver: Es verlangt, dass jeder, der die Software als Managed Service anbietet, den gesamten Stack, der zur Bereitstellung dieses Dienstes verwendet wird, einschließlich Orchestrierung, Überwachung und unterstützender Infrastruktur, als Open Source veröffentlichen muss. Da dies für einen Cloud-Anbieter mit proprietärer Infrastruktur praktisch unmöglich ist, fungiert SSPL als praktisches Verbot, Managed Services anzubieten. Die Open Source Initiative erkennt SSPL nicht als Open-Source-Lizenz an. Auch die Free Software Foundation tut dies nicht. Sowohl Redis als auch Elasticsearch unter SSPL sind nach den in der Branche wichtigsten Definitionen proprietäre Software, die zufällig ihren Quellcode veröffentlicht.

HashiCorp: Die darauf folgende Übernahme

Die kommerziell bedeutendste Entwicklung in dieser Geschichte ist, was mit HashiCorp nach der Lizenzänderung geschah. IBM übernahm HashiCorp im April 2024 für 6,4 Milliarden US-Dollar – eine der größten Übernahmen im Bereich Enterprise-Infrastruktursoftware. IBM betreibt Red Hat, das fast vollständig auf Open-Source-Software aufbaut und das weltweit größte Enterprise-Linux-Unternehmen ist. Die Übernahme von HashiCorp bringt Terraform, Vault, Consul und Nomad in IBMs Portfolio neben Red Hats OpenShift und Ansible.

Der OpenTofu-Fork erreichte unterdessen im Mai 2024 Version 1.7 und implementierte Funktionen, die Terraform noch nicht ausgeliefert hatte. Die Unterstützung der Linux Foundation bedeutet, dass OpenTofu institutionelle Unterstützung hat und wahrscheinlich nicht am Burnout der Maintainer scheitern wird – das Schicksal vieler Community-Forks. OpenTofu ist jetzt eine glaubwürdige langfristige Alternative zu Terraform für Organisationen, die sich mit den BSL-Beschränkungen oder IBMs Eigentum unwohl fühlen.

Die praktische Frage für Teams, die derzeit Terraform verwenden, ist einfach: Wenn Sie Terraform nicht kommerziell als Dienstleistung anbieten und nicht bei einem Cloud-Anbieter sind, schränkt BSL Sie nicht ein. Die meisten Enterprise-Nutzer sind nicht betroffen. Die Lizenzänderung ist am wichtigsten für Unternehmen, die verwaltete Terraform-Dienste aufbauen möchten – und für sie ist OpenTofu der offensichtliche Weg.

Redis: Der Fork, der sich am schnellsten bewegte

Die Redis-Lizenzänderung war die dramatischste in Bezug auf Geschwindigkeit und Breite der Reaktion. Innerhalb einer Woche nach der Ankündigung im März 2024 hatten AWS, Google Cloud, Oracle und Alibaba Cloud alle Ingenieursressourcen für Valkey bereitgestellt – einen Linux Foundation Fork von Redis 7.2.4, der letzten Version unter der alten BSD-Lizenz. Das Valkey GitHub-Repository hatte in seinem ersten Monat mehr Mitwirkende als die meisten Open-Source-Projekte in Jahren ansammeln.

Redis Ltd. (das Unternehmen, zu unterscheiden vom Redis-Projekt) hat darauf bestanden, dass Redis nie wirklich "Community Open Source" im gleichen Sinne wie Linux oder PostgreSQL war – es wurde immer vom Unternehmen kontrolliert. Dies ist technisch korrekt: Redis Ltd. besaß das Urheberrecht, verlangte eine CLA für Beiträge und traf alle wichtigen architektonischen Entscheidungen. Die BSD-Lizenz war eine geschäftliche Entscheidung, kein Gründungsprinzip. Als sich die Geschäftsrechnung änderte – insbesondere als AWS ElastiCache und andere verwaltete Redis-Dienste groß genug wurden, um Redis Ltd.s adressierbaren Markt spürbar zu verkleinern – änderte sich die Lizenz.

Valkey 7.2 ist jetzt das standardmäßige Redis-kompatible Angebot auf mehreren großen Cloud-Plattformen. Für neue Projekte, die heute starten, ist die praktische Wahl zwischen Valkey (Linux Foundation, Apache 2.0, Cloud-native Unterstützung) und Redis 7.4+ (SSPL, Redis Ltd., kommerzielle Lizenzierung für Managed Services). Beide sind ausgereift, beide leistungsstark, und die API ist nahezu identisch. Das Ökosystem spaltet sich.

Elastic: Der ältere Fall, der jetzt wie die Vorlage aussieht

Elastics Lizenzänderung von 2021 war der früheste und in gewisser Weise der klarste Fall. Elastic stellte Elasticsearch und Kibana auf SSPL um, als direkte Reaktion darauf, dass Amazon einen verwalteten Elasticsearch-Dienst anbot – Amazon Elasticsearch Service – ohne wesentliche Beiträge zum Projekt. Die Antwort von Amazon war, Elasticsearch 7.10 (die letzte Apache 2.0-Version) zu forken und OpenSearch zu erstellen, das es jetzt pflegt und an die Linux Foundation übergeben hat.

Vier Jahre später hat sich OpenSearch deutlich von Elasticsearch unterschieden. AWS liefert Funktionen in OpenSearch aus, die kein Elastic-Äquivalent haben, und Elastic hat Funktionen in Elasticsearch ausgeliefert, die nicht in OpenSearch sind. Die beiden sind für fortgeschrittene Anwendungsfälle nicht mehr ohne weiteres kompatibel. Teams, die heute zwischen ihnen wählen, entscheiden sich effektiv zwischen zwei verschiedenen Produkten, die einen gemeinsamen Vorfahren haben, nicht zwischen "dem Original" und "einem Fork."

Das Open-Core-Modell und seine Grenzen

Die Unternehmen, die dieser Dynamik am erfolgreichsten entgangen sind, sind diejenigen, die von Anfang an Open-Core-Modelle aufgebaut haben, anstatt sich auf permissive Lizenzen für beliebte Produkte zu verlassen, die sie später monetarisieren wollten. GitLab, Grafana und HashiCorps eigenes Vault sind Beispiele, bei denen das Kernprodukt Open Source ist, aber wesentliche Enterprise-Funktionen (SSO, Audit-Logging, erweiterte RBAC, Compliance-Tools) nur kommerziell erhältlich sind. Dies schafft eine klare Wertschöpfung, ohne die Community-Nutzung einzuschränken, die die Akzeptanz fördert.

Der Weg der Lizenzänderung – Veröffentlichung unter einer permissiven Lizenz, Aufbau massiver Akzeptanz, dann Wechsel zu einer restriktiveren Lizenz, sobald ein Cloud-Anbieter konkurriert – wird zunehmend als Einbahnstraße angesehen. Sobald ein Community-Fork existiert und institutionelle Unterstützung hat, hat das ursprüngliche Projekt das Community-Wohlwollen verloren, das die permissive Lizenzierung generierte. Es bleibt das kommerzielle Geschäft, aber ohne die Positionierung als "Open-Source-Projekt, das jeder nutzt", die es angetrieben hat.

Für Entwickler und Infrastrukturteams lautet die praktische Schlussfolgerung: Behandeln Sie jedes Open-Source-Projekt, das von einem einzigen Unternehmen kontrolliert wird und eine CLA-Anforderung hat, als potenziell proprietär. Die Lizenz, die Sie heute sehen, ist möglicherweise nicht die Lizenz, die die Software in drei Jahren regelt. Die sicherste Open-Source-Software aus Sicht des Lizenzrisikos gehört einer Stiftung (Linux Foundation, Apache Software Foundation, CNCF) oder hat eine echte verteilte Governance anstelle der Kontrolle durch ein einzelnes Unternehmen.

Was als Nächstes kommt

Die Lizenzkriege sind noch nicht vorbei. Mehrere andere weit verbreitete Infrastrukturprojekte – gepflegt von gut finanzierten Unternehmen mit Konkurrenz durch Cloud-Anbieter – stehen vor ähnlichen Dynamiken. Die Unternehmen haben beobachtet, was mit HashiCorp, Redis und Elastic passiert ist, und treffen Lizenzentscheidungen entsprechend.

Ein aufkommendes Modell: Dual Licensing von Anfang an, bei dem die Software sowohl unter einer Open-Source-Lizenz für die Community-Nutzung als auch unter einer kommerziellen Lizenz für die produktive Enterprise-Nutzung verfügbar ist, mit klaren Grenzen, die sich nicht rückwirkend verschieben. Ein weiteres: Stiftungseigentum von Anfang an, ohne dass ein einzelnes Unternehmen die Lizenz kontrolliert. Keines der beiden Modelle löst die grundlegende Spannung zwischen Open-Source-Adoptionsdynamik und kommerzieller Software-Monetarisierung perfekt – aber beide vermeiden den Vertrauensschaden, der durch die Änderung von Lizenzen entsteht, nachdem die Community bereits auf Ihrer Software aufgebaut hat.