From Redis Switching to BSL to the AGPL Revival: Source Available, AI, and the License Wars

In August 2023, HashiCorp moved Terraform, Vault, Consul, and all its core products from MPL 2.0 to BSL 1.1. The community erupted; a month later the Linux Foundation spearheaded a fork called OpenTofu. You’d think the story ends there — but in April 2024 IBM announced a $6.4 billion acquisition of HashiCorp, closing in February 2025, making HashiCorp a business unit under IBM’s Red Hat. The license-changing OSS company didn’t decline; it became an acquisition target.

The other thread is even more ironic. In 2021 Elastic moved Elasticsearch from Apache 2.0 to a dual SSPL+ELv2 license; AWS immediately forked OpenSearch in response. Three years later, in August 2024, Elastic added AGPL v3, forming an SSPL+ELv2+AGPL triple-license combo, with CEO Shay Banon publishing a post titled “We are back open source” — a full circle. In 2025 Redis 8.0 followed the same script, adding AGPL.

This post is about that group of “source-visible but not open source” licenses (Source Available): how they evolved, how they push back against OSI’s open source definition, and how cloud vendors forced them back to AGPL. We end with the US and Chinese court rulings confirming open source license enforceability, plus a selection and compliance checklist.

Define the Terms First: Open Source vs Source Available

Open Source is an OSI registered trademark. For a license to call itself “open source”, it must pass OSI’s ten-clause Open Source Definition (OSD) review. As of 2026 OSI has approved more than 100 licenses.

Source Available is not the same as open source. The code is publicly readable and forkable, but with usage restrictions — “cannot use as a managed service”, “production use requires payment”. BSL, SSPL, ELv2, RSALv2, FSL all fall in this category, and OSI has approved none of them.

The OSD clauses most often violated by Source Available licenses are three:

flowchart TD
    OSD["OSD Ten Clauses"] --> V5["Clause 5<br/>No discrimination<br/>against persons/groups"]
    OSD --> V6["Clause 6<br/>No discrimination<br/>against fields of endeavor"]
    OSD --> V9["Clause 9<br/>No restriction<br/>on other software"]

    V5 -->|"SSPL discriminates<br/>against SaaS companies"| X["Violated"]
    V6 -->|"BSL/ELv2/RSALv2/FSL<br/>restrict hosting/production"| X
    V9 -->|"SSPL requires the entire<br/>service stack be SSPL"| X

    classDef base fill:#bbdefb,stroke:#2196F3,color:#0D4741
    classDef clause fill:#fff3e0,stroke:#FF9800,color:#BF360C
    classDef bad fill:#ffcdd2,stroke:#f44336,color:#B71C1C
    class OSD base
    class V5,V6,V9 clause
    class X bad

OSI executive director Stefano Maffulli put it bluntly in 2025: “Calling BSL open source is like calling a veggie burger beef.” He did acknowledge “Delayed Open Source Publication” (DOSP) as a legitimate practice — projects can pre-commit to “automatically convert to an OSI license in a few years”, which is exactly how BSL works. This exit path is also how Elastic and Redis later “returned to open source”.

The trap developers most easily fall into is seeing a BSL or FSL label on GitHub and assuming “open source, free to use”, only to discover a year later during legal review that production deployment violates the license. The dilemma: buy a commercial license, or migrate to another project.

The Five Source Available Pillars and Two Variants

BSL 1.1: The Originator of Fill-in-the-Blank Terms

Business Source License was created by MariaDB in 2013, drafted by attorney Heather Meeker. Its core mechanism:

flowchart LR
    NOW["Today<br/>Source readable/<br/>modifiable/<br/>non-production use"] -->|"Change Date<br/>default 4 years"| FUTURE["Auto-conversion<br/>to GPL/Apache/MPL"]

    classDef now fill:#fff3e0,stroke:#FF9800,color:#BF360C
    classDef fut fill:#c8e6c9,stroke:#4CAF50,color:#1B5E20
    class NOW now
    class FUTURE fut

• Source is publicly readable, modifiable, usable in non-production environments
• A Change Date is set (default 4 years, can be shortened by the licensor)
• After expiry, auto-converts to GPL 2.0 or another compatible open source license (Apache, MPL also specifiable)
• Before expiry, commercial production use requires a commercial subscription
• Through the Additional Use Grant (a fill-in-the-blank clause), each project customizes its permitted use scope

Adopters: HashiCorp (August 2023, 4-year Change Date, conversion to MPL 2.0), CockroachDB (3-year conversion to Apache 2.0), Sentry (early use, later moved to FSL).

OSI rejected BSL for the same reason as the others: restricting production use before the change date violates Clause 6 (no discrimination against fields of endeavor).

SSPL: MongoDB’s Trap for Cloud Providers

Server Side Public License was created by MongoDB in October 2018, modified from AGPL v3. The key difference from AGPL is in Section 13:

• AGPL v3 Section 13: only requires releasing the source of “the network service directly interacting with the software”
• SSPL Section 13: extends to the entire service stack — if you offer the software as a public service, you must release the source of the entire service stack (management tools, backup, monitoring, UI, EC2/IAM and all related programs) under SSPL

This means AWS, Azure, GCP would have to open source their entire cloud stack to offer MongoDB managed services — practically impossible. That’s SSPL’s design intent: make it impossible for cloud providers to do managed services off the existing code.

MongoDB submitted SSPL for OSI approval in 2018 and withdrew the application in March 2019 after it became clear approval wasn’t happening. OSI explicitly stated SSPL violates OSD Clauses 5, 6, and 9 simultaneously. From then on SSPL was formally classified as “source-available license, not open source”. Debian, Red Hat, and Fedora subsequently removed MongoDB from their package repositories.

Adopters: MongoDB (2018), Elastic (2021 dual-license), Redis (2024).

ELv2: Elastic’s Simplified Version

Elastic License v2 was released by Elastic in February 2021, a major simplification over 1.0. The core restrictions are just two clauses:

1. Prohibition on offering the software as a managed service to third parties (cannot directly compete with Elastic Cloud)
2. Prohibition on circumventing license limitations (e.g. cannot remove license key checks)

ELv2 doesn’t enforce copyleft, so embedding it in an application doesn’t trigger contagion. It’s paired with SSPL as a dual-license — users pick one. OSI didn’t approve it, again for Clause 6 (restricting the hosting field of endeavor).

RSALv2: Redis’s Version

Redis Source Available License v2 was published on March 20, 2024. Starting from Redis 7.4, core Redis moved from BSD 3-Clause to RSALv2 + SSPLv1 dual-license.

RSALv2 is a permissive non-copyleft source-available license: allows use, copying, distribution, modification, embedding into applications; prohibits offering the software as a managed service to third parties (similar to ELv2); no copyleft enforcement, so embedding doesn’t trigger contagion.

FSL: Sentry’s Standardized Template

Functional Source License was introduced by Sentry in November 2023, co-designed by Sentry CEO David Cramer and Heather Meeker (yes, the same attorney who drafted BSL). FSL aims to solve BSL’s “each project is effectively a different license” problem by providing a standardized template.

FSL core mechanism: defines “Permitted Purpose” — all purposes other than “Competing Use”; defines “Competing Use” — used in a commercial product or service competing with the licensor’s software. Each version auto-converts to Apache 2.0 or MIT after 2 years.

Adopters: Sentry, Codecov, parts of HashiCorp Boundary, Liquibase. FSL positions itself as a “Fair Source” license and no longer claims to be open source. But OSI has still not approved it.

Two Variants: PolyForm and Hippocratic

• PolyForm family (2019, led by Heather Meeker): a collection of source-available license templates written in plain English — Noncommercial, Small Business, Strict, Perimeter, Trial, Internal Use, etc., covering different use cases. None OSI-approved.
• Hippocratic License (2019, Coraline Ada Ehmke): adds an ethics clause on top of MIT — prohibits using the software for activities that violate the UN Universal Declaration of Human Rights. Version 3.0 (HL3, 2021) is modular: the core clause protects human rights, optional modules cover environmental justice, labor rights, media, military, surveillance, etc. The legal community is generally skeptical of enforceability; critics like Bruce Perens argue these clauses go far beyond what copyright licenses can enforce. OSI did not approve it.

There’s also an old relic — JSON License, written by Douglas Crockford in 2002, essentially MIT plus one line: “The Software shall be used for Good, not Evil.” That single line violates OSD Clause 6, and both FSF and OSI refused to recognize it as free/open source. The Apache Foundation once allowed JSON License code into projects but later tightened policy over ambiguity; companies like IBM internally banned use of the JSON.org parser because legal worried about the vagueness of “Evil”.

The Eight-Year License War: Full Timeline

Lining up the key events from 2018 to 2026 reveals the industry’s evolution logic:

timeline
    title 2018-2026 Open Source / Source Available License Wars
    2018.10 : MongoDB : AGPL v3 → SSPL v1
             : First anti-CSP license
    2019.01 : AWS : Launches DocumentDB
             : Clean impl bypasses AGPL
    2019.03 : MongoDB : Withdraws OSI application
    2021.01 : Elastic : Apache → SSPL + ELv2
    2021.04 : AWS : Forks OpenSearch
    2023.08 : HashiCorp : MPL → BSL 1.1
    2023.09 : OpenTofu : LF forks Terraform
    2023.11 : Sentry : BSL → FSL
    2024.03 : Redis : BSD → RSALv2 + SSPL
             : LF forks Valkey
    2024.04 : IBM : $6.4B acquires HashiCorp
    2024.08 : Elastic : Adds AGPL (triple-license)
    2024.10 : OSI OSAID v1.0 released
    2025    : Redis 8.0 adds AGPL (triple-license)

Behind the timeline are three recurring patterns: cloud vendors freeloading on open source projects, projects switching to Source Available to fight back, Linux Foundation forking replacements. The four cases below run the full playbook.

Case 1: Facebook React BSD+Patents (2016-2017)

React had a PATENTS file alongside its BSD license containing a “patent retaliation clause”: if you sue Facebook for patent infringement, you immediately lose your patent grant to use React.

The risk was one-sided — all the risk was loaded onto licensees, with Facebook taking no symmetric obligation. The Apache Foundation’s legal committee in July 2017 classified Facebook BSD+Patents as Category X (banned), prohibiting Apache projects from depending on it directly. Affected projects included RocksDB and Bahir. Around the same time, Automattic’s Matt Mullenweg announced WordPress would stop rewriting its UI on React, saying “we can’t build our entire product on code where Facebook can unilaterally revoke the patent grant”.

In September 2017, Facebook moved React, Jest, Flow, and Immutable.js to the MIT license. This is the landmark case of the open source community winning via collective pressure.

Case 2: Elasticsearch Dual-License → AWS Fork → Return to AGPL

Elasticsearch was Apache 2.0 from 2010. In 2015 AWS launched Amazon Elasticsearch Service, directly based on Elastic’s open source code for managed services, with revenue almost entirely flowing to AWS. Both sides accused the other of “anti-fork”. Elastic moved X-Pack security/monitoring code to proprietary Elastic License in 2018; AWS launched Open Distro for Elasticsearch in 2019 in response.

In January 2021, Elastic announced Elasticsearch and Kibana were moving from Apache 2.0 to SSPL v1 + ELv2 dual-license, with users picking one. The blog post title was the sarcastic “Doubling Down on Open”. The OSI board subsequently issued the statement “The SSPL is Not an Open Source License”.

In April 2021, AWS forked OpenSearch based on Elastic 7.10 (the last Apache version), retaining Apache 2.0, and renamed Amazon Elasticsearch Service to Amazon OpenSearch Service. Logz.io, Aiven, and others joined the OpenSearch camp.

In August 2024, Shay Banon published “We are back open source”, adding AGPL v3 as a third license option (SSPL + ELv2 + AGPL). His stated reasons: (1) the relationship with AWS had improved; (2) he wanted to win back the open source community’s trust. Around the same time AWS donated OpenSearch to the Linux Foundation as the OpenSearch Software Foundation. This is the industry’s first case of “switching the license and then coming back”.

Case 3: MongoDB AGPL → SSPL (2018)

MongoDB had been on AGPL v3 since 2009, originally to close the SaaS loophole. But AWS took a third path: writing a clean reimplementation — Amazon DocumentDB (launched 2019), which only implements the MongoDB API without using its source code, thus routing around AGPL’s copyleft.

MongoDB then invented SSPL, extending contagion to the entire service stack. But this move didn’t stop DocumentDB either — it didn’t use MongoDB source code at all. The result was a double loss: MongoDB didn’t stop the cloud vendor, but got removed from Debian, Red Hat, and Fedora repositories, and community contribution traffic dropped. In March 2019, MongoDB withdrew its OSI approval application once it became clear it couldn’t pass.

Commercially MongoDB didn’t lose much; its stock briefly dipped then recovered. SSPL instead became the “license template” for Elasticsearch and Redis later.

Case 4: HashiCorp MPL → BSL (2023)

On August 10, 2023, HashiCorp moved all its core products — Terraform, Vault, Consul, Nomad, Packer, Boundary, Waypoint, Vagrant — from MPL 2.0 to BSL 1.1. Co-founder Armon Dadgar publicly named Spacelift, env0, and Scalr as building SaaS products directly on Terraform to compete with Terraform Cloud: “it’s not fair to compete with us using the tool we built”. The core BSL 1.1 restriction is no competitive use within the Change Date (4 years), after which it auto-converts to MPL 2.0.

A month later, in September 2023, Spacelift, env0, Harness, Gruntwork, Scalr and others announced a fork called OpenTF (later renamed OpenTofu), formally becoming a Linux Foundation project in January 2024, retaining Apache 2.0. OpenTofu 1.7 (May 2024) added state encryption and other features the original Terraform didn’t have.

Vault’s fork followed — in April 2024 the Linux Foundation launched OpenBao, retaining MPL 2.0, with participants including GitLab, 1Password, and SUSE.

In April 2024 IBM announced the $6.4 billion acquisition of HashiCorp, closing in February 2025. The license policy remained unchanged after the acquisition. OpenTofu has become one of the de facto standards for open source IaC.

Case 5: Redis BSD → RSALv2+SSPL (2024)

On March 20, 2024, Redis announced that starting with Redis 7.4 it would move from BSD 3-Clause to RSALv2 + SSPLv1 dual-license. The reason was the same as the others: AWS ElastiCache, Google Cloud Memorystore, and Azure Cache for Redis had been providing managed services based on Redis for years with almost no upstream contributions and no payment.

On April 1, 2024, the Linux Foundation announced Valkey, forked from Redis 7.2.4 (the last BSD version), retaining BSD 3-Clause. Backers included AWS, Google Cloud, Oracle, Ericsson, and Snap. Original Redis core maintainer Madelyn Olson (employed at AWS) and others moved to Valkey. Valkey 8.0 (September 2024) introduced multi-threaded I/O improvements, raising single-node throughput 2-3x and starting to diverge from Redis at the kernel level.

AWS ElastiCache for Valkey went live in October 2024; Google Memorystore added a Valkey option in 2025; Oracle followed suit. All three major cloud vendors collectively replaced the original with the fork.

In 2025, Redis 8.0 added AGPL v3 as a third license option (RSALv2 + SSPLv1 + AGPLv3), following Elastic’s “return to AGPL” path.

A Few Patterns

Running through the five cases, several near-inevitable patterns emerge:

• Source Available licenses almost always trigger a fork. The Linux Foundation has effectively become a “fork incubator” — OpenSearch, OpenTofu, OpenBao, Valkey all came out of it.
• AGPL has been rediscovered as the “OSI-compliant but anti-cloud-vendor” option. Over the past two years both Elastic and Redis have taken this route: the Source Available + AGPL triple-license combo. AGPL forces cloud vendors to either open their own code or not host it. This is one of the two paths that emerged in 2024-2025; whether it becomes an industry standard remains to be seen.
• AGPL’s “network clause” is ineffective against clean-room API-compatible implementations. MongoDB’s case proved it: cloud vendors can write a clean compatible implementation to route around copyleft. “Source copyleft” cannot replace a “business model moat”.

Licenses in the AI Era: Three Layers of Legal Nature

AI models are more complex than software — a single model contains three layers with completely different legal natures: weights, code, and training data. Traditional software licenses don’t perfectly cover any of them.

flowchart TD
    M["AI Model"] --> W["Weight Files<br/>data-like artifacts"]
    M --> C["Training/Inference Code<br/>traditional software"]
    M --> D["Training Data<br/>copyright + database rights"]

    W --> W1["LLaMA / Gemma<br/>custom licenses"]
    W --> W2["Falcon / Mistral<br/>Apache 2.0"]
    W --> W3["Stable Diffusion<br/>OpenRAIL-M"]
    C --> C1["Usually Apache 2.0<br/>or MIT"]
    D --> D1["Most contentious<br/>Copyright Office 2025"]

    classDef base fill:#bbdefb,stroke:#2196F3,color:#0D4741
    classDef layer fill:#fff3e0,stroke:#FF9800,color:#BF360C
    classDef leaf fill:#c8e6c9,stroke:#4CAF50,color:#1B5E20
    class M base
    class W,C,D layer
    class W1,W2,W3,C1,D1 leaf

Three Schools of Large Model Licensing

Custom commercial licenses with restrictions — Meta’s LLaMA is representative. LLaMA 2 (July 2023) allows commercial use, but companies with more than 700 million monthly active users must apply to Meta for a separate paid license; LLaMA 4 (2025) keeps the 700M MAU threshold, prohibits EU users from using or distributing Llama 4 models; requires derivative model names to start with “Llama”; requires displaying a “Built with Llama” badge. Google’s Gemma is similar, prohibiting specific harmful-use classifications and requiring derivatives to inherit the same terms.

Pure Apache 2.0 (truly permissive open source) — a minority. Falcon 40B / 180B (TII) is one of the few early large LLMs using pure Apache 2.0; Mistral 7B v0.1 (September 2023) is considered the first commercially important model that is “open source by almost any standard beyond the OSI 2024 AI Definition”; Mixtral 8x7B (December 2023) is also Apache 2.0. But Codestral uses a non-production license, and Mistral Large/Small via API are proprietary commercial — different models within the same company can have completely different licenses.

OpenRAIL family (use-restricted, copyleft-like) — designed by the RAIL Initiative (licenses.ai). RAIL-A (applications), RAIL-M (models), RAIL-S (source code); derivatives include BigScience BLOOM RAIL 1.0, CreativeML OpenRAIL-M (Stable Diffusion), CodeML OpenRAIL-M (BigCode), and others. OpenRAIL’s key feature: usage restrictions are inherited by all derivative works; OpenRAIL itself states it is not an OSI open source license (violates OSD Clause 6). As of April 2023, OpenRAIL had become the second-largest license family after permissive open source.

OSAID and Unresolved Disputes

In October 2024, OSI officially released OSAID v1.0 (Open Source AI Definition). It requires models to provide access to training data information, model architecture, and training code. Under this definition, “open” models like Llama, Gemma, and Qwen mostly don’t qualify as OSAID-compliant — either because they don’t disclose training data or because they restrict commercial use. OSAID itself is still contested within the industry; some researchers consider the bar too high, some vendors consider it too strict.

Several unresolved issues:

• Training data copyright: The US Copyright Office’s 2025 report makes clear that AI training involves the right of reproduction. Multiple rights holders are suing AI companies; the case law direction is still unsettled.
• EU TDM exception: The EU Text and Data Mining exception may override Share-Alike clauses, but with significant interpretive room.
• Open washing: Models self-labeling “open” but carrying significant restrictions, triggering pushback.

Yale’s CCAI Proposal (2026)

On June 15, 2026, Yale researcher Grant Shanklin published a paper in the Oxford International Journal of Law and IT proposing Contextual Copyleft AI License (CCAI). The core mechanism: treat generative AI models as derivative works of their training data, requiring AI developers who train models on open source code to disclose their model architecture and training data. This is an academic proposal extending traditional copyleft thinking to the AI era; it’s not currently a legal or industry standard. Whether it gets adopted and can be enforced depends on subsequent legislation and case law.

Are Open Source Licenses Really Enforceable in Court?

Many people have a misconception about open source licenses: thinking they’re community conventions without legal force. In fact, courts in both the US and China have explicitly ruled that open source licenses are enforceable under copyright law.

US: Jacobsen v. Katzer (2008-2010)

The first US federal appeals case explicitly recognizing the enforceability of open source licenses. Robert Jacobsen was the author of JMRI, open source model train control software, licensed under the Artistic License. Matthew Katzer / KAMIND Associates didn’t comply with the Artistic License terms (no attribution, no modification marks, no source disclosure) and incorporated the code into commercial products.

The district court initially held that the Artistic License was a “covenant” (contract promise) rather than a “condition”, so violation could only constitute breach of contract. The Federal Circuit (CAFC) reversed in 2008, ruling explicitly that open source license conditions are conditions of the copyright license, and violation constitutes copyright infringement, not just breach of contract. The court reasoned that open source licenses exchange copyright use authorization through “open distribution + conditional obligations”, making them essentially copyright licenses.

Significance: Debunked the notion that “open source licenses can’t be enforced in court” and established the legal foundation for all subsequent open source license litigation.

US: Artifex v. Hancom (2016-2017)

Artifex Software owns the copyright to Ghostscript (GPL v3). Korean company Hancom integrated Ghostscript into its commercial Hancom Office software, neither open sourcing its own code nor buying a commercial license. Artifex sued, claiming both copyright infringement and breach of contract under GPL.

Hancom argued GPL was only a copyright license, so violation could at most cause license termination, not contract breach liability. Judge Jacqueline Scott Corley denied the motion to dismiss, ruling that users accepting GPL terms upon download makes GPL contractual in nature; GPL’s “source disclosure obligation” constitutes an “extra element” beyond copyright law, so breach of contract claims can stand.

Significance: The first explicit court ruling that GPL is both a copyright license and an enforceable contract. Every distribution of a product using Ghostscript must provide or offer to provide source code; this obligation persists even after license termination. The parties reached a settlement in December 2017, with specific terms confidential.

US: Oracle v. Google Java API Case (2010-2021)

The dispute: whether APIs are copyrightable; whether Google’s copying of 37 Java SE API declaring codes for Android constituted fair use.

Eleven years of litigation with multiple reversals: 2012 district court ruled APIs aren’t copyrightable; 2014 CAFC reversed, holding APIs can be copyrightable, and remanded for fair use retrial; 2016 jury found Google’s use fair; 2018 CAFC reversed again, finding infringement; on April 5, 2021, the US Supreme Court ruled 6-2 for Google, finding that copying 11,500 lines of declaring code (only 0.4% of the Java SE platform) constituted fair use and transformative use.

Significance: Established the precedent that API copying can constitute fair use, while also implying APIs themselves can be copyrightable — leaving long-term uncertainty for clean-room implementations and compatibility development.

China: Digital Paradise “Luobox” Case and GPL Enforceability

Chinese courts have also produced landmark rulings on open source license enforceability. The Digital Paradise case (“Luobox case”) is China’s first GPL “unclean hands” defense case: the court explicitly held that the GPL agreement constitutes a legal relationship of a contractual nature, and violation can cause license termination and constitute infringement of the upstream party; it applied the “separate program doctrine” to determine what counts as a derivative work.

In 2018, the Beijing Intellectual Property Court, as the court of first instance, had a defendant invoke GPL-3.0’s copyleft mechanism as a defense in a software copyright infringement case. The court didn’t directly interpret GPL clauses but implied GPL is enforceable in China.

The Key Dispute Over GPL Contagion Boundaries

The most common practical question: does dynamically linking GPL code count as a “derivative work”?

The FSF’s official position is aggressive — statically linking GPL code = derivative work, the whole must be GPL; dynamically linking GPL code also constitutes a derivative work, the whole must be GPL; only independent programs communicating via pipes, sockets, or command lines count as an “aggregate”, not contagious.

But the legal definition of “derivative work” is unclear, and the FSF’s expansive interpretation may not be fully adopted by courts. The Linux kernel has a syscalls exception (explicitly allowing non-GPL programs to use the kernel via system calls); LGPL is designed to allow dynamic linking without contagion. Practical advice: to stay closed, either use LGPL, go through IPC, or clean-room reimplement. Trying to bypass GPL via “dynamic linking” is significant legal risk.

An Enterprise Selection and Compliance Checklist

Mandatory Checks Before Adopting a New Dependency

Step 1: Identify the license type

• Check the LICENSE file
• Check package.json / pom.xml / Cargo.toml and other metadata
• Check all dependency licenses (including transitive dependencies)
• Distinguish OSI open source / Source Available / proprietary — when you see BSL/SSPL/ELv2/RSALv2/FSL, be alert immediately

Step 2: Assess compliance obligations

• Permissive (MIT/BSD/Apache): retain copyright notice; Apache additionally requires NOTICE and change statements
• Weak copyleft (MPL/LGPL/EPL): modified parts must be open, new parts can be closed
• Strong copyleft (GPL): the entire derivative work must be GPL; beware dynamic linking traps
• Strongest copyleft (AGPL): SaaS deployment also triggers open source obligations
• Source Available (BSL/SSPL/ELv2/RSALv2/FSL): assess “competitive use” clauses and Change Date

Step 3: Identify patent risk

• Does it trigger patent retaliation clauses (Apache/MPL/GPL v3/EPL/CDDL)
• Do you need to purchase a commercial patent license
• Do you need to report to company legal

Step 4: Build an SBOM (Software Bill of Materials)

• Use SPDX / CycloneDX standards to record all dependency licenses
• Automatically scan for license changes before each release
• Deploy scanning tools like FOSSA / Snyk License / Black Duck

Common Pitfalls Reference Table

Compliance Trends That Have Already Happened

A few facts that aren’t predictions but already occurred, that engineering teams need to track:

• The EU Cyber Resilience Act already mandates SBOM. This means software products sold in the European market must provide an SBOM as a legal obligation, not an option.
• The triple-license combo (Source Available + AGPL) has become a new practice in the past two years. Both Elastic and Redis did this; more companies will likely follow.
• OSI is promoting OSAID; the OpenRAIL family continues to expand. The boundary between AI model licenses and traditional open source licenses will become clearer.
• Enterprise compliance automation: tools like FOSSA and Snyk License are becoming standard in CI/CD pipelines.

References

Official authoritative sources:

• SPDX License List v3.28.0: https://spdx.org/licenses/
• OSI Approved Licenses: https://opensource.org/licenses/alphabetical
• OSI OSAID v1.0 (2024-10): https://opensource.org/ai

Source Available licenses:

• MariaDB BSL 1.1: https://mariadb.com/bsl11/
• MongoDB SSPL FAQ: https://www.mongodb.com/legal/licensing/server-side-public-license/faq
• Elastic License v2: https://www.elastic.co/es/blog/elastic-license-v2
• Sentry FSL: https://blog.sentry.io/introducing-the-functional-source-license-freedom-without-free-riding/
• FSL official: https://fsl.software/
• Fair Source definition: https://fair.io/about/
• PolyForm Project: https://polyformproject.org/why-adopt-polyform

Historical case documents:

• Apache bans Facebook BSD+Patents — LWN.net: https://lwn.net/Articles/728293/
• The SSPL is Not an Open Source License — OSI Blog: https://opensource.org/blog/the-sspl-is-not-an-open-source-license
• Amazon Forks Elasticsearch as OpenSearch — InfoQ: https://www.infoq.com/news/2021/04/amazon-opensearch/
• HashiCorp Licensing FAQ: https://www.hashicorp.com/license-faq
• Redis Adopts Dual Source-Available Licensing: https://redis.io/blog/redis-adopts-dual-source-available-licensing.md

Case law and AI licenses:

• Artifex v. Hancom — FSF: https://www.fsf.org/blogs/licensing/update-on-artifex-v-hancom-gnu-gpl-compliance-case-1
• JACOBSEN v. KATZER ruling: https://lawcat.berkeley.edu/record/1122274/files/fulltext.pdf
• Google v. Oracle fair use summary: https://www.copyright.gov/fair-use/summaries/Google-LLC-v-Oracle-Am-Inc-141-S-Ct-1183-2021.pdf
• RAIL Initiative FAQ: https://www.licenses.ai/faq-2
• Shanklin, “The Case for Contextual Copyleft,” Oxford IJLIT (2026): https://academic.oup.com/ijlit/article-abstract/doi/10.1093/ijlit/eaag003/8460592

The previous post, Mainstream Open Source Licenses: From MIT to AGPL, How Engineers Choose, covers the copyleft boundaries and selection logic of the 14 OSI-approved licenses. This post completes the picture with Source Available and AI. Together they form a base map for engineering teams dealing with open source license issues.