Open Source Is in Almost Every Product
A modern software product typically incorporates hundreds of open-source components — frameworks, libraries, testing tools, build utilities, and infrastructure software. Each component comes with a licence specifying conditions for use. Most conditions are simple: attribution, licence notice preservation. Some conditions are commercially dangerous: copyleft obligations that can require open-sourcing an entire commercial product. Understanding which components carry which conditions and building a continuous compliance system is one of the most important and most overlooked IP management tasks for technology startups.
The Open-Source Licence Spectrum
| Licence | Commercial Use | Copyleft Condition | SaaS Risk |
|---|---|---|---|
| MIT | Freely permitted | None — attribution only | None |
| BSD (2-clause/3-clause) | Freely permitted | None — attribution variations | None |
| Apache 2.0 | Freely permitted | None — plus patent licence grant | None |
| LGPL 2.1/3.0 | Permitted for applications | Modifications to library must be shared | Low if not statically linked |
| GPL 2.0/3.0 | Triggers copyleft on distribution | Combined work must be GPL if distributed | High for distributed software |
| AGPL 3.0 | Triggers copyleft on network use | Entire stack must be open-sourced if offered as service | Very high for SaaS |
| SSPL | Triggers copyleft on service offering | All code used to run the service must be open-sourced | Very high for any service |
| BUSL/Elastic Licence | Restricted commercial use | Not open-source — commercial licence required | Requires commercial licence |
GPL Contamination — How It Happens
GPL contamination typically happens not through deliberate decision but through incremental dependency creep. A developer adds a GPL library to solve an immediate technical problem without understanding the licence implications. The dependency becomes deeply integrated over months. The contamination is discovered only when an automated scanner runs during Series A due diligence — at the worst possible time.
The contamination mechanism: GPL version 2 and 3 require that any software combined with GPL code and distributed to users must be released under GPL. The key question is what constitutes "combined." AGPL extends this to network use — even without distributing software to users, providing access to it as a service over a network triggers the copyleft obligation. This makes AGPL the highest-risk licence category for SaaS products.
Prevention — Three-Step Approach
- 1Prevent — Licence PolicyEstablish a written open-source use policy: MIT, BSD, Apache 2.0, ISC — approved; LGPL — conditional approval with architect review; GPL, AGPL, SSPL — not approved for incorporation in commercial product. Communicate to all developers and enforce through code review.
- 2Detect — Automated ScanningIntegrate licence scanning into your CI/CD pipeline. FOSSA, Mend, and Black Duck all offer integrations that flag non-compliant dependencies before they are merged. Run scans on every pull request and block merges introducing non-approved licences.
- 3Remediate — Replace and DocumentWhen a non-compliant component is identified, find a permissive alternative. Most GPL/AGPL components have MIT, Apache, or BSD equivalents. Document the remediation in your open-source bill of materials. Complete remediation before fundraising or due diligence begins.
What Investors Check
Sophisticated investors at Series A and beyond run automated open-source scans as part of technical due diligence. They look for: GPL or AGPL components in the commercial product; SSPL or Elastic-licensed components used without commercial licences; licence compliance failures (missing attribution notices); and inconsistencies between stated IP ownership and actual licence obligations. A clean scan report showing only permissive licences is a positive signal. A report showing AGPL contamination in a SaaS product is a due diligence red flag that can delay or kill a round.
Open-Source Contributions by Your Team
When employees contribute to open-source projects — submitting patches, creating plugins, maintaining public repositories — they may be granting rights in your company's IP to the project. Most major projects use Contributor Licence Agreements (CLAs) that require contributors to assign or broadly licence their contributions. Establish a policy requiring manager approval for open-source contributions made during company time or using company resources, and review any CLAs before signing.
For complete software IP protection guidance, read the Software and Digital Copyright guide and visit the Startup IP Hub.
Commercial Licences for Open-Source Tools
Several widely used open-source tools have adopted business model licences that are not truly open-source — including MongoDB (SSPL), Elasticsearch (Elastic Licence 2.0), HashiCorp tools (BUSL), and Redis modules (previously RSAL). These tools may appear free to use in development and testing but require commercial licences for production SaaS deployments. Startups that deploy these tools in production without commercial licences may be in breach of the licence terms, creating IP liability that surfaces during due diligence. Conduct a specific audit of all infrastructure and database tools used in your production environment to confirm their licence type and whether your use requires a commercial licence. The cost of commercial licences for individual tools is typically far less than the legal and business disruption cost of discovering an unlicensed deployment during a funding round. For complete guidance on software IP and all open-source compliance topics, visit the Startup IP Hub.
Building an Open-Source Compliance Culture
The most effective open-source compliance programmes are built on developer education rather than purely on automated scanning. When developers understand why GPL and AGPL licences create commercial risk — not just that they are flagged by a scanner — they make better licence decisions at the point of dependency selection rather than requiring remediation after the fact. Build a brief open-source licence training session into developer onboarding. Maintain a company wiki page listing approved licences with plain-language explanations of why each is approved or restricted. Celebrate compliance — when a developer identifies and replaces a non-compliant dependency, recognise that contribution as IP risk management, not just a technical task. Create a clear escalation path for licence questions so that developers who are uncertain about a component's licence have a quick route to legal guidance without having to delay their work. This cultural approach, combined with automated scanning in the CI/CD pipeline, creates the strongest practical defence against open-source compliance failures. For all software IP guidance, read the Software and Digital Copyright guide and visit the Startup IP Hub.