Manually re-checking is the default method, because it
needs no tool: after a dependency update, open each package that shows
a version bump in the lockfile diff and read its license field
yourself. It works when the diff touches one or two packages you
already recognize. It stops working at the scale a routine
npm update or pip install -U actually
produces, because a version bump carries no signal about whether the
license moved with it — a patch release and a relicense look
identical in a diff that only shows version numbers.
| Package | Baseline | Current | Verdict |
|---|---|---|---|
left-pad | 1.3.0, MIT | not touched this update | stable |
stable-lib | 2.1.0, Apache-2.0 | 2.2.0, Apache-2.0 | version bump only |
infra-tool | 1.9.0, MPL-2.0 | 2.0.0, BUSL-1.1 | license changed |
Eyeballing the lockfile diff, stable-lib and
infra-tool both look like the same kind of event: a
routine minor-to-major version bump. Nothing in either diff line says
which one also changed its declared license. Pasted into this tool,
the two snapshots resolve to one finding: infra-tool
changed from MPL-2.0 (copyleft) to BUSL-1.1 (source-available);
stable-lib is reported unchanged. This is the exact shape
of HashiCorp's real 2023 Terraform relicense — MPL-2.0 to
BUSL-1.1 — which also arrived inside a version bump nobody
flagged in time. Merging on "the diff looked like an ordinary release"
is exactly the mechanism that carried it, and the other three events
this tool's README documents, into projects that never chose to accept
the new terms.
| Question | Where to answer it |
|---|---|
| I have last month's dependency list and today's — did any package's license change between them? | License Drift Check — paste both, get the exact list of changed, added, and removed packages in one click, no signup. |
| My lockfile diff shows a dozen packages bumped — which ones do I need to open and re-read the license for? | License Drift Check — it names exactly the ones whose license field changed; manual re-checking means opening all twelve to find out. |
| A package's version number jumped from 1.x to 2.0 — does that mean the license changed too? | Neither method can tell from the version number alone; a major bump and a relicense are independent facts. This tool reads the license field itself rather than inferring anything from semver. |
| I want to be sure a specific package I already accepted a license change for doesn't keep flagging every run. | License Drift Check — the CLI and the browser page both accept an ignore list; a manual check has no equivalent memory across updates. |
Neither method is wrong about the small case: one dependency updated, one page to open, a person can read that correctly every time. The gap opens exactly where a real dependency tree already makes manual re-checking hardest — a lockfile diff with a dozen or more version bumps in it, most of them genuinely routine, and no signal in the diff itself pointing at the one that is not. That is precisely when "the bumps all looked ordinary" and "every one of their licenses is still what it was last time" stop being the same sentence, and it is the gap this tool exists to close.
A lockfile diff or a Dependabot/Renovate PR shows which packages bumped version — it does not show which one's license field changed, because a license is metadata, not a code diff line. Checking by hand means opening every bumped package's own registry or GitHub page, one at a time, and reading its license yourself. At two or three dependencies that is realistic. At the dozens a routine npm update or pip install -U touches, a person reads the ones that look risky — a major version bump, an unfamiliar name — and skips the ones that look routine, which is exactly where a relicense hides: nothing about a version number says whether the license changed with it.
A baseline snapshot has three packages: left-pad 1.3.0 (MIT), infra-tool 1.9.0 (MPL-2.0), and stable-lib 2.1.0 (Apache-2.0). After an update, left-pad is untouched, stable-lib bumps to 2.2.0 still under Apache-2.0, and infra-tool bumps to 2.0.0 — now under BUSL-1.1. The lockfile diff shows two version bumps, both looking like ordinary releases; nothing distinguishes the one that also changed license from the one that did not. Pasted into this tool, the two snapshots resolve to one finding: infra-tool changed license from MPL-2.0 (copyleft) to BUSL-1.1 (source-available); stable-lib is reported unchanged. This is the exact shape of HashiCorp's real 2023 Terraform relicense, MPL-2.0 to BUSL-1.1, which also arrived inside a routine version bump.
Reading one package's license field is obvious once you already know to open that specific package's page. What manual re-checking gets wrong is coverage: deciding, for every single package a lockfile diff touched, to actually go open its page and read the license string, not just skim the version number and the changelog for anything alarming. A dependency tree with dozens of packages updating in one PR makes that full sweep exactly the kind of bookkeeping a person under time pressure to merge skips — which is why the four relicensing events this tool's README documents all reached existing users through a routine bump nobody re-checked.
No. It replaces the step of noticing that a package's license string changed at all. Once it names infra-tool as changed from MPL-2.0 to BUSL-1.1, you still need to read what BUSL-1.1 actually permits for your use — this tool's family label (permissive, copyleft, source-available) is a keyword-based skim aid, not a legal opinion, exactly as the tool's own front page and footer already say.
More: how a dependency's license change reaches your lockfile · License Drift Check vs. FOSSA, for continuous scanning and policy enforcement rather than a one-off snapshot diff.