详细对比所有开源许可及其不同版本

qwen

以下是基于知识库内容对常见开源许可证及其不同版本的详细对比，重点突出版本间差异和核心条款变化：

---

1. GPL（GNU General Public License）

• 版本: v2 vs v3
  • GPLv2（1991）:
    • 要求衍生代码开源，但未明确专利授权条款 [[4]]。
    • 允许通过“类库例外”（如GCC运行时库例外）实现与非GPL代码的兼容 [[9]]。
  • GPLv3（2007）:
    • 新增专利授权条款，禁止通过专利诉讼限制用户权利 [[9]]。
    • 禁止通过技术手段（如DRM）限制用户修改代码的权利 [[9]]。
    • 明确对云端服务（SaaS）的适用性（需结合AGPL） [[9]]。
  • 关键差异: v3强化了专利保护和反限制条款，但兼容性降低（部分项目如Linux仍使用v2） [[9]]。

---

2. LGPL（GNU Lesser General Public License）

• 版本: v2.1 vs v3
  • LGPLv2.1:
    • 允许动态链接闭源代码，但修改库本身需开源 [[10]]。
  • LGPLv3:
    • 同步GPLv3的专利条款，要求衍生库必须开源 [[10]]。
    • 明确禁止通过技术手段（如加密签名）限制用户修改库的能力 [[10]]。
  • 关键差异: v3与GPLv3更一致，但限制更多，适用于需兼容闭源的库开发 [[10]]。

---

3. Apache许可证

• 版本: v1.0 vs v2.0
  • Apache 1.0:
    • 允许自由使用，但未明确专利授权条款 [[6]]。
  • Apache 2.0（2004）:
    • 明确授予用户专利权，禁止贡献者发起专利诉讼 [[6]]。
    • 要求声明修改内容，允许商标使用但需明确标识 [[6]]。
  • 关键差异: v2.0增加了专利保护和明确的修改声明要求，企业友好性更强 [[6]]。

---

4. BSD许可证

• 版本: 4条款 vs 3条款 vs 2条款
  • 4条款BSD（原始版）:
    • 包含“广告条款”，要求衍生软件声明中提及原作者 [[5]]。
  • 3条款BSD:
    • 移除广告条款，仅保留版权声明、非背书要求和免责声明 [[3]]。
  • 2条款BSD（简化版）:
    • 进一步移除非背书条款，仅保留版权声明和免责声明 [[7]]。
  • 关键差异: 版本越新限制越少，2条款BSD与MIT类似，但更简洁 [[3]][[7]]。

---

5. MIT许可证

• 版本: 无官方版本，但存在变体
  • 标准MIT:
    • 允许自由使用、修改、分发，仅需保留版权声明 [[3]]。
  • X11 MIT（扩展版）:
    • 明确禁止使用作者名或机构名进行推广 [[8]]。
  • 关键差异: 变体通常增加非背书条款，但核心条款一致 [[3]][[8]]。

---

6. MPL（Mozilla Public License）

• 版本: MPL 1.1 vs MPL 2.0
  • MPL 1.1:
    • 仅覆盖文件级Copyleft，修改的文件需开源，但允许与其他代码混合 [[4]]。
  • MPL 2.0（2012）:
    • 允许以GPL或Apache 2.0方式兼容，简化分发要求 [[4]]。
    • 明确专利授权条款，禁止专利诉讼报复 [[4]]。
  • 关键差异: v2.0更注重兼容性和专利保护，适合混合开发 [[4]]。

---

7. AGPL（GNU Affero General Public License）

• 版本: AGPLv3（唯一主流版本）
  • AGPLv3:
    • 在GPLv3基础上增加“网络服务条款”，要求通过网络提供服务时开源代码 [[1]][[9]]。
    • 适用于SaaS场景（如云数据库），强制服务端代码开放 [[9]]。

---

其他许可证版本差异

• SSPL（Server Side Public License）:
  • MongoDB推出的GPL扩展版，要求云端服务必须开源所有相关代码，但未被OSI认可 [[1]]。
• EPL（Eclipse Public License）:
  • v1.0和v2.0差异较小，v2.0明确专利授权和代码托管条款 [[8]]。

---

核心版本差异总结表

许可证	主要版本	核心变化	来源
GPL	v2 → v3	新增专利条款、反DRM限制、云端适用性	[[9]]
LGPL	v2.1 → v3	同步GPLv3专利条款，禁止技术限制	[[10]]
Apache	v1.0 → v2.0	明确专利授权和商标规则	[[6]]
BSD	4条款 → 2条款	移除广告条款和非背书要求	[[3]][[7]]
MPL	v1.1 → v2.0	兼容GPL/Apache，简化分发	[[4]]

---

选择建议:

• GPLv3适用于强开源约束，GPLv2兼容性更高。
• Apache 2.0优于v1.0，适合企业协作。
• 2条款BSD或MIT适合最小化限制的项目。
• AGPLv3和SSPL针对云端服务场景，但法律风险需评估 [[1]][[9]]。

如需特定许可证的详细条款，可参考OSI官方文档或法律分析 [[1]][[9]]。

---

---

deepseek

以下是主流开源许可证及其不同版本的详细对比，涵盖主要特点、版本差异与适用场景，按限制严格性从宽松到严格排序：

一、宽松许可证（Permissive Licenses）

1. MIT 许可证

• 特点：最宽松的许可证，仅要求保留原作者的版权声明，允许闭源、商用、修改和二次分发，无专利条款。
• 版本：无明确版本区分，但需确保包含完整的许可声明。
• 适用场景：商业项目、个人开源项目、希望最大限度自由使用的场景。

2. BSD 许可证

• 版本差异：
  • BSD 2-Clause：仅需保留版权声明，禁止使用原作者名义推广。
  • BSD 3-Clause：在2-Clause基础上增加“禁止使用原作者或项目名称进行市场推广”的条款。
• 特点：允许闭源和商用，适合需要高度灵活性的项目。
• 适用场景：嵌入式系统、商业软件集成。

3. Apache License 2.0

• 特点：
  • 包含明确的专利授权条款，使用代码即授予专利使用权。
  • 要求修改后的代码需在文件中标注变更说明，并保留原协议声明。
  • 对商标使用有限制。
• 适用场景：涉及专利技术的项目（如云计算、大数据框架）。

---

二、弱 Copyleft 许可证（Weak Copyleft）

4. Mozilla Public License (MPL 2.0)

• 特点：
  • 仅要求对修改后的文件开源，其他部分可闭源。
  • 允许与私有代码混合使用。
• 适用场景：需要部分代码开源的商业项目。

5. Eclipse Public License (EPL 2.0)

• 特点：
  • 衍生作品需开源修改部分，但独立模块可闭源。
  • 提供专利保护，明确禁止专利诉讼。
• 适用场景：企业级开发工具（如Eclipse IDE）。

6. GNU Lesser GPL (LGPL)

• 版本：通常与GPL版本绑定（如LGPLv2.1、LGPLv3）。
• 特点：
  • 允许动态链接闭源软件，但静态链接需开源。
  • 修改后的代码必须采用LGPL。
• 适用场景：库文件开发（如第三方SDK）。

---

三、强 Copyleft 许可证（Strong Copyleft）

7. GNU GPL

• 版本差异：
  • GPLv2：要求衍生作品必须开源，但未明确专利条款。
  • GPLv3：增加对“Tivoization”（硬件锁定）的限制，明确专利授权和反版权规避条款。
• 特点：传染性强，任何使用GPL代码的项目必须整体开源。
• 适用场景：Linux内核、要求强制开源的项目。

8. GNU AGPL (Affero GPL)

• 版本：AGPLv3（基于GPLv3扩展）。
• 特点：
  • 填补GPL的“SaaS漏洞”，要求通过网络提供服务的代码必须开源。
• 适用场景：云服务、SaaS应用（如GitLab、Nextcloud）。

---

四、特殊用途许可证

9. Creative Commons (CC)

• 常见组合：
  • CC0：放弃所有权利，等同于公有领域。
  • CC BY-SA：要求署名且衍生作品使用相同协议。
• 适用场景：非代码作品（文档、设计、图片）。

10. The Unlicense

• 特点：完全放弃版权，将代码置于公有领域。
• 适用场景：希望彻底放弃控制权的项目。

---

版本对比与关键差异

许可证	版本差异关键点	严格性等级
BSD	2-Clause vs. 3-Clause（市场推广限制）	宽松
GPL	v2无专利条款，v3反硬件锁定	强Copyleft
Apache	2.0新增专利授权和商标限制	宽松（含专利）
AGPL	基于GPLv3，增加网络服务开源要求	最强Copyleft

---

选择建议

1. 商业友好：MIT、BSD、Apache（首选宽松协议）。
2. 专利保护：Apache 2.0、EPL。
3. 强制开源：GPL/AGPL（需避免代码被闭源使用）。
4. 混合开发：MPL、LGPL（允许部分闭源）。

如需完整列表或法律细节，可参考OSI官方列表或查阅各协议原文。