AGPL 实战：自建、SaaS 与「改了一行」的边界

AGPL 到底特殊在哪

GPL 的触发条件是「分发」，AGPL 在第 13 条上加了一句：如果用户通过网络与修改后的程序交互，也算分发，必须向这些用户提供对应源码。这一条是为 SaaS 时代准备的——你可以不分发二进制，但只要你把服务开给别人用，义务就来了。

很多团队对它的理解停在「用了 AGPL 就要开源整个系统」，这既不准确，也容易吓退本来完全合规的用法。

三种场景，三种结论

第三行是争议最多的：没改代码，要不要开源？严格按条文，你仍须向网络用户提供该程序的源码。实践中，多数项目方和法务接受「给出上游仓库地址 + 版本号」作为履行方式，因为对应源码就是上游那份。但如果你的部署包含补丁、配置生成器或周边模块，边界就开始模糊。

「改了一点」怎么算

AGPL 保护的是程序本身，不是你的整个技术栈。调用一个 AGPL 的命令行工具、通过 API 与它通信，通常不会让你的业务代码变成衍生作品；把它的代码链接进你的进程、修改它的核心模块，则很可能算。

判断标准还是老问题：两者是否构成一个更大的程序、是否共享数据结构与内部接口。这个边界没有自动判定，真要商用，找律师看具体架构比看十篇博客靠谱。

企业内部使用，基本不受影响

员工在内网用 AGPL 软件，不对外提供服务，就不构成「通过网络交互」。这也是为什么大量公司敢在内网跑 Grafana、MinIO 这类 AGPL 项目。

但要注意两个坑：一是把内网服务暴露给客户或合作伙伴；二是把 AGPL 组件打包进卖给客户的产品。前者触发网络条款，后者触发传统分发条款。

商业上更现实的问题

比起法律义务，更常见的是商业风险：一些公司直接禁止 AGPL 依赖进入产品线，无论合规与否。这时候替代方案是买商业授权，或者换一个 Apache-2.0/MIT 的同类项目。

选型阶段就查许可证，比上线后返工便宜得多。

我的判断

AGPL 不是「不能用」，而是「用了要清楚代价」。自建自用几乎没有负担；对外提供修改版服务，就要准备好源码出口；把它嵌进商业产品，先问法务。

最危险的态度不是拒绝 AGPL，而是「反正没人查」。这类义务一旦被主张，往往发生在公司最不想被打断的时候。

延伸阅读

• 许可证里的三条附加条款
• 值得自建的 8 个开源项目