Software licensing models are not just a legal or billing question; they are a supply-chain risk you inherit the moment you add a dependency. Every package you pull into a build arrives with a license that dictates what you may do with the code, what you must disclose, and — less obviously — what happens to your legal footing if the project changes its terms or gets abandoned. Teams that treat licensing as the lawyers' problem end up shipping copyleft code into proprietary products, or depending on a package whose license flipped overnight, and only discover it during an acquisition or an audit.
This guide walks through the main software licensing models, the practical obligations each imposes, and why license data belongs in the same inventory as your vulnerability data.
The families of license
Open-source licenses split into two broad camps, with a few hybrids and the proprietary world alongside them.
Permissive licenses — MIT, BSD (2- and 3-clause), Apache 2.0 — let you use, modify, and redistribute the code, including inside closed-source products, with minimal obligations. Usually you must preserve the copyright notice and license text. Apache 2.0 adds an explicit patent grant and a requirement to state significant changes, which is why enterprises often prefer it over MIT for larger dependencies.
Copyleft licenses — the GPL family, LGPL, MPL, AGPL — require that derivative works be released under the same license. This is the "viral" property people worry about. GPLv3 obligates you to release the source of anything you distribute that links against GPL code. AGPLv3 goes further: it triggers the disclosure obligation even when you only offer the software over a network, closing the "SaaS loophole" that let companies use GPL code as a hosted service without sharing source. If you run a SaaS product, AGPL dependencies are the ones to watch most closely.
Weak copyleft — LGPL, MPL 2.0 — is the middle ground. LGPL lets you link a library into proprietary code as long as the LGPL library itself stays open and replaceable. MPL 2.0 applies copyleft at the file level, so only the files you modify carry the obligation.
Proprietary and commercial licenses grant specific, negotiated rights and usually forbid redistribution or modification. Perpetual, subscription, and usage-based (metered) licenses are all variants here; the security-relevant point is that they often restrict your ability to audit or patch the code yourself.
Dual licensing and the relicensing trap
Some projects ship under a dual-license model: an open license (often GPL or AGPL) for community use and a paid commercial license for companies that want to avoid the copyleft obligations. MySQL and Qt are long-standing examples. Dual licensing is fine — until you assume you're on the permissive branch when your usage actually falls under the copyleft one.
More consequential in recent years is relicensing. A project that starts permissive can change its terms, and your existing dependency version keeps its old license while every new release carries the new one. The wave of moves to "source-available" licenses — the Business Source License (BSL) used by MariaDB and adopted by others, the Server Side Public License (SSPL) that MongoDB adopted, and Elastic's shift for Elasticsearch — caught many teams off guard. These licenses are not OSI-approved open source; SSPL and BSL restrict how you can offer the software as a service. If your dependency pins to an old version and you upgrade without checking, you can cross a licensing line unknowingly. Track the license per version, not per package.
Why software licensing models are a security concern, not just a legal one
Three concrete reasons license data belongs next to vulnerability data.
First, patchability. If a dependency's license forbids modification or the project goes commercial-only, your ability to apply a security patch yourself is constrained. A vulnerable, abandoned, permissively licensed package you can fork and fix is a very different risk than one you legally cannot touch.
Second, abandonment and maintenance signal. License changes frequently accompany governance changes — a company taking control, a maintainer walking away, a fork splitting the community. Each of those events shifts how quickly security fixes will arrive. When Elasticsearch relicensed, the OpenSearch fork emerged and the two now patch on different schedules; which one you depend on determines your CVE response time.
Third, compliance gates in regulated environments. If you operate under SOC 2, FedRAMP, or similar regimes, you're expected to know your software provenance. An unknown or non-compliant license in a component is an audit finding in its own right, independent of any CVE. Our compliance material in the Academy covers how license attestations feed those audits.
Tracking licenses with an SBOM
You cannot manage what you cannot see, and license obligations hide in transitive dependencies just as vulnerabilities do. A software bill of materials (SBOM) in CycloneDX or SPDX format records the license of every component, direct and transitive. Generating one is a one-command step in most ecosystems:
# CycloneDX for a Node project
npx @cyclonedx/cyclonedx-npm --output-file sbom.json
# Syft for a container image, SPDX output
syft myimage:latest -o spdx-json
With the SBOM in hand, enforce a policy: block builds that introduce a license on your deny-list (say, AGPL or SSPL for a proprietary product), and flag any license change between versions. Tooling makes this a gate rather than a quarterly scramble — an SCA platform such as Safeguard reads the license field alongside the vulnerability data, so a policy-violating license fails the same pipeline check that a critical CVE would. The point is to catch the GPL-into-proprietary mistake at the pull request, not at the acquisition due-diligence stage.
A practical policy
Keep it simple enough that developers can follow it without a lawyer on speed-dial:
- Allow permissive licenses (MIT, BSD, Apache 2.0) freely.
- Allow weak copyleft (LGPL, MPL) with review of how you link.
- Require legal sign-off for strong copyleft (GPL, AGPL) in anything you distribute or host.
- Deny source-available licenses (SSPL, BSL, Elastic License) in products you ship or offer as a service, unless commercially licensed.
- Re-check the license on every version bump, not just on first add.
Write it down, encode it as an SBOM policy, and let the pipeline enforce it.
FAQ
What are the main software licensing models?
Broadly: permissive open source (MIT, BSD, Apache 2.0), copyleft open source (GPL, LGPL, AGPL, MPL), dual/commercial licensing where a project offers both open and paid terms, and proprietary licenses (perpetual, subscription, or usage-based). Source-available licenses like SSPL and BSL are a newer category that is not OSI-approved open source.
Which open-source license is riskiest for a SaaS product?
AGPL is the one to watch, because its network-use clause triggers source-disclosure obligations even when you only offer the software over a network rather than distributing it. Source-available licenses like SSPL also restrict offering the software as a service.
Can a dependency's license change after I've adopted it?
Yes. Projects relicense — MongoDB moved to SSPL, Elasticsearch to the Elastic License, MariaDB uses BSL. Your pinned version keeps its old license, but any upgrade adopts the new one, so track the license per version and re-check on every bump.
How do I track licenses across all my dependencies?
Generate an SBOM (CycloneDX or SPDX) that records each component's license, including transitive ones, and enforce a license policy in CI. An SCA tool can gate builds on disallowed licenses the same way it gates on vulnerabilities.