五分钟看懂开源协议

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

身为程序员,咱们不可避免的要和开源项目打交道,不论是咱们本身作了些开源项目,仍是使用开源项目,对各类开源协议的了解是必要的。
这篇文章旨在短期内让读者朋友们对常见的开源协议有了了解,在建立本身开源项目时能够灵活选用协议,在使用开源项目时也能够避免踩到开源协议的坑。
基于上述目的,文章篇幅不长,若是感受不过瘾,建议多读几遍~vue

文章概览

summary

1、OSI(Open Source Initiative)

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

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

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

github-license
github

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

3、Apache 2.0

3.1 关键词

修改代码须要说明程序员

3.2 关键点

  1. 须要保留原有做者的声明
  2. 若是修改了代码,须要进行说明
  3. 不承担责任
  4. 能够新增许可,但不能对 Apache 协议形成更改

3.3 商业化

可用于商业github

3.4 举个栗子

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

3.5 使用此协议的开源项目

hadoop,tomcatflask

4、BSD 2

4.1 关键词

声明协议bootstrap

4.2 关键点

  1. 再发布的产品中包含源代码,则在源代码中必须带有原来代码中的BSD协议
  2. 若是再发布的只是二进制类库/软件,则须要在类库/软件的文档那个和版权声明中包含原来代码中的BSD协议

4.3 商业化

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

4.4 使用此协议的开源项目

brew

5、BSD 3

5.1 关键词

声明协议

5.2 关键点

相比 BSD 2.0 新增协议以下: 不能够用开源代码的“做者/机构的名字”或“原来产品的名字”作市场推广

5.3 商业化

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

5.4 举个栗子

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

5.5 使用此协议的开源项目

flask,redis,numpy

6、MIT

6.1 关键词

许可声明

6.2 关键点

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

6.3 商业化

容许商业化

6.4 举个栗子

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

6.5 使用此协议的开源项目

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

7、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

8、GPL 3.0

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

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

使用此协议的的开源项目

GIMP,Bash,YouCompleteMe

9、LGPL

9.1 关键词

引用类库无需开源

9.2 关键点

  1. LGPL 容许商业软件经过引用(link)的方式使用 LGPL 类库,而不须要开放源代码
  2. 可是若是修改或衍生 LGPL 协议代码,则必须采用 LGPL 协议

9.3 商业化

适合商业软件

9.4 举个栗子

小益使用 LGPL 协议开源了一个 Android 类库,小张作开发时引用了此类库。以后小张将项目上架到 GooglePlay 而不开源,是没有违反协议的。可是小张引用类库时,是以源码的形式引用的,那就必需要将项目开源了。

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

alibaba/jvm-sandbox

10、AGPL 3.0

10.1 关键词

网络交互

10.2 关键点

AGPL 在 GPL 的基础上,增长了一条限制,经过网络与用户交互,也须要提供源代码

10.3 商业化

能够用于商业,可是必须开放源码

10.4 使用此协议的开源项目

octotree

11、EPL 2.0

11.1 关键词

修改源码须要开源

11.2 关键点

  1. 修改源码后发布须要开源
  2. 软件贡献者再次将源码开源发布时,须要使用 EPL 协议,除非获得做者受权
  3. 项目中引用了 EPL 协议的代码,项目开源时可使用其余协议,可是引用的那部分代码仍然须要使用 EPL 协议

11.3 商业化

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

11.4 使用此协议的开源项目

che

12、MPL

12.1 关键词

版权集中

12.2 关键点

  1. 修改后的代码版权归软件的发起者,能够无偿使用

12.3 商业化

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

12.4 举个栗子

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

12.5 使用此协议的开源项目

syncthing,firefox-ios

十3、如何选择开源协议

  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
相关文章
相关标签/搜索