When a dependency moves to a source available license, start by checking which versions are affected and what your use is. Then pick one of four paths: stay on the old version, accept the new terms, fork the last open version, or replace it. Do not upgrade by default.
Step 1: Read the new terms and the version boundary
Relicensing normally applies from a given release forward. Earlier releases stay under the license they were published with. Find the exact release where the change happened and read the new text, not a news summary.
Look at what the new license restricts. SSPL section 13 concerns offering the program as a service. The BSL restricts production use according to its Additional Use Grant and converts to an open license on a Change Date.
Step 2: Classify your use
- Do you only run it behind your own application?
- Do you distribute it to customers?
- Do you offer it to others as a hosted service?
- Do you modify it?
Each answer changes the exposure. Many internal uses are low risk under these licenses, but the counsel's reading is what counts.
Step 3: Choose a path
- Pin the last compatible version. Cheap now, but you give up upstream fixes, so security patches become your problem.
- Accept the new terms. Fine when your use fits and the review is documented.
- Fork the last open version. Needs people to maintain it. Check whether a community fork already exists and whom it is backed by.
- Replace. Highest cost, cleanest result.
Pinning deserves a warning. An old version without patches is a vulnerability exposure. Track advisories for it, and set a review date.
Step 4: Put it in the policy
Add the new license identifier to your policy as review required, so a similar change in another package triggers a review. Automated checks can compare license data between versions in a lockfile update and flag a change.
What to record
- The version where the license changed and the date you noticed.
- Your use classification.
- The path chosen, the owner and the review date.
Safeguard's dependency scanning and SBOM generation show where the package sits and which products use it, and policies and gates can stop an upgrade that you have not approved. The free scan is a first look. For the license terms, read the sources below.
Quick check
Do old versions change license when the project does?
Normally no. Earlier releases stay under the license they were published with. Confirm the exact release boundary in the project's files.
Is pinning the old version a safe default?
Only with a plan for security fixes. You no longer get upstream patches.
Sources
This post is general information, not legal advice.
Last reviewed: 19 October 2026.
