开源协议与知识共享协议 License许可指南

前言：为什么需要理解这些协议？

在软件开发、内容创作和技术交流中，许可证决定了他人能以何种方式使用你的作品，也决定了你能以何种方式使用他人的成果。理解不同协议的核心差异，不仅能帮你规避法律风险，还能让你在开源协作中做出更明智的选择。

本文整合了经典开源软件协议、知识共享（CC）协议家族，以及实践中常见的自定义协议类型，按照从严格到宽松的顺序进行系统梳理。

第一部分：经典开源软件协议（从严格到宽松）

1. AGPL（GNU Affero General Public License）

严格程度：★★★★★（最严格）

AGPL 是目前开源协议中最严格的协议之一。它在 GPL 的基础上，堵上了一个著名的"SaaS 漏洞"。

核心条款：

• 不仅代码的分发需要开源，如果你通过网络向用户提供服务（比如 SaaS 应用），也必须将完整的服务端源代码公开给所有用户。
• 任何基于 AGPL 代码的衍生作品，整个项目都必须以 AGPL 协议开源。

关键背景：除了 AGPL，其他许可证都规定只有在"分发"时才需要遵守许可证。云服务（SaaS）是否构成"分发"呢？答案是不构成。AGPL 正是为了防止"白嫖"而设计——它规定云服务也必须提供源码。

适用场景：旨在防止云服务商"白嫖"开源项目却不回馈社区的项目。

典型项目：MongoDB（早期）、RocketChat。

商业风险：极高。绝大多数商业公司会禁止在内部或云服务中使用 AGPL 代码。如果你想用 AGPL 代码提供商业服务，必须做好开源全部代码的准备。

2. GPL（GNU General Public License）

严格程度：★★★★☆

GPL 是最富盛名的"Copyleft"协议，有着强"传染性"。它由理查德·斯托曼为 GNU 计划而撰写，保证终端用户运行、学习、分享及修改软件的自由。

核心条款：

• 任何基于 GPL 代码的衍生作品，整个项目都必须以 GPL 协议开源，禁止闭源商用。
• 动态或静态链接 GPL 库都可能触发此要求。
• 支持商业用途，但必须开源！

版本差异：

实际影响：GPL 协议有点像病毒，一旦被感染，整个项目就演变成了 GPL 项目，强制开源——再也回不到过去了！程序库尤为需要关注：在 GPL-v2 协议下发布库，你将强制使用该库的任何应用程序也在 GPL 协议下发布。

典型项目：Linux、GCC、scapy。

重要说明：Linux 内核维护者为何反对 GPLv3？

Linux 内核的维护者们一直反对 GPL-v3 协议，这造成了 GPL 在版本 2 和 3 之间的分裂。核心分歧如下：

（1）对"Tivo化"（Tivoization）的限制

GPLv3 增加了一条重要规定：如果设备运行了 GPLv3 的软件，那么必须允许用户安装他们自己修改过的版本。这是为了阻止硬件厂商通过技术手段锁定设备，不让用户修改。但 Linux 创始人林纳斯·托瓦兹认为，软件许可证不应该去管硬件设计。

（2）数字版权管理（DRM）条款

GPLv3 的 DRM 相关条款与"Tivo化"问题紧密相关。托瓦兹对此表示强烈反对，认为这超出了软件许可的范围，甚至称这些要求"很疯狂"。

（3）专利授权条款

GPLv3 增加了明确的专利授权条款，而托瓦兹认为 GPLv2 在这方面的"模糊"处理对内核来说已经足够，引入新条款反而增加复杂性。

（4）理念分歧：实用主义 vs. 自由软件哲学

更深层的原因在于理念。托瓦兹代表了一种实用主义，他希望 Linux 能被广泛使用，包括被商业公司使用，因此不愿加入可能限制使用方式的条款。而自由软件基金会起草的 GPLv3 则更偏向纯粹的自由软件哲学，试图用许可证来捍卫软件自由。

最终结果：Linux 内核继续使用 GPLv2，许多内核主要贡献者也持相同观点。这使得开源世界的两大旗帜——Linux 内核（GPLv2）和许多新项目（GPLv3）在许可证上产生了根本性的分裂。两者在重要条款上不兼容，意味着一个 GPLv2 的项目原则上不能直接合并 GPLv3 的代码。

商业风险：高。一旦在项目中使用，就可能被迫开源全部代码，有真实的法律纠纷案例。

3. LGPL（GNU Lesser General Public License）

严格程度：★★★☆☆

LGPL 是 GPL 的类库友好版，属于弱 Copyleft 的代表。最初被称为"Library GPL"（库 GPL），后改为"Lesser GPL"（更宽松的 GPL）。

核心条款：

• 允许商业软件通过动态链接的方式调用 LGPL 库，而不需要开源商业软件本身的代码。但前提是：用户必须有能力自行替换该 LGPL 库的版本。如果商业软件通过技术手段（如签名校验、私有加载器）阻止用户替换该 .so/.dll 文件，即使采用动态链接也可能违规。
• 如果修改了 LGPL 库本身或静态链接，则需要开源。
• 如果使用静态库方式链接，则退化为 GPL 授权。

举例说明：

小益使用 LGPL 协议开源了一个 Android 类库，小张做开发时调用了该库。之后小张将项目上架到 GooglePlay 而不开源，这是没有违反协议的。但是如果小张引用类库时，是以源码的形式引用的，那就必须要将项目开源了。

适用场景：非常适用于被广泛引用的第三方类库。

典型项目：GTK、FFmpeg。

商业风险：中等。需要仔细区分动态链接和静态链接的使用方式，并确保用户有替换库的自由。

4. MPL（Mozilla Public License）

严格程度：★★★☆☆

MPL 被称为文件级的 GPL，是又一个经典的弱 Copyleft 协议。

核心条款：

• 如果你修改了 MPL 协议下的某一个文件，那么这个文件必须开源。
• 但与同项目的其他文件（如你的闭源代码）可以不受影响。
• 修改后的文件版权归修改者所有，但整体文件仍需遵循 MPL 开源。
• 支持模块外的源代码闭源，便于商业软件引用 MPL 的模块（库）。

举例说明：

小益使用 MPL 协议开源了一个 Android 类库，小张对源码进行修改以后重新发布，修改部分的版权归小张所有，但修改后的文件仍需遵循 MPL 协议开源。

适用场景：适合既要保持核心模块开源协作，又想保留部分代码闭源的项目。

典型项目：Firefox 浏览器。

5. Apache License 2.0

严格程度：★★☆☆☆

Apache 许可证是企业友好型的宽松协议，在 MIT 的基础上增强了法律保护。由 Apache 软件基金会发布，最初为 Apache HTTP 服务器而撰写。

核心条款：

• 专利授权：明确授予用户专利使用权，并包含"专利报复"条款——如果你对该代码的贡献者或使用者发起专利诉讼，你的专利授权将自动终止。
• 修改声明：修改过的文件需要明确说明（State Changes）。
• 保留声明：需要保留版权声明、免责声明和 NOTICE 文件。
• 明确禁止商标使用权。

效力对比：宽松程度与 MIT 近似，但法律保护更强，主要体现在专利授权的明确性上。

兼容性注意：Apache 2.0 与 GPLv3 兼容，但与 GPLv2 不兼容。

适用场景：适合需要专利保护的大型项目，以及希望被广泛用于商业场景的开源项目。

典型项目：Kubernetes、TensorFlow、Android、Spring Boot。

商业风险：低。

6. BSD（Berkeley Software Distribution）

严格程度：★☆☆☆☆

BSD 协议授予使用者很大的自由，基本上可以"为所欲为"——自由使用、修改源代码，也可以将修改后的代码作为开源或专有软件再发布。

核心条款（以 3-Clause 为例）：

• 可以随意使用，支持商业闭源。
• 必须署名原作者（保留版权声明和免责条款）。
• 不可以用开源代码的"作者/机构的名字"或"原来产品的名字"做市场推广。

版本差异：

适用场景：对商业集成很友好的协议，很多企业首选 BSD 协议，因为可以完全控制第三方的代码，在必要时可以修改或二次开发。

典型项目：FreeBSD、Go 语言早期版本。

7. MIT License

严格程度：☆☆☆☆☆（最宽松）

MIT 协议是最流行、限制最少的协议之一。作者只想保留版权，而无任何其他限制。

核心条款：

• 允许别人以任何方式使用，支持商业闭源。
• 必须署名原作者（在发行版中包含原许可协议的声明）。
• 原作者不承担代码使用后的风险（免责声明）。

举例说明：

小益使用 MIT 协议开源了一个 Android 类库，只要小张引用类库时保留了包含许可声明，那后续项目开源与否，都是符合协议的。

风险提示：因为没有明确的专利授权条款，存在潜在的专利纠纷风险——但这取决于具体的司法管辖区和案件情况。

典型项目：React、Vue.js、Node.js。

商业风险：最低。

第二部分：知识共享（Creative Commons）协议家族（常用版）

适用于文字、图片、视频、音乐、数据集等非软件作品

重要警告：Creative Commons 官方明确不建议将 CC 协议用于软件或源代码。CC 协议缺乏对源码分发、编译产物、专利等软件特有问题的处理条款，混用会导致严重的法律不确定性。软件请务必使用第一部分所述的开源许可证。

CC 协议（Creative Commons，知识共享协议）主要应用于非软件作品。以下 4 种是实践中最主流、最常见的协议。所有版本均以 4.0 国际版 为准（2013 年发布，是目前最新且适用范围最广的版本）。

CC 协议速览（仅限 4.0 国际版）

各协议详解（4.0 国际版）

（1）CC BY-NC-ND（署名-非商业-禁止演绎）

严格程度：★★★★★（最严格）

核心要求：

• 允许他人下载和分享作品
• 必须署名
• 不得用于商业目的
• 不得修改、改编或基于此创作衍生作品

典型场景：

• 学术论文、研究报告
• 原始采访记录
• 希望保护作品完整性、不希望被断章取义的内容

特别说明：这就是我们聊天中提到的 "CC BY-NC-ND 4.0-style intent" 所对应的协议。

（2）CC BY-NC-SA（署名-非商业-相同方式共享）

核心要求：

• 允许他人修改和再创作
• 必须署名
• 不得用于商业目的
• 衍生作品必须使用相同许可证（SA = ShareAlike）

典型场景：

• 希望作品被自由改编但保持非商业性质
• 要求衍生作品也保持同样的开放性
• 适合协作式非商业项目

（3）CC BY-NC（署名-非商业）

核心要求：

• 允许他人修改和再创作
• 必须署名
• 不得用于商业目的
• 对衍生作品的许可证不做限制（可以改用其他非商业协议）

典型场景：

• 允许学术或教育机构自由使用和改编
• 防止企业直接拿去盈利的教材、研究成果
• 创作者希望保持"非商业共享"的灵活性

（4）CC BY（署名）

严格程度：☆☆☆☆☆（最宽松）

核心要求：

• 允许任何人以任何方式使用（包括修改、再创作、商业用途）
• 唯一要求：必须署名
• 无需使用相同协议分发（衍生作品可以闭源）

典型场景：

• 被认为是开放获取的"黄金标准"
• 适合希望作品被最广泛传播和利用的内容
• 学术论文、开放教材、政府开放数据等

补充说明：CC BY 是 CC 协议家族中最接近公共领域（CC0） 的协议，但保留了署名要求。

版本说明：为什么都推荐使用 4.0？

结论：新作品应一律使用 4.0 版本，除非有特定历史兼容性需求。

一句话总结

第三部分：自定义协议与其他特殊场景

除了标准化的开源协议和 CC 协议，在现实世界中你还会遇到大量"自定义协议"或特殊场景。

1. "源码可见"但"保留所有权利"（All Rights Reserved）

形式：项目根目录下有个 LICENSE 文件，但内容并非任何开源协议，而是写明了"All Rights Reserved"或自定义的条款。

含义：

• 这是最严格的版权保留声明，意味着作者没有授予任何默认的、自由使用的权限。
• 通常允许你为了学习在本地查看和运行。
• 严格禁止修改后的分发、复刻（Fork）以及任何形式的商业使用。

重要区别：它不是开源软件，只是"源码可见"的专有软件。

示例（来自我们聊天中的案例）：

Source is All Rights Reserved, guided by CC BY-NC-ND 4.0-style non-commercial / no-derivatives intent.

• 个人学习/本地构建：允许
• 修改/复刻/分发构建产物：禁止
• 商业/生产/付费交付：禁止（需购买商业许可）

对你的影响：修改后的代码上传到公开仓库是明确禁止的再分发行为。对于私有仓库，虽然处于灰色地带，但更安全的做法是仅在本地用 Git 管理版本。商业使用必须购买商业许可证。

2. 商业软件许可协议（EULA）

形式：通常是一份冗长的法律文本，出现在软件安装时的"最终用户许可协议"（End-User License Agreement, EULA）中，或在采购合同时签订的条款里。

常见限制：

• 限制软件安装的终端数量
• 限制使用的地理范围
• 是否允许反向工程
• 明确规定服务等级（SLA）和支持条款
• 赔偿与责任上限条款

与开源协议的区别：追求广泛传播的开源协议不同，商业许可的目标是保护商业利益和控制使用方式。

3. 延迟开源协议（BSL - Business Source License）

形式：一种混合模式，代码在一段时间内（如4年）按自定义的商业协议运行，限制云服务等用途，到期后自动转为宽松的开源协议（如 Apache 2.0）。

含义：允许开发者在项目初期通过商业许可获利或控制其使用范围，同时承诺未来会将其彻底开源。

典型项目：CockroachDB。

4. SSPL（Server Side Public License）

形式：为云时代而生的服务端强 Copyleft 协议。

特点：

• 在 GPL 基础上要求，如果你将 SSPL 协议下的软件作为云服务提供给他人，就必须把包括管理工具、运维平台在内的整个服务栈代码都开源。

争议：SSPL 未被开源倡议组织（OSI）认可为"开源协议"，被拒绝的具体原因是歧视特定领域的使用者，违反了开源定义的第六条（不歧视）。商业使用风险极高。

典型项目：MongoDB（后期版本）。

同类参考：Elastic License 2.0 是另一种"源码可用"的现代协议，常作为 SSPL 的替代方案出现。

5. 使用 UNLICENSED 声明

形式：在项目配置文件中（如 package.json 或 Cargo.toml）将 license 字段设置为 "UNLICENSED"。

含义：这是一种明确的声明，表示该软件包是私有的，未授权给任何公众使用、修改或分发，除非作者另行单独授权。

重要区分：这完全不同于 Unlicense（公共领域贡献）。UNLICENSED = 保留所有权利；Unlicense = 放弃所有权利。

补充：CC0 / Unlicense（公共领域贡献）

位置：在严格度谱系的最宽松端。

核心要求：放弃所有版权，允许任何人以任何方式使用，无需署名。

典型场景：相当于"不保留任何权利"，将作品直接置于公共领域。

实际重要性：在数据科学、AI 训练集和开放数据领域，CC0/Unlicense 具有极高的实用性，因为数据集通常包含大量来自不同来源的信息，逐一署名不现实。许多政府开放数据和公共数据集都采用 CC0 协议。

注意：Unlicense 和 CC0 在目的上相似，但 Unlicense 主要针对软件，CC0 更通用。两者都存在少量司法管辖区不完全承认的问题，但在实践中被广泛接受。

第四部分：常见问题与注意事项

Q1：开源软件的专利如何处理？

• 包含明确专利条款的协议：Apache 2.0 和 GPLv3 包含明确的条款，授予用户使用软件所包含的所有专利的许可。
• 未提及专利的协议：BSD、MIT 和 GPLv2 未明确提及专利。法律界普遍认为它们包含隐含的专利许可，但这仅针对作者有权授权的专利。MIT/BSD 的"隐含专利许可"在学术界存在争议，并未在所有司法管辖区得到确认。
• 重要限制：如果代码侵犯了第三方专利，开源协议无法提供保护。开源作者可能根本不拥有相关专利权（例如专利属于其雇主或第三方）。
• 总结：除非有明确的"保留专利"的条款，使用开源软件通常不构成侵犯作者专利，但不保证不侵犯第三方专利。在商业使用前进行专利检索是审慎的做法。

Q2：违反协议有什么后果？

很多公司希望避开 GPL 条款，既使用 GPL 软件，又不把自己的专有代码开源。理论上，这是做不到的。因为 GPL 的设计目的，就是为了防止出现这种情况。

实际法律执行：

• 法院通常无法直接强制被告公开源码，但可以颁布禁令（Injunction），禁止其继续分发侵权软件。
• 在实践中，为了避免产品下架或巨额赔偿，违规方往往被迫通过和解方式履行开源义务（如公开源码）。
• 德国等部分司法管辖区的判例对 GPL 执行更为严格，可能涉及更积极的执行措施。

关键点：不遵守 GPL 的风险不仅仅是"停止使用"，而是可能导致整个商业产品无法分发，因此合规非常重要。

Q3：云服务（SaaS）是否构成"分发"？

通常答案：不构成。使用开源软件提供云服务，不必提供源码。

例外：AGPL 和 SSPL 协议除外，它们规定云服务也必须提供源码。

Q4：如何为我的项目选择合适的协议？

Q5：上游项目突然变更协议，我该怎么办？

核心原则：许可证不可追溯撤销。 已发布的旧版本永远以旧协议存在，协议变更只影响新版本。

不同场景的应对：

版本兼容性速查：

• GPLv2 与 GPLv3：若原项目声明"GPLv2 或更高版本"，可自动升级使用；若声明"仅限 GPLv2"，则与 GPLv3 不兼容，无法混用。
• MIT/Apache 2.0 → GPL：升级后需遵循 GPL 要求（如整体开源），可考虑停留在旧版本。
• GPL → AGPL：新增网络服务开源要求，若对外提供 SaaS 服务需特别注意。
• 开源 → 闭源/商业协议：最后一个开源版本永久可用。新版本需购买商业许可或寻找替代方案。

典型案例：MongoDB（AGPL → SSPL）、Elasticsearch（Apache 2.0 → SSPL + Elastic License）、Redis 模块（AGPL → SSPL/RSALv2）。这些变更均未影响已发布旧版本，但导致许多发行版停止打包新版本，AWS 等云厂商则 Fork 了最后一个开源版本继续维护。

建议：在项目依赖文件中锁定明确版本号（而非追踪最新版），避免无意中升级到新协议版本。

第五部分：总结——从严格到宽松的完整谱系

将本文涵盖的所有协议按严格程度排序：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

更严格 --------------------------------------------------------------------> 更宽松
 
AGPL
  ↓
GPLv3
  ↓
GPLv2
  ↓
CC BY-NC-ND
  ↓
CC BY-NC-SA
  ↓
LGPL
  ↓
MPL
  ↓
CC BY-NC
  ↓
Apache 2.0
  ↓
BSD-3-Clause
  ↓
MIT / BSD-2-Clause
  ↓
CC BY
  ↓
CC0 / Unlicense

注：此排序基于对使用者自由的限制程度。软件协议与内容协议的义务性质不同（例如"强制开源" vs "禁止修改"），不可直接横向比较合规成本，此图仅用于直观理解相对宽松度。

附录：快速决策指南

如果你是项目作者，选择协议时先问自己三个问题：

1. 是否允许商业使用？ 如果"否"，考虑 CC BY-NC 或"保留所有权利+明确条款"。
2. 是否要求衍生作品也开源？ 如果"是"，考虑 GPL 或 AGPL；如果只是修改的部分开源，考虑 LGPL 或 MPL。
3. 是否需要专利保护？ 如果"是"，考虑 Apache 2.0 或 GPLv3。

如果你是项目使用者，使用前先问自己三个问题：

1. 我能不能闭源商用？ 检查协议是否允许（MIT/BSD/Apache/LGPL 允许；GPL/AGPL 禁止）。
2. 如果我修改了代码，需要开源什么？ 检查协议的"传染性"范围。
3. 如果我把代码部署成在线服务，需要开源吗？ 如果使用 AGPL/SSPL，需要；其他协议通常不需要。

免责声明：本文仅供学习参考，不构成法律建议。在涉及实际法律事务时，请咨询专业律师。本文内容基于截至 2026 年的法律实践，开源协议的解释可能随司法判例演变而变化。

AI