常见开源许可协议介绍及对比

主流开源协议一览

📝 各类协议详解

1️⃣ MIT 许可证 ⭐ 最受欢迎

特点： 最宽松、最简单，只需保留版权声明即可。

必须保留：

✅ 原版权声明

✅ 本许可声明

禁止：

❌ 无禁止事项

无需：

✗ 源文件必须开源

✗ 专利授权

✗ 公开修改内容

适用场景： 个人项目、初创公司、快速迭代的开源项目。如 React、Ruby on Rails、.NET Core。

2️⃣ BSD 许可证（2-Clause / 3-Clause）

BSD-2-Clause（Simplified BSD）：

• 比 MIT 还简单

• 去除了 BSD-3 中的"不得使用商标"条款

BSD-3-Clause：

• 多了一条：禁止使用贡献者姓名推广衍生产品

必须保留：

✅ 版权声明

✅ 本许可声明

禁止：

❌ 不得使用姓名推广衍生产品（仅3-Clause）

无需：

✗ 强制开源

适用场景： 与 MIT 类似，商业友好。如 Redis、Django（BSD）。

3️⃣ Apache 2.0

特点： MIT + 专利授权 + 贡献者专利授予。

必须保留：

✅ 版权声明

✅ 本许可声明

✅ 修改必须注明

自动获得：

✅ 专利授权

✅ 贡献者专利授予

✅ 衍生作品可申请专利

需要：

⚠️ 若提供二进制文件，必须包含协议副本

⚠️ 修改源文件必须注明

适用场景： 大型企业项目、需要专利保护的项目。如 Apache 全家桶、Kafka、Spring Boot。

4️⃣ ISC 许可证

特点： 功能上等同于 Simplified BSD，但法律上更简洁。

删除 BSD 中模糊的法律措辞

保留 MIT/BSD 的核心要求

适用场景： OpenBSD 等追求法律简洁的项目。

5️⃣ GPL v3（GNU General Public License v3）

特点： 传染性最强，使用者必须开源。

核心要求：

✅ 任何基于 GPL 代码修改/分发，必须开源

✅ 修改必须提供源码

✅ 分发二进制必须同时提供源码

增强：

✅ 明确专利授权

✅ 与 Apache 2.0 兼容

✅ 新增"设计自由"条款（防止 Tivoization）

适用场景： 强调代码必须保持开源的项目。如 Linux、GCC、Git、MySQL。

6️⃣ GPL v2

特点： 比 v3 更严格，无专利条款。

与 v3 区别：

❌ 无明确专利授权

❌ 与 Apache 2.0 不兼容

❌ 无 Tivoization 限制

适用场景： 经典 GNU 项目（MySQL v5.7 之前）。

7️⃣ LGPL v2.1/v3

特点： 宽松版GPL，允许链接（不修改）可闭源。

与 GPL 对比：

✅ LGPL 代码可以链接到闭源项目

✅ 但修改 LGPL 本身仍需开源

使用条件：

⚠️ 修改必须开源

⚠️ 需明确标注使用了 LGPL 库

适用场景： 库/框架。如 FFmpeg（LGPL）、Qt（LGPL）、大多数 GNU 库。

8️⃣ AGPL v3

特点： GPL 的加强版，网络使用也必须开源。

与 GPL 区别：

✅ GPL：分发/修改代码时开源

✅ AGPL：网络访问代码也必须开源（通过 SaaS 使用也需开源）

适用场景： 云服务/SaaS不希望用户修改代码的场景。如 MongoDB（早期 AGPL）、PostgreSQL。

9️⃣ MPL 2.0（Mozilla Public License 2.0）

特点： 文件级别开源，弱传染性。

核心机制：

✅ 只对修改的"文件"强制开源

✅ 库中的其他文件可保持闭源

✅ 企业友好：可与闭源代码混合使用

适用场景： Mozilla Firefox、RedHat 等商业友好的开源项目。

🔟 EPL 2.0（Eclipse Public License 2.0）

特点： 与 MPL 类似，文件级别开源。

与 MPL 区别：

✅ 更清晰的法律措辞

✅ 允许提供网络安装服务

✅ 更明确的专利保护

适用场景： Eclipse IDE、Thinker等 Java 项目。

1️⃣1️⃣ CDDL（Common Development and Distribution License）

特点： Mozilla MPL 的变体，Sun/Oracle 采用。

特点：

✅ 文件级别开源

✅ 可与 GPL 不兼容

⚠️ "贡献代码"需开放

适用场景： Solaris/OpenSolaris 遗留项目。

🏆 选择指南

场景

推荐协议

⚠️ 重要提醒

总结： MIT 最宽松，Apache 2.0 功能最全，GPL 最严格。选择时需权衡商业利益和开源理念。