4. Copyleft 许可证精讲
Copyleft 许可证的核心机制，是通过版权法赋予使用者自由，同时要求其衍生作品在再分发时保持同样的自由。理解 GPL 系列、AGPL 与 LGPL 的关键，不在于记住条文编号，而在于判断三件事：什么行为构成“分发”、传染性覆盖到哪些代码、商业集成时风险落在哪一层。这三者共同决定了合规义务的边界。
一、分发触发条件：义务何时被激活
GPL 的义务并非在“使用”时产生，而是在“分发”时产生。内部使用、自用部署、不对外提供副本，通常不触发源码公开义务。触发点包括：向客户交付二进制、通过镜像或下载页提供软件、将软件预装在硬件中销售、以 SaaS 形式向外部提供修改后的 AGPL 程序等。
需要特别区分“分发”与“网络交互”。GPL v2 与 v3 以分发为核心触发条件；AGPL 则把触发条件扩展到“通过网络与用户交互”。也就是说，即使不交付任何二进制，只要用户通过网络远程使用你修改过的 AGPL 程序，你仍需向其提供对应源码。这是 AGPL 与 GPL 最实质的差异。
二、传染性范围：GPL v2、v3、AGPL、LGPL 的边界
传染性范围取决于代码之间的结合方式。一般可分为四类关系：
- 独立程序：通过命令行、进程边界、网络协议通信，通常不构成衍生作品，各自许可证独立。
- 同一地址空间链接：静态链接、动态链接并共享数据结构，通常被视为衍生作品，GPL 义务覆盖整个作品。
- 库调用：LGPL 允许专有程序动态链接 LGPL 库，但若修改库本身，修改部分仍需按 LGPL 开放。
- 网络交互：AGPL 将远程交互视为分发等价行为，传染性可延伸至服务端修改版本。
GPL v2 与 v3 的主要差异在于：v3 增加了对“用户产品”中安装信息的反锁定要求（Anti-Tivoization）、更明确的专利授权条款，以及与 Apache 2.0 的兼容性。GPL v2 与 Apache 2.0 不兼容，而 GPL v3 与 Apache 2.0 兼容。这意味着，若项目需要集成 Apache 2.0 代码，选择 GPL v3 通常比 v2 更可行。
三、商业集成风险：风险落在哪一层
商业集成的风险通常不在“用了 GPL 软件”，而在“把 GPL 代码与专有代码结合后对外分发”。典型高风险场景包括：
- 把 GPL 库静态链接进专有客户端，导致整个客户端被要求以 GPL 发布。
- 在 SaaS 产品中集成 AGPL 组件并修改其源码，未向用户提供修改版本源码。
- 在硬件产品中嵌入 GPL v3 软件，却限制用户替换该软件，违反反 Tivoization 条款。
- 把 LGPL 库改成静态链接并修改库代码，却未开放库的修改部分。
相对安全的做法是：保持进程边界清晰，通过命令行、REST、gRPC 等协议通信；不修改 LGPL 库本身；对 AGPL 组件单独部署并评估是否构成“对应源码”提供义务；在分发前完成许可证清单与链接方式审计。
四、规避策略：从选型到交付的检查点
规避不是“一律不用 GPL”，而是把义务控制在可承受范围内。可参考以下检查点：
| 检查点 | 判断问题 | 处理建议 |
|---|---|---|
| 组件许可证 | 是 GPL v2、v3、AGPL 还是 LGPL？ | 建立 SBOM，标注每个组件许可证与版本 |
| 结合方式 | 静态链接、动态链接、进程隔离还是网络调用？ | 优先进程隔离；避免静态链接 GPL |
| 是否修改 | 是否修改了 GPL / LGPL / AGPL 源码？ | 保留修改记录，准备对应源码包 |
| 分发方式 | 是否对外交付二进制或提供网络交互？ | 分发前完成源码提供与声明文件 |
| 专利与兼容 | 是否涉及 Apache 2.0 等不兼容许可证？ | GPL v2 项目避免混入 Apache 2.0 代码 |
最后要强调的是，Copyleft 的“传染”并非无限扩张，而是围绕“衍生作品”和“分发/交互”两个法律事实展开。把这两个事实判断清楚，再结合链接方式、修改情况和分发路径，就能把 GPL 系列、AGPL 与 LGPL 的商业使用风险控制在可解释、可审计的范围内。