GPL-3.0、AGPL-3.0、LGPL-3.0 这些有什么区别

License

GPL-3.0、AGPL-3.0 和 LGPL-3.0 都是 GNU 家族的“著佐权”（copyleft）开源许可证，由自由软件基金会（FSF）发布，目标都是保障用户运行、研究、修改和分发软件的自由。但它们在开源义务的范围和强度上有显著区别。

下面从核心差异、使用场景、商业影响等角度为你清晰对比：

✅ 一句话总结区别

适用场景：通用软件（如编译器、命令行工具、桌面应用）
核心规则：
- 如果你分发（distribution）基于 GPL-3.0 的软件（包括修改版），必须公开整个项目的完整源代码，并以 GPL-3.0 发布。
- 内部使用或 SaaS 不分发？→ 无需开源（这是关键漏洞）。
商业影响：
- ❌ 不能将 GPL 代码集成到闭源商业软件中（除非不对外分发）；
- ✅ 可用于内部系统、SaaS（只要不把软件“分发”给客户）。

📌 例子：你用 GPL 软件搭建一个 Web 服务，用户只通过浏览器访问 → 不需要开源你的代码（因为没“分发”软件副本）。

适用场景：网络应用 / SaaS / 云服务
核心规则：
- 在 GPL-3.0 基础上，新增第13条：
  
  “如果你通过网络让用户与软件交互（如 Web 服务），即使没有分发软件，也必须向用户提供源代码。”
- 这堵住了 GPL 在 SaaS 场景下的“漏洞”。
商业影响：
- ❌ 任何基于 AGPL 的 SaaS 服务都必须开源；
- ❌ 几乎无法用于闭源商业产品（除非完全隔离，如通过 API 且不衍生）。

📌 例子：你修改了 AGPL 的 Nextcloud 并部署成网盘服务 → 必须向所有用户提供你修改后的完整源码。

适用场景：共享库（.so/.dll/.jar 等）
核心规则：
- 仅对库本身有 copyleft 要求；
- 如果你的程序动态链接（dynamic linking）LGPL 库，主程序可以闭源、商用、任意许可证；
- 如果静态链接或修改了库代码，则修改后的库必须以 LGPL 开源。
商业影响：
- ✅ 非常适合商业软件集成开源库（如 Qt、GTK+）；
- 开发者只需开放对 LGPL 库本身的修改，业务逻辑可保密。

📌 例子：你在闭源 App 中调用 LGPL 的 FFmpeg 解码视频 → 合法！只需说明用了 FFmpeg 并提供其 LGPL 源码链接。

特性	GPL-3.0	AGPL-3.0	LGPL-3.0
是否允许闭源衍生作品？	❌ 否	❌ 否	✅ 是（主程序可闭源）
SaaS/网络服务是否触发开源？	❌ 否	✅ 是	⚠️ 仅当修改/分发库本身
适合做库（library）吗？	❌ 不推荐	❌ 不推荐	✅ 专门为此设计
商业友好度	低	极低	中高
典型项目	Bash, GIMP, GCC	MongoDB（旧版）、Nextcloud、Odoo	FFmpeg, GTK+, Qt（可选）

AGPL 的“网络交互”定义较宽：即使只是提供 API 服务，也可能被认定为“远程网络交互”，从而触发开源义务。
GPL/LGPL 的“衍生作品”判断复杂：如果代码深度耦合（如直接嵌入、静态链接），可能被认定为整体作品，导致整个项目需开源。
三者之间兼容性：
- AGPL-3.0 与 GPL-3.0 可通过第13条互操作；
- LGPL-3.0 可被“升级”为 GPL-3.0 使用。

选择哪个，取决于你想在多大程度上强制他人开源，以及你的项目是应用、服务还是库。

最后更新于 2026年1月26日