FSL: A License for the Bazaar, Not the Cathedral
A new “Functional Source License” (FSL) for SaaS software aims to block commercial competitors for two years while promising an automatic switch to a permissive open-source license afterward. Supporters see it as a pragmatic way to fund development and limit “free-riding” by large cloud providers while still giving users source access and a long-term escape hatch; critics argue it undermines core free‑software principles, complicates contributions and forking, and blurs the line between open source and source‑available models. The exchange also surfaces legal and trust concerns around timed license changes and highlights broader tension between sustaining commercial SaaS businesses and preserving unrestricted software freedom.
Scope and nature of the FSL
- FSL is seen as a “source-available, eventually-open” license: code is usable now with a non‑compete restriction, and automatically becomes Apache 2.0 after two years.
- The restriction mainly targets competing SaaS offerings; non‑commercial and non‑competing self‑hosting is allowed.
- Some describe it as “least-worst” for SaaS: better than fully proprietary or BUSL, but clearly not FOSS during the exclusivity period.
Forks, “bazaar vs cathedral,” and contribution dynamics
- Critics argue FSL is structurally cathedral-like: one special party controls commercial use; meaningful forks must lag two years and match the original team’s pace.
- Concern that security fixes and features in the “community” fork will always be two years behind, making real competition or safety hard.
- Others counter that forks are still possible, especially if the main project stagnates, and note that many open projects already require CLAs or special contributor grants.
Legal and practical concerns
- One thread questions whether time‑delayed relicensing and automatic termination are valid under some EU laws; others respond that time‑phased grants are common and terms are known upfront.
- Edge cases raised: what happens if the future license reference (e.g., Apache) “disappears”; responses suggest courts would likely uphold the intent and that existing forks retain the license they already have.
- Ambiguity around what counts as a “competing use” and “exposing APIs” makes some wary of legal risk.
Business model and “free‑rider” debate
- Supporters frame FSL as protection against cloud providers or resellers who repackage the product as a hosted service without funding its development.
- Critics say software doesn’t “wear out” like physical commons; “harmful free‑riding” is really a business‑model problem, not a license problem.
- Some argue open source inherently surrenders monopoly on commercial exploitation; if that’s unacceptable, the project should be plainly proprietary.
Relationship to FOSS definitions and messaging
- Many emphasize FSL is not Free/Open Source under FSF/OSI definitions due to field‑of‑use (no‑competition) restrictions.
- Strong pushback against marketing that calls the product “open source” or “single‑source open source”; several see this as muddying established terminology.
- Sentry representatives acknowledge FSL is not Open Source until expiry, describe it as aligned with “open source ideals,” and say some public wording will be revised.
Alternatives and ecosystem impact
- Some suggest AGPL/GPL as simpler, established solutions; counterarguments stress GPL stigma in commercial environments, app‑store incompatibility, and perceived “viral” risk.
- Several commenters say they would not contribute under FSL, seeing a two‑year delay on freedom as unacceptable; others care mainly about having source to debug and self‑host, not formal FOSS status.