PILLAR GUIDE

Open source license risk: the complete enterprise guide.

This open source license risk guide is the buyer side reference for the exposure created when widely used projects change their license. It explains what relicensing exposure is, how to map the blast radius across your estate, and how to contain it without stalling delivery. Written for the CISO, the general counsel, procurement, and engineering leaders who carry the risk.

Open source license risk used to feel like a settled topic. For years the dominant licenses were permissive or copyleft, both well understood, and the main job was compatibility hygiene. That changed when a wave of widely used projects moved from open licenses to source available terms. The exposure these changes create is rarely mapped, and it can apply to software already running in production. This open source license risk guide sets out what changed, why it matters, and what to do about it.

What open source license risk actually is

Open source license risk is the exposure created when the terms governing software you run restrict how you may use, modify, or distribute it. Most of the time those terms are stable and benign. The risk spikes in two situations. The first is a compatibility conflict, where combining components under incompatible licenses creates an obligation you did not intend. The second, and the one driving current concern, is a relicense, where a project you already depend on changes its terms under you.

A relicense does not rewrite the copies of the software you have already deployed. It changes the terms that apply the next time you upgrade, redistribute, or deploy the software in a restricted way. That is why the exposure is easy to miss. Nothing breaks on the day of the change. The risk accrues quietly until an upgrade, an audit, or a deal brings it to the surface.

Source available is not open source

The single most important distinction in this guide is that source available is not the same as open source. Source available means you can read the code, but the license restricts what you may do with it. The Business Source License and the Server Side Public License are both source available, and neither is approved by the Open Source Initiative. Policies, contracts, and engineering habits built on the assumption that visible source means open source are precisely where exposure enters.

The practical consequences fall into three buckets. Competitive use restrictions limit offering the software, or a close substitute, as a commercial service. Copyleft and distribution obligations, such as those under the GNU AGPL, can require you to release source under specific conditions. Commercial license demands arise when a vendor concludes your usage now needs a paid agreement. Each of these can apply to software already in production.

The relicensing wave, as of 2026

This is a fast moving topic, so the events below carry an as of date and should be checked against current sources. As of August 2023 HashiCorp moved Terraform, Vault, Consul, Nomad and Packer from an open source license to the Business Source License 1.1. The Business Source License restricts competitive production use and converts to an open license after a delay, commonly four years. IBM later acquired HashiCorp. The community fork of Terraform is OpenTofu.

As of March 2024 Redis moved from an open source license to a dual model under the Redis Source Available License version 2 and the Server Side Public License, and later added an open license option. The community fork is Valkey. Elasticsearch and Kibana moved from Apache 2.0 to the Server Side Public License and the Elastic License in 2021, and later added an open license option. The fork led by AWS is OpenSearch. MongoDB moved to the Server Side Public License in 2018. The pattern is consistent: a commercially backed open source project changes terms to protect a revenue model, and a community fork appears to preserve the open posture.

Mapping the blast radius

The blast radius is everything that depends on a relicensed component, direct and transitive, across your estate. A single relicensed library can sit beneath dozens of services through transitive dependencies that no one chose deliberately. Mapping the blast radius is how you separate true production exposure from a harmless reference in a test fixture. Without the map, teams either panic over nothing or miss the deployment that actually matters.

• Identify every direct use of the relicensed component across repositories and environments.
• Trace transitive dependencies, since the riskiest uses are often the ones no one adopted on purpose.
• Record how each instance is deployed, because the license trigger depends on use, not mere presence.
• Rank instances by exposure, so the remediation budget retires the largest risk first.

The first step for most enterprises is an open source license risk assessment that produces the full dependency tree. From there a relicensing exposure review sizes what the changes cost.

Quantifying exposure in board language

A finding that cannot be costed cannot be prioritized. Exposure is sized two ways. The cost of exposure estimates what the risk could cost if it materializes, whether as a commercial license demand, a remediation scramble, or a stalled deal. The cost to cure estimates what it takes to contain the risk through a fork, a removal, or a negotiated license. Presenting both lets leadership decide with numbers rather than adjectives, and it keeps spend pointed at the exposure that counts.

Containing open source license risk

Containment runs along three paths, and most programs use a mix. The first is to migrate to a community fork or an alternative, such as OpenTofu for Terraform, Valkey for Redis, or OpenSearch for Elasticsearch. The second is to negotiate a commercial license, which is often the cleaner answer when usage is deep and switching is expensive. The third is to remove the dependency, which suits low value or easily replaced components.

Choosing a path

The right path depends on how you use the component, how costly switching is, and which license triggers your deployment crosses. A relicensed tool you run purely internally, never offered as a service, may carry little real exposure and need no change at all. The same tool embedded in a product you ship can require urgent action. Judgment matters, which is why a raw scanner report is not a plan.

Preventing the next relicense from surprising you

The cheapest exposure to contain is the exposure that never enters. An open source governance and SBOM program sets license rules, approval gates, and intake controls so a future relicense is caught at intake rather than in an audit. A current software bill of materials means the next time a dependency changes terms, you find it on your schedule, not the vendor's.

Read next

This guide is the hub for a cluster of deeper articles. Start with permissive vs copyleft vs source available explained for the license families. Then read open source license risk in containers and images for where exposure hides in your build, and open source license risk for the board for how to brief leadership.

For the vendor specific picture, see the relicensing pillar, the Redis and Elastic database licensing pillar, and the HashiCorp and Terraform pillar. Our buyer side independence is the reason this analysis names risk plainly, as explained in why our independence matters.

COMMON QUESTIONS

Questions buyers ask.

CONTAINMENT

Map your open source license risk before it surfaces.

A confidential open source license risk assessment. Independent, buyer side, paid only by you.

Not ready to talk? Read the free open source license risk guides first.