在 GitHub 上，开源项目通常会使用一些常见的开源协议来定义项目的使用、修改和分发规则。以下是目前 GitHub 上最常见的几种开源协议及其差异和示例说明：
TL;DR
| 协议 | 宽松程度 | 是否强制开源 | 专利保护 | 适用场景 |
|---|---|---|---|---|
| MIT | 最宽松 | 否 | 无 | 希望代码被广泛使用 |
| Apache 2.0 | 宽松 | 否 | 有 | 希望提供专利保护 |
| GPL | 严格 | 是 | 无 | 希望确保代码始终开源 |
| LGPL | 较宽松 | 部分是 | 无 | 希望代码被更广泛集成 |
| BSD | 宽松 | 否 | 无 | 希望代码被广泛使用且简单 |
| MPL 2.0 | 中等 | 部分是 | 无 | 希望代码部分开源但允许混合 |
协议详解
1. MIT License
- 特点：
- 非常宽松，几乎没有任何限制。
- 允许用户自由使用、复制、修改、合并、发布、分发、再授权甚至用于商业用途。
- 唯一要求是保留原始版权声明和许可声明。
- 适用场景：
- 适合希望代码被广泛使用的开发者。
- 示例：Vue.js 使用了 MIT License 。
- 差异：
- 相较于其他协议（如 GPL），MIT 不强制要求衍生作品也必须开源。
2. Apache License 2.0
- 特点：
- 提供了明确的专利授权条款，保护用户免受潜在的专利诉讼。
- 允许用户自由使用、修改和分发代码，但需要保留版权声明和许可证文件。
- 明确限制商标使用，不允许用原作者的商标进行宣传。
- 适用场景：
- 适合希望保护知识产权并提供专利保障的项目。
- 示例：Apache Kafka 使用了 Apache License 2.0 。
- 差异：
- 比 MIT 更加详细，特别是关于专利和商标的规定。
3. GNU General Public License (GPL)
- 特点：
- 强制性开源，任何基于 GPL 代码的衍生作品也必须以 GPL 协议发布。
- 用户可以自由使用、修改和分发代码，但必须公开源码。
- 适用场景：
- 适合希望确保代码始终开源的项目。
- 示例：Linux Kernel 使用了 GPL 。
- 差异：
- 相较于 MIT 和 Apache，GPL 对衍生作品有更强的约束力。
4. Lesser GNU General Public License (LGPL)
- 特点：
- 是 GPL 的一个变种，允许将 LGPL 代码作为库链接到闭源项目中。
- 衍生作品如果是独立模块，可以不公开源码；但如果修改了 LGPL 库本身，则必须公开修改后的代码。
- 适用场景：
- 适合希望代码被更广泛地集成到商业项目中的库类项目。
- 示例：GNU C Library (glibc) 使用了 LGPL 。
- 差异：
- 比 GPL 更宽松，但仍要求对库本身的修改保持开源。
5. BSD License
- 特点：
- 类似于 MIT，非常宽松。
- 分为两种主要版本：2-Clause（简化版）和 3-Clause（禁止用项目名称做广告）。
- 要求保留版权声明和许可证文件。
- 适用场景：
- 适合希望代码被广泛使用且不介意闭源衍生作品的项目。
- 示例：FreeBSD 使用了 BSD License 。
- 差异：
- 相较于 MIT，3-Clause 版本增加了对广告的限制。
6. Mozilla Public License 2.0 (MPL 2.0)
- 特点：
- 是 BSD 系协议和 GPL 系协议的折中。
- 要求对 MPL 覆盖的代码部分保持开源，但允许与闭源代码混合。
- 必须保留版权信息，并公开对覆盖代码的修改。
- 适用场景：
- 适合希望代码部分开源但允许与其他闭源代码协作的项目。
- 示例：Firefox 使用了 MPL 2.0 。
- 差异：
- 比 GPL 更宽松，但比 MIT 和 BSD 更严格。
7. Creative Commons (CC)
- 特点：
- 主要用于非代码内容（如文档、图片、音乐等）。
- 提供多种版本，包括 CC0（完全放弃版权）、CC BY（署名即可使用）等。
- 适用场景：
- 适合非软件项目或需要灵活授权的内容。
- 示例：Wikipedia 的部分内容使用了 CC BY-SA 。
- 差异：
- 不适用于传统意义上的代码项目。
