--- title: "AGPL-3.0：把网络服务也纳入开源合规的许可证" description: 'GPL 家族的补丁。当你的软件通过网络提供服务，AGPL 要求你必须向所有用户公开源代码。它是最"强硬"的开源许可证，也是最容易踩坑的许可证。' date: "2026-08-28" type: "notes" kind: "note" tags: - 开源 - License --- **GNU Affero General Public License v3** 是 Free Software Foundation 在 2007 年 11 月 19 日发布的一份自由软件许可证，通常缩写为 AGPL-3.0。它诞生的初衷很直接，GPL 有一个盲区，一旦你把软件部署在自己服务器上以网络服务的方式提供给用户，GPL 的 copyleft 义务就不会被触发，因为你没有"分发"任何一份程序。AGPL 就是补这个漏洞的。 ## 它长什么样 AGPL-3.0 一共 15 条。前 14 条基本沿用了 GPL-3.0 的结构，Section 2 讲版权许可，Section 5 讲修改版本的整体发布，Section 6 讲分发目标代码时同时提供源代码，Section 14 讲后续版本的可选性。真正让 AGPL 和 GPL 拉开差距的是 Section 13，也就是所谓"Remote Network Interaction"。 换句话说，AGPL 的骨架和 GPL 一样，只是多了一颗钉子把"通过网络提供服务"这一场景钉死。 ## Section 13 是核心 Section 13 的条款不长，但分量极重。原文大意是，如果你修改了程序，并且通过远程网络让用户与之交互，你必须免费、按标准或惯例方式，向你所有远程网络用户开放修改版本的源代码。 GPL 的 copyleft 只在"分发"发生时触发。分发包括拷贝二进制、打包安装包、上传到下载站。AGPL 把这些行为之外再加了一种，也就是通过网络把服务提供给第三方。这个"加一种"就是它和 GPL 的根本区别。 它带来的直接后果是，只要一家公司把 AGPL 授权的软件部署到自家服务器对外提供服务，公司就得把自身所做的修改以源代码形式向所有访问者开放。哪怕访问者只看到一个前端页面，哪怕代码根本跑在服务器上，只要访问者通过网络与这份修改后的程序交互，就必须能拿到源代码。 ## 具体到编程里的几个动作 第一层动作是识别。你引入的一个依赖，如果它的 LICENSE 文件里写着 AGPL-3.0，你就必须把它当作合规义务的一部分来管理，而不是当作普通依赖随意使用。第二层是判断是否"修改"。仅仅是调用库、把程序原样部署到云上，不算修改，不触发 Section 13；如果你 fork 了仓库、加了功能、改了 bug、打了补丁，那就是修改，触发义务。第三层是交付。触发之后，你必须以一种所有远程用户都能访问到的形式提供源代码，通常的做法是在项目主页挂一个源代码链接，或者在服务器上跑一个公开的源码仓库。 ## 两个绕不开的案例 MongoDB 是最经典的例子。3.6 版本之前 MongoDB 用 AGPL-3.0 授权，2018 年之后切换到 SSPL。切换的原因公开写在官方博客里，创始人担心像 Amazon、Google 这样的云服务商会用未修改的 MongoDB 直接跑托管数据库服务，然后坐收商业利润却不需要回馈任何贡献。SSPL 比 AGPL 更严，它要求你把整个服务基础设施的代码都开源。但 SSPL 严格意义上不被 OSI 和 FSF 承认是"开源"，这也说明连一个原本就吃 AGPL 苦的项目都觉得 AGPL 还不够硬。 Microsoft Roslyn 早期用 AGPL，引发过 .NET 社区的公开争论。争议的核心不在于 Roslyn 本身写得怎么样，而在于很多人担心 Microsoft 的开源动机并不纯正，怀疑他们只是用一份开源许可证给商业产品包装一层合规外衣。这类争议反复出现，说明 AGPL 一旦出现在大公司手里，几乎必然伴随商业动机的猜测。 FSF 有一个专门的 AGPL 执法团队，会主动追踪违反 AGPL 的案例并推动维权。这也解释了为什么 AGPL 被称"最严的开源许可证"，它不是纸面条款，是有执法动作的。Elastic 在 2021 年把 Elasticsearch 切换到 SSPL 之后，FSF 公开施压，也是同一逻辑的延伸。 ## 常见的几种误解 一种是以为"我们只是通过网络提供服务，没有分发二进制，所以不算违规"。这个判断错在漏看了 Section 13。AGPL 把网络交互定义为触发条件。 另一种是以为"我们内部使用，不对外提供，所以没事"。只要不对外，那确实不触发 AGPL，但如果有一天你把这套内部系统开放给外部用户，之前做的所有修改都要追溯。 还有一种比较隐蔽，以为"我把源代码放到某个私密仓库就够合规了"。Section 13 要求的是所有远程网络用户都能获得源代码，不是"你能找到就行"。私密仓库对远程用户不可访问，等于没交付。 最后一种是以为"只要我 fork 了别人的 AGPL 项目，就必须把我的项目整个改成 AGPL"。这条判断要看你的代码是否构成"基于该程序的修改版本"。如果你的项目是独立产品，只是链接或调用 AGPL 库，风险要具体判断，不是所有集成方式都必然传染。但一旦你的二进制与 AGPL 库深度耦合，构成衍生作品，传染几乎不可避免。 ## 关联词 - **AGPL-3.0**，GNU Affero General Public License v3，FSF 2007 年发布，GPL 家族中把网络服务纳入 copyleft 的版本。 - **Section 13**，Remote Network Interaction，AGPL 独有的一条，把"通过远程网络向用户提供服务"定义为开源合规的触发条件。 - **Copyleft**，GPL 系列的核心机制，任何基于原作的衍生作品必须整体以同一开源协议发布。 - **SSPL**，Server Side Public License，Elastic 和 MongoDB 推出的更严版本，比 AGPL 多要求服务基础设施也开源。 - **衍生作品**，判断一个修改是否构成 AGPL 传染的关键，深度耦合的二进制集成通常被判为衍生。 - **FSF 执法团队**，Free Software Foundation 里负责追踪 AGPL 违规并推动维权的部门。 ## 小结 AGPL-3.0 在 GPL 家族里位置很靠硬的那一端，对做 SaaS、网络服务、云托管、推理平台的项目几乎无法回避。它最容易被忽视的地方在于 Section 13 的触发条件，只要你的服务对外，只要你做了修改，源代码就必须向所有访问者开放，这条没有例外。合规成本可以预估，也可以设计规避，但假装这条不存在是最容易付出法律代价的选择。 ## 参考资料 - [GNU AGPL 官方文本](https://www.gnu.org/licenses/agpl-3.0.en.html) - [OSI AGPL-3.0 页面](https://opensource.org/license/agpl-v3) - [FSF GPL FAQ](https://www.gnu.org/licenses/gpl-faq.html)