OpenSource Risk Experts
Map your blast radius

PILLAR . THE COMPLETE GUIDE

Open Source in M&A and Compliance: The Complete Guide

Open source in M&A and compliance is where software value and licensing risk meet. A target runs on open source, and the obligations attached to that code, from copyleft reach to AGPL network use to source available relicensing, can move a valuation or trigger remediation cost. This guide sets out how to map the exposure, quantify it, and price it in, from the buyer side.

Open source M and A due diligence

Most of what a buyer pays for in a software deal is code, and almost all modern code rests on open source. The dependency tree of a typical target runs to thousands of components, the great majority of them pulled in transitively and never reviewed by anyone on the target's team. Each component carries a license, and each license carries obligations. When diligence treats open source as a footnote, it leaves the single largest source of hidden risk unexamined. This guide explains how to treat open source in M and A and compliance as a first class workstream, and what that workstream needs to produce.

Why open source in M&A and compliance is material

The risk is material because the obligations are enforceable and the exposure is often already live. A copyleft component that has been linked into a shipped product can carry a source disclosure obligation that the target never satisfied. A dependency offered to customers over a network can trigger the GNU AGPL network use clause. A widely used tool that relicensed to a source available model may now sit under terms that restrict the very use the target depends on. None of these are theoretical. They are conditions that exist on the day of close, and they pass to the buyer with the asset.

The financial shape of the risk varies. Sometimes it is a remediation cost, the engineering effort to remove or replace a component. Sometimes it is a commercial license the buyer will have to take. Sometimes it is a constraint on the product roadmap, where a license prevents a planned use. Each of these is quantifiable, and each belongs in the valuation model rather than in a surprise after the deal closes.

The license families that drive exposure

Three broad families matter. Permissive licenses, such as the MIT and Apache families, generally ask only for attribution and notice, and rarely create deal level risk on their own. Copyleft licenses, such as the GPL and the GNU AGPL, can require that derivative works or networked services make source available under the same terms, which is where most compliance failures hide. Source available licenses, such as the Business Source License and the Server Side Public License, are not open source at all, and carry competitive use limits or service obligations that can apply to software already in production.

Getting these families right is the foundation of the work. A target that believes it ships only permissive code, but has an AGPL library three layers down feeding a customer facing service, has a compliance gap that diligence must surface. We cover the obligations in detail in copyleft distribution obligations explained, and the glossary entries on the Business Source License and related terms give the precise definitions a deal team can rely on.

How relicensing changes the diligence picture

The relicensing wave of recent years has added a new dimension to open source diligence. As of August 2023, HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License 1.1, which restricts competitive production use and converts to an open license after a delay, commonly four years. IBM later acquired HashiCorp. Redis moved to a dual model with the Server Side Public License as of March 2024 and later added an open license option. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License as of 2021, with an open option added later. MongoDB moved to the Server Side Public License in 2018.

For a deal, the consequence is that a target may be running a dependency under terms that have changed since adoption, often without the target's knowledge. The community forks OpenTofu, Valkey, and OpenSearch offer alternatives, but switching carries its own cost and timeline. Diligence has to determine which version of each affected component the target runs, whether the new terms bite given the target's use, and what it would cost to remediate. The broader mechanics are covered on the relicensing exposure pillar.

Quantifying open source risk for a deal

A finding that is not quantified does not change a deal. The discipline is to express each open source exposure in money and time. For a copyleft component on a critical path, the figure is the engineering cost to replace it plus the schedule risk. For a relicensed dependency, it is the commercial license cost or the migration cost to a fork, whichever the buyer would choose. For a missing attribution obligation, it is usually small, a cleanup task rather than a deal issue. Ranking the findings this way lets the deal team focus on the few that matter and set the rest aside.

The output is a red flag memo that the deal team can act on. It names each material exposure, attaches a cost, and recommends whether to price it into the offer, require remediation as a condition of close, or seek a representation and warranty. We walk through the method in quantifying open source risk for a deal, which shows how a dependency finding becomes a line in the valuation model.

What open source due diligence produces

A complete diligence deliverable has five parts. First, a dependency tree for the target that resolves the full graph, not just declared packages. Second, a license verdict on every node, with source available components flagged and dated. Third, an obligation analysis that names which obligations bite given the target's distribution and service model. Fourth, a quantified remediation cost for each material finding. Fifth, the red flag memo that ties it together for the deal team. The work is read only on the target's systems and is timed to fit the diligence window. Our open source M and A due diligence service delivers exactly this, and a foundation open source license risk assessment can be run first where time allows.

Compliance after the deal closes

Diligence does not end the work. A buyer that inherits a target's dependency tree also inherits its compliance posture, and the integration phase is when obligations are either satisfied or quietly carried forward. The cheapest moment to close a gap is the first ninety days, when remediation budget is still in the deal and engineering attention is on integration. After that, the gap becomes ordinary technical debt that competes for resources with everything else. A post close compliance pass, anchored to the diligence findings, turns the red flag memo into a closed list.

Governance is what keeps the gap closed. License policy, approval gates, and an accurate software bill of materials catch the next relicense or the next risky dependency at intake rather than in an audit. The combined estate of two merged companies is exactly where governance tends to slip, because two sets of practices have to become one. The wider discipline of building and keeping that record sits on the open source license risk pillar.

A buyer side checklist

Before signing, confirm five things. You have a resolved dependency tree for the target, not just a license summary the seller prepared. Every source available and copyleft component on a critical path is identified and dated. The obligations that actually bite are named, separated from the ones that do not. Each material finding carries a remediation cost in money and time. And the deal documents address the risk, through price, a condition of close, or a representation. If any of the five is missing, the open source workstream is incomplete, and the gap is the buyer's to carry.

Because we are independent and buyer side, take no vendor fees, and resell no software, the diligence we produce serves the buyer's position and nothing else. The point is not to kill deals. It is to make sure the price reflects the software you are actually buying.

IN THIS CLUSTER

Read next on open source in M and A and compliance.

DEALQuantifying open source risk for a dealTurn a dependency finding into a line in the valuation model. COPYLEFTCopyleft distribution obligations explainedWhen distribution and network use trigger source disclosure. SERVICEOpen source M and A due diligenceFind the exposure before the deal closes. RELATED PILLARRelicensing exposureHow license changes create production exposure. RELATED PILLAROpen source license riskMap, quantify, and contain exposure across the estate.

COMMON QUESTIONS

Questions deal teams ask.

Why does open source matter in M and A and compliance?

A target's value sits largely in its software, and that software runs on open source whose licenses carry obligations. Copyleft reach, AGPL network use, and source available relicensing can each create exposure that changes valuation or triggers remediation cost. Diligence that ignores open source misses a material risk.

What is the difference between copyleft and permissive obligations?

Permissive licenses usually require only attribution and notice. Copyleft licenses can require that you make source available under the same terms when you distribute, and the GNU AGPL extends that obligation to software offered over a network. The reach of copyleft is the central compliance question in most deals.

How does relicensing affect a deal?

When a dependency such as Terraform, Redis, or Elasticsearch moves to a source available license, the target may be running it under terms that restrict competitive use or demand a commercial license. That exposure can be priced into the deal or remediated before close, but only if diligence finds it first.

What does open source due diligence produce?

A dependency tree for the target, a license verdict on every node, a list of obligations that bite given the target's distribution and service model, a quantified remediation cost, and a red flag memo the deal team can act on while there is still room to price the risk.

Is source available code a compliance problem?

It can be. Source available is not open source. The Business Source License and the Server Side Public License are not approved by the Open Source Initiative and carry competitive use limits or far reaching service obligations that can apply to software already in production at the target.

Is this legal advice?

No. This is commercial and licensing risk advisory, not legal advice. For interpretation of license terms and compliance positions in a deal, we recommend you engage your own counsel.

MORE IN THIS CLUSTER

Explore more from this guide.

M AND A AND COMPLIANCE

AGPL and Copyleft Exposure in Diligence

ARTICLE / M AND A AND COMPLIANCE

Open Source in M&A and Compliance FAQ

M AND A AND COMPLIANCE

Open Source Risk in a Code Escrow

ARTICLE / UPDATED JUNE 17 2026

Open Source Risk in Carve Outs

M AND A AND COMPLIANCE

Sell Side Open Source Cleanup Before a Sale

M AND A AND COMPLIANCE

Why Standard Due Diligence Misses Open Source Risk

DEAL

Find the open source exposure before close.

Independent, buyer side open source M and A due diligence. Paid only by you.

Scope due diligence