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

LicenceCommercial UseCopyleft ConditionSaaS Risk
MITFreely permittedNone — attribution onlyNone
BSD (2-clause/3-clause)Freely permittedNone — attribution variationsNone
Apache 2.0Freely permittedNone — plus patent licence grantNone
LGPL 2.1/3.0Permitted for applicationsModifications to library must be sharedLow if not statically linked
GPL 2.0/3.0Triggers copyleft on distributionCombined work must be GPL if distributedHigh for distributed software
AGPL 3.0Triggers copyleft on network useEntire stack must be open-sourced if offered as serviceVery high for SaaS
SSPLTriggers copyleft on service offeringAll code used to run the service must be open-sourcedVery high for any service
BUSL/Elastic LicenceRestricted commercial useNot open-source — commercial licence requiredRequires 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

  • 1
    Prevent — Licence Policy
    Establish 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.
  • 2
    Detect — Automated Scanning
    Integrate 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.
  • 3
    Remediate — Replace and Document
    When 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.

Open Source Red Flag
Building a SaaS product on an AGPL-licensed framework or infrastructure component and only discovering the licence implication during investor technical due diligence. AGPL-contaminated SaaS products either require open-sourcing the entire service stack or purchasing a commercial licence from the component vendor — potentially expensive and subject to the vendor's terms. Check every major framework and infrastructure dependency for AGPL status before beginning product development.

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.