开源许可证详解
下面我来用通俗易懂的方式为你详细介绍主流的开源许可证,包括它们分别允许你干什么(✅ 权利)和限制你干什么(⚠️ 义务/限制)。这对你未来使用或开源项目非常重要。
🧭 总览:开源许可证怎么选?
不同的许可证,在“能不能闭源”、“要不要公开修改”、“能不能商用”这些点上差异最大。
许可证 | 商业可用 | 闭源可用 | 修改后是否必须开源 | 适合谁 |
---|---|---|---|---|
MIT | ✅ | ✅ | ❌ 不强制 | 开发者、初创 |
Apache 2.0 | ✅ | ✅ | ❌ 不强制 | 企业、平台级 |
BSD 3-Clause | ✅ | ✅ | ❌ 不强制 | 教学、研究 |
GPL v3 | ✅ | ❌ | ✅ 强制 | 注重自由的开源社区 |
LGPL v3 | ✅ | ✅(限度) | ✅ (库级别) | 做库的人 |
MPL 2.0 | ✅ | ✅ | ✅(文件级) | 平衡自由和开源 |
🎯 1. MIT License(最宽松)
✅ 权利:
可以免费使用、复制、修改、分发;
可以闭源使用(你修改了也不需要开源);
可以用于商业用途。
⚠️ 义务:
保留原作者的许可证和版权声明;
没有担保,出错作者不负责。
✅ 适合: 快速开发、创业、发库、个人项目。
📌 举例:React、jQuery、Vue(早期)都用了 MIT。
🎯 2. Apache License 2.0(商业友好)
✅ 权利:
跟 MIT 类似,也可以商用、修改、闭源;
还增加了对专利的保护,大公司更喜欢;
可以再授权给别人使用。
⚠️ 义务:
保留许可证;
说明你有没有修改代码;
不能乱用原作者的商标(比如 Apache Logo);
无担保。
✅ 适合: 公司平台、需要规避专利风险的项目。
📌 举例:TensorFlow、Kubernetes、Android 系统核心组件。
🎯 3. BSD License(学术背景)
有两种:BSD 2-Clause 和 BSD 3-Clause(多了个“不能用作者名背书”条款)
✅ 权利:
和 MIT 类似,自由使用、修改、商用;
不要求开源修改;
无限制分发。
⚠️ 义务:
保留版权信息和许可条款;
不可使用作者名字为你项目背书。
✅ 适合: 教学科研、低限制应用。
📌 举例:FreeBSD、OpenCV、PostgreSQL。
🎯 4. GPL(通用公共许可证)
📌 这是最有争议的一个,也是最严格的。
✅ 权利:
免费使用、修改、分发;
强制开源:你修改了,就必须开源出来!
⚠️ 限制:
不能闭源商用:只要你“发布”了修改版软件,就必须把你自己写的部分也一起开源;
用了 GPL 的库,整个软件可能也必须 GPL;
一旦用了,不能悔改闭源。
⚠️ 适合: 重视自由的开源项目,如 GNU 工具、Linux Kernel。
📌 举例:GNU、WordPress、Linux Kernel(部分)。
🎯 5. LGPL(宽松版 GPL)
✅ 权利:
你可以把 LGPL 开源库嵌入你的闭源应用里;
不影响你的代码闭源,只要库本身不改。
⚠️ 限制:
如果你修改了 LGPL 的库,必须开源你改的部分;
如果只是链接调用,不用开源主项目。
✅ 适合: 做工具库、组件,不想强制别人开源。
📌 举例:FFmpeg、glibc。
🎯 6. MPL 2.0(文件级别开源)
✅ 权利:
商业友好,可闭源使用;
修改的部分 只要你改了某个文件,就开源那个文件就行(不像 GPL 是整个项目)。
⚠️ 限制:
保留 MPL 文件的许可证;
修改后的文件开源,但其他文件不用。
✅ 适合: 希望部分共享、又希望灵活控制开源范围的项目。
📌 举例:Firefox、Thunderbird、Rust 编译器。
✅ 总结一句话记住这些许可证:
许可证 | 一句话记忆 |
---|---|
MIT | “随便用,记得署名” |
Apache 2.0 | “随便用,别抢我商标” |
BSD | “学术界的 MIT” |
GPL | “用了我的就都得开源” |
LGPL | “我开源,但你可以闭源用” |
MPL | “改我,就开我;不改,不开” |