An npm licence compliance checklist for shipping software
A typical web app pulls in hundreds of packages, each with its own licence. Most are permissive. The few that are not are the ones worth ten minutes before a release, an acquisition review or a customer security questionnaire.
The categories this tool uses
permissive — MIT, ISC, BSD, Apache-2.0 and similar. Keep the notice; little else is required.
weak-copyleft — LGPL, MPL, EPL, CDDL. Changes to the library itself usually have to be shared; using it as a dependency usually does not.
strong-copyleft — GPL, AGPL, SSPL. Distributing (or, for AGPL and SSPL, offering over a network) software that includes it can carry obligations on your own code. Review these first.
unlicensed — UNLICENSED or SEE LICENSE IN .... No grant is visible in the metadata; read the file it points to.
unknown — no licence declared, or an identifier this tool does not recognise.
Checklist
Run the check on package-lock.json, once with devDependencies and once with --no-dev: build tools you do not ship matter far less.
Read every strong-copyleft entry's own repository. Declared metadata can be wrong.
For a dual-licensed (MIT OR GPL-3.0) package, record which option you rely on.
For an unknown package, look for a LICENSE file, then ask the maintainer to add a licence field.
Add node license-check.mjs --fail-on copyleft to CI so a new dependency cannot add one silently.
What this does not tell you
It reads only the licence field package authors declared in their own package.json. It does not read licence files, detect code copied between packages, or follow transitive licences that npm did not record. It is a heuristic and is not legal advice.