短答案

AGPL 的“网络交互”指外部用户通过网络远程使用被覆盖的程序。只要这一条件成立，就应当向这些用户提供对应的源代码，包括你修改后的版本。它把 GPL 的“分发”触发点扩展到了“远程使用”。

边界条件

• 内部使用通常不触发。 程序只在公司内部部署、不向外部用户开放使用的，一般不构成网络交互；一旦开放给客户、合作伙伴或公众使用，判断随之改变。
• 触发的是“使用”，不是“传输”。 用户无需下载软件，只要通过浏览器或 API 使用服务，就可能落入 AGPL 的源代码提供义务。
• 修改过的版本同样覆盖。 提供源代码的范围包括你对原程序的修改；仅提供原始上游代码，不能替代你实际运行的版本。
• 组合作品的边界需要单独判断。 把 AGPL 组件与自有代码结合时，是否存在衍生作品、以何种方式结合，决定了自有代码是否被一并覆盖；这一点不能靠“只调用不改”概括。
• SSPL 不是 AGPL。 MongoDB 等采用的 SSPL 把“提供服务”的义务写得更宽，判断标准不同，不能套用 AGPL 的结论。

下一步

1. 盘点组件与调用方式。 列出所有 AGPL 组件，标明是独立进程、动态链接还是代码合并。
2. 判断是否存在外部交互。 按实际部署形态确认服务是否对外开放，而不是按“我们只是 SaaS”作结论。
3. 准备源代码提供机制。 若触发，确定提供对象、提供方式与版本对应关系，并保留提供记录。
4. 评估隔离方案。 在合规成本过高时，考虑替换组件或通过进程与接口隔离降低覆盖范围。

需要就开源许可证义务作具体判断，可参见知识产权布局。

出处：《开源许可证合规：先判断分发形态，再谈许可证义务》

本文为存量研究文章的问答化改写，完整论证与法规依据见出处文章。最后更新：2026 年 11 月 4 日。