Source-Available License & Governance Risk Report 2026

Executive Summary

Source code access, Open Source, source available and commercial usability are not the same thing. For the procurement of critical software, the license is only one layer. Governance, brand and release control, patch continuity, contributor base, build reproducibility, data and protocol compatibility as well as the existence of a credible fallback are equally important.

This report examines six well-known ecosystems using a disclosed 100-point risk model and supplements it with an event timeline, a License Bill of Materials (LBOM) and an operational response model. The case studies cover MongoDB, HashiCorp/Terraform and OpenTofu, Redis and Valkey, Elasticsearch and OpenSearch, CockroachDB as well as the Business Source License reference model from MariaDB.

The score assesses procurement and continuity risk from a user’s perspective. It is neither a legal opinion nor a moral judgment about vendors. A high value can be defensible given a commercial contract and a good Exit plan. A low value does not replace a license review.

Citable key findings

1. [OBSERVED] Several infrastructure-relevant projects changed their license or added new license options in recent years; this gave rise to forks, new foundation models and altered procurement decisions.
2. [CALCULATED] In the disclosed model, CockroachDB 24.3+ reaches 72/100, MongoDB Community Server 63/100, Terraform/HashiCorp BSL 45/100, the MariaDB BSL reference model 42/100, Redis 38/100 and Elasticsearch 26/100. Higher means more modeled procurement risk, not worse software.
3. [OBSERVED] On 10 August 2023, HashiCorp announced the switch of future releases of several products from MPL 2.0 to BSL 1.1; OpenTofu emerged as a community/foundation response.
4. [OBSERVED] In 2024, Redis moved from BSD-3-Clause to RSALv2/SSPLv1 for new versions and, with Redis 8 in May 2025, added AGPLv3 as a further option; Valkey emerged in 2024 under the umbrella of the Linux Foundation.
5. [OBSERVED] In 2024, Elastic added AGPLv3 as an option alongside ELv2 and SSPL for the relevant free source code portions. A later additional option does not erase the intervening governance and fork history.
6. [INTERPRETATION] A fork is only a viable Exit if releases, security patches, maintainers, governance, ecosystem compatibility and migration work in practice.
7. [RECOMMENDATION] Critical components need an LBOM with license version, Change Date, Change License, patch source, fork option, data format, upgrade/downgrade path and a responsible owner.
8. [RECOMMENDATION] Procurement should fund four response paths in advance: accept a commercial license, pin the version in a controlled way, adopt a fork or migrate.

---

1. Research question and scope

How can the vendor and continuity risk of a source available or license-changed infrastructure component be measured without confusing the license name with actual Exit capability?

1.1 Assessed dimensions

Dimension	Weight	Core question
License change history	20	Has the steward changed rights or terms to a relevant extent?
Field-of-use / service restriction	20	Can certain business models or managed services be restricted?
Governance concentration	15	Who controls roadmap, trademarks, release and merge?
Patch continuity	15	Can the user obtain security and bug fixes independently?
Fallback fork risk	15	Does a technically and organizationally credible fork exist?
no time-based open conversion	10	Is there a binding Change Date or does the restriction remain permanent?
Clarity risk	5	How unambiguous are scope, Additional Use Grant and exceptional cases?

1.2 Not assessed

• product quality, performance or market share;
• the individual legal position of a user;
• commercial discounts or support quality;
• ideological “openness”;
• the probability of a future license change as a statistical forecast.

---

2. Empirical basis and case studies

2. Terms

Open Source

In this report, “Open Source” denotes software under a license recognized by the Open Source Initiative or compatible with the Open Source Definition. The essential point is that there is no impermissible discrimination against persons, groups or fields of endeavor.

Source available

The source code can be inspected and possibly modified, but usage rights contain restrictions that can go beyond classic open source licenses.

BSL

The Business Source License is a source available model with a Change Date after which a defined version can automatically switch to an open source license. The specific Additional Use Grant determines what is permitted before that date.

Fork

Separation of a code base under a permissible earlier license. A fork reduces risk only if governance, maintainers, release process, security, ecosystem and adoption are sustainable.

Last Open Version

The last version before a license change that remains under the earlier open source license. Legally and technically it is not the same thing as a permanently maintained product.

---

---

3. Methodology

3.1 Dimensions

The score is a risk score; higher means more procurement risk.

Code	Dimension	Weight
H	History of abrupt license changes	20
F	Field-of-use / competition restriction	20
G	Concentration of governance	15
P	Continuity of patches under the old/open license	15
K	Absence of a viable fork/fallback	15
T	Absence of an automatic open source conversion	10
C	Ambiguity/complexity of the terms	5

Procurement risk = H + F + G + P + K + T + C

3.2 Interpretation

Points	Band
0–24	low
25–49	moderate
50–69	high
70–100	very high

3.3 Assessment boundary

The analysis refers to the publicly documented situation as at the data cutoff date. It does not assess individual use. An activity can be permitted under one license and prohibited or subject to a paid license under another. This must be examined legally on the specific facts.

---

---

4. Result

Rank by higher risk	Ecosystem	Risk / 100	Band
1	CockroachDB 24.3+	72	Very high
2	MongoDB Community Server	63	High
3	Terraform / HashiCorp BSL	45	Moderate
4	MariaDB BSL reference model	42	Moderate
5	Redis	38	Moderate
6	Elasticsearch	26	Moderate

Complete matrix

Ecosystem	H /20	F /20	G /15	P /15	K /15	T /10	C /5	Total
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

Machine-readable version:

data/FDR-2026-06_license_risk_scores.csv

The ranking is not a statement about which product is technically better.

---

---

5. Case studies

5.1 MongoDB Community Server – 63 points

On 16 October 2018, MongoDB announced that future Community Server releases, including certain patch releases, would be moved from AGPLv3 to the Server Side Public License. The stated aim was in particular to address provision as a service.

The OSI has not recognized the SSPL as an open source license and does not classify it as Open Source.

Procurement risk

• Existing AGPL versions remain under their license.
• Future patches and features follow the new license.
• Users must check their own mode of operation against the SSPL.
• A “we host it ourselves” is not automatically the same question as “we offer it to third parties as a service”.
• Migration to an alternative document database is technically not trivial.

[INTERPRETATION] The central risk factor is patch continuity: an old right of use preserves code, but not automatically the future maintenance line.

5.2 Terraform / HashiCorp BSL – 45 points

On 10 August 2023, HashiCorp announced that future releases of its core products would be moved from MPL 2.0 to BSL 1.1. The Additional Use Grant permits broad use but restricts competitive offerings.

On 25 August 2023, the OpenTofu initiative announced the fork of Terraform. This created a concrete fallback under open governance.

Why the score is only moderate

The license change and competition restriction increase risk. OpenTofu, however, substantially reduces the fork risk:

• active independent releases,
• public repository,
• community and corporate backing,
• continuity with existing Terraform artifacts,
• alternative governance.

[INTERPRETATION] A viable fork can reduce the risk of a license change faster than contract clauses alone. It does not, however, automatically eliminate provider, plugin or state compatibility questions.

5.3 Redis – 38 points

In 2024, Redis announced that Redis 7.4 and later releases would be provided dually under RSALv2 and SSPLv1; the vendor described these licenses as source available. Earlier BSD versions remained unchanged.

In May 2025, Redis added AGPLv3 as a third license option. In parallel, Valkey was built up as an open fork under the umbrella of the Linux Foundation.

Risk effect

• The historical change increases governance risk.
• AGPLv3 again provides an OSI-compatible open source option.
• Valkey creates a viable fallback.
• Ecosystem, modules, distributions and cloud offerings can nevertheless split permanently.

[INTERPRETATION] The return of an open license option reduces current license risk. It does not reset the organizational history to zero.

5.4 Elasticsearch – 26 points

In 2021, Elastic had moved Elasticsearch and Kibana from Apache 2.0 to Elastic License 2.0 and SSPL. In August 2024, the company announced the addition of AGPLv3 as an additional option for the free source code.

At the same time, OpenSearch exists as a fork and alternative ecosystem.

Assessment

• The AGPL option reduces field-of-use risk for the parts licensed accordingly.
• ELv2 and SSPL remain available as options.
• OpenSearch reduces dependence on a single sponsor.
• Feature, plugin and API compatibility must still be examined.

5.5 CockroachDB 24.3+ – 72 points

For CockroachDB 24.3 and later versions, Cockroach Labs documents the CockroachDB Software License. The terms distinguish between permitted free use and constellations requiring a paid license; the documentation names revenue and usage conditions among others.

Risk drivers

• proprietary sponsor-centric license,
• terms dependent on organizational and usage context,
• no equivalent, broadly established fork,
• critical database function,
• future patch and feature line under the same governance.

[INTERPRETATION] The deeper a product sits in data storage and transaction logic, the higher the economic value of a clear long-term license path.

5.6 MariaDB BSL reference model – 42 points

MariaDB developed the BSL as a model in which source code is initially available under limited usage rights and switches to an open source license no later than a defined Change Date.

This entry assesses the BSL pattern, not every current MariaDB product across the board.

Strengths

• automatic time-based opening,
• terms and Change Date visible,
• source code available,
• possibility of a long-term open version.

Risks

• before the Change Date, production or competitive uses can be limited,
• each implementation has its own Additional Use Grants,
• security and release cycles can be faster than the conversion,
• “will be open in four years” does not solve today’s usage questions.

---

---

6. What a license change triggers economically

6.1 Patch Gap

last open version
→ new CVE
→ patch only in the new license line
→ freeze, backport, contract or migration

6.2 Governance Split

Maintainers, cloud providers, distributors and users choose different lines. This leads to:

• duplicate integrations,
• diverging APIs,
• brand and name changes,
• differing release velocity,
• fragmented documentation.

6.3 Procurement Delay

Legal, engineering, security and purchasing must examine:

• current use,
• planned use,
• affiliate structures,
• managed service offerings,
• redistribution,
• revenue/company thresholds,
• support and indemnification.

6.4 Migration Cost

A license change does not automatically create a technical change. But it alters the option set and can thereby create an unplanned migration or contract value.

---

---

7. License Bill of Materials

[RECOMMENDATION] In addition to an SBOM, a company should maintain an LBOM – License Bill of Materials.

Field	Content
Component	product/library
Version	production version
License	SPDX ID or exact text
License source	stable URL/file
Copyright Holder	sponsor/foundation
Change Date	for BSL
Additional Use Grant	exact wording
Type of use	internal, SaaS, redistribution
last open state	version/commit
Fork	name and maturity
Patch plan	vendor, community, internal
Owner	legal + engineering
Review date	next date

---

---

8. Contractual and architectural measures

Before adoption

1. Store the license text.
2. Define the usage scenario in writing.
3. Separate open and commercial features.
4. Document the Last Open Version.
5. Test data export.
6. Examine the fork and replacement market.
7. Define a patch SLA.
8. Require notification of license changes.

During operation

• Monitor release notes
• Diff license files via CI
• Update SBOM/LBOM
• Observe critical forks
• Test restore and migration
• Do not overdo in-house abstraction layers, but isolate critical interfaces

Contract clauses

• Duty to notify on license change
• Right of continued use for the existing version
• Access to security patches
• Export and transition support
• Pricing and renewal rules
• Code escrow where appropriate
• Release of data and configuration

---

3. Results overview

The complete raw values are held in data/FDR-2026-06_license_risk_scores.csv. The score is a transparent decision aid. It should not be cited without the individual dimensions or the specific deployment context.

4. Governance and fork capability model

A repository is not yet an independent supply path. A viable fork requires at least six capabilities.

Capability	minimum evidence	Red flag
technical build capability	reproducible builds, CI, releases	binary artifacts depend on private systems
security capability	CVE process, advisories, coordinated patches	only upstream can close critical vulnerabilities
maintainer capacity	several active maintainers/organizations	single sponsor or bus factor 1
governance	documented decisions and roles	informal control without an escalation path
ecosystem compatibility	clients, providers, plugins, formats	brand or API break without migration
economic viability	funding, support or broad adoption	no funds for long-term maintenance

4.1 Fork Maturity Levels

• F0 - theoretical: code can be copied, but there is no active release path.
• F1 - buildable: the community can produce artifacts and run basic tests.
• F2 - maintainable: independent fixes, releases and security processes exist.
• F3 - migratable: data, APIs and integrations have documented transitions.
• F4 - ecosystem-capable: relevant providers, distributors, plugins and users carry the fork.
• F5 - institutional: neutral governance, funding, transparent roadmap and long-term release capability.

A fork below F2 is not a viable production fallback. Between F2 and F4 it can serve as a tactical bridge. Only F4/F5 significantly reduces structural dependence.

4.2 Patch Continuity Gap

Patch Continuity Gap =
time to upstream security fix
- time to usable fix in the chosen supply path

With a pinned legacy version, the value can become infinite if no more backports appear. With a young fork it can fluctuate in the initial phase. A commercial contract can reduce the gap if SLA, security advisories and backports are clearly regulated.

---

5. License Bill of Materials (LBOM)

An SBOM states which components and versions are inside the product. The LBOM adds the legal and supply-side dimension.

5.1 Mandatory fields

Field	Purpose
component_name / version	exact identification
source_repository / distributor	actual supply path
current_license / license_text_hash	applicable terms and evidence
previous_license	make change visible
change_date / change_license	time-based switching logic
additional_use_grant	relevant exception or permission
production_use	scope of deployment and criticality
modified	own modifications and copyleft relevance
managed_service_exposure	possible competition/service risk
patch_source	upstream, distributor, fork or internal
fallback_project	specifically named technical path
data_format / protocol	migration capability
owner / legal_review_date	accountability and currency
decision_record	accepted risk and response plan

Template:

data/FDR-2026-06_LBOM_template.csv

5.2 Triggers for re-examination

• new major or minor version;
• change to LICENSE, FAQ or Additional Use Grant;
• change of ownership or acquisition;
• new hosted/managed service focus;
• fork or foundation being established;
• EOL or changed patch policy;
• distribution changes binary or package source;
• product becomes part of a regulated or customer-critical system.

5.3 Evidence Vault

The current license URL alone is not enough. The following must be archived:

• license text and hash;
• version/tag/commit;
• FAQ and vendor announcement;
• procurement decision;
• legal review and assumptions;
• contract and exceptions;
• technical migration tests;
• patch and EOL documentation.

This keeps the decision traceable even if web pages are changed later.

---

6. Four response paths and their economics

Path A - Accept a commercial license

Sensible when: product value and support exceed migration costs and dependence is contractually manageable.

To negotiate:

• a clear definition of permitted use;
• pricing and renewal mechanics;
• security and patch SLA;
• escrow or source/build access where appropriate;
• export and transition support;
• change-of-control and EOL rules;
• liability and indemnification within the agreed scope.

Risk: a favorable first contract can become more expensive as dependence grows. Therefore measure Exit costs in parallel.

Path B - Pin the version in a controlled way

Sensible when: no migration is possible in the short term and the old license version remains legally/technically usable.

Mandatory costs:

• in-house security backport;
• reproducible builds;
• isolated package source;
• CVE monitoring;
• compatibility with operating system, libraries and clients;
• a fixed end date for the interim solution.

Risk: pinning easily turns into permanent forking without a budget. A frozen version is not a cost-free state.

Path C - Adopt a fork

Sensible when: the fork reaches at least F2/F3, a relevant community and migration exist and governance fits the organization’s own risk profile.

Examination:

• release cadence;
• security advisories;
• maintainers and sponsors;
• API/data compatibility;
• upgrade and rollback path;
• provider/plugin ecosystem;
• license and trademark.

Risk: the fork can be technically compatible but operationally immature. A proof of migration is mandatory.

Path D - Migrate to a different architecture

Sensible when: dependence is high anyway, the roadmap does not fit, or data/protocol standards make a switch possible.

Cost blocks:

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

Risk: migration driven only by license symbolism can be economically worse than a clean commercial contract. Base the decision on scenarios, not emotions.

---

7. Quantitative decision framework

For each critical component, three values are calculated separately.

7.1 Exposure Score

Exposure =
criticality × breadth of deployment × change/service relevance

7.2 Replaceability Score

Replaceability =
data portability + protocol standard + fork maturity + internal knowledge

7.3 Continuity Cost

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

A high license risk figure with low criticality is less urgent than a moderate score in a core system with no real fallback.

7.4 Example matrix

Component	Risk	Criticality	Replaceability	Decision
internal dev database	high	low	high	observe / test migration
production state store	moderate	very high	medium	contract + fork drill
IaC core	moderate	very high	high	dual compatibility and Exit test
analytics search	moderate	high	medium	measure data format and reindex time

The rows are a methodological example, not a product recommendation.

---

8. Procurement and contract controls

1. name the exact product components and license versions in the contract;
2. rule out contradictions between website, repository and Order Form;
3. explicitly clarify commercial use, hosting and internal shared services;
4. cap price changes, renewal and minimum term;
5. define EOL, security and backport obligations;
6. regulate data export and migration support;
7. include change-of-control and material license change as review triggers;
8. negotiate an appropriate transition period;
9. document own modifications and contributions;
10. examine trademark and distribution rights separately from code rights;
11. record subprocessor and telemetry terms;
12. fund the Exit drill and technical documentation.

---

9. Architectural measures

9.1 Standards at the boundaries

• SQL and documented dump formats instead of exclusively proprietary admin APIs;
• OpenTelemetry instead of vendor-internal agents only;
• S3-compatible object boundaries where functionally sufficient;
• OCI images and reproducible builds;
• declarative configuration in the repository;
• open protocols and clients;
• document data models outside the product.

Standards do not eliminate every Lock-in, but they reduce the surface that has to be reconstructed.

9.2 Adapters instead of spreading proprietary semantics

Proprietary features should sit behind a narrow internal interface. If product-specific query syntax, IAM or event semantics are spread throughout the code, every switch becomes a rewrite.

9.3 Regular dual build or restore test

For tier-1 components:

• export from the active version;
• import into fork or alternative;
• a minimal regression suite;
• performance and data comparison;
• documented deviations;
• estimated cutover time.

A theoretically compatible fork is not an Exit asset without a test.

---

10. License-Change Incident Playbook

A material license change should not be treated as a purely legal event. For critical components it is a supply chain incident with technical, commercial and organizational consequences. The goal of the first 30 days is not immediate migration but the restoration of a sound basis for decisions.

Hour 0 to 24 - freeze and verify the change

1. Archive the original announcement, repository commit, new license file and FAQ.
2. Determine exactly which versions, components, SDKs, providers and libraries are affected.
3. Stop automatic upgrades and uncontrolled image/package tags.
4. Do not shut down active production reflexively.
5. Inform legal, procurement, security, engineering and the product owner.
6. Do not adopt public interpretations as contract interpretation without verification.

Result: an immutable Evidence Bundle with timestamp and a preliminary scope matrix.

Day 2 to 5 - determine exposure

Record for each use:

• internal use, distribution or hosted service;
• own modifications;
• version and source of supply;
• production data volume;
• criticality, RTO and RPO;
• existing commercial agreement;
• planned releases and upgrade dependencies;
• customer or audit obligations;
• known alternative or fork.

Result: an Exposure Register with affected, not affected, unclear and a named reviewer.

Day 6 to 10 - evaluate four paths in parallel

Path	technical work	commercial work	central open question
Commercial	contract and version test	offer, rights, SLA	Is the dependence manageable on acceptable terms?
Pin	build, backport, isolation	support/liability risk	How long can the version be operated securely?
Fork	migration and compatibility	support/sponsor review	Is the fork actually able to deliver?
Replace	target architecture and data migration	project budget	Is a switch economically and timely feasible?

The paths should not be examined sequentially. Anyone who first negotiates a contract for months and only then tests a fork loses valuable option time.

Day 11 to 20 - proofs instead of opinions

• import current data into the fork/alternative;
• run the regression suite;
• measure performance and failure modes;
• trace the security advisory and patch process;
• model the commercial offer including renewal/Exit clauses;
• estimate the effort for backports and in-house distribution;
• examine customer and compliance impacts.

Day 21 to 30 - decision and Sunset Clock

Each chosen path receives:

• a Decision Record;
• accepted residual risk;
• budget and owner;
• measurable milestones;
• a Sunset Date for interim solutions;
• triggers for re-evaluation;
• a communication plan.

A “pin it for now” without a Sunset Date is not a decision but unfunded product responsibility.

---

11. Economic scenario model for the four paths

A license event should be treated like a real option. The company holds several alternative courses of action with different immediate costs and later risks.

11.1 Commercial Path

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

The Exit Reserve is a deliberately set-aside budget for migration, not a mandatory balance sheet item. Without it, the commercial path appears artificially cheap as long as dependence grows.

11.2 Pinning Path

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

The last term is decisive: a later migration can become more expensive because data volume, integrations and knowledge loss grow.

11.3 Fork Path

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

Divergence Risk describes the expected additional work when upstream and fork diverge in APIs, data formats or ecosystems.

11.4 Replacement Path

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

Replacement can have the highest initial costs but produce the lowest long-term governance dependence. That is a scenario question, not a general rule.

11.5 Example calculation

A critical component has so far caused 30,000 euros of internal annual effort. After the license event, the following Base scenarios are assumed:

Path	Year 1	Year 2	Year 3	Residual dependence
Commercial	95,000	110,000	126,000	high
Pin	80,000	105,000	150,000	very high
Fork	170,000	65,000	70,000	medium
Replace	260,000	45,000	48,000	low

The figures are purely illustrative. At the nominal three-year total, Commercial would be 331,000, Pin 335,000, Fork 305,000 and Replacement 353,000 euros. Replacement could nevertheless be strategically sensible if it eliminates an existential service or patch risk. Conversely, Commercial can be economically superior if the vendor delivers real support value and Exit rights are cleanly secured by contract.

11.6 Sensitivities

Vary at least:

• annual license price increase;
• migration delay;
• number of critical integrations;
• patch effort;
• data conversion duration;
• parallel operation;
• value of features and support;
• outage or security exposure;
• discount rate;
• residual value of in-house migration artifacts.

---

12. Governance for the board, CTO and procurement

12.1 Responsibility model

Role	Responsibility
Board/Executive Sponsor	risk appetite and budget decision
CTO/Chief Architect	technical dependence and target paths
CISO/Product Security	patch continuity, advisories, supply chain
Legal	interpretation of license, contract and use
Procurement	commercial rights, renewal, EOL, Exit
Service Owner	actual deployment, SLOs, operational knowledge
Finance	TCO, provisions/reserves, scenarios
Internal Audit/Compliance	evidence and control effectiveness

12.2 Quarterly reporting

For tier-1 components:

• number of components with a current LBOM entry;
• share with an archived license hash;
• share with a named patch source;
• share with a tested alternative;
• average age of the last Exit/restore test;
• open unclear license assessments;
• EOL within 12/24 months;
• components with single-maintainer/single-vendor risk;
• commercial spend and renewal exposure;
• findings from drills.

12.3 Risk Appetite

Example policy:

“Tier-1 production components may be operated under a source available or commercially restricted license if usage rights are clarified in writing, patch continuity is assured and an Exit or fork path tested within twelve months is documented.”

An organization can choose a different threshold. What matters is that acceptance is explicit rather than accidental.

---

13. Case study comparison: what the events have in common

13.1 MongoDB

The introduction of the SSPL shows that a freely visible repository does not automatically mean an OSI-compliant open source license. For typical end users the practical effect can be limited; for providers of competing services the interpretation is central. Procurement must examine the class of use rather than merely the product name.

13.2 Terraform and OpenTofu

Here the separation between data/configuration portability and governance is particularly visible. HCL, providers and state are not risk-free through a fork alone. What is decisive is compatibility, the registry/provider ecosystem, the release process and long-term community governance.

13.3 Redis and Valkey

The path from BSD via RSAL/SSPL to the additional AGPL option, with Valkey governance emerging in parallel, shows that license and community developments are dynamic. A decision from March 2024 can have different options in July 2026. This argues for versioned reviews instead of a one-time white/blacklist.

13.4 Elasticsearch and OpenSearch

The history illustrates that forks develop independent roadmaps. Later additional license options at the original project do not automatically undo migration, brand or ecosystem decisions that companies have already made.

13.5 CockroachDB

Time-delayed or restricted license models require a close examination of Change Dates, versions and commercial usage rights. The name of a license family is not enough; concrete parameters and Additional Use Grants are decisive.

13.6 Common pattern

1. economic tension between steward and cloud/service providers;
2. license change as leverage;
3. uncertainty about scope and future;
4. fork or alternative project;
5. separate roadmaps and ecosystems;
6. later stabilization, new license option or commercial clarification.

This pattern is not a forecast that every project develops this way. It is a reason to preserve courses of action in advance for core components.

---

14. License Change Drill

An annual tabletop and technical drill can simulate the following assumption:

“From the next major release, the previous use is no longer possible under the same terms; security fixes for the current version end in nine months.”

Tabletop questions

• Who notices the change first?
• Which systems and customers are affected?
• Which versions are in production?
• Where is the archived license evidence held?
• Can automatic upgrades be stopped?
• Which data and APIs have to be migrated?
• Which fork or replacement has actually been tested?
• How long does patch capability last?
• Who is allowed to accept commercial terms?
• What budget is available within 30 days?

Technical part

• export current production data anonymized or synthetically;
• deploy the fork/alternative;
• import and smoke tests;
• run critical queries/workflows;
• document performance and compatibility;
• test rollback;
• record actual effort and missing artifacts.

Proof of success

The drill does not count as passed because a meeting took place. What is required:

• a reproducible deployment;
• a documented data path;
• a test log;
• issues with owner and due date;
• updated TCO scenarios;
• an Executive Decision Record.

---

15. Visualization specification

Chart 1 - Procurement Risk Score

• File: data/FDR-2026-06_license_risk_scores.csv;
• horizontal bars;
• label: “modeled procurement risk, not a legal assessment”;
• subscores in the tooltip.

Chart 2 - License and fork timeline

• File: data/FDR-2026-06_license_governance_timeline.csv;
• event types: license change, fork response, additional option, governance event;
• visually connect original project and fork;
• do not assert implicit causality beyond mere temporal proximity.

Chart 3 - Fork Maturity Radar

• six capabilities;
• publish only if every rating carries an evidence note;
• no decorative ranking without a rubric.

Chart 4 - Response path TCO

• four paths as cash flow scenarios;
• Low/Base/High;
• security backport and parallel operation visible.

Chart 5 - LBOM Coverage

• share of critical components with a current license hash, owner, patch source and tested alternative.

---

16. Reproducibility

Files

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

Mandatory rules

1. Archive license texts by version/tag, do not merely link the current website.
2. Document vendor announcement, repository license and OSI status separately.
3. Do not use “source available” as a synonym for “Open Source”.
4. Do not derive fork maturity from GitHub stars.
5. Do not infer product quality from license risk.
6. Do not treat not documented as zero risk.
7. Log every score change with source, date and reviewer.
8. Have legal interpretation reviewed by qualified counsel.

---

17. Limitations

1. The model assesses six curated ecosystems, not a complete market sample.
2. Scores contain analytical weightings by FW Delta.
3. Public documentation can be incomplete.
4. A commercial contract can reduce risks but is not assessed individually here.
5. Fork capability changes quickly.
6. License effects depend on use, modification, distribution and jurisdiction.
7. The report is not a legal opinion.
8. A low score does not prove future license stability.
9. A high score does not prove an indefensible deployment.
10. Before publication, license texts and project status must be re-examined.

---

18. Permissible and impermissible statements

Permissible:

“The FW Delta model assesses procurement risk on the basis of license history, governance, patch continuity and fallback capability.”

Impermissible:

“CockroachDB is 72 percent insecure.”

Permissible:

“Redis 8 additionally offers AGPLv3 alongside RSALv2 and SSPLv1.”

Impermissible:

“The earlier Redis license change was completely reversed.”

Permissible:

“A fork reduces vendor risk only if it can release, patch and migrate independently.”

Impermissible:

“Every fork guarantees vendor independence.”

---

19. Version history

• 1.0 · July 2026 · Six ecosystems, event timeline, fork maturity model, LBOM and four response paths consolidated.
• Live version open · Re-examine license texts, repositories, governance and security processes before publication.

20. Sources

1. Open Source Initiative, “The Open Source Definition”, https://opensource.org/osd, accessed in July 2026.
2. Open Source Initiative, “Frequently Asked Questions”, https://opensource.org/faq, accessed in July 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, accessed in July 2026.
4. MongoDB, “MongoDB Issues New Server Side Public License”, 16 October 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, accessed in July 2026.
6. HashiCorp, “HashiCorp adopts Business Source License”, 10 August 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, accessed in July 2026.
8. OpenTofu, “OpenTofu Announces Fork of Terraform”, 25 August 2023, https://opentofu.org/blog/opentofu-announces-fork-of-terraform/.
9. OpenTofu, “About OpenTofu”, https://opentofu.org/docs/intro/, accessed in July 2026.
10. Redis, “Redis Adopts Dual Source-Available Licensing”, 20 March 2024, https://redis.io/blog/redis-adopts-dual-source-available-licensing/.
11. Redis, “Redis is now available under the AGPLv3 open source license”, 1 May 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 August 2024, https://www.elastic.co/blog/elasticsearch-is-open-source-again.
14. Elastic, “Licensing FAQ”, https://www.elastic.co/pricing/faq/licensing, accessed in July 2026.
15. OpenSearch, “About”, https://opensearch.org/about.html, accessed in July 2026.
16. Cockroach Labs, “Licensing FAQs”, https://www.cockroachlabs.com/docs/v26.2/licensing-faqs, accessed in July 2026.
17. Cockroach Labs, “CockroachDB Software License”, https://www.cockroachlabs.com/cockroachdb-software-license, accessed in July 2026.
18. MariaDB, “Business Source License FAQ”, https://mariadb.com/bsl-faq-adopting/, accessed in July 2026.
19. MariaDB, “Business Source License 1.1”, https://mariadb.com/bsl11/, accessed in July 2026.
20. SPDX, “License List”, https://spdx.org/licenses/, accessed in July 2026.
21. OpenTofu, “Manifesto”, https://opentofu.org/manifesto/, accessed in July 2026.

---

Disclosure and disclaimer

FW Delta builds and operates systems on Open Source, source available and commercial components. The company can profit economically from migration, modernization and ownership projects. The methodology, scores and limitations are therefore disclosed.

This report is not legal advice. License texts, contract terms and specific use must be reviewed by qualified professionals.