What Is Open Source License Risk and Why It Matters Now

Open source license risk is the business exposure that comes from the licenses governing the open source you run, and above all from the exposure created when a project changes its license under software you have already deployed. For most of the past two decades, enterprises treated open source as a settled matter. You adopted a project, accepted its license once, and moved on. That assumption has broken, and open source license risk is the name for what broke. It matters now because the change is no longer hypothetical. It has already happened to some of the most widely used infrastructure in the enterprise.

This article defines the risk plainly, explains why it has become urgent, and shows how it spreads through a dependency tree. It is written from the buyer side, by an independent advisory paid only by the buyer. It is not legal advice. For interpretation of any specific license, we point you to your own counsel.

What open source license risk actually is

At its simplest, open source license risk is the gap between what you assume a license permits and what it actually requires, multiplied by how much of your software depends on it. The risk takes three main forms. The first is competitive use restriction, where a license forbids using the software to compete with the vendor, a clause central to the Business Source License. The second is copyleft and distribution obligation, where a license requires you to share source under certain conditions, as the GNU AGPL does for software offered over a network. The third is the commercial license demand, where continued use of the software the way you run it now requires a paid agreement.

The crucial point is that all three can apply to software already in production. You do not have to do anything new to acquire the exposure. The terms change, and your running systems inherit the change. That is what separates license risk from most other forms of technical risk. It can arrive without any action on your part.

Why it matters now

The reason the topic has moved from theory to boardroom is a series of concrete relicensing events. MongoDB moved to the Server Side Public License in 2018. Elasticsearch and Kibana moved from Apache 2.0 to the Server Side Public License and the Elastic License as of 2021, and later added an open license option. HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License as of August 2023, and IBM later acquired HashiCorp. Redis moved to a model combining the Server Side Public License and the RSALv2 as of March 2024, and later added an open license option. Each of these projects was deeply embedded in enterprise infrastructure when its terms changed.

Two facts compound the urgency. First, source available is not open source. The Business Source License and the Server Side Public License are not approved by the Open Source Initiative, so the comfortable mental model of permanently open code no longer fits. Second, the pattern is continuing. Each new relicensing event teaches other vendors that the move is viable, which means the question is not whether more projects will follow but which ones, and whether you depend on them. An organization that has never mapped its license exposure is, in effect, betting that none of its critical dependencies will change terms.

The blast radius: how one change spreads

The most underestimated part of license risk is its reach. A relicensing event does not stop at the named project. It travels through everything that depends on the component, directly and transitively. We call this the blast radius. A database that relicenses affects every service that embeds it, every internal tool built on those services, and sometimes every product shipped to customers on top of those tools. The named project might be one line in a dependency file. The exposure can be the whole platform built above it.

Mapping the blast radius is the work that turns a vague worry into a defined figure. Until you know how many systems depend on a relicensed component and how, you cannot say whether the exposure is trivial or existential. Most organizations discover that the truth sits somewhere in between, but they only discover it by tracing the tree. This is the core of our open source license risk assessment, which produces a complete dependency map with the license state of every node.

License risk is not security risk

A common error is to fold license risk into the existing security program and assume it is covered. The two share an inventory, but they ask different questions. A security vulnerability is a flaw in code that an attacker might exploit. License risk is exposure in terms that a vendor or auditor might enforce. A component can be flawless from a security standpoint and still carry serious license exposure, and a tool that scans for known vulnerabilities will say nothing about whether a dependency has relicensed. We explore this distinction in detail in open source license risk versus security risk.

The practical implication is that someone has to own license risk explicitly. If it is treated as a subset of security, it tends to fall between teams, because the security tooling does not surface it and the legal team does not see the inventory. We cover the ownership question in who owns open source license risk in the enterprise.

What a buyer should do first

The first move is always the same: map before you worry. An accurate inventory with the current license state of each component tells you whether you have a problem and where it sits. From there, the work divides cleanly. Where a relicensed component reaches deep into production, you scope a containment plan. Where it sits at the edge, you note it and move on. Where a commercial license is genuinely required, you negotiate it from your side of the table rather than accepting a list price. None of this is possible without the map, which is why we treat the assessment as the foundation for everything else.

Open source license risk is not a reason to abandon open source. Open source remains the most productive way to build software, and the relicensing wave touches a small fraction of the projects an enterprise runs. The point is not fear. The point is visibility. A company that can see its license exposure can manage it calmly. A company that cannot is simply hoping. For the full landscape, see the open source license risk pillar, and for the events driving it, the relicensing exposure pillar.