Lizenzwechsel als Lieferantenrisiko

Warum ein Lizenzwechsel kein Rechtsthema ist

In den meisten Unternehmen kommt die Lizenzprüfung ganz am Ende. Ein Werkzeug prüft beim Erstellen der Software die Liste der verwendeten Komponenten. Jemand schaut nach, ob etwas mit Copyleft-Pflichten in das ausgelieferte Produkt gerutscht ist. Copyleft heißt: Wer den Code weitergibt, muss seinen eigenen Code unter derselben Lizenz offenlegen. Danach gilt das Thema als erledigt. Diese Prüfung beantwortet genau eine Frage: Darf ich das heute so ausliefern.

Die teure Frage beantwortet sie nicht. Die lautet: Wer kann die Bedingungen dieser Komponente einseitig ändern und was kostet mich das, wenn es passiert.

Am 10. August 2023 hat HashiCorp diese zweite Frage für eine ganze Werkzeugklasse beantwortet. Das Unternehmen kündigte an, alle künftigen Versionen seiner Kernprodukte von der MPL 2.0 auf die Business Source License 1.1 umzustellen. Betroffen waren Terraform, Vault, Consul, Boundary, Nomad, Waypoint, Packer und Vagrant. Schnittstellen und 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 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.

In derselben Datei steht heute noch etwas anderes. Als Lizenzgeber ist die International Business Machines Corporation eingetragen. IBM schloss die Übernahme von HashiCorp am 27. Februar 2025 ab. Die Partei, die über die Nutzungsbedingungen deiner Infrastrukturwerkzeuge entscheidet, hat also nach dem Lizenzwechsel noch einmal den Eigentümer gewechselt.

Der Kern in einem Satz

Lizenzrisiko ist keine einmalige Prüfung, sondern eine laufende Beobachtung: Wer 2023 bewertet hat, wem er vertraut, hatte 2025 einen anderen Vertragspartner, ohne dass sich an seiner Software etwas geändert hätte.

Was BSL, SSPL und Elastic License regeln

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

Die BSL 1.1 ist ausdrücklich keine Open-Source-Lizenz. Die BSL hat aber ein eingebautes Verfallsdatum. Jede Version wandelt sich an einem festgelegten Stichtag in eine offene Lizenz um, spätestens vier Jahre nach ihrer ersten Veröffentlichung. Die oft zitierten vier Jahre sind also keine Kulanz des Anbieters, sondern die vertragliche Obergrenze. Für Terraform gilt die Vier-Jahres-Frist und als Ziellizenz 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. Der Lizenzgeber hatte sie aus dem Genehmigungsverfahren zurückgezogen, als absehbar war, dass sie nicht genehmigt würde.

Die Elastic License 2.0 ist die dritte Variante. Für Anwender ist sie die praktisch wichtigste, weil die standardmäßig herunterladbaren Elasticsearch-Pakete bis heute unter ihr ausgeliefert werden.

Wo die Risikoschwelle für Anwender liegt

Die wichtigste Passage steht nicht im Lizenztext, sondern in den begleitenden Fragen und Antworten. Redis definiert den Auslöser als kommerzielles Konkurrenzangebot: ein an Dritte verkauftes Produkt, das aus dem Code abgeleitet ist und sich erheblich mit einem Redis-Produkt überschneidet. Die interne Nutzung im eigenen Unternehmen 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 so eine Lizenz wenig. Für jedes Produkt, das du an Kunden verkaufst und in dem die Komponente steckt, ändert sie alles. In vielen Architekturen ist diese Grenze unsichtbar, weil dieselbe Komponente auf beiden Seiten läuft.

Warum das Einfrieren der Altversion ein Ablaufdatum hat

Die naheliegende Antwort auf einen Lizenzwechsel ist, auf der letzten offen lizenzierten Version stehen zu bleiben. Das funktioniert, aber nur befristet. Redis sagte Sicherheitsupdates für die BSD-lizenzierten Altversionen ausdrücklich nur bis zum Erscheinen der Redis Community Edition 9.0 zu. Alle 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 Sicherheitslücke, für die es keinen Patch mehr unter der alten Lizenz gibt.

Drei Lizenzwechsel, vier Abspaltungen

Auf jeden dieser Lizenzwechsel folgte ein Fork. Ein Fork ist eine Abspaltung des Quellcodes, die unter der alten Lizenz eigenständig weiterentwickelt wird.

Projekt	Lizenzwechsel	Abspaltung
Elasticsearch	Apache 2.0 zu SSPL und Elastic License, 14.01.2021	OpenSearch, seit 16.09.2024 unter der OpenSearch Software Foundation der Linux Foundation
Terraform	MPL 2.0 zu BSL 1.1, 10.08.2023	OpenTofu, seit 20.09.2023 bei der Linux Foundation, seit 23.04.2025 CNCF Sandbox
Vault	MPL 2.0 zu BSL 1.1, 10.08.2023	OpenBao, seit 17.06.2025 Sandbox-Projekt der OpenSSF
Redis	BSD 3-Clause zu RSALv2 und SSPLv1, 20.03.2024	Valkey, seit 28.03.2024 bei der Linux Foundation

Das Muster ist in allen vier Zeilen gleich. Auf den Lizenzwechsel folgt binnen Wochen eine Abspaltung der letzten offen lizenzierten Version und diese Abspaltung sucht sich sofort 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 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, weil er zeigt, wie ungleich diese Kosten verteilt sind.

Elastic ergänzte am 29. August 2024 die AGPL als dritte Lizenzoption. Die Öffnung ist enger, als die Überschrift nahelegt. Nach Elastics eigenen Lizenz-Antworten gilt die AGPL für den Quellcode ab Version 8.16. Die standardmäßig herunterladbaren Pakete stehen weiterhin unter der Elastic License 2.0. Die Rückkehr betrifft die Quellcode-Option, nicht das ausgelieferte Standardpaket.

Der Effekt auf die Abspaltung 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 auf über eine Milliarde. Nach Angaben der Stiftung kamen die Beiträge aus mehr als 400 Organisationen.

Bei Redis lief es ähnlich. Am 1. Mai 2025 kam AGPLv3 als zusätzliche Option hinzu, beginnend mit Redis 8. RSALv2 und SSPLv1 blieben bestehen. Valkey entwickelte danach eigenständig weiter: Version 9.0 erschien am 21. Oktober 2025 unter dem Dach der Linux Foundation.

Dazu kommt eine Ebene, die sich dem Anbieter ganz entzieht. Fedora ersetzte Redis ab Fedora Linux 41 systemweit durch Valkey, ausdrücklich wegen der SSPL, die die Lizenzregeln der Distribution nicht zulassen. Bestehende Installationen wurden beim Upgrade automatisch umgestellt. Wenn eine Distribution einmal den Standard gewechselt hat, entscheidet nicht mehr dein Team, was auf einem neu aufgesetzten Server landet.

Und die Abspaltung hat einen Preis bekommen. AWS bepreist seinen Valkey-Dienst niedriger als die übrigen Engines. Damit ist die Migration für den Einkauf nicht mehr nur ein Lizenzargument, sondern auch ein Kostenargument. Eine Rückmigration müsste gegen beides argumentieren.

Ein sauberer Beweis 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 Versionen der Abspaltung nach der Öffnung, unveränderte Standards in den Distributionen, wachsende Download-Zahlen, ein Preisvorteil. Für eine Risikobewertung reicht das. Eine Rückkehr ist nicht unmöglich, aber sie kostet ein zweites Migrationsbudget, das niemand freigibt.

Warum ein Stiftungsdach ein hartes Auswahlkriterium ist

Der eigentliche Unterschied liegt nicht in der Lizenz, sondern in der Struktur, die über sie entscheidet. Ein Unternehmen, das alle Rechte hält, kann die Lizenz ändern, wann es will. Eine Stiftung mit Mitgliedern kann das praktisch nicht, weil dieselbe Entscheidung dort Einigkeit zwischen konkurrierenden Firmen erfordert.

Genau deshalb gingen die Abspaltungen zu Stiftungen. OpenTofu wurde am 20. September 2023 als Projekt der Linux Foundation aufgenommen, unter MPL 2.0, mit Zusagen von mehr als 140 Organisationen. Am 23. April 2025 kam die Aufnahme in die CNCF auf Sandbox-Stufe dazu. Die OpenSearch Software Foundation wurde am 16. September 2024 unter der Linux Foundation gegründet, AWS übertrug das Projekt. OpenBao, die Abspaltung von Vault, ist seit dem 17. Juni 2025 Sandbox-Projekt der OpenSSF.

Dass diese Struktur mehr ist als eine Geste, zeigte der Konflikt danach. HashiCorp schickte OpenTofu am 3. April 2024 eine Unterlassungsaufforderung wegen angeblich übernommenen BSL-Codes. OpenTofu wies die Vorwürfe am 11. April 2024 öffentlich zurück und legte die Herkunft des Codes offen. Eine Abspaltung ohne 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 Cyber Resilience Act, Verordnung (EU) 2024/2847, ist seit dem 10. Dezember 2024 in Kraft. Die Meldepflichten nach Artikel 14 gelten ab dem 11. September 2026, die Hauptpflichten ab dem 11. Dezember 2027. Artikel 24 schafft die Rolle des Open-Source-Software-Stewards: juristische Personen, die die Entwicklung quelloffener Software für kommerzielle Zwecke dauerhaft unterstützen. Stewards müssen eine Sicherheitsrichtlinie führen, Schwachstellen behandeln und aktiv ausgenutzte Schwachstellen melden. Bußgelder drohen ihnen nicht. Damit ist ein Stiftungsdach nicht nur eine Frage der Governance, sondern 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 Liste der Komponenten, die deine Produktion erstellen, ausrollen oder betreiben. Für jede davon eine Aussage, wer die Bedingungen ändern kann.

critical_path: [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
  foundation: allow

require_for_critical_path:
  exit_path_documented: true
  license_file_watched: true
  upstream_owner_recorded: true
  resale_exposure_flagged: true

Die vier Anforderungen im letzten Block bedeuten: Ein kompatibler Ersatz ist benannt und getestet. Die Lizenzdatei des Projekts wird beobachtet. Der Rechtsträger ist erfasst, nicht der Markenname. Und es ist markiert, ob die Komponente in einem Produkt steckt, das du verkaufst.

Die dritte Anforderung 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. Die Datei ändert sich im Repository, bevor eine Pressemitteilung erscheint und sie lässt sich laufend beobachten. Ein kleines Skript, das nachts läuft, reicht dafür:

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"

Deine Prüfliste beantwortet dann fünf Fragen, bevor eine Ankündigung kommt:

Prüffrage	Grün	Rot
Wer hält die Rechte?	Stiftung mit Mitgliedern und Governance-Dokument	Ein Unternehmen, dem alle Beiträge übertragen werden
Was passiert bei einer Übernahme?	Die Governance überdauert den Eigentümer	Die Lizenzentscheidung folgt dem Eigentümer, wie bei Terraform
Gibt es eine kompatible Abspaltung?	Aktiv, unter Stiftungsdach, mit Finanzierungszusage	Keine oder eine ohne institutionellen Rückhalt
Wie lange trägt die Altversion?	Sicherheitsupdates zugesagt und terminiert	Updates enden mit der nächsten Hauptversion, wie bei Redis
Wo sitzt die Nutzung?	Nur 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 ein vollständiger Lizenzscan über tausende 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 fehlt üblicherweise.

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

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

Drittens: den Auslöser festlegen. Nicht “wir schauen uns das an, wenn es soweit ist”, sondern eine benannte Bedingung. Zwei taugen dafür: das Ende der Sicherheitsupdates 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 und beides kommt mit Vorlauf.

Der Aufwand dafür ist gering, solange kein Anlass besteht. Genau deshalb wird er dann nicht betrieben.

Was nach der BSL kommt

Die BSL ist nicht der Endpunkt. Sentry veröffentlichte im November 2023 die Functional Source License als Nachfolgemodell: zwei Jahre Frist statt vier, automatischer Übergang auf Apache 2.0 oder MIT und kein zusätzlicher Nutzungsvorbehalt, dessen Mehrdeutigkeit an der BSL kritisiert worden war.

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

Was du jetzt prüfen kannst

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 Schritte reichen für den Anfang. Erstens: eine Liste der Komponenten, die Produktion erstellen, ausrollen 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 deinen Tests mitläuft.

Wie viel davon du brauchst, hängt von deinem Ausgangszustand ab. Wer nur intern betreibt und nichts weiterverkauft, kommt mit Liste und Beobachtung weit. Wenn du wissen willst, wie die Bewertung für deine Architektur aussieht, melde dich.

Hinweis

Dieser Artikel ist keine Rechtsberatung. Die Angaben zum Cyber Resilience Act stammen aus der Zusammenfassung der Europäischen Kommission, verbindlich ist nur der Text im Amtsblatt. Dass die spätere Öffnung keine Rückmigration ausgelöst hat, stützt sich auf Indizien und lässt sich nicht beweisen.

Ein Lizenzwechsel kostet dich eine Migration und die Rücknahme gibt sie dir nicht zurück

Kernaussagen