开源项目更改许可证的时候，都大喊是云厂商逼的。但真的只是这样吗？

开源软件作者或者背后的公司修改项目的开源许可证，甚至修改为 source available 许可证的事情，近几年已经发生了很多次，反反复复修改好几次的也屡见不鲜：   

• 2024年4月3日，Zabbix 官方宣布，Zabbix7.0（即将发布的LTS版本）将在 AGPLv3 协议下发布。Zabbix 是一个企业级分布式开源监控解决方案，自2001年以来的所有主要和次要版本均在 GPLv2 许可下发布。公告称，此次许可证的变更不会阻止 Zabbix 用户使用 Zabbix 软件。唯一的区别是，在 AGPLv3 许可证下如果用户修改源代码并通过分发或网络提供给他人，则必须共享新的源代码。

• 2024年3月20日，Redis 商业公司 CEO Rowan Trollope 宣布，Redis 将从 BSD3-Clause 许可证过渡到双重许可证模式，包括 RSALv2 和 SSPLv1。这一变化的影响将从 Redisv7.4 版本开始，贯穿到未来所有的 Redis 发布版本。

• 2021年，Elastic 公司的 Elasticsearch 和 Kibana 这两个开源项目都更改了开源协议，从7.11版本开始，由之前的 Apache2.0 许可证调整成 SSPL 与 ElasticLicense 双许可。

• 此前，2016年7月，Facebook 在其开源项目 React 的开源协议 BSD 中附加了专利条款，以降低 Facebook 的专利诉讼风险；2018年9月，数据库制造商 Redis Labs 宣布将其 Redis 模块的许可协议由 AGPL v3 变更为 Apache v2  与 Commons Clause 相结合的许可协议，以限制 Redis  相关软件的销售；2018年10月，MongoDB 宣布其开源许可协议从 AGPL v3 切换到 Server Side Public License (SSPL)；开源数据库，比如 CockroachDB、Confluent、Elastic 、MongoDB、RedisLabs、TimescaleDB，也都更换过许可证。

• 而2018年 MongoDB 首席执行官戴夫·伊蒂切里亚（Dev Ittycheria）在宣布更换许可证时特别提到了云服务提供商。他声称，这些公司简直就是在考验 AGPL 的边界：一方面受益于别人的工作成果，另一方面却没有共享其代码，这也是目前所有开源项目在更改许可证时候，提及最多的原因。

联通云基础技术研发总经理 钟忻

Redis 是一家经过多轮融资的商业公司，此举可能是想借鉴 MongoDB 的经验，自 MongoDB 将证书改为 SSPL 以来，收入大幅增长，股价到达了352美元，超过了上市时的10倍。

但 Redis 变更许可的时间比 MongoDB 晚了好几年，而且社区贡献者也更多。现在已经有很多 Redis 的分叉项目，社区的原贡献者也会更多的参与分叉项目的研发，将来也许会有更开放的替代品崛起。

而且有实力的云厂商也早就推出了 Redis 的替代产品，社区许可的改变，也将促使更多的云厂商加大对自主可控的 Redis 替代产品的研发投入力度。

以 Redis 为例可以看到，开源产品更改使用许可也许是未来一段时间的趋势，其意图是通过更改开源许可，增加商业收入，避免被云厂商坐收渔翁之利。但是如何构建好项目的护城河，能达到既保持生态独大，又增加商业收入，存在一定不确定性，需进一步观察。

蚂蚁开源办公室负责人 边思康

法律上来说，Redis 修改 license 合理，但在“道德”或者其他层面也许存在争议，我们也的确看到 Redis 社区很快出现了分裂，部分 Redis 的贡献者 fork 出了新项目 Valkey，而 AWS，Google，Oracle 等公司也在支持相应的社区分叉。这基本是 Terraform vs OpenTofu 的重演。

那么，为什么这个修改还是发生了呢？

只能说是潜在的收益，被判断大过了社区分裂的成本。

开源项目协议修改的共性思维是一种被称为 bait and swtich（诱导转向）的设计思路，即首先通过宽松的许可证在一个新的业务领域快速构建社区，之后通过修改许可证限制的方式，形成产品 serving 服务形态所需要的关键能力壁垒，并从法律层面保护自身提供的业务能力不会被轻易复制。如 Redis Inc 针对这件事情发布了对于修改 license 的解释，其中 “allow us to sustainably provide permissive use of our source code” （可持续性）以及后半段 “The majority of Redis' commercial sales are channeled through the largest cloud service providers, who commoditized Redis' investments and its OSS community” 都将修改目的直接对准了云厂商的托管竞争影响到了公司「商业可持续」的维护相关社区，通过 license 的变更来降低竞争压力，潜在实现更好的商业盈利。

另外值得注意的是，bait and switch 类型的 license 修改，在 Redis，Elastic 等案例中潜在可被视为一种防御措施。然而，这当中，根据修改 license 的时间早晚以及项目实际控制权的归属，可能会有「可能是有意诱导」的情况发生。比如，从2020年1月开始的中间件项目 Airbyte 在开源后仅仅三年的时间后，于2023年修改了 license，考虑到其业务形态，相关的 license 修改其实有可能是一种战略层面有意为之，为公司积累核心资产形成商业壁垒的动作。随着目前更多公司 license 进行修改，这种「有意为之」的进攻型用法也许会在未来变多。

上海交通大学电信学院长聘教授 金耀辉

我认为开源软件项目调整许可证的几个原因：首先，调整许可证可能是项目方寻求盈利的一种策略，他们可能在探索如何通过开源项目实现商业化。此外，这种调整有时也是为了应对云服务商的竞争，通过特定的许可证如 AGPL 和 SSPL，来限制竞争对手在不同环境下使用代码，同时保护项目的知识产权。比如 AGPL 要求任何衍生作品也必须开源，而 SSPL 则对在线使用的代码设有一定限制。

许可证的调整带来的影响也是多方面的，比如：社区内部可能会因为对项目发展方向的不同理解而产生分歧。这种许可证的变化，无疑会对整个生态系统产生广泛影响。从企业用户的角度看，他们可能面临增加的使用成本和需要关注的合规性问题，这需要他们在利弊之间做出权衡。同时，开源社区也可能因观点不同而分裂，有的贡献者可能会选择离开。还有一些公司可能会因为这些变化而放弃使用某些软件，转而寻找其他的替代品。

不过，个人认为这些变化也将带来了积极的一面。例如，它们有助于保护开源社区的长期可持续发展，并鼓励公平回馈贡献，也有助于维护开源项目的影响力和价值。此外，这还可能推动新的商业模式的出现，以及促进开源许可证的多样性和创新。

神策数据首席架构师 张铎

在我看来，目前开源软件开发者（包括个人和公司），在云时代到来之后确实都遇到了极大的困境。

在云时代出现之前，开源软件开发者，或者说主要开发者，和其他用开源软件做商业化的人或者公司，基本是在同一个起跑线上竞争的，反正主要就是卖拷贝，原作者优势可能还更大。

但到了云时代，云厂商对于开发者是真正的降维打击。云厂商只要把你的软件拿来在云上部署然后售卖，就可以产生巨大的收益，这种模式比之前卖拷贝的效率高了几个数量级。但这种收益，是不会和其他开发者共享的。并且由于云本身其实是个收租的生意，其他开发者没有云厂商的体量和资源，基本也无法按照云的模式来售卖。即便真的自己做云服务，也由于规模效应和其他产品的不完备，很难和云厂商竞争。所以，所谓云厂商只索取不贡献，其实并没有切中要害。即便云厂商把改动都回馈到开源社区，结局还是原作者赚的钱只是云厂商的零头甚至零头都不到，这种模式怎么可能维持的下去呢？

所以，在没有找到一个合适的收益分享的模式，以及确定开源软件作者应该分享多大收益的前提下，开源软件作者和云厂商的斗争还是会继续持续下去的。这块最终的解决方案 ，说实话我目前我也想不到，但这些修改许可证的公司，本身也是在进行各种尝试吧，不应该只是从开源精神和许可证的角度进行批判，还是得理解他们的困境，期望最终我们能找到一个合适的解法。

阿里云开源法务专家 付钦伟

自由/开源运动至今形成了相对稳定的行为范式，近几年多起开源软件变更许可事件引起了广泛讨论，除了软件使用广之外，还在于：要么是超出行为范式预期，要么具有话题性的冲突点。虽然 Redis Labs 变更许可协议不存在法律问题，但开源有其内在的精神追求和情怀，其外在表现是大众对于“开源”的心理预期。Redis Labs 变更许可协议行为，不符合大众对于开源协作的预期。

虽然 Redis Labs 将矛头指向云厂商，本质上是融资之后对盈利的焦虑，核心还是商业策略。所谓不贡献开源的云厂商，不仅为 Redis 贡献了大量代码，还有核心维护成员，在 Redis 最近3个大 release 中，来自亚太区的贡献占比超过60%，过去7年里阿里云就向 Redis 社区贡献了数百项功能。MongoDB 也和阿里云于2019年达成战略合作，并于2023年宣布将与阿里云的全球战略合作伙伴关系延长4年，阿里云的客户将能够在全球范围内使用由阿里云数据中心托管的 MongoDB 服务。营造云与开源的对立无益于开源的发展，也不是对云与开源关系的恰当描述。

本次 Redis 协议变更争议，并非因其商业化本身（其商业化动作很早就开始了）。

开源不排斥商业化，开源商业化是个颇具挑战的命题，同时也是开源生命力之所在。我们要包容的看待个人、初创企业以及商业公司的商业化探索。对于开源初创企业来说，如何在尊重开源精神、保持开源预期延续性的前提下，构建自己的商业化之路，避免开源与闭源的对立；对于包括云厂商在内的商业公司，如何与开源项目共赢，在实现价值的同时保持价值的输出，如持续的代码贡献、社区支持、多样化的开源生态等，避免商业化对开源预期造成冲击，是任何企业都需要认真思考的问题。

在开源这个基于共识和协作的世界里，无论是商业策略还是纯粹的开源活动，都应当始终锚定一个点：尊重共识、管理预期。开源本身又是一个包容的社会，任何事情都要从尊重开源精神出发，避免对 “开源预期” 的破坏，这也是我从很多“社区事故”中获得的感悟。  

转载自 | 木兰开源社区 

作者 | mulan 

编辑 | 王梦玉

相关阅读 | Related Reading

定档 11.2-3，COSCon'24 第九届中国开源年会暨开源社十周年嘉年华正式启动！

开源人在国际学术会议中的所见所感

开源社简介

开源社（英文名称为“KAIYUANSHE”）成立于 2014 年，是由志愿贡献于开源事业的个人志愿者，依 “贡献、共识、共治” 原则所组成的开源社区。开源社始终维持 “厂商中立、公益、非营利” 的理念，以 “立足中国、贡献全球，推动开源成为新时代的生活方式” 为愿景，以 “开源治理、国际接轨、社区发展、项目孵化” 为使命，旨在共创健康可持续发展的开源生态体系。

开源社积极与支持开源的社区、高校、企业以及政府相关单位紧密合作，同时也是全球开源协议认证组织 - OSI 在中国的首个成员。

自2016年起连续举办中国开源年会（COSCon），持续发布《中国开源年度报告》，联合发起了“中国开源先锋榜”、“中国开源码力榜”等，在海内外产生了广泛的影响力。