Every open source package a team pulls in carries a license string somewhere — a license field in a manifest, a LICENSE file in the repo root, or a classifier buried in package registry metadata. Those strings are inconsistent: "MIT", "MIT License", "The MIT License (MIT)", and "Expat" can all mean the same thing. To make license data usable for compliance policy, a scanner has to normalize that mess against a shared vocabulary. The SPDX License List, maintained by the Linux Foundation's SPDX legal team, is that vocabulary for the vast majority of open source tooling, including Snyk's License Compliance feature. This post walks through the publicly documented mechanics of how Snyk detects license metadata, maps it to SPDX identifiers, handles the licenses that don't fit, and turns the result into enforceable policy — based on Snyk's own product documentation rather than internal implementation details we can't verify.
What Is the SPDX License List, and Why Does Alignment to It Matter?
The SPDX License List is a curated registry of standardized short identifiers for software licenses — things like MIT, Apache-2.0, and GPL-3.0-only — maintained by the SPDX legal team under the Linux Foundation since the project's founding in 2010. It exists because free-text license strings are not machine-comparable: a tool can't reliably decide whether "GPL v3" and "GNU General Public License, version 3" impose the same obligations without a canonical mapping. The list also defines exception identifiers (like GCC-exception-3.1) and, starting with SPDX 2.1, a license expression syntax that lets a package declare compound terms such as (MIT OR Apache-2.0) or (GPL-2.0-only WITH Classpath-exception-2.0). Because SBOM formats (SPDX and CycloneDX) and most license-scanning tools reference these identifiers directly, staying aligned with the list is what allows license findings to be exchanged between tools, expressed in an SBOM, and matched against legal policy without ambiguity. Misalignment means two scanners can disagree on what a package's license even is.
How Does Snyk Detect License Information Before It Can Classify Anything?
Snyk's license detection starts at the same layer as its vulnerability scanning: the dependency graph built from manifest and lockfile parsing (package.json/package-lock.json for npm, pom.xml for Maven, requirements.txt/Pipfile.lock for Python, and equivalents for the other ecosystems it supports). According to Snyk's documentation, license data for each dependency is sourced from the package's published metadata in its registry — the license field in an npm package.json, the <licenses> block in a Maven POM, the classifiers in a PyPI package's metadata, and so on — rather than from parsing repository LICENSE files directly for every transitive dependency. This is a meaningful distinction: it means license accuracy is bounded by what publishers declared in registry metadata, which is also why a package with an empty or missing license field shows up as unlicensed even if its repository actually ships a LICENSE.md.
How Does Snyk Map Raw License Strings to SPDX Identifiers?
Snyk normalizes the free-text and shorthand strings pulled from package metadata against the SPDX identifier space, resolving common aliases and formatting variants to a single canonical identifier. A string like "Apache 2.0", "Apache License 2.0", or "Apache-2" is intended to resolve to the single SPDX identifier Apache-2.0; "BSD" variants get disambiguated toward specific identifiers like BSD-2-Clause or BSD-3-Clause where the metadata is specific enough to support it. This normalization step is what allows Snyk's dependency tree, which spans multiple ecosystems each with their own metadata conventions, to be filtered and reported on using one consistent identifier set instead of dozens of ecosystem-specific spellings. It's also the step most exposed to upstream metadata quality — if a package publishes a nonstandard or malformed license string, normalization can only do as much disambiguation as the SPDX list and its known aliases support.
What Happens When a License Isn't a Standard SPDX Identifier?
When a detected license string doesn't correspond to anything on the SPDX List, Snyk classifies it as an "Unknown" license rather than guessing or silently dropping it, and surfaces it as its own category in license reports and policy rules. This mirrors the approach the SPDX specification itself recommends for non-standard licenses: rather than forcing a fit into an existing identifier, the spec defines a LicenseRef- prefix convention for custom or proprietary license text that isn't on the official list, so that an SBOM can still reference it consistently even though it isn't part of the canonical registry. Proprietary licenses, custom "all rights reserved" terms, and packages with genuinely missing license metadata all fall into this bucket. Because copyleft obligations and legal risk are often concentrated in exactly the packages that don't cleanly match a known license, treating "unknown" as its own explicit category — rather than a silent gap — is what makes it possible to write a policy rule like "flag any dependency with an unknown or unrecognized license" instead of only being able to police the licenses you already expected to see.
How Does Snyk Turn SPDX Identifiers Into Enforceable Policy?
Snyk groups normalized SPDX identifiers into a small set of risk categories — broadly permissive, copyleft, and proprietary/unknown — and lets teams set policy actions (such as failing a build or opening a PR-blocking issue) per category rather than requiring a rule for every one of the hundreds of individual SPDX identifiers. A team can, for example, allow anything classified permissive (MIT, Apache-2.0, BSD-3-Clause), require manual review for copyleft identifiers (GPL-3.0-only, LGPL-2.1-only, AGPL-3.0-only), and block anything that resolves to unknown. This category layer sits on top of the SPDX identifier mapping described above: the identifier is the normalized fact, and the category is the policy-relevant interpretation of that fact. Keeping the identifier layer aligned with SPDX is what lets that categorization stay portable — the same GPL-3.0-only finding means the same thing whether it's viewed in Snyk's UI, exported to an SPDX-format SBOM, or handed to a legal team that references the SPDX List directly.
How Does This Alignment Stay Current as SPDX Updates Its List?
The SPDX License List is not static — the SPDX legal team periodically publishes new versions that add newly submitted licenses, add exception identifiers, and occasionally deprecate older identifiers in favor of more precise replacements (the historic GPL-3.0 identifier, for instance, was deprecated in favor of the more explicit GPL-3.0-only and GPL-3.0-or-later). For a scanner's classifications to stay meaningful, its underlying license database has to track these revisions rather than freezing on whatever version of the list it launched against; otherwise, newly-submitted licenses in packages would fall into "unknown" indefinitely, and deprecated identifiers would keep surfacing in new reports after the canonical list has moved on. Snyk's documentation describes maintaining and updating its license database as an ongoing part of the product rather than a one-time import, which is the mechanism that keeps its classifications from drifting away from the current SPDX List over time. Any tool in this space faces the same structural requirement: SPDX alignment is a maintenance commitment, not a feature you ship once.
How Safeguard Helps
License classification is only as trustworthy as the metadata and mapping logic behind it, and that logic is difficult for any single team to audit from the outside — which is exactly why understanding the mechanics matters before you build compliance policy on top of it. Safeguard approaches software supply chain risk from the same principle: findings should be traceable back to a verifiable source rather than treated as a black-box verdict. For teams building or reviewing license compliance programs, Safeguard helps by continuously monitoring the open source components in your software supply chain, surfacing license and provenance data in standard formats like SPDX and CycloneDX so it can be cross-checked against other tools rather than trusted blindly, and flagging components with missing, ambiguous, or high-risk license metadata before they reach production. Combined with Safeguard's broader supply chain security posture — dependency provenance verification, SBOM generation, and vulnerability correlation — this gives security and legal teams a second, independently verifiable view of license risk, rather than a single point of failure in one vendor's classification pipeline.