Chaos and Order

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

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

Prologue — How we got here by 2026

As of May 2026, the question "is this actually open source?" comes up in engineering Slacks at least once a week. Elastic, Redis, HashiCorp, MongoDB, Sentry, Cockroach, Confluent, MariaDB, n8n — a large share of the tools we use every day are no longer distributed under a license recognized by the OSI (Open Source Initiative).

You can compress the last seven years into a single sentence. **"Cloud companies (especially AWS) sell managed services built on our code and make more money than we do," and the OSS companies responded by changing licenses.** That dynamic produced a long line of "source-available" licenses outside the OSI definition, and every move created a community fork.

This post maps the seven years. Who changed what and when, why they did it, which forks survived, and what your company should actually decide in 2026. Twelve chapters, roughly 65 minutes of reading.

Three big shifts up front.

- **BSL is now a de facto standard.** MongoDB invented SSPL in 2018. HashiCorp moved Terraform, Vault, and Consul to BSL in 2023. Redis, Sentry, and Cockroach all followed in 2024. More than half of new infrastructure OSS launches under BSL or a variant.

- **Forks always happen.** Elastic into OpenSearch (AWS, 2021), Terraform into OpenTofu (LF, 2023), Vault into OpenBao (LF, 2024), Redis into Valkey (LF, 2024). The Linux Foundation has effectively become the "fork incubator."

- **The OSI definition is under pressure.** There is simultaneous push to "recognize source-available as open source" and counter-criticism that "the OSI definition is broken." In 2024 and 2025, OSI sat at the center of another debate with the Open Source AI Definition (OSAID).

1. Why everyone is moving to non-OSI licenses

Let us first define "non-OSI license." The OSI was founded in 1998 as a nonprofit and stewards the Open Source Definition (OSD). The OSD has ten clauses, and the one most often violated by the licenses we cover is #6 (no discrimination against fields of endeavor — "cannot restrict use to specific business areas").

BSL, SSPL, RSALv2, FSL, ELv2 — most of the licenses in this post violate #6. They either forbid selling the software as a managed service, treat companies above a revenue threshold differently, or only flip to Apache after a delay.

**Why companies move off OSI.** Three reasons usually combine.

1. **Managed-service competition from AWS, Google, and Microsoft.** Amazon ES (2015), Amazon RDS, Amazon DocumentDB (MongoDB API compatible), Amazon MemoryDB (Redis compatible), Amazon EMR (Hadoop and Spark) — the pattern of AWS taking OSS and selling it managed has repeated. The OSS company's traffic ends up at AWS while company revenue stalls.

2. **VC pressure.** Most OSS companies see revenue plateau at Series B or C. As the 2020 to 2023 ZIRP (zero interest rate policy) era ended, VCs pushed harder on "how will you monetize this?" Relicensing is the most direct answer.

3. **Imitation accelerates.** MongoDB moved to SSPL in 2018 and did well (the stock dropped, then recovered fully). Elastic followed with SSPL and ELv2 in 2021. HashiCorp moved to BSL in 2023. "There's precedent, and the market accepted it" lowers the bar for the next company.

**The non-OSI license family.**

| --- | --- | --- | --- |

| Sustainable Use License | n8n (2022) | Internal use and embedding allowed, selling hosting forbidden | No |

When Elastic returned to AGPL in August 2024, AGPL was rediscovered as "the alternative to BSL." AGPL is a genuine OSI-approved open source license while still producing the effect of "if AWS wants to sell this managed, they have to release their own code too," which is cleaner than SSPL from the company's perspective.

2. The OSI definition versus "source-available" debate

The OSD has ten clauses. The ones the OSI has explicitly cited as being violated by BSL and SSPL include:

- **OSD #5 (No discrimination against persons or groups):** SSPL applies differently to SaaS companies, which OSI reads as discrimination.

- **OSD #6 (No discrimination against fields of endeavor):** BSL adds field-restricted clauses like "no production use."

- **OSD #9 (License must not restrict other software):** OSI reads SSPL's "all software bundled with this must also be SSPL" as discrimination against other software.

In 2019 OSI formally stated SSPL did not meet the OSD. MongoDB had applied for SSPL approval and withdrew the application. Since then, BSL, ELv2, RSALv2, and FSL have all failed OSI approval for similar reasons.

**The "source-available" term.** Licenses that fail OSI approval increasingly call themselves "source-available." The code is published (you can read it and fork it) but you cannot use it for certain purposes.

The problem is the average developer does not know the distinction. They see a "BSL" or "FSL" label on a GitHub page, assume "open source, can use freely," and ship it to production. A year later legal says "this is BSL and your production use violates the license," and the company picks one of two things — (a) buy a license, or (b) migrate to a different OSS.

**"Stop redefining open source."** The counterargument from the non-OSI camp is that "the OSI definition was written in 1998 and does not reflect the reality of cloud managed services." HashiCorp's Armon Dadgar, MongoDB's Eliot Horowitz, and Sentry's David Cramer have all made variants of this argument. "We made the code, we have the right to decide how to license it."

**OSI's position.** OSI consistently replies that "of course a company can license its code however it wants. But please reserve the term 'open source' for licenses that meet the OSD." In 2025 OSI executive director Stefano Maffulli said, "Calling BSL open source is like calling a veggie burger beef."

The debate has not ended. As of 2026 the OSI definition is unchanged, but "what do we call source-available?" has become a new label war. New labels arrive every year — Fair Source, Sustainable Source, Functional Source.

3. Elastic 2021 (SSPL+ELv2) into OpenSearch (AWS), then back to AGPL (Aug 2024)

Elastic's license journey is the most symbolic case of the BSL wave. When Shay Banon created Elasticsearch in 2010, it was Apache 2.0. AWS launched Amazon Elasticsearch Service in 2015, kicking off a seven-year tension.

**2018 to 2020: the first collision.** Elastic open-sourced some "X-Pack" code (security and monitoring) in 2018 but under the proprietary Elastic License. AWS announced a clone called Open Distro for Elasticsearch in 2019. Both sides called the other "fork hostile."

**January 2021: SSPL+ELv2 relicense.** Elastic announced that Elasticsearch and Kibana would move from Apache 2.0 to a dual license — SSPL or Elastic License v2. Users had to choose one. Neither was OSI approved.

AWS's response was immediate. **OpenSearch fork (April 2021).** Built from Elastic 7.10 (the last Apache-licensed version), OpenSearch kept Apache 2.0. Amazon ES was renamed Amazon OpenSearch Service the same year.

**2021 to 2024: parallel universes.** The two projects evolved separately. Elasticsearch quickly integrated commercial features from Elastic. OpenSearch was developed by a consortium of AWS, Logz.io, Aiven, and others. They were functionally similar but APIs and clients diverged subtly. Migrating either way meant "small code changes, big operational changes."

**August 2024: Elastic returns to AGPL.** Shay Banon wrote on his blog "We are back open source." AGPL v3 was added as a license option for Elasticsearch and Kibana, making it a tri-license of SSPL, ELv2, and AGPL. AGPL is OSI approved, so Elastic could once again say "we are truly open source."

**Why did they come back.** Banon gave two reasons. (1) "Our relationship with AWS has improved" — Amazon OpenSearch Service has settled, and AWS no longer treats Elastic as the threat. (2) "We want the open source community's trust back" — SSPL took too much criticism.

**The 2026 landscape.** Both Elasticsearch and OpenSearch survived. AWS donated OpenSearch to the Linux Foundation in 2024, creating the OpenSearch Software Foundation. OpenSearch is no longer "AWS's project" but a real LF project. Elasticsearch makes revenue from its own SaaS (Elastic Cloud) and self-hosted licenses. Both camps look like winners.

**The lesson.** Elastic shows that "a license change is not one-way." It is the first major project to leave OSI and return. Yet during those three years, the OpenSearch fork took root, and that fork will not disappear.

4. HashiCorp 2023 BSL, IBM acquisition (2024), then OpenTofu (Terraform) and OpenBao (Vault)

HashiCorp is famous for its infrastructure OSS lineup — Terraform, Vault, Consul, Nomad, Packer, Vagrant, Boundary, Waypoint. Founded in 2014, nearly all of those tools were MPL 2.0 (Mozilla Public License) or a similar OSI-approved license.

**August 2023: relicense to BSL.** HashiCorp announced that all major products (Terraform, Vault, Consul, Nomad, Packer, Boundary, Waypoint) would move from MPL 2.0 to BSL v1.1. Change Date set to 4 years, Change License set to MPL 2.0. During the period, "may not be used in a competing product."

The reason was explicit. Spacelift, env0, and Scalr had built SaaS products that competed directly with Terraform Cloud (HashiCorp's SaaS). From HashiCorp's perspective, "competing with us using the tool we built is unfair."

**OpenTofu fork (September 2023).** A month after the BSL announcement, ecosystem companies including Spacelift, env0, Harness, Gruntwork, and Scalr announced a Terraform fork. It was first called OpenTF and quickly renamed to OpenTofu. In January 2024 it officially launched as a Linux Foundation project, keeping Apache 2.0.

OpenTofu grew quickly. 1.6 GA in 2024, 1.7 in May 2024 (added state encryption — a feature the original Terraform did not have), and v1.10-something as of 2026. It is largely compatible with the original Terraform, with growing divergence over time.

**April 2024: IBM announces HashiCorp acquisition.** IBM announced a 6.4 billion USD acquisition of HashiCorp. After EU and UK regulatory approval through late 2024, the deal closed in February 2025. HashiCorp is now a business unit under IBM Red Hat.

After the acquisition, HashiCorp's license policy stayed consistent. BSL stays, and some products integrate with IBM's other lines (Red Hat OpenShift, etc.). Some skeptics expected "IBM is here now, so they'll go back to open source," but no such move has happened as of 2026.

**OpenBao fork (April 2024).** The Vault fork came slightly after OpenTofu. Around the time of the IBM announcement, the Linux Foundation announced OpenBao. It keeps Mozilla Public License 2.0 (Vault's original license). Participants include GitLab, 1Password, and SUSE.

OpenBao has not grown as fast as OpenTofu. Vault has more complex usage patterns ("HCP Vault" managed service is well established), and the immediate value of a fork is less obvious. Still, v2.0 launched in 2025 as official GA.

**The 2026 landscape.** Terraform and OpenTofu are evolving in parallel. Small teams and OSS-friendly organizations move to OpenTofu. Enterprises and organizations inside the IBM and Red Hat ecosystem stick with Terraform and HCP. Vault and OpenBao are diverging similarly. When a company picks one, license is just one factor — context like "do we have an IBM contract, do we use 1Password" matters.

5. Redis 2024 SSPL+RSALv2 into Valkey (Linux Foundation)

Redis is the in-memory data store Salvatore Sanfilippo created in 2009. The license started as BSD 3-Clause. In the late 2010s, Redis Labs (now Redis, Inc.) formed to commercialize it. Core Redis stayed BSD, but modules (RediSearch, RedisGraph, RedisJSON, RedisTimeSeries) moved to Redis Source Available License (RSAL) in 2018.

**March 2024: core Redis relicensed to SSPL+RSALv2.** Redis announced that from Redis 7.4 it would leave BSD for dual SSPLv1 and Redis Source Available License v2 (RSALv2). The motivation was identical to others — AWS ElastiCache, Google Memorystore, and Azure Cache for Redis sell managed services on top of Redis without Redis Inc capturing direct revenue.

**Valkey fork (March 2024, same week).** Within a week of the license announcement, AWS, Google, Oracle, Ericsson, Snap, and others announced the Valkey project under the Linux Foundation. Built from Redis 7.2.4 (the last BSD version), keeping BSD 3-Clause. Madelyn Olson (originally a Redis core maintainer, at AWS) and others moved over as core maintainers.

Valkey settled quickly. v7.2.5 in April 2024 (Redis compatible), v8.0 in September 2024 (independent features begin — improved multi-threaded I/O), v8.1 in 2025, and v9.x as of May 2026. AWS ElastiCache for Valkey officially launched (October 2024), and Google Memorystore added a Valkey option (2025).

**Redis Inc's response.** Redis rolled out Redis 7.4 and 8.0 quickly, differentiating by integrating Vector Search and JSON modules into the core. They also simplified Redis Cloud pricing. In 2025 Redis made another license adjustment — from Redis 8.0 they added AGPL v3 as another option, making it a tri-license (SSPLv1, RSALv2, AGPLv3). The same playbook as Elastic.

**The 2026 landscape.** Redis versus Valkey is one of the most active fork battles. Valkey positions as "real OSS, cloud-friendly." Redis positions as "faster new features plus enterprise." Small teams move to Valkey quickly because code compatibility is near 100%, so migration cost is low.

**Technical differences are beginning to emerge.** Valkey 8.0's multi-threaded I/O boosted single-node throughput by 2 to 3 times. Redis 8.0 added similar features but with different implementations. As of 2026 the two are diverging on "same protocol, different internals." Within one or two years more libraries and tools will likely support only one side.

6. MongoDB 2018 SSPL — the original BSL move

The starting point of all this is MongoDB. MongoDB is a document DB 10gen (now MongoDB Inc) created in 2009, initially under AGPL v3. Even before AWS announced Amazon DocumentDB in the mid-2010s, MongoDB had tensions with managed hosting providers.

**October 2018: SSPL announcement.** MongoDB announced it would leave AGPL v3 for Server Side Public License v1 (SSPL). SSPL was based on AGPL v3 but added "if you offer this as a service, the entire stack of your service (management tools, backup tools, monitoring, interface, etc.) must be released under SSPL."

The clause effectively meant "AWS, do not sell MongoDB as a managed service." There was no chance AWS was going to release its ECS, EC2, and IAM code under SSPL.

**OSI rejects SSPL (2019).** MongoDB submitted SSPL for OSI approval and withdrew. OSI stated explicitly that "SSPL violates OSD #5, #6, and #9." Since then SSPL has been classified as a "source-available license, not open source."

**Amazon DocumentDB launches (January 2019).** Three months after the SSPL announcement, AWS launched Amazon DocumentDB. MongoDB API compatible but actually built on a different engine (Aurora-based). MongoDB called it "a clone that circumvents Mongo compatibility," but using the API without using the code is not a license violation.

**Business impact for MongoDB.** Interestingly, MongoDB stock dropped right after the SSPL announcement and quickly recovered, then surged in 2020 to 2021. MongoDB Atlas (managed service) grew fast. As of 2026, MongoDB Atlas accounts for over 70 percent of MongoDB revenue and the company's market cap is in the 20 billion USD range.

**The meaning of the MongoDB case.** MongoDB proved two things. (1) **You can survive a relicense.** SSPL was not a kiss of death. (2) **But you lose community trust.** Many developers no longer accept MongoDB calling itself an "open source company." External contributor PRs on GitHub dropped sharply after SSPL.

Every subsequent BSL decision — Elastic, HashiCorp, Redis, Sentry — referenced MongoDB. The psychological-barrier-removal effect of "MongoDB did it, so we can too" was significant.

7. Sentry 2024 FSL (Functional Source License)

Sentry is an error tracking tool started in 2008. It was distributed under BSD 3-Clause for years, moved to Business Source License once in 2019, and in 2024 announced its own FSL (Functional Source License), becoming a center of the license debate again.

**Defining FSL.** Functional Source License has two key clauses.

1. **Non-compete period:** For 2 years from publication, "you may not use this code to build a Sentry competitor." Internal use, embedding, modification and use within your own company — all OK.

2. **Automatic OSS conversion:** After 2 years the code automatically converts to Apache 2.0 (or MIT, the project picks). So "any version that is 2 years old or more" is genuinely open source.

**Why create FSL.** Sentry CEO David Cramer wrote on the blog, "BSL is too vague and SSPL is too strong. What we want is simple — prevent competitors from competing with us using our code, but release it after 2 years."

FSL differs from BSL in two ways. (a) **Shorter non-compete period** — BSL is 4 years, FSL is 2. (b) **Production use is OK from day one** — BSL restricts production use itself, but FSL only restricts "use as a competing product."

**The Fair Source movement.** Sentry positions FSL as part of a larger movement called "Fair Source." They created fair.io and maintain a list of companies that adopted FSL. As of 2025, roughly 30 companies adopted FSL — PowerSync, GitButler, Keygen, Bytebase, and others.

**OSI's position.** OSI also viewed FSL as not meeting the OSD (the same discrimination clauses). So FSL is in the "source-available license" category. That said, OSI did speak positively about the "automatic OSS conversion after 2 years" mechanism itself.

**As of 2026.** Sentry is actively promoting FSL. Using fair.io's manual and template licenses, more new OSS projects start under FSL from day one. That said, large infrastructure OSS (databases, message queues) still prefer BSL or SSPL — the "automatic conversion after 2 years" is a burden from the company's perspective.

**Assessment.** FSL can be viewed as "a softer BSL" or "a time-delayed Apache license." A reasonable middle ground for small OSS companies, but slower to adopt in large infrastructure.

8. Cockroach Labs 2024 relicense

CockroachDB is a distributed SQL database started in 2015 by Cockroach Labs. Initially Apache 2.0, it moved to BSL 1.1 in 2019 (Change Date 3 years, Change License Apache 2.0). Core was BSL, enterprise features were separate commercial license.

**August 2024: CockroachDB Community License (CCL).** Cockroach Labs announced that from CockroachDB v24.3 the project would leave BSL for its own "CockroachDB Community License" (CCL). The core changes are two.

1. **Free-use limits shrank.** Free only for "non-production" or "companies with annual revenue under 10 million USD." Above that requires a commercial license.

2. **All features in one license.** Before there was "OSS core plus enterprise." Now one package contains everything and license depends on context of use.

**Community reaction.** Cockroach Labs's change drew sharper reactions than other BSL moves. There was a criticism that "this is effectively shipping commercial software as a free trial." Small startups suddenly need to buy an expensive license the moment they cross a limit.

**Did a fork happen.** Interestingly, a large CockroachDB fork did not happen. Two reasons. (1) **Distributed SQL has too high operational complexity.** A Redis or Terraform fork can be operated by an in-house team, but maintaining a fork of a distributed system like CockroachDB needs 10+ core engineers. (2) **Alternatives already exist.** YugabyteDB offers similar distributed SQL under Apache 2.0, so migration is an option without a fork.

**As of 2026.** CockroachDB focuses on commercial revenue and pushes toward large enterprise customers. Small teams move to alternatives like Postgres + Citus, YugabyteDB, or TiDB. Cockroach Labs is a "fork-immune" case of relicensing, but at the same time a "community contraction" case.

9. n8n Sustainable Use License — another branch of the Fair Source movement

n8n is a workflow automation tool started in Germany in 2019. It positioned as the self-hosted alternative to Zapier and Make. The license is interesting because it has been "non-OSI" by design from the start.

**Core of the Sustainable Use License.** The n8n license permits:

- **Internal use:** Free for internal workflow automation in a company.

- **Embedding:** Embed n8n inside your own product — but "reselling n8n as a hosted service" is forbidden.

- **Modification and contribution:** Code modifications and PRs welcome.

The one thing forbidden is **"do not sell n8n as a managed SaaS."** That competes with n8n Cloud, which n8n Inc operates directly.

**Why SUL.** n8n CEO Jan Oberhauser explained, "If we go MIT or Apache, Zapier will take our code and embed it inside Zapier. If we go AGPL, the same can happen, but the source-disclosure obligation gives us some protection — yet from the user's perspective it's too strong. We needed something in the middle."

**Member of the Fair Source movement.** n8n participates in Sentry's fair.io movement. SUL differs from FSL but the spirit is similar — "a license that lets us control how we monetize the tool we built, but gives users as much freedom as possible."

**As of 2026.** n8n is growing fast. They raised a Series B (about 70 million USD, Highland Europe and others) in 2025, and they are competing with Zapier and Make in the AI workflow automation space. SUL has some criticism for "not being open source," but n8n's self-hosted user base keeps growing.

**Other Fair Source cases.** PowerSync (DB sync), GitButler (Git GUI), Keygen (license management), Bytebase (DB DevOps) — all fair.io members adopting SUL or FSL. Small OSS companies starting with commercial-friendly source-available from day one is a strong trend.

10. The AWS "strip-mining" narrative — how much is true

The most common word to describe the last eight years of the BSL wave is "strip-mining." The image is "AWS strip-mines the value of OSS like a quarry and sells it as its own managed service." MongoDB, Elastic, HashiCorp, and Redis all used this narrative — explicitly or implicitly — to justify their relicensing.

**How true is it.** Partly true, but also simplified.

**The true parts:**

- AWS has repeated the pattern of taking OSS and selling it as managed. Amazon ES (2015), MongoDB API clone DocumentDB (2019), MemoryDB (Redis compatible, 2021).

- AWS's OSS managed service revenue is in the tens of billions USD. Compared directly to the makers of the OSS, the gap is large.

- The rate at which AWS contributed code to OSS projects was historically very low. The criticism "they only take, never give" had merit.

**The simplified parts:**

- The simple model "AWS stole the OSS company's direct revenue" is inaccurate. AWS managed services also build OSS awareness. Elasticsearch's worldwide user base exploded thanks to Amazon Elasticsearch Service.

- After 2020, AWS OSS contributions increased. Valkey, OpenSearch, OpenTelemetry, Karpenter, Bottlerocket, Firecracker — all are AWS-created or AWS-led OSS.

- The story "AWS takes our revenue" is often a substitute explanation for "we cannot do enterprise sales so our revenue stalled." AWS takes enterprise customers via managed services, but companies that do not use managed are more likely to buy the OSS company's enterprise license.

**Cloud-three comparison.**

| Cloud | OSS managed strategy | OSS contribution |

| --- | --- | --- |

| AWS | "Take OSS and managed it" — Elasticsearch, MongoDB API, Redis, Postgres | Leads OpenSearch, Valkey, Karpenter, Firecracker. Active since 2020. |

| Google Cloud | "OSS managed + major contributor" — BigQuery, Spanner, Anthos, Knative | Leads TensorFlow, Kubernetes, gRPC, Istio, Go. The most active. |

| Microsoft Azure | "OSS managed + owns GitHub" — Azure DB for PostgreSQL/MySQL, Azure Cache for Redis | Open-sourced VSCode, TypeScript, .NET. Runs GitHub itself. |

GCP is generally rated as the strongest OSS contributor, and AWS has caught up fast since 2020. The simple picture of "AWS only strip-mines" is no longer accurate by 2026 standards.

**What remains true.** Most managed service revenue still goes to the cloud big three. OSS makers monetize with "Open Core" but it has limits. That gap is the underlying engine of the BSL wave.

11. The future of the OSI definition — how it evolves

The OSI Definition (OSD) has barely changed since 1998. As of 2026, pressure to change it comes from several directions.

**Pressure direction 1: recognize source-available.** "OSI should recognize licenses like BSL and FSL in some form." The reasoning is "we must adapt to reality (the cloud managed threat)." But OSI consistently replies, "the definition of open source is about not restricting freedom to use."

**Pressure direction 2: OSAID (Open Source AI Definition).** In 2024 OSI released "Open Source AI Definition" v1.0 for AI models. It defines disclosure criteria not only for code but also for training data, weights, and process. Meta's Llama releases weights but not training data, so it does not meet OSAID — OSI explicitly stated Meta is "open weights" but not "open source."

The decision created a big debate. Meta's stance is "you can effectively call it open." OSI's stance is "don't use 'open source' loosely." As of 2026 OSAID v1.0 has settled, but "what do we call Meta's Llama" is still unclear.

**Pressure direction 3: extension beyond software.** Collaboration with Creative Commons and Open Data. OSI is expanding influence into non-software domains (data, models, content).

**Changes within OSI itself.** OSI underwent significant leadership and governance changes from 2023 to 2025. Stefano Maffulli was named executive director, and the board was reformed for more transparent policy decisions. Funding sources diversified (GitHub, Bloomberg, Sloan Foundation, and others).

**The criticism that "the OSI definition is broken."** Some say "the OSI definition no longer fits the cloud era." But if the definition changes, it weakens, and "open source" itself becomes ambiguous. So OSI chose to defend the definition and creates new categories (like OSAID for AI) to respond to the era's changes.

**The 2026 balance.** The OSI definition survived as-is. BSL, SSPL, and FSL settled into the source-available category. The two camps coexist like parallel universes. When a new OSS project starts, "MIT/Apache or BSL/FSL?" is now a standard fork in the road.

12. Where Korean and Japanese companies stand — Kakao, Naver, NTT, Rakuten

Korean and Japanese companies' reactions to the BSL wave differ from US companies'.

**Korea: Kakao's fork-friendly policy.** Kakao has an explicit policy of "preferring forkable licenses for OSS usage." Kakao Enterprise, KakaoBank, and Kakao Pay all share a guideline: "avoid BSL/SSPL when picking new infrastructure if possible, prefer the forked OSI-licensed version if one exists."

In practice, Kakao quickly moved review to Valkey after Redis relicensed, and from 2025 several services migrated to Valkey. OpenTofu is used for internal Kakao Cloud infrastructure automation, and Elasticsearch runs in parallel with OpenSearch.

**Korea: Naver D2's balanced stance.** Naver participates in OSS through its D2 (developer community brand). The stance toward BSL is pragmatic: "we prefer OSI licenses long term, but BSL can be used short term based on business need."

Naver Cloud offers managed Elasticsearch and managed OpenSearch in parallel. Users choose. Internal systems like Naver Pay and Naver Search regularly review the most used tools alongside license impact.

**Japan: NTT's conservative stance.** The NTT group (NTT Communications, NTT Data, etc.) is very conservative on OSS licenses. Legal review for BSL or SSPL in production runs long, and they prefer to explicitly purchase OSI-approved or commercial licenses when possible.

NTT Data continues to use Terraform Enterprise on a formal license even after the HashiCorp acquisition. They use Elastic on an Elastic Cloud enterprise contract. Japanese enterprise "legal risk avoidance" culture strongly influences OSS license choice.

**Japan: Rakuten's multi-cloud stance.** Rakuten operates its own cloud (Rakuten Cloud) in parallel with AWS. Their stance on OSS licenses is comparatively open — they prefer OSI licenses but will adopt BSL when business needs require. Rakuten Mobile leans deeply on OSI-licensed infrastructure like OpenStack and Kubernetes.

**Korea and Japan common patterns.** (1) Higher preference for managed services. They tend to push license complexity onto the cloud provider rather than absorbing it. (2) Long legal review cycles mean responses to license changes are slower than in the US. (3) Trust in the forked OSI-licensed versions (OpenSearch, Valkey, OpenTofu) is rising fast.

13. If you are using an OSS whose license changed — a migration strategy

What if your company uses Elasticsearch, Terraform, Redis, or MongoDB and is worried about the license change? A four-step frame.

**Step 1: impact assessment.** Answer these questions.

- Is the version we use OSI licensed or source-available? (E.g., Elasticsearch through 7.10 is Apache, from 7.11 it is SSPL/ELv2.)

- Could our usage potentially violate the license? (E.g., are we embedding it inside our own SaaS that we charge for?)

- Are we using a managed service or self-hosting? (Managed pushes the license burden onto the cloud.)

**Step 2: identify options.** Compare these options.

| --- | --- | --- | --- |

**Step 3: pilot.** Operate one to three alternatives for one to three months in the least-impacting environment (staging, non-critical services). Measure performance, operability, and team learning curve.

**Step 4: phased rollout.** Move the option that passed the pilot starting from the lowest-usage services. Move critical services last. Migration is three stages — data move + monitoring + backup verification.

**Specific migration cases.**

- **Elasticsearch into OpenSearch.** API compatibility above 90 percent. From 7.10 or lower, nearly zero downtime possible. For 8.x, use a migration tool (OpenSearch Migration Assistant).

- **Terraform into OpenTofu.** .tf files from 1.6 or lower are mostly compatible. Need to verify provider and module compatibility. In CI/CD just swap the terraform binary for tofu.

- **Redis into Valkey.** v7.2.4 and below 100 percent compatible. Above v8.0 depends on whether new features are used. Client libraries are almost all compatible.

- **Vault into OpenBao.** A data migration tool (Vault to OpenBao migrator) exists but is not yet as stable as OpenTofu. Try with small secret backends first.

- **HashiCorp Vault Enterprise into 1Password Secrets Automation or AWS Secrets Manager.** A way to reduce license cost and operational burden at the same time.

**Examples of companies that migrated well.** GitLab is one of the largest early movers from Vault to OpenBao. 1Password partnered with OpenBao officially from the start, strengthening integration. AWS, Google, and Snap actively adopted Valkey from the announcement and moved their infrastructure.

14. If your company needs to relicense — a decision guide

The reverse scenario — your company is building an OSS and revenue is flat. How do you decide "should we relicense?"

**Five questions to answer first.**

1. **Is our revenue stall actually about licensing?** Is AWS really taking your revenue, or is your enterprise sales infrastructure weak? Is marketing weak? Without diagnosing the real cause of the revenue stall, relicensing is not the cure.

2. **What is the likelihood of a fork?** What is the operational complexity of your OSS? Redis and Terraform fork easily. CockroachDB and MongoDB are harder to fork. Kafka and Elasticsearch are in the middle.

3. **Can you absorb the loss of community trust?** Sharp drop in external PRs, slower GitHub star growth, weaker "open source company" brand — can your revenue increase offset these costs?

4. **Which license to move to?** BSL (Apache after 4 years), SSPL (strict), FSL (Apache after 2 years), Sustainable Use License (freedom plus non-compete) — each trades off differently.

5. **How will you provide a migration path?** What if existing users reject the new license? Will you keep the last OSS version in maintenance mode, or fully cut off?

**Decision matrix.**

| Situation | Recommended license |

| --- | --- |

| Small OSS, mostly self-hosted, little managed | Keep OSI license (MIT/Apache/AGPL) |

| Mid OSS, cloud managed threatens revenue | Try AGPL or FSL |

| Large OSS, clear cloud-provider threat | BSL (HashiCorp model) or SSPL (MongoDB model) |

| SaaS-first plus partial self-host offering | Sustainable Use License (n8n model) |

| AI / model domain | OSAID-compliant license or custom |

**Communication matters.** Whether a relicense succeeds or fails depends more on communication than on the relicense itself. Elastic's SSPL announcement was abrupt and drew sharp outside criticism. Redis was better — they signaled possible impact to the community in advance and pre-cleaned some module licenses (not perfect, but softer).

**Try other options before relicensing.** (a) Strengthen Open Core (separate enterprise features as commercial), (b) Launch your own managed service (Elastic Cloud, MongoDB Atlas, Redis Cloud), (c) Partner with cloud providers (like Snowflake and dbt Labs), (d) Form a consortium (CNCF, LF). Relicensing should be the last resort.

**Is the decision reversible.** Elastic returned to AGPL after three years. Redis returned partially with an AGPL option in 2025. Relicensing is not permanent, but the trust lost during a change-then-reverse cycle can be permanent.

Epilogue — The 2026 conclusion and the next seven years

As of May 2026, "what is open source?" does not have a clear answer. The OSI definition is alive, but some large OSS companies are outside it. AWS, Google, and Microsoft are the biggest consumers of OSS and increasingly the biggest contributors. Korean and Japanese companies hold a pragmatic balance in the middle.

The seven years of the BSL wave have shown three things.

1. **License is a business model.** Less a technical decision, more a business one. So when the company's revenue structure changes, the license changes too (like Elastic returning to AGPL).

2. **Forks always happen.** OSS that is not too operationally complex gets forked if the license changes. The Linux Foundation acts as the fork incubator, with cloud companies providing funding and people.

3. **Community trust is hard to buy back.** Even companies that went to SSPL/BSL and came back have a hard time fully regaining external contributor trust. So relicense decisions must be careful.

**What will happen in the next seven years.** A few guesses.

- **AI model licensing becomes a mainstream issue.** OSAID, Llama licensing, model weight disclosure — when we say "open source model," what exactly we mean becomes more important.

- **Cloud company OSS contributions grow.** As AWS, GCP, and Azure invest more in their own OSS (Karpenter, Knative, OpenTelemetry), the simple "OSS company vs cloud" framing weakens.

- **The source-available category matures.** Licenses like FSL and SUL standardize, and the share of new OSS companies starting source-available from day one rises.

- **The OSI definition survives.** But it evolves by creating new categories (OSAID, Open Data, etc.).

I hope this post helps your company on its next license decision (whether as a user or as a maker). The next chapter of open source is still being written by all of us.

References

- OSI (Open Source Initiative). The Open Source Definition. https://opensource.org/osd

- OSI. Open Source AI Definition v1.0. https://opensource.org/ai/open-source-ai-definition

- OSI. Statement on SSPL. https://opensource.org/blog/the-sspl-is-not-an-open-source-license

- Elastic. Elasticsearch is Free and Open Source — Again (AGPL v3 announcement, Aug 2024). https://www.elastic.co/blog/elasticsearch-is-open-source-again

- Elastic. Doubling Down on Open, Part II (SSPL+ELv2 announcement, 2021). https://www.elastic.co/blog/license-change-clarification

- AWS. Stepping up for a truly open source Elasticsearch (OpenSearch fork, 2021). https://aws.amazon.com/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch/

- OpenSearch Software Foundation. https://opensearch.org/

- HashiCorp. HashiCorp adopts Business Source License (Aug 2023). https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license

- OpenTofu (Linux Foundation). https://opentofu.org/

- OpenBao (Linux Foundation). https://openbao.org/

- IBM. IBM to acquire HashiCorp (Apr 2024). https://newsroom.ibm.com/2024-04-24-IBM-to-Acquire-HashiCorp-Inc-Creating-a-Comprehensive-End-to-End-Hybrid-Cloud-Platform

- Redis. Redis Adopts Dual Source-Available Licensing (Mar 2024). https://redis.io/blog/redis-adopts-dual-source-available-licensing/

- Valkey (Linux Foundation). https://valkey.io/

- MongoDB. Server Side Public License FAQ. https://www.mongodb.com/licensing/server-side-public-license/faq

- MariaDB. Business Source License v1.1. https://mariadb.com/bsl11/

- Sentry. Introducing the Functional Source License (2023). https://blog.sentry.io/introducing-the-functional-source-license-freedom-without-free-riding/

- Fair Source. https://fair.io/

- Cockroach Labs. CockroachDB Community License (Aug 2024). https://www.cockroachlabs.com/blog/enterprise-license-announcement-2024/

- n8n. Sustainable Use License. https://docs.n8n.io/sustainable-use-license/

- Confluent. Confluent Community License FAQ. https://www.confluent.io/confluent-community-license-faq/

- Heather Meeker. Business Source License explained (blog series). https://heathermeeker.com/2017/04/16/the-business-source-license/

- Linux Foundation. https://www.linuxfoundation.org/

- TechCrunch. Sentry, n8n team up on Fair Source (2024). https://techcrunch.com/2024/09/24/sentry-and-n8n-among-companies-pushing-fair-source-software-movement/

- The Register. Elastic returns to open source: it depends what you mean by "open source" (2024). https://www.theregister.com/2024/08/30/elastic_open_source/

- Kakao tech blog. https://tech.kakao.com/

- Naver D2. https://d2.naver.com/

- NTT Open Source Software Center. https://www.ntt.com/en/services/network/oss.html

- Rakuten Institute of Technology. https://rit.rakuten.com/

- CNCF (Cloud Native Computing Foundation). https://www.cncf.io/