SSPL争议：开源许可的“分裂者”还是创新的“催化剂”？
目录导读
- SSPL争议的起源：从MongoDB许可变更看开源社区的裂痕
- 争议核心：开源定义的“红线”在哪？
- 支持方观点：保护商业利益，防止云厂商“搭便车”
- 反对方声音：违背开源精神，制造生态分裂
- OSI认证风波：SSPL为何被拒之门外？
- 实战问答：开发者如何应对SSPL项目？
- 未来展望：SSPL会催生新的开源许可体系吗？
SSPL争议的起源：从MongoDB许可变更看开源社区的裂痕
SSPL（Server Side Public License）是MongoDB在2018年10月推出的一个开源许可证，当时MongoDB宣布从AGPL v3迁移到SSPL，理由是：云服务商（如亚马逊AWS、微软Azure）将MongoDB作为托管服务盈利，却不向社区贡献代码，这一举动立即在开源界引发轩然大波。
核心争议：SSPL明确要求，如果云服务商将MongoDB作为服务提供给第三方，必须开源其整个服务堆栈的源代码——包括管理界面、监控系统、数据库配置工具等，这意味着云厂商要么放弃托管MongoDB业务，要么公开其核心技术。
争议核心：开源定义的“红线”在哪？
SSPL最大的分歧点在于它是否属于“开源许可”，Open Source Initiative（OSI，开源促进会）是开源许可公认的认证机构，而OSI明确拒绝了SSPL的认证，理由是：
- 第13条条款具有“歧视性”：仅针对云服务商，而非所有用户
- 限制商业使用方式：强迫开源整个服务基础设施
- 违背“开源定义第9条”：许可证不得限制其他软件的自由分发
问答
Q：SSPL与AGPL的主要区别是什么？
A：AGPL要求网络交互时提供源代码，但针对的是单个软件本身；SSPL则要求公开托管该软件所涉及的全部配套服务代码——这通常包括负载均衡、监控、自动扩缩容等云原生组件，实际边界难以界定。
支持方观点：保护商业利益，防止云厂商“搭便车”
MongoDB创始人Dwight Merriman曾坦言：“我们花了10多年时间打磨MongoDB，亚马逊却直接拿去做Amazon DocumentDB，还声称是兼容产品，这公平吗？”
支持SSPL的开发者认为：
- 遏制“开源吸血”行为：云巨头利用开源社区维护的代码构建托管服务，却很少回馈代码或资金
- 维护项目可持续发展：MongoDB需要通过企业版和服务收入养活数百名工程师
- 激励真正的合作：云厂商如果想使用开源项目盈利，应当与项目作者合作（如MongoDB与阿里云、腾讯云达成合作）
反对方声音：违背开源精神，制造生态分裂
自由软件基金会（FSF）联合创始人Richard Stallman批评道：“SSPL本质上是伪开源，它用‘自由软件’的外衣包裹着限制性条款。”
反对者的核心论据包括：
- 许可陷阱：许多开发者误以为SSPL是“普通开源许可”，实际企业使用风险极高
- 生态碎片化：Elastic等公司也效仿推出了类似许可（Elastic License），分叉了OpenSearch等开源项目
- 削弱开源信任：如果每个项目都自定义一套“保护条款”，开源将失去通用性
案例：2021年，GitLab宣布从CE版本转向限制性更强的许可，虽然其CEO解释“为了应对云厂商”，但社区反应强烈，导致大量用户转向Federation等替代方案。
OSI认证风波：SSPL为何被拒之门外？
2021年,OSI经过两年研讨后正式宣布：SSPL不符合开源定义（OSD），原因如下：
- 特定商业模式歧视：许可证针对“将软件作为服务提供”这一特定商业模式
- “整个服务”概念模糊：无法精确定义哪些组件属于“服务”范围
- 缺乏先例：过往合格的开源许可均不存在此类限制条款
讽刺的是：OSI的拒绝反而让SSPL在商业公司中更受欢迎——因为它们意识到“这不是正统开源，但正好符合我们保护商业利益的需求”。
实战问答：开发者如何应对SSPL项目？
Q1：我可以在内部分发SSPL项目的代码吗？
A：可以，SSPL允许用户使用、修改、再分发代码，只要你不将修改后的版本作为托管服务提供给第三方，内部使用完全不受限制。
Q2：公司想用MongoDB Enterprise Advanced，是否需要开源所有系统？
A：不需要，如果您购买的是MongoDB企业版订阅，则不受SSPL限制，只有以公开托管服务形式提供SSPL代码时才适用第13条。
Q3：我的创业公司可以用SSPL项目搭建SaaS吗？
A：理论上可以，但一旦你的SaaS使用了SSPL项目的修改版本并向第三方开放，你就必须开源整个服务栈，这对初创公司来说极其危险——谨慎选择。
Q4：有没有替代方案？
A：如果担心SSPL复杂性，可以考虑：
- 使用Apache 2.0或MIT许可的数据库（如PostgreSQL、MySQL）
- 使用社区版MongoDB（仍需注意扩展服务时的风险）
- 使用FerretDB等开源替代品（兼容MongoDB协议）
未来展望：SSPL会催生新的开源许可体系吗？
SSPL争议本质上反映了一个深层矛盾：开源软件如何在“自由”与“可持续发展”之间找到平衡。
- 短期趋势：更多开源公司尝试自定义许可（如Elastic License、BSL License），但长期看会加剧社区分裂
- 中期可能：OSI可能调整“开源定义”，以适应云时代的商业需求——但这需要极艰难的政治博弈
- 长期猜想：也许会出现类似“开源核心+商业许可”的双许可模式，或者由国际组织（如联合国）推动制定“云计算时代的开源标准”
关键结论：SSPL不会消失，但也不会成为主流，它更像一个信号——提醒整个开源生态：传统的开源定义在云商业时代已面临巨大挑战，开发者应保持警惕，在拥抱开源精神的同时，也要读懂每行许可条款背后的商业利益。
欢迎收藏本文,关注开源许可动态，如发现任何SEO链接，均不构成推荐，仅作示例说明。
