五分钟看懂开源协议
五分钟看懂开源协议
五分钟了解常用的开源协议，祝你的开源一臂之力。
身为程序员，我们不可避免的要和开源项目打交道，不管是我们自己做了些开源项目，还是使用开源项目，对各种开源协议的了解是必要的。
这篇文章旨在短时间内让读者朋友们对常见的开源协议有了了解，在创建自己开源项目时可以灵活选用协议，在使用开源项目时也可以避免踩到开源协议的坑。
基于上述目的，文章篇幅不长，如果感觉不过瘾，建议多读几遍～
OSI(Open Source Initiative)
OSI，开发源代码组织，是一个旨在推动开源软件发展的非盈利组织。目前受到 OSI 承认的开源协议一共 83 种，具体协议可以在 查看。
在 Github 上如何添加开源协议
我们在 Github 上创建一个开源项目时，新建一个名为 LICENSE 的文件时，就会弹出选择开源协议的按钮，我们点进去就可以看到，Github 默认支持的协议模板。
我们下面就看看这几种协议的内容，以及在这几种协议中如何去选择。协议的具体内容在这里不做解读，因为实在是篇幅不短，先聊聊其中的重点。
Apache 2.0
3.1 关键词
修改代码需要说明
3.2 关键点
- 需要保留原有作者的声明
- 如果修改了代码，需要进行说明
- 不承担责任
- 可以新增许可，但不能对 Apache 协议造成更改
3.3 商业化
可用于商业
3.4 举个栗子
小益使用 Apache 协议开源了一个 Android 类库，只要小张引用类库时保留了原作者的声明，并对修改的源码进行说明，那后续项目开源与否，都是符合协议的。
3.5 使用此协议的开源项目
hadoop，tomcat
BSD 2
4.1 关键词
声明协议
4.2 关键点
- 再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议
- 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档那个和版权声明中包含原来代码中的BSD协议
4.3 商业化
允许闭源商业软件的发布和销售
4.4 使用此协议的开源项目
brew
BSD 3
5.1 关键词
声明协议
5.2 关键点
相比 BSD 2.0 新增协议如下：不可以用开源代码的“作者/机构的名字”或“原来产品的名字”做市场推广
5.3 商业化
允许闭源商业软件的发布和销售
5.4 举个栗子
小益使用 BSD 协议开源了一个 Android 类库，只要小张引用类库时保留了原作者的声明，并对修改的源码进行说明，那后续项目开源与否，都是符合协议的。
5.5 使用此协议的开源项目
flask，redis，numpy
MIT
6.1 关键词
许可声明
6.2 关键点
- 软件中必须包含许可声明
6.3 商业化
允许商业化
6.4 举个栗子
小益使用 MIT 协议开源了一个 Android 类库，只要小张引用类库时保留包含了许可声明，那后续项目开源与否，都是符合协议的。
6.5 使用此协议的开源项目
vue，react，bootstrap，vscode，electron，axios，terminal
GPL 2.0
7.1 关键词
感染
7.2 关键点
- 使用 / 修改 / 衍生 GPL 类库的代码或软件，必须也采用 GPL 协议进行开源
- 项目开源后可以再增加其他开源协议，但是协议必须比 GPL 宽泛
- 不提供品质担保，使用采用此协议的软件产生的任何后果都不会负责
7.3 商业化
可以用于商业，但是必须开放源码
7.4 举个栗子
小益使用 GPL 协议开源了一个 Android 类库，这个时候小张做开发时，本着不重复造轮子的想法，在项目中引用了小益的类库。项目开发完成以后，小张想把项目上架到 GooglePlay，但是不想开源，这个时候就违反了 GPL 协议。
为了不违反协议，小张索性将项目开源，而在选择开源协议的时候，小张必须选择 GPL 协议。
GPL 的本质就是生生不息，不断衍生。
7.5 使用此协议的的开源项目
Linux，GCC，scapy
GPL 3.0
GPL 3.0 相比 2.0 新增了一些条例：
- 任何向 GPL 项目贡献的成果将永远以 GPL 协议发行
- GPL 软件设备的用户有权更改软件
使用此协议的的开源项目
GIMP，Bash，YouCompleteMe
LGPL
9.1 关键词
引用类库无需开源
9.2 关键点
- LGPL 允许商业软件通过引用(link)的方式使用 LGPL 类库，而不需要开放源代码
- 但是如果修改或衍生 LGPL 协议代码，则必须采用 LGPL 协议
9.3 商业化
适合商业软件
9.4 举个栗子
小益使用 LGPL 协议开源了一个 Android 类库，小张做开发时引用了此类库。之后小张将项目上架到 GooglePlay 而不开源，是没有违反协议的。但是小张引用类库时，是以源码的形式引用的，那就必须要将项目开源了。
9.5 使用此协议的的开源项目
alibaba/jvm-sandbox
AGPL 3.0
10.1 关键词
网络交互
10.2 关键点
AGPL 在 GPL 的基础上，增加了一条限制，通过网络与用户交互，也需要提供源代码
10.3 商业化
可以用于商业，但是必须开放源码
10.4 使用此协议的开源项目
octotree
EPL 2.0
11.1 关键词
修改源码需要开源
11.2 关键点
- 修改源码后发布需要开源
- 软件贡献者再次将源码开源发布时，需要使用 EPL 协议，除非得到作者授权
- 项目中引用了 EPL 协议的代码，项目开源时可以使用其他协议，但是引用的那部分代码仍然需要使用 EPL 协议
11.3 商业化
允许闭源商业软件的发布和销售
11.4 使用此协议的开源项目
che
MPL
12.1 关键词
版权集中
12.2 关键点
- 修改后的代码版权归软件的发起者，可以免费使用
12.3 商业化
允许闭源商业软件的发布和销售
12.4 举个栗子
小益使用 MPL 协议开源了一个 Android 类库，小张对源码进行修改以后重新发布，修改后的源码版权也属于小益。
12.5 使用此协议的开源项目
syncthing，firefox-ios
如何选择开源协议
- 如果想省事，不关系别人用自己的代码去做什么，直接选 MIT 或者 BSD 就好
- 如果想代码修改以后做出声明，选择 Apache 协议
- 如果想“繁衍”后代，那么使用 GPL 协议
其实看了上述介绍，了解了各个协议之间的区别，我们基本上也就清楚项目该选哪种协议了。如果还不清楚，可参照此 。
参考
通用公共许可证
后续会不定期更新五分钟系列，内容主要集中在一些不太需要深入的技术点，旨在让读者朋友们快速了解一些技术概念。
本文首发于 GitChat，未经授权不得转载，转载需与 GitChat 联系。
阅读全文:
您还可以下载 CSDN 旗下精品原创内容社区 GitChat App ，阅读更多 GitChat 专享技术内容哦。
