The Legal Risks of "Source-Available" Licenses: SSPL, BSL, and Beyond

Source-available licenses allow developers to read and modify a software's source code, but they also impose restrictions on how the software can be used, which disqualify them as true open-source licenses.

Companies typically adopt source-available license models to stop cloud providers from reselling their work without contributing back meaningfully. And while this solves a commercial problem, it also creates compliance risks for anyone deploying the software.

Below, we break down the legal implications of source-available licenses, why the Open Source Initiative (OSI) doesn't approve them, and what businesses should understand before making the switch.

How Do Source-Available Licenses Create Legal Uncertainty?

Source-available licenses let you download, view, and often modify a software project's codebase. Popular examples include MongoDB's Server Side Public License (SSPL) and the Business Source License (BSL) first introduced by MariaDB.

Source-available licenses create legal uncertainty because they combine open access to source code with non-standard commercial restrictions that are interpreted differently across jurisdictions.

On the surface, these licenses feel similar to open-source models because the code is out in the open and developers can usually build and distribute their own versions without approvals or contracts.

The friction appears when you look at how the software can be used. Unlike open-source licenses (whether permissive like Apache 2.0 or copyleft like GPL), source-available licenses add what legal experts call "field-of-use" limitations, which restricts what developers can do with the software commercially.

In practical terms, a field‑of‑use limitation means the license tells you how you are allowed to use the software (for example, "you may not offer this as a hosted service" or "you may not build a competing product on top of this engine").

For businesses, this turns license review into a business‑model review: product, sales, and legal teams must confirm that current and planned offerings do not fall into a prohibited "field of use," or they risk running the product without a valid license.

For example, Section 13 of MongoDB's SSPL requires developers who offer MongoDB as a service to third parties to release their entire service infrastructure (including load balancers, APIs, management tools, and everything else) under the same license.

In this aspect, the SSPL mirrors the GNU General Public License (GPL) version 3 copyleft requirements. However, it goes a step further and requires that, if users offer the software as a service, all other components used to run that service (not just modifications or derivative work) must be made available under the SSPL.

The Business Source License (BSL) is another popular source-available license. The base BSL typically restricts production use. However, HashiCorp's BSL implementation includes an "Additional Use Grant" that permits production use as long as developers don't build products that compete with HashiCorp's commercial offerings:

"Production use" in this context usually means running the software in live customer-facing or revenue-generating systems, as opposed to internal testing or development, so BSL terms often draw the legal line exactly where the commercial stakes are highest.

Companies adopted source-available licenses to stop cloud giants like AWS and Alibaba from taking open-source projects and offering them as managed services without contributing back meaningfully to development.

And while source-available licenses have helped protect open-source revenue and sustainability, they also carry significant legal risk, especially for downstream users of the software.

Why Does the Open Source Initiative (OSI) Reject Source-Available Licenses?

The Open Source Initiative (OSI) maintains the industry-standard definition of what qualifies as open source. Their rejection of source-available licenses like SSPL and BSL is based on specific, measurable violations of the Open Source Definition's requirements.

SSPL was formally submitted to the OSI's license-review process and then withdrawn in 2019 after it became clear there was no community consensus to approve it; the OSI does not list SSPL as an approved open source license.

The OSD includes ten criteria that every open-source license must meet. Source-available licenses typically violate at least two of them.

Let's briefly take a look at some of them.

Criterion: No Discrimination Against Persons or Groups

Open source licenses can't play favorites. By designing terms specifically to block cloud providers, source-available licenses effectively discriminate against a specific group of users.

Take MongoDB's SSPL, for instance. Anyone offering MongoDB as a service would have to release their entire service stack under the same terms. This is designed to make cloud providers like AWS choose between expensive compliance or avoiding the software entirely.

HashiCorp's BSL takes a different approach but achieves the same goal. Its "Additional Use Grant" prohibits competitive use, which in practice means "you can't be a cloud provider offering this."

Criterion: No Discrimination Against Fields of Endeavor

Open source licenses can't tell you what you can't use the software for, whether for genetic research, nuclear power, or commercial profit. This is the "field-of-use" violation.

A BSL clause that explicitly bans "competing services" or an SSPL provision that restricts "offering the software as a service" essentially tells certain business models that they're not welcome.

Criterion: License Must Not Restrict Other Software

Open-source licenses can't impose requirements on other software used alongside the licensed program.

The SSPL in particular appears to violate this criterion. As mentioned, Section 13 of the SSPL says that if developers offer the software as a service, they must release the code for their entire stack, including backup tools, UIs, management layers, etc.

This is considered a much larger scope of disclosure than GPL requires. With GPL, you must open-source your modifications to the GPL software itself, not everything that interacts with it over a network.

Whether the SSPL actually violates Criterion 9 is debated. Some parties contend that it's a condition on use, not a restriction on other software, but others view it as disqualifying.

Ultimately, the open-source distinction is binary for the OSI. If a license imposes a "field-of-use" restriction (no matter how reasonable it seems for protecting open-source projects), it is legally incompatible with the principles of open source.

Key license characteristics for cloud-era software

What Happens When Projects Switch to Source-Available Licenses? (Case Studies)

When major projects change to SSPL/BSL-style terms, the ecosystem reacts quickly. Major Linux distributions like Red Hat, Fedora, and Debian typically remove the software from their main repositories.

These distributions act as the trusted supply chain for the internet and observe strict free software guidelines (like the DFSG) to ensure legal safety for their users. When a license fails open-source principles, these guardians of the ecosystem drop the software to protect their downstream customers.

What's more, cloud providers and open-source communities often launch competing forks to preserve an OSI-compatible alternative. At a glance, here's how some of the prominent cases unfolded:

Let's take a closer look at each case.

MongoDB's SSPL Switch (2018)

MongoDB moved from the GNU Affero General Public License (AGPL) to the SSPL specifically to prevent cloud providers from offering MongoDB as a service without contributing back.

As Eliot Horowitz, co-founder and former CTO of MongoDB, clarifies in the official announcement:

"The market is increasingly consuming software as a service, creating an incredible opportunity to foster a new wave of great open source server-side software. Unfortunately, once an open source project becomes interesting, it is too easy for cloud vendors who have not developed the software to capture all of the value while contributing little back to the community…"

The OSI rejected SSPL as non-open-source almost immediately. In addition, Red Hat removed MongoDB from Fedora and RHEL repositories within months, citing incompatibility with their distribution guidelines.

In the words of Tom Callaway, a technical and community outreach program manager at Red Hat: "It is the belief of Fedora that the SSPL is intentionally crafted to be aggressively discriminatory towards a specific class of users…"

Not long after, Debian followed suit by removing MongoDB from its main repositories. AWS responded by launching DocumentDB, a MongoDB-compatible service that didn't use MongoDB's code at all.

Business takeaway at a glance

• Cloud providers avoided SSPL obligations by launching compatible but independent services, limiting MongoDB's leverage over major platforms.
• Major Linux distributions removed MongoDB packages to stay within their free software guidelines, forcing enterprises to reconsider how they deploy and update MongoDB.
• The licensing move protected some revenue but reduced default distribution and increased compliance complexity for downstream users.

Elastic's Dual-License Move (2021)

After years of AWS offering "Amazon Elasticsearch Service" without contributing revenue back to Elastic, the company tried to force a deal by switching from Apache 2.0 to a dual license: the Elastic License 2.0 and SSPL.

Instead of paying, however, AWS (along with partners like Red Hat, SAP, and Capital One) forked the project to create OpenSearch.

Because of AWS's massive engineering resources, OpenSearch quickly became a viable, truly open-source alternative that directly competes with Elastic's core product.

Major Linux distributions like Debian and Red Hat also removed Elasticsearch from their official repositories. With the SSPL switch, Elastic protected a revenue stream through commercial control, but they lost the immense platform mindshare and unified ecosystem that made the project dominant.

Redis Goes Dual-License (2024)

Redis Labs changed Redis from the permissive BSD license to a dual license combining Redis Source Available License v2 (RSALv2) and SSPL.

The reaction was swift. Former Redis maintainers and industry giants (including Google Cloud, AWS, and Oracle) united to launch Valkey. Within weeks, major cloud providers announced support for Valkey, effectively isolating the original vendor from the open ecosystem they built.

In the words of Madelyn Olson, former Redis maintainer and co-creator of Valkey:

"I worked on open source Redis for six years, including four years as one of the core team members that drove Redis open source until 7.2. I care deeply about open source software, and want to keep contributing. By forming Valkey, contributors can pick up where we left off and continue to contribute to a vibrant open source community."

For a company considering a similar license change, this case demonstrates just how high the risk of switching to a source-available license can be. Your most powerful users can and will organize to make your product obsolete, redirecting all future development energy away from your commercially licensed version.

HashiCorp and Terraform (2023)

HashiCorp switched Terraform from Mozilla Public License 2.0 (MPLv2) to the Business Source License (BSL) to prevent niche competitors from building value-added services on top of their engine.

In response, the open-source community launched OpenTofu, which secured Linux Foundation backing and contributing companies including Spacelift, Env0, and Scalr.

By placing the project under neutral governance, OpenTofu attracted enterprises that preferred a stable, non-proprietary standard over a vendor-controlled tool.

This case makes clear that even a well-defined "Additional Use Grant" under BSL can introduce enough uncertainty to push the ecosystem toward a fork.

The Consistent Pattern

Across all four cases, the same sequence emerges: a license announcement is followed by community backlash, a swift fork, and then removal from major Linux distributions.

For any business considering a source-available license, these examples show both sides. Source-available licenses often succeed in stopping direct resale, but they also risk alienating the community and incentivizing your biggest customers and rivals to fund a permanent competitor with the moral high ground of being "truly open."

Litigation and Compliance Considerations for Source-Available Licenses

Violating a source-available license shifts the legal ground from a simple contract dispute to copyright infringement. Since these licenses limit the scope of use (e.g., "non-competing purposes"), stepping outside that boundary, even by accident, means users are operating without a license.

For businesses, the key risk is that violating a source-available license can turn what looks like a commercial contract issue into a combined copyright and contract dispute with potential injunctions and significant damages.

Enforcement typically starts with a cease-and-desist letter demanding either compliance or purchase of a commercial license. If ignored, compliance penalties can include, but aren't limited to:

• A preliminary injunction forcing you to shut down the infringing service immediately
• Permanent injunction after trial
• Monetary damages (either actual damages and profits, or statutory damages)
• Attorney's fees and costs

Recent cases involving dual-licensed software indicate that courts may use the licensor's commercial pricing as a reference point for calculating damages, effectively converting a "free" license violation into a claim for paid license fees and related losses. That makes non-compliance with source-available terms more than a theoretical IP issue: it becomes a quantifiable financial risk that in-house counsel and deal teams need to factor into M&A, vendor selection, and audit planning.

While some licenses like the SSPL include a cure period (30 days), this offers little comfort. Businesses would still face the operational chaos and expense of an emergency migration to become compliant. Most businesses can't move that fast, which makes the theoretical cure period less protective than it appears.

While some licenses like the SSPL include a 30‑day cure period, this offers limited comfort in practice because most businesses cannot redesign and migrate a production service within that window.

Although there are not yet reported decisions interpreting SSPL or BSL specifically, courts have repeatedly confirmed that open source and dual-licensed software terms are legally enforceable and can support both injunctive and monetary relief.

Cases like Jacobsen v. Katzer, Artifex v. Hancom, and ongoing litigation such as SFC v. Vizio and European decisions against Orange S.A. show that violating "free" or open source license terms can lead to injunctions, substantial damages, and specific performance obligations.

The practical takeaway for businesses is that using SSPL- or BSL-licensed software without tight compliance creates a similar litigation profile: a dispute can escalate from a commercial negotiation into a combined copyright and contract enforcement action, with the associated disruption and financial exposure.

Should You Use a Source-Available License for Your Product?

If you're thinking about source-available licenses for commercial protection, it pays to pressure-test your strategy with these key considerations:

• Weigh the trade-offs: Source-available licenses help block competitive services, but that protection comes at a cost. You'll likely lose distro support and experience a decline in community contributions because developers prefer working on truly open projects they can use without restrictions. Consider whether blocking cloud providers is worth fragmenting your ecosystem. MongoDB, Elastic, and Redis all made this trade. Each now competes with an open-source fork that has its own contributor base and roadmap.
• Make your license language precise: Vague language creates legal exposure for your users and enforcement headaches for you. So, define terms that often cause ambiguity or raise disputes, like "production use," "competitive service," "offer as a service" with measurable criteria (e.g., revenue thresholds, feature lists, etc.). The more ambiguous your terms, the more reluctant enterprises will be to adopt your software.
• Build an enforcement & commercial-offer playbook: Decide how you'll detect violations, what remediation (and cure) you'll permit, and when you'll litigate vs. negotiate. Also, publish a clear commercial licensing path and pricing framework so customers know how to get compliant quickly.
• Prepare for a fork: If you relicense an existing open-source project, assume the community will fork the last open-source version. OpenTofu, OpenSearch, and Valkey are all popular forks of previously open software. With that in mind, ask yourself: how will you maintain differentiation? How will you message the change to existing users? The companies that handled this best acknowledged the fork publicly and articulated a clear value proposition for their commercial version.
• Consider long-term market position: Source-available licensing is a bet that commercial revenue from restrictions outweighs the ecosystem benefits of true open source. Once you've switched licenses and the community has forked, rolling back to open source and rebuilding trust is easier said than done.

Summary

Source-available licenses occupy a precarious legal position. They share similarities with open source models when it comes to accessibility but impose restrictions that disqualify them under the OSI's Open Source Definition.

The OSI's position signals that these licenses lack the legal clarity and standardization that make true open-source adoption predictable and safe. And the market has already shown the cost of getting this wrong.

MongoDB, Elastic, Redis, and HashiCorp faced distro package removals, full or partial community forks, and long-term distrust after shifting away from true open source licenses.

For companies considering source-available licenses, it's important that you understand you may be trading ecosystem benefits for control, and that decision comes with significant implications for your long-term market position.