Dependency License Checker

Dependency License Compliance: The Risk Hidden in Every node_modules

Open-source dependencies are the foundation of modern software, the average JavaScript project has 1,500+ packages in its dependency tree, written by thousands of people, under dozens of different licenses. Most of those licenses are friendly: MIT, Apache-2.0, BSD. A few are not, and a single GPL or AGPL package in the wrong place can create real legal obligations. License checking is the boring part of supply-chain security that becomes very loud during diligence, acquisition, or a customer's security review.

The Five License Categories That Matter

Out of the hundreds of OSS licenses in the wild, almost everything maps to one of five buckets:

1. Permissive. MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC, Unlicense, CC0, 0BSD.
The rules: use it however you want, closed-source, commercial, SaaS, embedded. Just preserve the copyright notice (Apache-2.0 also wants you to note modifications and include the NOTICE file). For 99% of commercial software, this is the entire universe of licenses you want.

2. Weak copyleft. LGPL-2.1, LGPL-3.0, MPL-2.0, EPL-2.0.
File-level or library-level copyleft. You can link against an LGPL library from proprietary code (dynamic linking, typical case) without GPL contamination, but if you modify the LGPL library itself, those modifications must be open-sourced. MPL-2.0 is similar at the file level, any MPL file you change stays MPL, but proprietary files don't get tainted.

3. Strong copyleft. GPL-2.0, GPL-3.0.
"If you distribute software that includes GPL code, the entire combined work must be GPL." Linking, static or dynamic, counts. "Distribution" historically meant shipping binaries; some interpretations now include SaaS. Strong copyleft is incompatible with most commercial software business models. Exceptions: pure tooling (a GPL build tool doesn't contaminate the build output), separate-process invocation (calling a GPL CLI is generally fine).

4. Network copyleft. AGPL-3.0.
GPL plus "if users interact with this code over a network, you must give them the source." Designed specifically to close the SaaS loophole in GPL. Most large companies (Google, Apple, Microsoft) ban AGPL entirely; smaller SaaS companies often do too. A single AGPL dep can obligate a SaaS provider to publish their entire codebase. Treat AGPL as a hard stop.

5. Unknown / proprietary / "custom".
No SPDX identifier, or one this tool doesn't recognize. The default copyright stance is "all rights reserved", you have no rights unless explicitly granted. Resolution requires opening the actual LICENSE file and reading the terms. Often these are "source-available but not OSS" licenses (BSL, SSPL, Elastic License) with usage restrictions that matter.

How the Tool Classifies

Your package.json's dependencies and devDependencies list packages by name and version range. For each, the tool resolves the published license metadata (the license field in the package's own package.json, which by convention is an SPDX identifier or expression).

• "MIT" → permissive.
• "Apache-2.0" → permissive.
• "(MIT OR Apache-2.0)" → permissive (user picks).
• "GPL-3.0-only" → strong copyleft.
• "SEE LICENSE IN LICENSE" → unknown; check manually.
• Missing → unknown.

The output is a table grouped by tier so the strong-copyleft and unknown rows are impossible to miss.

The Transitive Trap

Direct dependencies are easy: you chose them, you know what they do, their licenses are usually visible. Transitive dependencies, the deps of your deps, are where the risk hides.

A real pattern we've seen:

• You install some-popular-package@^2 (MIT, totally fine).
• It depends on some-utility@^4 (MIT).
• Which depends on tiny-helper@^1 (AGPL-3.0).

You never picked tiny-helper. You may not even know it exists. But it's in your node_modules, it's getting bundled into your ship, and you may have just inherited its license terms.

This is why the serious license tools (FOSSA, Black Duck, Snyk License Compliance, npm license-checker) walk the entire installed tree. This tool, working only from package.json, audits your direct deps, which catches the deliberate-but-forgotten choice ("oh right, we added that GPL ORM last quarter"). For full transitive coverage, run a CI tool against the lockfile and node_modules.

Common Compliance Mistakes

• Trusting the license field blindly. Some packages declare MIT in package.json but ship Apache-2.0 source in their actual LICENSE file. Mismatches happen; spot-check.
• Ignoring dual licenses. "(MIT OR GPL-2.0)" means you pick. "(MIT AND BSD-3-Clause)" means both apply. Read the operators.
• Treating MPL as "basically MIT". It's not, file-level copyleft has real implications if you fork.
• Assuming a transitive dep "doesn't count". It does. Distribution is distribution.
• Skipping the NOTICE file for Apache-2.0 deps. Apache requires you to include any NOTICE file from upstream in your distribution. Most products forget. Auditors notice.

What to Do When You Find Something

The triage workflow:

1. GPL or AGPL in your prod deps, high priority. Options: replace the dep, isolate it (separate process), get a commercial license from the author, or accept that your product must be open-sourced under the same terms.
2. LGPL or MPL, usually fine if you don't fork the library. Add to your acceptable-licenses allowlist with the "no modifications" guardrail.
3. Unknown, open the package's LICENSE file. Often turns out to be a valid permissive license with poor metadata; sometimes turns out to be 'all rights reserved'. Resolve case-by-case.
4. Commercial / source-available (BSL, SSPL, Elastic), read the terms. Many ban SaaS use, hosting as a service, or competing products. May be fine for you; may not.

Building a License Policy

Mature teams codify:

• Allowlist of acceptable licenses (typically: MIT, Apache-2.0, BSD-2/3, ISC, 0BSD, Unlicense, CC0).
• Blocklist of forbidden licenses (typically: AGPL-*, SSPL, BSL with restrictive terms).
• Review-required tier (LGPL, MPL, GPL): allowed only with legal sign-off and architectural guardrails.

Enforce in CI with license-checker or similar against the lockfile, fail builds on policy violations. This tool is the quick-look audit you do before formalizing the policy.

Privacy

The audit runs entirely in your browser. Your package.json, which often reveals your tech stack, vendor choices, internal package names, and unreleased experiments, stays in the tab. Open DevTools Network during a check: zero outbound requests.