# TL;DR

Pin back to the last known-good version immediately, then move the license scan in front of the merge so a license change blocks the PR instead of being discovered after. Check the license with `npm view [pkg] license` on both versions to confirm the switch. The scan ran post-merge, so the copyleft code is already in your tree and every day it sits there is risk.

## Error

```text
agent's license check ran after merge; the new version switched to a copyleft license and legal flagged it
```

## Steps

1. Confirm the license change. Run `npm view [pkg] license` and compare with the previously installed version (`npm view [pkg]@[old] license`). Expected: the new version shows a copyleft license such as GPL-3.0 while the old one showed a permissive one.
2. Find every usage. Search the codebase for imports of the package. Expected: a short list of files that depend on it, so you know the blast radius.
3. Revert to the last good version. Pin the previous version in package.json, run `npm install`, and run the test suite. Expected: tests pass and the lockfile points at the old version.
4. Decide the path forward. Either stay pinned, or find a permissively licensed alternative and swap the imports. Expected: a decision recorded in the PR or ticket, not just a revert.
5. Move the license gate pre-merge. Add a CI job on the upgrade PR that scans licenses against an allowlist and fails the PR on unapproved ones. Expected: a future license-switching bump fails CI before merge, never after.

## Use this when

- Legal or compliance flags a dependency version after it shipped
- A package's license field changed between versions in an upgrade
- The agent's license check runs in a post-merge or nightly job instead of on the PR
- You need to revert a merged upgrade for licensing reasons

## Not for this skill when

- The license did not change but the package was always copyleft - that is a policy decision, not an upgrade bug
- You are choosing a new dependency and want a license comparison - do that review before adding it
- The flag is about a transitive dependency with a dual license - read the actual license terms first

## Variant phrasings

- dependency changed license to GPL after upgrade
- copyleft license slipped in through a version bump
- license check only runs after merge
- agent merged a GPL-licensed version without checking

## Why it happens

Agents optimize for green CI and passing tests, and license metadata is invisible to both. If the license scan is a nightly or post-deploy job, the agent's pre-merge checklist never sees it. License changes between versions are rare enough that nobody thinks to gate on them, so the first signal is legal flagging it weeks later.

## Edge cases

- Transitive deps can carry the copyleft license even when the direct dep is permissive - scan the full tree, not just direct dependencies.
- Dual-licensed packages (e.g. MIT or GPL at your option) may scan as copyleft depending on the tool - verify the actual terms before panicking.
- Some packages change license only in a README while package.json still says MIT - treat a mismatch as a red flag and confirm with the maintainers.
- Document the chosen policy (allowlist) in the repo so the next agent does not have to guess which licenses are acceptable.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2sbd6xZMpn2C5snn46P_Kw