开源许可证三兄弟：一个老好人，一个革命者，一个讲究人
一文讲透 MIT、GPL v3 和 Apache 2.0 到底啥区别
引子
你有没有遇到过这种情况——
在网上看到一段好用的代码，想拿过来用，结果一看下面那堆英文协议就头疼。MIT、GPL、Apache……这都是些啥？我用了会不会摊上官司？改了能不能卖钱？
别急。今天我用最糙的大白话，给你把这三位爷掰扯清楚。
故事的开始
话说很久很久以前（其实也没多久），有个叫理查德·斯托曼的老哥，觉得软件应该自由共享，大家互相帮助多好啊。于是他发起了一场叫"自由软件"的运动，还搞了个叫 GPL 的协议。
后来呢，大家觉得斯托曼那套太"左"了，有些人就想搞点更灵活、更务实的。于是 MIT 冒出来了，Apache 也冒出来了。
这三兄弟，就这么各走各的路了。
老大 MIT：老好人一个
MIT 这人吧，没啥脾气。你问他："我能用你的代码不？"
他说："能。"
"我能改不？"
"能。"
"我能改完了不告诉你、拿去卖钱不？"
"也能。"
"那万一出了事咋办？"
"出了事别找我，跟我没关系。"
就完了。
这就是 MIT。全宇宙最宽松、限制最少的协议。你要做的唯一一件事，就是在你的项目里保留一句"这玩意儿最初是 MIT 写的"。
谁最爱用 MIT？
那些想让代码被全世界随便用的人。比如 jQuery、React、Node.js，用的都是 MIT。为啥？因为这些项目想成为生态的基石，越多人用越好，管你闭源开源，爱咋用咋用。
用大白话总结 MIT：
"代码白送你，随便折腾，出了事别找我。"
老二 GPL：革命者，有原则
GPL 这哥们，跟 MIT 完全反着来。
他的信条是："你用了我的，你的也得交出来。"
这就是江湖上赫赫有名的"传染性"。你如果用了 GPL 的代码，或者基于它改了改，并且把你的作品发布出去了，那么对不起——你的整个项目的源码，必须也以 GPL 协议公开。
打个比方：
你拿了张 GPL 的红烧肉秘方，加了点辣椒，开了家"老张家辣味红烧肉"。
GPL 说了：你不但要卖红烧肉，还得把你那加辣版的完整秘方贴门口，谁想看都能看。
GPL v3 还多了两条规矩：
第一，如果你把这个软件装在硬件上卖，不能把硬件锁死。用户得能装他自己改过的版本。这就是针对当年 Tivo 录像机的"反Tivo化"条款。
第二，谁要是想拿专利来卡用户，没门。你贡献代码就等于自动授权所有人免费使用你的相关专利。
谁最爱用 GPL？
那些有理想的、想捍卫"软件自由"的项目。比如 Linux 内核（虽然它用的是 GPL v2）、WordPress、Git。这些项目的作者觉得：我的代码你可以用，但你别把它锁起来，你得让更多人受益。
用大白话总结 GPL：
"代码可以给你，但你的修改也得共享出来。别想着拿我的东西做闭门生意。"
老三 Apache：讲究人，懂人情世故
Apache 这哥们，既不像 MIT 那么没脾气，也不像 GPL 那么激进。他是个讲究人，讲规矩、懂人情。
他的规则是这样的——
第一，你可以随便用、随便改、随便卖。这点跟 MIT 一样。
第二，你改了哪儿，得说清楚。如果你修改了代码并发出去，必须在改过的文件里注明：这些是我改的，原版是人家 Apache 写的。这叫"保留修改声明"。
第三，专利的事儿，我帮你摆平了。这是 Apache 最值钱的地方。每一个给 Apache 项目贡献代码的人，都自动给你一张"专利免单券"——你不用担心用了他的代码被他的专利告。这在企业里太重要了。
第四，别拿我的名号去招摇撞骗。你不能说"这是 Google 认证的"或者"得到了 Apache 基金会的官方支持"。
谁最爱用 Apache？
大厂。比如 Google 的 Kubernetes、Apache 基金会的 Hadoop、Spring 框架。这些项目背后是跨国公司，他们既要开放生态，又要在法律上把锅甩干净——出了事别找我，而且我不让你打着我的旗号忽悠人。
用大白话总结 Apache 2.0：
"代码给你用，专利给你免，但你改了啥要写清楚，别拿我名号骗人。"
一张表看懂三兄弟
| 比什么 | MIT（老好人） | GPL v3（革命者） | Apache 2.0（讲究人） |
|---|---|---|---|
| 能用吗？ | 能 | 能 | 能 |
| 能改吗？ | 能 | 能 | 能 |
| 能商用吗？ | 能 | 能 | 能 |
| 改了能闭源卖吗？ | 能 | 不能，必须开源 | 能 |
| 要注明改动吗？ | 不需要 | 不需要（但整个项目都得开源） | 必须标明改动文件 |
| 专利授权？ | 没说 | 有（但笼统） | 明确、详细 |
| 能用原作者名号吗？ | 没说 | 没说 | 不行，有商标限制 |
| 核心精神 | 随便用，别找我 | 用了我的，你得还回来 | 随便用，但账要记清楚 |
到底选哪个？给你个直截了当的建议
如果你就想分享代码，大家爱咋用咋用，别给我添麻烦——选 MIT。省事、省心，全世界都在用。
如果你是个理想主义者，想让所有用了你代码的项目都保持开源——选 GPL v3。但你要有心理准备，有些商业公司会因为"传染性"而避开你的项目。
如果你在搞大项目，或者背后有公司，担心专利风险，又不想别人打着你旗号骗人——选 Apache 2.0。大厂的标配，体面。
最后送你三句口诀
MIT：代码随便用，出事别找我。
GPL：用了我的码，你得还回来。
Apache：用了请注明，专利我买单。
好了，三个许可证的故事讲完了。下次在 GitHub 上看到这三位爷，你就知道他们是啥路数了。
记住一句话：选许可证，就像选人生——没有最好的，只有最适合的。
参考文献
[1] 赵亮, 高超, 苏晓艳. 开源许可证对比研究[J]. 计算机科学与应用, 2021, 11(12): 2971-2981.
[2] 开源许可证的选择：挑战和影响因素[J]. 软件学报, 2022, 33(1): 1-25.
[3] 刘良勇. 常见开源许可证的特点剖析与比较[EB/OL]. 威科先行, 2025-04-23.
[4] 一种开源许可证的检测与依据兼容性的推荐方法[J]. 小型微型计算机系统, 2023(12).
[5] 开源许可证合规性研究[J]. 软件学报, 2022.
[6] 网络知识产权体系下开源协议的法理研究——基于GPL协议的司法实践与法理冲突分析[J]. 维普中文科技期刊数据库.
[7] Free Software Foundation. GNU General Public License, Version 3[EB/OL]. (2007-06-29)[2026-07-19]. https://www.gnu.org/licenses/gpl-3.0.html.
[8] Open Source Initiative. The MIT License[EB/OL]. (2006-01-01)[2026-07-19]. The MIT License – Open Source Initiative.
[9] Apache Software Foundation. Apache License, Version 2.0[EB/OL]. (2004-01-01)[2026-07-19]. https://www.apache.org/licenses/LICENSE-2.0.
[10] GitHub, Inc. Choose an Open Source License[EB/OL]. (2024-07-01)[2026-07-19]. https://choosealicense.com.
致谢
本文的写作得益于开源社区十余年来的实践积累与理论探索。在此，谨向所有为开源事业默默奉献的开发者、维护者及布道者致以诚挚的敬意。
谨向自由软件基金会（FSF）创始人理查德·斯托曼先生及GNU工程团队致以敬意，正是他们对“软件自由”信念的长期坚守，为开源生态奠定了哲学基础与法律框架。
感谢开放源代码促进会（OSI）在开源许可证认证方面的持续工作，感谢Apache软件基金会在企业级开源治理方面的制度探索。
最后，向本文的读者致谢。开源精神的核心在于分享与传承，愿本文能帮助更多开发者理解许可证背后的逻辑与情怀，共同推动中国开源生态的健康发展。
特别说明：本文引用的所有许可证原文及项目授权信息，均以各官方网站发布的最新版本为准。文中涉及的法律条款解读系作者基于公开文献的个人理解，不构成法律意见。如涉及重大商业决策，建议咨询专业法律人士。
)
