开源 License
作为一个开源爱好者，我们经常会写一些开源的软件或者工具在网上分享，或者为一些其他的开源软件贡献一些自己的力量，但是对于开源许可（License）是有很多种的，每一种有不同的约束，在法治国家是具有法律约束力的。
概念
贡献者（Contributors）& 受益者（Recipients）
贡献者（Contributors） 指的是对某个开源软件或项目提供了代码（包括最初的或者修改过的）并发布的人或实体（团队、公司、组织等），按照参与时间先后，可以分为初始贡献者（Initial Contributor）和后续贡献者（Subsequent Contributors）。
受益者（Recipients） 指的是开源软件或项目的获取者，也就是那些用了这个开源软件的人，后续贡献者也属于受益者之列。
源码（Source Code）& 类库（Object Code）
源码（Source Code） 就是指各种语言写成的源代码，通过源码结合文档，我们可以了解各个开源软件的具体细节，也可以做很多的修改。
类库（Object Code） 就是指由源码编译后生成的”类库”，当然很多语言不需要编译，那源码本身就是类库。
分清楚这两个概念很重要，有些开源协议对”你发布的是哪种 Code 时应该怎样”有着明确的约束。
衍生模块（Derivative Module）& 独立模块（Separate Module）
衍生模块（Derivative Module） 指的是依托或包含”最初的”或者”从别人处获取的”开源代码而产生的代码，是原源代码的增强、改善和延续的模块。
独立模块（Separate Module） 指的是参考或借助原源代码开发出的独立的、不包含也不依赖于原源代码的模块。
理解这两个概念的目的在于，很多开源许可对涉及商业发布时，哪些是衍生的、哪些是独立的，有着明确的规定。
开放源码促进会（Open Source Initiative）
简称 OSI，1998 年 2 月由 Bruce Perens 和 Eric S. Raymond 创立，旨在推动和促进开源软件的发展。官网是 opensource.org。
目前经过 OSI 批准的开源协议有 76 种，列表在官网上有，另有一份介绍比较全面的列表。
常见协议
我们常见的开源 License：BSD、Apache、GPL、LGPL、MIT、MPL 都是 OSI 批准的，它们对受益者有着不同的约束。
BSD License
BSD 是 Berkeley Software Distribution 的缩写，出现于上世纪 70 年代，最初是为了发行 UNIX 衍生版操作系统而起草的。
这个 License 给了使用者很大的自由，基本上可以自由使用、修改源代码，也可以将修改后的代码作为开源或专有软件再发布。
对使用者的约束：
- 如果再发布的产品中包含源代码，则源代码中必须带有原来的 BSD License。
- 如果再发布的只是二进制类库/软件，则需要在文档和版权声明中包含原来的 BSD License。
- 不可以用开源代码的作者/机构名字和原产品名字做市场推广。
举个例子：你用开源代码 A 修改后产生了产品 B，你对 B 的控制由你自己决定，可以用任何协议再开源，也可以闭源商业发布。但因为 B 中包含了 A，你需要在 B 的版权声明中注明有使用到 A，并附带上 A 的开源协议，且不能以原作者名义做商业推广。
目前常见的版本有：BSD 3-Clause License、BSD 2-Clause License。
Apache License
由 Apache Software Foundation（ASF） 起草，现在流行的是 Apache License 2.0。
该 License 和 BSD License 类似，鼓励代码共享和尊重原作者的著作权，允许代码修改和再发布（开源或商业）。
需要满足的条件：
- 需要给代码提供一份 Apache License。
- 如果修改了代码，需要在被修改的文件中说明。
- 衍生代码中需要带有原代码中的 License、商标、专利声明和其他原作者规定需要包含的说明。
- 如果再发布的产品包含 Notice 文件，则 Notice 文件中需要带有 Apache License。
MIT License
最早于 1988 年由麻省理工学院（MIT）起草，作者只想保留版权，而无任何其他限制。
你必须在发行版里包含原许可协议的声明，无论是以二进制还是源代码形式发布。商业软件可以使用，也可以修改 MIT License 的代码，甚至可以出售。
GPL
GNU General Public License，简称 GPL，第一个版本起草于 1989 年 2 月。旨在保证代码的开源/免费使用，以及引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码以闭源商业软件形式发布和销售。目前使用该 License 最为我们熟悉的就是 Linux。
GPL 的”传染性”：只要在软件中使用了 GPL 许可的产品（类库引用、修改后的代码或衍生代码），该软件产品也必须采用 GPL 许可，即必须开源和免费。
因此，对于代码有保密要求的商业软件，GPL 许可的开源代码不适合作为类库或二次开发的基础。
LGPL
GNU Lesser General Public License，简称 LGPL。因为 GPL 太严苛，为了让商业公司也能使用，设计了 LGPL。
LGPL 允许商业软件通过类库引用（link）方式使用 LGPL 类库而不需要开源商业软件的代码。但如果修改了 LGPL 许可的代码或做了衍生，则所有修改的代码和衍生代码都必须采用 LGPL 许可。
简单说：商业软件可以使用，但不能修改 LGPL 许可的代码——改了人家的代码你也要开源。
MPL
The Mozilla Public License，简称 MPL，1998 年初由 Netscape 公司的 Mozilla 小组为其开源软件项目设计。
MPL 允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者。这种授权维护了商业软件的利益，要求基于这种软件的修改无偿贡献版权给该软件，围绕该软件的所有代码版权都集中在发起开发人手中。商业软件可以使用，也可以修改 MPL-2.0 协议的代码，但修改后的代码版权归软件的发起者。
各种 License 对比
几个关键维度的说明：
| 项目 | 描述 |
|---|---|
| License and copyright notice | 在代码中保留作者提供的许可和版权信息 |
| State Changes | 在代码中声明对原来代码的重大修改及变更 |
| Disclose Source | 代码必须公开。基于 LGPL 协议则只需公开使用的开源代码部分 |
| Library usage | 该库可以用于商业软件中 |
| Hold Liable | 代码的作者承担代码使用后的风险及后果 |
| Use Trademark | 可以使用作者的姓名、Logo 或商标 |
| Sublicensing | 允许在软件分发传播过程中附加原来没有的许可条款 |
各 License 的要求、允许与禁止对比：
| License | 要求 | 允许 | 禁止 |
|---|---|---|---|
| BSD | 许可和版权信息 | 商用、分发、修改、私用、附加许可 | 责任承担 |
| Apache | 协议和版权信息、声明变更 | 商用、分发、修改、私用、专利授权、附加许可 | 责任承担、商标使用 |
| MIT | 许可和版权信息 | 商用、分发、修改、私用、附加许可 | 责任承担 |
| MPL | 公开源码（全部）、协议和版权信息 | 商用、分发、修改、私用、专利授权、附加许可 | 责任承担、商标使用 |
| GPL | 公开源码（全部）、协议和版权信息、声明变更 | 商用、分发、修改、私用、专利授权 | 责任承担、附加许可 |
| LGPL | 公开源码（修改部分）、协议和版权信息、库引用 | 商用、分发、修改、私用、专利授权、附加许可 | 责任承担 |
| No license | 协议和版权信息 | 商用、私用 | 分发、修改、附加许可 |
| Unlicense | N/A | 商用、私用、分发、修改 | 责任承担 |
No license：你保留所有权利，不允许他人分发、复制或创造衍生物。将代码发布到 GitHub 时需遵守 GitHub 协议，别人可以查看和 Fork 你的代码。
Unlicense：你放弃版权，将劳动成果无私贡献出来，丧失对作品的全部权利。
开源授权许可的区别图：
另外值得注意的是专利授权问题。BSD、MIT 在 License 里没有明确专利授权的声明，可能存在专利授权争议。GPL-2.0、LGPL-2.1 虽有专利相关规定但不够明确，GPL-3.0 则明确了专利授权，不会存在这个问题。公司商业软件使用开源软件时需注意 License 的版本和具体描述。
你会选择哪种开源授权许可？
参考：