为什么给一份代码多个许可证
版权所有者可以同时以多种条件许可同一份代码。接收者只需选择其中一个并遵守其条件即可。这样做的目的主要有两个。
- 扩大兼容性 — 为了与不同的生态都能良好契合。
- 商业模式 — 在以开源发布的同时，另行销售商业许可证。
类型 1：同时提供两个宽松型许可证 — MIT OR Apache-2.0
这是 Rust 语言和大多数 Rust crate 采用的方式。用户可以在 MIT 和 Apache-2.0 中任选其一。
- 选择 Apache-2.0，可以获得明确的专利许可。
- 选择 MIT，也可以放进 GPL-2.0-only 项目（因为 FSF 认为 Apache-2.0 与 GPL-2.0 不兼容）。
相当于兼得两者的优点，因此深受库作者欢迎。按惯例，仓库中会放置 LICENSE-MIT 和 LICENSE-APACHE 两个文件。
类型 2：著佐权 + 商业 —「要么 GPL，要么付费」
将代码以 GPL、AGPL 公开，同时通过单独合同向不愿承担公开源代码义务的企业销售商业许可证。MySQL（GPL + Oracle 商业许可）、Qt（LGPL-3.0/GPL + 商业）是代表性案例。
这种模式只有在版权所有者拥有全部代码的权利时才能运作。因为对于外部贡献者仅以 GPL 贡献的代码，版权所有者无权以商业许可证出售。
CLA 与 DCO
- CLA（贡献者许可协议）：贡献者向项目运营方授予广泛使用其贡献（包括再授权）的权利，或转让版权的协议。要做商业双重许可，实际上是必需的。也有像 Apache 基金会 ICLA 那样只授予再授权权利、版权仍保留在贡献者手中的形式。
- DCO（Developer Certificate of Origin，开发者原创证书）：贡献者在每次提交时确认「我有权以本项目的许可证提交这段代码」的方式（用
git commit -s添加Signed-off-by:行）。Linux 内核采用此方式。DCO 不授予再授权权利，因此不足以支撑商业双重许可。
用 SPDX 表达式书写
多个许可证之间的关系用 SPDX 许可证表达式书写。
| 表达式 | 含义 | 示例 |
|---|---|---|
A OR B | 二者任选其一遵守（选择型双重许可） | MIT OR Apache-2.0 |
A AND B | 两者都须遵守（不同部分混合的情况） | MIT AND BSD-3-Clause |
A WITH 例外 | 为许可证附加例外条款 | GPL-2.0-only WITH Linux-syscall-note |
| 括号 | 指定组合顺序 | (MIT OR Apache-2.0) AND Unicode-3.0 |
如果把 OR 和 AND 弄混，意思就会完全相反。用户可以选择时用 OR，必须全部遵守时用 AND。
注意事项
- 已获得的权利依然有效：即使以后只保留商业许可证，此前以开源发布的版本所授予的许可通常仍然有效。
- 与「开放核心」不同：核心开源、附加功能以闭源商业形式销售的模式并不是双重许可。为同一份代码提供两个许可证才是双重许可。
- 不要与源代码可见许可证混淆：越来越多的项目转向 BUSL、SSPL 这类可以看到源代码但按 OSI 标准不属于开源的许可证。这是一种不同于双重许可的策略。
- 准确提供声明文件：如果是选择型，须提供每个许可证的全文，并在 README 中明确写明「二者任选其一」。
应用示例
要应用 Rust 风格的双重许可，可以在生成器中分别获取 MIT 和 Apache-2.0 文件，保存为 LICENSE-MIT、LICENSE-APACHE，并在元数据中写上 license = "MIT OR Apache-2.0"。每个文件头中写 SPDX-License-Identifier: MIT OR Apache-2.0。
本文为一般信息，不构成法律意见。重要决定请咨询专业人士。
参考来源
- SPDX Specification, License Expressions — https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/
- Rust API Guidelines, Licensing — https://rust-lang.github.io/api-guidelines/necessities.html
- Developer Certificate of Origin — https://developercertificate.org/
- Apache ICLA — https://www.apache.org/licenses/contributor-agreements.html