制作|开源中国
作者|罗拉_陈
了解开源的人很少不知道GPL。
1983年，自由软件之父RMS推出了GNU项目，从某种意义上可以看作是开源的开始。在RMS的理念中，知识产权是一种社会赋权，应该允许权利人通过合同自由转让软件权利，如复制、修改和再分发的权利。
这就是所谓的“Copyleft”。为了支持这一理念，1989年，RMS和一群律师起草了世界上第一份开源软件协议——GNU通用公共协议证书，GPL至今仍是开源界最流行的开源许可证之一。
总的来说，从相对于“版权”的“Copyleft”到整个自由软件运动，RMS的初衷都是反对专有软件。这也为以后开源和其他势力的对抗埋下了伏笔。而Web和云计算的兴起，对开源世界的冲击所引发的一系列摩擦就是一例。
面对新模式的入侵，开源世界并没有坐视不管，AGPL就是因为这个原因而诞生的。在AGPL更加严格的限制下，制造商们确实开始害怕了。
然而事与愿违。AGPL并没有被大多数开源公司视为有效的方式，甚至开始被边缘化。甚至GNU官员也说AGPL没有解决“SaaS选择”的问题。
AGPL真的“无效”吗？
01 a“检漏和补缺”
上世纪诞生的GPL没有想到的是，软件的分发模式在21世纪将会发生翻天覆地的变化。
GPL主要是针对以微软为代表的传统软件分发商业模式。其约束的前提是“发布”软件，即软件必须通过互联网或光盘发布，才能受到GPL的限制。
随着以谷歌为代表的互联网服务提供商的出现，这一条款不再适用。因为他们不分发软件！谷歌的商业模式是向客户提供网络服务。如果不分发，就不需要开源它的私有解决方案，基本上是无拘无束的。
大家都把GPL Web服务的这个漏洞叫做Loopwhole。
同样，SaaS也是如此。在SaaS云上提供软件服务也是不“分发”的漏洞。云计算公司不能与社区分享变化，这给了他们一个优势。比如亚马逊的Aurora MySQL就是基于MySQL的。
因此，一些自由软件倡导者开始推动修改GPL许可条款的内容。
2002年，在自由软件基金会的同意下，Affero发布了基于GPLv2的AGPL的原始版本。随着2007年GPLv3的发布，AGPL也更新了基于GPLv3的AGPLv3。现在，当我们谈论AGPL时，我们指的是这个版本。
AGP可以说是GPL的一个“查漏补缺”。AGP继承了GPL的所有条款，并在此基础上增加了一条:如果其许可下的软件通过网络与用户进行交互，则需要将源代码提供给用户，所有修改也要提供给用户。
本质上，AGPL的目标是基于网络的应用。起初，谷歌和其他网络服务公司是其主要观察对象。然后，随着云计算的兴起，亚马逊和其他云供应商成为新的目标，以确保开源SaaS应用程序代码的变化将反馈到自由软件社区。
如果你认为自由软件赚不到钱，那你就错了。
开放核心模式是一种开源的商业模式。简单来说，就是开源一个免费的社区版，而对商业版收费闭源。
在开放核心模式下，AGPL是完全可行的。比如你开发一个商城，如果是用GPL开源，竞争对手可以直接拿程序来提供SaaS服务；根据AGPL的规定，那些部署相关程序但不想开源的人需要购买商业版权。
2018年11月，因为不想让云提供商白白盈利，Secondary正式走向开放核心模式，anNeo4junced表示，从Secondary 3.5开始，企业版只在商业许可下可用，源代码是Github上不再可用的Neo4j，而Secondary Community Edition将在AGPLv3下继续开源。
AGPL的有效性是显而易见的，但它仍然被出卖了。
同样在2018年，Redis Labs将Redis模块的许可从AGPL更改为带有Commons条款的Apache v2.0。其中，Commons条款不属于开源协议，明确禁止商业:“许可证授予的权利不包括也不授予您销售软件的权利。”
公地条款并非孤例。几乎与此同时，MariaDB公司创立了BSL，BSL本质上是一种介于闭源和Open Core开源模式之间的“中间模式”。BSL中指定级别以下的使用总是完全免费的，指定级别以上的使用需要商业授权。而且BSL保证在某个时间点成为“真正的”开源，那时项目的所有使用行为都是免费的。MongoDB创造了SSPL，比AGPL更过分。如果您将产品作为服务提供给他人，SSPL要求公开发布任何修改和管理的源代码。
其中BSL和SSPL都不是开源协议，都没有通过OSI的认证。
从开源的角度来看，OSI批准的开源许可植根于AGPL。为什么这些开源公司另起炉灶，制造一些不被开源界认可的“非开源许可证”？
AGPL不工作了吗？
02没有武德“正面交锋”AGPL
与其说AGPL的失败，不如说商业世界的竞争是“没有武德”。从完全商业的角度来看，AGPL是一个完全不同的问题。
首先，AGPL不受商业公司的欢迎。
显然，像AGPL这样的强版权许可会传染，保守的商业公司自然会对AGPL产生怀疑。毕竟，如果不谨慎采用AGPL，将会给公司带来技术泄露的风险。
例如，苹果不允许GPL /AGPL授权的软件出现在应用商店中，而谷歌以禁止AGPL而闻名。Mongo DB此前使用AGPL也被美国三大云厂商亚马逊、微软、谷歌排除在其云服务之外。
因为GPL一旦被授权，就不能撤销，AGPL更糟糕。用户仅使用软件来触发授权。许多拥有AGPL项目的公司会被大型企业要求采用更宽松的许可，因为使用AGPL违反了他们的公司政策。
一些律师表示，许多企业害怕GPL/AGPL，担心感染自主开发的代码。
其次，大公司抢蛋糕，不管你开不开。
也许是因为对AGPL的抵制，也许是因为商业世界的利益至高无上。大公司在抢占“蛋糕”的时候，往往吃得并不好看。
文档数据库市场巨大，但由于MongoDB采用AGPL授权模式，其他云厂商巨头一直无法直接使用开源的Mongo DB，但他们还是设法进入了这个市场。微软首先推出了document DB，这是一款通过采用与MongoDB兼容的API来支持MongoDB的产品。这款产品后来升级为Cosmos DB，支持除MongoDB之外的一系列其他开源接口。亚马逊紧随其后，推出了document DB服务。
一些评论家认为，当SSPL从MongoDB启动时，AGPL是无效的。云服务在很多以SaaS模式开源商业化的初创企业面前成了一把双刃剑:客户把数据和计算交给开源公司，开源公司的服务质量依赖于云服务提供商，他们的代码也暴露在公共环境中。那么，无论从规模经济还是服务质量来看，后者在基础设施层自然都有一定的优势。
于是，一个不平等产生了:基于IT巨头的地位，开源创业公司很难抗拒；与此同时，开源越来越离不开商业运营。
当亚马逊以一分为二的方式处理Elasticsearch时，他们甚至发文声讨Elasticsearch的行为，称其为“伪开源”。再比如Docker。虽然Docker几乎已经成为当今容器技术事实上的标准，但是Google推出的Kubernetes在更高层次的容器布局生态中是绝对占优势的。Docker实际上并没有从中得到多少好处。
最后，侵犯AGPL的成本不高，维权难。
AGPL作为OSI认证的开源协议，必须具有法律效力。但是，你有没有发现，企业很少通过法律诉讼来维权？
对AGPL侵权采取法律行动，如果弊大于利或者结果难以预料，执法成本过高，就没有意义。
一方面，许多AGPL侵权者可能无法提供多少有趣的代码，很可能侵权者的代码非常糟糕。按照许可要求要求对方公开代码，会增加自己代码维护的负担。此外，大多数AGPL违规者通常无法支付太多赔偿。
另一方面，如果要起诉大公司，一个案子的诉讼费是一笔巨款。况且对方有雄厚的资金实力作为后盾，官司会很长。比如对VMware的侵权诉讼，拖了五年，还是以原告放弃上诉告终。
此外，对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宣布其核心开源项目的许可证将从Apache License 2.0改为AGPLv3。Grafana Labs认为，这是一种更公平的方式，有助于建立一个更强大的社区。
Grafana Labs首席执行官Raj Dutt表示，他知道AGPL对自己产品的“保护”无法达到与其他授权相同的水平，但他认为这已经达到了某种平衡，这就是Grafana Labs的不断探索——如何在开源和社区的“价值创造”与商业化策略的“价值获取”之间取得平衡。开源一直是Grafana Labs的核心，他认为AGPLv3的采用将使社区和用户继续享受他们一直享有的自由。
2021年6月，ThingsPanel将开源许可协议改为AGPLv3。ThingPanel表示，Grafana、Loki和Tempo转投AGPLv3许可的消息给了它新的灵感，以进一步平衡商业和开源，从而更好地推动Thingpanel项目。最大化开源是ThingPanel的最佳选择。
事实上，AGPLv3协议已经存在并运行了14年，维基百科也有一个采用AGPLv3开源协议的开源项目列表。
尽管Redis实验室将Redis模块从AGPL移植到了结合了Apache 2.0和Commons子句的许可证上，Redis的作者antirez这样表述:
“对于我将要开发的Redis模块，比如Disque，我会选择AGPL。我们生活在云时代，所以使用新的许可证将迫使其他SaaS公司重新提交他们的改进。”
坚持自由还是妥协商业，或许这才是问题的核心。
