You’ve probably seen “open source” stamped on a GitHub repository and assumed you could use the code however you wanted. That’s not always true anymore.
Major infrastructure vendors like HashiCorp, MongoDB, Redis, and Elasticsearch have shifted to “source-available” licensing. The code is still visible, but new restrictions determine how you can use it in production. Terms like “competitive offering” and “production use” create legal grey areas.
Get it wrong and you might face expensive license negotiations or have to migrate off a dependency you’ve built your product around.
This article is part of our comprehensive guide on Open Source Licensing Wars – How HashiCorp, Redis and Cloud Economics Are Reshaping Infrastructure Software, where we explore the licensing crisis affecting infrastructure projects and what it means for CTOs making technology decisions.
This article walks you through the licensing spectrum—from permissive options like BSD and Apache 2.0, through copyleft licenses like GPL, to the newer source-available licenses like BSL and SSPL.
What Makes a License “Open Source”? The OSI Definition
Open source doesn’t just mean you can see the code. The Open Source Initiative maintains the actual definition through ten specific criteria that any license must meet.
The OSI created the Open Source Definition by adapting the Debian Free Software Guidelines back in 1997. If a license doesn’t meet all ten criteria and get OSI approval, it’s not officially open source—no matter what the marketing materials claim.
Two criteria matter most when distinguishing between open source and source-available licenses. Criterion #6 says licenses can’t discriminate against fields of endeavour. You can’t prohibit someone from using the software for genetic research, running a business, or competing with you. Criterion #9 prevents licenses from imposing restrictions on other software that you use alongside the licensed program.
These two criteria are where Business Source License and SSPL fall short.
OSI approval has commercial consequences beyond branding rights. When MongoDB switched to SSPL, major Linux distributions dropped it from their repositories because it violated their open source policies. You can’t get into Debian or Red Hat Enterprise Linux repositories without an OSI-approved license. That distribution exclusion reduces adoption and creates installation friction for potential users.
The term “source-available” emerged to describe licenses where you can view the code but restrictions violate the Open Source Definition. If a license prohibits specific use cases—running competitors, cloud hosting, commercial production—it’s source-available, not open source. The code might be on GitHub with full visibility, but it doesn’t grant the freedoms that open source promises.
What Are Permissive Licenses and How Do BSD, Apache, and MPL Differ?
Permissive licenses give you considerable freedom. Use the code, modify it, distribute it commercially, combine it with proprietary software—all without copyleft obligations or source disclosure requirements.
BSD 3-clause sits near the permissive end of the spectrum. It requires you to keep the license notice in the code and not use the project’s name for endorsement without permission. That’s it. Mac OSX used BSD-licensed code because the license didn’t force Apple to open source their operating system.
Apache 2.0 adds specificity that lawyers appreciate. It includes an explicit patent grant protecting you from patent litigation by contributors. If someone contributes code to an Apache 2.0 project, they automatically grant you rights to any patents covering that code. The license also includes trademark protection. These additions make Apache 2.0 safer for commercial adoption than BSD or MIT, even though the core permission structure is similar.
Mozilla Public License implements what’s called weak copyleft or file-level copyleft. Modifications to MPL-licensed files must be shared, but you can combine MPL code with proprietary code as long as you keep them in separate files. This makes MPL easy to use in closed-source products while ensuring improvements to the MPL-licensed components get shared back.
All these permissive licenses are GPL-compatible and can be mixed in most projects. They maximise adoption velocity because they don’t place burdens on users.
So why did companies abandon them? Cloud providers monetised permissively-licensed infrastructure projects without contributing financially. AWS, Google Cloud, and Azure built managed services from projects like Redis, PostgreSQL, and MySQL. Azure Cache for Redis and Google Memorystore generate high-margin revenue that never flows back to the companies that built the databases. For maintainers trying to sustain commercial businesses around infrastructure projects, permissive licenses meant watching competitors profit from their work. This tension between cloud providers and open source companies is explored in depth in our open source licensing wars overview.
What Is the Business Source License and How Does Its Time-Delay Mechanism Work?
While permissive licenses proved vulnerable to cloud provider exploitation, source-available alternatives like the Business Source License took a different approach.
The Business Source License was created by MariaDB in 2016 and updated to BSL 1.1 in 2017. It’s a source-available license that sits between open source and proprietary software. You can view the code and use it for non-production purposes, but commercial production deployment is restricted.
The interesting bit is the “springing license” mechanism. BSL automatically converts to open source after a specified Change Date. That Change Date is set to a maximum of four years from each version’s release. Once that date arrives, the conversion is permanent—that version becomes truly open source with no production restrictions.
Each software version has its own Change Date. This creates a rolling window where recent versions remain BSL while older versions convert to open source. If you release Terraform 1.5 in January 2023 with a four-year Change Date and Apache 2.0 as the target license, it automatically becomes Apache 2.0 in January 2027. HashiCorp’s adoption of BSL for Terraform sparked the OpenTofu fork and raises questions about IBM’s future licensing direction.
The Change License must be GPL v2 or later, or a GPL-compatible license. This ensures the eventual open source version maintains genuine open source freedoms.
BSL includes an Additional Use Grant—a customisable clause where licensors specify exceptions to production restrictions. HashiCorp permits production use except for competitive offerings, though terms like “competitive offering” lack clear boundaries, making it difficult to know if your use case violates the license without getting legal review. MariaDB limits use to three server instances in production. Each implementation customises this clause differently based on what behaviours they want to restrict.
For non-production use, BSL is permissive. Development environments, testing, CI/CD pipelines, and internal tools are all freely permitted. The restrictions only apply to production deployment, and even then only to uses not covered by the Additional Use Grant.
The problem is definitional ambiguity. BSL doesn’t define “production use” precisely. Is an internal business-critical system production? What about a customer-facing feature that’s still in beta? Different licensors and users might interpret these terms differently, creating compliance uncertainty.
If your production use isn’t covered by the Additional Use Grant, you need to purchase a commercial license from the vendor, wait for the Change Date, or switch to an alternative tool.
What Is the Server Side Public License and Why Did OSI Reject It?
MongoDB created the Server Side Public License in 2018, pioneering a pattern of restrictive licensing changes that other infrastructure vendors would follow. SSPL is based on AGPL v3 but expands disclosure requirements beyond traditional copyleft.
AGPL closes the “SaaS loophole” in standard GPL by requiring source disclosure when users access the software over a network.
SSPL goes further. If you offer SSPL software as a service, you must release source code for your entire infrastructure stack—management software, monitoring tools, APIs, orchestration, storage systems, and hosting automation. Everything you use to make that program available as a service.
In 2019, OSI declined to approve SSPL because it violates two core criteria. It discriminates against cloud hosting (criterion #6). It imposes obligations on unrelated software in your stack (criterion #9).
MongoDB designed SSPL to prevent AWS, Google Cloud, and Azure from offering MongoDB-as-a-service without contributing financially.
The targeting worked. AWS built DocumentDB rather than comply with SSPL. But Debian and Red Hat removed MongoDB from their distributions because it no longer met open source standards. When Redis adopted SSPL in 2024, it triggered an even more dramatic community response with the Valkey fork achieving 83% enterprise adoption within months.
For internal use, SSPL behaves like AGPL. You can fork it, modify it, run it at scale within your organisation without triggering disclosure obligations. The infrastructure stack requirement only applies when you “offer the functionality of the Program as a service to third parties.”
The definition of “offering as a service” creates compliance uncertainty. Does hosting for a single customer count? What about internal use at scale? These grey areas require legal interpretation.
How Should You Choose a License for Infrastructure Projects in 2026?
License selection starts with your project goals. Broad adoption? Protection from cloud competition? Revenue? The answer determines which license makes sense.
For broad adoption, Apache 2.0 is the standard choice because the patent grant provides legal safety. Companies can integrate it into commercial products without worrying about patent litigation.
For sustainability with openness, copyleft licenses ensure derivative works stay open. AGPL works well for SaaS where you want to prevent proprietary forks. MPL provides file-level protection while allowing combination with proprietary code.
For competitive protection, BSL provides time-delayed conversion while restricting production competitors. Choose your Change Date—two years for fast-moving infrastructure, four years for stable platforms. Craft your Additional Use Grant carefully to reduce compliance uncertainty.
SSPL prevents cloud provider monetisation but triggers community fragmentation and distribution exclusion. The Redis experiment suggests AGPL might offer better balance.
If you lack legal teams, stick to OSI-approved licenses to reduce legal review burden and vendor lock-in risk.
When evaluating BSL or SSPL dependencies, plan for license changes. Have a fork readiness plan, budget for commercial licenses, or identify migration alternatives.
A simple framework: Start with “Do I need to prevent cloud provider competition?” If no, use Apache 2.0. If yes, try AGPL first. It’s OSI-approved, well-understood, and maintains distribution access. Only move to BSL if you need broader production restrictions. Only consider SSPL if you’re willing to accept community fork risk.
What Are the Compliance Implications of Each License Type?
Permissive license compliance is straightforward. Keep license notices in the code. Include attribution in your documentation. SBOM tools automate this entirely.
Copyleft compliance requires sharing source code when you distribute or provide network access. GPL, LGPL, and AGPL have well-documented processes and clear case law.
BSL compliance gets murky. Interpreting “production use” and Additional Use Grant boundaries requires legal analysis. The licensor’s interpretation is binding, so you need clarity directly from them.
SSPL compliance centres on infrastructure stack boundaries. What counts as “programs you use to make the Program available as a service”? The definition varies by context, creating subjective determinations.
Your internal approval process needs to match license types. Permissive licenses can flow through automated approval. Copyleft requires checking disclosure requirements. Source-available demands manual legal review because terms vary by implementation.
Most SBOM tools can detect BSL and SSPL licenses but can’t automate compliance decisions. You’ll need human legal interpretation.
Violation consequences differ by license type. Permissive and copyleft violations typically result in injunctions requiring compliance. Source-available violations might void the license entirely, requiring retroactive commercial license purchase.
Redis adoption now requires legal review for each release because the license terms changed. Without in-house counsel, that friction can become blocking.
FAQ Section
What happens when a BSL-licensed product reaches its Change Date?
On the Change Date, that version automatically converts to the Change License specified in the BSL notice. The conversion is permanent and that version becomes truly open source with no production restrictions. Each version has its own Change Date, creating a rolling window.
Can I fork a SSPL-licensed project and use it internally?
Yes. Forking SSPL software for internal use is permitted without triggering disclosure obligations. SSPL’s infrastructure stack requirement only applies when you “offer the functionality of the Program as a service to third parties.” Internal use doesn’t constitute offering as a service. If you host the software for customers as a managed service—even a single customer—SSPL obligations kick in.
Why did major Linux distributions drop MongoDB after the SSPL license change?
Debian and Red Hat removed MongoDB because it no longer met their open source standards. SSPL’s requirement to disclose infrastructure stack code discriminates against cloud hosting, violating Open Source Definition criterion #6. SSPL’s source-available status made it ineligible for inclusion.
How do I determine if my use case violates a BSL Additional Use Grant?
Read the specific Additional Use Grant in the software’s LICENSE file. Each BSL implementation customises this clause differently. If your use case isn’t clearly permitted, purchase a commercial license, wait for the Change Date, or choose an alternative tool. When in doubt, contact the vendor—their interpretation is binding.
Is the Business Source License truly “open source with a delay”?
This framing is technically accurate but misleading. While BSL eventually converts to open source after the Change Date, during the BSL period it’s source-available, not open source. Production use restrictions violate Open Source Definition criterion #6. For commercial adopters, those 2-4 years of restrictions create vendor lock-in risk and compliance obligations identical to proprietary software.
What’s the difference between AGPL and SSPL network copyleft?
AGPL requires sharing source code modifications when users access the software over a network. This closes the “SaaS loophole” in standard GPL. SSPL expands obligations dramatically. Beyond sharing modifications, SSPL requires releasing source code for “all programs you use to make the Program available as a service”—management software, monitoring tools, APIs, orchestration, storage, and hosting automation. SSPL effectively requires disclosing your entire infrastructure stack, which is why OSI rejected it.
Can I use permissive-licensed code in a BSL or SSPL project?
Yes. License compatibility flows in one direction. Code under permissive licenses can be incorporated into projects using more restrictive licenses. The combined work’s license is determined by the most restrictive license present.
Why do source-available licenses create vendor lock-in risk?
Source-available licenses allow unilateral license changes that can retroactively prohibit your use case. Under BSL, a vendor could tighten the Additional Use Grant in future versions, making upgrades require commercial licenses. Unlike true open source where you could fork and continue, source-available licenses restrict competitive forks, forcing you to pay or migrate.
How do I know if a license is OSI-approved?
Check the OSI’s official list at opensource.org/licenses. If a license isn’t on this list, it’s not officially open source regardless of marketing claims. Many source-available licenses deliberately mimic open source names—Business “Source” License, Server Side “Public” License—but lack OSI approval. Verify OSI approval rather than trusting terminology.
What compliance tools can scan for BSL and SSPL licenses?
Most SBOM and dependency scanning tools like FOSSA, Snyk, WhiteSource, and Black Duck can detect BSL and SSPL licenses and flag them for manual review. However, unlike permissive and copyleft licenses, BSL and SSPL require human legal interpretation. Additional Use Grant clauses vary by implementation. “Production use” definitions are context-dependent. Tools can alert you but can’t automate compliance decisions.
When should I consult a licensing attorney?
Engage legal counsel when considering BSL or SSPL for your own project—Additional Use Grant drafting has commercial implications. Also consult when adopting BSL or SSPL dependencies in commercial products, receiving vendor license change notifications, facing M&A due diligence, operating in regulated industries, or planning to fork source-available projects. For permissive and copyleft licenses, compliance is typically straightforward without legal review.
How has the source-available trend affected open source sustainability?
The shift toward source-available licensing reflects infrastructure companies’ response to cloud providers monetising open source projects without contributing financially. While BSL and SSPL provide revenue protection, they fragment communities. Elasticsearch forked to OpenSearch. When Redis switched to SSPL in March 2024, the Linux Foundation announced Valkey, backed by AWS, Google, and others. The Redis experiment is instructive—moved to SSPL in March 2024, faced backlash, returned to AGPLv3 in 2025. This suggests AGPL might offer better balance between protection and openness.
For a comprehensive overview of how these licensing changes have impacted major infrastructure projects and what CTOs should watch for, see our complete open source licensing wars guide.
