开源许可证三兄弟一个老好人一个革命者一个讲究人一文讲透 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软件基金会在企业级开源治理方面的制度探索。最后向本文的读者致谢。开源精神的核心在于分享与传承愿本文能帮助更多开发者理解许可证背后的逻辑与情怀共同推动中国开源生态的健康发展。特别说明本文引用的所有许可证原文及项目授权信息均以各官方网站发布的最新版本为准。文中涉及的法律条款解读系作者基于公开文献的个人理解不构成法律意见。如涉及重大商业决策建议咨询专业法律人士。