# 开源许可证完全指南从 MIT 到 GPL：一文搞懂所有主流许可证演化历史 · 权限对比 · 命名由来 · 选型指南 - 状态 / Status: 已发布 / Published - 时间 / Time: 2026-02-22T00:14:28+08:00 - 作者 / Author: - - 主题 / Topics: 未分类 / Other - 原文 / Source: https://mp.weixin.qq.com/s/upM9uz7epUvAtDnB19S2Mw ⚠️ 声明：本文所有信息均来自公开互联网资料，仅供参考学习。许可证选择涉及法律问题，建议咨询专业律师。 --- ⚠️ 声明：本文所有信息均来自公开互联网资料，仅供参考学习。许可证选择涉及法律问题，建议咨询专业律师。 📜 开源许可证完全指南 从 MIT 到 GPL：一文搞懂所有主流许可证 演化历史 · 权限对比 · 命名由来 · 选型指南 你是否在 GitHub 上看到过 MIT 、 GPL 、 Apache 2.0 这些许可证名称，却一直搞不清它们之间的区别？选错许可证可能让你的代码被"绑架"，或者让你意外违法。本文将带你 从历史源头到实战选型 ，彻底搞懂开源许可证的一切！ ✦ ✦ ✦ TL;DR 开源许可证速览表 先上结论！如果你只有 30 秒，记住这张表： 🎯 许可证分类速查 🟢 宽松型（Permissive） MIT · BSD · Apache 2.0 · ISC · Unlicense → 随便用，保留版权声明即可，可闭源商用 🟡 弱 Copyleft LGPL · MPL · EPL → 修改的文件需开源，但可链接到闭源代码 🔴 强 Copyleft GPL v2 · GPL v3 · AGPL → 整个衍生作品都必须开源，"传染性"许可证 🟣 Source-available（非开源） BSL · SSPL · Elastic License → 可看源码，但有商业限制，不是真正的开源 "When in doubt, use MIT for libraries, Apache 2.0 for larger projects." 「拿不准就用 MIT 做库，Apache 2.0 做大项目。」— 开源社区通用建议 ✦ ✦ ✦ 一 开源许可证的演化史 开源许可证的历史，其实是一部 程序员争取代码自由 的斗争史。 📍 1980 年代初期 — 黑暗时代降临 1980 年，美国修改版权法，软件被视为"文学作品"受版权保护。公司开始封锁源代码，程序员无法再自由分享和修改软件。 📍 1983 年 — GNU 计划诞生 MIT 程序员 Richard Stallman 宣布启动 GNU 计划，要创建一个完全自由的操作系统。 📍 1985 年 — Copyleft 概念诞生 Stallman 发布 GNU Emacs 时，首次使用 Emacs General Public License 。"Copyleft"一词来自程序员 Don Hopkins 寄给 Stallman 的一封信上的贴纸。 📍 1989 年 — GPL v1 发布 第一个通用的 GNU General Public License 诞生，开启了 Copyleft 许可证时代。 📍 1988-1990 年 — BSD 许可证出现 加州大学伯克利分校为其 BSD Unix 系统创建了许可证，成为宽松型许可证的鼻祖。 📍 1991 年 — GPL v2 发布 增加了"自由或死亡"条款。同年，Linus Torvalds 用 GPL v2 发布 Linux 内核。 📍 1995 年 — Apache 许可证诞生 Apache Group（后来的 Apache 软件基金会）为 Apache HTTP Server 创建许可证。 📍 1998 年 — "开源"一词诞生 Eric Raymond 和 Bruce Perens 创立开源倡议组织（OSI），"Open Source"正式成为术语。 📍 1999 年 — BSD 广告条款删除 伯克利删除了著名的"广告条款"，3-clause BSD 诞生，解决了与 GPL 的兼容性问题。 📍 2004 年 — Apache 2.0 发布 新增明确的 专利授权 和 专利报复条款 ，成为企业最爱。 📍 2007 年 — GPL v3 和 AGPL 发布 GPL v3 解决了专利和 DRM 问题；AGPL 堵住了"SaaS 漏洞"——网络服务也要开源。 📍 2018 年后 — Source-available 兴起 MongoDB 推出 SSPL，Redis、Elastic 等纷纷效仿，应对云厂商"白嫖"问题。 "The central idea of copyleft is to use copyright law, but flip it over to serve the opposite of its usual purpose." 「Copyleft 的核心思想是利用版权法，但将其颠倒过来，达到与其通常目的相反的效果。」— Richard Stallman ✦ ✦ ✦ 二 这些名字都是怎么来的？ 为什么叫 MIT？BSD 又是什么缩写？让我们揭秘这些许可证名字背后的故事。 🎓 MIT License — 麻省理工学院许可证 起源于 Massachusetts Institute of Technology （麻省理工学院），最早用于 1980 年代的 X Window System 项目。 有趣的是，MIT 这个名字有点"模糊"——其实有好几个版本（X11 License、Expat License），但大家现在说的 MIT 通常指 OSI 认证的 Expat 版本。 🐡 BSD License — 伯克利软件发行版许可证 全称 Berkeley Software Distribution ，来自加州大学伯克利分校为其 Unix 变体创建的许可证。 4-clause ：原版（1990），有烦人的广告条款 3-clause ：1999 年删除广告条款，最常用 2-clause ：又称 FreeBSD License，更简洁 🪶 Apache License — 阿帕奇许可证 来自 Apache Software Foundation ，最初为 Apache HTTP Server 创建。 "Apache" 名字据说来自"a patchy server"（一个打满补丁的服务器）的双关语，也是向美洲原住民阿帕奇部落致敬。 🐃 GPL — GNU 通用公共许可证 GNU General Public License ，由 Richard Stallman 为 GNU 项目创建。 GNU 是个递归缩写："GNU's Not Unix"（GNU 不是 Unix）。程序员的幽默感。 📚 LGPL — GNU 宽松通用公共许可证 Lesser General Public License ，最初叫 "Library GPL"（库 GPL）。 后来改名为 "Lesser"（宽松的），因为 FSF 不想让人觉得所有库都应该用它。 ☁️ AGPL — Affero 通用公共许可证 Affero General Public License ，以 Affero 公司命名。 2002 年 Affero 公司需要一个能覆盖网络服务的许可证，于是和 Stallman 合作创建了它。 🦊 MPL — Mozilla 公共许可证 Mozilla Public License ，由 Netscape 在 1998 年为 Mozilla 项目创建。 当时 Netscape 想开源浏览器代码，但觉得 GPL 太严格，于是自己写了一个。 🌐 ISC License — 互联网系统联盟许可证 Internet Systems Consortium 许可证，用于 BIND DNS 服务器等项目。 功能上等同于简化版 BSD，是 OpenBSD 项目的默认许可证。 💡 彩蛋：Copyleft 一词的来源 1984 年，程序员 Don Hopkins 给 Stallman 寄了一封信，信封上贴着一个贴纸，写着 "Copyleft Ⓛ — All Rights Reversed" （Copyleft — 所有权利颠倒）。Stallman 觉得这个词太妙了，于是采用了它。 ✦ ✦ ✦ 三 主流许可证详细对比 🟢 宽松型许可证（Permissive） 这类许可证限制最少， 基本上是"随便用，别告我" 。 🏆 MIT License — 最简单，最流行 ✅ 可商用 · ✅ 可修改 · ✅ 可分发 · ✅ 可闭源 ❗ 必须保留版权声明和许可证文本 代表项目： React、Vue.js、Node.js、jQuery、Ruby on Rails "Do whatever you want, just don't sue me." 🛡️ Apache 2.0 — 企业首选，有专利保护 ✅ 可商用 · ✅ 可修改 · ✅ 可分发 · ✅ 可闭源 ✅ 明确的专利授权 · ✅ 专利报复条款 ❗ 必须保留版权 · ❗ 必须注明修改内容 代表项目： Android、Kubernetes、TensorFlow、Spark "Same as MIT, but with patent protection and more words lawyers like." 🐡 BSD 3-Clause — 老牌经典 ✅ 与 MIT 几乎相同 ❗ 额外条款：不能用原作者名字做背书 代表项目： FreeBSD、macOS（Darwin 内核）、Nginx 📝 ISC License — 更精简的 BSD 功能等同于 BSD 2-Clause，但措辞更简洁 代表项目： OpenBSD、npm 包默认许可证 🆓 Unlicense — 直接放弃版权 等同于公共领域（Public Domain），无任何限制 ⚠️ 在某些国家/地区可能有法律问题，建议用 CC0 代替 🟡 弱 Copyleft 许可证 这类许可证介于宽松和严格之间， 修改的部分要开源，但可以链接到闭源代码 。 📚 LGPL — 库的 GPL ✅ 可用于闭源软件（通过动态链接） ❗ 对 LGPL 库本身的修改必须开源 ❗ 用户必须能替换 LGPL 库 代表项目： GNU C Library (glibc)、Qt（双许可） 🦊 MPL 2.0 — 文件级 Copyleft ✅ 只有修改的 文件 需要开源 ✅ 新增的文件可以用任何许可证 ✅ 与 GPL v3 兼容 代表项目： Firefox、Thunderbird "The middle ground between BSD and GPL." 🔴 强 Copyleft 许可证 这类许可证具有 "传染性" ——使用了这些代码，你的整个项目都要开源。 🐧 GPL v2 — Linux 内核的选择 ❗ 任何衍生作品必须同样 GPL ❗ 分发时必须提供源代码 ⚠️ 与 Apache 2.0 不兼容 代表项目： Linux 内核、Git、WordPress 🔒 GPL v3 — 更严格的保护 ✅ 与 Apache 2.0 兼容 ❗ 包含专利授权条款 ❗ 反 DRM 条款（"Tivoization" 限制） 代表项目： GCC、GIMP、Bash ☁️ AGPL v3 — 最严格的开源许可证 ❗ GPL v3 的所有限制 ❗ 网络交互也触发开源义务 （堵住 SaaS 漏洞） 代表项目： Grafana、Mastodon、MongoDB（曾用） "If users interact over a network, you must give them the source code." 🟣 Source-Available 许可证（非开源） ⚠️ 注意：这些不是开源许可证！ 虽然代码可见，但有商业使用限制， 不被 OSI 认可为开源 。 ⏰ BSL — 商业源码许可证 ✅ 可看源码，可修改 ❌ 不能用于生产环境（商业用途） ✅ 4 年后自动转为开源（通常是 Apache 2.0） 代表项目： MariaDB、HashiCorp Terraform/Vault 🌩️ SSPL — 服务器端公共许可证 基于 AGPL，但要求更极端： ❌ 如果提供 SaaS，必须开源 所有 相关基础设施代码 代表项目： MongoDB、Elastic（后改用） ⚠️ 被 Debian、Fedora 等发行版禁止 ✦ ✦ ✦ 四 权限速查 Cheatsheet 把这张表收藏起来，选许可证时对照看： 📊 许可证权限对比表 许可证 | 商用 | 修改 | 分发 | 专利 | 闭源 | Copyleft MIT | ✅ | ✅ | ✅ | ⚠️隐含 | ✅ | ❌ Apache 2.0 | ✅ | ✅ | ✅ | ✅明确 | ✅ | ❌ BSD 3-Clause | ✅ | ✅ | ✅ | ⚠️隐含 | ✅ | ❌ MPL 2.0 | ✅ | ✅ | ✅ | ✅ | ⚠️部分 | 🟡文件级 LGPL | ✅ | ✅ | ✅ | ✅ | ⚠️动态链接 | 🟡弱 GPL v2 | ✅ | ✅ | ✅ | ⚠️隐含 | ❌ | 🔴强 GPL v3 | ✅ | ✅ | ✅ | ✅明确 | ❌ | 🔴强 AGPL | ✅ | ✅ | ✅ | ✅明确 | ❌ | 🔴最强 ⚠️ 兼容性陷阱 GPL v2 和 Apache 2.0 不兼容！ 因为 Apache 2.0 的专利条款在 GPL v2 看来是"额外限制"。 GPL v3 解决了这个问题，可以和 Apache 2.0 混用。 ✦ ✦ ✦ 五 如何选择许可证？ 选许可证就像选政治立场，取决于你的价值观和目标： 🎯 你想让更多人用你的代码？ → 选 MIT 或 Apache 2.0 （企业项目推荐 Apache） 🔧 你担心专利纠纷？ → 选 Apache 2.0 ，有明确的专利授权和报复条款 🛡️ 你想确保改进永远开源？ → 选 GPL v3 ，防止被闭源商业化 ☁️ 你的软件会被当成 SaaS 使用？ → 选 AGPL ，堵住 SaaS 漏洞 📚 你在做一个库/框架？ → MIT （最大采用率）或 LGPL （希望改进回流） 🌳 快速决策树 1️⃣ 在乎被闭源商用吗？ → 不在乎：MIT/Apache → 在乎：下一步 2️⃣ 只要修改的部分开源？ → 是：MPL/LGPL → 否：下一步 3️⃣ 网络服务也要开源？ → 是：AGPL → 否：GPL "Niche down your license choice like you niche down your product." 「选许可证就像选细分市场——想清楚你要什么，不要什么。」 ✦ ✦ ✦ 六 开源许可证合规 SOP Checklist 不管你是 发布开源项目 还是 使用开源代码 ，都按这个清单检查： 📤 发布开源项目前检查 1 确定项目目标：想最大化采用率？想保护改进不被闭源？ 2 检查依赖项许可证兼容性（GPL 不兼容 Apache 2.0 等） 3 在项目根目录添加 LICENSE 文件（完整许可证文本） 4 在 README.md 中说明许可证类型 5 在 package.json / Cargo.toml 等配置文件中声明 license 字段 6 （可选）在源代码文件头部添加版权声明 📥 使用开源代码前检查 1 识别所有依赖项的许可证（使用 license-checker 等工具） 2 检查是否有 Copyleft 许可证（GPL/AGPL）影响你的闭源代码 3 保留所有版权声明和许可证文本 4 Apache 2.0：如有修改，需注明修改内容 5 GPL/LGPL：确保满足源代码分发要求 6 在最终产品中包含 NOTICE 文件或第三方许可证列表 🛠️ 常用合规检查工具 license-checker — npm 包许可证检查 FOSSA — 企业级许可证合规平台 ScanCode — 开源许可证扫描工具 licensee — GitHub 官方许可证检测 ✦ ✦ ✦ 💬 你的项目用的是什么许可证？ 欢迎在评论区分享你的选择和理由！ 如果这篇文章对你有帮助，记得 点赞收藏 ～ 📚 参考来源： 1. GNU 项目官方文档和许可证列表 2. Open Source Initiative (OSI) 认证许可证 3. Choose a License (choosealicense.com) 4. Free Software Foundation 历史档案 5. Wikipedia 开源许可证相关条目 6. Apache Software Foundation 官方 FAQ 参考原文信息列表： 1. https://www.gnu.org/licenses/license-list.en.html 2. https://opensource.org/licenses 3. https://choosealicense.com/licenses/ 4. https://en.wikipedia.org/wiki/Open-source_license 5. https://en.wikipedia.org/wiki/GNU_General_Public_License 6. https://en.wikipedia.org/wiki/MIT_License 7. https://en.wikipedia.org/wiki/BSD_licenses 8. https://en.wikipedia.org/wiki/Apache_License 9. https://en.wikipedia.org/wiki/GNU_Affero_General_Public_License 10. https://en.wikipedia.org/wiki/Copyleft 11. https://www.free-soft.org/gpl_history/ 12. https://snyk.io/articles/open-source-licenses/ 13. https://fossa.com/blog/open-source-software-licenses-101-bsd-3-clause-license/ 14. https://fossa.com/blog/open-source-licenses-101-apache-license-2-0/ 15. https://www.mend.io/blog/open-source-copyleft-licenses/ 16. https://memgraph.com/blog/history-of-open-source-licenses-what-license-to-choose 17. https://www.apache.org/licenses/LICENSE-2.0 18. https://opensource.guide/legal/ ✨ — END —