When a scanner flags a dependency as GPL-3.0 licensed, is that a blocker or a footnote? The answer depends entirely on how the tool doing the flagging decides to score it — and Snyk's open-source license compliance engine has a specific, documented answer to that question. Rather than treating every non-permissive license as equally dangerous, Snyk groups thousands of SPDX-identified licenses into risk categories, then maps those categories onto its familiar low/medium/high/critical severity scale — the same scale it uses for vulnerabilities. That consistency is deliberate: it lets security and legal teams triage license findings inside the same workflow, dashboards, and policy engine they already use for CVEs. This piece walks through how that classification actually works — what determines a license's default category, how organizations override it, and where the approach runs into real-world limits, particularly with transitive dependencies and license expressions that don't map cleanly to a single risk tier.
How does Snyk decide whether a license is risky in the first place?
Snyk starts from the license text itself, not the package's reputation or popularity. Its Open Source product identifies the declared license for a dependency — typically pulled from package manifests, SPDX license identifiers embedded in the package, or metadata registries like npm's package.json, Maven POM files, or PyPI's classifiers — and matches it against a maintained license database. That database groups licenses by the obligations they impose on downstream users: whether they require source disclosure, whether they permit commercial use without restriction, and whether they carry "viral" copyleft terms that could obligate a company to release its own proprietary code. A permissive license like MIT or Apache-2.0 imposes almost no downstream obligations, so it sits at the low-risk end by default. A strong copyleft license like AGPL-3.0, which can require that even network-accessed modifications be released under the same terms, sits at the opposite end.
What license risk categories does Snyk actually use?
Snyk's documentation describes license risk in terms of a small number of groupings rather than a flat list of hundreds of individual license types. Broadly, licenses fall into categories such as permissive (MIT, BSD-2-Clause, Apache-2.0, ISC), weak or "reciprocal" copyleft (LGPL-2.1, MPL-2.0, EPL-1.0), strong copyleft (GPL-2.0, GPL-3.0, AGPL-3.0), and an "unknown" or "none" bucket for packages where no license was declared or detected at all. That last category matters more than it might seem — a dependency with no discoverable license isn't automatically safe; from a legal-risk standpoint it's often treated as more uncertain than one with an explicit copyleft license, because there's no clear grant of rights to fall back on. Snyk's out-of-the-box policy typically treats unknown-license packages as worth flagging for manual review rather than silently passing them.
How does a license category turn into a severity level?
Each license group carries a default severity that Snyk applies automatically when it scans a manifest or lockfile, using the same low/medium/high/critical labels it assigns to vulnerabilities. In practice, permissive licenses generally default to no severity or informational status since they impose minimal compliance burden, weak copyleft licenses often land at medium because they require disclosure of modifications to the licensed component itself, and strong copyleft licenses like GPL-3.0 and AGPL-3.0 are commonly set to high or critical by default because of their broader reach into derivative and networked code. This mapping is what lets a license finding show up in the same severity-sorted issue list as a critical CVE — a legal/compliance risk and a security risk both compete for the same triage attention, which is the point: Snyk's model treats license exposure as a first-class risk dimension rather than a side report bolted onto vulnerability scanning.
Can organizations change how a license gets scored?
Yes — Snyk's license policy engine is built specifically to let organizations override the defaults rather than accept a fixed global ruleset. Through the Snyk web UI or the policy API, teams can set a custom severity for a specific license, mark a license as explicitly allowed or explicitly denied for their organization, and scope those rules to particular projects or the entire org. This matters because license risk is genuinely context-dependent: a company that only ships internal tooling and never distributes binaries externally may reasonably treat GPL-licensed dependencies as low risk, since GPL's copyleft obligations are typically triggered by distribution. A company shipping an embedded or on-prem product to customers faces a very different calculus for the same license. Snyk's policy configuration is the mechanism that lets the same underlying license database produce different severity outcomes for different business models, rather than forcing every customer into one legal team's judgment call.
Does the classification account for how a license was combined with other code?
Only partially, and this is one of the more meaningful limits of the approach as publicly documented. Snyk's engine identifies the declared license of each individual package in a dependency tree — including transitive dependencies pulled in indirectly — and reports on each one independently, including in lockfiles like package-lock.json, yarn.lock, or a Python requirements/poetry lockfile. What it does not claim to do is perform a full legal analysis of license compatibility across an entire dependency graph, such as determining whether combining an MPL-2.0 module with a GPL-2.0 module in a single build creates a compatibility conflict under either license's terms. Snyk's own guidance is that its scanning surfaces licenses for review and flags known-risky terms, but that compatibility questions spanning multiple interacting licenses are a legal determination the tool supports rather than fully automates. Some packages also carry dual or multi-license expressions (for example "MIT OR Apache-2.0"), and how a scanner resolves the "most permissive applicable option" versus flagging the ambiguity itself is a detail worth checking against current documentation rather than assuming.
Why does severity classification matter more than a simple allow/deny list?
A binary allow/deny list can't express the difference between "this license is worth a legal team's ten minutes" and "this license could force disclosure of proprietary source code," and that gap is exactly what severity scoring is designed to close. By expressing license risk on a graded scale, Snyk lets teams set thresholds — for instance, blocking a build only on critical-severity license findings while surfacing medium ones as a backlog item for legal review — instead of a single brittle rule that either blocks everything with any non-permissive term or catches nothing. This is also what makes license findings usable in CI/CD gates alongside vulnerability thresholds: a pull request can fail on "high severity or above" across both dimensions using one consistent policy statement, rather than maintaining two separate, incompatible rule systems for security bugs and legal terms.
How Safeguard Helps
Severity-scored license classification is a genuinely useful triage signal, but it's still one signal derived from declared metadata at a single point in the pipeline — and metadata can be missing, misdeclared, or overridden by an organization's own policy in ways that don't reflect what's actually running in production. Safeguard approaches software supply chain risk from the artifact and build-provenance level rather than relying solely on manifest-declared license fields, correlating what a scanner reports against what was actually built, signed, and deployed. For teams using Snyk or any other license-compliance tool, that means catching cases where a policy override quietly suppressed a real obligation, where a package's declared license doesn't match what shipped, or where a dependency entered the build through a path the manifest never surfaced. Compliance and security teams get a second, independent check on license and provenance claims — not a replacement for severity-based triage, but a way to verify that the triage is actually looking at the software that's really running.