Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

Prologue — "AWS is hosting my database"
1. The Permissive Baseline — 90% of OSS is still MIT or Apache 2.0
2. The AWS Strip-Mining Problem — late 2010s
3. MongoDB and the Birth of SSPL (2018)
- 3.1 The OSI's verdict — "this is not open source"
- 3.2 MongoDB's outcome — it survived
4. Timeline of the Rebellion — eight years at a glance
5. The Elastic Arc — Apache 2.0 to SSPL to AGPL in four years
6. The Redis Arc — a 2024 deja vu
7. HashiCorp and OpenTofu — schism in the IaC camp
8. Sentry and FSL — "Apache 2.0 in two years"
9. Other Licenses — CockroachDB, Confluent, FUTO
10. The OSI Definition Fight — whose word is "open source"?
11. License versus Rights Matrix (2026)
12. What This Means — for whom
13. License Decision Tree (for startups and maintainers)
14. Anti-Patterns — do not do this
Epilogue — what we learned in eight years
- Decision Checklist — when adopting an OSS component
- Next post preview
References

Prologue — "AWS is hosting my database"

Autumn 2018. MongoDB CTO Eliot Horowitz posted a sentence on the company blog.

"We have made the difficult decision to relicense MongoDB Server."

The surface justification was one line. Underneath was a seed that would grow into an eight-year dispute. Cloud providers were taking open source software and reselling it as a hosted service, contributing nothing back to the companies that built it. MongoDB called it "strip-mining" — like a mine emptied of ore, AWS was hauling the value out.

Whether the diagnosis was right or not, MongoDB's decision lit the fuse. SSPL — the Server Side Public License. The name said "Public License," but the OSI ultimately refused to bless it as open source. After MongoDB came Elastic, Redis, Confluent, CockroachDB, MariaDB, HashiCorp, Sentry — each making a version of the same call. All of them framed it as self-defense against AWS.

In 2026 we are near the end of this rebellion. Elastic added AGPLv3 as an option in August 2024 and returned to OSI-approved open source. Redis followed in May 2025. HashiCorp was acquired by IBM, while OpenTofu took its place as a CNCF project. Sentry invented FSL — the Functional Source License — promising automatic conversion to Apache 2.0 after two years. FUTO minted "Source First."

This piece walks through that eight-year license war — what happened, why, and why that one-line license field matters when you pick a database in 2026. It is neither apologia nor accusation. The goal is to give you the tools to decide.

1. The Permissive Baseline — 90% of OSS is still MIT or Apache 2.0

Before discussing the license war, let us set the scene. The license distribution of public GitHub repositories in 2026, per the Synopsys Black Duck OSS Audit:

MIT — roughly 45 to 50%
Apache 2.0 — roughly 20 to 25%
BSD-3-Clause and BSD-2-Clause — about 5%
GPL family (GPL/LGPL/AGPL) — about 15%
MPL 2.0, EPL, ISC, other OSI-approved — about 5%
Source-available (BSL, SSPL, FSL, ELv2, RSAL, Confluent CL, FUTO, etc.) — under 1% combined

Every dramatic license fight in this post is happening inside that 1% of the market. The other 99% remains placidly MIT or Apache 2.0. Hold that thought. BSL, SSPL, and FSL are not shaking the entire market — they appear specifically in single-vendor infrastructure components (databases, search engines, IaC tools, the OSS parts of monitoring SaaS).

1.1 MIT — twenty-one lines of freedom

The MIT license text is about 170 words. Summary: "Take it for free, do whatever you want, just keep the copyright notice and do not blame us."

Commercial use OK
Modification OK
Redistribution OK
Repackaging under a proprietary license OK
No copyleft obligation

React, Rails, Express, Vue, Node.js core, Prettier, Bun — most of the daily-use tools we ship are MIT. MIT's strength is its simplicity, and its weakness is the same. If AWS were to take React, brand it as their own, and resell it, there is no legal mechanism to stop them. Fortunately(?) React is not the kind of business that gets stripmined.

1.2 Apache 2.0 — MIT plus patent protection

Apache 2.0 layers two things on top of MIT's permissions.

Explicit patent grant — contributors grant patent rights with their code. A contributor cannot later attack users with a patent on what they contributed.
Trademark carve-out — the license is explicit that it does not grant trademark rights.

Kubernetes, Kafka, Spark, TensorFlow, Terraform (pre-BSL), Cassandra — the big cloud-native projects picked Apache 2.0 for a reason. The patent shield made enterprise adoption possible.

1.3 The GPL family — the last bastion of copyleft

GPL/LGPL/AGPL are copyleft licenses. The shape is the same: if you take this code, modify it, and distribute the result, your derivative must also be released under the same license. Think of it as contagious.

GPL v2 and v3 — when you distribute the binary, you must release the source. The Linux kernel is GPLv2.
LGPL — the library-scoped variant. Static versus dynamic linking changes the copyleft reach.
AGPL — GPL with the SaaS loophole closed. You must release source even when serving the software over a network. Bruce Perens authored it; OSI approved it in 2007.

The last clause is what made AGPL load-bearing. Plain GPL only triggers source release "when you distribute the binary." SaaS does not distribute binaries — it just hosts the software behind an API. AWS hosting MongoDB under AGPL would force AWS to publish its modifications. That is why MongoDB picked AGPL originally, and also why MongoDB later moved off of AGPL — AWS sidestepped AGPL by writing a clean-room reimplementation called DocumentDB.

2. The AWS Strip-Mining Problem — late 2010s

By around 2015 a pattern became clear. Open source infrastructure built by a single vendor breaks as a business model in the cloud era. The reasons were simple.

AWS, GCP, and Azure can stand up a hosted version of any OSS overnight. They already have the infrastructure, marketing, and sales machine.
The vendor can run their own cloud, but cannot beat AWS on user pool or price. AWS sells the same OSS cheaper, better integrated, with more reliability.
AWS contributes almost no code back upstream. The OSS vendor pays the R and D cost; AWS captures the revenue.

The clearest example was MongoDB to AWS DocumentDB (January 2019). Right after MongoDB moved to SSPL in late 2018, AWS launched DocumentDB — a "MongoDB-compatible API" built without reusing any SSPL code. A clean-room implementation that routed around the license. MongoDB CTO Mark Porter later said publicly that DocumentDB was 34% compatible with MongoDB, but 34% was enough to capture meaningful market share.

The same script repeated.

Elasticsearch to AWS Open Distro for Elasticsearch (March 2019) — AWS reimplemented parts of the X-Pack paid features (security, alerting, SQL) as open source. When Elastic moved to SSPL in 2021, AWS forked again as OpenSearch.
Redis to AWS ElastiCache — AWS had hosted open source Redis as ElastiCache for years, building substantial revenue. When Redis relicensed in 2024, AWS pivoted to the Linux Foundation-backed Valkey fork.

The frustration of OSS vendors boiled down to one sentence: "We built it, AWS sells it, and we are going under." Whether that diagnosis is precise is debatable — Red Hat built a 34-billion-dollar revenue business in exactly the same environment. But the sentiment became the political fuel of the license war.

3. MongoDB and the Birth of SSPL (2018)

On October 16, 2018, MongoDB Inc published the Server Side Public License v1. The core idea was AGPL pushed one notch further.

SSPL core clause (paraphrase):
"If you offer this software as a service to third parties,
 you must release the source code of the entire service —
 including the management, monitoring, backup, load balancing,
 and user authentication that supports it."

AGPL demands "source for the modified OSS itself." SSPL demands "source for everything around the OSS too." From AWS's perspective this is effectively unusable — running DocumentDB on SSPL would require AWS to publish its internal operations stack.

3.1 The OSI's verdict — "this is not open source"

MongoDB submitted SSPL to OSI for approval. In January 2021 OSI rejected it.

"SSPL violates clause 6 of the Open Source Definition — 'No Discrimination Against Fields of Endeavor' — because it discriminates against a specific field, namely cloud hosting."

This ruling was decisive. From that moment SSPL was filed under 'source-available,' a separate bucket distinct from open source. This is not a vocabulary spat. Many enterprise compliance policies say "only OSI-approved open source is allowed."

3.2 MongoDB's outcome — it survived

The debate was loud, but MongoDB's business did not collapse. The opposite, in fact — after the SSPL switch, Atlas's share of revenue rose steadily, and by 2026 Atlas accounts for over 70% of MongoDB's revenue. The license did not directly save the business, but it did not kill it either.

4. Timeline of the Rebellion — eight years at a glance

2010 ───────────────────────────────────────────────────────────── 2026
       The permissive golden era                  Rebellion and normalization

2010    Redis released (BSD 3-Clause)
2011    HashiCorp founded; Terraform under MPL 2.0
2012    Elasticsearch 1.0 (Apache 2.0)
2018-10 MongoDB to SSPL    just before AWS DocumentDB
2019-01 AWS DocumentDB launches
2019-03 AWS Open Distro for Elasticsearch
2021-01 Elastic to SSPL + ELv2    Apache 2.0 abandoned
2021-04 AWS forks to OpenSearch
2021-01 OSI: SSPL is not open source (official ruling)
2023-08 HashiCorp to BSL 1.1    Terraform, Vault, Consul, Nomad
2023-09 OpenTofu (Terraform fork) announced, Linux Foundation
2023-11 Sentry invents FSL — auto-convert to Apache 2.0 after 2 years
2024-01 OpenTofu 1.6 GA
2024-03 Redis to SSPL + RSALv2    against AWS ElastiCache
2024-03 Linux Foundation forks Valkey (successor to OSS Redis)
2024-08 Elastic adds AGPLv3 option    returns to OSI open source
2025-02 IBM completes HashiCorp acquisition
2025-04 OpenTofu becomes a CNCF incubation project
2025-05 Redis adds AGPLv3 option    returns to OSI open source
2025-11 Salvatore Sanfilippo rejoins Redis (developer evangelist)
2026-05 Present: end of the rebellion, partial rollback

Looking at this timeline, a common pattern emerges. (1) Single-vendor OSS (2) experiences an AWS hosted launch (3) moves to a non-OSI license (4) gets community-forked, and (5) some eventually return to an OSI license. We can call this the "license pendulum."

5. The Elastic Arc — Apache 2.0 to SSPL to AGPL in four years

5.1 The shock of January 2021

When Elastic CEO Shay Banon posted his blog, the search and logging industry briefly paused. Elasticsearch and Kibana were moving from Apache 2.0 to a dual license of SSPL plus ELv2 (Elastic License v2).

Banon's framing was familiar.

"We are forking ourselves so that nobody else needs to fork us."

A response to AWS running Open Distro for Elasticsearch. But the OSS community's reaction was cold. "A betrayal of ten years of Apache 2.0 promises" was the common refrain.

5.2 AWS's answer — the OpenSearch fork (April 2021)

Three months later AWS announced OpenSearch, forked from the last Apache 2.0 commit (7.10.2). By 2026 OpenSearch is a Linux Foundation project, with Aiven, Logz.io, Bonsai and others as core contributors alongside AWS. The "search market split" Elastic feared actually happened.

5.3 August 2024 — Return to AGPL

Three and a half years later, Elastic flipped the license again. AGPLv3 was added next to SSPL and ELv2, creating a triple-license model. Banon wrote: "We are now an Open Source Initiative-approved open source company again."

Two calculations sat underneath.

Reputation repair: Elastic had taken a real reputational hit. Returning to an OSI-approved license was an attempt to recover part of it.
Closing the OpenSearch gap: As OpenSearch grew, Elastic needed to win back mindshare in the OSS community.

AGPL is weaker copyleft than SSPL, but it is OSI-approved. AWS can host AGPL code as a managed service, provided AWS publishes its modifications. So Elastic gave up some competitive shielding against AWS in exchange for getting the OSI badge back. A business calculation, not an act of altruism.

6. The Redis Arc — a 2024 deja vu

6.1 The shock of March 2024

On March 20, 2024, Redis Inc announced that starting with Redis 7.4 the license would dual-fork to SSPL plus RSALv2 (Redis Source Available License v2). The framing matched Elastic — AWS, GCP, and Azure were running Redis OSS as their own businesses.

6.2 The Valkey fork — six days later

Six days after the announcement, the Linux Foundation announced the Valkey fork. AWS, Google Cloud, Oracle, Ericsson, and Snap were founding members. The starting point was Redis 7.2.4, the last BSD 3-Clause release. Six months later Valkey 8.0 was out, and by 2026 most cloud providers host Valkey instead of Redis.

The notable subplot was Redis creator Salvatore Sanfilippo ("antirez"). He had moved on from Redis by 2024, but in November 2024 he announced his return to Redis Inc as a developer evangelist. That decision shaped what came next.

6.3 May 2025 — Adding AGPL

Roughly six months after Salvatore's return, Redis added AGPLv3 as a third license option starting from Redis 8. Users can now pick among RSALv2, SSPLv1, and AGPLv3. The Elastic playbook, almost verbatim.

The Redis statement was direct.

"We made a mistake. We are returning to OSI-approved open source — but on our terms, with AGPLv3."

Community reaction was mixed. Percona's Vadim Tkachenko welcomed it as "a positive step" but called the move "largely a marketing manoeuvre." Valkey had built enough momentum, and most cloud providers had no incentive to switch back. You can flip the license back — you cannot flip trust back.

7. HashiCorp and OpenTofu — schism in the IaC camp

7.1 The BSL switch of August 2023

On August 10, 2023, HashiCorp moved Terraform, Vault, Consul, Nomad, Boundary, Waypoint, and Packer all at once from MPL 2.0 to BSL 1.1 (Business Source License). BSL, originally MariaDB's invention, has this shape.

Source open: yes, anyone can read it.
Use restricted: outside of the "Additional Use Grant" the license forbids commercial use. For HashiCorp specifically, that meant "offering a product or service that competes with HashiCorp's products."
Auto-conversion after four years: after four years, the source auto-converts to an open source license like MPL 2.0.

On the surface BSL is gentler than SSPL — "wait four years and it becomes OSS." But the core function was to block cloud providers from launching a hosted Terraform Cloud competitor during those four years.

7.2 OpenTofu — a fork within a month

One month after the announcement, in September 2023, the OpenTF Manifesto went live. Companies in the Terraform ecosystem — Gruntwork, Spacelift, env0, Scalr, Harness — co-authored a public statement. The demands were simple.

HashiCorp reverts Terraform to MPL 2.0.
If not, we fork.
The fork goes to the Linux Foundation.

HashiCorp said no. The OpenTF Foundation formed on September 20, and in November the name became OpenTofu (avoiding trademark clashes). OpenTofu 1.6.0 GA shipped in January 2024.

7.3 The 2026 landscape

OpenTofu 1.9 (May 2026) — shipping features Terraform does not have, like split for_each keys, state encryption, and dynamic providers.
CNCF incubation — formally adopted April 2025. Multi-vendor governance stabilized.
IBM acquires HashiCorp — completed February 2025. Terraform is now part of IBM's cloud tooling line.

OpenTofu and Terraform have diverged at the core by 2026. Some post-Terraform-1.6 features are not in OpenTofu, and OpenTofu's new features are not in Terraform. Even the state file format has drifted apart subtly. They are effectively two different tools now.

For a startup the decision rule is clean.

Need IBM/HashiCorp enterprise support — Terraform.
Prefer vendor-lock-free OSS — OpenTofu.
Run on AWS/Azure/GCP equally — OpenTofu is the safer pick.

8. Sentry and FSL — "Apache 2.0 in two years"

8.1 The critique of BSL

BSL's four-year conversion window felt long. "OSS in four years" almost meant "not OSS now." And the BSL "Additional Use Grant" clause was wordy and ambiguous, which compliance teams found hard to interpret.

8.2 Inventing FSL (November 2023)

Sentry CEO David Cramer worked with Heather Meeker (the lawyer behind BSL) to create the Functional Source License (FSL). The core idea is BSL stripped down and simplified.

FSL core:
- "Permitted Purpose": anything OK, except "Competing Use"
- "Competing Use": offering a product that directly competes with the licensor
- Auto-convert after 2 years to Apache 2.0 or MIT
- Sentry picked Apache 2.0

Two key differences from BSL.

Shorter conversion window: 4 years to 2 years. This is the decisive change. Two years is "roughly the same generation" on the tech cycle.
Simpler language: the verbose "Additional Use Grant" gets replaced by the two-term "Permitted Purpose / Competing Use" pair.

8.3 Sentry's later retreat

Interestingly, Sentry itself moved off of FSL by late 2024, returning to BUSL for self-hosted Sentry and Codecov. The reason cited was that "Competing Use" was too narrow. FSL survived as a license, but its inventor walked away.

FSL has found other adopters.

Convex (realtime database)
Keygen (license management)
Various SaaS OSS components

FSL has settled in as "the more honest BSL." "We are not pretending to be OSS — but in two years we genuinely will be." That promise reads more credible.

9. Other Licenses — CockroachDB, Confluent, FUTO

9.1 CockroachDB — BSL then proprietary

Cockroach Labs moved to BSL in 2019, and in 2024 took the further step of converting the core to a fully proprietary CockroachDB Enterprise License. Free self-hosting is no longer available. The most aggressive path of all the cases.

Startups picking CockroachDB should be aware. It began as an "OSS database," but in 2026 it is in practice a commercial product requiring an enterprise license.

9.2 Confluent Kafka — the Confluent Community License

Apache Kafka itself is Apache 2.0. But the additional components Confluent built (KSQL, parts of the Schema Registry, many Kafka Connect connectors) are under the Confluent Community License (CCL).

The CCL core restriction: "You may not use this to offer a Kafka SaaS business." AWS MSK (Managed Streaming for Kafka) cannot use Confluent's components, and AWS had to re-implement equivalents of KSQL and the Schema Registry.

9.3 FUTO and "Source First"

Eron Wolf's FUTO published its own FUTO License in 2024. The core clause: "non-commercial use is free, commercial use requires explicit permission." Under the OSI definition this is plainly not open source.

The interesting move is FUTO's rhetoric. Instead of "open source," they coined the term "Source First." Rather than fighting OSI on the definition, they explicitly separate themselves: "We deliver the social functions of OSS (transparency, learnability, free modification) — but we do not follow the OSI definition."

OSI does not love this. It is a direct challenge to the definitional monopoly of the words "open source." But by 2026, new categories like "source-available," "fair-code," and "source-first" have effectively taken root. The single definition of OSS is fracturing.

10. The OSI Definition Fight — whose word is "open source"?

10.1 OSD — ten clauses

The OSI, founded in 1998, maintains the Open Source Definition (OSD) as ten clauses. The load-bearing ones:

Free Redistribution — anyone can freely redistribute.
Source Code — source code must be included or freely accessible.
Derived Works — modifications and derivatives must be allowed.
Integrity of The Author's Source Code — modifications may be required to be distributed as patches.
No Discrimination Against Persons or Groups.
No Discrimination Against Fields of Endeavor — this is the clause that blocked SSPL.
Distribution of License.
License Must Not Be Specific to a Product.
License Must Not Restrict Other Software.
License Must Be Technology-Neutral.

10.2 The weight of clause 6

Clause 6 — "No Discrimination Against Fields of Endeavor." This is the pivot. SSPL, BSL, FSL, CCL, FUTO — they all share one trait: they target a specific field of endeavor, namely cloud hosting businesses. That is a clause 6 violation.

OSI's position is consistent. "If a license prevents someone from using it, it is not open source." This is not a word game. Every OSI-approved license from GPL to MIT respects clause 6. It is the trust foundation of the OSS ecosystem.

10.3 The "source-available" counterargument

The vendor side is also clear.

"The OSI definition was written in 1998. The enemy then was Microsoft proprietary licenses. The enemy in 2026 is different — it is AWS's capital-backed cloud hosting. A 1998 definition cannot defend against a 2026 threat."

This debate has not resolved. OSI defends the words "open source," and vendors accept the new term "source-available" — a kind of settlement has emerged. Behind it sits a larger question: "can an open source company survive as a business?" No one yet has a clear answer.

11. License versus Rights Matrix (2026)

For each license, here is what a user gets. Y is allowed, N is forbidden, C is conditional.

Right	MIT	Apache 2.0	GPL v3	AGPL v3	BSL 1.1	SSPL v1	FSL 1.1	ELv2	RSALv2	CCL
Read source	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y
Internal modify and use	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y
Repackage under proprietary	Y	Y	N	N	C	C	C	C	C	C
Copyleft obligation	N	N	Y	Y(net)	N	Y(strong)	N	N	N	N
Explicit patent grant	N	Y	Y	Y	N	Y	N	N	N	N
Run as a hosting business	Y	Y	Y	Y(if source published)	N(conditional)	C(full source release)	N(for 2 years)	N	N	N
OSI-approved	Y	Y	Y	Y	N	N	N	N	N	N
Time-based OSS conversion	-	-	-	-	after 4 yrs	-	after 2 yrs	-	-	-

This matrix helps a decision. If you need the OSI badge, your options are the GPL family or the permissive set. If you need to deter cloud businesses, you are looking at SSPL, BSL, FSL, or ELv2. If "eventually open" is the goal, FSL is the fastest at two years.

12. What This Means — for whom

12.1 Startups: picking an OSS database or component

The key question — "how bad is the relicense risk on this?"

When a startup leans on data infrastructure, a license change is a direct hit. Evaluate in this order.

Vendor lock-in risk — controlled by a single company, or by multi-vendor governance (CNCF, Linux Foundation, Apache Foundation)?
Permissive vs copyleft — does our code embed this OSS, or run it as a separate process?
Hosting business potential — could our service effectively become "a hosting service for this OSS"?
Long-term dependence — will we still need this in five years?

12.2 Cloud vendors: the hosting business

For AWS, GCP, and Azure the license landscape is getting more complex. Their 2026 response patterns:

Fork and self-operate: OpenSearch, Valkey. AWS forks directly and hosts.
Clean-room reimplementation: DocumentDB. Use no SSPL code, expose only the compatible API.
Revenue-sharing contracts: deals with some OSS vendors directly. Parts of the Confluent ↔ AWS and MongoDB ↔ AWS partnerships.
Acquisition: HashiCorp to IBM; GitLab being courted; etc.

12.3 OSS projects: sustainability

For maintainers, the license decision is essentially a business model decision. The 2026 consensus, such as there is one:

Pure-OSS single-vendor is hard. The Red Hat model worked at a particular scale and moment.
Direct collision with cloud providers is self-harm. You cannot win a hosting war against AWS.
Open Core is the most realistic shape. Core is OSS, add-ons are proprietary.
Foundation transfer builds trust. Once a project sits inside CNCF, the Linux Foundation, or Apache, the relicense risk disappears.

13. License Decision Tree (for startups and maintainers)

If you have to pick a license for a new OSS project, walk this tree.

[1] Is this project led by a single company?
    ├─ Yes — go to [2]
    └─ No (foundation/multi-vendor) — Apache 2.0. Done.

[2] Within 5 years, will there be a SaaS/hosting business on top of it?
    ├─ Yes — go to [3]
    └─ No (pure OSS, consulting/support model) — MIT or Apache 2.0. Done.

[3] Is the hosting business threatened by direct competitors (AWS/GCP/Azure)?
    ├─ Yes — go to [4]
    └─ No (internal tool, B2B SaaS focus) — Apache 2.0 + trademark protection. Done.

[4] Is the OSI-approved badge required for compliance?
    ├─ Yes — AGPLv3. Done. (Elastic and Redis chose this.)
    └─ No — go to [5]

[5] Do you want to explicitly promise "we will return this to OSS eventually"?
    ├─ Yes, 2 years — FSL 1.1
    ├─ Yes, 4 years — BSL 1.1
    └─ No, permanent proprietary — ELv2 or your own license (Codeium-style)

This tree is not absolute. But if you write down explicitly which node you answered which way, you will be able to justify the choice — and, if you ever change the license later, explain the change to the world. Most of the criticism Elastic and Redis took came not from the license change itself but from "you never told us why upfront."

14. Anti-Patterns — do not do this

Common mistakes in license decisions, gathered into a list.

14.1 Misusing the words "open source"

Calling a non-OSI license "open source" puts you in immediate conflict with OSI and gets your software blocked by enterprise compliance. In 2026 the precise word is "source-available." Be specific.

14.2 Sudden license changes

This is where Elastic and Redis paid the highest cost. Announce license changes at least six months in advance, with the rationale and supporting data published. "Suddenly" almost always breaks trust.

14.3 Dual licensing without a CLA

If contributors hold the copyright on their code, the company cannot unilaterally relicense. If you ever plan to commercialize, take a Contributor License Agreement or a DCO with copyright assignment from day one. Redis could relicense precisely because Redis Inc owned all contributor copyright.

14.4 The wrong "AWS is a threat" framing

For most OSS projects, AWS is not a threat. Very few OSS projects are large enough to be worth hosting at AWS scale. If your project is not one of those few, a BSL or SSPL framed as "AWS defense" is an axe to your own foot. It only slows adoption.

14.5 The quadruple-license trap

Elastic now offers AGPLv3 + SSPLv1 + ELv2 as three concurrent options. That looks like generosity, but for compliance teams it is a nightmare. You must explicitly pick a license, and the choice must propagate consistently across every dependent component.

Epilogue — what we learned in eight years

From MongoDB's SSPL announcement in 2018 to Redis's AGPL return in 2025 — eight years. The lessons are short.

A license expresses a business model. It is not the business model itself. Changing the license does not grow revenue.
You can only partly defend yourself against cloud providers through licensing. AWS almost always responds with a clean-room reimplementation (DocumentDB) or a fork (OpenSearch, Valkey).
The OSI badge has real value. Compliance, hiring, and PR all move on it. That is why Elastic and Redis came back to AGPL.
Foundation transfer is the final form of trust. Projects under CNCF, the Linux Foundation, or Apache have effectively zero relicense risk.
The eight-year pendulum is settling. SSPL and BSL survive, but only in a small slice of the market; many vendors have rolled back toward AGPL or Open Core.

If you read this in 2026 and have to pick a single OSS component, the final checklist is this.

Decision Checklist — when adopting an OSS component

Is the license OSI-approved? (MIT, Apache 2.0, BSD, GPL, AGPL, MPL, EPL)
Is it controlled by a single company, or by a foundation (CNCF, LF, ASF)?
Any license change in the last 5 years? What is the probability of a future change?
Does a community fork exist? What is its adoption versus the original? (OpenSearch, Valkey, OpenTofu, etc.)
Does our use pattern trigger the AGPL copyleft? (network-exposed plus external users)
Does our compliance policy allow SSPL, BSL, or FSL?
Will we still need this in five years? If so, what is the migration path?

Next post preview

The next post will look at the macro landscape of OSS governance in 2026 — the changing role of foundations (CNCF, Linux Foundation, Apache, Eclipse), how government regulation (EU CRA, US executive orders) is reshaping OSS, and the unresolved question of whether AI model weights count as open source. If the license is one line of text, governance is the political structure that breathes through it.