Modern software is built on open source. The average application includes hundreds of open source components. Each brings potential license compliance issues and security vulnerabilities. Here's how to assess open source risk in M&A.
The Open Source Reality
Typical findings in code assessments:
- 500-1000+ open source dependencies in a mid-size application
- 30-50% of code is open source, not proprietary
- 10-20 known vulnerabilities in dependencies (often more)
- 5-10 license types with varying obligations
This isn't necessarily bad—open source enables faster development. But it requires management and creates diligence obligations.
License Compliance Risk
License Categories
Open source licenses fall into categories with different implications:
Permissive (Low Risk):
- MIT, BSD, Apache 2.0
- Generally allow commercial use with attribution
- No requirement to open-source derived works
Copyleft (Higher Risk):
- GPL, LGPL, AGPL
- May require derived works to be open-sourced
- AGPL extends this to network use
- Interpretation and compliance can be complex
Proprietary/Custom (Varies):
- Custom licenses with specific terms
- May restrict commercial use or require fees
- Require individual assessment
Compliance Red Flags
- No license inventory: Company doesn't know what licenses they're using
- GPL in commercial product: May require open-sourcing proprietary code
- License conflicts: Incompatible licenses in the same codebase
- Missing attributions: Required notices not included
Security Vulnerability Risk
Dependency Vulnerabilities
Open source components regularly have security vulnerabilities discovered:
- New CVEs (Common Vulnerabilities and Exposures) published daily
- Popular libraries = popular attack targets
- Transitive dependencies (dependencies of dependencies) often overlooked
Assessment Approach
- Generate complete dependency inventory (including transitive)
- Scan against vulnerability databases (NVD, GitHub Advisory)
- Assess severity and exploitability of findings
- Review update and patching practices
Red Flags
- Critical/high vulnerabilities in production: Known serious issues not addressed
- Outdated dependencies: Components years behind current versions
- No update process: Dependencies never updated proactively
- End-of-life components: Using software that no longer receives security updates
Quantifying Open Source Risk
Translate findings to financial terms:
- License remediation: Replacing problematic components: $50K-$500K depending on scope
- Vulnerability remediation: Updating/patching dependencies: $25K-$100K
- Ongoing management: Tooling and process for dependency management: $20K-$50K annually
- Worst case: GPL violation could theoretically require open-sourcing proprietary code (rare, but material risk)
Case Study: The GPL Discovery
A buyer assessed a $20M B2B software acquisition. The target claimed fully proprietary technology.
Our scan revealed:
- 47% of the codebase was open source
- Three GPL-licensed libraries were linked into the core product
- Legal review suggested potential obligation to release source code
- 18 high-severity vulnerabilities in dependencies, some 2+ years old
Resolution:
- GPL libraries had to be replaced—$200K development cost
- Vulnerability remediation project—$75K
- Timeline: 4 months before "clean" product
- Purchase price reduced by $300K to cover remediation