OSS license management is the discipline of identifying every open source license present in your software's dependency tree, checking each one against your organization's policy, and catching incompatible or unknown licenses before they reach a shipped product. Done well it is invisible; done badly, or not at all, it surfaces as a legal scramble during due diligence, an acquisition, or a customer security review. This guide lays out a workflow that keeps license risk in check without turning every dependency bump into a legal ticket.
Why this matters beyond legal
It is easy to file license management under "legal's problem," but the risk is engineering-shaped. A copyleft license like the GPL or AGPL can obligate you to release source you intended to keep proprietary. A missing attribution can breach even the most permissive license. And the moment you cannot enumerate your licenses, you cannot answer a customer questionnaire or an acquirer's due-diligence checklist without a fire drill. License data lives in the same place as your vulnerability data, so it makes sense to manage both from your dependency inventory.
Build a license inventory from your SBOM
The foundation is a software bill of materials that records, for every direct and transitive dependency, its name, version, and license. Package registries carry license metadata, and tooling can extract it during a build. The output is a list you can query: "which packages are GPL," "which have no declared license," "did anything change since the last release."
The item that deserves the most attention is not GPL; it is UNKNOWN. A dependency whose license could not be determined is the real hazard, because you cannot make a policy decision about a license you cannot see. Treat unknown-license packages as a blocking finding to investigate, not a warning to ignore.
Define policy in tiers
A workable policy sorts licenses into a small number of tiers rather than adjudicating each package individually.
- Allowed: permissive licenses that impose only attribution, such as MIT, Apache 2.0, BSD-2-Clause, and BSD-3-Clause. These flow through automatically. For a deeper look at one of them, see our note on what the MIT License means.
- Review: weak copyleft like MPL 2.0 or LGPL, which are usable but carry conditions worth a human check depending on how you link or distribute.
- Restricted: strong copyleft like GPL and AGPL, which require deliberate approval because of their source-disclosure obligations.
- Denied: licenses your organization has decided never to accept, plus the
UNKNOWNbucket until resolved.
Writing the policy once, as tiers, means most dependencies never need individual attention. Only the review and restricted tiers generate work, and that work is bounded.
Enforce in CI, not in a meeting
The failure mode of manual license review is that it happens too late: after the code is written, sometimes after it ships. Move the check into the pipeline. When a build introduces a new dependency, resolve its license, compare it against the tiers, and fail the build on a denied license or an unresolved unknown. This turns license management from a periodic audit into a continuous gate, and it gives developers feedback at the moment they add the dependency, which is when the choice is cheapest to change.
# conceptual CI gate: fail on denied or unknown licenses
sbom-scan --format cyclonedx \
--deny "GPL-3.0-only,AGPL-3.0-only" \
--fail-on-unknown \
--exit-code 1
Keep the gate honest by allowing scoped, expiring exceptions for the genuine edge cases, rather than adding blanket suppressions that quietly disable the check.
Handle attribution automatically
Even fully permissive licenses require you to preserve copyright and license notices in what you distribute. The reliable way to satisfy this is to generate a third-party notices file from your SBOM at build time, so the attribution is derived from the same source of truth as the rest of your dependency data. Hand-maintained notices files drift and are the most common way a team fails a license audit despite using only permissive dependencies. Automating the notices file removes that whole failure class.
Keep it current as dependencies change
Licenses are not static. A project can relicense between versions, a dependency you added under MIT can pull in a new transitive package under GPL, and a fork can carry different terms than the original. Because your dependency tree changes with every update, license checking has to run on every build, not once a quarter. Tooling that watches your manifests continuously, the same way a software composition analysis tool watches for new CVEs, keeps the inventory accurate without anyone remembering to re-run an audit.
FAQ
What is the difference between OSS license management and SCA?
Software composition analysis focuses on finding known vulnerabilities in dependencies. OSS license management focuses on the legal terms of those same dependencies. Modern tools do both from a shared dependency inventory, since they need the same underlying SBOM.
Which licenses are the riskiest to overlook?
Strong copyleft licenses like GPL and AGPL, because of their source-disclosure obligations, and any dependency with an UNKNOWN or missing license, because you cannot make an informed decision about terms you cannot see.
How often should I check licenses?
On every build. Dependency trees change constantly, and a single version bump can introduce a new transitive dependency under a different license. Continuous checking in CI is far more reliable than periodic manual audits.
Do I need to comply with the MIT License if I only use the software internally?
The attribution obligation attaches to distribution and to substantial portions you copy. Purely internal use with no redistribution triggers fewer obligations, but building the attribution into your process anyway is cheap insurance for the day you do ship.