Open source due diligence assesses whether a target company's third-party code creates licence, security, ownership or remediation risk for an acquirer. It reviews dependency inventories, licence obligations, SBOM evidence, contractor and AI-generated code provenance, and whether open source use supports or compromises the value of the proprietary product.
For investors, the issue is rarely that a company uses open source. Nearly every modern software business does. The diligence question is whether that use is visible, governed and compatible with the buyer's intended ownership model. A dependency tree can contain obligations that do not appear in the financial model, customer contracts or management presentation.
FoundationState's technical due diligence service treats open source as part of the wider software risk picture: scope the work, review data room evidence, sample repositories and dependencies, interview engineering leadership, calibrate findings, and translate the outcome into deal implications. The right conclusion is measured. Most findings are remediable, but unmanaged licence exposure can affect IP value, completion planning and the first 100 days after close.
What should open source due diligence cover?
Open source due diligence should establish what third-party code exists in the product, which licences apply, whether obligations are understood, and whether the company can prove its dependency choices. The review usually combines repository sampling, package manifest analysis, SBOM review, engineering interviews and evidence from legal or procurement records.
The output should be commercial, not academic. A deal team needs to know whether the target can continue selling the product as planned, whether any customer or distribution model triggers additional obligations, whether remediation is a routine clean-up or a structural rewrite, and whether legal counsel needs to revisit warranties or disclosures.
In our diligence engagements we typically look for four evidence types:
- 1Dependency records showing direct and transitive packages across production systems, build tools and deployment artefacts.
- 2Licence classification showing permissive, copyleft, commercial, unlicensed and source-available components.
- 3Governance evidence such as approval policy, scanning tools, exception handling and ownership of remediation.
- 4Provenance evidence showing who introduced material code, where it came from, and whether contractor or AI-assisted work is controlled.
This connects directly to source code due diligence. A code review can show whether dependency use is disciplined, whether package choices are current, and whether the team understands the legal and operational consequences of what it has pulled into the product.
Which licence families matter commercially?
Licence families matter because they shape what an acquirer can do with the software. The Open Source Initiative licence list is the canonical reference point for recognised open source licences, but diligence still needs legal interpretation for the target's exact facts, distribution model and contracts.
Investors do not need to become licence lawyers. They do need to understand the commercial difference between common licence families.
| Licence family | Examples | Typical obligation | Deal risk to test |
|---|---|---|---|
| Permissive | MIT, BSD, Apache 2.0 | Preserve notices and attribution; sometimes patent terms | Usually manageable, but missing notices can still require clean-up |
| Weak copyleft | LGPL, MPL | Share modifications to the covered component in some circumstances | Review linking, modification and distribution patterns |
| Strong copyleft | GPL, AGPL | Source-sharing obligations may be triggered by distribution or network use | Can conflict with a proprietary product or SaaS model if embedded incorrectly |
| Source-available | Elastic Licence, Business Source Licence variants | Code is visible but use may be restricted | Not open source in the OSI sense; commercial restrictions need review |
| Unlicensed or unknown | No licence file, copied snippets, abandoned packages | No clear permission to use, modify or distribute | Ownership and permission may be unclear, especially in core product paths |
The risk is not the name of a licence in isolation. GPL or AGPL in an internal tool may be low risk. The same obligation inside a distributed proprietary product, embedded client, appliance, SDK or customer-hosted deployment can be materially different. Context matters.
Why do GPL and AGPL worry acquirers?
GPL and AGPL obligations matter because they can create source-sharing duties that sit awkwardly with proprietary software economics. In a transaction, the buyer may be acquiring recurring revenue, customer contracts and product IP on the assumption that the code can remain closed. A poorly understood copyleft dependency can challenge that assumption.
AGPL receives particular attention in SaaS because network use can be relevant. That does not mean every AGPL component is a deal breaker. It does mean the target should know where the component is used, whether it was modified, whether customers interact with it, and what counsel thinks the obligation means for the product model.
The measured position is important. Open source licence compliance rarely kills a deal on its own. It more often changes the disclosure schedule, remediation plan, warranty language, holdback discussion or post-close budget. Severe issues tend to appear when critical product functionality depends on code that cannot be used as currently sold.
Red flags include no dependency inventory, no approval process for high-obligation licences, copied code with unclear origin, packages that appear in production but not in the data room, and management statements that all open source is "free" without qualification.
How do SBOMs and dependency scanning help?
A software bill of materials, or SBOM, is an inventory of software components used in a product. In open source due diligence, an SBOM helps acquirers see direct and transitive dependencies, associated licences, package versions and sometimes vulnerability exposure. It is a starting point for questions, not the whole answer.
Dependency scanning tools are useful because modern software pulls in large dependency trees. A single application may include hundreds or thousands of packages once transitive dependencies are included. Manual review alone will miss things. Scanning can flag licence categories, missing notices, vulnerable package versions and duplicate or abandoned components.
Tools still need judgement. Scanners can misclassify licences, miss copied source files, overlook generated code, or treat development-only packages as if they were shipped to customers. Reviewers should reconcile tool output with repository structure, build artefacts, deployment patterns and engineering explanations.
The technical due diligence checklist should therefore request both the inventory and the process behind it. Who owns the SBOM? How often is it refreshed? Which systems are included? How are exceptions approved? What happens when a high-risk package is found?
How does code provenance affect IP value?
Open source compliance overlaps with software IP ownership. A buyer needs confidence that the company owns what it claims to own and has permission to use what it does not own. Provenance review asks where material code came from and whether that history is visible enough to rely on.
Contractor code is a common diligence area. If an agency or freelancer introduced substantial components, the repository history, contracts and assignment records should align. If they do not, legal counsel may need to test whether the company has the rights it thinks it has.
AI-generated code adds a newer provenance question. The issue is not that AI-assisted development is automatically unsafe. It is whether the company has a policy, whether sensitive proprietary code was pasted into external tools, whether generated output was reviewed before use, and whether developers understand the risk of reproducing third-party code patterns without attribution or permission.
In practice, provenance risk is highest where teams have copied snippets from forums, used unapproved packages to move quickly, relied on contractors without clean handover records, or introduced AI-assisted code without review. The commercial concern is not moral purity. It is whether the buyer can defend ownership and keep operating without surprise claims or remediation cost.
What remediation paths are realistic?
Most open source findings are manageable if they are found early. The right remediation depends on severity, product architecture and deal timing.
- 1Notice and attribution clean-up: Add missing notices, update third-party licence files and improve customer-facing disclosures.
- 2Package replacement: Swap a high-obligation or unsupported dependency for a lower-risk maintained alternative.
- 3Isolation or architectural change: Move a component out of a distributed product path or isolate it behind a service boundary where appropriate.
- 4Commercial licensing: Negotiate a paid licence or vendor agreement where a source-available or dual-licensed component is strategically important.
- 5Policy and tooling improvement: Establish scanning, approval thresholds, SBOM ownership and release checks so the issue does not recur.
The deal implication depends on timing. A missing notice file may be a pre-close housekeeping item. A core AGPL component embedded in customer-delivered proprietary software may require legal review, engineering effort and a negotiated remediation plan. A vague inventory in a small investment may be acceptable if the post-investment plan explicitly addresses it.
FoundationState's work with Finex Advisory reflects the same principle: diligence should separate practical operating improvements from findings that change investment confidence. Open source issues should be framed by severity, likelihood, remediation effort and ownership.
How severe is open source risk in M&A?
Open source risk should be taken seriously without being exaggerated. A mature software company can use open source extensively and still be a strong acquisition target. The risk rises when management cannot explain what is in the product, when licence obligations are unknown, or when dependency choices conflict with the commercial model being bought.
For investors, severity usually depends on four questions. Is the component material to the product? Is the product distributed, customer-hosted or exposed through a network service? Can the target replace or isolate the component without disrupting customers? Is the issue already disclosed and managed, or is it a surprise discovered late in exclusivity?
A good diligence report should avoid blanket statements such as "open source is risky" or "copyleft is unacceptable". Instead, it should show the evidence, explain the obligation in business terms, identify who should validate the legal interpretation, and recommend a proportionate action. That turns a potentially emotive issue into a manageable deal decision.
Get an independent view before dependency risk becomes IP risk. Contact FoundationState to scope technical due diligence around open source licence compliance, SBOM evidence, dependency governance and code provenance before your next acquisition or investment.
Frequently Asked Questions
What open source licences are risky in an acquisition?
The riskiest licences are those whose obligations conflict with the buyer's intended product model. Strong copyleft licences such as GPL and AGPL need careful review when used inside proprietary, distributed or network-accessed products. Unlicensed code, copied snippets and source-available components with commercial restrictions can also create acquisition risk.
What is an SBOM and why do acquirers ask for one?
An SBOM is a software bill of materials: an inventory of components used in a product. Acquirers ask for one because it helps identify dependencies, licences, package versions and sometimes vulnerability exposure. It gives diligence reviewers a structured starting point for testing open source compliance and dependency governance.
Does AI-generated code create ownership risk?
AI-generated code can create ownership or confidentiality risk if teams use it without policy, review or provenance controls. The main diligence questions are whether proprietary code was shared with external tools, whether generated output was reviewed, and whether the company can show that material code in the product has a defensible origin.
