LicenseGuard
Decides whether an open source dependency's license actually obligates you — given how your project ships.
What it can do
- Check Dependency License: Determine whether adding or keeping a single open source dependency creates a legal obligation, given how this project ships. Call this BEFORE adding a new dependency to a pr
- Check Manifest Licenses: Scan an entire dependency manifest and report every dependency whose license creates an obligation for this shipping model. Use when reviewing a project as a whole, preparing
- Explain License: Given an SPDX license identifier or expression, explain what it requires across every shipping model at once. Use when the question is about the license itself rather than a specific
What data it sees
Do you need an account
No: the server works without sign-in
Decides whether an open source dependency's license actually obligates you — given how your project ships.
Generic license scanners answer a different question ("what license is this?") and then warn on everything. LicenseGuard evaluates the license against your distribution model, so the same license produces different verdicts:
| How you ship | AGPL-3.0 dependency |
|---|---|
| SaaS (network-accessible) | blocked — §13 network clause |
| Internal use only | allowed |
| Distributed binary / on-prem | blocked — inherited GPL distribution terms |
| devDependency (never in the artifact) | allowed |
That last row is the point. A build-time linter under AGPL never ships, so it triggers nothing — but tools that warn on it anyway train people to ignore every warning they produce.
The same distinctions run through the rest of the license landscape, and they are not interchangeable:
- GPL obligations attach to distribution. Running GPL code as a network service is not distribution.
- AGPL adds §13, which attaches to network interaction — a separate trigger from GPL's distribution terms.
- MPL / EPL / CDDL are file-scoped and linkage-independent. MPL-2.0 §3.3 explicitly permits distributing a Larger Work under your own terms.
- LGPL is the one that actually depends on linkage: static linking carries a relinking obligation, dynamic linking does not.
Tools
| Tool | When to call it |
|---|---|
check_dependency_license |
Before adding a single dependency |
check_manifest_licenses |
To audit a whole manifest or lockfile |
explain_license |
To see what a license requires across every distribution model |
Coverage
npm · PyPI · Go modules · crates.io
Reads package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, pyproject.toml, poetry.lock, uv.lock, go.mod, go.sum, Cargo.toml, Cargo.lock — so transitive dependencies are covered, which matters because problem licenses usually arrive as a dependency of a dependency rather than one you added on purpose.
Dependencies that cannot be resolved are reported as not-checked or review, never as allowed. An incomplete scan is never presented as clean.
Run it locally instead
No auth on the hosted endpoint. If you would rather not send a lockfile to a third-party service, the same policy engine runs on your machine:
docker run -i --rm ghcr.io/rccaoki-wq/license-guard
Only package names and versions reach public registries. An end-to-end test pins the hosted and local paths together so they cannot disagree.
Disclaimer
Informational only, based on published license texts and declared dependency metadata. Not legal advice, and it does not claim to identify every obligation.
Server tool list (3)
Raw names from tools/list. Only developers need these.
| check_dependency_license | Determine whether adding or keeping a single open source dependency creates a legal obligation, given how this project ships. Call this BEFORE adding a new dependency to a project, and when auditing an existing one. A permissive result means no source-disclosure duty; a blocked result means the license obligates you and the dependency should be replaced or the shipping model reconsidered. |
| check_manifest_licenses | Scan an entire dependency manifest and report every dependency whose license creates an obligation for this shipping model. Use when reviewing a project as a whole, preparing for due diligence, or after a large dependency change. Pass a package-lock.json when one exists: problematic licenses usually arrive as transitive dependencies rather than ones you added directly, and only a lockfile reveals those. |
| explain_license | Given an SPDX license identifier or expression, explain what it requires across every shipping model at once. Use when the question is about the license itself rather than a specific package — for example when comparing AGPL-3.0 against GPL-3.0 for a hosted service, or deciding what a project may safely depend on. |