五分钟看懂开源协议

8,826 阅读6分钟

这是 ZY 第 12 篇原创技术文章

身为程序员,我们不可避免的要和开源项目打交道,不管是我们自己做了些开源项目,还是使用开源项目,对各种开源协议的了解是必要的。
这篇文章旨在短时间内让读者朋友们对常见的开源协议有了了解,在创建自己开源项目时可以灵活选用协议,在使用开源项目时也可以避免踩到开源协议的坑。
基于上述目的,文章篇幅不长,如果感觉不过瘾,建议多读几遍~

文章概览

summary

一、OSI(Open Source Initiative)

OSI,开发源代码组织,是一个旨在推动开源软件发展的非盈利组织。目前受到 OSI 承认的开源协议一共 83 种,具体协议可以在 OSI 官网 查看。

二、在 Github 上如何添加开源协议

我们在 Github 上创建一个开源项目时,新建一个名为 LICENSE 的文件时,就会弹出选择开源协议的按钮,我们点进去就可以看到,Github 默认支持的协议模板。点击协议会有详细的介绍。

github-license
github

我们下面就看看这几种协议的内容,以及在这几种协议中如何去选择。协议的具体内容在这里不做解读,因为实在是篇幅不短,先聊聊其中的重点。

三、Apache 2.0

3.1 关键词

修改代码需要说明

3.2 关键点

  1. 需要保留原有作者的声明
  2. 如果修改了代码,需要进行说明
  3. 不承担责任
  4. 可以新增许可,但不能对 Apache 协议造成更改

3.3 商业化

可用于商业

3.4 举个栗子

小益使用 Apache 协议开源了一个 Android 类库,只要小张引用类库时保留了原作者的声明,并对修改的源码进行说明,那后续项目开源与否,都是符合协议的。

3.5 使用此协议的开源项目

hadoop,tomcat

四、BSD 2

4.1 关键词

声明协议

4.2 关键点

  1. 再发布的产品中包含源代码,则在源代码中必须带有原来代码中的BSD协议
  2. 如果再发布的只是二进制类库/软件,则需要在类库/软件的文档那个和版权声明中包含原来代码中的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 关键点

  1. 软件中必须包含许可声明

6.3 商业化

允许商业化

6.4 举个栗子

小益使用 MIT 协议开源了一个 Android 类库,只要小张引用类库时保留包含了许可声明,那后续项目开源与否,都是符合协议的。

6.5 使用此协议的开源项目

vue,react,bootstrap,vscode,electron,axios,terminal

七、GPL 2.0

7.1 关键词

感染

7.2 关键点

  1. 使用 / 修改 / 衍生 GPL 类库的代码或软件,必须也采用 GPL 协议进行开源
  2. 项目开源后可以再增加其他开源协议,但是协议必须比 GPL 宽泛
  3. 不提供品质担保,使用采用此协议的软件产生的任何后果都不会负责

7.3 商业化

可以用于商业,但是必须开放源码

7.4 举个栗子

小益使用 GPL 协议开源了一个 Android 类库,这个时候小张做开发时,本着不重复造轮子的想法,在项目中引用了小益的类库。项目开发完成以后,小张想把项目上架到 GooglePlay,但是不想开源,这个时候就违反了 GPL 协议。 为了不违反协议,小张索性将项目开源,而在选择开源协议的时候,小张必须选择 GPL 协议。

GPL 的本质就是生生不息,不断衍生。

7.5 使用此协议的的开源项目

Linux,GCC,scapy

八、GPL 3.0

GPL 3.0 相比 2.0 新增了一些条例:

  1. 任何向 GPL 项目贡献的成果将永远以 GPL 协议发行
  2. GPL 软件设备的用户有权更改软件

使用此协议的的开源项目

GIMP,Bash,YouCompleteMe

九、LGPL

9.1 关键词

引用类库无需开源

9.2 关键点

  1. LGPL 允许商业软件通过引用(link)的方式使用 LGPL 类库,而不需要开放源代码
  2. 但是如果修改或衍生 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 关键点

  1. 修改源码后发布需要开源
  2. 软件贡献者再次将源码开源发布时,需要使用 EPL 协议,除非得到作者授权
  3. 项目中引用了 EPL 协议的代码,项目开源时可以使用其他协议,但是引用的那部分代码仍然需要使用 EPL 协议

11.3 商业化

允许闭源商业软件的发布和销售

11.4 使用此协议的开源项目

che

十二、MPL

12.1 关键词

版权集中

12.2 关键点

  1. 修改后的代码版权归软件的发起者,可以免费使用

12.3 商业化

允许闭源商业软件的发布和销售

12.4 举个栗子

小益使用 MPL 协议开源了一个 Android 类库,小张对源码进行修改以后重新发布,修改后的源码版权也属于小益。

12.5 使用此协议的开源项目

syncthing,firefox-ios

十三、如何选择开源协议

  1. 如果想省事,不关系别人用自己的代码去做什么,直接选 MIT 或者 BSD 就好
  2. 如果想代码修改以后做出声明,选择 Apache 协议
  3. 如果想“繁衍”后代,那么使用 GPL 协议

其实看了上述介绍,了解了各个协议之间的区别,我们基本上也就清楚项目该选哪种协议了。如果还不清楚,可参照此 网站

总结

summary

参考

zh.wikipedia.org/wiki/GNU通用公…
www.gnu.org/licenses/ol…
jxself.org/translation…
www.cnblogs.com/onlycxue/ar…

后续会不定期更新五分钟系列,内容主要集中在一些不太需要深入的技术点,旨在让读者朋友们快速了解一些技术概念,

关于我

about