AGPL云服务条款

本文目录导读：

1. 核心突破点：AGPL v3 第13条
2. 对云服务商的核心要求
3. 潜在的法律与商业风险 (对云服务商)
4. 特殊情况：AGPL + 商业许可
5. 常见误解与澄清
6. 如何合规使用AGPL云服务（建议步骤）

AGPL（Affero General Public License，通用公共许可证）云服务条款是一个非常重要且常被误解的议题，核心在于 AGPL v3 的“网络使用即分发”条款。

如果一家公司通过互联网提供基于AGPL软件的云服务,即使没有向用户分发软件副本，也被视为“分发”，从而需要向所有通过网络使用该服务的用户提供完整的、可修改的源代码。

下面从几个角度为你详细解读这个条款的含义、对云服务商和使用者的影响。

核心突破点：AGPL v3 第13条

与GPL v3相比，AGPL v3的关键新增是第13条（Remote Network Interaction）。

• GPL v2/v3的问题： 传统意义上的“分发”指物理或数字拷贝，如果一个公司修改了GPL软件，只在自己的服务器上运行（提供SaaS服务），用户通过浏览器访问但没有获得软件副本，在这种情况下，该公司不需要公开其修改后的源代码。
• AGPL v3 的解决： 为了堵上这个“SaaS/云服务漏洞”，AGPL规定，只要用户通过网络与运行AGPL软件的服务器进行交互，无论用户是否下载了软件副本，这个交互行为就等同于“分发”，运行该服务的组织必须向所有此类用户提供其正在使用的完整源代码（包含所有修改）。

对云服务商的核心要求

如果一家公司选择在云服务中使用AGPL许可的软件（无论是作为核心组件，还是作为修改、衍生作品的基础），它必须满足以下条件：

1. 提供源代码： 必须向所有通过网络使用该服务的用户提供完整、对应机器可读的源代码，这包括服务商自己所做的任何修改、增强或集成。
2. 源代码的获取方式： 通常是通过在服务中提供一个下载链接、一个公开的Git仓库，或一个明确的索取方式，最佳实践是让用户可以轻松、免费地获取。
3. 保持版权声明： 必须保留所有原始的AGPL版权声明，不能删除或修改。
4. 不添加限制： 不能向用户施加任何额外的、限制其行使AGPL所授予权利的条款，不能要求用户签署保密协议才能查看源代码。

潜在的法律与商业风险 (对云服务商)

违反AGPL云服务条款的后果可能很严重：

• 版权侵权： 核心开发者或版权持有者可以起诉侵权，因为AGPL是版权许可，违反其条款意味着未经授权使用软件，构成版权侵权，这可能导致巨额赔偿和禁令。
• 条款终止： AGPL v3第8条规定，一旦被认定为违反许可条款，且未在30天内纠正，你的许可将被自动终止，这意味着你瞬间失去了使用、修改和分发该软件的所有合法权利。
• 声誉损害： 在开源社区中，不遵守AGPL条款的行为被视为“盗版”或“不道德”，会严重损害公司的技术声誉，并可能影响到与其他开源开发者或公司的合作。
• 供应链风险： 如果贵司的产品依赖其他AGPL软件，你的客户（特别是大型企业、政府机构）可能会在尽职调查时发现问题，导致合同取消或延迟。

特殊情况：AGPL + 商业许可

很多公司在使用AGPL软件时,会面临一个选择：要么完全遵守AGPL（公开所有代码），要么购买商业许可。

• 常见组合（双重许可）： 许多流行的开源项目（MongoDB, Redis Stack, Neo4j 早期版本）采用“AGPL + 商业许可”模式。
  • AGPL 许可： 如果你想免费使用，并且愿意公开所有你自己的、与之交互的代码（尤其是你修改了核心库本身，或深度集成了它）。
  • 商业许可： 你向版权方付费，获得一份非AGPL的许可（通常是专有许可或更宽松的许可如Apache 2.0），允许你将该软件集成到自己的闭源云服务中，无需公开自己的代码。

常见误解与澄清

• 误解1：只要我不修改代码，就不需要公开。
  • 错。 AGPL第13条的核心是运行，即使你完全未修改原样运行，只要你向用户提供服务，你依然需要向用户提供该软件的完整源代码（尽管与官方发布的一致），虽然实际操作中用户拿到的都是官方代码，但法律上你仍负有这一义务。
• 误解2：我只需要把代码放在公司内部，给客户一个链接就行。
  • 对。 给用户提供源代码是满足要求的方式之一，但必须确保所有用户都能轻松访问，一个密码保护的内部链接对用户公开来说可能不够。
• 误解3：我用AGPL软件作为数据库后端，用户通过我的网站访问，我不需要公开。
  • 错。 只要用户通过网络与你的服务交互（通过你的Web应用），而你的后台运行了修改过的AGPL数据库，那么你就需要公开所有修改过的数据库代码和与它交互的、构成衍生作品的代码。

如何合规使用AGPL云服务（建议步骤）

1. 严格审查： 在你的软件供应链中，对所有引入的第三方库进行AGPL许可扫描，不要使用任何未经审查的AGPL代码。
2. 评估交互深度： 评估你的代码与AGPL代码的交互方式。
   • 修改内核： 如果你修改了AGPL库的源代码，几乎确定需要公开你自己的修改和与之紧密耦合的代码。
   • API调用： 如果你的应用程序只是通过网络API（如HTTP/REST）调用AGPL服务（调用一个AGPL数据库），通常认为不涉及AGPL限制，因为属于“独立程序”的交互，但这在法律上存在一些模糊地带（“系统集成”的例外）。
3. 考虑替代方案： 如果不想承担公开代码的风险，寻找使用更宽松许可（如MIT, Apache 2.0, BSD BSD-3, LGPL v3等）的替代库或产品。
4. 购买商业许可： 如果该AGPL项目提供商业许可，并且你能负担成本，这是最安全的闭源使用方式。
5. 构建合规流程： 建立内部流程，确保任何决定使用AGPL软件的人都理解其含义，并获得法律/合规部门的批准，在AGPL代码的仓库中，保留清晰的修改日志。
6. 保持公开透明： 如果决定使用AGPL并公开代码，创建一个清晰的公开仓库，包含所有你修改过的源代码，以及如何获取和构建的说明。

最终建议：

• 对于企业开发者/法务： 将AGPL视为 “高度传染性”的许可证，其触发条件远超GPL，任何面向最终用户的云服务，只要使用或修改了AGPL代码，默认假设你需要公开你的所有代码，除非你严格证明了“独立程序”或“系统集成”的例外。
• 对于个人/小团队： AGPL是保护你作品不被大公司“借走”而不回报社区的强大工具，如果你希望你的软件在云时代依然能保持开源，AGPL是最有力的选择之一。

如果你有具体的商业场景或正在评估某个AGPL库,建议咨询知识产权律师，因为最终的判断取决于具体的代码交互方式、商业模型和司法管辖区。