强互惠许可证分不到云收入，它买的是谈判筹码

改证宣言之下：互惠条款真正能改变什么？

Bergius 把默认许可从 MIT 换成 EUPL-1.2，究竟买到了什么谈判能力？这是读懂那篇宣言唯一需要回答的问题。2026 年 9 月 5 日，芬兰开发者 Henri Bergius 发表了一篇标题叫 I changed my license 的博客，宣布了这次换证，理由只有一句：EUPL 是一份 closes the SaaS loophole 的强互惠许可证，无论软件以什么方式分发，都要求互惠授权。Bergius

这句话里藏着两个词，恰好是衡量"买到什么"的标尺。SaaS loophole（SaaS 漏洞）指云厂商把开源软件做成托管服务赚钱、却不必回馈源码这件事，机制下一节展开。强互惠许可证（strong copyleft）要放在许可证光谱上看：最宽松的一档叫 permissive（宽松许可），MIT、Apache 2.0 属于这一类，基本是"随便用，别告我就行"；中间是弱互惠，代表是 LGPL，要求修改过的部分保持开放，但允许闭源代码和它链接；最紧的一档就是强互惠，代表是 GPL 和 EUPL，只要你的作品基于它衍生而成，整个衍生作品（derivative work，基于原作品修改或组合而成的作品）都必须以同样互惠的条款公开源码。Bergius 的选择，是从最宽松的一档直接跳到最紧的一档。他本人的许可史说明，这一步是第三次站队，不是一时冲动。

Midgard 时期他用 LGPLv2，因为那是个 web 框架，"使用弱互惠感觉是对的"；2011 年前后他认真转向 JavaScript 生态，换成 MIT，理由是 NPM 生态喜欢"互操作简单、不带钩子"的许可；2026 年他把默认许可切回强互惠。同一个作者，从弱互惠走到宽松，再走回强互惠，三次选择都画在这条时间线上：

而且他不是一切照单全收，这个灰度处理本身也是回答问题的证据。老项目 NoFlo 保留 MIT，理由是它已经有大量第三方贡献；只有 NoFlo UI 的重写分支和四个新项目（reticulum-js、dacar、signalk-energy-predictor、offshore-blogging-system）采用 EUPL-1.2。已经积累社区贡献的项目，改证代价更高，作者不会轻举妄动，谈判能力只部署在新项目上。Bergius

那么，这份宣言到底买到了什么？直觉答案通常是"向云厂商收租"：AWS 把我的数据库做成托管服务赚钱，我换一份强互惠许可，就能分一杯羹。这个直觉是错的，而且错得有教育意义。

互惠义务附着在版权之上，而版权只覆盖代码和基于代码的衍生作品。云厂商赚的钱，大头来自运维、集成、可用性这些服务能力，都不在版权覆盖面内。芬兰法律学者 Pessi Honkasalo 在 2009 年引用 Kulmala 2003 的一句话把这件事说透了：SaaS 的赚钱逻辑（earning logic）不建立在制作和管理副本之上，而建立在控制服务访问之上。你花钱买的是"随时能用这个服务"，不是"拿到一份程序副本"，版权法管的恰恰是后者。既然服务收入本来就不在版权覆盖面里，互惠条款自然够不着它。Honkasalo

Bergius 的姿态也不是空话。EUPL-1.2 的官方正文里，Article 1 把"分发或传播"定义得非常宽：出售、赠送、出租、传播、传输或以其他方式提供作品副本，都算；同时还补了一句：向任何其他自然人或法人"提供核心功能访问"（providing access to its essential functionalities）也算传播。欧委会门户为此专门标注了一行元数据：EUPL covers SaaS / network distribution，EUPL 覆盖 SaaS 与网络分发。EUPL-1.2

但条款能覆盖 SaaS，和条款能给作者带来收入，是两码事。强互惠许可证真正改变的不是收入分配，而是对方的退出成本：面对一份强互惠许可，云厂商只剩四个退出选项，公开修改并回馈源码、购买商业许可、停留在未修改的旧版本上、另起分支（fork，从某个版本把代码复制出去独立维护一个新项目）。许可证能做的，只是让这四个选项之间的算账结果发生变化。理解了"互惠义务够不着服务收入"这个前提，下一节的问题是：传统 copyleft 为什么管不到云服务？

为什么传统开源许可证管不到云服务？

答案是触发点。传统 copyleft（互惠版权，要求衍生作品以同样条款开放源码的许可机制）的互惠义务有一个激活条件：你必须"分发副本"给他人，义务才生效；只在服务器上跑修改版、只在内部使用，什么都不用公开。这个设计在软件以光盘和安装包流通的年代没有问题，但 SaaS（软件即服务，把软件跑在云端、用户通过网络使用）改变了流通方式，触发点就落空了。

Honkasalo 在 2009 年系统论述了学界此前已提到的 ASP loophole（也叫 SaaS loophole）。他的定义是：服务化场景下不发生版权法意义上的公开传播，因为"交互只通过网络发生，不转移任何副本"（the interaction happens only over a network, with no transfer of a copy）。于是 GPL 允许你修改程序、把它公开挂在服务器上，却不用发布源码。Honkasalo

把这条缝隙画出来，大概是下图的样子：

图注：左栏是 SaaS 模式，用户通过网络远程使用服务端的修改版程序，没有取得任何程序副本，GPL 的分发义务没有触发（红 ✗）；右栏是传统分发，用户拿到副本，copyleft 义务随之适用（绿 ✓）。底部总结了一句话：服务化使用绕开了 GPL 所依赖的分发触发点。这是概念示意图，图里的 GPL 不指向具体版本，也不承载 AGPL §13 的条款内容。Honkasalo

Honkasalo 对 GNU 许可家族的另一个贡献，是一套至今通用的三档互惠分类，它精确标出了漏洞的位置。第一档标准互惠（standard reciprocity），LGPL 为代表，只要求修改部分保持条款，不拖累组合的新代码；第二档强互惠（strong reciprocity），GPL 为代表，任何改编和组合都必须保持条款，但仍然以分发为触发点；第三档网络互惠（network reciprocity），AGPL 为代表，把"通过网络使用"本身当成触发。漏洞就藏在第二档和第三档之间的缝隙：GPL 的互惠足够强，但它的触发点够不着网络服务。

反常之处在于，这个缝隙不是没人看见，而是堵它的成本在当时被认为太高。Honkasalo 记录，GPLv3 草案第 1、2 稿里曾有一个 clause 7b4，本意正是给网络使用加源码公开义务；但评论者抱怨合规管理成本过高，FSF（Free Software Foundation，自由软件基金会）最终退缩，没有把它写进 GPLv3，而是把网络触发单独做成了一份新许可证：AGPLv3。它于 2007 年 11 月定稿，2008 年 3 月 3 日获 OSI 批准。这个"被正式批准"的状态请记住，后面 SSPL 的对照会用到。AGPLv3

所以 SaaS loophole 是版权法结构性的洞，不是哪份许可证写得粗心。要堵它，只能改触发点。这就是 AGPL 与 EUPL 各自在做的事。

AGPL 与 EUPL：各自把什么拉进了触发条件？

第一代对策就是重写触发点。AGPLv3 的 §13 是标准模板：如果你修改了程序，修改版必须显著地向所有通过网络远程与它交互的用户（前提是你的版本支持这种交互）提供获取对应源码的机会，免费、从网络服务器取。触发词是"远程网络交互"（interacting remotely through a computer network），而且限定在修改版上，纯上游使用不触发。AGPLv3

判断标准是设计意图。FSF 的 FAQ 解释：判据是程序是否"被显式设计为通过网络接受用户请求并发送响应"（expressly designed to accept user requests and send responses over a network），所以 web 服务器、在线游戏服务器算；用户只是通过 SSH 登录上去跑一个本来没打算联网的程序，不算。这是一条程序员视角的条款：它读的是程序的网络协议设计。

EUPL-1.2 的 Article 1 换了另一套措辞。它把"分发或传播"定义得很宽，并在其中加入一句：向任何其他自然人或法人"提供其核心功能访问"也算传播。EUPL-1.2

这是一条产品视角的条款：它不问你程序的协议设计，只问用户能不能用到核心功能。两条措辞都堵住了同一个洞，但触发点、举证路径、与 GPLv3 的关系全都不一样：

需要说明的是，"程序员视角 vs 产品视角"这个对照是基于两份原文措辞的归纳，条文本身没有明示继承关系；但两条条款共享同一个思路，即把触发点从"副本转移"挪到"功能访问"。可将二者视为针对同一漏洞的两种条文路径。

两条路径都在 OSI 承认的边界之内，是"堵洞"的第一代正统答案。但条款写出来了，不等于条款在组合使用中无懈可击。EUPL 的 Article 5 留了一扇门，这扇门通向强互惠的第一条边界。

强互惠的边界：EUPL 的出口歧义，SSPL 的越线拒认

EUPL 的 Article 5 有一个兼容出口（compatibility clause）：如果衍生作品同时基于 EUPL 作品和另一份兼容许可证下的作品，可以按那份兼容许可再许可；当两边义务冲突时，兼容许可的义务优先（compatible prevails）。附录的兼容清单里，GPLv2、GPLv3、AGPLv3、MPL、LGPL 都在列。EUPL-1.2

这个出口本来是为了互操作方便，但它开了一扇后门。把整条路径画出来：

漏洞的核心是：EUPL 工作与 GPLv3 工作合并成衍生作品后，被许可人（Licensee）可以主张"按 GPLv3 再许可"，再援引 Article 5 让 GPLv3 优先。而 GPLv3 没有网络触发条款，绕了一圈，SaaS 覆盖失效。

这条路径 2025 年底在 Hacker News 上被公开讨论，摆到了欧委会面前。欧委会的回应值得注意：它没有说"你们读错了"，而是发布了一份讨论稿，承认条款需要澄清。这份 2026 年 3 月发布的讨论稿由欧委会 EUPL 的 license steward（许可管家）Patrice-Emmanuel Schmitz 执笔。欧委会的立场是：SaaS 覆盖仍是核心，兼容出口不该吞掉它；但条款表述确实给了"自愿换证绕开 EUPL"的空间。拟议中的 EUPL-1.3 修订因此给 Article 5 加了两道硬约束：其一，再许可只在"兼容许可本身要求这么做"时才被允许（in so far these terms impose to do so），堵死自愿换证；其二，EUPL 自己的传播定义与权利范围必须凌驾于任何兼容许可之上。预期发布时间是 probably in early 2027，注意这个 probably，这是欧委会自己的限定语，不是承诺。EUPL 澄清

这件事最有价值的不是修订本身，而是它的存在本身说明：一份许可证的官方定位（"EUPL covers SaaS"）和它在组合使用中能否兑现，是两回事。法律威慑不等于已验证的确定性。欧委会还明确说，它不能替 FSF 表态 GPLv3 是否接受这个解读。官方立场尚且如此，条款的含糊地带只会更大。

强互惠的另一条边界在条款外部：如果把触发条款推到极限会怎样？SSPL（Server Side Public License，服务端公共许可）就是答案。MongoDB 是 SSPL 的发明者，2018 年底把 SSPL v2 提交给 OSI 评审，2019 年 3 月又撤回，理由是支持 OSI 批准的社区共识尚不存在。它的 §13 要求：只要你把程序作为服务提供给第三方，就必须把整套服务源码，包括管理软件、监控软件、备份软件、主机编排软件，都通过网络公开。这个范围远远超出"修改版源码"，把服务栈里所有第三方软件都拖了进来。2021 年 1 月 19 日，OSI（Open Source Initiative，开源促进会，维护开源定义的组织）董事会发布声明，把 SSPL 定性为 fauxpen source（假开源），点名 Elastic 的措辞违反 OSD（Open Source Definition，开源定义）第 6 条，并说把 SSPL 软件称为开源是"deception, plain and simple"，不折不扣的欺骗。OSI

这条边界的意义在于对照：AGPL 的网络触发没有越过 OSD 红线，所以被批准；SSPL 把触发范围从"修改版"扩张到"整个服务栈"，越线了，于是连"开源"的名分都丢了。为堵洞把触发条款推到极限，反而失去了这个武器最有价值的部分。

还有一条完全不碰触发条款的替代路径，叫 BSL（Business Source License，商业源码许可）。它不问你"是否把功能作为服务提供"，只问"是否在生产环境使用"：源码一直公开，非生产使用免费，生产使用需要商业许可，四年后整体切换到 GPL 系许可证。MariaDB 是 BSL 的发明者，并直白地在许可证正文里写明"这不是开源许可"；HashiCorp 在 2023 年把 Terraform 等产品从 MPL 2.0 切到 BSL 1.1。这条路避开了与 OSI 的正面对撞，代价是同样放弃"开源"名分。BSL

一边是条文中留有歧义的 EUPL，一边是越线被拒认的 SSPL，还有一条主动认输的 BSL。既然如此，为什么 Elastic 和 Redis 这些工业级项目，还要选 SSPL？下一章用三次真实的改证来回答。

MongoDB、Elastic、Redis 三次改证，究竟换来了什么？

三个改证事件本身先摆上桌：

以 Elastic 一节为主证据讲透。2021 年 1 月 14 日，Elastic 创始人 Shay Banon 在官方博客宣布：Elasticsearch 与 Kibana 从 Apache 2.0 转为 SSPL 与 Elastic License 双许可，用户可在两者间选择，覆盖所有维护中的分支，在 7.11 发布前生效。动机的原话是：限制云服务商在不回馈的情况下把 Elasticsearch 和 Kibana 作为服务提供（restricting cloud service providers from offering Elasticsearch and Kibana as a service without contributing back）。Elastic 2021

这段措辞还有一个值得单独拎出来的细节：它点名了 Amazon Elasticsearch Service 作为目标。Elastic 自己把 SSPL 描述为 MongoDB 发明的 source-available（源码可得）许可，并自评它比 Elastic License 更宽松。这个"更宽松"的自评，和几天后 OSI 那句"不折不扣的欺骗"摆在一起，是整次事件中张力最强的对照。Elastic 2021

2024 年 3 月 20 日，同一剧本换了主演和台词。Redis 公司宣布从 Redis 7.4 起采用 RSALv2 与 SSPLv1 双许可，BSD-3-Clause 停用。公告里那句"云厂商商品化了 Redis 的投资和它的开源社区"（cloud providers commoditize Redis' investments and its open source community），与本专题的主线几乎逐字吻合。而它的 FAQ 比 Elastic 走得更远，直接承认：RSALv2 和 SSPL 都不是 OSI 批准的许可，并且按照 OSI 的定义，Redis 不再是开源软件。这是改证方对自己身份转变最直白的一次承认。Redis 2024

Redis 的改证还有一个关键边界：不溯及既往。7.2 及之前的版本继续留在 BSD 下，可以无限期使用；安全补丁也只会回填到 Redis Community Edition 9.0 发布之前。这意味着旧版本成了对手的免费弹药：分叉者不需要任何授权，直接从 7.2.4 切出去就行。Redis 2024

把三次改证放到一起看，共性很清楚：改证方想买的是"限制云厂商白嫖"，可以理解为收租的替代品。但实际换来的结局只有三类：商业许可（Microsoft 与 Redis 达成协议，Redis 的公告里附了 Microsoft 高管的背书引语，而 AWS 与 Google Cloud 当时没有签）、云厂商的替代实现、以及社区分叉的威胁。三种结局没有一种叫"分成"。武器开火之后，市场反应不归你管。那两次分叉为什么能活下来？这是检验"谈判筹码"成色的地方。

为什么 OpenSearch 和 Valkey 活下来了？

Elastic 改证后 7 天，2021 年 1 月 21 日，AWS 宣布 fork 出 Apache 2.0 许可的 Elasticsearch 与 Kibana，基线是 7.10，也就是最后一个 Apache 2.0 版本。AWS 把 Elastic 对 SSPL"自由开放"的表述定性为 misleading and wrong（误导且错误），称 SSPL 是"一种伪装成开源许可的非开源许可"，并搬出 Fedora 社区"把 SSPL 视为自由或开源，会给整个 FOSS 生态投下阴影"的判断来背书；同时承诺 Amazon ES 现有 18 个版本不受影响，未来版本由新 fork 驱动并保持客户端兼容。AWS OpenSearch

Redis 改证后 8 天，2024 年 3 月 28 日，Linux Foundation 宣布托管 Valkey，fork 基线是 Redis 7.2.4，BSD-3-Clause。两次分叉相隔三年，模式内部却有一个清晰的分野：

关键贡献者是分叉的胜负手。Valkey 的发起人是 Madelyn Olson，AWS 的 principal engineer，之前是 Redis core team 的成员，干了四年。她在个人 GitHub 账号上建了仓库。消息传开时，她说大家都想着"我们不会去参与那个新许可证"，于是她挨个去问要不要来这边、把原来的团队聚起来，现维护者几乎当场答应。Linux Foundation 的 CTO 把 Valkey 存在的理由说得很明白：项目放在基金会而不是单家公司手里，意味着社区驱动，不会有"打破信任的突然改证"（surprise license changes that break trust）。Valkey

反过来看 Microsoft：它是唯一没有参与 Valkey fork 的顶级云厂商，因为它已经和 Redis 签了商业协议。付费和分叉是同一枚硬币的两面：改证方给云厂商留下的四个退出选项里，有人选了购买商业许可，有人选了另起分支。Redis 2024

现在回到 Bergius。他 2026 年选择 EUPL-1.2 时，面对的就是 OpenSearch 和 Valkey 这种反制的可能性。他自己说过一句话，可以作为整篇的注脚：open source 阵营赢了辩论，但企业和亿万富翁赢了钱。他更完整的表述是：我们赢了辩论，却几乎没有为用户或开发者赢到什么；我们的努力只是让大公司造东西更便宜，让亿万富翁变成万亿富翁。Bergius

把话说透：强互惠许可证不是收益机器，是议价装置。它的全部作用是改变对方的退出成本。如果你的项目像 Redis、Elasticsearch 那样拥有不可替代的生态势能，云厂商重写或分叉的成本高于合作成本，网络触发条款才有分量，对方才会回到谈判桌。如果没有这种势能，换证只会让你丢掉采用者，而大厂造一个兼容实现、或者 fork 一份不带 EUPL 的版本，成本低得很。判断一份强互惠许可对你是否有利，只需要问两个问题：你能否承受采用下降？别人重写或分叉你的项目的成本，是否真的高于与你合作？许可证买不来收入，它只买谈判筹码，而筹码的成色，由你的生态不可替代性决定。

参考文献

本专题引用的核心资料如下，建议深入学习时阅读原文：

1. I changed my license (Henri Bergius blog) — https://bergie.iki.fi/blog/eupl/
2. European Union Public Licence v1.2 — Official Text & FAQ (Interoperable Europe) — https://interoperable-europe.ec.europa.eu/licence/european-union-public-licence-version-12-eupl
3. Clarifying the EUPL Compatibility Clause (Interoperable Europe Discussion) — https://interoperable-europe.ec.europa.eu/collection/eupl/discussion/clarifying-eupl-compatibility-clause
4. GNU AGPL v3 — Section 13 (Remote Network Interaction) (OSI mirror) — https://opensource.org/licenses/AGPL-3.0
5. The SSPL is Not an Open Source License (OSI Board statement) — https://opensource.org/blog/the-sspl-is-not-an-open-source-license
6. Doubling down on open, Part II (Elastic license change blog) — https://www.elastic.co/blog/licensing-change
7. Stepping up for a truly open source Elasticsearch (AWS Open Source Blog) — https://aws.amazon.com/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch/
8. Redis Adopts Dual Source-Available Licensing (Redis Inc.) — https://redis.io/blog/redis-adopts-dual-source-available-licensing/
9. Why AWS, Google and Oracle are backing the Valkey Redis fork (TechCrunch) — https://techcrunch.com/2024/03/31/why-aws-google-and-oracle-are-backing-the-valkey-redis-fork/
10. Reciprocity under the GNU General Public Licenses (Pessi Honkasalo, NJCL 2009#1) — https://journals.aau.dk/index.php/NJCL/article/download/3022/2550/10348
11. Business Source License 1.1 — MariaDB official text & FAQ — https://mariadb.com/bsl11/