LicenseGuard

English | 日本語

Also listed on mcpservers.org, Smithery, the TensorBlock MCP Index, and the Docker MCP catalog.

Does this dependency's license create an obligation for the way you ship software?

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 depending on how the software reaches its users.

Live: https://licenseguard.tenchorooms.com

_{The workers.dev origin below is the same deployment, kept as the stable endpoint the MCP catalogs point at.}

Why does the distribution model decide it?

That last row is the whole 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 split runs through the rest of the license landscape, and the distinctions 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. Citing §13 for a distribution case is simply wrong, and LicenseGuard doesn't.
• MPL / EPL / CDDL are file-scoped and linkage-independent. MPL-2.0 §3.3 explicitly permits distributing a Larger Work under your own terms. Applying LGPL's relinking logic to them produces false positives.
• LGPL is the one that actually depends on linkage: static linking carries a relinking obligation, dynamic linking does not.

Verdicts are stated as facts with the clause cited. LicenseGuard does not tell you what to do.

Common questions

Does the GPL apply if I only host the software and never distribute it? No. GPL-3.0 triggers its obligations on distribution. Hosted SaaS is not distribution, so no obligation arises today — but shipping the same software later, as an on-prem deployment, a binary, or a published library, would trigger whole-work source disclosure.

Does the AGPL apply if I only host the software as a SaaS? Yes. AGPL-3.0 §13 requires that users interacting with a modified version over a network be offered the corresponding source of the whole work. This is the clause that makes AGPL behave differently from GPL for hosted services, and it is the entire practical difference between the two.

Do build-time and dev dependencies create license obligations? No. A dev dependency is not part of the artifact you ship, so distribution-triggered obligations do not arise. Tools that emit code into your output, such as code generators, are a separate case worth checking individually.

Is MIT safe for commercial use? Yes, in every distribution model. MIT asks for attribution and nothing more. Apache-2.0 reaches the same result while adding a patent grant and a NOTICE requirement — obligations, but ones that do not vary by how you ship.

Does static linking change the answer? Only for LGPL, and only for compiled languages. LGPL's design is that you may use the library in a proprietary work provided the user can replace it, which dynamic linking gives you and static linking does not. Go and Rust link statically by default, and nothing in Cargo.lock or go.sum says so.

Why does the same license give different answers for different projects? Because copyleft obligations attach to events — distributing, or letting users interact over a network — not to the presence of the code. Whether those events happen is a fact about your business, not about your repository, which is why a scanner that only reads your lockfile cannot decide it.

Use it from your coding agent

You need this when you are adding a dependency, not when you are searching the web. So the primary surface is an MCP tool, not a search result.

Hosted — nothing to install:

claude mcp add licenseguard --transport http https://license-guard.rcc-aoki.workers.dev/mcp

Local (stdio) — your manifest never leaves your machine. Only package names and versions are sent to public registries to look up licenses:

claude mcp add licenseguard -- docker run -i --rm ghcr.io/rccaoki-wq/license-guard:1.1.0

The image is published on every release and declared as an OCI package in the official MCP registry, so clients that read the registry can install it without any of this. To build it yourself instead: docker build -t licenseguard . && docker run -i --rm licenseguard.

Both paths run the same policy engine. They cannot disagree — an end-to-end suite (npm run e2e:stdio) pins them together.

Stateless Streamable HTTP, no authentication, no session state.

Use it from anything else

The JSON API returns the same verdicts:

curl "https://license-guard.rcc-aoki.workers.dev/api/pkg/pypi/pyload-ng?model=saas"
# => {"license":"AGPL-3.0-only","verdict":"blocked", ...}

Scan a whole lockfile:

curl -X POST https://license-guard.rcc-aoki.workers.dev/api/scan \
  -H 'content-type: application/json' \
  -d "$(jq -Rs '{content: ., distributionModel: "saas"}' package-lock.json)"

An agent-facing index lives at /llms.txt.

Supported manifests

Ecosystems: npm · PyPI · Go modules · crates.io · RubyGems · NuGet

Problem licenses usually arrive as a dependency of a dependency, not as something you added on purpose — so the lockfile path is the one that matters. package-lock.json v2/v3 embeds a license for every entry, which means a full transitive audit with zero network lookups and the exact versions that will actually be installed.

An incomplete scan is never reported as clean. Dependencies that could not be resolved appear as not-checked or review and are counted in the summary. They never become allowed.

A single scan performs at most 300 registry lookups, which bounds what one request can cost. Cached packages don't consume that budget, so the ceiling only binds on packages nobody has looked up yet — a first scan of a ~1000-crate Cargo.lock typically leaves a few dozen entries marked not-checked, and scanning again resolves them (measured: servo's 1043 crates reach zero unresolved published crates on the second pass). The result says so explicitly rather than quietly showing a shorter list.

Git dependencies and members of the workspace being scanned are reported as not-published instead, across every format that identifies them — Cargo.lock's source field, yarn's workspace: and git+ protocols, pnpm's tarball URLs, and package-lock.json's resolved. No public registry has license data for them, so they are never looked up. That is a different situation from hitting the lookup limit: re-scanning will not resolve them, and the result says so.

This matters for more than speed. A workspace member named after a package that also exists publicly — utils, core, or anything else generic — would otherwise be resolved against that unrelated public package and reported as allowed, because the workspace version (0.0.0-use.local) matches nothing and the lookup falls back to the latest release. Marking the origin is what stops a private package from inheriting a stranger's license.

Private registries are the deliberate exception. A resolved URL pointing somewhere other than npmjs is just as likely to be a transparent Artifactory or Nexus proxy serving the real public package, and nothing in the lockfile distinguishes the two — so those are still looked up, and still reported as unresolved if they fail.

SBOMs

CycloneDX and SPDX are read in JSON, including GitHub's {"sbom": …} envelope, so the response of gh api repos/OWNER/REPO/dependency-graph/sbom can be pasted unmodified. A license recorded in the document is used as-is; components without one are looked up. NOASSERTION, NONE, and LicenseRef-* are not treated as declarations, because they are the document saying it does not know.