Licenses change quietly, but break on update: a checklist for testing a self-hosted project

WEB technologies and their applications Hosting and VPSs
, , , ,
1

License changes quietly, and break during an update

There are categories of failures that cannot be fixed by rolling back the container, because the break happened not in your infrastructure. You update the self-hosted service to a minor version, and some users stop logging in — not due to a bug, but because the login feature was moved to a paid edition. This week such a plot unfolded at PLANKA, and it’s good because it shows the mechanism in full: what it looks like from the maintainers’ side, and what it looks like from the side of someone whose task board sits in a home docker-compose.

Below is exactly what happened, an eight-year chronology of similar twists (with all caveats, including reversals) and a fifteen-minute procedure that beforehand shows precisely what will bite you.

What happened in PLANKA 2.2

PLANKA is a self-hosted Kanban board, a visual clone of Trello, one of the most common answers to the question “what to replace Trello with for yourself.” In version 2.2.0 authentication via OIDC/SSO migrated from Community to Pro edition. Maintainers described this in issue #1754 in advance, not post-factum.

The argument there is exactly three points, and it deserves to be read rather than paraphrased in the style of “greedy developers”:

SSO is the unequivocal leader in maintenance cost: more than a hundred requests per month for configuration.

The second point is that SSO was originally conceived as a corporate feature and ended up in Community by oversight. The third is that according to their licensing guide, direct support is reserved for Pro/Enterprise clients, and the feature that generates a hundred tickets per month cannot live without support.

Symmetrically in Community it arrived: two-factor TOTP, auto-logout on inactivity, and trusted devices. Maintainers’ wording: account security remains free and open, corporate identity management is paid.

Error:

Here is what in this story is truly dangerous and has nothing to do with the licensing debate. Accounts created through SSO do not have passwords. After an update such users are deactivated, and an admin will have to manually assign them passwords or re-enable them. If the admin logs in through SSO — you get a service that no one can log into, and it can be fixed only by a script or environment variables.

The takeaway to carry separately from the rest of the article: before a major or minor update of any service with external authentication, make sure a local admin with a password exists. This rule predates PLANKA by about twenty years and saves regardless of the vendor’s licensing policy.

Eight years of the same plot

The PLANKA story is not unique and not even the loudest. It’s more useful to view it in a sequence — then you can see both the pattern and that the needle sometimes turns back.

Year Event Ecosystem reaction
October 2018 MongoDB issues SSPL for Community Server OSI approval still pending; distributions remove the package
January 2021 Elasticsearch and Kibana move from Apache 2.0 to SSPL / Elastic License AWS forks OpenSearch
April 2021 Grafana, Loki and Tempo relocate from Apache 2.0 to AGPLv3 fork did not arise, AGPL accepted
October–December 2022 domain name and trademark Gitea transferred to commercial Gitea Ltd without maintainer vote Codeberg announces Forgejo on December 15, 2022
August 2023 HashiCorp relocates products, including Terraform, to BUSL 1.1 fork OpenTofu, in September — under Linux Foundation
March 2024 Redis moves from BSD to RSALv2 / SSPL fork Valkey under Linux Foundation
August 2024 Elastic adds AGPLv3 as an option “Elasticsearch open source again”
May 2025 Redis 8 adds AGPLv3 By this time Valkey is living its own life
August 2026 PLANKA 2.2: OIDC/SSO → Pro discussions ongoing in issue and forums
Note:

Notice the two lines that break the comfortable narrative that “everyone is moving in one direction.” Elastic in 2024 and Redis in 2025 returned OSI-approved licenses — and both openly acknowledged that their relationship with the community suffered more than expected. So forks work. But they work for years, and the decision about your update is made tonight.

Three different mechanisms that always get lumped together

Half the debates in the comments under such news arise from the fact that “the project closed” means three completely different things with different consequences.

Mechanism one: license change of the code. MongoDB, Elastic, HashiCorp, Redis. The code remains accessible, but the terms of use change. For a home server, consequences are usually zero: SSPL and BUSL affect those who resell the product as a service. For forks this is, conversely, catastrophic — and that’s why forks appear immediately.

Mechanism two: moving a feature to a paid edition with the license unchanged. This is the PLANKA case. The code license is untouched, but the particular capability disappeared from the free build. For a home user this is more painful than the first case, because it hits directly even on the nearest docker compose pull.

Here too is the plot where the free tier terms from the provider change — a fresh example discussed in the thread about narrowing Oracle Always Free ARM by half. The mechanism for the user is exactly the same: rules changed after you built everything.

Mechanism three: change of project owner and brand. Gitea. Not a line of code changed, license the same — the decision maker on what happens tomorrow changed. Fork here arises not from legal restrictions, but from loss of trust in governance.

Warning:

Practical takeaway: when you read the news that “project X is no longer open source,” first determine the mechanism. It determines whether you need to do anything at all. For the first mechanism, the home user usually doesn’t need to do anything. For the second — yes, and urgently. For the third — decide who you’re aligned with, and there’s usually time to do so.

Fifteen minutes before docker compose up

Now, for what this whole thing was written: the checks below are not about ideology or whether the project is “correct.” They answer one question: how does this project make money and what will be taken away first if money becomes tight.

Project readiness checks before installation
Project readiness checks before installation1300×780 60 KB

Steps of checks are based on publicly available licensing materials of PLANKA, Redis, Elastic, Grafana, HashiCorp and Forgejo

Step 1. History of the LICENSE file, not the file itself

Look not at the current license text, but at its biography:

git clone --filter=blob:none https://github.com/<org>/<repo> && cd <repo>
git log --follow --oneline -- LICENSE
git log -1 --format=%ci -- LICENSE   # when was the last time touched

One commit titled “Initial commit” is normal. Two to three commits with messages like “update license” aren’t doom, but you should be more careful as you go down the list.

Step 2. CLA or DCO

This is the least appreciated point, and it predicts the future more than all the others combined. If a project requires signing a CLA (Contributor License Agreement) transferring rights to the company — the company gains the legal ability to unilaterally change the license for all code, including external contributions. If a DCO (Developer Certificate of Origin) is used — the rights stay with the authors, and unilateral reversal becomes practically impossible.

ls CONTRIBUTING.md CLA.md .github/  2>/dev/null
grep -ril "contributor license agreement\|Signed-off-by" . --include="*.md" | head

All high-profile reversals from the table above happened in projects with a CLA or with a single corporate copyright holder. This is not a coincidence — it’s mechanics.

Step 3. Who holds the domain and trademark

Gitea’s case is entirely about this. Check the site footer, the About page, the domain whois, and the organization owner on GitHub. The Foundation (Linux Foundation, Apache, SFC), a registered NGO (Codeberg e.V.), and a one-person LLC — three very different five-year forecasts. None of them is inherently bad, but the third one requires a fallback plan.

Step 4. The pricing page — a list of candidates for removal

Open the price list and read the table Community vs Pro/Enterprise before installation. Anything listed in the paid column of competitors, but currently free for your candidate, are features in the risk zone. SSO in this sense is the number one marker: the very wording “SSO tax” exists because single sign-on has become the first paid barrier in almost the entire industry.

Step 5. The ee/, pro/, enterprise/ directories in the repo

find . -maxdepth 2 -type d \( -name "ee" -o -name "pro" -o -name "enterprise" \)
find . -name "LICENSE*" -not -path "./node_modules/*"

If inside such a directory there is a standalone LICENSE — the boundary between free and paid has already been drawn in the code. This, by the way, is more honest than hidden restrictions: you can see where the line runs, and you can see when it’s moved.

Step 6. Data export without the product itself

The most practical check of all, and it isn’t about licenses at all. A simple question: if tomorrow the project becomes unacceptable to you, can you extract the data?

docker compose exec -T db pg_dump -U <user> <db> > backup.sql
docker compose exec -T db psql -U <user> -d <db> -c '\dt'

A clear schema in a regular RDBMS is freedom to leave. A proprietary binary format or a cloud API as the only way to access your data is a tether, which does not depend on any license.

Success:

A short checklist to run before any update, not just license changes:

  • a local admin exists with a password not dependent on an external login provider;
  • the CHANGELOG for the exact version you are updating to has been read, not the “latest”;
  • the image in compose is pinned to a specific version tag (ideally by digest image@sha256:… rather than :latest);
  • the database dump was created today and tested by restoring at least once;
  • the fork name is known, if any, and whether it is alive.

Where does fair indignation end

It’s worth saying the opposite as well, otherwise it would be propaganda. Open source does not negate the fact that maintenance costs money, and hundreds of tickets a month for a single feature is someone’s real unpaid work. Open core is a legitimate model, and many projects we use daily survive precisely because of it. The complaint in PLANKA’s case is justified not because the feature became paid, but because it was free and moved — and moved to a minor version where breaking changes aren’t typically expected.

Important:

And a fair caveat about forks that people like to skip. A fork is not a free solution and not an instant one. Forgejo announced in December 2022, and a full hard fork with a diverging codebase only happened in February 2024 — more than a year as a “drop-in replacement.” OpenTofu received a cease-and-desist from HashiCorp in April 2024. Forks live as long as they have maintainers and money; there are many more abandoned forks than successful ones. Having a fork is an argument, not a guarantee.

What to do right now if you have PLANKA

A concise action plan: do not update automatically; set up or verify a local admin with a password; dump the database; read issue #1754 in full, including migration comments; decide if you need SSO on a three-person install (for most home setups the answer is no) — and only then update. If you need SSO and don’t want to buy Pro, you have time: the old version isn’t gone and still works.

Sources

Question:

Interested in practice, not position. Who has experienced a situation where after updating a self-hosted service a function the whole project relied on disappeared—and what happened: paid for, rolled back, moved to a fork? And a separate question to those who run more than a dozen services at home: do you even read the CHANGELOG before docker compose pull, or do you also learn about changes from users?

GitHub лежал 7 часов 35 минут: три форжа, которые поднимаются за вечер