AGPL许可协议对衍生软件的开源要求是什么？

Question

**问题：** AGPL许可协议对衍生软件的开源要求具体体现在哪些方面？是否仅限于代码修改，还是也包括部署后的服务提供？若企业内部使用或通过网络提供服务，是否都需公开源代码？如何界定“衍生软件”的范围？相较于GPL，AGPL在开源要求上有何强化？企业在使用AGPL项目时应如何合规以避免法律风险？

Answer 1

AGPL许可协议深度解析与企业合规实践指南

一、AGPL开源要求的核心内容

AGPL（GNU Affero General Public License）是GPL（GNU General Public License）的一个变种，主要针对网络服务提供者。其核心目标是防止企业通过SaaS（软件即服务）方式使用自由软件而不回馈社区。

• 源代码公开义务：任何对AGPL授权软件的修改或衍生作品，必须以相同许可证发布源代码。
• 网络服务场景下的披露义务：即使未分发软件副本，只要通过网络向用户提供该软件的服务接口，就必须提供源代码。
• “衍生软件”定义：通常包括对原代码的修改、扩展、链接（静态或动态），以及在某些情况下与其集成的其他模块。

二、是否仅限于代码修改？

AGPL的开源要求不仅限于对原始代码的修改。它还包括以下情况：

行为类型	是否触发开源义务
直接修改源码	是
新增插件或模块	视情况而定，若构成衍生作品则需公开
部署为网络服务	是，即使未分发也需提供源码
仅内部使用	否，除非对外提供服务

三、企业内部使用与网络服务的区别

企业在使用AGPL项目时，是否需要公开源代码，取决于其使用方式：

1. 内部使用：如企业仅在内部运行AGPL软件，不对外提供访问接口，则无需公开源代码。
2. 外部服务提供：若企业将AGPL软件部署为Web服务、API服务等，并允许外部用户通过网络访问其功能，则必须向用户提供源代码。

四、“衍生软件”的界定标准

“衍生软件”是判断是否需开源的关键。虽然法律上尚未有统一定义，但通常遵循以下原则：

• 基于原软件进行修改、重构、封装
• 与原软件动态或静态链接
• 作为插件、模块、子系统嵌入原系统中
• 共享数据结构、接口调用频繁

建议企业在不确定是否构成衍生软件时，咨询法律顾问或参考FSF（自由软件基金会）的解释。

五、AGPL相较于GPL的强化点

AGPL与GPL的主要区别在于：增加了网络服务场景下的源码披露义务。以下是对比表格：

特性	GPLv3	AGPLv3
修改后必须开源	是	是
网络服务需提供源码	否	是
适用范围	传统软件分发	包含SaaS模式
典型代表	Linux内核	MongoDB、Redis Modules

六、企业如何合规使用AGPL项目

企业在使用AGPL项目时，应采取以下策略确保合规：

1. 明确使用场景：判断是否涉及网络服务、是否构成衍生作品。
2. 审查依赖关系：使用工具（如FOSSA、Black Duck）扫描项目依赖项，识别所有AGPL组件。
3. 制定源码披露机制：如需对外提供服务，应准备源代码并提供获取路径。
4. 采用替代方案：如不想承担开源义务，可选择Apache、MIT等宽松型许可证项目。
5. 签署商业许可协议：部分AGPL项目（如MongoDB）提供商业授权选项，企业可通过付费获得更灵活的使用权限。

七、流程图：AGPL合规判断逻辑

graph TD
    A[是否使用AGPL软件] --> B{是否构成衍生作品?}
    B -->|否| C[无需开源]
    B -->|是| D{是否通过网络提供服务?}
    D -->|否| E[内部使用 - 无需开源]
    D -->|是| F[必须提供源代码]
        

八、实际案例分析

某云服务商使用了AGPL授权的数据库引擎作为其核心服务的一部分，用户通过API访问数据存储功能。尽管该服务未下载软件本身，但由于其提供了远程交互接口，因此被认定为需提供源代码。最终该企业不得不将其定制版本开源。