A dependency changed its license: a response playbook

When a dependency changes its license, stop automatic upgrades to the new version, read the new text, and work out which of your products take that version. Then choose: stay on the last version under the old terms, accept the new ones, replace the library, or contact the maintainers.

Step 1: pause the upgrade path

Pin the current version and hold update pull requests for that package. The license that applies to a release is the one shipped with that release, so a version you already have generally stays under the terms it came with. Confirm that by reading the license file in the version you hold, and ask counsel if it matters.

Step 2: read the new terms

Compare the old and new text. Look for changes to who may use it, what for, whether hosted use is limited, and whether a fee applies. Check it against the criteria in the Open Source Definition to tell whether the new license is still open source.

Step 3: map your exposure

1. Which repositories use the package, and which version?
2. Is it in a product you distribute, a hosted service, or an internal tool?
3. Is it a direct or transitive dependency?
4. How hard would it be to remove?

An inventory that records versions and licenses answers these quickly. Without one, the exercise is slow.

Step 4: pick a path

• Stay on the old version. Fine for a while, but you stop receiving fixes from upstream. Plan an end date.
• Accept the new terms. If counsel is comfortable, record the decision and the date.
• Buy a commercial license. Some projects offer one. Price and terms are between you and the vendor.
• Move to a fork or alternative. Check that it is maintained, has several contributors and is under a stable license. See forking strategy.
• Replace it in house. Only when the surface is small.

Step 5: record and communicate

Write down what changed, what you decided and why. Tell the teams affected, and the customers if your contracts require it. Keep the old license file in your records.

Step 6: reduce the chance of surprise

Watch the license field in new releases of key dependencies, not only vulnerabilities. A check that flags a license change at pull request time gives you the warning before the merge. See license compliance debt and commercial open source license shifts.

Safeguard's SBOM and dependency scanning keep an inventory by version, policies and gates can stop an unreviewed change at merge, and you can try a free scan.

A note on timing

License changes are often announced in a blog post or a pull request before they take effect. If you follow the project, you may get days or weeks of notice. Use that window to run steps 2 and 3, so the decision is made before an update pull request arrives.

If you only find out after a bot has already merged the new version, treat it as an incident: revert to the previous version, then work through the steps in order. Do not ship a build with the new terms until someone has read them.

Quick check

Last reviewed: 19 October 2026.