Software due diligence on open source components addresses a risk that perpetual and subscription diligence both miss: the obligations that attach to free software. Open source is not the same as no cost. Software due diligence on open source components examines the licenses that govern the open source a target has built into its products and operations, the obligations those licenses create, and the risk that the target has not met them. The exposure is rarely a bill from a vendor. It is the obligation to disclose source code, the risk to proprietary intellectual property, and the security debt that rides along with unmanaged components.
This guide explains how to run that review, as part of the broader software due diligence method. It complements the commercial licensing work and matters most where the target is itself a software business whose value lives in its code.
What software due diligence on open source components examines
The review has three strands. The first is license obligation: what each open source license requires, from simple attribution under permissive licenses to source disclosure under strong copyleft. The second is compliance: whether the target has actually met those obligations in the way it distributes or hosts its software. The third is provenance and security: whether the components are known, maintained, and free of unpatched vulnerabilities. A target can be commercially clean on its paid software and still carry serious open source exposure in all three strands.
Why copyleft obligations carry the most risk
The licenses that matter most in diligence are the strong copyleft ones, because they can require a target to make its own source code available when it distributes software that incorporates the component. For a software business whose value sits in proprietary code, an unmanaged strong copyleft dependency is a direct threat to the asset being acquired. Permissive licenses, by contrast, usually require only attribution and carry little commercial risk. The job of the review is to find where copyleft obligations apply and whether the target has handled them, not to flag every open source package as a problem.
How open source exposure hides
Open source exposure hides for the same structural reason as latent licensing exposure: it lives in the code and the build, not in a contract the target can hand over. There is no vendor invoice for a copyleft library and no renewal notice for an unpatched dependency. The obligations are real but undocumented, and a target that has never run a software composition analysis genuinely may not know what it is carrying. A diligence that asks only for contracts will see none of it, which is why the open source strand needs its own method.
Key takeaways
- Open source is free of cost but not free of obligation. The risk is source disclosure, intellectual property, and security debt.
- Strong copyleft licenses carry the most risk because they can require a target to disclose its own proprietary source.
- Open source exposure lives in the code and the build, not in any contract the target can hand over.
- A target with no open source inventory or policy carries systemic risk that needs a remediation programme.
Measure with composition analysis, not representations
As with commercial licensing, the cure is measurement rather than questions. A software composition analysis scans the target codebase and build artefacts to produce an inventory of components, their licenses, and their known vulnerabilities. That inventory is the open source equivalent of the effective license position: it turns an unknown into a documented set of obligations the buyer can assess. Relying on a management representation that the target is compliant repeats the same false comfort error that hides commercial exposure, and should be avoided for the same reason.
Weigh the exposure against deal type
Open source risk weighs differently depending on what the buyer is acquiring. For a software business whose product ships to customers, a strong copyleft obligation in the distributed code base is a core risk to the asset. For an operating business that uses open source internally without distributing it, the same license may create little obligation, because the triggering event of distribution never happens. The review should frame each finding in terms of what the target actually does with the component, so the buyer weighs real obligations rather than theoretical ones, the same proportionality the legal and commercial diligence distinction calls for.
From finding to remediation plan
Open source findings convert into the same deal levers as commercial exposure. A serious copyleft obligation may justify a price adjustment, a specific indemnity, or a condition that the target remediate before close. A missing inventory justifies a post close remediation programme. The output of the review should be a prioritised remediation plan, not a raw component list, so the buyer knows which obligations to fix first and which can be managed over time. That plan carries into integration alongside the license reconciliation work.
Recommendations for buyers
- Run a software composition analysis rather than relying on a representation that the target is compliant.
- Prioritise strong copyleft obligations in distributed code, where the threat to intellectual property is greatest.
- Frame each finding by what the target actually does with the component, distribution versus internal use.
- Produce a prioritised remediation plan and carry it into the post close integration work.
Assess the target processes, not just the snapshot
A composition analysis captures the open source position on the day it runs, but the more telling question is whether the target has a process to manage open source at all. A business with a maintained inventory, a license policy, and a routine for reviewing new dependencies is carrying a managed risk that will stay managed after close. A business with none of these has a position that degrades continuously, because every new build can introduce a new obligation no one is tracking. The diligence should assess both the snapshot and the process behind it, because a clean snapshot with no process is a temporary state, while a manageable snapshot with a strong process is a durable one. For a software target, the maturity of open source governance is itself part of the asset quality.
Connect open source risk to the product roadmap
Open source obligations interact with what the target plans to do next. A component used internally today may become a distribution risk the moment the target ships the feature that depends on it, which a product roadmap will reveal. A copyleft dependency buried in a module the target intends to expose through a new product is a future exposure that a snapshot of current use will miss. The review is sharper when it reads the roadmap alongside the composition analysis, so the buyer understands not only the obligations the target carries now but the ones its own growth plan will trigger. This forward view matters most in exactly the deals where open source matters most: the acquisition of a software business that intends to keep building.
Why independence improves the open source review
An open source review built for the buyer alone focuses on the obligations that threaten the asset and the realistic cost of meeting them. An independent, buyer side advisor has no incentive to overstate a remediable attribution gap or to understate a serious copyleft threat, and presents a proportionate, prioritised view the deal team can act on. That neutrality is what turns a long component list into a usable assessment of open source risk.