Open Source Due Diligence Checklist

An open source due diligence checklist is the difference between buying a company and buying its hidden license liabilities. Almost every software business runs on open source, and the terms governing that open source can carry obligations and costs an acquirer inherits at close. A target may be shipping code under a strong copyleft license, or running a component that has relicensed to source available terms, without having priced either. Found during diligence, these are negotiable. Found after close, they are the buyer's problem. This article sets out the checks that protect deal value, organized as a checklist an acquirer can run.

We write from the buyer side as an independent advisory paid only by the buyer. This is not legal advice. For interpretation of a target's license obligations and deal terms, we point you to your own counsel.

Why an open source due diligence checklist matters

The open source due diligence checklist exists because a target's dependency tree can change the value of a deal. Open source is not free of obligation. A component under the GNU AGPL attaches conditions to network use. A component that distributes under a strong copyleft license can require source disclosure of code built on it. A dependency that has relicensed, such as those HashiCorp moved to the Business Source License as of August 2023, or those Redis and Elastic moved to source available terms, can require a commercial license or a migration. When an acquirer buys the company, it buys these obligations too. If they were never identified, the acquirer absorbs the cost of meeting them, which can be substantial and which the seller has effectively passed across in the price. A disciplined checklist surfaces all of this while the price is still open.

The value of the checklist is timing as much as content. The same finding has very different consequences depending on when it surfaces. During diligence it is a negotiating point, attached to a remediation cost the buyer can subtract from the offer or shift to the seller through a warranty. After close it is a sunk liability. The checklist is the instrument that moves the discovery to the right side of that line.

The inventory and license checks

The checklist begins with the inventory, because nothing else can be assessed without it. The acquirer needs a complete dependency tree for the target's software, direct and transitive, to the depth a real bill of materials reaches. A target that can produce a current, accurate inventory has already passed a meaningful test; a target that cannot is itself a finding, because it means the company does not know what it runs. With the inventory in hand, the next check is the license of every component. Each dependency carries terms, and the acquirer needs to know which licenses are present, with particular attention to the ones that impose obligations: the strong copyleft licenses, the source available licenses, and any custom commercial terms. The aim of this stage is a full map of what the target depends on and under what terms, which becomes the foundation for every judgment that follows.

Copyleft, relicensing, and compliance red flags

With the map complete, the checklist moves to the findings that change a deal. The first is copyleft in shipped or hosted code. A strong copyleft component woven into a product the target distributes, or offers as a service, can carry disclosure or licensing obligations that affect the target's own proprietary code. This is the classic open source red flag, and its severity depends on how the component is used. The second is relicensing exposure, a dependency that has moved from an open license to a source available one and now sits in the target's production stack under restricted terms. The acquirer needs to know whether the target is using such a component within what the new license permits or has crossed a line that demands a commercial license or a migration. We treat this specific risk in depth in relicensing exposure in an acquisition target. The third is the target's own compliance practice. A company with no maintained inventory, no license policy, and no approval process is carrying not just the risks you can see but the ones no one has looked for. The absence of process is itself a red flag, because it signals that the visible findings are unlikely to be the complete set.

Each red flag should leave diligence with a cost attached, not just a description. A finding without a number cannot be negotiated. The discipline is to size the remediation, whether that is a license to buy, a component to replace, or a process to build, so that the buyer can either price it into the offer or require the seller to address it before close.

Turning findings into deal terms

The checklist is only useful if its findings reach the deal. Each material exposure should map to a specific action: a price adjustment that reflects a remediation cost the buyer will bear, a warranty or indemnity that holds the seller responsible for a defined risk, or a condition that requires the target to remediate before close. The choice depends on the size and certainty of the exposure, but the principle is constant. A finding that stays in a diligence report and never reaches the purchase agreement protects no one. The buyer who runs the checklist, costs the findings, and carries them into the negotiation is the one who actually protects deal value. This is the work of our open source M and A due diligence service, which produces the inventory, the red flag memo, and the remediation costs an acquirer needs at the table. For the full picture of M and A and compliance risk, see the M and A and compliance pillar.