开源协议精讲 / 第三章：强 Copyleft 许可证

第三章：强 Copyleft 许可证

引言

Copyleft（版权左位）是开源世界中最具哲学深度的概念之一。如果说宽松许可证像是一份慷慨的礼物，那 Copyleft 更像是一个"以自由守护自由"的契约——你可以自由使用，但你必须让这份自由继续传递下去。

本章将深入解析强 Copyleft 许可证（Strong Copyleft），尤其是 GNU GPL 系列的运作机制、传染性以及边界案例。

3.1 Copyleft 的核心理念

3.1.1 什么是 Copyleft？

Copyleft 是一种利用版权法框架来保障软件自由的策略。其核心思想是：

如果你分发了基于 Copyleft 代码的衍生作品，你必须以相同的许可证（或兼容许可证）发布，并提供源代码。

与版权（Copyright）的对比：

3.1.2 强 Copyleft vs 弱 Copyleft

本章聚焦强 Copyleft，弱 Copyleft 将在第四章讨论。

3.2 GNU GPL 家族

3.2.1 版本演进

3.2.2 GPL v2 核心条款

GPL v2 是 Linux 内核使用的许可证，也是开源历史上最重要的许可证之一。

核心条款：

┌─────────────────────────────────────────────────┐
│                GPL v2 核心条款                    │
├─────────────────────────────────────────────────┤
│ 1. 自由复制和修改源代码                           │
│ 2. 分发时必须：                                   │
│    a) 使用 GPL 许可证                             │
│    b) 提供源代码或获取源代码的方式                 │
│    c) 保留所有版权声明和许可声明                   │
│ 3. 不得添加额外限制                               │
│ 4. 源代码必须是完整的、可编译的                    │
└─────────────────────────────────────────────────┘

“自由或死亡"条款（Section 2(b)）：

You must cause any work that you distribute or publish, that in whole or
in part contains or is derived from the Program or any part thereof, to
be licensed as a whole at no charge to all third parties under the terms
of this License.

这意味着：只要你的作品包含了 GPL 代码（即使是部分），整个作品都必须使用 GPL。

3.2.3 GPL v3 的改进

GPL v3（2007 年发布）针对新出现的法律和技术问题进行了重大改进：

主要改进：

反 Tivoization：

Tivoization 是指通过硬件限制阻止用户运行修改后的 GPL 软件（以 TiVo 机顶盒命名）。GPL v3 要求：

如果你分发包含 GPL v3 软件的设备，你必须提供足够的信息，让用户能够安装修改后的版本。

3.2.4 GPL v2 vs GPL v3

重要：Linux 内核至今仍使用 GPL v2，Linus Torvalds 明确反对 GPL v3 的反 Tivoization 条款。

3.3 传染性详解

3.3.1 什么是"传染性”？

“传染性”（Viral Nature）是 GPL 最具争议的特性。通俗来说：

如果你的软件使用了 GPL 代码，你的整个软件都必须以 GPL 发布。

技术术语：这被称为"衍生作品的 GPL 传染"（GPL Contamination of Derivative Works）。

3.3.2 什么构成"衍生作品"？

GPL 传染性的关键在于如何定义"衍生作品"（Derivative Work）。这在法律上是一个复杂的问题：

明确属于衍生作品的情况：

存在争议的情况：

3.3.3 FSF 的立场

FSF 对 GPL 传染性的解释：

注意：FSF 的立场不等于法律判决。截至目前，GPL 的传染范围尚未在大多数法域得到法院的充分检验。

3.3.4 边界案例分析

案例 1：Web 应用使用 GPL 库

场景：你的 Web 应用导入了一个 GPL 的 JavaScript 库
问题：你的整个 Web 应用是否必须开源？

分析：
- 如果是 GPL v2/v3：FSF 认为需要开源（如果构成衍生作品）
- 但实际上，GPL v2/v3 不限制通过网络提供的服务（SaaS）
- 如果使用 AGPL：则 SaaS 也需要开源

结论：GPL v2/v3 下，Web 应用通常不受传染
     （但 AGPL 会传染 Web 应用）

案例 2：闭源应用通过动态链接使用 GPL 库

场景：你的闭源应用动态链接了一个 GPL 的共享库
问题：你的应用是否必须开源？

分析：
- FSF 立场：是的，动态链接构成衍生作品
- 法律不确定性：尚无明确判例
- Linux 内核的立场：内核模块不需要 GPL（Linus 的特别例外）

结论：存在法律风险，建议咨询律师

案例 3：GPL 插件加载到闭源宿主程序

场景：闭源程序加载了 GPL 的插件
问题：宿主程序是否受 GPL 传染？

分析：
- 如果插件依赖宿主程序的内部 API → 可能传染
- 如果插件通过标准接口通信 → 可能不传染
- 如果插件是独立进程 → 不传染

结论：取决于耦合程度，需要具体分析

案例 4：企业内部分发 GPL 软件

场景：公司在内部使用和修改了 GPL 软件，分发给内部员工
问题：是否触发 GPL 的源代码公开义务？

分析：
- GPL v2/v3：公司内部使用不构成"分发"（Distribution）
- 只有对外部第三方的分发才触发义务
- 但将代码交给外包团队可能构成分发

结论：纯内部使用通常不受限，但外包等场景需谨慎

3.4 LGPL（GNU 宽松通用公共许可证）

3.4.1 概述

LGPL（Lesser General Public License）是 GPL 的弱化版本，主要面向库（Library）的使用场景。

3.4.2 LGPL 的核心规则

LGPL 允许闭源软件通过链接的方式使用 LGPL 库，但有以下条件：

3.4.3 LGPL 的"可替换性"条款

LGPL 要求使用 LGPL 库的应用必须允许用户替换该库：

你必须确保用户可以使用修改后的 LGPL 库版本来运行你的应用。

实现方式：

1. 动态链接（推荐）：用户只需替换 .so/.dll 文件
2. 静态链接：必须提供目标文件（.o），以便用户重新链接
3. 应用内嵌入：必须提供源代码或安装信息

3.4.4 LGPL 适用场景

• ✅ C/C++ 共享库
• ✅ 希望被闭源软件使用的库
• ✅ 需要保障库本身自由的项目
• ❌ 不适用于独立应用
• ❌ 不适用于 Web 后端（SaaS 不受限）

3.5 AGPL（GNU Affero 通用公共许可证）

3.5.1 概述

AGPL（Affero General Public License）是 GPL 的补丁版本，专门针对 SaaS（Software as a Service）场景。

3.5.2 AGPL 的核心创新：网络交互条款

GPL 的"漏洞"：

传统 GPL：
  分发软件 → 必须开源
  通过网络提供服务 → 不算"分发" → 不需要开源

AGPL：
  分发软件 → 必须开源
  通过网络提供服务 → 也算"分发" → 必须提供源代码

AGPL Section 13：

Notwithstanding any other provision of this License, if you modify the
Program, your modified version must prominently offer all users interacting
with it remotely through a computer network (if your version supports such
interaction) an opportunity to receive the Corresponding Source of your
version...

3.5.3 AGPL 传染的实际影响

3.5.4 AGPL 的争议与企业态度

负面态度：

• Google 内部禁止使用 AGPL 代码
• 许多企业将 AGPL 列入"黑名单"
• 云服务商特别警惕 AGPL

正面态度：

• MongoDB 最初使用 AGPL（后改为 SSPL）
• Nextcloud 使用 AGPL
• 一些开源项目使用 AGPL 防止"搭便车"

3.5.5 AGPL 适用场景

• ✅ 希望防止 SaaS 搭便车的项目
• ✅ 需要确保网络服务用户也能获得自由的项目
• ✅ 有明确商业模式的企业开源项目
• ❌ 不适合作为通用库的许可证
• ❌ 不适合希望被广泛采用的项目

3.6 GPL 兼容性

3.6.1 与 GPL 兼容的许可证

3.6.2 与 GPL 不兼容的许可证

3.7 GPL 在企业中的应用

3.7.1 企业对 GPL 的态度光谱

完全接受 ◄─────────────────────────────► 完全拒绝

  Red Hat    Canonical    Google Cloud    Apple
  (GPL 优先)  (混合策略)   (有限使用)     (尽量避免)

3.7.2 企业使用 GPL 的最佳实践

1. 清单管理：维护所有 GPL 依赖的清单
2. 隔离策略：将 GPL 代码与专有代码隔离
3. 法律审查：重大决策前咨询律师
4. 培训：确保开发团队理解 GPL 的要求
5. 自动化工具：使用 FOSSology、ScanCode 等工具扫描

3.7.3 常见的企业合规策略

3.8 常见问题

Q1：我修改了 GPL 软件但不分发，需要开源吗？

不需要。GPL 只在"分发"（Distribution）时触发源代码公开义务。私人使用和修改不受限。

Q2：GPL 软件可以用于商业目的吗？

可以。GPL 不禁止商业使用。你可以出售 GPL 软件，但你必须同时提供源代码，且购买者有权自由再分发。

Q3：我的项目使用了 GPL 代码，但我想保持闭源，怎么办？

1. 移除 GPL 代码：用宽松许可证的替代品替换
2. 开源你的项目：以 GPL 发布你的项目
3. 获得商业授权：如果版权持有者提供商业许可
4. 咨询律师：评估法律风险

Q4：GPL v2 和 GPL v3 可以混合使用吗？

取决于版本标识：

• GPL-2.0-only：只能与 GPL v2 兼容的代码混合
• GPL-2.0-or-later：可以选择使用 GPL v2 或更高版本
• GPL-3.0-only：只能与 GPL v3 兼容的代码混合
• GPL-3.0-or-later：可以选择使用 GPL v3 或更高版本

Q5：网络爬虫爬取 GPL 代码算分发吗？

不算。通过网络访问代码不构成 GPL 意义上的"分发"。但如果你将爬取的代码整合到你的软件中并分发，则构成分发。

3.9 本章小结

扩展阅读

1. GPL v2 全文：https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
2. GPL v3 全文：https://www.gnu.org/licenses/gpl-3.0.html
3. GPL FAQ：https://www.gnu.org/licenses/gpl-faq.html
4. FSF 许可证列表：https://www.gnu.org/licenses/license-list.html
5. Software Freedom Conservancy - GPL 合规指南：https://sfconservancy.org/copyleft-compliance/
6. 《The GPL Cooperation Commitment》：https://gplcc.github.io/gplcc/

上一章：宽松许可证 下一章：弱 Copyleft 许可证