Open-source licence compliance in a corporate codebase: what engineers actually need to know
The four licence families, why AGPL keeps catching SaaS teams by surprise, and a three-step setup to pass enterprise security questionnaires
If you've built a SaaS product, you've pulled in dozens, probably hundreds, of open-source dependencies. Most of your team has never read a single licence file. That has worked fine for years.
It stops working the day your first enterprise prospect sends a security questionnaire, or when a strategic investor's legal team asks for an SBOM during Series B due diligence. From that point on, 'we just use npm install' is not an answer.
Open-source licence compliance is not a legal formality. It's a sales prerequisite. This guide covers what the four licence families mean for a SaaS company, the one that catches most startups by surprise, and a three-step setup to get compliant in a week without a lawyer on retainer.
The four licence families that matter
Open-source licences sort into four families. The distinctions matter more for software companies than for individual developers.
Permissive licences (MIT, Apache 2.0, BSD variants, ISC) are the most common and least restrictive. You can use, modify, and ship permissive-licensed code in a proprietary SaaS product without opening your source. The only requirements are preserving copyright notices and, for Apache 2.0, including the licence text with any distribution. For a server-side SaaS, the distribution clause rarely applies.
Weak copyleft (LGPL, Mozilla Public License 2.0) requires you to publish modifications you make to the licensed library, but not to your application code that uses it. If you install an LGPL package via your package manager and don't modify it, your obligations are close to zero. If you fork it and ship your fork, you must open-source the fork.
Strong copyleft (GPL v2, GPL v3) requires that any software you distribute incorporating GPL-licensed code must also carry the GPL. 'Distribute' means shipping binaries, Docker images, or client-side JavaScript bundles. A pure server-side SaaS that never ships code to end users sits in a grey area under the traditional GPL interpretation.
Network copyleft (AGPL v3) closes that grey area deliberately. If users interact with your software over a network, which is every web application, the AGPL requires you to provide the complete source code even if you never distribute a binary. Using AGPL-licensed code on your backend technically obligates you to publish your source.
A fifth category has emerged more recently: source-available licences. SSPL, adopted by Redis in 2024, is broadly equivalent to AGPL with additional requirements. BUSL, adopted by HashiCorp's Terraform and Vault in 2023, allows free use for almost everything except competing commercial offerings and converts to a permissive licence after a defined period, typically four years. Neither is OSI-approved open source.
| Family | Key examples | SaaS server-side: freely use? | Enterprise risk |
|---|---|---|---|
| Permissive | MIT, Apache 2.0, BSD, ISC | Yes (preserve copyright notice) | None: pre-approve |
| Weak copyleft | LGPL, MPL 2.0 | Yes — publish modifications to the library only | Low — review on first use |
| Strong copyleft | GPL v2, GPL v3 | Grey area — server-side may be exempt; distributing binaries is not | Medium — review each case |
| Network copyleft | AGPL v3 | No — network interaction triggers source disclosure | High — get a commercial licence or swap |
| Source-available | SSPL, BUSL | Depends — SSPL similar to AGPL; BUSL blocks competing commercial use | Medium to high — needs legal review |
The AGPL trap, and why it keeps growing
The pattern is predictable. An open-source project achieves scale under a permissive licence, then relicences to AGPL or BUSL to stop cloud providers from running it commercially without contributing back. It happened with Elasticsearch in 2021, HashiCorp tools in 2023, and Redis in 2024. It will happen again.
What catches startups is not the headline relicensing event, which lands on Hacker News for a day. It's the transitive dependency problem. When you install a package, you get that package plus everything it depends on. A single top-level addition can pull in 40 transitive dependencies. Your team reviewed one licence. The dependency tree has 40 more that nobody checked.
Specific examples that have bitten teams: MinIO, widely used for self-hosted object storage, is AGPL-licensed. Several database drivers updated their licences in 2023 without much notice. WireGuard-go is MIT, but the kernel module it wraps is GPL-2.0-only, a distinction that matters if you distribute the kernel to customers.
AI coding tools added a layer to this problem
A meaningful share of new library additions in active codebases now comes from AI coding tool suggestions. A developer asks Cursor to wire up file-upload handling; Cursor suggests two libraries; the developer accepts. Nobody checked either licence. The library is added to package.json, passes CI, ships to production.
This is not a failure of intent. There is no step in the AI suggestion workflow that surfaces licence information. The model was trained on code that largely lived under permissive licences and has no mechanism to flag a licence risk. The only reliable defence is automation: a CI gate that fails on new AGPL, GPL, or SSPL additions unless they're explicitly allowlisted. Humans don't reliably audit licence files on every dependency update. A CI check does.
What enterprise procurement checks for licence compliance
When you enter an enterprise sales process, you'll hit one of three tiers depending on the buyer's security posture.
Tier one is the standard security questionnaire. It includes a question like: 'Do you use any open-source software with copyleft licensing?' The expected answer is not 'no', which is almost certainly false and a competent buyer will know it. The expected answer is: 'Yes, we've reviewed our dependencies and mitigated or documented our specific exposure.'
Tier two is an SBOM request. The customer wants a Software Bill of Materials: a structured list of every software component, its version, its licence, and its known vulnerabilities. SBOMs come in two formats: SPDX, used in US government procurement contexts, and CycloneDX, the OWASP standard that's more widely used in commercial tooling. Most enterprise customers accept CycloneDX JSON.
Tier three is a full vendor security review, where an external auditor examines your codebase or infrastructure directly. Having a current SBOM shortens this process by a week, sometimes more.
For Indian SaaS companies selling into US enterprise in 2026, tier one is the immediate reality. Tier two is increasingly common in deals above roughly 50,000 USD ACV. EU customers subject to the Cyber Resilience Act will require SBOMs for products sold into the EU from 2027.
The three-step practical setup
1. Know what you have today
Run a licence scanner against your current dependencies. The results will surprise you.
# Node.js
npx license-checker --csv > licenses.csv
# Python
pip-licenses --format=csv > licenses.csv
# Rust
cargo license
# Go
go-licenses report ./...Look specifically for AGPL, GPL, LGPL, SSPL, BUSL, and any 'unknown' entries. For each one, make a decision: obtain a commercial licence, swap to a permissive alternative, or document explicitly why the exposure doesn't apply. Write the decision down, even if the decision is 'accepted risk'.
2. Add a CI gate
# license-checker (Node) -- fail on new AGPL or GPL additions
npx license-checker \
--failOn 'AGPL-3.0;GPL-3.0;SSPL-1.0' \
--excludePackages '[email protected]'For polyglot codebases or teams that want a managed approach, FOSSA and Snyk's licence scanning provide a review workflow, SBOM export, and PR comments when a new addition needs sign-off. More configuration upfront; less manual triage ongoing.
3. Write a one-page OSS licence policy
Three clauses: what's pre-approved for use without review (MIT, Apache 2.0, BSD variants, ISC, MPL 2.0), what requires engineering lead sign-off before a dependency is added (LGPL, BUSL), and what's prohibited without legal review (AGPL, GPL, SSPL). Post it in your internal wiki. When a security questionnaire asks 'Do you have an open-source software policy?', this document is the answer.
The two things to do before your first enterprise call
Generate your SBOM and store it as a CI artifact. Syft (anchore/syft) produces CycloneDX and SPDX SBOMs from container images or package manager lock files. Wire it into your release pipeline so you generate a fresh SBOM on every deployment and store it alongside the build artifact.
syft your-image:latest -o cyclonedx-json > sbom.jsonKnow your one commercial exception. Most engineering teams find one dependency in their initial scan they can't easily replace: an AGPL analytics library, an SSPL storage engine, something that's become load-bearing in the stack. For each such dependency, either buy the commercial licence (pay once; the copyleft obligation lifts for your organisation), swap to a permissive alternative, or document why the AGPL obligation doesn't apply to your specific use case. This documented decision is more useful to a buyer's legal team than a theoretically clean scan.
The goal is not a perfect compliance posture. It's a defensible one: you know what you have, you have a process that catches changes, and you can explain your decisions in plain language when the security questionnaire asks.
Frequently asked questions
Related reading
DPDP Rules 2025 for engineers: what you actually have to change in your codebase
Most DPDP guides are written for DPOs, not engineers. Here are the six technical obligations the DPDP Rules 2025 create — what each one requires from your backend, which phase it activates in, and where to start.
What the ESOP grant letter doesn't tell you
Most Indian startup engineers receive an ESOP grant, pocket the letter, and assume the equity is worth the headline number. It usually isn't. Here is what to actually check before you exercise or resign.
DPDP Rules are live. Here is what your backend actually has to change.
The DPDP Rules were notified in November 2025 and most Indian SaaS teams are treating May 2027 as comfortable. It isn't. Here is what the Rules actually require you to build, in priority order.