【Git】Github 开源许可证详解

在 GitHub 创建仓库时，选择开源许可证（License）本质上是在定义别人可以对你的代码做什么、不能做什么，以及需要承担什么义务。

GitHub 默认下拉菜单中的所有 13 种常见许可证。按照开源限制力度从弱到强（宽松型 ➔ 弱传染型 ➔ 强传染型 ➔ 公共领域）对它们进行详细对比解析：

一、宽松型许可证（Permissive Licenses）

1. MIT License

定义与特点：世界上最流行、最简洁的开源许可证。极简条款，赋予使用者最大的自由度。
优点：极易理解；对开发者和商业公司极其友好，传播度最高。
缺点：不提供专利保护条款；不能保证后续修改的代码会开源。
应用场景：大部分开源工具库、前端框架、个人小项目、脚手架。
何时选择：希望代码被尽可能多的人（包括商业公司）免费使用和修改，且不在乎对方是否开源修改后的版本。

2. Apache License 2.0

定义与特点 ：在宽松的基础上加入了显式的专利授权条款 和修改声明要求。
优点：明确授予使用者专利权，并规定如果使用者起诉原作者侵犯专利，其许可证将被终止；要求修改过的文件保留修改说明，对企业级项目更安全。
缺点：条款相对复杂，阅读门槛高于 MIT。
应用场景：企业级开源项目、大型基础设施、涉及专利的技术项目（如 Android、TensorFlow、Kubernetes）。
何时选择：希望商业公司放心使用，但同时想防止商业公司拿你的代码申请专利反过来起诉你。

3. BSD 2-Clause "Simplified" License

定义与特点：比 MIT 稍微严格一点点的宽松许可证，去掉了早期 BSD 中的广告条款，仅包含"保留版权声明"和"免责声明"两项条款。
优点：极简，无专利约束，法律语言极其清晰。
缺点：知名度略低于 MIT，不包含专利保护。
应用场景：注重轻量、学术研究或传统 UNIX 社区项目。
何时选择：想要类似 MIT 的极简协议，但更偏好 BSD 体系的规范。

4. BSD 3-Clause "New" or "Revised" License

定义与特点：在 BSD 2-Clause 的基础上增加了第 3 条"禁止背书"条款（No-Endorsement Clause），即使用者不能用原作者或机构的名字来为自己的衍生产品做宣传/背书。
优点：保护原作者或机构的名誉不受滥用。
缺点：相比 MIT 稍微多了一层约束。
应用场景：大学、科研机构或名企发起的开源项目（如 Go 语言部分组件、Numpy 等）。
何时选择：不希望使用者借用你的名义或公司品牌去为他们的商业产品背书。

5. Boost Software License 1.0 (BSL-1.0)

定义与特点：由 C++ Boost 库团队制定，专为 C++ 源码和编译后的二进制文件设计。
优点：特别规定了如果代码被编译成二进制可执行文件发布，使用者无需在二进制中附带版权声明。
缺点：主要活跃于 C++ 社区，其他语言社区较少见。
应用场景：C++ 头文件库（Header-only libraries）、基础算法库。
何时选择：编写 C++ 基础库，希望别人把你的代码编译进商业软件时，不用在软件的"关于"或"法律信息"页面强制列出你的版权。

二、弱传染型 / 文件级开源许可证（Weak Copyleft Licenses）

核心特点 ：修改了原代码文件必须开源，但如果只是调用/链接该项目，使用者的主体代码可以保持闭源。

6. Mozilla Public License 2.0 (MPL 2.0)

定义与特点 ：介于 MIT 和 GPL 之间的折中方案。以文件为单位进行传染。
优点：对原文件的修改必须开源；但使用者可以将 MPL 许可的文件与商业闭源文件合并编译在一起。
缺点：知名度不如 LGPL 或 Apache。
应用场景：组件库、模块化工具（如 Firefox 内部组件、Terraform 等）。
何时选择：希望别人改进你的代码时必须把改进贡献出来，但允许别人把你的项目作为一个模块包含在他们的闭源商业系统中。

7. Eclipse Public License 2.0 (EPL 2.0)

定义与特点：由 Eclipse 基金会主导的弱传染型许可证，与 MPL 类似，同样针对代码模块/文件级别的修改。
优点：包含良好的专利授权条款，适合企业联合开发。
缺点：主要局限于 Java 和 Eclipse 生态体系。
应用场景：Java 企业级开源框架、Eclipse 插件生态。
何时选择：主要从事 Java 生态或 Eclipse 相关工具链开发，且希望获得企业级法律保护。

8. GNU Lesser General Public License v2.1 (LGPL v2.1)

定义与特点：自由软件基金会（FSF）专为类库（Libraries）设计的弱传染许可证。
优点：允许闭源商业软件通过动态链接（Dynamic Linking）使用该库，而不需要开源商业软件本身。
缺点：如果采用静态链接（Static Linking），可能导致商业软件面临开源压力或需提供目标文件（.obj）。
应用场景：基础动态链接库（如 FFmpeg、7-Zip 的部分库）。
何时选择：开发的是一个基础函数库，希望别人可以在闭源软件里通过动态链接调用它，但如果对方直接修改了你的库本身，必须开源修改后的库代码。

三、强传染型许可证（Strong Copyleft Licenses）

核心特点 ：强调"开源的自由"。"用者即开源"，只要项目使用了此类代码，整个衍生项目都必须以相同许可证开源，严禁闭源商业化套壳。

9. GNU General Public License v2.0 (GPL v2.0)

定义与特点：经典强传染型许可证，Linux 内核使用的正是此版本。规定任何包含或链接 GPL v2 代码的项目必须以 GPL v2 开源。
优点：有力保护开源生态，防止被商业公司侵占。
缺点：不支持 v3 的反 Tivo 化（硬件锁）和专利保护条款；对商业公司不友好。
应用场景：Linux 内核、Git、早期 GNU 工具链。
何时选择：希望严格保护代码不被闭源软件利用，且需要与 Linux 内核等 GPL v2 项目保持兼容。

10. GNU General Public License v3.0 (GPL v3.0)

定义与特点 ：GPL v2 的升级版，增加了专利授权和反 Tivo 化（禁止硬件禁止用户修改软件）条款。
优点：闭环堵住了利用硬件限制阻止用户运行修改版代码的漏洞，强化了专利保护。
缺点：许多大公司（如 Apple）严格禁止在产品内部使用 GPL v3 代码。
应用场景：独立开源软件、桌面应用（如 GIMP、Blender、GCC）。
何时选择：希望代码完全开源，强制要求任何衍生软件必须开源，且阻止任何公司将其嵌入封闭的硬件设备中。

11. GNU Affero General Public License v3.0 (AGPL v3.0)

定义与特点 ：传染力最强的许可证（最严格）。专门堵住了"云服务/SaaS 漏洞"。
优点：在 GPL v3 的基础上规定：如果将代码部署在服务器上作为网络服务（SaaS）提供给用户使用，也算作"分发"，必须向用户开源服务器端的全部源码。
缺点：商业公司几乎避之不及。
应用场景：开源数据库、云原生后端服务（如 Grafana 早期、MongoDB 早期、Mastodon）。
何时选择：开发的是后端服务/SaaS 产品，为了防止云厂商（如 AWS、阿里云）直接将你的免费开源软件包装成云服务收费却不给社区贡献任何代码。

四、无版权 / 公共领域（Public Domain / Unlicense）

核心特点：完全放弃版权，将代码彻底赠予全人类。

12. Creative Commons Zero v1.0 Universal (CC0 1.0)

定义与特点：知识共享组织推出的"无版权"声明，法律效力在全球范围内都非常严谨（解决了一些国家法律不允许作者放弃版权的问题）。
优点：使用者可以做任何事，无需署名、无需保留版权。
缺点：无专利保护。
应用场景：代码示例、教程素材、数据集、公共文档、设计资源。
何时选择：希望代码或内容完全属于公共领域，连"保留作者署名"的要求都不需要。

13. The Unlicense

定义与特点：专为软件代码设计的"完全放弃版权"许可证，条款极其简短直白。
优点：明确宣称"这是一个无许可证的软件"，所有人可以自由复制、修改、发布、商业化。
缺点：在某些民法典国家的法律效力不如 CC0 严谨。
应用场景：个人极小 Demo、算法模板、配置模版。
何时选择：纯粹想把代码扔进网络，不在乎任何版权、署名或后续发展。

快捷选型指南（决策树）

你的核心诉求	推荐选择	典型代表
我不在乎谁用，越多人用越好，公司随便用	MIT License	React, Vue, jQuery
给公司用，但我想防止别人拿我的技术搞专利起诉	Apache License 2.0	Android, Kubernetes
我写的是基础库，别人动态调用可以闭源，但改我的库必须开源	LGPL v2.1	FFmpeg
任何人只要用了我的代码，整个软件都必须开源（桌面/软件）	GPL v3.0	Blender, Ansible
我做的是 Web/云端服务，防止云厂商拿去搞 SaaS 商业化	AGPL v3.0	Mastodon, Grafana
彻底放弃版权，随便拿去用，署名都不用写	CC0 1.0 或 The Unlicense	教程代码、数据集