M AND A AND COMPLIANCE

Why standard due diligence misses open source risk.

A typical technical diligence confirms a license list exists and scans for known vulnerabilities. It rarely traces the dependency tree, checks for relicensed components, or tests copyleft obligations against how the target ships. The exposure that moves valuation sits exactly where the standard checklist stops.

Understanding why standard due diligence misses open source risk starts with seeing what a typical diligence is built to do. Most technical diligence in a deal is designed to confirm two things: that the target maintains a list of the open source it uses, and that the code is reasonably free of known security vulnerabilities. Both are worth checking. Neither reaches the exposure that has grown most dangerous since the relicensing wave began. A license list that was accurate when written says nothing about whether the components on it have since changed their terms. A vulnerability scan says nothing about a commercial license demand waiting in a deeply buried dependency. The gap between what diligence checks and what now matters is where deals get surprised. None of this is legal advice, and license interpretation belongs with your own counsel.

What standard due diligence actually checks

The conventional open source step in a deal usually does three things. It requests the target's bill of materials or license inventory and confirms one exists. It runs a vulnerability scan to flag components with known security flaws. And it asks management to represent that the company complies with its open source obligations. Each is a reasonable box to tick, but together they describe the target's own view of itself rather than an independent test of it. They confirm that records exist; they do not confirm that the records are complete or current. For relicensing risk, completeness and currency are exactly the properties that matter.

The transitive dependency blind spot

The first thing a surface level review misses is depth. A target's license list typically captures the components engineers chose deliberately, the direct dependencies. It rarely captures the full transitive tree, the components pulled in automatically several layers down. A relicensed component almost never sits at the top where it is easy to see. It hides in the layers, inside something the target adopted years ago for an unrelated reason. A diligence that reads the target's list rather than rebuilding the tree from the code inherits every gap in that list. The exposure that surprises an acquirer after close was almost always present before it, just unseen, a problem the open source due diligence checklist is built to close.

Relicensed components hide in plain sight

The second miss is time. A license recorded when a component was adopted is not the license that governs it today. Between 2018 and 2024, a series of widely used projects moved from open licenses to source available terms: MongoDB to the Server Side Public License in 2018, Elasticsearch and Kibana to the Server Side Public License and the Elastic License in 2021, HashiCorp's Terraform, Vault, Consul, Nomad, and Packer to the Business Source License in August 2023, and Redis to a source available model in 2024. A target that adopted any of these under their original open license, and never revisited the record, carries an exposure its own inventory does not show. Standard diligence reads the stale record and moves on. The mechanics of how these changes reach into a target are set out in relicensing exposure in an acquisition target.

Copyleft obligations are tested too rarely

The third miss is obligation. A vulnerability scan does not test whether the target's use of a strongly copyleft component, for example under the GNU AGPL, creates distribution obligations given how the target actually ships its software. A component can be perfectly secure and still carry a condition that, triggered by the way the target distributes or offers its product, would require source disclosure the buyer never intended. This is not a security question and a security tool will not find it. It requires reading the licenses against the deployment model, which is the work described in copyleft distribution obligations explained. A clean security report is not a clean license position.

Why the miss costs real money

An overlooked relicensed component is not an abstract compliance footnote. If a target depends on something that has moved to source available terms, the acquirer may inherit a future commercial license cost, a forced migration to a community fork such as OpenTofu, Valkey, or OpenSearch, or both. Surfaced during diligence, with a remediation cost attached, that exposure can be priced into the deal or addressed in the terms. Surfaced after close, it becomes an unbudgeted liability that lands on the integration team. The difference between the two outcomes is purely a matter of when the work was done. Translating the exposure into a number the deal team can use is the subject of quantifying open source risk for a deal.

Surface it early, while it still affects price

The value of finding this exposure depends entirely on timing. A dependency tree review that rebuilds the target's true position, checks every component against its current license, tests copyleft obligations against the deployment model, and attaches a remediation estimate is most useful while there is still room to negotiate. Run it in the final week before signing and the findings arrive too late to move the price. Run it early and the deal team can decide whether to adjust the valuation, seek a specific indemnity, or make remediation a condition. The point of independent diligence is not to kill deals; it is to make sure the buyer pays a price that reflects what they are actually acquiring. The full set of resources sits in the M and A and compliance pillar.

The buyer side view

We run open source diligence that goes where the standard checklist stops: rebuilding the transitive tree, checking each component against its current license, testing copyleft obligations against how the target ships, and attaching a remediation cost the deal team can price in. We are independent and paid only by you, the acquirer, never by the target or any vendor, so the findings serve your valuation and not the sale. We deliver the work through our open source M and A due diligence service, with the exposure quantified in language a board and an investment committee can act on.

COMMON QUESTIONS

Questions buyers ask.

CONTAINMENT

Find the exposure before the deal closes.

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

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