身为程序员，我们不可避免的要和开源项目打交道，不管是我们自己做了些开源项目，还是使用开源项目，对各种开源协议的了解是必要的。
OSI(Open Source Initiative)
OSI，开发源代码组织，是一个旨在推动开源软件发展的非盈利组织。目前受到OSI承认的开源协议一共83种，具体协议可以在OSI 官网查看。
在 Github 上如何添加开源协议
我们在 Github 上创建一个开源项目时，新建一个名为 LICENSE 的文件时，就会弹出选择开源协议的按钮，我们点进去就可以看到，Github 默认支持的协议模板。点击协议会有详细的介绍。
开源协议一览表
| 开源协议 | 特点 | 共享 | 修改 | 衍生 | 商业化 | 例子 |
|---|---|---|---|---|---|---|
| Apache | 允许商业使用和闭源，但需要保留版权声明和使用许可条款 | 可以自由地查看、使用、修改和共享源代码，但修改后的项目必须开放源代码库的链接 | 可以自由选择协议进行修改和衍生项目 | 可以自由选择协议进行商业化 | Hadoop分布式计算框架、Apache Tomcat Web服务器等 | |
| GPL | 最严格和强大的，要求任何使用、修改或衍生代码的项目都必须采用GPL协议 | 可以自由地查看、使用、修改和共享源代码 | 必须使用GPL协议进行修改和衍生项目 | 必须使用GPL协议进行商业化 | Linux操作系统、GIMP图像编辑器等 | |
| BSD | 简洁和慷慨的，允许商业使用和闭源，但需要保留版权声明 | 可以自由地查看、使用、修改和共享源代码 | 可以自由选择协议进行修改和衍生项目 | 可以自由选择协议进行商业化 | FreeBSD操作系统、Nginx Web服务器等 | |
| MIT | 简单和宽松的，允许商业使用和闭源，但需要保留版权声明 | 可以自由地查看、使用、修改和共享源代码 | 可以自由选择协议进行修改和衍生项目 | 可以自由选择协议进行商业化 | React JavaScript库、TensorFlow机器学习框架等 | |
| Mozilla | 旨在保护用户隐私和自由，允许商业使用和闭源，但需要保留版权声明 | 可以自由地查看、使用、修改和共享源代码 | 必须使用MPL协议进行修改和衍生项目 | 必须使用MPL协议进行商业化 | Firefox浏览器、Rust编程语言等 | |
| LGPL | 允许商业使用和闭源，但需要保留版权声明和使用许可条款，并开放源代码库的链接 | 可以自由地查看、使用、修改和共享源代码，但修改后的项目必须开放源代码库的链接 | 必须使用LGPL协议进行修改和衍生项目，并开放源代码库的链接 | 必须使用LGPL协议进行商业化，并开放源代码库的链接 | Qt开发框架、GTK+图形界面库等 |
三、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 协议
其实看了上述介绍，了解了各个协议之间的区别，我们基本上也就清楚项目该选哪种协议了。如果还不清楚，可参照此网站。
参考
GNU通用公共许可证
GNU General Public License, version 1
GNU通用公共许可协议
LGPL 与GPL的区别
