Please stop inventing new software licences (2020)
Software vendors are increasingly creating bespoke “open” licenses that let them publish source code while restricting commercial use, competition from cloud hyperscalers, or training of AI models. Commenters argue this blurs the established meaning of Open Source as defined by OSI and FSF, misleads users and contributors, and complicates legal review and license compatibility. Many see value in source-available or non-commercial models, but insist they should use clear, standardized labels and not be marketed as open source.
Definition and Misuse of “Open Source”
- Many argue “open source” should mean OSI-compliant licenses only; anything else should be called “source available,” “shared source,” etc.
- Others see that as overly narrow or “childish,” preferring broader notions like “free software” or FOSS.
- Several comments stress that calling non‑OSI licenses “open source” is misleading marketing that trades on FOSS “street cred.”
- There is confusion between “open source” (as a formal movement/definition) and the intuitive reading “source code is visible.”
Fairness, Hyperscalers, and Business Models
- Some maintain that classic OSS assumptions (universities, fair play, contributions back) break down in a cloud/SaaS world where hyperscalers extract value without contributing.
- Suggestions include using AGPL or not using OSS licenses at all if you want to prevent big cloud vendors from free‑riding.
- Others respond that licenses are about rights, not “fairness” or “contributing back”; if you don’t like the allowed uses, choose a different license instead of complaining.
Custom / Non‑Standard and Source‑Available Licenses
- Many warn that bespoke licenses hurt adoption, especially in enterprises where anything non‑standard triggers legal review.
- Several examples of “source available but not OSS” models are discussed: Microsoft’s reference license, BSL, SSPL, Functional/Fair Source, PolyForm, Unreal, and similar.
- Some participants want more standardized, vetted non‑OSS licenses (non‑commercial, no‑competition, trial‑only, small‑business‑only), rather than everyone inventing new ones.
- Others argue that OSI already has too many licenses and that new ones increase complexity and compatibility headaches.
Terms, Ideology, and History
- Debate over whether “open source” inherently implies open governance; some say yes in practice, others say governance is orthogonal to licensing.
- Several emphasize the historical difference between “Free Software” (user freedoms, FSF) and “Open Source” (development/quality and business‑friendly framing, OSI).
- There is disagreement on whether language drift (“open source” = “public source”) should be accepted or resisted; one side sees defending terminology as vital to preserving values, the other as pedantic.
Practicalities and Edge Cases
- GitHub’s ToS grants limited rights to fork and copy code on GitHub itself, even when project licenses are restrictive, but this may not extend cleanly to local use.
- Thread notes that public domain and CC0 are not OSI‑approved, highlighting subtle gaps between everyday and OSI notions of “open.”