浅谈 开源许可证
Posted 鱼竿钓鱼干
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了浅谈 开源许可证相关的知识，希望对你有一定的参考价值。
目录
浅谈 开源许可证
最近帮开源社区打杂，有个任务涉及到使用其他开源仓库来开发。留意了一下开源许可证，发现帮忙开发的项目使用的 Apache 2.0 开源许可证，可能使用的其他开源仓库有以下几种开源许可证类型
- BSD-License
- BSD-2-Clause license
- BSD-3-Clause license
- MIT license
- GPL license
突然意识到自己仓库大多使用的是 MIT license 对于其他的一些开源许可证还不曾了解他们之间的区别，所以写一篇博客记录一下学习过程。
参考了一些不错的资料，如果觉得这篇博客写得比较零散可以直接跳到参考文献中查看详细情况。
一、什么是开源许可证
1.1 什么是开源
开源 != 免费
开源是指公开源代码，但这并不代表就是免费的，具体要看其采用的许可证或协议。
有时候，开源也可以作为一种商业模式存在
- 提供订阅服务
- 高级功能付费
- 提供云服务
- 生态价值
- 捐赠打赏
开源 != 放弃版权
开源软件并不意味着完全放弃版权，通过开源许可证可以允许其他使用者或者开发者拥有部分权利（例如专利权、是否允许修改源代码等）
1.2 什么是开源许可证
本节参考引用 阮一峰 开源许可证教程
阮一峰 开源许可证教程
开源许可证是一种法律许可。通过它，版权拥有人明确允许，用户可以免费地使用、修改、共享版权软件。
版权法默认禁止共享，也就是说，没有许可证的软件，就等同于保留版权，虽然开源了，用户只能看看源码，不能用，一用就会侵犯版权。所以软件开源的话，必须明确地授予用户开源许可证。
一般有两种主流的开源许可证
- Copyleft 许可证
- 宽松许可证
Copyleft 许可证（Copyleft 许可证）
Copyleft 与 Copyright 是反义词，Copyleft 运动是典型的反版权运动在软件领域的表现，也是开源软件的主要思想。
一般有下面几个条件
- 如果分发二进制格式，必须提供源码
- 修改后的源码，必须与修改前保持许可证一致
- 不得在原始许可证以外，附加其他限制
上面三个条件的核心就是：修改后的 Copyleft 代码不得闭源。
常见的 Copyleft 许可证有以下几种
- AGPL（在 GPL 基础上还对云服务做出要求）
- GPL（项目级别传染性）
- LGPL（库级别传染性）
- MPL（文件级别传染性）
宽松许可证（permissive 许可证）
宽松许可证基本对用户没有限制，用户开源修改代码后闭源
一般有下面几个特点
- 基本没有使用限制，可以用代码做任何事
- 没有担保，不保证代码质量，用户自己承担风险
- 披露要求，用户必须披露原始作者。
常见的 宽松许可证有以下几种
- Apache-2
- MIT
- BSD 系列
- BSD 2-Clause “Simplified” Licens
- BSD 3-Clause Clear License
- BSD 3-Clause “New” or “Revised” License
- BSD 4-Clause “Original” or “Old” License
二、为什么要有开源许可证
2.1、No License：没有开源许可证意味着什么
- 在进行创造性的工作（写作、设计、编程等）时，作品默认受专有版权保护。未经许可，他人无法复制、分发或修改作品。
- 如果作者没有应用开源许可协议，那么对项目做出贡献的人也将成为此项目的专属版权（copyright）所有者。这意味着没有人（也包括初始作者）可以使用、复制、分发后者修改他们的贡献
对于开源项目而言，一般会希望有其他人一起参与到项目的贡献当中或是将开源项目分享出去，因此最好在显眼处明确特定的开源许可证，说明关于项目的权限许可情况。
2.2、在面对没有 No License 的项目时我们应该怎么做？
对于用户
如果您发现没有许可证的软件，这通常意味着您没有获得软件创建者的许可来使用、修改或共享该软件。尽管 GitHub 等代码主机可能允许您查看和分叉代码，但这并不意味着您可以出于任何目的使用、修改或共享软件。
- 请维护者添加许可证。除非软件包含相反的强烈指示，否则缺少许可证可能是一种疏忽。如果软件托管在 GitHub 等站点上，请打开请求许可证的问题并包含指向此站点的链接。如果您大胆并且很明显哪个许可证最合适，请打开拉取请求以添加许可证 - 请参阅此站点上每个许可证（例如，MIT）页面侧栏中的“建议此许可证”。
- 请勿使用该软件。查找或创建开源许可证下的替代方案。
- 协商私人许可证。带上你的律师。
三、常见的开源许可证
3.1 基本术语
在 https://choosealicense.com/appendix/ 你可以看到常见开源协议的许可、条件和限制情况
如果你在创建 GitHub 仓库时选择了特定的开源许可证，你可以在 LICENSE 的详细页看到下面这幅图
它指明了 Apache License 2.0 许可证的以下三点
- Permissions
- Limitations
- Conditions
下面介绍一下图表中涉及到的一些术语概念
许可 permissions
| 术语 | 中文 | 含义 |
|---|---|---|
| Commercial use | 商业用途 | 许可材料和衍生品可用于商业目的 |
| Distribution | 分配(分发) | 许可材料可以分发 |
| Modification | 修改 | 许可材料可以修改 |
| Patent use | 专利用途 | 该许可证提供来自贡献者的专利权的明确授予 |
| Private use | 私人使用 | 许可材料可以私下使用和修改 |
条件 conditions
| 术语 | 中文 | 含义 |
|---|---|---|
| Disclose source | 披露来源 | 分发许可材料时，必须提供源代码 |
| License and copyright notice | 许可和版权声明 | 许可材料中必须包含许可和版权声明的副本 |
| License and copyright notice for source | 源代码的许可和版权声明 | 许可和版权声明的副本必须以源形式包含在许可材料中，但二进制文件不需要 |
| Network use is distribution | 网络使用就是分布 | 通过网络与许可材料交互的用户有权接收源代码的副本 |
| Same license | 相同的许可证 | 分发许可材料时，必须在同一许可下发布修改。在某些情况下，可以使用类似或相关的许可证 |
| Same license (file) | 相同的许可证（文件） | 分发许可材料时，必须在同一许可证下发布对现有文件的修改。在某些情况下，可以使用类似或相关的许可证 |
| Same license (library) | 相同的许可证（库） | 分发许可材料时，必须在同一许可下发布修改。在某些情况下，可以使用类似或相关的许可，或者此条件可能不适用于将许可材料用作库的作品 |
| State changes | 状态更改 | 对许可材料所做的更改必须记录在案 |
限制 limitations
| 术语 | 中文 | 含义 |
|---|---|---|
| Liability | 责任 | 本许可包括责任限制 |
| Trademark use | 商标使用 | 该许可证明确声明它不授予商标权，即使没有此类声明的许可证可能不会授予任何隐含的商标权 |
| Warranty | 保证 | 本许可证明确声明它不提供任何保证 |
3.2 常见的开源协议
Apache-2.0（最受商业软件喜爱）
https://choosealicense.com/licenses/apache-2.0/
一种宽松的许可证，其主要条件要求保存版权和许可声明。贡献者提供专利权的明确授予。许可作品、修改和大型作品可以按照不同的条款分发，并且没有源代码。
BSD 系列
主要有以下几种
- BSD 2-Clause “Simplified” Licens
- BSD 3-Clause Clear License
- BSD 3-Clause “New” or “Revised” License
- BSD 4-Clause “Original” or “Old” License
BSD 3-Clause “New” or “Revised” License
https://choosealicense.com/licenses/bsd-3-clause/
修改后的 BSD 许可证
一种类似于 BSD 2 条款许可证的宽松许可证，但第 3 条禁止他人在未经书面同意的情况下使用版权所有者或其贡献者的名义来推广衍生产品。
- 允许商业发布和销售
- 使用者可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布
- 主要条件是要求尊重代码作者的著作权，即包含原始版权和免责声明（二进制形式分发必须分发文档中包含版权申明及免责声明）
- 未经事先特别书面许可，不可以用开源代码的“作者/机构的名字”或“原来产品的名字”做市场推广
BSD 2-Clause “Simplified” License
https://choosealicense.com/licenses/bsd-2-clause/
一种宽松的许可证，有两种变体，BSD 2 条款和 BSD 3 条款。两者都与 MIT 许可证有非常细微的差异。
比 BSD 3-Clause “New” or “Revised” License 少一个条目，去掉了“不可以用开源代码的“作者/机构的名字”或“原来产品的名字”做市场推广。”.
BSD 3-Clause Clear License
https://choosealicense.com/licenses/bsd-3-clause-clear/
BSD 3-Clause “New” or “Revised” License 条款许可证的变体，明确不授予任何专利权。
BSD 4-Clause “Original” or “Old” License
https://choosealicense.com/licenses/bsd-4-clause
类似于 BSD 3 条款许可证的宽松许可证，但带有“广告条款”，要求在所有广告材料中确认原始来源。
GPL 系列
主要有以下几种
- GNU General Public License v2.0（GNU GPLv2）
- GNU General Public License v3.0（GNU GPLv3）
- GNU Lesser General Public License v2.1（GNU LGPLv2.1）
- GNU Lesser General Public License v3.0（GNU LGPLv3）
- GNU Affero General Public License v3.0（GNU AGPLv3）
GNU General Public License v2.0
https://choosealicense.com/licenses/gpl-2.0/
GNU GPLv2
GNU GPL 是使用最广泛的自由软件许可证，并且有很强的 copyleft 要求。在分发衍生作品时，作品的源代码必须在同一许可下提供。GNU GPL 有多种变体，每种变体都有不同的要求。
GNU General Public License v3.0
https://choosealicense.com/licenses/gpl-3.0/
GNU GPLv3
这种强大的 copyleft 许可证的许可条件是在同一许可证下提供许可作品和修改的完整源代码，其中包括使用许可作品的大型作品。必须保留版权和许可声明。贡献者提供专利权的明确授予。
GPLv2 和 GPLv3的差异：
- GPLv3包含了明确的专利许可
- GPLv3对类似TiVo这种硬件做了一些要求（TiVo是一种数字录像设备，它能帮助人们非常方便地录下电视节目并跳过广告）添加了对数字版权管理和加密签名的限制，不仅要求用户公开源码，还要求公布相关硬件及必要的安装信息
- 使用者可以按照要求加一些补充条款
GNU Lesser General Public License v2.1
GNU LGPLv2.1
https://choosealicense.com/licenses/lgpl-2.1/
GNU LGPL 主要用于软件库，要求派生作品在同一许可证下进行许可，但仅链接到它的作品不受此限制。GNU LGPL 有两个常用版本。
GNU Lesser General Public License v3.0
GNU LGPLv3
此 copyleft 许可证的许可条件是在同一许可证或 GNU GPLv3 下提供许可作品和修改的完整源代码。 必须保留版权和许可声明。贡献者提供专利权的明确授予。但是，通过许可作品提供的接口使用许可作品的较大作品可能会以不同的条款分发，并且没有较大作品的源代码。
GNU Affero General Public License v3.0
https://choosealicense.com/licenses/agpl-3.0/
GNU AGPLv3
这个最强大的 copyleft 许可证的许可条件是在同一许可证下提供许可作品和修改的完整源代码，其中包括使用许可作品的大型作品。必须保留版权和许可声明。贡献者提供专利权的明确授予。当修改后的版本用于通过网络提供服务时，必须提供修改版本的完整源代码。
传染性
GPL 系列的开源许可证通常具有传染性，为了促进分享，只要使用了 GPL 的代码，那么整个项目都必须以 GPL 的方式开源，也就是上面 Conditions 中的 Same license。
不同的类 GPL 开源许可有着不同强度的传染性
- GPL 是工程级别的强传染
- LGPL 是库级别的弱传染：如果只是子系统/模块用了，那么只需要子系统/模块开源，整个工程不用开源；如果是以动态链接调用LGPL许可证的库，那么项目也不用开源
- AGPL 明确了GPL 2.0/3.0关于提供网络服务也属于分发限制的说明：使用GPL的自由软件，但是并不发布与网络之中，则可以自由的使用GPL协议确不开源自己私有的解决方案。AGPL则增加了对此做法的约束。比如使用了AGPL代码的软件是一个网络应用，那么这个软件的所有源码和修改代码也必须开源
MIT
https://choosealicense.com/licenses/mit/
一个简短而简单的许可，条件只要求保护版权和许可声明。许可作品、修改和大型作品可以按照不同的条款分发，并且没有源代码。
3.3 如何选择开源许可证
可以参考这个网站 Choose an open source license
或是参考下面这份经典网图
3.4 许可证之间的兼容性
在 开源许可证兼容性指南 中可以查询到常见开源许可证之间的兼容性
开源许可证兼容性列表的使用场景是针对开源项目选择许可证，假定有一个开源软件使用了一个许可证，而你想把它的代码组合到你要发布的开源项目中。
许可证的兼容性列表可以分为以下两种情况：
- 合并/修改代码：从要组合的代码中取出整体/部分代码，修改或不修改都可以，然后把它添加到你的代码中构成一个作品。
- 使用库：没有直接复制代码，在编译或运行时通过链接、导入或其他典型的机制（例如静态与动态链接）把要组合的开源代码绑定在一起。
备注：（下方内容可以对应到兼容性列表中有【1】【2】【3】的项）
【1】LGPLv2.1 允许你把代码重新按照 GPLv2 以后的 GPL 许可证发布。所以如果你可以把 LGPL 的代码按照合适的 GPL 版本发布，那么你就可以组合两方代码。
【2】MPL的代码和GPL系列的代码组合的结果是，MPL协议的代码遵循MPL协议，GPL系列的代码遵循GPL系列协议，所以原来按照 MPL 发布的那些文件还是可以使用 MPL 条款的，组合而成的作品整体上可以按照GPL系列的许可证发布。
【3】查看双方的许可证协议中是否包含一个条款允许你将协议升级到稍后的版本。例如，LGPLv2.1和GPLv3是不兼容的，但如果两方的许可证协议中都包含“可以升级到更高版本”的条款，那么LGPLv2.1就可以升级到LGPLv3，LGPLv3和GPLv3、AGPLv3是兼容的。
- LGPL+与GPL+代表许可证授予用户将许可证升级到未来版本的权利，例如LGPLv2.1+意味着用户可以把许可证升级到LGPL v2.1之后的版本。
- 下方的表格第一行展示了你的项目要使用的许可证，左边第一列是你要组合的软件带有的开源许可证，他们之间的交叉处显示了你是否可以组合他们。
合并/修改代码的许可
证兼容性列表
| 交叉处显示两方代码是否可以组合 | MIT | BSD 2-Clause | BSD 3-Clause | Apache 2.0 | MPL 2.0 | LGPLv2.1 | LGPLv2.1+ | LGPLv3 | GPLv2 | GPLv2+ | GPLv3 | AGPLv3 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| MIT | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 |
| BSD 2-Clause | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 |
| BSD 3-Clause | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 |
| Apache 2.0 | 可以，组合遵循Apache 2.0 | 可以，组合遵循Apache2.0 | 可以，组合遵循Apache2.0 | 可以 | 可以 | 可以，组合遵循GPLv3 [1] | 可以，组合遵循GPLv3 [1] | 可以 | 不可以 | 可以，组合遵循GPLv3 [3] | 可以 | 可以 |
| MPL 2.0 | 可以，组合遵循MPL2.0 | 可以，组合遵循MPL2.0 | 可以，组合遵循MPL2.0 | 可以，组合遵循MPL2.0 | 可以 | 可以 [2] | 可以 [2] | 可以[2] | 可以[2] | 可以[2] | 可以[2] | 可以[2] |
| LGPLv2.1 | 可以，组合遵循LGPLv2.1 | 可以，组合遵循LGPLv2.1 | 可以，组合遵循LGPLv2.1 | 可以，组合遵循LGPLv2.1 | 可以[2] | 可以 | 可以,组合遵循LGPLv2.1 | 可以，组合遵循GPLv3 [1] [3] | 可以 | 可以 | 可以 | 可以 |
| LGPLv2.1+ | 可以，组合遵循LGPLv2.1+ | 可以，组合遵循LGPLv2.1+ | 可以，组合遵循LGPLv2.1+ | 可以，组合遵循LGPLv2.1+ | 可以[2] | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 |
| LGPLv3 | 可以，组合遵循LGPLv3 | 可以，组合遵循LGPLv3 | 可以，组合遵循LGPLv3 | 可以，组合遵循LGPLv3 | 可以[2] | 可以，组合遵循GPLv3 [1] [3] | 可以，组合遵循LGPLv3 | 可以 | 不可以 | 可以，组合遵循GPLv3 [3] | 可以 | 可以 |
| GPLv2 | 可以，组合遵循GPLv2 | 可以，组合遵循GPLv2 | 可以，组合遵循GPLv2 | 可以，组合遵循GPLv2 | 可以[2] | 可以，组合遵循GPLv2 [1] | 可以，组合遵循GPLv2 [1] | 不可以 | 可以 | 可以，组合遵循GPLv2 | 不可以 | 不可以 |
| GPLv2+ | 可以，组合遵循GPLv2+ | 可以，组合遵循GPLv2+ | 可以，组合遵循GPLv2+ | 可以，组合遵循GPLv2+ | 可以[2] | 可以，组合遵循GPLv2+ [1] | 可以，组合遵循GPLv2+ [1] | 可以，组合遵循GPLv3 [1] [3] | 可以 | 可以 | 可以 | 可以 |
| GPLv3 | 可以，组合遵循GPLv3 | 可以，组合遵循GPLv3 | 可以，组合遵循GPLv3 | 可以，组合遵循GPLv3 | 可以[2] | 可以，组合遵循GPLv3 [1] | 可以，组合遵循GPLv3 [1] | 可以，组合遵循GPLv3 [1] [3] | 不可以 | 可以，组合遵循GPLv3 [3] | 可以 | 可以 |
| AGPLv3 | 可以，组合遵循AGPLv3 | 可以，组合遵循AGPLv3 | 可以，组合遵循AGPLv3 | 可以，组合遵循AGPLv3 | 可以 | 可以，组合遵循AGPLv3 [1] [3] | 可以，组合遵循AGPLv3 [1] [3] | 可以，组合遵循AGPLv3 [1] [3] | 不可以 | 可以，组合遵循AGPLv3 [3] | 可以，组合遵循AGPLv3 | 可以 |
使用库的兼容性列表
| 交叉处显示两方代码是否可以组合 | MIT | BSD 2-Clause | BSD 3-Clause | Apache 2.0 | MPL 2.0 | LGPLv2.1 | LGPLv2.1+ | LGPLv3 | GPLv2 | GPLv2+ | GPLv3 | AGPLv3 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| MIT | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 |
| BSD 2-Clause | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 |
| BSD 3-Clause | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 |
| Apache 2.0 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 不可以 | 可以，组合遵循GPLv3 [3] | 可以 | 可以 |
| MPL 2.0 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 [2] | 可以 [2] | 可以[2] | 可以[2] | 可以[2] | 可以[2] | 可以[2] |
| LGPLv2.1 | 可以 | 可以 | 可以 | 可以 | 可以[2] | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 |
| LGPLv2.1+ | 可以 | 可以 | 可以 | 可以 | 可以[2] | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 | 可以 |
| LGPLv3 | 可以 | 可以 | 可以 | 可以 | 可以[2] | 可以 | 可以 | 可以 | 不可以 | 可以，组合遵循GPLv3 [3] | 可以 | 可以 |
| GPLv2 | 可以，组合遵循GPLv2 | 可以，组合遵循GPLv2 | 可以，组合遵循GPLv2 | 可以，组合遵循GPLv2 | 可以[2] | 可以，组合遵循GPLv2 [1] | 可以，组合遵循GPLv2 [1] | 不可以 | 可以 | 可以，组合遵循GPLv2 | 不可以 | 不可以 |
| GPLv2+ | 可以，组合遵循GPLv2+ | 可以，组合遵循GPLv2+ | 可以，组合遵循GPLv2+ | 可以，组合遵循GPLv2+ | 可以[2] | 可以，组合遵循GPLv2+ [1] | 可以，组合遵循GPLv2+ [1] | 可以，组合遵循GPLv3 [1] [3] | 可以 | 可以 | 可以 | 可以 |
| GPLv3 | 可以，组合遵循GPLv3 | 可以，组合遵循GPLv3 | 可以，组合遵循GPLv3 | 可以，组合遵循GPLv3 | 可以[2] | 可以，组合遵循GPLv3 [1] | 可以，组合遵循GPLv3 [1] | 可以，组合遵循GPLv3 [1] [3] | 不可以 | 可以，组合遵循GPLv3 [3] | 可以 | 可以 |
| AGPLv3 | 可以，组合遵循AGPLv3 | 可以，组合遵循AGPLv3 | 可以，组合遵循AGPLv3 | 可以，组合遵循AGPLv3 | 可以 | 可以，组合遵循AGPLv3 [1] [3] | 可以，组合遵循AGPLv3 [1] [3] | 可以，组合遵循AGPLv3 [1] [3] | 不可以 | 可以，组合遵循AGPLv3 [3] | 可以，组合遵循AGPLv3 | 可以 |
四、参考资料
- 阮一峰 开源许可证教程
- 康月牙 一篇简洁的“开源许可证” 要点说明~
- Choose an open source license
- 开源的法律保护
- wikipedia 自由及开放源代码软件许可证比较
- 常见开源协议都有哪些？开源约束是什么？
- 一文看懂开源许可证，能不能商用再也不抓瞎
- 律师视点｜没有无义务的权利：从开源软件侵权谈GPL开源合规
- ABC 时代 GPL 许可证传染性问题探讨
- 开源许可证兼容性指南
- 深入理解开源许可证（Apache,MIT,GPL,BSD,CC）
以上是关于浅谈 开源许可证的主要内容，如果未能解决你的问题，请参考以下文章
Facebook发布React 16 专利条款改为MIT开源协议