Yes. A license is declared by each published version, so an upgrade can carry different terms from the version you use now. A fix pull request that bumps a package should be checked for license changes, because a vulnerability fix is not a reason to accept new obligations without noticing.
Why this can happen
Package metadata is part of each release. In npm, for example, the license field in package.json is set per version and is expected to be an SPDX identifier such as MIT, or an SPDX expression, or a pointer to a license file. Nothing in the registry model stops a maintainer from changing that field in a later release.
Most of the time nothing changes. The rare change, such as a move to a source available or copyleft license, is the one that matters, and a security bump is a poor moment to discover it. For background, see what a business source license change date means.
What to add to the review
A license check on a fix pull request is quick:
- Compare the license declared by the old version and the new one for each changed package.
- Include transitive packages that the update pulls in or swaps.
- Flag any difference, and any new "SEE LICENSE IN" or unlicensed value.
- Route flagged changes to whoever owns license policy.
Automate the comparison. A person will not reliably spot a changed field in a lockfile diff.
What to do when it changed
| Change | Typical response |
|---|---|
| Permissive to permissive | Note it and merge |
| Permissive to copyleft or restricted | Hold the PR, ask legal or the policy owner |
| Declared license becomes unclear | Hold, check the project repository |
| License unchanged but a new transitive appears | Check the new package too |
If you must patch but cannot accept the new terms, options include a backported fix from a distributor, pinning an earlier fixed release, or replacing the package. Our fixed version or backported fix post covers how to judge each.
Keep a record
For audits and customer questions, store the license for each component version in your SBOM. A license check result attached to the pull request is useful evidence that a person looked.
Where license data comes from
License information is declared by authors and collected from package metadata, repository files and sometimes both. These sources can disagree, and metadata can be missing or free text instead of a standard identifier. Treat an unclear result as a reason to look at the project itself, not as a pass. SPDX identifiers make comparisons reliable, so prefer tooling that normalises to them, and record the source of each value in your SBOM.
Where Safeguard fits
Safeguard's SBOM and dependency scanning records components and their license data, and policies and gates can block changes that break your license rules. A free scan lists the licenses in your dependencies.
Quick check
Do patch releases ever change licenses?
It is uncommon, but nothing prevents it, so check programmatically rather than assuming.
Is a license check legal advice?
No. It flags changes so the right person can decide.
Sources
Last reviewed: 19 October 2026.
