COMPARISON
Source available vs open source compared.
Source available vs open source is the distinction at the center of the relicensing wave. The two look alike, because in both cases you can read the code, but the licenses behave very differently, and the gap between them is where enterprise license risk lives.
Source available vs open source is a distinction that sounds academic until it appears in production. When HashiCorp, Redis, Elastic, and MongoDB moved widely used projects from open source licenses to source available ones, many teams kept using the software as before, on the assumption that visible code meant open source. It does not. This comparison sets out what separates the two, why source available is not open source, and what the difference means for the software you already run. For the wider frame, see our pillar on open source license risk.
What open source means
Open source is not simply code you can see. It is a precise idea defined by the Open Source Definition, maintained by the Open Source Initiative. A license qualifies as open source only if it permits use, modification, and redistribution for any purpose, with no restriction on the field of use and no discrimination against persons, groups, or uses. Permissive licenses such as MIT and Apache 2.0 meet this bar, and so do copyleft licenses such as the GNU GPL and the GNU AGPL, even though copyleft adds reciprocity conditions. What unites them is that none restricts who may use the software or for what. The benchmark is set out in our definition of an OSI approved license.
What source available means
Source available means the source code is published and readable, but the license attaches conditions that the Open Source Definition does not allow. The most common condition is a field of use restriction: the license permits most uses but bars offering the software as a competing commercial or managed service, or it delays open use until a future date. The Business Source License used by HashiCorp and the Server Side Public License used by MongoDB, Elastic, and Redis are the prominent examples. You can read the code, study it, and often run it, but a class of use is carved out. That carve out is exactly what keeps these licenses outside the open source definition. Our glossary entry on the source available license covers the mechanics in more depth.
Source available vs open source at a glance
| Dimension | Open source | Source available |
|---|---|---|
| Code visibility | Source is published and readable. | Source is published and readable. |
| Field of use | No restriction. Any purpose, including competitive and commercial use. | Restricted. Commonly bars competitive or managed service use. |
| OSI approval | Approved against the Open Source Definition. | Not approved as open source. |
| Redistribution | Permitted, sometimes with reciprocity under copyleft. | Permitted within the license's use limits, not beyond. |
| Examples | MIT, Apache 2.0, GNU GPL, GNU AGPL. | Business Source License, Server Side Public License, Redis Source Available License. |
| Enterprise risk | Low license risk from terms, though obligations such as copyleft still apply. | Competitive use and production restrictions can apply to software already running. |
Why the distinction matters for enterprises
The risk in confusing the two is concrete. A source available license can restrict competitive use, managed service offerings, or production deployment, and those restrictions can apply to software a company adopted years earlier under an open source license, then carried forward through upgrades. Treating a source available component as if it were open source is how exposure enters production without anyone deciding to accept it. The exposure is sharpest for vendors that resell or host software, because the competitive and service restrictions are written precisely for that case. The way these changes reach an estate is traced in our pillar on relicensing.
How to act on the difference
The practical response is to track the license state of every dependency precisely, rather than sorting components into a single open source bucket.
- Record whether each component is open source or source available, and which specific license governs the version you run.
- Flag any source available component that sits in a competitive, hosted, or distributed path, because that is where a restriction is most likely to bite.
- Treat a relicense as a change of state, not a footnote, so a component that moved from open source to source available is re evaluated rather than carried forward unexamined.
- Where a source available restriction reaches a live use, weigh the open paths, including a fork to an open source alternative or a negotiated commercial license.
The distinction is not a reason to avoid source available software outright. Plenty of it is safe to run, depending on how you use it. The point is to decide that on the facts rather than on the assumption that readable code is open source. A confidential assessment maps where each kind sits in your estate and sizes any exposure, so the decision rests on numbers. See also our explainer on permissive, copyleft, and source available explained. Interpretation of whether a specific license restricts your use is a question for your own counsel.
COMMON QUESTIONS
Questions buyers ask.
What is the difference between source available and open source?
Open source means the source code is available and the license meets the Open Source Definition, which permits use, modification, and redistribution for any purpose without field of use restrictions. Source available means the code is visible but the license restricts use in some way, commonly barring competitive or managed service use. Visible code alone does not make software open source.
Is source available the same as open source?
No. Source available licenses such as the Business Source License and the Server Side Public License are not approved by the Open Source Initiative, because they place restrictions that the Open Source Definition does not allow. The two terms are often confused, but the difference carries real obligations for enterprise use.
Why does the distinction matter for enterprises?
Source available terms can restrict competitive use, managed service offerings, or production deployment, and those restrictions can apply to software already running. Treating a source available component as if it were open source is how exposure enters production unnoticed, which is why the license state of each dependency should be tracked precisely.
Which licenses are source available rather than open source?
Common examples include the Business Source License used by HashiCorp, the Server Side Public License used by MongoDB, Elastic, and Redis, and various source available licenses such as the Redis Source Available License. Permissive licenses such as MIT and Apache 2.0, and copyleft licenses such as the GNU GPL and AGPL, are open source.
Is this comparison legal advice?
No. It is commercial and licensing risk analysis, not legal advice. For interpretation of whether a specific license restricts your use, engage your own counsel.
CONTAINMENT
Know which of your code is actually open.
A confidential open source license risk assessment. Independent, buyer side, paid only by you.
Not ready to talk? Read the free open source license risk guides first.