'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.