'Source available' is not open source, and that's okay
What “Open Source” Means vs “Source Available”
- Many insist “open source” must follow OSI/FSF definitions: unrestricted use (including commercial/SaaS), right to modify and redistribute, ability to fork. Usage restrictions (e.g., “no competing SaaS”) break this.
- Others argue that if the source is visible and broadly usable, with only narrow SaaS restrictions, it’s “open enough” for almost all users and an improvement over fully closed code.
- Several stress that open source is about legal rights, not whether maintainers accept contributions or run an open bug tracker; a closed “cathedral” development style is still open source if the license is.
Community, Spirit, and Evolving Norms
- Some want “open source” to also imply open governance, contributor-friendly processes, and genuine community participation, not just a bare OSI-compliant license.
- Others reject stretching the term that far, proposing “community-driven” as a separate label and warning that blurring definitions makes communication and expectations harder.
Why Defend the Line?
- Hardliners say the value of OSI-style Open Source is predictable rights: if a license is standard, companies and developers can use code without lawyers.
- Any custom or “almost open” license reintroduces legal uncertainty, especially vague SaaS clauses (“primary value of the service,” “competition,” etc.).
- They emphasize the four freedoms, especially the right to run software for any purpose; restricting business models is seen as antithetical to free/open software.
SaaS, Cloud Providers, and New Licenses
- Some see non-compete/source-available licenses as a reaction to “Big Cloud” hosting popular OSS (Redis, Terraform, MinIO, etc.) and capturing most revenue.
- Others respond: if you don’t want that, don’t use an open source license; calling restricted licenses “open source” is misleading, even if the business motivation is understandable.
- Alternatives discussed: AGPL (closes classic network-use loophole but doesn’t block unmodified hosting), SSPL (more aggressive but rejected by OSI), and time-delayed licenses like BUSL (source-available now, guaranteed FOSS later).
Value and Risks of Source-Available
- Pro-source-available arguments: better debugging, auditing, reproducible builds, and admin sanity compared to opaque binaries; still useful even without full freedoms.
- Skeptical views: source-available projects rarely build resilient communities, can rug-pull or stagnate, and often centralize power with one company; many users avoid them like any proprietary dependency.
Terminology and Authority
- Several note that “open source” as plain English naturally suggests “source is open to see,” conflicting with OSI’s stricter meaning.
- Some propose distinguishing “Open Source” (capitalized, OSI sense) from generic “open source,” but acknowledge that language drift and marketing will keep the debate recurring.