Source-Available License & Governance Risk Report 2026

Executive Summary

Source Code Access, Open Source, Source Available und kommerzielle Nutzbarkeit sind nicht dasselbe. Für die Beschaffung kritischer Software ist die Lizenz nur eine Ebene. Ebenso wichtig sind Governance, Marken- und Releasekontrolle, Patchkontinuität, Contributor-Basis, Build-Reproduzierbarkeit, Daten- und Protokollkompatibilität sowie die Existenz eines glaubwürdigen Fallbacks.

Dieser Report untersucht sechs bekannte Ökosysteme anhand eines offengelegten 100-Punkte-Risikomodells und ergänzt es um eine Ereignis-Timeline, eine License Bill of Materials (LBOM) und ein operatives Reaktionsmodell. Die Fallstudien umfassen MongoDB, HashiCorp/Terraform und OpenTofu, Redis und Valkey, Elasticsearch und OpenSearch, CockroachDB sowie das Business-Source-License-Referenzmodell von MariaDB.

Der Score bewertet Beschaffungs- und Kontinuitätsrisiko aus Sicht eines Nutzers. Er ist weder Rechtsgutachten noch moralisches Urteil über Anbieter. Ein hoher Wert kann bei einem kommerziellen Vertrag und gutem Exit-Plan vertretbar sein. Ein niedriger Wert ersetzt keine Lizenzprüfung.

Zitierfähige Kernergebnisse

1. [OBSERVED] Mehrere infrastrukturell relevante Projekte änderten in den vergangenen Jahren ihre Lizenz oder ergänzten neue Lizenzoptionen; daraus entstanden Forks, neue Stiftungsmodelle und veränderte Beschaffungsentscheidungen.
2. [CALCULATED] Im offengelegten Modell erreicht CockroachDB 24.3+ 72/100, MongoDB Community Server 63/100, Terraform/HashiCorp BSL 45/100, das MariaDB-BSL-Referenzmodell 42/100, Redis 38/100 und Elasticsearch 26/100. Höher bedeutet mehr modelliertes Beschaffungsrisiko, nicht schlechtere Software.
3. [OBSERVED] HashiCorp kündigte am 10. August 2023 den Wechsel künftiger Releases mehrerer Produkte von MPL 2.0 zu BSL 1.1 an; OpenTofu entstand als Community-/Foundation-Reaktion.
4. [OBSERVED] Redis wechselte 2024 von BSD-3-Clause für neue Versionen zu RSALv2/SSPLv1 und ergänzte mit Redis 8 im Mai 2025 AGPLv3 als weitere Option; Valkey entstand 2024 unter dem Dach der Linux Foundation.
5. [OBSERVED] Elastic ergänzte 2024 AGPLv3 als Option neben ELv2 und SSPL für relevante freie Quellcodeanteile. Eine spätere zusätzliche Option löscht die zwischenzeitliche Governance- und Forkgeschichte nicht.
6. [INTERPRETATION] Ein Fork ist nur dann ein belastbarer Exit, wenn Releases, Security Patches, Maintainer, Governance, Ecosystem-Kompatibilität und Migration praktisch funktionieren.
7. [RECOMMENDATION] Kritische Komponenten brauchen eine LBOM mit Lizenzversion, Change Date, Change License, Patchquelle, Forkoption, Datenformat, Upgrade-/Downgradepfad und verantwortlichem Owner.
8. [RECOMMENDATION] Beschaffung sollte vier Reaktionspfade vorab finanzieren: kommerzielle Lizenz akzeptieren, Version kontrolliert pinnen, Fork einsetzen oder migrieren.

---

1. Forschungsfrage und Scope

Wie lässt sich das Lieferanten- und Kontinuitätsrisiko einer source-available oder lizenzveränderten Infrastrukturkomponente messen, ohne Lizenzname und tatsächliche Exit-Fähigkeit zu verwechseln?

1.1 Bewertete Dimensionen

Dimension	Gewicht	Kernfrage
Lizenzwechselhistorie	20	Hat der Steward Rechte oder Bedingungen in relevantem Umfang geändert?
Field-of-Use-/Servicebeschränkung	20	Können bestimmte Geschäftsmodelle oder Managed Services eingeschränkt sein?
Governance-Konzentration	15	Wer kontrolliert Roadmap, Marken, Release und Merge?
Patchkontinuität	15	Kann der Nutzer Security- und Bugfixes unabhängig erhalten?
Fallback-Fork-Risiko	15	Existiert ein technisch und organisatorisch glaubwürdiger Fork?
keine zeitgesteuerte Open-Conversion	10	Gibt es einen verbindlichen Change Date oder bleibt die Einschränkung dauerhaft?
Klarheitsrisiko	5	Wie eindeutig sind Scope, Additional Use Grant und Ausnahmefälle?

1.2 Nicht bewertet

• Produktqualität, Performance oder Marktanteil;
• individuelle Rechtslage eines Nutzers;
• kommerzielle Rabatte oder Supportqualität;
• ideologische „Offenheit“;
• Wahrscheinlichkeit einer zukünftigen Lizenzänderung als statistische Prognose.

---

2. Empirische Basis und Fallstudien

2. Begriffe

Open Source

In diesem Report bezeichnet „Open Source“ Software unter einer von der Open Source Initiative anerkannten beziehungsweise mit der Open Source Definition vereinbaren Lizenz. Zentral ist, dass keine unzulässige Diskriminierung von Personen, Gruppen oder Einsatzfeldern erfolgt.

Source available

Der Quellcode ist einsehbar und möglicherweise modifizierbar, aber Nutzungsrechte enthalten Einschränkungen, die über klassische Open-Source-Lizenzen hinausgehen können.

BSL

Die Business Source License ist ein Source-available-Modell mit einer Change Date, nach der eine definierte Version automatisch unter eine Open-Source-Lizenz wechseln kann. Die konkrete Additional Use Grant bestimmt, was vor diesem Datum erlaubt ist.

Fork

Abspaltung eines Codebestands unter einer zulässigen früheren Lizenz. Ein Fork reduziert Risiko nur, wenn Governance, Maintainer, Release-Prozess, Security, Ecosystem und Adoption tragfähig sind.

Last Open Version

Letzte Version vor einem Lizenzwechsel, die unter der früheren Open-Source-Lizenz verbleibt. Sie ist rechtlich und technisch nicht dasselbe wie ein dauerhaft gepflegtes Produkt.

---

---

3. Methodik

3.1 Dimensionen

Der Score ist ein Risikoscore; höher bedeutet mehr Procurement-Risiko.

Code	Dimension	Gewicht
H	Historie abrupter Lizenzänderungen	20
F	Field-of-use-/Wettbewerbsbeschränkung	20
G	Konzentration der Governance	15
P	Kontinuität von Patches unter alter/offener Lizenz	15
K	Fehlen eines tragfähigen Forks/Fallbacks	15
T	Fehlen einer automatischen Open-Source-Conversion	10
C	Unklarheit/Komplexität der Bedingungen	5

Procurement-Risiko = H + F + G + P + K + T + C

3.2 Interpretation

Punkte	Band
0–24	niedrig
25–49	moderat
50–69	hoch
70–100	sehr hoch

3.3 Bewertungsgrenze

Die Analyse bezieht sich auf die öffentlich dokumentierte Situation am Datenstichtag. Sie bewertet keine individuelle Nutzung. Eine Aktivität kann unter einer Lizenz zulässig, unter einer anderen untersagt oder lizenzpflichtig sein. Das muss juristisch im konkreten Sachverhalt geprüft werden.

---

---

4. Ergebnis

Rang nach höherem Risiko	Ökosystem	Risiko / 100	Band
1	CockroachDB 24.3+	72	Sehr hoch
2	MongoDB Community Server	63	Hoch
3	Terraform / HashiCorp BSL	45	Moderat
4	MariaDB BSL reference model	42	Moderat
5	Redis	38	Moderat
6	Elasticsearch	26	Moderat

Vollständige Matrix

Ökosystem	H /20	F /20	G /15	P /15	K /15	T /10	C /5	Gesamt
CockroachDB 24.3+	15	15	12	8	8	10	4	72
MongoDB Community Server	15	15	10	8	2	10	3	63
Terraform / HashiCorp BSL	15	15	10	5	0	0	0	45
MariaDB BSL reference model	10	12	8	5	3	0	4	42
Redis	15	10	8	3	0	0	2	38
Elasticsearch	10	5	6	2	0	0	3	26

Maschinenlesbare Fassung:

data/FDR-2026-06_license_risk_scores.csv

Die Rangfolge ist keine Aussage darüber, welches Produkt technisch besser ist.

---

---

5. Fallstudien

5.1 MongoDB Community Server – 63 Punkte

MongoDB kündigte am 16. Oktober 2018 an, künftige Community-Server-Releases einschließlich bestimmter Patch-Releases von AGPLv3 auf die Server Side Public License umzustellen. Ziel war insbesondere, die Bereitstellung als Service zu adressieren.

Die OSI hat die SSPL nicht als Open-Source-Lizenz anerkannt und ordnet sie nicht als Open Source ein.

Procurement-Risiko

• Bestehende AGPL-Versionen bleiben unter ihrer Lizenz.
• Zukünftige Patches und Features folgen der neuen Lizenz.
• Nutzer müssen die eigene Betriebsform gegen die SSPL prüfen.
• Ein „wir hosten selbst“ ist nicht automatisch dieselbe Frage wie „wir bieten es Dritten als Service an“.
• Migration zu einer alternativen Document Database ist technisch nicht trivial.

[INTERPRETATION] Der zentrale Risikofaktor ist Patch Continuity: Ein altes Nutzungsrecht konserviert Code, aber nicht automatisch die zukünftige Wartungslinie.

5.2 Terraform / HashiCorp BSL – 45 Punkte

HashiCorp kündigte am 10. August 2023 an, künftige Releases seiner Kernprodukte von MPL 2.0 auf BSL 1.1 umzustellen. Die Additional Use Grant erlaubt breite Nutzung, schränkt aber wettbewerbliche Angebote ein.

Am 25. August 2023 kündigte die OpenTofu-Initiative den Fork von Terraform an. Dadurch entstand ein konkreter Fallback unter offener Governance.

Warum der Score nur moderat ist

Die Lizenzänderung und Wettbewerbsbeschränkung erhöhen Risiko. OpenTofu reduziert jedoch das Fork-Risiko erheblich:

• aktive eigenständige Releases,
• öffentliches Repository,
• Community- und Unternehmensunterstützung,
• Anschluss an bestehende Terraform-Artefakte,
• alternative Governance.

[INTERPRETATION] Ein belastbarer Fork kann das Risiko eines Lizenzwechsels schneller reduzieren als Vertragsklauseln allein. Er beseitigt aber nicht automatisch Provider-, Plugin- oder State-Kompatibilitätsfragen.

5.3 Redis – 38 Punkte

Redis kündigte 2024 an, Redis 7.4 und spätere Releases dual unter RSALv2 und SSPLv1 bereitzustellen; der Anbieter beschrieb diese Lizenzen als source available. Frühere BSD-Versionen blieben unverändert.

Im Mai 2025 ergänzte Redis AGPLv3 als dritte Lizenzoption. Parallel wurde Valkey unter dem Dach der Linux Foundation als offener Fork aufgebaut.

Risikowirkung

• Historischer Wechsel erhöht Governance-Risiko.
• AGPLv3 stellt wieder eine OSI-kompatible Open-Source-Option bereit.
• Valkey schafft einen tragfähigen Fallback.
• Ökosystem, Module, Distributionen und Cloud-Angebote können sich dennoch dauerhaft aufteilen.

[INTERPRETATION] Die Rückkehr einer offenen Lizenzoption reduziert aktuelles Lizenzrisiko. Sie setzt die organisatorische Geschichte nicht auf null.

5.4 Elasticsearch – 26 Punkte

Elastic hatte Elasticsearch und Kibana 2021 von Apache 2.0 auf Elastic License 2.0 und SSPL umgestellt. Im August 2024 kündigte das Unternehmen an, AGPLv3 als zusätzliche Option für den freien Quellcode hinzuzufügen.

Gleichzeitig existiert mit OpenSearch ein Fork und alternatives Ökosystem.

Einordnung

• Die AGPL-Option reduziert Field-of-use-Risiko für die entsprechend lizenzierten Teile.
• ELv2 und SSPL bleiben als Optionen bestehen.
• OpenSearch reduziert Abhängigkeit von einem einzelnen Sponsor.
• Feature-, Plugin- und API-Kompatibilität müssen trotzdem geprüft werden.

5.5 CockroachDB 24.3+ – 72 Punkte

Cockroach Labs dokumentiert für CockroachDB 24.3 und spätere Versionen die CockroachDB Software License. Die Bedingungen unterscheiden zwischen zulässiger freier Nutzung und lizenzpflichtigen Konstellationen; die Dokumentation nennt unter anderem Umsatz- und Nutzungsbedingungen.

Risikotreiber

• eigene sponsorzentrierte Lizenz,
• Bedingungen abhängig vom Organisations- und Nutzungskontext,
• kein gleichwertiger, breit etablierter Fork,
• kritische Datenbankfunktion,
• künftige Patch- und Featurelinie unter derselben Governance.

[INTERPRETATION] Je tiefer ein Produkt in Datenhaltung und Transaktionslogik sitzt, desto höher ist der wirtschaftliche Wert eines klaren Langzeit-Lizenzpfads.

5.6 MariaDB BSL reference model – 42 Punkte

MariaDB entwickelte die BSL als Modell, bei dem Source Code zunächst unter begrenzten Nutzungsrechten verfügbar ist und spätestens zu einem definierten Change Date unter eine Open-Source-Lizenz wechselt.

Dieser Eintrag bewertet das BSL-Muster, nicht pauschal jedes aktuelle MariaDB-Produkt.

Stärken

• automatische zeitliche Öffnung,
• Bedingungen und Change Date sichtbar,
• Quellcode verfügbar,
• Möglichkeit einer langfristig offenen Version.

Risiken

• vor dem Change Date können Produktions- oder Wettbewerbsnutzungen begrenzt sein,
• jede Implementierung besitzt eigene Additional Use Grants,
• Security- und Release-Zyklen können schneller sein als die Conversion,
• „wird in vier Jahren offen“ löst heutige Nutzungsfragen nicht.

---

---

6. Was ein Lizenzwechsel wirtschaftlich auslöst

6.1 Patch Gap

letzte offene Version
→ neue CVE
→ Patch nur in neuer Lizenzlinie
→ Freeze, Backport, Vertrag oder Migration

6.2 Governance Split

Maintainer, Cloud-Anbieter, Distributoren und Nutzer wählen unterschiedliche Linien. Das führt zu:

• doppelten Integrationen,
• divergierenden APIs,
• Marken- und Namenswechsel,
• unterschiedlicher Release-Geschwindigkeit,
• fragmentierter Dokumentation.

6.3 Procurement Delay

Legal, Engineering, Security und Einkauf müssen prüfen:

• aktuelle Nutzung,
• geplante Nutzung,
• Affiliate-Strukturen,
• Managed-Service-Angebote,
• Redistribution,
• Umsatz-/Unternehmensgrenzen,
• Support und Indemnification.

6.4 Migration Cost

Ein Lizenzwechsel erzeugt nicht automatisch einen technischen Wechsel. Aber er verändert die Optionsmenge und kann dadurch einen ungeplanten Migrations- oder Vertragswert erzeugen.

---

---

7. License Bill of Materials

[RECOMMENDATION] Neben einer SBOM sollte ein Unternehmen eine LBOM – License Bill of Materials führen.

Feld	Inhalt
Komponente	Produkt/Library
Version	produktive Version
Lizenz	SPDX-ID oder exakter Text
Lizenzquelle	stabile URL/Datei
Copyright Holder	Sponsor/Foundation
Change Date	bei BSL
Additional Use Grant	exakter Wortlaut
Nutzungsart	intern, SaaS, Redistribution
letzter offener Stand	Version/Commit
Fork	Name und Reife
Patch-Plan	Vendor, Community, intern
Owner	Legal + Engineering
Reviewdatum	nächster Termin

---

---

8. Vertrags- und Architekturmaßnahmen

Vor Aufnahme

1. Lizenztext speichern.
2. Nutzungsszenario schriftlich definieren.
3. offene und kommerzielle Funktionen trennen.
4. Last Open Version dokumentieren.
5. Datenexport testen.
6. Fork- und Replacement-Markt prüfen.
7. Patch-SLA definieren.
8. Lizenzänderungs-Notification verlangen.

Während des Betriebs

• Release Notes überwachen
• Lizenzdateien per CI diffen
• SBOM/LBOM aktualisieren
• kritische Forks beobachten
• Restore und Migration testen
• eigene Abstraktionsschichten nicht übertreiben, aber kritische Interfaces isolieren

Vertragsklauseln

• Mitteilungspflicht bei Lizenzänderung
• Fortnutzungsrecht für bestehende Version
• Security-Patch-Zugang
• Export- und Transition-Support
• Preis- und Renewal-Regeln
• Code Escrow, wo sinnvoll
• Daten- und Konfigurationsherausgabe

---

3. Ergebnisübersicht

Die vollständigen Rohwerte liegen in data/FDR-2026-06_license_risk_scores.csv. Der Score ist eine transparente Entscheidungshilfe. Er soll nicht ohne die einzelnen Dimensionen oder den konkreten Einsatzkontext zitiert werden.

4. Governance- und Fork-Fähigkeitsmodell

Ein Repository ist noch kein unabhängiger Lieferpfad. Für einen belastbaren Fork werden mindestens sechs Fähigkeiten benötigt.

Fähigkeit	minimale Evidenz	Red Flag
technische Build-Fähigkeit	reproduzierbare Builds, CI, Releases	Binärartefakte hängen von privaten Systemen ab
Security-Fähigkeit	CVE-Prozess, Advisories, koordinierte Patches	nur Upstream kann kritische Lücken schließen
Maintainer-Kapazität	mehrere aktive Maintainer/Organisationen	einzelner Sponsor oder Bus-Factor 1
Governance	dokumentierte Entscheidungen und Rollen	informelle Kontrolle ohne Eskalationsweg
Ecosystem-Kompatibilität	Clients, Provider, Plugins, Formate	Marken- oder API-Bruch ohne Migration
wirtschaftliche Tragfähigkeit	Finanzierung, Support oder breite Adoption	keine Mittel für langfristige Maintenance

4.1 Fork Maturity Levels

• F0 - theoretisch: Code kann kopiert werden, aber kein aktiver Releasepfad.
• F1 - buildbar: Community kann Artefakte erzeugen und grundlegende Tests ausführen.
• F2 - wartbar: unabhängige Fixes, Releases und Securityprozesse existieren.
• F3 - migrierbar: Daten, APIs und Integrationen haben dokumentierte Übergänge.
• F4 - ecosystemfähig: relevante Provider, Distributoren, Plugins und Nutzer tragen den Fork.
• F5 - institutionell: neutrale Governance, Finanzierung, transparente Roadmap und langfristige Releasefähigkeit.

Ein Fork unterhalb F2 ist kein belastbarer Produktionsfallback. Zwischen F2 und F4 kann er als taktische Brücke dienen. Erst F4/F5 reduziert strukturelle Abhängigkeit deutlich.

4.2 Patch Continuity Gap

Patch Continuity Gap =
Zeit bis Upstream-Sicherheitsfix
- Zeit bis nutzbarer Fix im gewählten Lieferpfad

Bei einer gepinnten Altversion kann der Wert unendlich werden, wenn keine Backports mehr erscheinen. Bei einem jungen Fork kann er in der Anfangsphase schwanken. Ein kommerzieller Vertrag kann den Gap reduzieren, wenn SLA, Security Advisories und Backports klar geregelt sind.

---

5. License Bill of Materials (LBOM)

Eine SBOM sagt, welche Komponenten und Versionen im Produkt stecken. Die LBOM ergänzt die rechtliche und lieferseitige Dimension.

5.1 Pflichtfelder

Feld	Zweck
component_name / version	exakte Identifikation
source_repository / distributor	tatsächlicher Lieferpfad
current_license / license_text_hash	geltende Bedingungen und Nachweis
previous_license	Veränderung sichtbar machen
change_date / change_license	zeitliche Umschaltlogik
additional_use_grant	relevante Ausnahme oder Erlaubnis
production_use	Einsatzumfang und Kritikalität
modified	eigene Änderungen und Copyleft-Relevanz
managed_service_exposure	mögliches Wettbewerbs-/Service-Risiko
patch_source	Upstream, Distributor, Fork oder intern
fallback_project	konkret benannter technischer Pfad
data_format / protocol	Migrationsfähigkeit
owner / legal_review_date	Verantwortlichkeit und Aktualität
decision_record	akzeptiertes Risiko und Reaktionsplan

Vorlage:

data/FDR-2026-06_LBOM_template.csv

5.2 Trigger für erneute Prüfung

• neue Major- oder Minor-Version;
• Änderung von LICENSE, FAQ oder Additional Use Grant;
• Eigentümerwechsel oder Akquisition;
• neuer Hosted-/Managed-Service-Fokus;
• Fork oder Foundation-Gründung;
• EOL oder geänderte Patchpolitik;
• Distribution wechselt Binär- oder Paketquelle;
• Produkt wird Teil eines regulierten oder kundenkritischen Systems.

5.3 Evidence Vault

Die aktuelle Lizenz-URL allein reicht nicht. Zu archivieren sind:

• Lizenztext und Hash;
• Version/Tag/Commit;
• FAQ und Anbieterankündigung;
• Beschaffungsentscheidung;
• Rechtsprüfung und Annahmen;
• Vertrag und Ausnahmen;
• technische Migrationstests;
• Patch- und EOL-Unterlagen.

Damit bleibt die Entscheidung nachvollziehbar, selbst wenn Webseiten später geändert werden.

---

6. Vier Reaktionspfade und ihre Ökonomie

Pfad A - Kommerzielle Lizenz akzeptieren

Sinnvoll, wenn: Produktwert und Support höher sind als Migrationskosten und Abhängigkeit vertraglich beherrschbar ist.

Zu verhandeln:

• klare Definition erlaubter Nutzung;
• Preis- und Renewal-Mechanik;
• Security- und Patch-SLA;
• Escrow oder Source/Build-Zugang, wo angemessen;
• Export- und Übergangsunterstützung;
• Change-of-Control- und EOL-Regeln;
• Haftung und Freistellung im vereinbarten Scope.

Risiko: Ein günstiger erster Vertrag kann bei wachsender Abhängigkeit teurer werden. Deshalb Exitkosten parallel messen.

Pfad B - Version kontrolliert pinnen

Sinnvoll, wenn: kurzfristig keine Migration möglich ist und die alte Lizenzversion rechtlich/technisch nutzbar bleibt.

Pflichtkosten:

• eigener Security-Backport;
• reproduzierbare Builds;
• isolierte Paketquelle;
• CVE-Monitoring;
• Kompatibilität mit Betriebssystem, Libraries und Clients;
• festes Enddatum für die Übergangslösung.

Risiko: Pinning wird leicht zu dauerhaftem Forking ohne Budget. Eine eingefrorene Version ist kein kostenloser Zustand.

Pfad C - Fork übernehmen

Sinnvoll, wenn: Fork mindestens F2/F3 erreicht, relevante Community und Migration existieren und Governance zum eigenen Risikoprofil passt.

Prüfung:

• Releasekadenz;
• Security Advisories;
• Maintainer und Sponsoren;
• API-/Datenkompatibilität;
• Upgrade- und Rollbackpfad;
• Provider-/Plugin-Ökosystem;
• Lizenz und Trademark.

Risiko: Der Fork kann technisch kompatibel, aber operativ unreif sein. Ein Proof of Migration ist Pflicht.

Pfad D - Auf andere Architektur migrieren

Sinnvoll, wenn: Abhängigkeit ohnehin hoch, Roadmap unpassend oder Daten-/Protokollstandards einen Wechsel ermöglichen.

Kostenblöcke:

Migration TCO =
Discovery + Build + Data Move + Dual Run + Validation + Training + Decommission

Risiko: Migration nur aus Lizenzsymbolik kann wirtschaftlich schlechter sein als ein sauberer kommerzieller Vertrag. Entscheidung auf Szenarien, nicht Emotionen stützen.

---

7. Quantitatives Entscheidungsschema

Für jede kritische Komponente werden drei Werte getrennt berechnet.

7.1 Exposure Score

Exposure =
Kritikalität × Einsatzbreite × Änderungs-/Service-Relevanz

7.2 Replaceability Score

Replaceability =
Datenportabilität + Protokollstandard + Fork-Reife + internes Wissen

7.3 Continuity Cost

Continuity Cost =
Commercial path
oder
Pinning/Backport
oder
Fork adoption
oder
Migration

Eine hohe Lizenzrisikozahl bei niedriger Kritikalität ist weniger dringlich als ein moderater Score in einem Kernsystem mit keinem realen Fallback.

7.4 Beispielmatrix

Komponente	Risiko	Kritikalität	Replaceability	Entscheidung
interne Dev-Datenbank	hoch	niedrig	hoch	beobachten / Testmigration
produktiver State Store	moderat	sehr hoch	mittel	Vertrag + Fork-Drill
IaC-Kern	moderat	sehr hoch	hoch	duale Kompatibilität und Exit-Test
Analytics-Suche	moderat	hoch	mittel	Datenformat und Reindex-Zeit messen

Die Zeilen sind ein methodisches Beispiel, keine Produktempfehlung.

---

8. Beschaffungs- und Vertragskontrollen

1. exakte Produktbestandteile und Lizenzversionen im Vertrag nennen;
2. Widerspruch zwischen Website, Repository und Order Form ausschließen;
3. kommerzielle Nutzung, Hosting und interne Shared Services ausdrücklich klären;
4. Preisänderung, Renewal und Mindestlaufzeit begrenzen;
5. EOL-, Security- und Backportpflichten definieren;
6. Datenexport und Migrationssupport regeln;
7. Change-of-Control und Material License Change als Review-Trigger aufnehmen;
8. angemessene Übergangsfrist verhandeln;
9. eigene Modifikationen und Contributions dokumentieren;
10. Trademark- und Distribution-Rechte getrennt von Code-Rechten prüfen;
11. Subprozessor- und Telemetriebedingungen erfassen;
12. Exit Drill und technische Dokumentation finanzieren.

---

9. Architekturmaßnahmen

9.1 Standards an den Grenzen

• SQL und dokumentierte Dumpformate statt ausschließlich proprietärer Admin-APIs;
• OpenTelemetry statt nur vendorinterner Agenten;
• S3-kompatible Objektgrenzen, wo fachlich ausreichend;
• OCI Images und reproduzierbare Builds;
• deklarative Konfiguration im Repository;
• offene Protokolle und Clients;
• Datenmodelle außerhalb des Produkts dokumentieren.

Standards beseitigen nicht jeden Lock-in, reduzieren aber die Fläche der Rekonstruktion.

9.2 Adapter statt Verteilung proprietärer Semantik

Proprietäre Funktionen sollten hinter einer schmalen internen Schnittstelle liegen. Wenn produktspezifische Query-Syntax, IAM oder Eventsemantik im gesamten Code verteilt ist, wird jeder Wechsel zu einem Rewrite.

9.3 Regelmäßiger Dual-Build oder Restore-Test

Für Tier-1-Komponenten:

• Export aus der aktiven Version;
• Import in Fork oder Alternative;
• minimale Regression Suite;
• Performance- und Datenvergleich;
• dokumentierte Abweichungen;
• geschätzte Cutover-Zeit.

Ein theoretisch kompatibler Fork ist ohne Test kein Exit-Asset.

---

10. License-Change Incident Playbook

Ein materieller Lizenzwechsel sollte nicht als rein juristisches Ereignis behandelt werden. Für kritische Komponenten ist er ein Supply-Chain-Incident mit technischen, kommerziellen und organisatorischen Folgen. Das Ziel der ersten 30 Tage ist nicht sofortige Migration, sondern die Wiederherstellung einer belastbaren Entscheidungsbasis.

Stunde 0 bis 24 - Veränderung einfrieren und verifizieren

1. Originalankündigung, Repository-Commit, neue Lizenzdatei und FAQ archivieren.
2. Betroffene Versionen, Komponenten, SDKs, Provider und Libraries exakt bestimmen.
3. Automatische Upgrades und unkontrollierte Image-/Package-Tags stoppen.
4. Aktive Produktion nicht reflexartig abschalten.
5. Legal, Procurement, Security, Engineering und Product Owner informieren.
6. Öffentliche Interpretationen nicht ungeprüft als Vertragsauslegung übernehmen.

Ergebnis: Ein unveränderliches Evidence Bundle mit Zeitstempel und eine vorläufige Scope-Matrix.

Tag 2 bis 5 - Exposure bestimmen

Für jede Nutzung erfassen:

• interne Nutzung, Distribution oder Hosted Service;
• eigene Modifikationen;
• Version und Bezugsquelle;
• produktive Datenmenge;
• Kritikalität, RTO und RPO;
• vorhandene kommerzielle Vereinbarung;
• geplante Releases und Upgradeabhängigkeiten;
• Kunden- oder Auditverpflichtungen;
• bekannte Alternative oder Fork.

Ergebnis: Exposure Register mit affected, not affected, unclear und benanntem Reviewer.

Tag 6 bis 10 - Vier Pfade parallel bewerten

Pfad	technische Arbeit	kommerzielle Arbeit	zentrale offene Frage
Commercial	Vertrags- und Versionstest	Angebot, Rechte, SLA	Ist die Abhängigkeit zu akzeptablen Bedingungen beherrschbar?
Pin	Build, Backport, Isolation	Support-/Haftungsrisiko	Wie lange kann die Version sicher betrieben werden?
Fork	Migration und Kompatibilität	Support-/Sponsorprüfung	Ist der Fork tatsächlich lieferfähig?
Replace	Zielarchitektur und Datenmigration	Projektbudget	Ist ein Wechsel wirtschaftlich und rechtzeitig machbar?

Die Pfade sollten nicht sequentiell geprüft werden. Wer erst monatelang über einen Vertrag verhandelt und danach einen Fork testet, verliert wertvolle Optionszeit.

Tag 11 bis 20 - Proofs statt Meinungen

• aktuelle Daten in Fork/Alternative importieren;
• Regression Suite ausführen;
• Performance und Failure Modes messen;
• Security Advisory und Patchprozess nachvollziehen;
• kommerzielles Angebot inklusive Renewal-/Exit-Klauseln modellieren;
• Aufwand für Backports und eigene Distribution schätzen;
• Kunden- und Complianceauswirkungen prüfen.

Tag 21 bis 30 - Entscheidung und Sunset Clock

Jeder gewählte Pfad erhält:

• Decision Record;
• akzeptiertes Rest-Risiko;
• Budget und Owner;
• messbare Meilensteine;
• Sunset Date für Übergangslösungen;
• Trigger zur Neubewertung;
• Kommunikationsplan.

Ein „vorerst pinnen“ ohne Sunset Date ist keine Entscheidung, sondern unfinanzierte Produktverantwortung.

---

11. Wirtschaftliches Szenariomodell für die vier Pfade

Ein Lizenzereignis sollte wie eine Realoption behandelt werden. Das Unternehmen besitzt mehrere Handlungsalternativen mit unterschiedlichen Sofortkosten und späteren Risiken.

11.1 Commercial Path

Commercial TCO =
License + Support + Renewal Growth + Integration + Exit Reserve

Die Exit Reserve ist ein bewusst zurückgestelltes Budget für Migration, nicht eine bilanzielle Pflichtposition. Ohne sie erscheint der kommerzielle Pfad künstlich günstig, solange die Abhängigkeit wächst.

11.2 Pinning Path

Pinning TCO =
Build Pipeline + Patch Monitoring + Backports + Compatibility Work + Deferred Migration

Der letzte Term ist entscheidend: Eine spätere Migration kann teurer werden, weil Datenmenge, Integrationen und Wissensverlust wachsen.

11.3 Fork Path

Fork TCO =
Migration + Regression + Operational Learning + Support + Divergence Risk

Divergence Risk beschreibt erwartete Mehrarbeit, wenn Upstream und Fork APIs, Datenformate oder Ökosysteme auseinanderlaufen.

11.4 Replacement Path

Replacement TCO =
Discovery + Rebuild + Data Conversion + Dual Run + Validation + Decommission

Replacement kann die höchsten Anfangskosten haben, aber langfristig die geringste Governance-Abhängigkeit erzeugen. Das ist eine Szenariofrage, keine allgemeine Regel.

11.5 Beispielrechnung

Eine kritische Komponente verursacht bisher 30.000 Euro internen Jahresaufwand. Nach dem Lizenzereignis werden folgende Base-Szenarien angenommen:

Pfad	Jahr 1	Jahr 2	Jahr 3	Restabhängigkeit
Commercial	95.000	110.000	126.000	hoch
Pin	80.000	105.000	150.000	sehr hoch
Fork	170.000	65.000	70.000	mittel
Replace	260.000	45.000	48.000	niedrig

Die Zahlen sind rein illustrativ. Bei nominaler Dreijahressumme wären Commercial 331.000, Pin 335.000, Fork 305.000 und Replacement 353.000 Euro. Trotzdem könnte Replacement strategisch sinnvoll sein, wenn es ein existenzielles Service- oder Patchrisiko eliminiert. Umgekehrt kann Commercial wirtschaftlich überlegen sein, wenn der Anbieter echten Supportwert liefert und Exitrechte sauber vertraglich gesichert sind.

11.6 Sensitivitäten

Mindestens variieren:

• jährliche Lizenzsteigerung;
• Migration Delay;
• Zahl kritischer Integrationen;
• Patchaufwand;
• Datenkonvertierungsdauer;
• Parallelbetrieb;
• Wert von Features und Support;
• Ausfall- oder Security-Exposure;
• Diskontsatz;
• Restwert eigener Migrationsartefakte.

---

12. Governance für Vorstand, CTO und Procurement

12.1 Verantwortungsmodell

Rolle	Verantwortung
Board/Executive Sponsor	Risk Appetite und Budgetentscheidung
CTO/Chief Architect	technische Abhängigkeit und Zielpfade
CISO/Product Security	Patchkontinuität, Advisories, Supply Chain
Legal	Lizenz-, Vertrags- und Nutzungsauslegung
Procurement	kommerzielle Rechte, Renewal, EOL, Exit
Service Owner	tatsächlicher Einsatz, SLOs, Betriebswissen
Finance	TCO, Rückstellungen/Reserven, Szenarien
Internal Audit/Compliance	Nachweis und Kontrollwirksamkeit

12.2 Quartalsreporting

Für Tier-1-Komponenten:

• Anzahl Komponenten mit aktuellem LBOM-Eintrag;
• Anteil mit archiviertem Lizenzhash;
• Anteil mit benannter Patchquelle;
• Anteil mit getesteter Alternative;
• durchschnittliches Alter des letzten Exit-/Restore-Tests;
• offene unclear-Lizenzbewertungen;
• EOL innerhalb 12/24 Monaten;
• Komponenten mit Single-Maintainer-/Single-Vendor-Risiko;
• kommerzielles Spend und Renewal Exposure;
• Findings aus Drills.

12.3 Risk Appetite

Beispielhafte Policy:

„Tier-1-Produktionskomponenten dürfen unter einer source-available oder kommerziell eingeschränkten Lizenz betrieben werden, wenn Nutzungsrechte schriftlich geklärt, Patchkontinuität gesichert und ein innerhalb von zwölf Monaten getesteter Exit- oder Forkpfad dokumentiert ist.“

Eine Organisation kann eine andere Schwelle wählen. Wichtig ist, dass die Akzeptanz explizit statt zufällig ist.

---

13. Fallstudienvergleich: Was die Ereignisse gemeinsam haben

13.1 MongoDB

Die SSPL-Einführung zeigt, dass ein frei sichtbares Repository nicht automatisch eine OSI-konforme Open-Source-Lizenz bedeutet. Für typische Endnutzer kann die praktische Wirkung begrenzt sein; für Anbieter konkurrierender Services ist die Auslegung zentral. Procurement muss Nutzungsklasse statt bloß Produktnamen prüfen.

13.2 Terraform und OpenTofu

Hier ist die Trennung zwischen Daten-/Konfigurationsportabilität und Governance besonders sichtbar. HCL, Provider und State sind nicht allein durch einen Fork risikofrei. Entscheidend sind Kompatibilität, Registry-/Provider-Ökosystem, Releaseprozess und langfristige Community-Governance.

13.3 Redis und Valkey

Der Verlauf von BSD über RSAL/SSPL zur zusätzlichen AGPL-Option und parallel entstandener Valkey-Governance zeigt, dass Lizenz- und Communityentwicklung dynamisch sind. Eine Entscheidung vom März 2024 kann im Juli 2026 andere Optionen haben. Das spricht für versionierte Reviews statt einmaliger White-/Blacklist.

13.4 Elasticsearch und OpenSearch

Die Geschichte illustriert, dass Forks eigenständige Roadmaps entwickeln. Spätere zusätzliche Lizenzoptionen beim Originalprojekt beseitigen nicht automatisch Migrations-, Marken- oder Ökosystementscheidungen, die Unternehmen bereits getroffen haben.

13.5 CockroachDB

Zeitverzögerte oder eingeschränkte Lizenzmodelle verlangen eine genaue Betrachtung von Change Dates, Versionen und kommerziellen Einsatzrechten. Der Name einer Lizenzfamilie reicht nicht; konkrete Parameter und Additional Use Grants sind entscheidend.

13.6 Gemeinsames Muster

1. wirtschaftliche Spannung zwischen Steward und Cloud-/Serviceanbietern;
2. Lizenzänderung als Hebel;
3. Unsicherheit über Scope und Zukunft;
4. Fork- oder Alternativprojekt;
5. getrennte Roadmaps und Ökosysteme;
6. spätere Stabilisierung, neue Lizenzoption oder kommerzielle Klärung.

Dieses Muster ist keine Prognose, dass jedes Projekt so verläuft. Es ist ein Grund, bei Kernkomponenten Handlungsoptionen vorab zu erhalten.

---

14. License Change Drill

Ein jährlicher Tabletop- und Technikdrill kann folgende Annahme simulieren:

„Ab nächstem Major Release ist die bisherige Nutzung nicht mehr unter denselben Bedingungen möglich; Security Fixes für die aktuelle Version enden in neun Monaten.“

Tabletop-Fragen

• Wer erkennt die Änderung zuerst?
• Welche Systeme und Kunden sind betroffen?
• Welche Versionen sind produktiv?
• Wo liegt der archivierte Lizenznachweis?
• Können automatische Upgrades gestoppt werden?
• Welche Daten und APIs müssen migriert werden?
• Welcher Fork oder Ersatz ist tatsächlich getestet?
• Wie lange reicht die Patchfähigkeit?
• Wer darf kommerzielle Bedingungen akzeptieren?
• Welches Budget steht innerhalb von 30 Tagen bereit?

Technikteil

• aktuelle Produktionsdaten anonymisiert oder synthetisch exportieren;
• Fork/Alternative deployen;
• Import und Smoke Tests;
• kritische Queries/Workflows ausführen;
• Performance und Kompatibilität dokumentieren;
• Rollback testen;
• Ist-Aufwand und fehlende Artefakte erfassen.

Erfolgsnachweis

Der Drill gilt nicht als bestanden, weil ein Meeting stattfand. Benötigt werden:

• reproduzierbares Deployment;
• dokumentierter Datenpfad;
• Testprotokoll;
• Issues mit Owner und Due Date;
• aktualisierte TCO-Szenarien;
• Executive Decision Record.

---

15. Visualisierungsspezifikation

Chart 1 - Procurement Risk Score

• Datei: data/FDR-2026-06_license_risk_scores.csv;
• horizontale Balken;
• Label: „modelliertes Beschaffungsrisiko, keine Rechtsbewertung“;
• Subscores im Tooltip.

Chart 2 - Lizenz- und Fork-Timeline

• Datei: data/FDR-2026-06_license_governance_timeline.csv;
• Ereignistypen: license change, fork response, additional option, governance event;
• Originalprojekt und Fork visuell verbinden;
• keine implizite Kausalität über reine zeitliche Nähe hinaus behaupten.

Chart 3 - Fork Maturity Radar

• sechs Fähigkeiten;
• nur veröffentlichen, wenn jedes Rating mit Evidence Note versehen ist;
• kein dekoratives Ranking ohne Rubrik.

Chart 4 - Reaktionspfad-TCO

• vier Pfade als Cashflow-Szenarien;
• Low/Base/High;
• Security-Backport und Parallelbetrieb sichtbar.

Chart 5 - LBOM Coverage

• Anteil kritischer Komponenten mit aktuellem License Hash, Owner, Patchquelle und getesteter Alternative.

---

16. Reproduzierbarkeit

Dateien

• data/FDR-2026-06_license_risk_scores.csv
• data/FDR-2026-06_license_governance_timeline.csv
• data/FDR-2026-06_LBOM_template.csv

Pflichtregeln

1. Lizenztexte nach Version/Tag archivieren, nicht nur aktuelle Website verlinken.
2. Anbieterankündigung, Repository-Lizenz und OSI-Status getrennt dokumentieren.
3. „Source available“ nicht als Synonym für „Open Source“ verwenden.
4. Fork-Reife nicht aus GitHub-Stars ableiten.
5. Produktqualität nicht aus Lizenzrisiko folgern.
6. not documented nicht als Nullrisiko werten.
7. jede Scoreänderung mit Quelle, Datum und Reviewer protokollieren.
8. rechtliche Auslegung durch qualifizierte Beratung prüfen.

---

17. Grenzen

1. Das Modell bewertet sechs kuratierte Ökosysteme, keine vollständige Marktstichprobe.
2. Scores enthalten analytische Gewichtungen von FW Delta.
3. Öffentliche Dokumentation kann unvollständig sein.
4. Ein kommerzieller Vertrag kann Risiken reduzieren, ist hier aber nicht individuell bewertet.
5. Fork-Fähigkeit verändert sich schnell.
6. Lizenzwirkungen hängen von Nutzung, Modifikation, Distribution und Jurisdiktion ab.
7. Der Report ist kein Rechtsgutachten.
8. Ein niedriger Score beweist keine zukünftige Lizenzstabilität.
9. Ein hoher Score beweist keinen unvertretbaren Einsatz.
10. Vor Veröffentlichung müssen Lizenztexte und Projektstatus erneut geprüft werden.

---

18. Zulässige und unzulässige Aussagen

Zulässig:

„Das FW-Delta-Modell bewertet Beschaffungsrisiko anhand von Lizenzhistorie, Governance, Patchkontinuität und Fallback-Fähigkeit.“

Unzulässig:

„CockroachDB ist zu 72 Prozent unsicher.“

Zulässig:

„Redis 8 bietet zusätzlich AGPLv3 neben RSALv2 und SSPLv1.“

Unzulässig:

„Die frühere Redis-Lizenzänderung wurde vollständig rückgängig gemacht.“

Zulässig:

„Ein Fork reduziert Lieferantenrisiko nur, wenn er unabhängig releasen, patchen und migrieren kann.“

Unzulässig:

„Jeder Fork garantiert Vendor-Unabhängigkeit.“

---

19. Versionshistorie

• 1.0 · Juli 2026 · Sechs Ökosysteme, Ereignis-Timeline, Fork-Maturity-Modell, LBOM und vier Reaktionspfade konsolidiert.
• Live-Version offen · Lizenztexte, Repositories, Governance und Securityprozesse vor Veröffentlichung neu prüfen.

20. Quellen

1. Open Source Initiative, „The Open Source Definition“, https://opensource.org/osd, abgerufen im Juli 2026.
2. Open Source Initiative, „Frequently Asked Questions“, https://opensource.org/faq, abgerufen im Juli 2026.
3. Open Source Initiative, „The SSPL is not an Open Source License“, https://opensource.org/blog/the-sspl-is-not-an-open-source-license, abgerufen im Juli 2026.
4. MongoDB, „MongoDB Issues New Server Side Public License“, 16.10.2018, https://www.mongodb.com/company/newsroom/press-releases/mongodb-issues-new-server-side-public-license-for-mongodb-community-server.
5. MongoDB, „Server Side Public License“, https://www.mongodb.com/licensing/server-side-public-license, abgerufen im Juli 2026.
6. HashiCorp, „HashiCorp adopts Business Source License“, 10.08.2023, https://www.hashicorp.com/en/blog/hashicorp-adopts-business-source-license.
7. HashiCorp, „Business Source License FAQ“, https://www.hashicorp.com/en/license-faq, abgerufen im Juli 2026.
8. OpenTofu, „OpenTofu Announces Fork of Terraform“, 25.08.2023, https://opentofu.org/blog/opentofu-announces-fork-of-terraform/.
9. OpenTofu, „About OpenTofu“, https://opentofu.org/docs/intro/, abgerufen im Juli 2026.
10. Redis, „Redis Adopts Dual Source-Available Licensing“, 20.03.2024, https://redis.io/blog/redis-adopts-dual-source-available-licensing/.
11. Redis, „Redis is now available under the AGPLv3 open source license“, 01.05.2025, https://redis.io/blog/agplv3/.
12. Linux Foundation, „Linux Foundation Launches Open Source Valkey Community“, https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-valkey-community.
13. Elastic, „Elasticsearch is open source, again“, 29.08.2024, https://www.elastic.co/blog/elasticsearch-is-open-source-again.
14. Elastic, „Licensing FAQ“, https://www.elastic.co/pricing/faq/licensing, abgerufen im Juli 2026.
15. OpenSearch, „About“, https://opensearch.org/about.html, abgerufen im Juli 2026.
16. Cockroach Labs, „Licensing FAQs“, https://www.cockroachlabs.com/docs/v26.2/licensing-faqs, abgerufen im Juli 2026.
17. Cockroach Labs, „CockroachDB Software License“, https://www.cockroachlabs.com/cockroachdb-software-license, abgerufen im Juli 2026.
18. MariaDB, „Business Source License FAQ“, https://mariadb.com/bsl-faq-adopting/, abgerufen im Juli 2026.
19. MariaDB, „Business Source License 1.1“, https://mariadb.com/bsl11/, abgerufen im Juli 2026.
20. SPDX, „License List“, https://spdx.org/licenses/, abgerufen im Juli 2026.
21. OpenTofu, „Manifesto“, https://opentofu.org/manifesto/, abgerufen im Juli 2026.

---

Disclosure und Haftungsausschluss

FW Delta baut und betreibt Systeme auf Open-Source-, source-available und kommerziellen Komponenten. Das Unternehmen kann wirtschaftlich von Migrations-, Modernisierungs- und Ownership-Projekten profitieren. Die Methodik, Scores und Grenzen werden deshalb offengelegt.

Dieser Report ist keine Rechtsberatung. Lizenztexte, Vertragsbedingungen und konkrete Nutzung müssen durch qualifizierte Fachpersonen geprüft werden.