开源软件开源协议详解与选择指南
本文梳理常见开源协议的内容、宽松程度差异及使用注意，并附协议选择决策表与快速判断流程。
目录
一、开源协议的概念
**开源协议（Open Source License）**是在开源软件发布时附带的许可条款，规定了使用者可以如何使用、修改、分发该软件的代码及衍生作品。不同协议对使用者的自由度和义务限制不同，因此常被区分为「宽松」或「严格」。
二、常见开源协议分类
| 类型 |
英文 |
要点 |
| 宽松型 |
Permissive |
限制少，常允许闭源再发布，一般要求保留原版权声明 |
| 强 Copyleft |
Strong Copyleft |
衍生作品通常须以相同协议开源，限制闭源使用 |
| 弱 Copyleft |
Weak Copyleft |
部分场景可与闭源代码结合，核心或修改部分仍须开源 |
三、常见开源协议详解
1. MIT License
| 项目 |
说明 |
| 类型 |
宽松型 |
| 核心 |
允许自由使用、复制、修改、合并、发布、分发、授权和销售；须保留原始版权与许可声明 |
| 宽松度 |
非常宽松 |
| 注意 |
商业可闭源；必须保留原版权信息 |
| 适用 |
希望广泛传播、法律风险低的库或工具 |
2. Apache License 2.0
| 项目 |
说明 |
| 类型 |
宽松型 |
| 核心 |
允许商业使用、修改、分发；明确专利授权；须保留版权/专利/商标/许可声明；修改文件须注明变更 |
| 宽松度 |
宽松，比 MIT 多专利与声明要求 |
| 注意 |
须披露使用 Apache 代码；修改文件需说明更改 |
| 适用 |
企业级项目，尤其涉及专利时 |
3. ISC License
| 项目 |
说明 |
| 类型 |
宽松型 |
| 核心 |
条款极短：允许使用、复制、修改、分发；须保留版权与许可声明 |
| 宽松度 |
与 MIT 接近，常被视作等价选型 |
| 注意 |
无专利明示条款（与 Apache 2.0 不同） |
| 适用 |
大量开源库（尤其 Node/npm 生态）采用 |
4. BSD License（2-Clause / 3-Clause）
| 项目 |
说明 |
| 类型 |
宽松型 |
| 核心 |
2-Clause：版权 + 免责声明；3-Clause：另加不得用原作者名义推广 |
| 宽松度 |
非常宽松，接近 MIT |
| 注意 |
3-Clause 禁止用作者名做广告 |
| 适用 |
科研、教育、轻量项目 |
5. GPL（v2 / v3）
| 项目 |
说明 |
| 类型 |
强 Copyleft |
| 核心 |
基于 GPL 的衍生作品须以 GPL 开源；须提供源码并允许他人使用、修改、再分发。v3 增加反「Tivo 化」、更明确的专利授权等 |
| 宽松度 |
不宽松，闭源使用受限 |
| 注意 |
链接/包含 GPL 代码时，整体常须 GPL 开源；不能与大量非兼容协议混成闭源产品。GPLv2 与 Apache 2.0 通常被认为不兼容 ；GPLv3 可与 Apache 2.0 组合（同一项目混用时须整体满足 GPLv3） |
| 适用 |
强调自由软件理念的项目 |
6. LGPL
| 项目 |
说明 |
| 类型 |
弱 Copyleft |
| 核心 |
动态链接 LGPL 库的闭源程序可不开源；修改 LGPL 库本身则须以 LGPL 开源 |
| 宽松度 |
介于宽松与强 Copyleft 之间 |
| 注意 |
静态链接可能触发更严条款 |
| 适用 |
希望被闭源软件调用的库 |
7. MPL 2.0
| 项目 |
说明 |
| 类型 |
弱 Copyleft |
| 核心 |
修改过的受 MPL 覆盖文件须以 MPL 开源；新增文件可闭源；与 GPL 默认不兼容（需额外处理） |
| 宽松度 |
中等，比 GPL 宽松、比 MIT 严 |
| 注意 |
需分清哪些文件受 MPL 约束 |
| 适用 |
大型项目希望核心开源、外围可闭源 |
8. AGPL
| 项目 |
说明 |
| 类型 |
强 Copyleft |
| 核心 |
类似 GPL，但增加网络服务场景：通过网络提供服务时通常须提供对应源码 |
| 宽松度 |
最严格之一 |
| 注意 |
SaaS 需特别谨慎；部署 AGPL 代码的服务往往须开源相关代码 |
| 适用 |
防止云服务商闭源使用而不回馈 |
9. Unlicense
| 项目 |
说明 |
| 类型 |
公共领域倾向 |
| 核心 |
放弃版权，意图进入公共领域 |
| 宽松度 |
极宽松 |
| 注意 |
部分法域对「公共领域」声明认定不同，可配合其他许可 |
| 适用 |
希望代码尽可能无限制使用 |
10. CC0
| 项目 |
说明 |
| 类型 |
公共领域/放弃权利（多用于非软件） |
| 核心 |
常用于文档、图片、数据等，放弃版权 |
| 宽松度 |
极宽松 |
| 注意 |
软件更常用 Unlicense 或 MIT |
| 适用 |
开放数据、文档、媒体资源 |
四、宽松程度比较（从最宽松到最严格）
复制代码
公共领域类 → Unlicense、CC0（非代码常用 CC0）
超宽松类 → MIT、ISC、BSD 2-Clause、BSD 3-Clause
宽松+专利 → Apache 2.0
弱 Copyleft → LGPL、MPL 2.0
强 Copyleft → GPL v2 / v3
网络服务最严 → AGPL
五、使用开源协议时的注意事项
| 要点 |
说明 |
| 兼容性 |
不同协议可能不兼容；GPLv2 与 Apache 2.0 常被视为不兼容，升级链路或选 GPLv3 才易与 Apache 2.0 代码同项目组合 |
| 版权声明 |
宽松协议通常仍要求保留原作者版权与许可声明 |
| 专利 |
Apache 2.0、GPLv3、AGPL 等含专利相关条款，可降低部分诉讼风险理解成本 |
| 衍生作品 |
强 Copyleft 对「链接/组合」是否构成衍生作品认定严格 |
| SaaS |
AGPL 对「通过网络提供服务」有额外开源要求，影响商业模式 |
| 贡献者协议 |
部分项目要求签署 CLA（Contributor License Agreement） |
说明 ：具体是否构成衍生作品、静态/动态链接是否触发义务，应以正式法律意见 与协议全文为准，本文仅供技术选型参考。
六、开源协议选择决策表
| 需求 / 场景 |
推荐协议 |
理由简述 |
| 最大程度自由、闭源商用也可 |
MIT / ISC / BSD 2-Clause / Unlicense |
宽松，一般仅保留版权声明；Node 生态常见 ISC |
| 商业项目且关注专利表述 |
Apache 2.0 |
宽松 + 专利授权条款，常见企业选择 |
| 库可被闭源程序调用 |
LGPL |
动态链接主程序常可闭源；改库须开源 |
| 禁止闭源衍生、强调自由软件 |
GPL v2 / v3 |
强 Copyleft |
| 防止闭源云服务白嫖代码 |
AGPL |
网络服务场景源码义务更严 |
| 只开源核心模块、外围闭源 |
MPL 2.0 |
弱 Copyleft，通常修改过的 MPL 文件须开源 |
| 文档、图片、数据集等非代码 |
CC0 |
放弃版权，便于复用 |
| 希望全球无版权限制倾向 |
Unlicense / CC0 |
注意法域差异 |
| 要兼容 GPL 但不想全项目 GPL |
LGPL 或 MPL |
弱 Copyleft，约束面更小 |
| 参与现有大项目 |
遵循项目已有协议 |
如 Linux GPLv2、Firefox MPL 2.0 等 |
七、快速判断流程
复制代码
是否允许闭源商用？
├─ 是 → MIT / Apache 2.0 / BSD / Unlicense
└─ 否 → 是否要求衍生作品也开源？
├─ 是 → GPL / AGPL（若含网络服务且要防 SaaS 闭源 → AGPL）
└─ 否 → 是否为「库」且希望闭源主程序调用？
├─ 是 → LGPL / MPL
└─ 否 → 选宽松协议（MIT / Apache 2.0）
是否主要为非代码资源？ → CC0 等
实操建议 ：用上表与流程缩小范围后，再阅读所选协议的完整官方文本，必要时咨询法务。
八、补充：其他协议与实务要点
8.1 文档与媒体：Creative Commons 系列（除 CC0 外）
| 许可 |
要点 |
| CC BY |
署名即可，较宽松，适合希望保留署名权的文档/配图 |
| CC BY-SA |
署名 + 衍生作品须同许可（类似 Copyleft），与部分商业二次创作需核对 |
| CC BY-NC |
非商业；不建议用于「开源软件配套文档」的通用发布（限制商用传播） |
| CC0 |
放弃权利，最利于任意复用（与上文一致） |
软件源码本身仍优先用 OSI 认可的软件许可（MIT、Apache 等），不要用 CC-BY 当主代码许可。
8.2 其他较常见软件许可（简表）
| 许可 |
类型 |
要点 |
| EPL 2.0 |
弱 Copyleft |
Eclipse 系；修改贡献通常须开源 |
| CDDL |
弱 Copyleft |
文件级 Copyleft，与 GPL 兼容性历史上常需个案判断 |
| EUPL |
弱~强之间可选 |
欧盟官方多语言版本，与 GPLv2 等有一定兼容设计 |
| zlib |
宽松 |
类似 BSD，游戏/图形库常见 |
8.3 「源码可得」但非传统开源（选型时注意）
部分许可提供源码 但限制商业托管或竞争服务，OSI 开源定义下可能不被认可为开源 。若在依赖库中遇到 SSPL 等，应单独阅读全文并评估是否与产品形态冲突，不可按 MIT 同等对待。
8.4 双重许可（Dual Licensing）
同一项目可同时提供：社区版（如 GPL） + 商业许可（付费闭源使用）。企业采购时常买后者以获得闭源分发权；贡献代码前需看清是否要求版权转让或只接受某种许可下的贡献。
8.5 如何确认「这个项目到底是什么协议」
复制代码
仓库根目录 LICENSE / COPYING / LICENSE.md
package.json 的 "license" 字段（Node）
Cargo.toml license（Rust）
SPDX-License-Identifier（源文件头注释）
发行页 / 官网法律说明
复杂仓库可能多文件多许可 （如核心 MIT、某子目录 GPL），须按路径分别遵守。可用 SPDX 、SBOM（软件物料清单）做依赖协议审计。
8.6 兼容性速查（示意，不替代法务）
| 组合 |
常见结论（概括） |
| MIT + Apache 2.0 |
可一同用于可再分发作品，通常需保留两类声明 |
| GPLv2 + Apache 2.0 |
多认为不兼容，勿想当然合并 |
| GPLv3 + Apache 2.0 |
GPLv3 项目可纳入 Apache 2.0 代码（整体遵循 GPLv3） |
| LGPL 库 + 闭源主程序 |
动态链接场景常被讨论为可行；静态链接须谨慎 |
根据常见开源许可知识整理，选型请以协议原文与专业法律意见为准。