When a private equity firm or strategic acquirer opens the data room on a software target, the spreadsheet of customer contracts and revenue multiples gets the attention. The dependency tree rarely does. That's a problem: modern codebases are 70-90% open source by volume, and a single mislicensed component — a GPL-licensed library statically linked into proprietary code, an AGPL package powering a SaaS backend, a "no license" file scraped from a random GitHub repo — can force a re-architecture, trigger source-code disclosure obligations, or blow a hole in the indemnification terms of a deal. Open source license audits have quietly become a standard line item in technical due diligence, sitting alongside code quality and security scans. Vendors like Mend.io (formerly WhiteSource) built their reputation on developer-facing software composition analysis (SCA), but M&A due diligence asks a different question than continuous CI/CD monitoring does: not "what changed this sprint," but "what license obligations does this entire codebase carry today, and can we prove it to counsel." This post breaks down where that gap shows up and how to close it.
What Is Open Source License Risk, and Why Does It Matter in M&A?
Open source license risk in M&A is the exposure a buyer inherits when a target's software incorporates open source components under terms that conflict with the buyer's commercial licensing model, chain-of-title representations, or planned use of the code. The clearest example is copyleft: code licensed under GPL-2.0, GPL-3.0, or AGPL-3.0 generally requires that derivative works be released under the same terms, and AGPL extends that obligation to software offered as a network service — a common trap for SaaS targets that never intended to open source anything. This isn't theoretical. In 2008, the Software Freedom Law Center sued Cisco over GPL violations in Linksys firmware, a case that ran for two years before settling. In 2021, the Software Freedom Conservancy sued Vizio over GPL-licensed code in its SmartCast TV software, a dispute that produced a landmark 2024 California appellate ruling affirming that GPL terms are enforceable as third-party beneficiary contract rights — meaningfully raising the legal stakes for anyone who ships copyleft code without complying with its terms.
How Often Do License Conflicts Actually Show Up in Target Codebases?
They show up in the majority of codebases scanned, not a fringe minority. Synopsys' long-running Open Source Security and Risk Analysis (OSSRA) report — built substantially from Black Duck's M&A and audit engagements — has consistently found that around half of audited codebases contain open source license conflicts, and roughly 30% contain components with no identifiable license or a custom, unreviewed license. Recent editions also report that 96% of scanned codebases contain open source at all, with open source making up over 75% of total code volume on average. Put those together and the arithmetic is uncomfortable for a buyer: a mid-sized target with a few hundred thousand lines of code will typically carry hundreds of open source components, and it is statistically likely that a meaningful fraction of them have license terms nobody in the company has reviewed, let alone reconciled with the product's commercial terms.
What Happens When License Risk Surfaces After a Deal Closes?
When it surfaces after signing, the buyer — not the seller — usually owns the fix, and the fix is rarely cheap. Post-close discovery of copyleft code embedded in a proprietary product can force engineering teams to re-implement or strip out functionality, delay planned integrations, and in the worst case trigger source-disclosure demands from a copyright holder or a nonprofit enforcement body like the Software Freedom Conservancy. This is precisely why representations and warranties around IP ownership and third-party code compliance are now standard in software M&A purchase agreements, and why buyers increasingly negotiate specific indemnification carve-outs or escrow holdbacks tied to unresolved open source findings rather than accepting a blanket IP rep. A license audit that happens during diligence — before the purchase price is set — shifts that leverage back to the buyer; one that happens after closing shifts the cost entirely onto whoever now owns the code.
Why Do Standard Due Diligence Checklists Miss This Risk?
They miss it because legal-led diligence checklists are built to review contracts and representations, not to parse source trees, and most SCA tooling only sees what's declared in a manifest. A legal team reviewing a target's IP assignment agreements and customer contracts has no visibility into whether a package.json, pom.xml, or requirements.txt file is even complete — and in codebases that predate modern dependency management, or that have been through multiple acquisitions themselves, it frequently isn't. Vendored libraries copied directly into a repo, minified JavaScript bundles with stripped attribution comments, forked GitHub projects with modified headers, and binary-only third-party components routinely fall outside manifest-based scanning entirely. A 2003 case still cited in this space, SCO Group v. IBM, is part of why source-level (not just manifest-level) auditing became a due diligence norm in the first place — it put the industry on notice that undocumented code provenance could become a multi-year legal liability.
How Does Mend.io Fit Into M&A Diligence, and Where Does It Fall Short?
Mend.io fits well into continuous, developer-integrated SCA — it plugs into CI/CD pipelines, reads dependency manifests and lockfiles, and flags license and vulnerability issues as code ships, which is exactly what it was designed for as a rebrand of WhiteSource in 2022. Where it falls short for M&A specifically is that it inherits the core limitation of manifest-based SCA: it's built to monitor declared dependencies going forward, not to forensically reconstruct the full open source footprint of a codebase that may have been developed over a decade, across multiple teams, without consistent dependency hygiene. Point-in-time due diligence needs source and binary scanning that catches copy-pasted snippets and undeclared components a manifest never recorded, and it needs output formatted for a legal or corporate development audience — a clean, defensible report a lawyer can attach to a disclosure schedule — rather than a developer ticket queue. Tools optimized for the "shift left, catch it in the PR" workflow aren't wrong for that job; they're just answering a different question than "what does this entire codebase actually contain, right now, for a deal closing in six weeks."
What Should a Real Open Source License Audit for M&A Include?
A real audit combines source, binary, and container scanning with legal-grade reporting, not just a manifest diff. That means scanning actual source code for embedded and vendored open source (not only declared dependencies), performing binary and container image analysis to catch compiled third-party components with no source manifest at all, cross-referencing every identified component against SPDX license identifiers to flag copyleft and unknown-license risk, and producing a report structured the way legal and corporate development teams actually consume findings — component inventory, license classification, conflict flags, and remediation priority, tied to specific files and repositories a buyer's counsel can reference in redlines. It should also happen early enough in the process to inform valuation and deal structure, not get bolted on during the final week before signing when there's no time left to negotiate around what it finds.
How Safeguard Helps
Safeguard is built for exactly this moment: a compressed diligence window where a buyer needs a defensible, complete picture of a target's open source exposure, not a developer dashboard. Safeguard scans source repositories, binaries, and container images together to build a full software bill of materials that includes components manifest-based tools miss — vendored code, forked libraries, and binary-only dependencies with no declared entry anywhere. Every component is automatically classified against SPDX license data, with copyleft, network-copyleft (AGPL), and unknown-license findings flagged and prioritized by the actual legal exposure they create, not just a generic severity score.
Because diligence teams need to hand findings to lawyers, not just engineers, Safeguard produces audit-ready reports mapped to specific repositories and files, suitable for attaching to disclosure schedules or informing indemnification and escrow terms during negotiation. And because the relationship doesn't end at signing, Safeguard's continuous monitoring carries forward post-close, so the buyer inherits ongoing visibility into the target's open source posture during integration — not a one-time snapshot that goes stale the day the deal closes. For acquirers who want license risk quantified before it's priced into a purchase agreement rather than litigated after, that combination — forensic-depth scanning plus legal-ready output plus continuous post-close coverage — is the difference between an audit that checks a box and one that actually protects the deal.