先看结论（TL;DR）#

• 想要最大化采用与商业友好 → MIT / BSD-2/3 / Apache-2.0（更推荐 Apache-2.0，因含专利授权与反诉终止条款）。
• 希望改动必须回馈，但不“传染”整个闭源代码 → MPL-2.0（文件级复制左）或 EPL-2.0。
• 坚持强复制左（强制整体开源） → GPL-3.0（或历史上的 GPL-2.0-only）。
• SaaS 也要触发开源义务 → AGPL-3.0（闭源商用慎用其依赖）。
• 为库选择“弱复制左” → LGPL-2.1/3.0（动态链接通常可闭源，静态需可重链接）。
• Rust 生态普遍做法 → MIT OR Apache-2.0 双许可；Dart/Flutter 生态常见 BSD-3/MIT。

核心概念速览#

• 复制左（Copyleft）强度：
  • 宽松（Permissive）：MIT、BSD、Apache-2.0 —— 几乎不“传染”。
  • 弱复制左（Weak Copyleft）：LGPL、MPL-2.0、EPL-2.0 —— 仅对库、文件或模块层面施加义务。
  • 强复制左（Strong Copyleft）：GPL、AGPL —— 派生整体需 GPL/AGPL 开源。
• 专利授权（Patent Grant）：Apache-2.0、GPLv3 家族、MPL-2.0、EPL-2.0 包含；MIT、BSD 通常不含。
• SaaS 触发：仅 AGPL 明确要求对网络交互用户提供源代码（尤其对修改版）。
• NOTICE/署名：Apache-2.0 要求携带 NOTICE；MIT/BSD 要保留版权与许可文本。
• 链接与“衍生作品”：LGPL 对动态/静态链接有不同要求；GPL 对组合/链接更严格；MPL-2.0 是文件级。

对比矩阵（工程师视角）#

纵向滚动查看要点，横向按许可证对比。

典型场景选型#

1. 通用应用/库，追求传播与商用灵活

   • 首选：Apache-2.0（或 MIT OR Apache-2.0 双许可，Rust 社区常见）。
   • 考虑：若组织对专利较敏感且无需 NOTICE，MIT 也可；但更推荐 Apache-2.0。

2. 希望“只开放被修改的那部分”

   • 选：MPL-2.0（文件级复制左），或 EPL-2.0（模块级）。
   • 适合：SDK、插件体系、浏览器扩展类、企业内平台组件。

3. 坚持社区“回流”，不介意影响闭源整合

   • 选：GPL-3.0（或历史原因用 GPL-2.0-only）。
   • 注意：与闭源/Apache-2.0 依赖的兼容与分发边界。

4. 网络服务也要开源义务

   • 选：AGPL-3.0。
   • 提醒：闭源公司采纳其依赖前要评估合规风险与替代方案。

5. 商用闭源 App 依赖开源库

   • 优先：MIT / BSD / Apache-2.0 / MPL-2.0 / EPL-2.0 / LGPL。
   • 谨慎：GPL/AGPL 直接链接或合并代码路径。

6. Rust / Dart 生态实践

   • Rust：大量 crate 采用 MIT OR Apache-2.0（双许可，最大化下游兼容）。
   • Dart/Flutter：官方 SDK 与众多包多见 BSD-3-Clause 与 MIT；企业级组件可考虑 MPL-2.0 以保护修改面。

兼容性与合并实务（高频疑问）#

• Apache-2.0 × GPL：
  • 与 GPL-2.0：不兼容。
  • 与 GPL-3.0：可兼容（组合分发走 GPLv3）。
• MPL-2.0 的 Secondary License：若没有标注 “Incompatible With Secondary Licenses”，可在特定条件下转至 GPLv2/GPLv3/LGPL/AGPL，便于生态互通。
• LGPL 动态链接：通常不“传染”应用，但需允许用户替换库（例如提供 .so/.dylib 或可重链接方式）；静态链接需要提供可重链接目标或等效机制。
• AGPL 在 SaaS 场景：你修改了 AGPL 程序并通过网络提供服务 → 需要向交互用户提供对应源代码。未修改时义务更轻，但常见做法也会提供源码链接以避免争议。
• 商标与背书：许可证通常不授予商标使用权；Apache-2.0 明确有非背书/商标条款；BSD-3 有非背书条款。

合规清单（Distribution/发布时）#

宽松许可（MIT/BSD/Apache-2.0）

• 保留上游 LICENSE；Apache-2.0 另需携带/合并 NOTICE。
• 在 About/文档中保留版权与署名；如有改动，建议标注。

弱复制左（LGPL/MPL-2.0/EPL-2.0）

• 修改过的被覆盖文件/模块的源代码需一并提供或可获取方式。
• LGPL：动态链接 OK；静态链接需提供可重链接手段/目标文件。
• 在发行包中附上对应 LICENSE 与变更说明。

强复制左（GPL/AGPL）

• 若分发二进制，必须同时提供对应源码或获取方式（等价可得）。
• AGPL：网络交互（尤其修改版）需向服务用户提供源码获取入口。

通用

• 在仓库根目录放置 LICENSE，并在 README 标注。
• 使用 SPDX 标识（如：License: MIT 或 SPDX-License-Identifier: Apache-2.0）。
• 保留第三方依赖的 LICENSE/NOTICE 汇总（可自动生成）。

常见踩坑#

1. 忽略专利条款：MIT/BSD 不含专利授权；在受专利敏感的领域更偏向 Apache-2.0/MPL-2.0/GPLv3/EPL-2.0。
2. 把 LGPL 当 MIT 用：静态链接或不提供可重链接方式会违规。
3. 误解 MPL：它的复制左只覆盖被修改的 MPL 文件本身，不会“传染”整个工程。
4. 混用 GPL-2.0 与 Apache-2.0：二者不兼容，发布前做清理。
5. SaaS 忽视 AGPL：选依赖前先过一遍合规评估。
6. 漏掉 NOTICE：使用 Apache-2.0 组件时，NOTICE 文件务必保留。
7. 把“源可得”当“开源”：如 SSPL、BSL、PolyForm 等非 OSI 开源许可，合规与生态接受度不同，务必区分。

给维护者的选型建议（含模板）#

• 通用库/工具：MIT OR Apache-2.0（双许可）。
• 仓库做法：在每个源码文件头添加 SPDX-License-Identifier: MIT OR Apache-2.0；根目录放两份完整 LICENSE 与合并的 NOTICE（如需）。
• 平台可扩展组件（希望外部贡献回流但不影响闭源）：MPL-2.0。
• 要点：仅修改的 MPL 文件需开源；可选加上 Secondary License 兼容声明。
• 带强价值积累且必须开源回馈：GPL-3.0 / AGPL-3.0（SaaS 也要回流则选 AGPL）。

SPDX 示例（放在文件头，工具友好）：

1
// SPDX-License-Identifier: MIT
2
// SPDX-License-Identifier: MIT OR Apache-2.0
3
// SPDX-License-Identifier: MPL-2.0
4
// SPDX-License-Identifier: GPL-3.0-or-later
5
// SPDX-License-Identifier: AGPL-3.0-only

FAQ（工程化细节）#

• 发布到 iOS/Android 应用商店算“分发”吗？
  • 是。若包含 GPL 代码并形成派生作品，你需要提供对应源码获取方式。
• 仅在公司内部用算“分发”吗？
  • 纯内部使用通常不构成分发（AGPL 在对内网络交互下要求也较宽松），但一旦对外提供或对外部用户可访问，需要重新评估。
• 我没修改 AGPL 程序，只部署未改动版本提供服务？
  • 义务显著减轻；但为稳妥常见做法也会提供上游源码链接与许可文本。
• 依赖树里混有不同许可证怎么办？
  • 建立 SBOM（软件物料清单）与许可清单，用 SPDX/扫描工具自动汇总 LICENSE/NOTICE 并在发行物中合并。

一句话版#

• MIT：给你几乎所有自由，只要保留版权与许可文本。
• BSD-2/3：与 MIT 类似，3-Clause 多了“非背书”条款。
• Apache-2.0：宽松 + 专利授权/反诉终止 + NOTICE 要求。
• LGPL：库友好；动态链接一般不“传染”，静态需可重链接。
• MPL-2.0：文件级复制左，只开你改动过的文件。
• EPL-2.0：企业常用的弱复制左；可选二次许可与 GPL 互通。
• GPL-2.0/3.0：强复制左；v3 更关注反 DRM/反 Tivoization。
• AGPL-3.0：把复制左延伸到网络服务场景。
• Unlicense/CC0：近似公有领域，但不含专利授权。