Open source licenses are legal contracts, not suggestions — and a single GPL-licensed transitive dependency pulled into a proprietary codebase can create real obligations around source disclosure and redistribution. Snyk Open Source ships with a built-in license compliance engine that runs alongside its vulnerability scanner, checking every manifest and lockfile against a default policy the moment a project is imported. That policy isn't a black box: it's a configurable rule set built from SPDX license identifiers, three severity tiers, and per-license "instructions" that decide whether a match gets logged quietly, surfaces as a warning, or fails a build. Most teams never touch it and inherit Snyk's defaults, which lean toward flagging strong copyleft and unrecognized licenses. This post walks through how that default policy is structured, what triggers a failure versus a warning, and the concrete steps to customize it for your organization's actual legal risk tolerance.
What does Snyk's default license policy actually check?
Snyk's default license policy checks every open source dependency's declared license against a curated list of SPDX-identified licenses and assigns each one a severity and an enforcement instruction. When you run snyk test or snyk monitor, or when Snyk scans a repository via its GitHub, GitLab, or Bitbucket integration, it cross-references the license metadata pulled from the package registry (npm, PyPI, Maven Central, RubyGems, and others) against this policy table. The check happens in the same pass as vulnerability scanning, so license issues appear in the same project dashboard, the same PR check, and the same snyk test output as CVEs — they're just categorized under "license issues" rather than "security issues." This matters operationally: a failed license check can block a pull request merge or fail a CI pipeline exactly the way a critical vulnerability would, if the policy is configured to do so.
How does Snyk classify licenses by default?
Snyk classifies licenses into three severity buckets — low, medium, and high — based on the obligations each license imposes, and it ships with sensible defaults rather than leaving every license unassigned. Permissive licenses like MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, and ISC are typically categorized as low severity because they impose minimal redistribution or disclosure requirements. Weak copyleft licenses such as MPL-2.0, LGPL-2.1, and EPL-1.0 usually land at medium severity, since they only require source disclosure for modified files within the licensed component itself. Strong copyleft licenses — GPL-2.0, GPL-3.0, and AGPL-3.0 in particular — are the ones most default policies flag at high severity, because they can impose "viral" obligations that extend disclosure requirements to a larger combined work, which is a common concern for companies shipping proprietary software. Each severity tier maps to a default instruction: low severity licenses are generally allowed with no action, medium severity licenses trigger a warning, and high severity licenses are the ones most commonly configured to fail a check out of the box.
What happens when a license is unrecognized or missing?
When Snyk can't map a dependency's declared license to a known SPDX identifier, it treats the package as carrying an "Unknown License" and flags it for manual review rather than silently allowing it. This happens more often than teams expect — package metadata is frequently incomplete, a maintainer may use a non-standard license string, or a package.json/setup.py field may simply be blank. Because an unknown license represents legal uncertainty rather than a known-safe permissive grant, Snyk's default posture treats it as a risk signal worth surfacing, similar in spirit to how it treats strong copyleft licenses. Dual-licensed packages (for example, a library offered under either MPL-2.0 or a commercial license) are evaluated against whichever license identifier the package registry actually publishes in its metadata, which is why the same library can sometimes report differently across ecosystems if maintainers haven't standardized their SPDX declarations.
How do you customize the license policy?
You customize Snyk's license policy from the organization settings, where admins can change the severity and instruction assigned to any license already in the default table, or add licenses that aren't covered out of the box. For each license entry, there are typically three configurable instructions: ignore (no notification), warn (surface in the UI and reports without blocking anything), and fail (block the build or PR check, mirroring how a vulnerability threshold works). A common customization pattern is downgrading LGPL from a fail to a warn for organizations that only consume it as an unmodified dynamically-linked dependency, or conversely upgrading a permissive-but-unfamiliar license to a warn so legal review gets a signal before it becomes routine. Changes made at the organization level apply to newly scanned and re-scanned projects going forward; they don't retroactively rewrite historical scan results already stored for a project until that project is tested again. On plans that support more granular controls, policies can also be scoped to specific projects or groups rather than applied as a single blanket configuration across every repository in the org, which is useful for teams that maintain both open source and closed proprietary codebases under one Snyk organization with genuinely different tolerance for copyleft exposure.
How does license policy enforcement reach pull requests and CI pipelines?
License policy enforcement reaches pull requests and CI pipelines the same way vulnerability policy does — through Snyk's PR checks and the exit code returned by snyk test. When a git integration is connected, Snyk automatically opens a check on pull requests that introduce a new dependency, and if that dependency's license resolves to a "fail" instruction, the check reports a failure status that can be wired into required-status-check rules in GitHub or GitLab, blocking merge until someone resolves or explicitly overrides it. In CI, snyk test returns a non-zero exit code when a fail-severity license issue is found, which is what actually breaks the pipeline step if the license check is included in the build gate. It's worth noting this is a separate switch from vulnerability scanning: teams can run snyk test for vulnerabilities only, or include --severity-threshold and license-specific flags depending on how their pipeline is configured, so a fail-on-license posture has to be deliberately wired into the same gate rather than assumed to come free with vulnerability scanning.
What are the most common mistakes teams make when customizing this policy?
The most common mistake is treating the license policy as a one-time setup task rather than a living document that needs review as the dependency tree grows and legal guidance evolves. Teams frequently downgrade a high-severity license to "warn" during an initial rollout to reduce noise, then forget to revisit that decision, which quietly reintroduces the exact copyleft exposure the default policy was designed to catch. A second common issue is applying a single org-wide policy across genuinely different codebases — an internal tool that's never distributed externally has a very different GPL risk profile than a commercial SaaS product embedding the same library, and a one-size-fits-all policy either over-blocks the former or under-protects the latter. Third, teams often assume the "Unknown License" bucket is a temporary scanning gap rather than a permanent category that needs an actual triage process, letting flagged packages accumulate without ever getting a legal determination on record.
How Safeguard Helps
Snyk's license policy engine is a strong first layer, but it's scoped to what Snyk itself can scan, and license risk in a modern software supply chain rarely stays inside one tool's boundary. Safeguard gives security and legal teams a consolidated view of license and provenance findings across every scanner in the stack — Snyk included — so a GPL flag raised in one repository's SCA tool doesn't sit isolated from the same dependency showing up unflagged in a different pipeline or a container image built from a separate registry. Safeguard continuously builds and reconciles SBOMs across build systems, correlates dependency and license data against the artifacts that actually ship, and surfaces policy drift — like a license instruction quietly changed from fail to warn — as an auditable event rather than a silent configuration change. For teams that need to demonstrate license compliance evidence for audits, customer due diligence, or SOC 2 reviews, Safeguard turns scattered per-tool policy decisions into a single, defensible record of what was allowed, what was flagged, and why, across the entire software supply chain rather than just the portion one scanner covers.