开源协议精讲 / 第四章：弱 Copyleft 许可证

第四章：弱 Copyleft 许可证

引言

弱 Copyleft（Weak Copyleft）许可证是介于宽松许可证和强 Copyleft 之间的"中间地带"。它们保留了 Copyleft 的精神——修改后的源代码必须公开——但对于如何与专有代码结合使用，则给出了比 GPL 更宽松的条件。

如果你正在开发一个库，既希望保持开源，又希望被商业软件采用，弱 Copyleft 可能是最佳选择。

4.1 弱 Copyleft 的定位

4.1.1 许可证光谱

宽松 ◄──────────────────────────────────────────► 强 Copyleft

MIT    BSD    Apache-2.0    MPL    EPL    LGPL    GPL    AGPL
                          ← 弱 Copyleft →

4.1.2 核心区别

4.2 Mozilla 公共许可证（MPL）

4.2.1 概述

Mozilla 公共许可证（Mozilla Public License, MPL）是 Mozilla 基金会创建的弱 Copyleft 许可证，主要用于 Firefox、Thunderbird 等项目。

4.2.2 核心机制：文件级 Copyleft

MPL 最独特的特征是文件级 Copyleft（File-level Copyleft）：

你的项目
├── myfile_a.cpp      ← 你的代码（可以使用任何许可证）
├── myfile_b.cpp      ← 你的代码（可以使用任何许可证）
├── mpl_code.cpp      ← MPL 代码（修改后必须开源）
└── mpl_code.h        ← MPL 代码（修改后必须开源）

关键规则：

4.2.3 MPL 2.0 的关键条款

条款 1.1 - 定义：

"Covered Software" means Source Code Form to which the initial
Contributor has attached the notice in Exhibit A...

"Larger Work" means a work that combines Covered Software with
other material, in a separate file or files...

条款 3.1 - 再分发：

You may not offer or impose any terms on any Covered Software in
Source Code Form that alters or restricts the applicable version
of this License...

条款 3.3 - 与 GPL 的兼容性：

You may additionally convey a work that is a combination of the
Covered Software with a work governed by a Secondary License...

4.2.4 MPL 2.0 与 GPL 的兼容性

MPL 2.0 包含一个"次级许可证"（Secondary License）条款，允许将 MPL 代码与 GPL 代码组合：

MPL 代码 + GPL 代码 → 可以以 GPL 发布组合作品

但注意：反向操作（将 GPL 代码纳入 MPL 项目）仍然受 GPL 传染性限制。

4.2.5 注意事项

⚠️ MPL 2.0 常见误解

1. “MPL 代码可以随意用于闭源项目”：错误！你必须公开对 MPL 文件的修改
2. “文件级 Copyleft 意味着没有传染性”：MPL 文件本身有传染性，只是不会传染到其他文件
3. “可以不提供 MPL 文件的源代码”：错误！分发二进制时必须提供源代码

4.3 Eclipse 公共许可证（EPL）

4.3.1 概述

Eclipse 公共许可证（Eclipse Public License, EPL）是 Eclipse 基金会创建的弱 Copyleft 许可证。

主要使用项目：Eclipse IDE、Jakarta EE、OpenJ9

4.3.2 EPL 2.0 核心条款

EPL 2.0 的核心机制是模块级 Copyleft：

关键规则：

1. 修改 EPL 代码：必须以 EPL 发布修改后的模块
2. 新增模块：可以使用任何许可证
3. 组合使用：必须明确声明哪些模块是 EPL，哪些不是

4.3.3 EPL 与 MPL 的对比

4.3.4 EPL 的法律特色

EPL 包含一个独特的贡献者协议条款：

Each Contributor hereby grants You a world-wide, royalty-free,
non-exclusive license...

under Contributor Patents...
to make, use, sell, offer for sell, have made, import, and otherwise
transfer the Contribution...

这意味着贡献者自动授予专利许可，为企业使用提供了法律保障。

4.4 LGPL 详解

4.4.1 概述

LGPL（Lesser General Public License）已在第三章简要介绍，这里深入其作为弱 Copyleft 许可证的技术细节。

4.4.2 LGPL 的"可替换性"要求

LGPL 的核心要求是用户必须能够替换 LGPL 库：

┌─────────────────────────────────────────────────┐
│              LGPL 可替换性要求                    │
├─────────────────────────────────────────────────┤
│ 1. 动态链接（推荐）                               │
│    - 用户替换 .so/.dll 文件即可                    │
│    - 最简单的合规方式                              │
│                                                   │
│ 2. 静态链接                                       │
│    - 必须提供应用的目标文件（.o/.obj）             │
│    - 或提供完整的源代码                            │
│    - 允许用户重新链接                              │
│                                                   │
│ 3. 内嵌入应用                                      │
│    - 必须提供安装信息或源代码                       │
│    - 允许用户更新库                                │
└─────────────────────────────────────────────────┘

4.4.3 LGPL 的链接边界

动态链接 vs 静态链接：

数据结构和头文件：

如果 LGPL 库的头文件（.h）定义了数据结构：

- 你的代码使用了这些数据结构 → 是否受 LGPL 传染？
- FSF 立场：如果数据结构是"复杂"的，可能构成衍生作品
- 实践中：简单的 API 调用通常不受限

4.4.4 LGPL v2.1 vs LGPL v3

4.5 链接边界的深入分析

4.5.1 什么是"链接"？

在讨论弱 Copyleft 时，“链接”（Linking）是最关键的概念：

应用程序（App）
    │
    ├── 编译时链接（Compile-time Linking）
    │     ├── 静态链接：库代码直接嵌入可执行文件
    │     └── 动态链接：运行时加载 .so/.dll
    │
    ├── 运行时链接（Runtime Linking）
    │     ├── 动态加载：dlopen/LoadLibrary
    │     └── 插件系统：独立 .so/.dll 文件
    │
    └── 进程间通信（IPC）
          ├── 管道（Pipe）
          ├── 套接字（Socket）
          └── 共享内存（Shared Memory）

4.5.2 各种链接方式的法律含义

4.5.3 “修改"的定义

弱 Copyleft 许可证对"修改”（Modification）的定义至关重要：

MPL 2.0 的定义：

"Modified Version" of Covered Software means software that contains
modifications of the Covered Software...

EPL 2.0 的定义：

"Modification" means any copy of or change to the Content...

LGPL 的定义：

A "work based on the Library" means either the Library or any
derivative work under copyright law...

4.5.4 边界案例

案例 1：使用 LGPL 库的 API 但不修改库

场景：你的闭源应用通过动态链接使用 LGPL 库
问题：是否需要开源你的应用？

分析：
- 你没有修改 LGPL 库
- 你通过动态链接使用
- LGPL 库对用户是可替换的

结论：✅ 不需要开源你的应用

案例 2：修改了 LGPL 库的源代码

场景：你修改了 LGPL 库的源代码，然后在你的应用中使用
问题：需要开源什么？

分析：
- 修改后的 LGPL 库：必须以 LGPL 发布
- 你的应用代码：如果通过动态链接使用，不需要开源
- 如果静态链接：需要提供 .o 文件或源代码

结论：必须开源库的修改部分，应用本身可能不需要

案例 3：将 LGPL 库代码复制到你的项目中

场景：你将 LGPL 库的某些函数复制到你的项目文件中
问题：你的文件是否受 LGPL 传染？

分析：
- 你复制了 LGPL 代码
- 这些代码现在是你项目的一部分
- 文件级 Copyleft（MPL）：该文件受 MPL 约束
- LGPL：可能整个文件受 LGPL 约束

结论：⚠️ 这种情况可能触发传染，建议使用链接方式

4.6 弱 Copyleft 许可证的适用场景

4.6.1 场景决策矩阵

4.6.2 选型流程

你的项目是什么？
├── C/C++ 库 → LGPL v3
├── Java 模块 → EPL 2.0
├── Web 应用组件 → MPL 2.0
├── 桌面应用 → MPL 2.0 或 EPL 2.0
└── 需要 GPL 兼容 → MPL 2.0（含条款 3.3）

4.6.3 企业采用建议

4.7 弱 Copyleft 的合规实务

4.7.1 合规检查清单

使用弱 Copyleft 许可证的代码时，需要检查以下事项：

MPL 2.0 合规：

• 标识所有 MPL 文件
• 记录对 MPL 文件的修改
• 提供 MPL 文件的源代码
• 在分发包中包含 MPL 许可证文本
• 如果与 GPL 组合，确认条款 3.3 的适用性

EPL 2.0 合规：

• 标识所有 EPL 模块
• 记录对 EPL 模块的修改
• 提供 EPL 模块的源代码
• 声明 Secondary License（如果有）
• 在分发包中包含 EPL 许可证文本

LGPL v3 合规：

• 确保 LGPL 库对用户可替换
• 如果静态链接，提供 .o 文件或源代码
• 提供 LGPL 库的源代码
• 在分发包中包含 LGPL 许可证文本
• 提供安装信息（针对设备场景）

4.7.2 常见合规错误

4.8 本章小结

扩展阅读

1. MPL 2.0 全文：https://www.mozilla.org/en-US/MPL/2.0/
2. MPL 2.0 FAQ：https://www.mozilla.org/en-US/MPL/2.0/FAQ/
3. EPL 2.0 全文：https://www.eclipse.org/legal/epl-2.0/
4. LGPL v3 全文：https://www.gnu.org/licenses/lgpl-3.0.html
5. FSF - LGPL 说明：https://www.gnu.org/licenses/why-not-lgpl.html
6. Eclipse Foundation - 许可证：https://www.eclipse.org/legal/licenses.php

上一章：强 Copyleft 许可证 下一章：公共领域与极简许可