FSL：给集市的许可证，不给大教堂的许可证
一种面向 SaaS 软件的新“Functional Source License”（FSL）旨在在两年内阻止商业竞争者，同时承诺之后自动切换为宽松的开源许可证。支持者认为，这是一种务实方式：既能资助开发、限制大型云服务商的“搭便车”，又能让用户获得源码访问和长期的退出通道；批评者则认为，它破坏了自由软件的核心原则，增加了贡献与分叉的复杂性，并模糊了开源与源码可得模式之间的界限。这场讨论还暴露了围绕定时改许可证的法律与信任问题，并凸显了维持商业 SaaS 业务与保留不受限制的软件自由之间的更大张力。
FSL 的范围与性质
- FSL 被视为一种“源码可得、最终开放”的许可证：代码现在可用，但带有非竞争限制，并且在两年后会自动变为 Apache 2.0。
- 该限制主要针对竞争性的 SaaS 服务；非商业用途和不竞争的自托管是允许的。
- 有人将其描述为 SaaS 场景下的“次优解中的较优者”：比完全专有或 BUSL 更好，但在独占期内显然还不是 FOSS。
分叉、“集市 vs 大教堂”，以及贡献动态
- 批评者认为 FSL 在结构上更像大教堂：由某个特殊方控制商业使用；有意义的分叉必须滞后两年，并且必须与原团队的节奏保持一致。
- 有人担心“社区”分叉中的安全修复和功能永远会落后两年，这会让真正的竞争或安全保障变得困难。
- 也有人反驳说，分叉仍然是可能的，尤其是在主项目停滞时；并指出许多开放项目本来就要求 CLA 或特殊的贡献授权。
法律与实践方面的顾虑
- 有一条讨论质疑，延时再许可和自动终止在某些欧盟法律下是否有效；另一些人回应说，分阶段授予权利很常见，而且条款在一开始就是已知的。
- 有人提出边缘情况：如果未来的许可证引用（例如 Apache）“消失”了会怎样；回应认为法院大概率会维护其意图，而现有分叉会保留它们已经拥有的许可证。
- 对什么算“竞争性使用”以及“暴露 API”的含义存在模糊性，这让一些人对法律风险感到担忧。
商业模式与“搭便车”之争
- 支持者将 FSL 描述为对云服务提供商或转售商的一种保护：防止他们把产品重新打包成托管服务，却不为其开发提供资金。
- 批评者说，软件不会像物理公地那样“磨损”；所谓有害的“搭便车”其实是商业模式问题，而不是许可证问题。
- 还有人认为，开源本质上就意味着放弃对商业利用的垄断；如果无法接受这一点，那项目就应该明确地做成专有软件。
与 FOSS 定义及表述方式的关系
- 许多人强调，FSL 不符合 FSF/OSI 对自由/开源的定义，因为它带有用途范围限制（禁止竞争）。
- 对把产品称为“开源”或“single-source open source”的营销方式反对很强烈；不少人认为这是在混淆既有术语。
- Sentry 代表承认，在到期前 FSL 不属于 Open Source，把它描述为与“开源理想”一致，并表示一些公开措辞会被修订。
替代方案与生态影响
- 有人建议使用 AGPL/GPL，认为它们更简单且更成熟；反方则强调 GPL 在商业环境中的污名、与应用商店的不兼容，以及被认为具有“传染性”的风险。
- 不少评论者表示他们不会在 FSL 下贡献，认为自由要延迟两年是不可接受的；也有人主要关心能否获得源码来调试和自托管，而并不在意正式的 FOSS 身份。