AGPL“失效”

懂开源的，没有几个是不知道 GPL 的。

1983年，自由软件之父 RMS（Richard Mattew Stallman）发起 “GNU 计划”，某种意义上可以视为开源的肇始。在 RMS 的哲学中，知识产权是一种社会赋权，权利人应该被允许通过契约的方式，自由转让软件权利，如复制、修改、再发布的权利。

这就是所谓的 “Copyleft” 。为了支撑这一概念的落地，1989年 RMS 与一群律师起草了世界上第一个开源软件协议 —— GNU 通用公共协议证书（GNU General Public License，也就是 GPL），到现在 GPL 依旧是开源世界最流行的开源许可证之一。

总的来说，从相对于“版权（Copyright）”的“Copyleft”，到整个自由软件运动，RMS 的初衷就是——反对专有软件。这也为之后开源与其他势力的不对付埋下了伏笔。Web 和云计算崛起之后，对开源世界带来的冲击而引发的一系列摩擦就是一个例证。

面对新模式的侵袭，开源世界并没有坐以待毙，AGPL（GNU Affero General Public License）就是为此诞生的。在 AGPL 更严苛的限制条件下，各厂商也的确开始忌惮。

但是，事与愿违。AGPL 并没有被多数开源公司视为有效途径，甚至开始走向边缘化。甚至连 GNU 官方也表示，AGPL 并没有解决“SaaS 替代品（SaaSS，Service as a Software Substitute）”的问题。

AGPL 真的“失效”了吗？

01 一次“查漏补缺”

诞生在上个世纪的 GPL 没有想到的是，软件的分发模式会在21世纪发生翻天覆地的变化。

GPL 主要是针对以微软为代表的传统软件分发商业模式，其约束生效的前提是“发布”软件，也就是说，必须通过互联网或光盘 release 软件，才会受到 GPL 的限制（也不算真的限制，就是需要明示地附上相关源代码，且你分发的软件也必须是 GPL 的）。

随着以 Google 为代表的网络服务提供者（Application Service Provider）出现，这一条款就不再适用了。因为他们不分发软件！Google 的商业模式是为客户提供网络服务，不分发就不需要开源他的私有解决方案，基本就等于不受约束。

大家将 GPL 的这个漏洞称之为 Web Service Loopwhole。

同理，SaaS（Software as a Service，软件即服务）也是一样。SaaS 在云上提供软件服务，也是走了不“分发”的漏洞。云计算公司可以不向社区共享更改，让他们获得了某种优势。比如，亚马逊的 Aurora MySQL 就是基于 MySQL 。

于是，一些自由软件理念者开始推动修改 GPL 授权条款的内容。

2002年，在自由软件基金会 (Free Software Foundation, FSF) 的同意下，Affero 公司基于 GPLv2 发布了 AGPL 的最初版本。随着 GPLv3 在2007年发行，AGPL 也重新在 GPLv3 的基础上，更新了 AGPLv3。现在，我们说起的 AGPL，指的就是这一版本。

AGPL 可以说是对 GPL 的一次“查漏补缺”。AGPL 继承了 GPL 所有条款，并在此基础上增加了一条：如果其许可下的软件与用户通过网络进行交互，那么就需要提供源代码给用户，所有的修改也同样要提供给用户。

本质上说，AGPL 就是针对基于 web 的应用程序的。在一开始，Google 等网络服务公司是其主要的观察对象，然后随着云计算崛起，亚马逊等云厂商又成为了新的对象，用于确保对开放源代码 SaaS 应用代码的修改会反馈给自由软件社区。

如果你认为自由软件不能赚钱，那就错了。

Open Core 模式就是一种开源商业模式。简单说来，就是开源一个免费的社区版，而对商业版本闭源收费。

在 Open Core 模式下，AGPL 完全可行。比如说你开发了一套商城，如果以 GPL 开源，竞争对手就可以直接拿走程序提供 SaaS 服务；而在 AGPL 下，部署了相关程序但是不想开源的，就需要购买商业版权。

2018年11月，因为不想让云提供商白白获利， Neo4j 正式走向 Open Core 模式，宣布从 Neo4j 3.5版本开始，企业版仅在商业许可下提供，不再在 Github 上提供源代码，而 Neo4j 社区版将在 AGPLv3 下继续开源。

AGPL 的效力是显而易见的，但是依旧遭到了“背叛”。

同样是在2018年，Redis Labs 将 Redis 模块的许可证从 AGPL 更改为 Apache v2.0 ，并附带 Commons Clause 。其中，Commons Clause 不是开源协议，明令禁止商业：“许可证授予的权利不包括、并且不授予您销售软件的权利。”

Commons Clause 并不是孤例。几乎是在同一时期， MariaDB 公司创建 BSL，这是本质上介于闭源和 Open Core 开源模式的“中间模式”，BSL 中指定级别以下的使用总是完全自由的，超过指定级别的使用需要有商业授权，并且 BSL 保证在某个时间点会变成“真的”开源，这时所有对项目的使用行为都是自由的。 MongoDB 创建 SSPL，比 AGPL 更过分的是，如果你将产品作为服务提供给他人，SSPL 要求公开发布任何修改以及管理层的源代码。

其中，BSL 和 SSPL 都不是开源协议，都没有通过 OSI （Open Source Intiative）的认证。

从开源维度上来讲，放着 AGPL 一个根正苗红的被 OSI 认可的开源许可证不用，这些开源公司为什么要另起炉灶去创建一些不被开源世界所认可的“非开源许可证”呢？

难道是 AGPL 不好使？

02 不讲武德“对抗” AGPL

与其说 AGPL 不好使了，不如说在商业世界里的竞争都是“不讲武德”的。完全从商业角度来看 AGPL 就是完全另一码事了。

首先，AGPL 并不受商业公司待见。

显而易见，AGPL 等强 Copyleft 许可证是带有传染性的，倾向于保守的商业公司天然对 AGPL 存有疑虑，毕竟不谨慎采用 AGPL 就会为公司带来技术外泄的风险。

比如，苹果就不允许 GPL /AGPL 授权的软件出现在应用商店，而谷歌更是以禁止 AGPL 闻名，Mongo DB 之前使用 AGPL 也被美国三大云厂商亚马逊、微软和谷歌排除在其云服务之外。

因为 GPL 一旦授权就无法撤销，而 AGPL 更糟，用户只是使用软件就会触发授权。许多拥有 AGPL 项目的公司都会被大企业要求转而采用更宽松的许可证，因为使用 AGPL 违反了他们公司的政策。

有律师表示，不少企业对 GPL/AGPL 有恐惧心理，担心传染自研代码。

其次，大企业抢蛋糕，管你什么开不开源。

或许是基于对 AGPL 的抗拒心态，又或许是商业世界利益至上，大企业在抢占“蛋糕”时，吃相往往不好看。

文档数据库市场巨大，但因为 Mongo DB 采取 AGPL 授权模式，其他云厂商巨头一直没办法直接使用开源的 MongoDB，但是他们还是想了办法进入这个市场。微软首先推出 Document DB这个产品，采用兼容 MongoDB 的 API 的方式来实现对 MongoDB 的支持。这个产品后来升级成为 Cosmos DB，支持除了 MongoDB 以外的其他一系列开源接口。亚马逊也紧跟其后，推出了 Document DB 服务。

有评论认为，从 MongoDB 推出 SSPL 便知道 AGPL 效果不佳。云服务在众多以 SaaS 模式进行开源商业化的初创公司面前成为了一把双刃剑：客户把数据和计算交给开源公司，而开源公司的服务质量（包括性能、可扩展性和可用性）又取决于云服务商（AWS、阿里或微软等）同时其代码还暴露在公开环境中。那么无论从规模经济还是服务质量来看，后者在基础设施层上天然具有一定优势。

从而，一种不平等产生了：基于 IT 巨头的地位，开源创业公司很难有反抗之力；与此同时，开源越来越离不开商业运作。

在亚马逊用分叉（fork）的方式对付 Elasticsearch 时，他们甚至还发文怒斥 Elasticsearch 的这种行为，称其为“假开源”。另一个例子是 Docker，虽然 Docker 几乎已成为当今容器技术的事实标准，但在更高层次的容器编排生态，谷歌推出的 Kubernetes 占了绝对主导。Docker 实际上并没有从其中获得多少好处。

最后，违反 AGPL 的成本不高，而且维权也很难。

AGPL 作为一个被 OSI 认证的开源协议，肯定是具有法律效力的。但是，你有没有发现企业却很少通过法律诉讼维权？

因为如果弊大于利或者胜负难料，执法成本过高，那么对 AGPL 侵权采取法律行动是没有意义的。

一方面，很多 AGPL 侵权者未必能提供多少令人感兴趣的代码，很可能侵权者的代码很烂，要求对方根据许可证要求披露代码反而是增加自己维护代码的负担。而且，绝大多数 AGPL 侵犯者通常也无法拿出多少钱来进行赔偿。

另一方面，如果你想告一家大公司，那么一起案件的诉讼费就是一笔巨款，况且对方有着强大的经济实力作为后盾，诉讼将会非常长，比如针对 VMware 的侵权诉讼拖了5年之久，还是以原告放弃上诉收场。

此外，AGPL 的侵权行为往往是跨国的，而跨国起诉的难度则更大。

因此，对于 AGPL 违约，大家更多的是从道德层面谴责 —— 享受开源成果，是应该给社区回馈的。

03 自由理想崩塌了吗？

“我有个异端观点，那就是我们过分担忧授权了。尤其是：我认为我们并不需要互惠许可证，不需要像 GPL 之类的许可证，去惩罚拿了开源代码却做闭源开发的人。”

2009年，《大教堂与集市》的作者、开源界领袖式的人物 Eric S. Raymond 在长岛 Linux 用户组聚会上宣称，鉴于开源运动与众不同的运作方式，GPL 许可证已经不再是必要的了。

这撕开了开源世界的一个真相：自由软件与开源软件之间存在裂缝。

AGPL 虽然是开源许可证，但它更重要的身份是：自由软件许可证。AGPL 的焦点是从软件绝对必须 100% 自由的角度出发的，它更符合早期开源项目建立的核心 —— 注重开放性和软件自由性。

但是，随后开发形式被更新了，开源项目的内核也发生了改变。对现在的开源项目来说，自由什么的可能不太重要，开源是为了完成命令，又或者只是为了开放某个软件的一个组件。

从这一维度来说，让 AGPL “失效”的，并不是商业的“围剿”，而可能是理想的崩塌。

其实，AGPL 在商业上，并非完全不可绕过。在 AGPL 的规则中，被要求开源出来的仅仅是修改部分； AGPL 也有很多例外条款，比如以聚合体发布可以闭源。同时，AGPL 也允许做封装，还可以通过标准接口调用，或者使用动态链接把程序的模块相互划分开来，形成独立的文件，以区分代码。很多公司是可以绕过，比如 Google GMS 就可以不开源。

时至今日，依旧有开源公司选择成为 AGPL 的拥趸。

2021年4月，Grafana Labs 公司宣布旗下核心开源项目（Grafana、Grafana Loki 和 Grafana Tempo）的许可证将从 Apache License 2.0 变更为 AGPLv3。Grafana Labs 公司认为这是一种更公平的方式，并且有助于建立更强大的社区。

Grafana Labs CEO Raj Dutt 表示，自己也知道 AGPL 对自家产品的“保护”不能达到像其他许可证（例如SSPL）那种程度，但他认为这已经实现了一定的平衡，这种平衡是 Grafana Labs 公司一直以来的探索 —— 如何在开源和社区的“价值创造”以及商业化策略的“价值获取”之间取得平衡。开源一直以来都是 Grafana Labs 的内核，他相信采用 AGPLv3 可以让社区和用户继续拥有一直以来享有的自由。

2021年6月，ThingsPanel 变更开源授权协议为 AGPLv3。ThingsPanel 表示，Grafana、Loki和Tempo 改用 AGPLv3 许可证的新闻给了其一个新的启示，去进一步平衡商业与开源，以更好地推动 ThingPanel 项目的开展。最大化的开源是 ThingPanel 的最佳选项。

事实上，AGPLv3 协议已经存在并运行了长达 14 年，维基百科还专门有一份列出了 哪些开源项目是采用了 AGPLv3 开源协议的列表。

尽管 Redis Labs 将 Redis 模块从 AGPL 迁移到将 Apache 2.0 与 Commons Clause 相结合的许可证，但是 Redis 作者 antirez 是这样表态的：

“对于我将开发的Redis模块，比如Disque，我会选择AGPL。我们生活在云时代，所以使用新许可证会强制其他SaaS公司重新提交回他们的改进。”

对自由坚守，还是对商业妥协，或许这才是问题的核心。

来源：oschina 作者：lola_chen