Source-Available vs Open Source: The Difference

In recent years, foundational software projects such as Redis, Elasticsearch, and Terraform have made headlines by departing from long-standing open source licenses (BSD, Apache 2.0, MPL 2.0) in favor of Source-Available licenses like SSPL-1.0, BUSL-1.1, RSALv2, and ELv2.

While developers can still inspect and build code hosted on public GitHub repositories, "source-available" and "open source" represent fundamentally distinct legal frameworks. This guide explains the definitive criteria set by the Open Source Initiative (OSI), analyzes the restricting clauses, and highlights real-world project transition data.

1. The Open Source Benchmark: OSI 10 Open Source Definitions

Open Source is not an informal industry term; it is a legally protected certification mark managed by the Open Source Initiative (OSI). An OSI-approved license (such as MIT, Apache-2.0, BSD-3-Clause, or GPL) must rigorously meet all 10 criteria of the Open Source Definition (OSD), including:

• Criteria 5 (No Discrimination Against Persons or Groups): The license must not discriminate against any person or group of persons.
• Criteria 6 (No Discrimination Against Fields of Endeavor): The license must not restrict anyone from making use of the program in a specific field of endeavor (e.g., commercial production, cloud hosting, or research).

Under true open source licensing, anyone—including a direct market competitor—is entitled to run, modify, redistribute, and monetize the software without paying royalties or obtaining permission.

2. What Defines a Source-Available License?

A Source-Available license grants users the right to view and compile the source code, but explicitly restricts specific commercial activities—most commonly, providing the software as a competing managed cloud service or managed database offering.

Because these restrictions violate Criteria 6 (No Discrimination Against Fields of Endeavor), the OSI explicitly categorizes source-available software as proprietary and non-open source.

3. Key Source-Available Licenses and Restrictive Clauses

Major infrastructure software tracked on Relicensed utilizes the following source-available frameworks:

1) SSPL-1.0 (Server Side Public License)

Introduced by MongoDB and later adopted by Redis and Elasticsearch, the SSPL is derived from AGPL-3.0 with a crucial modification in Section 13 (Offering the Program as a Service).

If an entity makes the software's functionality available to third parties as a service (e.g., DBaaS), Section 13 mandates that the entire software stack used to provide the service—including management software, control planes, backup systems, and monitoring agents—must be released publicly under the SSPL. For cloud hyperscalers, disclosing proprietary cloud infrastructure source code is unacceptable, effectively preventing them from selling the software as a service.

2) BUSL-1.1 (Business Source License)

Employed by HashiCorp (Terraform, Vault, Consul), CockroachDB, and Sentry:

• Use Restrictions: Configured via an "Additional Use Grant" that specifies which commercial uses are permitted and which competing services are prohibited.
• Change Date: Unlike permanently proprietary licenses, BUSL code converts automatically to an OSI-approved open source license (such as Apache-2.0 or MPL-2.0) after a designated period (maximum 4 years).

3) RSALv2 (Redis Source Available License v2) & Elastic License 2.0

Custom source-available licenses that directly bar providing the software as a managed service or reselling it as a value-added commercial wrapper.

4. Real-World Transition Data Summary

Here is how major projects in the Relicensed dataset transitioned from open source to source-available terms:

5. Actionable Takeaways for Engineering Teams

1. Internal Workloads: Running internal self-hosted instances (e.g., using Redis for caching or Terraform for provisioning your own apps) remains permitted across virtually all source-available licenses.
2. SaaS Platforms: If your company monetizes infrastructure as a service, source-available updates represent high legal risk. Pinning pre-change versions or migrating to forks like Valkey, OpenTofu, or OpenSearch is advised.

To determine whether your software stack is affected by license boundary versions, run our online License Checker.