You installed a tool you love, built your workflow around it, and then one morning the maintainer announces a new license. The code you depended on is now restricted to personal use, or the project has moved behind a paid tier, or a company bought it and quietly changed the terms. This pattern has become common enough that developers now have a name for it: the "rug pull." Over the last several years, projects that once shipped under permissive open source licenses such as MIT or Apache 2.0 have shifted to source-available licenses, business source licenses, or proprietary terms. The change is often legal, sometimes reasonable, and almost always disruptive for people who did not read the fine print.
The surprising part is how rarely users check. Most people who depend on an open source app never open the LICENSE file, never track whether the project has a single corporate owner, and never ask what happens to their data or their extensions if the project changes hands. A license change does not break your software on the day it happens, which is exactly why it catches people off guard. You keep using the app until a feature disappears, an update requires a subscription, or a compliance audit at your employer asks why an unapproved license is sitting on a work laptop.
This article explains what an open source license change actually means, how to read a license without a law degree, how to audit your own software stack, and what to do when a tool you rely on goes closed. We will walk through a real-world style audit with numbers, compare the license families you are likely to encounter, and finish with a practical migration checklist. Along the way we will point to tools and guides on LionScripts that can help you test and replace what you depend on. The goal is not to tell you to abandon every project that changes its terms. It is to make sure the decision is yours, made with your eyes open.
Key Takeaways
- An open source license change can restrict use, add paid tiers, or move code to source-available terms without changing how the app looks on day one.
- Read the LICENSE file and the project's own licensing FAQ, not just the homepage label. "Free" and "open source" are not the same thing.
- Track ownership: a company acquisition or a venture round is the single strongest predictor of a future license change.
- Keep a written inventory of every tool you depend on, with its license, owner, and a "what breaks if this disappears" note.
- Before you migrate, export your data and test a restore. A tool you cannot leave is a tool you do not truly own.
- Forks and permissive-licensed alternatives often protect you, but only if the community behind them is active.
What Does an Open Source License Change Actually Mean?
An open source license change is any modification to the legal terms under which a piece of software is distributed, where the new terms reduce the freedoms that the original license granted. The most common forms are a move from a permissive license (MIT, BSD, Apache 2.0) to a copyleft license (AGPL, GPL), a move to a source-available license that publishes code but restricts commercial use, or a move to a proprietary license with a closed codebase. Some changes are relicensing for future versions only. Others apply retroactively to new releases while older versions remain under the old terms.
It is important to separate three things that people often blur together:
- Source code access: Can you read the code at all?
- Usage rights: Can you run it commercially, modify it, and redistribute it?
- Governance: Who controls the project, its roadmap, and its license going forward?
A project can keep its code public and still change its usage rights dramatically. A project can keep its license identical and still change governance when a single company acquires the maintainers. Each type of change carries different risk for you.
Why Projects Change Their Licenses
Maintainers rarely make this move casually. The usual reasons are financial. A small team maintaining a popular project may face thousands of dollars a month in hosting and development costs, and a cloud provider may offer a hosted version of the same software without contributing back. Companies respond by adding licenses that block that specific behavior. Others change license after an acquisition, when investors expect a return. Understanding the motive helps you judge whether the change is a fair business decision or a sign that the project is entering a long, uncertain period.
How Do You Read a License Without a Law Degree?
Most people only need to answer five questions to understand what a license allows. Open the LICENSE file in the project's repository, and look for the answers to these:
- Can I use it commercially? Look for explicit grants of commercial use.
- Can I modify it? Most open source licenses allow this, but some restrict redistribution of modified versions.
- Can I host it as a service for others? This is the question that caused the most recent controversies. AGPL and some source-available licenses address it directly.
- Do my changes have to be published? Copyleft licenses like GPL and AGPL say yes if you distribute or, in AGPL's case, network-serve the software.
- Does the license apply to past versions? Check the changelog or license history to see whether an older release is still under the original terms.
Be wary of a few common traps. A project may say "free to use" on its homepage while the LICENSE file restricts commercial use. Some projects use a "Commons Clause" addendum that appends a restriction to an otherwise permissive license. And a dual-licensing model means the same code is available under a free license for individuals and a paid license for companies, which can flip without warning if the maintainer decides to sell more commercial licenses.
Quick Reading Checklist
- Is there a LICENSE or COPYING file in the root of the repository?
- Does the license name match the badge on the README? Mismatches are a warning sign.
- Is there a separate "licensing" or "commercial use" page? Read it. It often contains the real rules.
- Has the project's CONTRIBUTOR-LICENSE-AGREEMENT changed? A new CLA can give the maintainer rights to relicense your contributions.
How Do You Audit Your Own Software Stack?
Auditing sounds like corporate compliance work, but a personal or small-business version takes under an hour for most people. The key is to write everything down. Memory is unreliable, and a spreadsheet makes patterns visible: three tools from the same company, two with a shared maintainer, one that recently took venture funding.
A Worked Example: The 47-Password, 12-Service Problem
Consider a freelance designer who uses 12 services daily: a notes app, a password manager, a password-based backup tool, a WordPress site with 9 plugins, a Chrome extension, a design plugin, a task manager, a self-hosted file sync server, a photo editor, a budgeting app, an email client, and a calculator. She has 47 saved passwords across those services, and her password manager holds the vault for all of them.
Her audit goes like this:
- List every tool (12 rows). For each, record the name, the version, the license, the owner, and where the data lives.
- Mark licenses. Of the 12, 7 are proprietary commercial apps, 3 are open source under MIT or Apache, 1 is AGPL, and 1 recently moved from MIT to a source-available license.
- Flag the risky one. The source-available tool is her self-hosted file sync server. It now prohibits offering the software as a service to third parties. Her use is internal, so it is still allowed, but a future version could add terms she does not want.
- Check the data path. She exports her notes and file sync data monthly to a separate drive. That single habit turns a license change into an inconvenience rather than a crisis.
- Set a review date. She puts a recurring calendar reminder for the first Monday of each quarter to repeat the audit.
The audit took her 40 minutes. The output was a one-page document that told her exactly which tools to watch, which to back up more often, and which she could replace without a weekend of pain.
Building Your Own Inventory
- Column 1: Tool name and version
- Column 2: License type (permissive, copyleft, source-available, proprietary)
- Column 3: Owner (individual, company, foundation)
- Column 4: Data format and export path
- Column 5: Replacement candidate and rough migration effort in hours
- Column 6: Last reviewed date
What Are the Main License Families, and How Do They Compare?
Not all licenses carry the same risk. The table below compares five license families you are most likely to encounter, across criteria that matter in practice.
| License family | Examples | Commercial use | Can be relicensed by maintainer later | Forks protected | Risk of future closure |
|---|---|---|---|---|---|
| Permissive | MIT, BSD, Apache 2.0 | Yes | Only for new contributions under a CLA | Yes, forks stay open | Low for existing versions |
| Weak copyleft | LGPL, MPL 2.0 | Yes, with conditions | Limited | Yes | Low to moderate |
| Strong copyleft | GPL v3, AGPL v3 | Yes, with conditions | Limited | Yes, derivative work must stay open | Low, but can deter some businesses |
| Source-available | BSL, SSPL, Commons Clause add-ons | Restricted | Yes, by the owner | Often no | High |
| Proprietary with public code | Various vendor licenses | Usually restricted | Yes | No | Very high |
The practical takeaway is that a permissive license protects the version you already have, because nobody can take back rights you already received. A source-available license gives the owner the freedom to change the rules for future releases, which is exactly what happened in several high-profile cases. If you rely on a tool for something important, prefer tools under permissive or strong copyleft licenses with active community forks.
What Warning Signs Predict a License Change?
License changes rarely arrive without precedent. Look for these signals before the announcement:
- A recent acquisition or funding round. Investors expect revenue, and license changes are a common way to monetize.
- A single maintainer carrying the project. Burnout and financial strain often lead to a change in terms.
- A hosted version offered by a large cloud provider. This is the trigger behind many source-available moves.
- A new CLA requirement. When contributors are asked to sign away relicensing rights, the owner is preparing for flexibility.
- Vague language on the commerc
