License compliance guide

npm package license compliance: which open-source licenses are safe for commercial use

npm audit checks for CVEs. It checks nothing about licenses. An npm install that pulls in a single AGPL-licensed package can legally require you to open-source your entire application. Here is how to find every license in your dependency tree — and what to do when you find a risky one.

• Why license risk is different
• The npm license landscape
• The AGPL blind spot
• How to check all your licenses
• Transitive dependencies
• What to do with a risky license
• FAQ

Why license compliance is a separate audit from CVE scanning

A CVE is a bug — someone will publish a patch, you upgrade, the risk closes. A license is a permanent legal condition of the package. No advisory database tracks it. No future release fixes it. And unlike a security vulnerability, you can ship for years before the obligation surfaces — often during an acquisition due diligence, a customer security review, or a cease-and-desist from the package author.

The npm registry contains packages under hundreds of different licenses. The vast majority use permissive licenses (MIT, Apache-2.0) that impose almost no obligations. A small minority use copyleft licenses that, under the right conditions, require you to publish your application's source code under those same terms. The consequence of missing one is not a vulnerability score — it is a legal obligation you may have already violated.

The npm license landscape

There are three categories. The table below covers the licenses you are most likely to encounter:

The AGPL blind spot — especially for AI/ML projects

The GPL's copyleft triggers when you distribute software — shipping a binary to end users. Running a GPL web app on your server is generally not distribution, so the GPL's obligations do not activate for a server-side web application. AGPL closes this gap with a single additional clause: if you run the software to provide a service over a network, users of that service are entitled to the source code.

For a web app — including APIs, SaaS dashboards, and any backend service with external users — AGPL means: if you use even one AGPL-licensed npm package, you must make your entire application's source code available to users under the AGPL license.

AGPL also affects companies beyond startups. During M&A due diligence, AGPL in a target company's dependency tree is a common deal complication — buyers must either obtain a commercial license from the package author (if one is available) or remove the dependency before closing.

How to check all your npm package licenses

Three methods, graduated by coverage:

1. Quick sweep of direct dependencies — paste into DepCheck

   Paste your package.json into DepCheck. Any copyleft-licensed package in your direct dependencies is flagged with severity and license name. No install required — runs in your browser, only package names and versions are looked up.

   Scan your package.json →

2. Check a single package

   For a quick spot-check on a specific dependency before installing:

   # Show the license field from the registry
   npm info package-name license
   
   # For more detail: download the tarball and read the LICENSE file
   npm pack package-name
   tar -tzf package-name-1.0.0.tgz | grep -i license

   Note: the license field in package.json is self-reported by the author. It can be wrong, outdated, or missing. Always confirm against the LICENSE file in the tarball for any high-stakes decision.

3. Full transitive audit with license-checker

   Direct dependencies are just the start. Every transitive dependency (a dependency of a dependency) carries its own license, and those obligations apply to you too. Use license-checker to walk your entire node_modules tree:

   # Install once
   npm install -g license-checker
   
   # List all licenses (production deps only)
   license-checker --production
   
   # JSON output
   license-checker --production --json > licenses.json
   
   # Fail if any package falls outside your approved list
   license-checker --production \
     --onlyAllow 'MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC;CC0-1.0;Unlicense'

   Run this after every npm install or dependency update. Add it as a step in your CI pipeline so a new transitive dependency with a risky license fails the build before it reaches production.

Transitive dependencies: the hidden problem

Your package.json might contain only MIT-licensed direct dependencies. But each of those packages has its own dependencies. A single AGPL package three levels deep in your dependency tree carries the same obligations as one you installed directly — you are running the code regardless of where npm install found it.

A real example of how this happens: a popular utility package (MIT) adds a new optional feature in a minor release. The feature depends on a visualization library (AGPL). Your lockfile updates on your next npm install, and a new AGPL package is now part of your production bundle without a single change to your own package.json.

What to do when you find a risky license

You have four options, roughly in order of preference:

1. Find a permissively-licensed alternative

   Search npmjs.com for packages that solve the same problem. Many popular AGPL or GPL packages have MIT-licensed alternatives with comparable APIs — the ecosystem is large. Check weekly download counts and open issue velocity to assess maintenance health before switching.

2. Buy a commercial license

   Many packages that use AGPL (or SSPL) for their open-source release also offer a commercial license that removes the copyleft obligation. This is the dual-licensing model — common in infrastructure software and increasingly in AI tooling. Contact the package author or check their website for commercial licensing options.

3. Isolate via a service boundary

   If you run the AGPL code as a completely separate microservice — a standalone process with its own deployment, communicating only through a well-defined API — you may be able to contain the copyleft to that service's code alone, rather than your entire application. This is architecturally complex and legally uncertain; treat it as a last resort and get legal advice before relying on it.

4. Open-source under the copyleft license

   If the package is genuinely the right tool and no commercial license exists, you can release your application under AGPL (or the relevant copyleft license). For internal tools, open-source developer tooling, or projects where the code is not a competitive secret, this is sometimes the cleanest path.

For packages with no license field at all: contact the author and ask them to add a license (most will add MIT if asked). If the package is a transitive dependency, open an issue on the upstream package that pulled it in, or switch to an alternative that uses a fully-licensed dependency chain.

Scan your package.json for license risk →

Frequently asked questions

Also in the Copper Bay Labs ship-safety suite

License risk is one layer of your pre-ship checklist. These free tools cover the rest: