Ein Lizenzwechsel kostet dich eine Migration. Die Rücknahme der Lizenz erstattet sie dir nicht zurück.

Warum ein Lizenzwechsel kein Rechtsthema ist

In den meisten Unternehmen sitzt die Lizenzprüfung am Ende der Kette. Ein Scanner läuft im Build, wirft eine Komponentenliste aus, jemand prüft, ob etwas Copyleft-Pflichtiges ins ausgelieferte Produkt gerutscht ist, und damit gilt das Thema als erledigt. Diese Prüfung beantwortet eine einzige Frage: Darf ich das heute so ausliefern.

Sie beantwortet nicht die Frage, die teuer wird. Die lautet: Wer kann die Bedingungen dieser Komponente einseitig ändern, und was kostet mich diese Änderung, wenn sie kommt.

Am 10. August 2023 hat HashiCorp diese zweite Frage für eine ganze Werkzeugklasse beantwortet. Das Unternehmen kündigte an, alle künftigen Releases seiner Kernprodukte von der MPL 2.0 auf die Business Source License 1.1 umzustellen: Terraform, Vault, Consul, Boundary, Nomad, Waypoint, Packer und Vagrant. APIs, SDKs und nahezu alle übrigen Bibliotheken blieben unter MPL 2.0.

Entscheidend ist, was dabei nicht passierte. Die Umstellung wirkte nicht rückwirkend. Die Lizenzdatei im Terraform-Repository nennt als lizenziertes Werk Terraform ab Version 1.6.0. Alles bis einschließlich 1.5.x bleibt MPL 2.0. Wer im August 2023 nichts tat, hatte kein akutes Problem. Er hatte ein Datum, ab dem jedes Update eines war.

Und in derselben Datei steht heute noch etwas anderes: Als Licensor ist die International Business Machines Corporation eingetragen, mit einem Copyright-Vermerk von 2024 für IBM Corp. IBM schloss die Übernahme von HashiCorp am 27. Februar 2025 ab, bei einem Unternehmenswert von 6,4 Mrd. USD und 35 USD je Aktie in bar. Die Partei, die über die Nutzungsbedingungen deiner Infrastrukturwerkzeuge entscheidet, hat also nach der Relizenzierung noch einmal den Eigentümer gewechselt.

Die Eigentümerkette

Zwischen Ankündigung und heute liegen zwei Ereignisse, die dieselbe Komponente betreffen: die Relizenzierung am 10. August 2023 und der Eigentümerwechsel am 27. Februar 2025. Wer 2023 bewertet hat, wem er vertraut, hat 2025 einen anderen Vertragspartner bekommen, ohne dass sich an seinem Build etwas geändert hätte. Lizenzrisiko ist deshalb kein einmaliger Prüfpunkt, sondern eine laufende Beobachtung.

Was BSL, SSPL und Elastic License tatsächlich regeln

Die drei Lizenzen, die MIT und Apache im Infrastrukturbereich verdrängen, funktionieren unterschiedlich, und die Unterschiede sind für die Risikobewertung relevant.

Die BSL 1.1 ist ausdrücklich keine Open-Source-Lizenz. Sie enthält aber einen eingebauten Verfallsmechanismus: Jede Version wandelt sich am festgelegten Change Date in eine offene Lizenz um, spätestens am vierten Jahrestag ihrer ersten öffentlichen Verbreitung, je nachdem, was früher eintritt. Als Change License schreibt der Lizenztext die GPL 2.0 oder eine GPL-kompatible Lizenz vor. Die häufig zitierten vier Jahre sind also keine Kulanz des Anbieters, sondern die vertragliche Obergrenze. Für Terraform ist als Change Date die Vier-Jahres-Frist ab Veröffentlichung eingetragen, als Change License die MPL 2.0.

Die SSPL hat diesen Mechanismus nicht. Die Open Source Initiative stellte am 19. Januar 2021 fest, dass die SSPL keine Open-Source-Lizenz ist. Sie wurde vom Lizenzgeber aus dem Genehmigungsverfahren zurückgezogen, als absehbar war, dass sie nicht genehmigt würde. Die OSI bezeichnet solche Lizenzen als “fauxpen source”.

Die Elastic License 2.0 ist die dritte Variante in diesem Feld und für Anwender die praktisch folgenreichste, weil unter ihr bis heute die standardmäßig herunterladbaren Elasticsearch-Distributionen ausgeliefert werden.

Wo die Risikoschwelle für Anwender wirklich liegt

Die praktisch wichtigste Passage steht nicht im Lizenztext, sondern in der begleitenden FAQ. Redis definiert das auslösende Merkmal als kommerzielles Konkurrenzangebot: ein an Dritte verkauftes Produkt, das aus der Codebasis abgeleitet ist und sich erheblich mit einem kommerziellen Produkt des Anbieters überschneidet. Die interne Bereitstellung als Dienst innerhalb der eigenen Organisation einschließlich Tochtergesellschaften bleibt ausdrücklich erlaubt.

Das ist die eigentliche Risikoschwelle, und sie verläuft quer durch die meisten Unternehmen. Für den internen Betrieb ändert eine solche Lizenz wenig. Für jedes Produkt, das du an Kunden verkaufst und in dem die Komponente steckt, ändert sie alles. Genau diese Grenze verläuft in vielen Architekturen unsichtbar, weil dieselbe Komponente in beiden Kontexten läuft.

Warum das Einfrieren der Altversion ein Ablaufdatum hat

Die naheliegende Antwort auf eine Relizenzierung ist, auf der letzten offen lizenzierten Version stehen zu bleiben. Das funktioniert, aber nur befristet. Redis sicherte Sicherheits-Backports auf die BSD-lizenzierten Altversionen ausdrücklich nur bis zum Release der Redis Community Edition 9.0 zu. Patches danach erscheinen unter der neuen Doppellizenz.

Damit ist der Mechanismus benannt, der jede Einfrier-Strategie aufzehrt: Nicht die Lizenz zwingt zum Wechsel, sondern die erste Schwachstelle, für die es keinen Patch mehr unter der alten Lizenz gibt.

Drei Relizenzierungen, vier Forks

Projekt	Vorher	Neu	Datum	Fork	Stiftungsdach	Spätere Öffnung
Elasticsearch	Apache 2.0	SSPL + Elastic License	14.01.2021	OpenSearch	OpenSearch Software Foundation (LF) seit 16.09.2024	AGPL als dritte Option, 29.08.2024
Terraform	MPL 2.0	BSL 1.1	10.08.2023	OpenTofu	Linux Foundation seit 20.09.2023, CNCF Sandbox seit 23.04.2025	keine
Vault	MPL 2.0	BSL 1.1	10.08.2023	OpenBao	OpenSSF Sandbox seit 17.06.2025	keine
Redis	BSD 3-Clause	RSALv2 + SSPLv1	20.03.2024	Valkey	Linux Foundation seit 28.03.2024	AGPLv3 als Option, 01.05.2025

Das Muster ist in allen vier Zeilen identisch: Auf die Relizenzierung folgt binnen Wochen ein Fork der letzten offen lizenzierten Version, und dieser Fork sucht sich unmittelbar ein Stiftungsdach. Valkey wurde am 28. März 2024 angekündigt, acht Tage nach der Redis-Ankündigung, unter BSD 3-Clause, aufsetzend auf Redis 7.2.4, mit AWS, Google Cloud, Oracle, Ericsson und Snap Inc. als Unterstützern.

Warum die spätere Öffnung die Migration nicht zurückholt

Zwei der drei Anbieter haben ihre Entscheidung später teilweise korrigiert. Das ist der interessanteste Teil des Vorgangs, weil er zeigt, wie asymmetrisch diese Kosten verteilt sind.

Elastic ergänzte am 29. August 2024 die AGPL als dritte Lizenzoption neben ELv2 und SSPL. Der Beitrag nennt OpenSearch nicht beim Namen, sondern spricht von einem Fork “with a different name and a different trajectory”. Und die Öffnung ist enger, als die Überschrift nahelegt: Nach Elastics eigener Lizenz-FAQ gilt die AGPL für den Quellcode ab Version 8.16, während die standardmäßig herunterladbaren Distributionen weiterhin unter der Elastic License 2.0 stehen. Die Rückkehr betrifft die Quellcode-Option, nicht das ausgelieferte Standardartefakt.

Der Effekt auf den Fork war das Gegenteil einer Rückwanderung. Im ersten Jahr der OpenSearch Software Foundation, das die AGPL-Ankündigung einschließt, stiegen die OpenSearch-Downloads um 78 Prozent im Jahresvergleich auf über 1 Mrd., bei mehr als 8.800 Beiträgen aus über 400 aktiven Organisationen, 16 Mitgliedsorganisationen und einem fünfzehnköpfigen Technical Steering Committee. Fünf Jahre nach dem Fork überschritt das Projekt 2026 die Marke von 2 Mrd. Downloads; eine Untersuchung von Linux Foundation Research nennt 77 Prozent der Befragten, die OpenSearch als wichtige Kern- oder Unterstützungskomponente für KI-Anwendungen sehen.

Bei Redis verlief es analog. Am 1. Mai 2025 kam AGPLv3 als zusätzliche Option hinzu, beginnend mit Redis 8. RSALv2 und SSPLv1 blieben bestehen, die AGPL ist eine Option, kein Ersatz. Valkey entwickelte danach eigenständig weiter: Version 9.0 wurde am 21. Oktober 2025 allgemein verfügbar, unter Linux-Foundation-Governance, mit bis zu 40 Prozent höherem Durchsatz gegenüber 8.1, bis zu 2.000 Knoten und über 1 Mrd. Requests pro Sekunde.

Dazu kommt eine Schicht, die sich einer Anbieterentscheidung vollständig entzieht. Fedora ersetzte Redis ab Fedora Linux 41 systemweit durch Valkey, ausdrücklich wegen der SSPL, die die Lizenzrichtlinien der Distribution nicht zulassen. Bestehende Installationen wurden beim Upgrade über ein Kompatibilitätspaket automatisch migriert. Wenn eine Distribution einmal den Standard umgestellt hat, entscheidet nicht mehr dein Architekturteam, was auf einem neu ausgerollten Host landet.

Und schließlich hat der Fork einen Preis bekommen. AWS bepreist ElastiCache for Valkey 33 Prozent niedriger im Serverless-Modus und 20 Prozent niedriger bei knotenbasierten Clustern als die übrigen unterstützten Engines, bei 90 Prozent geringerem Mindestdatenvolumen und einem Einstieg ab rund 6 USD pro Monat. Damit ist die Migration für den Einkauf nicht mehr nur ein Lizenz-, sondern ein Kostenargument. Eine Rückmigration müsste gegen beides argumentieren.

Ein sauberer Negativbeweis ist das nicht. Niemand kann belegen, dass kein einziger Nutzer zurückgewechselt ist. Belegbar sind die Indizien, und sie zeigen alle in dieselbe Richtung: eigenständige Fork-Releases nach der Öffnung, unveränderte Distributions-Standards, wachsende Download-Zahlen, ein struktureller Preisvorteil. Für eine Risikobewertung reicht das. Der Punkt ist nicht, dass eine Rückkehr unmöglich wäre. Der Punkt ist, dass sie ein zweites Migrationsbudget kostet, das niemand freigibt.

Warum Stiftungs-Governance ein hartes Auswahlkriterium ist

Wer die vier Zeilen der Tabelle nebeneinanderlegt, sieht den eigentlichen Unterschied nicht in der Lizenz, sondern in der Struktur, die über sie entscheidet. Eine Kapitalgesellschaft mit vollständiger Rechteinhaberschaft kann relizenzieren, wann sie will. Eine Stiftung mit Mitgliederstruktur kann das praktisch nicht, weil dieselbe Entscheidung dort Konsens zwischen konkurrierenden Unternehmen erfordert.

Genau deshalb ging der Weg der Forks nicht über Community-Repositories, sondern über Stiftungen. OpenTofu wurde am 20. September 2023 als Projekt der Linux Foundation aufgenommen, unter MPL 2.0, mit Support-Zusagen von mehr als 140 Organisationen und über 600 Einzelpersonen sowie mindestens 18 Vollzeitentwicklern über mindestens fünf Jahre. Am 23. April 2025 kam die Aufnahme als CNCF-Projekt auf Sandbox-Stufe dazu. Die OpenSearch Software Foundation wurde am 16. September 2024 unter der Linux Foundation gegründet, AWS übertrug das Projekt; genannt wurden damals über 700 Mio. Downloads und über 200 Projekt-Maintainer, mit AWS, SAP, Uber, Aiven, Atlassian, Canonical, DigitalOcean und NetApp Instaclustr unter den Gründungsmitgliedern. OpenBao, der Fork von Vault, wurde zunächst unter LF Edge entwickelt und ist seit dem 17. Juni 2025 Sandbox-Projekt der OpenSSF, unter anderem im Einsatz als Secret Store von EdgeX Foundry.

Dass diese Struktur mehr ist als eine Geste, zeigte der Konflikt danach. HashiCorp stellte OpenTofu am 3. April 2024 eine Unterlassungsaufforderung wegen der behaupteten Übernahme BSL-lizenzierten Codes zu. OpenTofu wies die Vorwürfe am 11. April 2024 öffentlich und vollständig zurück, ein Vorgang, den auch die Fachpresse dokumentierte. Ein Fork ohne institutionellen Rückhalt hätte diesen Brief mit den Mitteln eines Freizeitprojekts beantworten müssen.

Seit Ende 2024 hat dieses Kriterium zusätzlich eine regulatorische Anschlussstelle. Der EU Cyber Resilience Act, Verordnung (EU) 2024/2847, ist seit dem 10. Dezember 2024 in Kraft; die Notifizierung von Konformitätsbewertungsstellen gilt ab dem 11. Juni 2026, die Meldepflichten nach Artikel 14 ab dem 11. September 2026 und die Hauptpflichten ab dem 11. Dezember 2027. Artikel 24 schafft dabei die neue Kategorie des Open-Source-Software-Stewards: juristische Personen, die die Entwicklung freier und quelloffener Software für kommerzielle Zwecke dauerhaft und systematisch unterstützen. Stewards müssen eine Cybersicherheitspolitik führen, Schwachstellen behandeln und aktiv ausgenutzte Schwachstellen melden, unterliegen aber keinen Bußgeldern. Damit sind Stiftungsdächer nicht nur governance-politisch, sondern auch regulatorisch eine benennbare Rolle in deiner Lieferkette.

Wie du das im kritischen Pfad bewertest

Die Bewertung gehört nicht in ein Compliance-Dokument, sondern in dieselbe Liste wie deine Anbieterrisiken. Praktisch heißt das: eine kurze Menge von Komponenten, die Produktion bauen, deployen oder betreiben, und für jede von ihnen eine Aussage darüber, wer die Bedingungen ändern kann.

# dependency-policy.yml
# Bewertet wird nicht die Lizenz von heute, sondern wer sie morgen ändern kann.

critical_path:
  # Alles, was Produktion baut, deployt oder betreibt
  - terraform
  - vault
  - redis
  - elasticsearch

license_class:
  open:             [MPL-2.0, Apache-2.0, BSD-3-Clause, MIT, AGPL-3.0]
  source_available: [BUSL-1.1, SSPL-1.0, Elastic-2.0, RSAL-2.0, FSL-1.1-Apache-2.0]

governance:
  single_owner: review_required   # Ein Eigentümer, eine Entscheidung
  foundation:   allow             # Linux Foundation, CNCF, OpenSSF

require_for_critical_path:
  exit_path_documented:    true   # Kompatibler Ersatz benannt und getestet
  license_file_watched:    true   # Diff auf die LICENSE im Upstream
  upstream_owner_recorded: true   # Rechtsträger, nicht Markenname
  resale_exposure_flagged: true   # Steckt die Komponente in einem verkauften Produkt

Die dritte Zeile im unteren Block ist die, die am seltensten existiert. Der Rechtsträger ändert sich bei Übernahmen, der Markenname nicht. Wer in seiner Komponentenliste HashiCorp stehen hat, hat den Stand von 2024 dokumentiert.

Der einzige zuverlässige Frühindikator ist die Lizenzdatei selbst. Sie ändert sich im Repository, bevor eine Pressemitteilung erscheint, und sie lässt sich kontinuierlich beobachten:

# Läuft nächtlich, nicht im Release-Build
for repo in hashicorp/terraform redis/redis elastic/elasticsearch; do
  curl -sSf "https://raw.githubusercontent.com/$repo/main/LICENSE" \
    | shasum -a 256 | awk -v r="$repo" '{print r, $1}'
done > licenses.now

diff licenses.baseline licenses.now \
  || notify "LICENSE im Upstream geändert, Prüfung auslösen"

Diese Prüfliste beantwortet dann fünf Fragen, und zwar bevor eine Ankündigung kommt:

Prüffrage	Grüne Flagge	Rote Flagge
Wer hält die Rechte?	Stiftung mit Mitgliederstruktur und Governance-Dokument	Eine Gesellschaft mit Rechteübertragung über alle Beiträge
Was passiert bei einer Übernahme?	Governance überdauert den Eigentümer	Lizenzentscheidung folgt dem Eigentümer, wie bei Terraform
Gibt es einen kompatiblen Fork?	Aktiver Fork unter Stiftungsdach, mit Finanzierungszusage	Kein Fork, oder ein Fork ohne institutionellen Rückhalt
Wie lange trägt die Altversion?	Sicherheits-Backports zugesagt und terminiert	Backports enden mit dem nächsten Major, wie bei Redis CE 9.0
Wo sitzt die Nutzung?	Ausschließlich intern, keine Weitergabe an Dritte	Bestandteil eines Produkts, das du verkaufst

Wer diese fünf Spalten für seine zehn wichtigsten Abhängigkeiten füllt, hat mehr Aussagekraft als jeder vollständige Lizenzscan über 4.000 transitive Pakete. Die Bewertung gehört an dieselbe Stelle wie die Frage, welche Anbieter du überhaupt in den kritischen Pfad lässt.

Wie ein Ausstiegspfad aussieht, bevor du ihn brauchst

Ein Ausstiegspfad ist kein Dokument, sondern ein getesteter Zustand. Er hat drei Stufen, und die dritte ist die, die üblicherweise fehlt.

Erstens: benennen. Für jede Komponente im kritischen Pfad ein Ersatzkandidat mit Namen. In den vier Fällen dieser Betrachtung existiert er jeweils und ist schnittstellenkompatibel zur letzten offen lizenzierten Version, weil genau daraus geforkt wurde.

Zweitens: testen. Der Ersatz läuft in der Continuous Integration mit, nicht in einer Notfallübung. Eine Konfigurationssprache, die auf zwei Implementierungen läuft, ist ein anderes Risiko als eine, bei der niemand je die zweite ausprobiert hat. Praktisch ist das eine Integrationsaufgabe, keine Migration: eine zweite Pipeline-Variante, die nichts deployt, sondern nur beweist, dass sie es könnte.

Drittens: den Auslöser definieren. Nicht “wir schauen uns das an, wenn es soweit ist”, sondern eine benannte Bedingung. Zwei taugen dafür: das Ende der Sicherheits-Backports für die letzte offen lizenzierte Version, und der Moment, in dem die Komponente in ein Produkt wandert, das du an Dritte verkaufst. Beides ist beobachtbar, beides kommt mit Vorlauf, und beides lässt sich an dieselbe Stelle hängen, an der du ohnehin eigene Komponenten baust statt zu mieten.

Der Aufwand dafür ist gering, solange kein Anlass besteht. Genau das ist der Grund, warum er dann nicht betrieben wird.

Was nach der BSL kommt

Die BSL ist nicht der Endpunkt dieser Entwicklung. Sentry veröffentlichte am 17. November 2023 die Functional Source License als BSL-Nachfolgemodell: nur zwei Jahre Umwandlungsfrist statt vier, automatischer Übergang auf Apache 2.0 oder MIT und kein Additional Use Grant, dessen Mehrdeutigkeit an der BSL kritisiert worden war. Sentry und Codecov wurden darunter relizenziert.

Für die Bewertung heißt das zweierlei. Die Fristen werden kürzer, die Umwandlung wird verlässlicher. Aber der strukturelle Punkt bleibt derselbe: Auch eine gut gebaute Quelloffen-mit-Einschränkung-Lizenz ist eine einseitige Entscheidung eines einzelnen Rechtsträgers. Was sich verbessert, ist die Vorhersagbarkeit der Bedingungen, nicht die Verteilung der Entscheidungsmacht.

Was du diese Woche entscheiden musst

Die Frage ist nicht, ob du quelloffene Software einsetzt. Die Frage ist, wie viele Komponenten in deinem kritischen Pfad einen einzelnen Rechtsträger haben, der ihre Bedingungen einseitig ändern kann, und ob du für diese Komponenten einen Pfad hast, der schon einmal gelaufen ist.

Drei Festlegungen reichen für den Anfang. Erstens: eine Liste der Komponenten, die Produktion bauen, deployen oder betreiben, mit dem Rechtsträger statt dem Markennamen. Zweitens: eine automatische Beobachtung der Lizenzdateien dieser Komponenten, damit der Anstoß aus dem Repository kommt und nicht aus einem Blogbeitrag, den zufällig jemand liest. Drittens: für jede Komponente mit Einzeleigentümer ein benannter Ersatz, der in der Continuous Integration mitläuft.

Der Rest ist Buchhaltung. Wenn du wissen willst, wie diese Bewertung für eine bestehende Architektur konkret aussieht, sprich mit uns.

Quellen

Hinweis zur Quellenlage: Die Angaben zum Cyber Resilience Act stammen aus der offiziellen Zusammenfassung der Europäischen Kommission; der EUR-Lex-Volltext der Verordnung (EU) 2024/2847 war beim Abruf nicht auswertbar. Für rechtsverbindliche Aussagen ist ausschließlich die im Amtsblatt veröffentlichte Fassung maßgeblich, insbesondere die Artikel 3, 14, 24 und 71. Die Aussage, dass die spätere Lizenzöffnung keine Rückmigration ausgelöst hat, stützt sich auf die genannten Indizien und ist als Negativbeweis nicht führbar. Kursierende Adoptionszahlen zu OpenTofu sowie namentliche Anwenderangaben ließen sich nicht primär belegen und werden hier bewusst nicht verwendet. Dieser Artikel ist keine Rechtsberatung; für die Bewertung deiner konkreten Lizenzsituation ziehe qualifizierten Rechtsrat hinzu.

Kernaussagen