OPEN SOURCE LICENSE RISK

Open source license risk for the board.

Open source license risk for the board is no longer a technical footnote. A single relicensing event can create unbudgeted cost, constrain a roadmap, and surface in an audit or a deal. This article sets out what directors should expect to see and the questions that separate a controlled estate from a hopeful one.

Boards have learned to ask about cyber risk, concentration risk, and key supplier risk. Open source license risk for the board belongs in the same conversation, because the failure mode is similar: a dependency you rely on changes terms outside your control, and the cost lands without warning. The difference is that this risk has been quieter, so many boards have never been briefed on it at all. That silence is itself a finding.

The trigger is relicensing. Over the past several years a series of widely used projects moved from open source licenses to source available terms. As of August 2023 HashiCorp moved Terraform, Vault, Consul, Nomad and Packer to the Business Source License 1.1, and was later acquired by IBM, with the community fork OpenTofu. As of March 2024 Redis moved to a model that includes the Server Side Public License, with the fork Valkey. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License in 2021, with the fork OpenSearch. MongoDB moved to the Server Side Public License in 2018. Source available is not open source, and neither the Business Source License nor the Server Side Public License is approved by the Open Source Initiative. Each change created production exposure for enterprises that had rarely mapped it.

Why this is a governance matter, not just a technical one

A board is responsible for overseeing material financial and strategic risk. A relicense touches all three of those. It can demand an unplanned commercial license fee, which is a financial outcome. It can force a migration that diverts engineering from the roadmap, which is strategic. It can surface during a regulatory audit or an acquisition, which is reputational and transactional. When a risk produces those outcomes, oversight of it sits with the board, not solely with engineering.

The reason this risk escapes attention is that it lives below the line most reporting draws. Open source is treated as free and therefore unmanaged. The component that quietly changed terms does not appear on any vendor list, so it never reaches the risk register. Naming the category and putting it on the agenda is the first act of governance, because you cannot oversee what management has never surfaced.

What management should report

A board does not need a dependency tree. It needs a clear, current summary that a director can act on. A useful report names the most material open source dependencies, states whether any of them have relicensed, sizes the exposure in financial terms, and describes the containment plan with a timeline and an owner. Because the topic moves quickly, the report should carry an explicit as of date, so everyone knows how stale the picture might be.

The financial framing matters most. A director cannot weigh a list of license names, but can weigh a number: the estimated cost if a top dependency relicensed, set against the cost to remediate now. That comparison is the language of the boardroom, and it turns an abstract technical worry into a decision the board is equipped to make. The open source license risk guide describes how that exposure is quantified.

Four questions a board should ask

The simplest way to test the maturity of an estate is to ask four questions and listen to how confidently they are answered. Do we know every open source component we run and its current license. Has any component we depend on changed its license, and how would we know. What would a relicense of our top dependencies cost us. Who owns the response, and how quickly would it move. A hesitant answer to any of these is the exposure, expressed in real time.

Knowing what you run

The first question sounds basic and is the one most often answered poorly. A complete inventory reaches transitive dependencies and the components buried inside container images, not just the libraries a team declared. If management cannot produce a current bill of materials, the rest of the answers are guesses. For where these components hide, see open source license risk in containers and images.

Knowing what changed

The second question tests whether the inventory is alive. A snapshot taken once and filed is worthless against a risk whose defining feature is sudden change. The right answer describes a monitoring process that flags a relicense at intake, so a board hears about it as news rather than as a crisis. Understanding the families involved helps here: see permissive vs copyleft vs source available explained.

Relicensing, valuation, and deals

Open source exposure becomes most expensive at the moment of a transaction. In an acquisition, a target's dependency tree can carry relicensing risk that a buyer will price in as a cost to cure. A board overseeing a deal benefits from surfacing that exposure during diligence, with a remediation figure attached, while there is still room to adjust price or terms. The same logic protects a company being acquired: a clean, documented estate removes a discount the other side would otherwise claim.

What good oversight looks like

Good oversight does not require directors to understand license text. It requires a standing place on the risk agenda, a report that is current and financial, a named owner, and a monitoring process that turns sudden changes into scheduled decisions. The aim is the same one that defines mature governance everywhere: no surprises. When the next project relicenses, the board should learn of it from a planned briefing, with the exposure already sized and a path already chosen, rather than from an auditor or a vendor letter. Interpretation of the underlying license terms and any fiduciary question should go to your own counsel.

COMMON QUESTIONS

Questions buyers ask.

CONTAINMENT

Give your board a number, not a guess.

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.