Open source licence due diligence

Open source licence due diligence answers three questions about a target's software: what open source components are inside it, what each component's licence requires, and whether any requirement reaches the company's own code. Nearly all commercial software contains open source, so the presence of components is expected. The findings come from the licence terms and from whether the company knows what it is using.

Reveneau's diligence request asks for the component inventory in SPDX identifiers, the output of the most recent licence scan, the written open source policy, and the record of who approved each copyleft component, because those four artefacts together show both what the exposure is and whether the company was managing it. Morgan Lewis's note of 2026-06-05, Open-Source Software: Common Areas of Inquiry in M&A Due Diligence, lists the same set: a written policy, employee training, contributions to open source projects, monitoring and inventories, regular scans, and an approval process for copyleft-licensed software.

This page explains the licence families in plain language, what to ask for, and how to turn a finding into a price. For the wider security and compliance review, see assessing security and compliance; for the code provenance questions AI-written code adds, see code provenance and licence exposure in AI-generated code. The pillar guide places this page in the full review.

What does an open source licence actually require?

An open source licence is a permission with conditions. The Open Source Initiative's definition (version 1.9, 2007-03-22) sets ten criteria a licence must meet to be called open source, starting with free redistribution and access to source code, and the OSI maintains the list of licences that meet them. The permission is always broad. The conditions are where the licences differ, and they fall into three families.

Permissive licences ask for attribution. The MIT License grants permission "to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies", on the condition that the copyright notice and the permission notice "shall be included in all copies or substantial portions of the Software". The Apache License 2.0 (January 2004) adds an explicit patent licence from each contributor and, in section 4, conditions on redistribution: include the licence, mark modified files, keep the notices, and carry the NOTICE file forward. A company using permissive components owes credit and notices, and nothing about its own code changes.

Copyleft licences ask for the same freedom in return. The GNU General Public License version 3 (2007-06-29) says in its preamble that if you distribute copies "you must pass on to the recipients the same freedoms that you received", and section 5(c) makes the mechanism explicit: "You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy." In plain words: if a company modifies GPL code, or builds its own code into a single work with GPL code, and then distributes that work, the whole work has to be offered under the GPL, source included. That is the clause that can reach proprietary code, and it is why copyleft has its own line in every diligence request.

Network copyleft closes the SaaS gap. The GPL's condition is triggered by distribution, and a SaaS company distributes nothing: users interact with the software over a network. The GNU Affero General Public License version 3 (2007-11-19) adds section 13 for exactly that case: a modified version "must prominently offer all users interacting with it remotely through a computer network ... an opportunity to receive the Corresponding Source of your version". An AGPL component modified inside a SaaS product can therefore carry a source-offer obligation even though no binary ever ships.

Family	Example licences	What it asks for	Can it reach the company's own code?
Permissive	MIT, Apache-2.0	Keep the notices; Apache-2.0 adds a NOTICE file and a patent grant	No
Copyleft on distribution	GPL-3.0	Offer the whole distributed work under the same licence, with source	Yes, when the company's code and the component form one distributed work
Copyleft on network use	AGPL-3.0	The same, plus a source offer to users who interact over a network	Yes, including for SaaS that ships no binary

Whether a given combination forms "one work" is a legal question that depends on how the code is linked and packaged, and the reviewer's job is to find the combinations and hand them to counsel with the facts, not to rule on them.

What should the reviewer ask the target for?

The reviewer should ask for four artefacts: the component inventory, the latest scan output, the written policy, and the copyleft approval record. Each answers a different question and the absence of each is a different finding.

1. The inventory, in SPDX identifiers. The SPDX License List (version 3.29.0, released 2026-09-16) gives every common licence a short standard name, so an inventory that uses them can be checked by a tool and compared across products. CISA describes the fuller form, a software bill of materials, as "a nested inventory, a list of ingredients that make up software components". A company that can export one has tooling in its build; a company that has to assemble one has never looked.
2. The scan. Ask which tool ran, when, over which repositories, and for the raw output. Morgan Lewis observes that "OSS scans often discover inconsistencies and issues that need to be remedied prior to the closing", which is the plain reason to run one before the price is fixed rather than after.
3. The written policy. A policy says which licences are allowed without approval, which need approval, and which are forbidden, and who decides. Its existence shows the company treats licences as a managed input. Its absence is common at early stage and becomes a finding as the company grows.
4. The approval record for copyleft. For every GPL or AGPL component in the inventory, who approved it, when, and on what basis (isolated as a separate process, used unmodified, or accepted with the obligation understood). This record is where most real exposure surfaces, because approval is usually missing.

Ask also about contributions outward. A company whose engineers contribute to open source projects under no approval process can carry proprietary code out of the company, and Morgan Lewis lists contribution policies among the areas of inquiry. And ask, for AI-written code, whether any tool used was configured to filter suggestions that match public code, since the provenance page explains why that setting matters.

How does a licence finding become a price?

A licence finding becomes a price by asking what it costs to remove the obligation, and the answer ranges from an afternoon to a rewrite. The reviewer's report should carry that cost on every copyleft row, following the four-field format on the report template.

Four outcomes cover most findings. The component is used unmodified and separately, and counsel confirms no obligation attaches: record it and move on. The component can be replaced by a permissive alternative: the cost is the engineering time to swap and re-test, usually days. The component is woven into the product and has no alternative: the cost is either a rewrite of that part or a commercial licence from the component's author, where one exists. The company has already distributed the combined work: the exposure is historical as well as forward-looking, and the finding goes to counsel with a Critical severity.

Missing notices in permissive components are the fifth and most common finding. They cost little to fix and they are a fair measure of whether anyone was paying attention.

Resist the round numbers. Several vendor pages claim a percentage of codebases with licence conflicts; none we found publishes a method or a sample, so none appears here. The finding in front of you has an inventory, a scan and a cost, and that is the only number the deal needs.

What does a mature open source programme look like?

A mature programme has an inventory generated by the build, a scan on every release, a policy that engineers can find, an approval record, and someone accountable for all four. There is an international standard for exactly this: the OpenChain Project maintains ISO/IEC 5230, "the international standard for open source license compliance programs", and ISO/IEC 18974 for open source security assurance. A target that conforms, or can show the elements without the certificate, is at the low-risk end.

Early-stage companies will have little of it, and that is normal. The finding at seed is whether the founders know which licences they are using. The finding at growth stage is whether a process exists. The finding at buyout is whether the process ran, because a large company with a policy nobody followed has the exposure without the excuse. Scope by stage sets how deep to go at each.

The inventory is also the starting point for the security half of the same question: which components are out of date and carry known vulnerabilities. The two reviews use the same list, and a company that cannot produce the list for the licence review cannot produce it for the security review either.