开源许可证速查：MIT、Apache 2.0、GPL v3 怎么选？

发表于 分类于 ， 阅读次数： 本文字数： 1.6k 阅读时长 ≈ 3 分钟

面对五花八门的开源许可证，最常被问到的无非三件事：能不能商用？能不能改了闭源？要不要写专利和修改声明？这篇文章用一张速查表和几条决策准则，帮你在 1 分钟内选对证。

🧭 先看结论（速查表）

特性 MIT 许可证 Apache 2.0 许可证 GPL 许可证 (v3)
类型 宽松（Permissive） 宽松（Permissive） 传染共享（Copyleft）
商业使用 允许 允许 允许
修改后闭源 允许 允许 不允许
需要包含原许可证 是 是 是
需要说明修改 否 是 是
专利授权 无明确说明 明确授权 明确授权
“传染性” 无 无 强

图表要点：如果你希望“随便用、闭源也行”，首选 MIT 或 Apache 2.0；如果你希望“别人用到你的代码时必须开源”，选择 GPL v3。

🧩 三大许可证，一口气读懂

✅ MIT：最宽松、落地最简单

  • 核心义务：在再分发时保留原始版权与许可证文本。
  • 适用场景：前端库、工具脚本、样例项目、教育项目等，希望最低合规成本、最大化传播。
  • 风险点：没有明确的专利授权条款，企业法务更偏好 Apache 2.0。

✅ Apache 2.0：工程团队的默认首选

  • 核心义务：保留 LICENSE 与 NOTICE，对修改做合理标识；自带专利授权与专利反诉终止条款。
  • 适用场景：需要进入企业或商业产品的库/服务；关注专利风险的项目。
  • 亮点：与 MIT 同样宽松，但合规边界更清晰，专利条款更友好。

🔁 GPL v3：强 Copyleft，确保改动也开源

  • 核心义务：凡分发衍生作品，必须以 GPL 兼容方式开源全部相关源代码，并保留许可证与修改说明。
  • 适用场景：你希望代码永远开源、阻止他人闭源使用改动成果（例如工具链、基础软件）。
  • 注意：对闭源商业分发不友好；与部分生态的许可证兼容性较差。

🧠 怎么选？用这 4 个问题秒定

  1. 你是否希望别人基于你的代码做出的产品可以闭源？
    • 是 → 选 MIT 或 Apache 2.0
    • 否 → 选 GPL v3（若是网络服务场景且更在意“通过网络提供服务”也触发开源义务，可考虑 AGPL）
  2. 你是否担心专利纠纷？
    • 是 → 优先 Apache 2.0（自带明确专利授权与防滥诉条款）
    • 否 → MIT 也可
  3. 你的目标用户是谁？
    • 企业/商业产品集成 → Apache 2.0 更易被法务接受
    • 个人/教学/社区 Demo → MIT 简洁好用
  4. 你是否需要与其他许可证兼容？
    • npm/Go/Rust 等社区通用库 → MIT/Apache 2.0 兼容面更广
    • 想“强制开源传递” → GPL 系列

🗂️ 合规清单（实操）

  • 在仓库根目录放置 LICENSE 文件；Apache 2.0 另需 NOTICE（列出版权与声明）。
  • 再分发二进制或源代码时，携带原始许可证文本；Apache 2.0 对“修改过的文件”做适当标注。
  • 第三方依赖合规：记录依赖及其许可证；打包/发行时附上对应的 LICENSE/NOTICE 汇总。
  • 版权年份与持有人保持最新；多人或公司名义应统一口径。
  • 公司项目：与法务确认是否需要额外的贡献者许可协议（CLA）。

❓ 常见误区

  • “用了 GPL 的库就必须把我的 SaaS 也开源？”——如果只是通过网络调用且未分发程序，GPL 的触发较弱，但 AGPL 明确将“网络提供服务”纳入义务，注意区分。
  • “MIT 就没有任何限制？”——仍需保留版权与许可证文本；没有专利条款并不等于无限责任。
  • “Apache 2.0 一定要每个文件头都加版权声明吗？”——并非强制，但为便于溯源，核心文件加上版权头是常见实践。

📎 模板与参考

✨ 小结

  • 想要传播最广、合规成本最低：选 MIT。
  • 想兼顾企业合规与专利风险：选 Apache 2.0。
  • 想确保改动继续开源并回馈社区：选 GPL v3（或在“网络服务”场景下考虑 AGPL）。

把本文表格收藏到书签，你的许可证选择基本不会错。