Snyk’s license compliance feature doesn’t just flag forbidden licenses; it actively prevents you from merging code that violates your defined policies.
Let’s see it in action. Imagine you’ve configured Snyk to block any dependency with an "AGPL-3.0" license. You’re working on a new feature and decide to add a popular logging library, winston, which happens to be licensed under AGPL-3.0.
Here’s what your package.json might look like before the merge:
{
"name": "my-awesome-app",
"version": "1.0.0",
"dependencies": {
"express": "^4.17.1",
"lodash": "^4.17.21",
"winston": "^3.3.3"
}
}
When you push your changes to trigger a CI/CD pipeline that includes Snyk, Snyk scans your dependencies. It identifies winston as having an AGPL-3.0 license. Because you’ve set a blocking policy for this license, Snyk will fail the build.
Your CI/CD output will look something like this:
...
[snyk] Running Snyk CLI...
[snyk] Testing /path/to/your/project...
Organization: your-org
Package manager: npm
Target file: package-lock.json
Tested 120 dependencies for known vulnerabilities, license issues, and policy violations.
✗ Forbidden license detected
'winston@3.3.3' uses license 'AGPL-3.0'.
This license is found in your policy and is set to be blocked.
See https://your-snyk-instance/org/your-org/policies/licenses for more details.
Remediation:
- Consider removing the 'winston' dependency.
- Or, consult with your legal team to understand the implications of using this license.
...
[CI/CD Stage: Snyk Scan] FAILED
The build fails, and your code is prevented from being merged until the license issue is resolved.
The core problem Snyk’s license compliance solves is the legal and business risk associated with using open-source software (OSS) that has restrictive licenses. Many OSS licenses, like the AGPL, have "copyleft" provisions that can require you to open-source your own proprietary code if you distribute software that links to or incorporates AGPL-licensed components. This is a non-starter for most businesses. Snyk provides a mechanism to enforce your organization’s acceptable license policy across all your projects.
Internally, Snyk maintains a comprehensive database of open-source packages, their licenses, and their license versions. When you integrate Snyk into your workflow (CI/CD, Git hooks, CLI), it analyzes your project’s dependencies. For each dependency, it queries its database to determine the associated license(s). It then compares these identified licenses against the policies you’ve configured in your Snyk project settings.
Your Snyk license policy is where you define what’s acceptable. You can specify:
- Allowed Licenses: Licenses that are always okay.
- Restricted Licenses: Licenses that require explicit review or approval.
- Forbidden Licenses: Licenses that automatically block builds or deployments.
You can manage these policies at the organization or individual project level. For example, you might allow MIT, BSD, and Apache 2.0 licenses universally, but restrict GPLv2 and block AGPL versions entirely.
The key levers you control are:
- The Policy Configuration: This is the heart of the system. You define the rules. This is typically done through the Snyk UI under "Policies" for your organization or specific projects. You’ll select license identifiers (like "MIT", "GPL-3.0-only", "Apache-2.0") and assign them a status (Allowed, Restricted, Forbidden).
- The Integration Point: Where Snyk runs matters. Running it in a CI/CD pipeline before merging is the most effective way to prevent violations. You can also use Git hooks for immediate feedback during development.
- The Dependency Management: Snyk relies on your project’s manifest files (
package.json,pom.xml,requirements.txt, etc.) and lock files (package-lock.json,yarn.lock,Pipfile.lock) to identify direct and transitive dependencies.
Snyk’s license compliance doesn’t just check the top-level dependencies declared in your manifest; it recursively analyzes all transitive dependencies. This is critical because a seemingly innocuous library you added might pull in a dependency with a problematic license deep in its dependency tree, and that’s the one that could cause legal issues. The system accurately traces these indirect dependencies to ensure comprehensive coverage.
The next hurdle you’ll likely encounter is managing the "Restricted" license category, which often requires a manual workflow for legal review before approval.