Open-source licensing in a corporate SaaS codebase: a non-lawyer's guide that's actually right

Software teams add hundreds of dependencies. Most operate with a mental model that works until it doesn't: permissive licences (MIT, Apache) are fine; GPL is a red flag; stop there. That model misses three categories of risk increasingly common in production SaaS codebases — the AGPL trap, buried transitive dependencies, and the relicensing wave that changed terms on several widely-used infrastructure tools between 2021 and 2024.

Why this got harder after 2021

The licence landscape shifted when major open-source projects moved to commercial terms.

HashiCorp switched Terraform from MPL 2.0 to Business Source Licence (BUSL 1.1) in August 2023. Redis moved from BSD 3-clause to a source-available licence in 2024. Elasticsearch switched to SSPL in 2021, prompting AWS to fork it as OpenSearch under Apache 2.0. MongoDB adopted SSPL in 2018.

The pattern in each case was similar: a successful open-source project reached a point where the maintaining company's commercial interests conflicted with cloud providers offering the same software as a managed service. Relicensing followed. Forks emerged — OpenTofu from Terraform, Valkey from Redis. Engineers who had added these tools years earlier found themselves under different terms without noticing.

The operational problem is not always with the library itself (Terraform's CLI is rarely a direct dependency in a product's code). The problem is the habit it exposes: most teams audit dependencies once, add them to a package manager, and never revisit the licence. What was Apache 2.0 in 2021 might be BUSL now.

The four licence families that actually determine your risk

Permissive licences (MIT, Apache 2.0, BSD, ISC) place no restrictions on commercial use. Keep the copyright notice. For Apache 2.0, include a NOTICE file when you distribute. For a SaaS product where you never distribute, even that requirement doesn't trigger. These are safe anywhere in your stack.

Weak copyleft licences (LGPL, MPL 2.0, EPL 2.0) apply copyleft only at the library boundary. If you use an LGPL library without modifying its source, the copyleft does not spread to your codebase. If you do modify the library, those modifications stay LGPL. Most Java ecosystems and some JavaScript packages carry LGPL components. For SaaS, they are generally safe when the library is used unmodified.

Strong copyleft licences (GPL v2 and v3) require that any work incorporating the licenced code be distributed under the same terms. The trigger word is distributed. In a SaaS deployment, software runs on your servers; users interact over HTTP but never receive the code. GPL's trigger does not fire. This is the SaaS loophole, and it is real.

Source-available licences (BUSL 1.1, SSPL, licences with Commons Clause additions) are not OSI-approved open source. They look like open source (GitHub repository, licence file, package registry listing) but carry commercial restrictions the Open Source Initiative has not certified. Treat them as proprietary with conditional terms, not as freely usable infrastructure.

GPL has a SaaS loophole. AGPL does not.

GPL's copyleft trigger is distribution. When you deploy on your own servers and users interact via HTTP, you are not distributing software — you are running it yourself. GPL's trigger does not fire. This is confirmed by the licence text and the Free Software Foundation's own guidance. It is why GPL-licenced libraries exist in commercial SaaS backends without causing legal problems.

AGPL v3 was written to close this gap deliberately. Section 13 adds an explicit network service clause: users who interact with a modified AGPL program over a network must be offered the corresponding source.

The result: running modified AGPL software as a service triggers a source disclosure obligation even without distributing anything. Most corporate legal teams interpret 'corresponding source' broadly — often as the full application that links to the AGPL component. The conservative reading is: treat AGPL in a commercial SaaS codebase as a blocker that requires explicit legal clearance, not a default green light.

AGPL appears in more places than engineers expect. Several analytics platforms, observability tools, and database utilities have AGPL editions sitting alongside commercial ones. A package's README may not make this obvious. Run a scan.

Transitive dependencies: where the problem usually lives

Direct dependencies are easy to audit. The risk is usually two or three levels deeper.

A common pattern: your package.json shows library-x (MIT). library-x depends on utility-y (MIT). utility-y depends on helper-z (AGPL-3.0). Every direct dependency is MIT. The AGPL is in the transitive tree, invisible to a manual check.

Most teams discover this during M&A due diligence or when a general counsel requests a software bill of materials (SBOM) for the first time. Someone runs the scan, finds an AGPL dependency, and has to explain why it has been in production for 18 months.

The tooling for a full dependency scan is straightforward and runs in under a minute for most projects:

# Node.js / npm (installs globally once)
npx license-checker --production \
  --failOn 'GPL-2.0;GPL-3.0;AGPL-3.0;SSPL-1.0;BUSL-1.1' \
  --excludePrivatePackages

# Python
pip install pip-licenses
pip-licenses --format=markdown --order=license

# Multi-language and container scanning (Syft: https://github.com/anchore/syft)
syft dir:. -o cyclonedx-json > sbom.json

# Scan SBOM for blocked licences
grep -i 'agpl\|sspl\|gpl-[23]\|busl' sbom.json

Generate the SBOM as part of your build pipeline, not as an on-demand audit. Add it to your release artefacts: the snapshot from 18 months ago will tell you exactly when a licence changed.

Check the licence date, not just the licence name

A dependency audit asks the wrong question when it only asks 'what licence is this?' The better question is: what licence does this have now, and what licence did it have when we added it?

Licence changes are not always announced prominently. The Redis relicensing in 2024 was posted on a company blog; the actual licence file in the repository changed the same day. If you track semantic version bumps but not licence changes, you would not have noticed.

Three practices help:

1. When a dependency updates, check whether the licence changed, not just whether tests pass. Most package update tools (Renovate, Dependabot) surface version bumps but not licence changes.
2. For critical infrastructure dependencies (database clients, auth libraries, message queue clients), review the licence annually regardless of version changes. A library can change its licence without publishing a new version.
3. Archive the SBOM output as part of each release. The snapshot from 18 months ago tells you exactly when a licence changed relative to your deployment history.

A practical audit you can run today

# Quick AGPL/GPL check across Node projects in a monorepo
find . -name 'package.json' -not -path '*/node_modules/*' | while read f; do
  dir=$(dirname "$f")
  echo "=== $dir ==="
  cd "$dir" && npx --yes license-checker --production \
    --failOn 'AGPL-3.0;GPL-2.0;GPL-3.0;SSPL-1.0' \
    --excludePrivatePackages 2>/dev/null || echo "BLOCKED LICENCE FOUND"
  cd - > /dev/null
done

# Python: check all requirements.txt in project
pip install pip-licenses
pip-licenses | grep -E 'GNU Affero|GNU General|SSPL|Business Source'

Run this against your main repository. Most teams find at least one unexpected flag — usually a transitive AGPL dependency they did not knowingly add.

The policy: two lists and a CI gate

The policy does not need a committee. Three artefacts, kept in your repository, cover the majority of cases.

An allowlist of licences safe to use without review: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC, Python-2.0, LGPL-2.1, LGPL-3.0, MPL-2.0, EPL-2.0, CC0-1.0, Unlicense. These are safe for SaaS use without further legal involvement.

A blocklist requiring legal review before merge: GPL-2.0, GPL-3.0, AGPL-3.0, SSPL-1.0, BUSL-1.1, and any licence with a Commons Clause addition.

A CI step that runs the scanner and fails the build when a blocked licence appears. Engineers do not need to remember to run manual scans; the pipeline does it for them. Most blocked-licence findings have a permissively-licenced alternative. Occasionally legal clears an exception. Rarely, you remove the dependency.

The setup takes an afternoon. Licence issues surface in code review, where they take minutes to resolve, rather than in due diligence, where they take weeks.

Where this is heading

The trajectory from open source to source-available is not reversing. If anything, questions around AI training data, model weights, and generated-code ownership will add new licence dimensions that current frameworks do not clearly address. Several AI model licences explicitly restrict commercial deployment or fine-tuning without a commercial agreement — patterns that look familiar because they are. Building the audit habit now, while the surface area is manageable, is the straightforward move.