fsl.software
提供功能源代码许可证
- 比 AGPLv3 更宽松，降低企业采用时被迫公开专有代码的风险
- 相较 open core，所有产品功能都可在当前阶段用于几乎所有用途，并在两年后完全宽松开源
- 相较 BSL，减少 Additional Use Grant 带来的许可证实现差异
- 两年转换期较 BSL 常见四年更短
- 最终转换为主流宽松许可证 Apache 2.0 或 MIT
- 不是 OSI 意义上的 Open Source，强调 Fair Source
- 两年内仍存在使用限制，不能用于损害生产者的场景
- 只允许 Apache 2.0 或 MIT 作为转换许可证，灵活性有限
- 正文未提供法律适用范围、合规示例或具体商业案例
- 生态采用度与行业接受度正文未充分说明
深度测评
是什么
FSL（Functional Source License）是一种 Fair Source 许可证，定位于 SaaS 公司开放核心产品源码时的授权选择。它的核心目标是在“用户可以使用、学习和修改软件”与“开发者和厂商避免有害搭便车”之间取得平衡。FSL 软件的每个版本在发布两年后会自动转换为 Apache 2.0 或 MIT。
核心能力
从正文看，FSL 提供 FSL-1.1-ALv2 与 FSL-1.1-MIT 两种变体。用户可以运行、研究、修改并分发变更，也可以向生产者提交改进；限制主要针对会削弱生产者可持续性的“有害搭便车”。它明确区别于传统 Open Source，因为开源许可证无法阻止这类搭便车；也区别于 AGPLv3，因为后者强 copyleft 可能让企业担心专有代码披露风险。
定价与生态
正文未提及任何收费模式，FSL 更像是许可证文本与采用规范，而非商业 SaaS 产品。它属于 Fair Source initiative，并提供 GitHub 采用指南。生态上，它参考了 Business Source License 的时间转换思路，但认为 BSL 的 Additional Use Grant 造成过多差异，且四年周期过长，因此采用更标准化的两年转换期。
优缺点
优点是规则相对清晰：两年后进入 Apache 2.0 或 MIT，许可证结果可预期；相比 open core，不是永久关闭部分功能；相比 AGPL，对企业法务和专有代码更友好。缺点是它并非 OSI 意义上的开源，两年内仍有使用限制；“有害搭便车”的边界可能需要结合具体条款和法律解释判断；正文也没有展示足够多的实际采用案例。
适合谁与中国访问
FSL 适合希望公开源码、建立开发者信任，但又担心云厂商或竞争者直接复制商业服务的 SaaS 与开发者工具公司。对使用方而言，适合能接受 Fair Source 条款并看重未来宽松开源转换的团队。中国访问情况正文未提供，判定为未知。
本测评基于公开资料整理,不构成购买建议,请以 fsl.software 官网实际信息为准。
中文卖点
保护SaaS公司免受搭便车
官网快照
价格走势
用户评价
评分明细(分布与用户短评)接入中。当前展示 TG4G 综合评分,数据源自公开测评与用户反馈。