【开源许可与版权工程】AGPL、SSPL、BSL：云厂商时代的"反云"许可证
内容提要
本文讨论了反云许可证的演变，重点分析了开源许可证如何应对云服务商的盈利模式。自2007年AGPL发布以来，MongoDB的SSPL、Elastic的ELv2、HashiCorp的BUSL等许可证相继出现，旨在限制云厂商利用开源软件获利而不回馈社区。文章探讨了这些许可证的法律背景、经济影响及其对开源生态的挑战，强调了云厂商与开源项目之间的博弈关系。
关键要点
-
反云许可证旨在限制云厂商利用开源软件获利而不回馈社区。
-
开源商业模式的原始假设包括分发假设和支持服务假设。
-
SaaS和云计算的兴起改变了开源软件的商业化路径，云厂商不再触发传统的分发条款。
-
AGPL是对SaaS漏洞的回应，要求修改后的程序在网络服务中披露源码。
-
MongoDB的SSPL试图扩展传染范围，要求云厂商披露服务源代码。
-
Elastic的ELv2和HashiCorp的BUSL也采取了类似的反云策略，限制云服务商的使用。
-
Redis在2024年改为RSALv2和SSPL，进一步限制云厂商的盈利模式。
-
云厂商对反云许可证的应对策略包括Fork开源项目以避免商业限制。
-
国内云厂商如阿里云和腾讯云在开源许可证策略上表现谨慎，倾向于支持宽松许可证以促进合作。
延伸问答
反云许可证的主要目的是什么？
反云许可证旨在限制云厂商利用开源软件获利而不回馈社区。
AGPL许可证与传统GPL的主要区别是什么？
AGPL要求在网络服务中提供修改后的程序源码，而传统GPL只在软件分发时触发披露义务。
MongoDB的SSPL许可证有什么特别之处？
SSPL要求云厂商在提供服务时披露所有相关的服务源代码，触发条件比AGPL更宽松。
Elastic的ELv2许可证主要限制了什么？
ELv2禁止将软件作为托管服务提供给第三方，旨在保护Elastic的商业利益。
HashiCorp的BUSL许可证有什么独特之处？
BUSL设定了一个未来的开源日期，允许在此之前的非竞争性使用，但禁止商业竞争。
国内云厂商对反云许可证的态度如何？
国内云厂商如阿里云和腾讯云在开源许可证策略上表现谨慎，倾向于支持宽松许可证以促进合作。
