Short answer. Open source license risk is the chance that software you already run changes its terms in a way that restricts how you deploy it. Between 2021 and 2026, Elastic, HashiCorp, Redis, Open WebUI and NocoDB all moved to licenses the Open Source Initiative does not recognize. Three of those changes produced forks that survived (OpenSearch, OpenTofu, Valkey), and two produced reversals with no visible reverse migration. You can evaluate the risk before you deploy by checking who holds the copyright, what the license text actually says, where the project's revenue comes from, whether a credible fork exists, and how long a migration would really take.
Who this is for. Teams and individuals who self host production services and pick their own components, rather than inheriting them from a procurement process.
In January 2026, someone opened a discussion on the NocoDB repository with a plain question: since version 0.301.0 is no longer published under an OSI approved license, should the project still be described as open source, or would "source available" be the more honest label?
The maintainers answered candidly, and the release notes say the same thing plainly: NocoDB transitioned from AGPL 3.0 to a fair code Sustainable Use License, following the path n8n took before it, framed as a way to keep giving more to the community edition while refusing to subsidize companies that take without contributing. The license text limits use to your own internal business purposes, or to non-commercial and personal use. The project also uses a contributor license agreement, which is why relicensing external contributions raised no legal obstacle. By the July 2026 release, self hosted deployments resolve their feature tier from the signed license key itself, so installs that had quietly been running Enterprise features they were not licensed for now fall back to the plan they actually hold.
Nothing about that is unusual any more. That is the point.
If you self host, the license file in a repository has become an operational input, not a legal footnote. It determines whether you can still pull the image you built your workflow around, whether the feature you demoed to your team is still in the free tier next quarter, and whether the project you standardized on will be maintained by the same people in two years. Choosing infrastructure in 2026 is a governance decision that happens to have a technical component, and most teams are still making it the other way round.
Open source vs source available: what the license labels actually mean
Open source is a defined term. The Open Source Initiative maintains the definition and the list of approved licenses, and a license that is not on that list is not open source no matter how the project markets itself. Source available means the code is published and usually modifiable, but with restrictions on deployment or commercial use that would disqualify it from the OSI definition.
Here is what you are likely to encounter in a self hosted stack, and what each one restricts.
OSI approved
BSD 3-Clause, MIT and Apache 2.0. Permissive. They restrict almost nothing beyond attribution. Valkey ships under BSD 3-Clause, OpenSearch under Apache 2.0.
MPL 2.0. Weak copyleft, applied file by file. Files you modify stay under MPL, the rest of your codebase does not. Used by OpenTofu.
AGPLv3. Strong copyleft. Network use triggers the obligation to publish modified source, which matters the moment you run a modified build as a service. Offered by Redis 8 and by Elasticsearch and Kibana, in each case as one option of three.
Not OSI approved
BSL 1.1. Source available. Blocks commercial use that competes with the licensor, until each release converts to a designated open license after a set period. HashiCorp set four years per release, converting to MPL 2.0. Used by Terraform, Vault, Consul and Nomad.
SSPL v1. Source available. You may offer the software as a service only if you publish the entire service management stack around it, which in practice nobody does. Used by MongoDB, and still offered alongside AGPLv3 by both Redis and Elastic.
Elastic License 2.0. Source available. Blocks offering the product as a managed service, and blocks circumventing license key functionality. Used in Elastic's default distributions.
Sustainable Use License and fair code variants. Source available. Limit you to your own internal business purposes and to non-commercial or personal use, which rules out offering the software as a service. Used by n8n, and by NocoDB from 0.301.0, previously AGPLv3.
BSD 3-Clause plus a branding clause. The base is permissive, but the added clause restricts removing or altering project branding above a usage threshold, which is enough to keep it off the approved list. Used by Open WebUI from v0.6.6.
The practical consequence: anything in the first group means you deploy and stop thinking about it. Anything in the second means somebody on your side needs to have read the specific clauses before the service goes into production.
What changed: a timeline of open source relicensing, 2021 to 2026
The relicensing wave is old enough now that we can stop arguing about motives and just look at outcomes.
2021. Elastic moved the Apache 2.0 source of Elasticsearch and Kibana to a dual SSPL and Elastic License 2.0 arrangement at the 7.11 release. AWS forked 7.10.2 in April 2021 and shipped it as OpenSearch under Apache 2.0.
August 2023. HashiCorp relicensed Terraform, Vault, Consul and Nomad from MPL 2.0 to the Business Source License 1.1. Within days a manifesto appeared on GitHub signed by a long list of companies. The Linux Foundation adopted the fork as OpenTofu in September 2023, the first stable release shipped on 10 January 2024, and the CNCF accepted the project in April 2025.
March 2024. Redis Ltd moved Redis from BSD 3-Clause to a dual SSPLv1 and RSALv2 license, which meant any cloud provider offering a managed Redis compatible service now needed a commercial agreement. Within weeks AWS, Google Cloud, Oracle, Ericsson and Snap backed a fork of Redis 7.2.4, the last BSD release, and the Linux Foundation accepted it as Valkey in late March 2024.
August 2024. Elastic added AGPLv3 alongside SSPL and ELv2, with the change targeted at the 8.16 release. Founder Shay Banon published a post titled "Elasticsearch Is Open Source. Again!"
April 2025. The wave reached the self hosted application layer rather than the infrastructure layer, and it arrived in a softer form. Open WebUI kept a BSD 3-Clause base at v0.6.6 but added a branding protection clause, plus a contributor license agreement for anything submitted after v0.6.5. Deployments of fifty users or fewer in a rolling thirty day window are exempt, as are substantive contributors with written permission and holders of an enterprise license. Everything up to v0.6.5 stays BSD 3-Clause and can still be forked freely.
May 2025. Redis added AGPLv3 as a third option from Redis 8, making the project OSI compliant again.
January 2026. NocoDB moved from AGPLv3 to a fair code Sustainable Use License at version 0.301.0.
Five departures and two returns in five years, and the most recent departure arrived after both returns. This is not a trend with a direction. It is a permanent condition of the ecosystem.
Do open source forks actually survive? What Valkey, OpenTofu and OpenSearch prove
Yes, but only under specific conditions, and by 2026 there is enough evidence to name them precisely.
AWS reported in May 2026 that Valkey had marked its second anniversary with more than 100 million Docker pulls and adoption across nearly every major cloud provider. AWS launched ElastiCache for Valkey in October 2024 with serverless priced 33 percent lower and node-based clusters 20 percent lower than the other supported engines, and it now recommends Valkey for new deployments. Google offers Memorystore for Valkey and Oracle supports it on OCI Cache. The release cadence is steady: ElastiCache picked up Valkey 9.0 in May 2026 and 9.1 in July 2026. When the largest clouds recommend a fork over the original and price it lower, the question of whether the fork survives is settled.
OpenTofu followed the same arc, and it has stopped being a renamed Terraform. Native state encryption and early variable evaluation shipped in OpenTofu with no equivalent in Terraform's open source CLI. The divergence runs both ways, which is worth stating plainly: Terraform introduced ephemeral values and ephemeral resources in version 1.10 in late 2024 and write-only arguments in 1.11, and OpenTofu added its own ephemerality support a year later in 1.11. Neither project is simply trailing the other. Meanwhile IBM completed its 6.4 billion dollar acquisition of HashiCorp on 27 February 2025, and Terraform's roadmap now runs through IBM's commercial priorities, including integration with watsonx, Ansible and OpenShift.
OpenSearch is the oldest of the three and the quietest, which is its own kind of evidence. AWS forked Elasticsearch 7.10.2 in 2021, kept it on Apache 2.0, and later moved it to the Linux Foundation under its own foundation structure, which retired the obvious objection that the project was one vendor's answer to another vendor.
Three forks, one pattern, and it is worth stating explicitly because it is the closest thing to a rule this whole story produced.
- Funded backing at launch. A major cloud provider or a coalition of vendors put paid engineers on it from day one.
- Neutral governance. The project sits with a foundation, so no single company can relicense it again.
- An open license. Permissive or OSI approved, so downstream adoption carries no new legal analysis.
Forks that lack all three do not tend to survive contact with the second year. That is the test to apply when someone on your team says "there is already a fork" as if that settles the matter.
Do license reversals bring users back?
Redis is open source again. Elasticsearch is open source again. Neither reversal appears to have brought the migrated users back, and nobody publishes a number for reverse migration, so treat what follows as an argument from switching costs rather than as a measurement.
Once a team has swapped a binary, updated its runbooks, retrained its on call engineers and passed a procurement review on the new component, the cost of moving back is the same as the cost of moving out, and the motivation is far weaker. Migration is sticky in the direction it last moved. A vendor that relicenses is not making a reversible decision about its license. It is making an irreversible decision about its user base, and it usually finds this out about eighteen months later.
For you, the practical consequence is smaller and more useful: the moment to evaluate license risk is before deployment, not during the incident. Once a project is load bearing in your stack, you have already lost most of your options.
Why license risk hits self hosters harder than enterprises
Enterprise teams have a procurement function that reads license files, plus legal review, vendor risk registers and a person whose job is to notice that a component changed terms. It is slow and annoying and it mostly works. If you run your own infrastructure with a small team, none of that exists, and three things make your exposure worse.
You may be the distributor. The moment you host a service for anyone outside your organization, including clients, users of a product you sell, or a community instance, several source available licenses start to apply to you in ways they do not apply to a company running the same software internally. The trigger in most of these licenses is commercial activity and offering the software as a service, not company size.
Your upgrade path is a single command. Nobody reviews the license diff between two container tags. If a project gates a feature behind a paid tier in a minor release, you find out when something stops working, in production, usually on the day you least wanted to find out. The NocoDB July 2026 release is a clean example of the mechanism: same image, feature set resolved at runtime from a license key rather than from what the binary contains.
Open core creep is invisible until it isn't. Very few projects announce that they are becoming less open. They ship a release where SSO moved to the paid tier, then one where audit logs did, then one where the feature you actually needed did. Each individual step is defensible. The cumulative direction is a product decision that was never announced as one, and it is far more common than an outright license change.
A legal dimension is arriving from the other side too. The EU Cyber Resilience Act starts its vulnerability and incident reporting obligations on 11 September 2026, with full application in December 2027, and it introduces a defined role for open source stewards. Governance is becoming something regulators care about, which is a separate article, but it belongs in the same mental bucket.
How to evaluate license risk before you deploy: five questions
Avoiding single vendor projects is not the answer. Plenty of excellent software is built by companies that need revenue, and refusing to run any of it would leave you with a very short list. The answer is pricing the risk instead of ignoring it. Ask these five questions before a service becomes load bearing.
1. Who can relicense this tomorrow?
Look for a copyright assignment or a contributor license agreement that transfers rights to one company. If a single legal entity holds the rights, a relicense is a board decision rather than a community negotiation. Projects governed by the Linux Foundation, the CNCF or the Apache Software Foundation cannot do this unilaterally, and that is the entire value of the arrangement. NocoDB is the clean illustration: when the license changed, the discussion thread noted that the project uses a CLA, so relicensing contributed code raised no legal obstacle at all.
2. What is the actual license, not the label on the README?
"Open source" is now used to describe BSL, SSPL, the Elastic License, Sustainable Use licenses, fair code and a range of bespoke variants, none of which the OSI recognizes. Read the file. Look specifically for a competition clause, a service provider clause, and any time delay before the code converts to an open license.
3. Where is the revenue coming from?
A project funded by managed hosting has a structural reason to restrict competitors and very little reason to gate features you use on your own server. A project funded by an enterprise tier has a structural reason to move features out of the free tier over time. Neither is wrong. They fail differently, and knowing which one you are dealing with tells you what to watch for.
4. If it forks, does the fork clear all three bars?
Funded backing, neutral governance, open license. Two out of three describes a project that will be alive next year and quiet the year after.
5. How long would migration actually take?
Not the binary swap. The runbooks, the monitoring, the backup and restore procedure you have never tested, the integration that nobody documented, the client who has to be told. Write the number down. That number is the real cost of the license risk you are accepting, and it is the only one that will matter when you need it.
If you are already thinking in these terms about the tooling layer, our comparison of Stacker, Coolify, CapRover, Vercel and Railway applies the same lens to deployment platforms, and the real cost of self hosting in 2026 covers the economic half of the same decision.
How to spot a relicense before it happens: six early warning signals
Relicensing is almost never a surprise to people who were paying attention. The signals are consistent across almost every case in the timeline above.
- A contributor license agreement or copyright assignment requirement appears, or is tightened, for new contributors.
- Funding news lands, particularly a growth round or an acquisition. Investors ask about monetization, and the license is the easiest lever.
- The word "sustainability" starts appearing in release notes and maintainer posts.
- Features move from the community edition to a paid tier in consecutive releases.
- The commercial hosted offering starts shipping features that never reach the self hosted build.
- Trademark policy is published or tightened. This is often the first move, because it is the least controversial one, and it frequently precedes a license change by several months.
Tooling helps. Pin your images by digest rather than by tag so an upgrade is a decision rather than an accident. Keep an SBOM so you can answer "where does this component appear" in minutes instead of days. GitHub moved open source license compliance into public preview on 30 June 2026. It lets an enterprise define a central license policy and block noncompliant dependencies at the pull request, with an Evaluate mode that annotates without blocking. Read the eligibility line before you get excited: it is limited to GitHub Enterprise Cloud customers holding GitHub Advanced Security Code Security licenses, so most small self hosting teams cannot use it, and it covers dependencies rather than the services you deploy. For everyone else the equivalent is a license field in your own SBOM and the discipline to look at it.
What to do when a project you run changes its license
It will happen eventually to something in your stack. The response that works is boring, and it has four steps.
Do not migrate on the day of the announcement. The first forty eight hours produce the loudest takes and the worst decisions, and a fork announced in that window has not yet demonstrated any of the three qualities that predict survival.
Establish whether the change affects you at all. A large share of relicensing changes are aimed squarely at cloud providers and managed service vendors. If you run a service internally, or for a fixed set of clients under contract, many source available licenses leave you exactly where you were. Read the text before you act on the headline.
Pin your current version. You are entitled to keep using the release you already have under the license it shipped with. Prior releases do not retroactively change terms. That buys you months, and months is all you need.
Then evaluate, budget and decide. Score the fork against the three criteria, cost the migration honestly, and choose. Sometimes the answer is to stay and pay, and that is a legitimate outcome rather than a defeat.
The mechanics are the same ones that apply to any component reaching end of life, which is why the Gateway API migration playbook we published for ingress-nginx reads like a template for this situation as well.
Why infrastructure choice is now a governance decision
For a long time, choosing infrastructure was a technical exercise with a compliance checkbox attached. Benchmarks, feature matrices, operational complexity, and then somebody confirmed the license was permissive and everyone moved on.
The five years since Elastic's first relicense have inverted that. The technical comparison between Redis and Valkey, or between Terraform and OpenTofu, is genuinely close. The governance comparison is not close at all, and it is the one that predicts where you will be in three years. Engineers who learned this the hard way in 2024 now check the governance model before they check the benchmarks, and they are right to.
Own the infrastructure, and you own the decision about what runs on it. That is worth something on the day someone else's board meeting changes the terms.