大多数公司，都对 AGPL 许可证“敬而远之”
出品 | CSDN（ID：CSDNnews）
AGPL 许可证的设计初衷是弥补某些人认为的 GPL 许可证中的漏洞。GPL 是一种流行的自由软件许可证，可保证任何收到该软件副本的人都有权免费或付费运行、研究、修改和共享该软件。GPL 许可软件的发行商不得对许可所保证的权利施加限制。例如，禁止分发受保密协议约束的软件。许可条款将沿用至衍生作品，而且分发时直接应用于修改后的代码。GPL 旨在确保无论由谁修改或如何修改，软件的所有副本都保持开源。
GPL 的创建在 SaaS 兴起之前，因此该许可证文本仅适用于分发可下载的软件。当有人通过 SaaS 模型分发软件时，二进制文件永远不会分发给最终用户，这意味着该许可条款不适用。因此，SaaS 提供商能够采用 GPL 许可的软件，并使用其他许可条款分发它。对于 GPL的作者（自由软件基金会）来说，SaaS的这个“漏洞”是对自由软件的滥用，因此他们创建了 AGPL 来弥补该漏洞。AGPL 许可证与 GPL 几乎相同，只不过增加了第 13 条，该条款规定如果你允许用户通过网络允访问修改后的软件，则必须向这些用户提供源代码。
13. 远程网络交互；与GNU通用公共许可证一起使用。尽管本许可证还有其他规定，但如果您修改本程序，则您的修改版本必须以某种显而易见的方式向所有通过计算机网络与其远程交互（如果您的版本支持此类交互）的用户提供接收您的版本的相应源代码的机会，您可以通过一些标准或惯用方式提供软件复制，在网络服务器上免费提供相应的源代码。这些相应的源代码应包括根据下段规定纳入 GNU 通用公共许可证第 3 版的任何作品的相应源代码。
尽管本许可证还有其他规定，但您有权利将任何受保护的作品与在 GNU 通用公共许可证第3版下许可的作品链接或结合成一个单一的组合作品，并传递由此产生的作品。本许可证的条款将继续适用于受保护作品的部分，但与之结合的作品将继续受 GN U通用公共许可证第3版的管辖。
上述附加文本的主要问题之一是内容含糊不清。它只规定了 GPL 和 AGPL 许可代码如何协同工作，但没有提及其他许可证。此外，也没有具体说明什么是访问权限，仅指出“通过计算机网络与其远程交互的用户”可以访问源代码。当合并到公司的代码库中时，不清楚哪些其他代码可能会受到许可证的病毒式传播。各个公司担心的是，他们可能会被迫开源原本不打算开源的软件。
AGPL 的限制阻碍了可访问性和采用
对于自由和开源软件，自由软件基金会有一个明确的观点，即所有计算机用户都享有运行、研究、修改和重新分发软件的四种自由。这建立在所有软件都应该免费的道德原则之上。因此，AGPL 等许可证限制了最终用户应用软件的方式。意料之外的结果是阻碍了软件的使用，而非让更多软件开放。谷歌甚至完全禁止在公司内部使用任何 AGPL 许可的软件。
我见过的所有公司都禁止 AGPL。
因为即使在内部使用，它也会像病毒一样传播，最终你可能不得不发布一些你从未预料到的、非常敏感的东西。
允许任何人在任何公司环境中使用 AGPL 代码都是愚蠢的行为。
许多开源用户将 SaaS“漏洞”视为自然地使用开源软件的方式，因为它不会限制软件的使用或分发方式。强迫使用 AGPL 是双输的局面。Reddit 用户 temujin9 写道：“如果所有开源开发人员都坚持使用 AGPL……则最终结果是，各个公司都会避免 AGPL，并编写自己的软件。从为开源贡献的时间来看，由企业资助的开发远超自由职业者，因此会出现大量糟糕的闭源代码，以及一些没有资金支持的 AGPL 项目。因此，如果你相信‘所有软件应该始终是开源的’，那么使用 AGPL 就是违背这一目标，因为使用 AGPL 会导致你的软件成为一种更难访问、更不被广泛接受的开源类型。”
对于 AGPL，企业的反应不是遵守条款并开放更多软件，而是完全退步。最近，Agnostiq 将 Covelent 的许可从 AGPL 更改为 Apache 2.0，主要原因是“确保更广泛的用户社区的可访问性，消除 AGPL 许可施加的障碍”。Agnostiq 首席执行官 Oktay Goktas 表示：“许多 Covalent 用户都表示 AGPL 许可证及其 Copyleft 要求带来了各种困难。迁移到 Apache 消除了 AGPL 施加的限制，并为社区的蓬勃发展做出了贡献。”对于大多数企业来说，AGPL 施加的限制太严格了，无法采用，这严重阻碍了项目获取关注的能力。
AGPL 双重许可漏洞
AGPL 也未能幸免于自身漏洞的影响。根据 AGPL，原作者拥有版权，因此拥有双重商业许可的专有权。他们可以在 AGPL 下以开源的方式发布软件，同时也可以在商业许可下发布 SaaS 版本。Flask 开发者 Armin Ronacher 在 2013 年总结了这一现象：
“AGPL 第 3 版取得了巨大的“成功”，尤其是在初创社区中，他们找到了完美的基础许可证，可获得包含商业许可在内的双重许可。MongoDB、RethinkDB、OpenERP、SugarCRM 以及 WURFL 现在都使用 AGPL 第3版作为双重商业许可的工具。他们可以轻松利用 AGPL 第 3 版实现双重许可，因为原始版权的作者有权使用商业许可，但通过 AGPL 第 3 版获取的源代码本身不会继承该权利。”
—— Armin Ronacher，《Licensing in a Post Copyright World》
这个“漏洞”的问题在于，它允许公司宣传自己是免费且开源的，同时还切断了 SaaS 的竞争。虽然可下载版本是开放的，但 SaaS 版本不需要参与开源协作、创新或竞争。
对企业来说，AGPL 的风险太大
各家公司不敢使用 AGPL 是因为开发人员在 AGPL 许可下组合代码存在一定的风险，因为这将要求他们开源其代码库中原本不打算开源的部分。这限制了用户根据自己的需求调整代码的能力，同时也授予了原始版权所有者专有的商业权利。
各家公司不仅不敢将 AGPL 许可的代码合并到自己的代码库中，而且出于谨慎，许多公司甚至禁止最终用户在公司设备上安装任何 AGPL 许可的代码。这意味着不仅各个代码库会受到影响，而且软件最终用户的采用也存在重大障碍。
并非所有企业都打算开源所有代码。虽然人们对开源的接受度已大大提高，但将 AGPL 强加给用户的结果只会背离开源，导致开放的软件越来越少。
原文链接：https://opencoreventures.com/blog/2023-10-agpl-license-is-a-non-starter-for-most-companies/
推荐阅读：
▶ 拼参数、拼应用、拼落地，大模型时代的 AI 编程何以称强？