Why you should care about transitive npm license compliance

License compliance is usually categorized as a legal concern, not a security concern. But there's an intersection between license management and supply chain security that is worth understanding.

The license change signal

When a malicious actor takes over a package, they often change the license field in package.json or pyproject.toml. Sometimes this is intentional obfuscation — making the package look different enough that diff-checking tools catch something. Sometimes it's careless — the new maintainer isn't thinking about license continuity. Sometimes it's a tell in the other direction — they change it to something that would never be chosen for a legitimate package (licenses that don't exist, or strings that aren't license identifiers).

Veln's metadata coherence check (one of the eight trust score signals) includes a license validity check: is the license field a recognized SPDX license identifier? Is it consistent with previous versions? An unexpected license change is a low-weight signal, but combined with other anomalies, it contributes to the trust score calculation.

The practical license compliance workflow

Beyond the security signal, license compliance matters because:

• GPL/LGPL/AGPL dependencies may impose viral licensing requirements on your code
• Some licenses are incompatible with each other
• Some companies have policies against certain license types (e.g., copyleft licenses in proprietary products)

Tools for npm license auditing:

# license-checker — lists all packages and their licenses
npm install -g license-checker
license-checker --summary

# Output example:
# MIT: 847
# ISC: 123
# BSD-3-Clause: 45
# Apache-2.0: 23
# GPL-3.0: 2  ← these need review

For Python:

pip install pip-licenses
pip-licenses --format=table --with-urls

What a license change in a transitive dependency tells you

If a package that has been MIT for five years suddenly becomes UNLICENSED or a non-standard license string, something has changed. Either:

• The new maintainer changed the license (worth investigating)
• The package was modified in an unusual way (worth investigating)
• It's a typo or oversight (still worth a quick check)

License changes don't indicate malicious activity by themselves. But a package with a suspicious license change, published by a new account, with a fresh signing key, and zero community observations — that combination is worth holding for review.

Integrating license checks into CI

- run: npm ci
- run: license-checker --onlyAllow 'MIT;ISC;Apache-2.0;BSD-2-Clause;BSD-3-Clause' \
         --excludePrivatePackages

This step fails the build if any package uses a license outside the approved list. Combined with Veln's metadata coherence check, it provides two independent signals that would catch an unexpected license change.

---

License changes are a low-weight supply chain signal. Veln checks license coherence as part of its metadata score.