aoi学院

Aisaka's Blog, School of Aoi, Aisaka University

开发知识-开发人员需要知道的6种开源协议

什么是软件许可协议?

通俗来讲,许可协议是指用来授权其他人具有某种使用你的作品的权利。

依靠许可协议将你的作品对外开源或者对你的作品的各个方面逐一进行授权,是一个不错的方法(WordPress, Drupal 和许多其它的内容管理系统都是开源软件)。一旦对外开源,你将失去所有对你的作品的版权,别人也没有义务将你标注为作品的原创者或捐献者。

开源许可协议使人们免去了研究那些专业的许可条款的麻烦,使人们更方便的对开源项目贡献出自己的代码。而且它还能保护你作为作品的原创作者,确保你至少拥有由于贡献参与而带来的署名荣誉。它还能用来阻止其他人企图声明对你的作品拥有所有权的行为。

但是很多的软件作者和设计者都对各种不同的开源许可协议的内容和含义不甚了了。当你选择了某种开源许可协议时,你都放弃了哪些权力?在没有能明白各种开源协议的确切含义前,在不知道它们最适用于什么情况下时,软件开发者不可能在关于哪个许可协议最适合自己的软件的问题上做出准确的抉择。


BSD

BSD开源协议(original BSD license、FreeBSD license、Original BSD license)。BSD是”Berkeley Software Distribution”的缩写,意思是”伯克利软件发行版”。

BSD开源协议是一个给于使用者很大自由的协议。基本上使用者可以”为所欲为”,可以自由的使用,修改源代码,也可以将修改后的代码作为开源或者专有软件再发布。

但“为所欲为”的前提当你发布使用了BSD协议的代码,或则以BSD协议代码为基础做二次开发自己的产品时,需要满足三个条件:

  1. 如果再发布的产品中包含源代码,则在源代码中必须带有原来代码中的BSD协议。
  2. 如果再发布的只是二进制类库/软件,则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
  3. 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。

BSD 代码鼓励代码共享,但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码,也允许使用或在BSD代码上开发商业软件发布和销售,因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议,因为可以完全控制这些第三方的代码,在必要的时候可以修改或者二次开发。

相较于GPL许可证和MPL许可证的严格性,BSD许可证就宽松许多了,一样是只需要附上许可证的原文,不过比较有趣的是,它还要求所有进一步开发者将自己的版权资料放上去,所以拿到以BSD许可证发行的软件可能会遇到一个小状况,就是这些版权资料许可证占的空间比程序还大。


Apache Licence

Apache Licence 2.0(Apache License, Version 2.0、Apache License, Version 1.1、Apache License, Version 1.0)

Apache License(Apache许可证),是Apache软件基金会发布的一个自由软件许可证。

Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似,同样鼓励代码共享和尊重原作者的著作权,同样允许代码修改,再发布(作为开源或商业软件)。需要满足的条件也和BSD类似:

  1. 需要给代码的用户一份Apache Licence。(代码可以商用或开源,但是如果开源必须要保留原有的开源声明)
  2. 如果你修改了代码,需要再被修改的文件中说明。(代码可以随意修改,如果开源,必须要写明修改的内容)
  3. 在延伸的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的协议,商标,专利声明和其他原来作者规定需要包含的说明。
  4. 如果再发布的产品中包含一个Notice文件,则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可,但不可以表现为对Apache Licence构成更改。(修改后开源的,可以加新的协议要求,但是不能与之前的apache协议冲突。)
  5. Apache Licence也是对商业应用友好的许可。使用者也可以再需要的时候修改代码来满足并作为开源或商业产品发布/销售。(代码可以任意使用,原作者不承担任何责任)

使用这个协议的好处是:

  1. 永久权利。一旦被授权,永久拥有。
  2. 全球范围的权利。在一个国家获得授权,适用于所有国家。假如你在美国,许可是从印度授权的,也没有问题。
  3. 授权免费。无版税, 前期、后期均无任何费用。
  4. 授权无排他性。任何人都可以获得授权。
  5. 授权不可撤消。一旦获得授权,没有任何人可以取消。比如,你基于该产品代码开发了衍生产品,你不用担心会在某一天被禁止使用该代码。

GPL

GPL(GNU General Public License)

GPL协议又分为v1、v2、v3,GPL协议最早由大名鼎鼎的斯托曼创建。

  • v1:已经gpl开源的软件不能修改协议成为闭源,修改的代码必须开源。开源并不免费,如果提供软件维护服务,可以向用户收取服务费。如果把gpl软件作为其中一个独立服务,软件不需要开源。
  • v2:在v1基础上,加上了一条限制,主要是强调gpl软件如果和自己开发的软件一起发布,自己开发的软件就必须开源,如果分开发布,就可以不开源
  • v3:在v2的基础上进一步收紧,不管是不是一起发布,只要用到了gpl软件,都必须开源

我们很熟悉的Linux就是采用了GPL。GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用,但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux,包括商业公司的linux和linux上各种各样的由个人、组织以及商业软件公司开发的免费软件了。

GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用,修改后的代码或者衍生代码)GPL 协议的产品,则该软件产品必须也采用GPL协议,既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题,还可以享受免费的优势。

由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议,对于使用GPL协议的开源代码,商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。

其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。


MPL

MPL (Mozilla Public License 1.1)

MPL协议允许免费重发布、免费修改,但要求修改后的代码版权归软件的发起者。这种授权维护了商业软件的利益,它要求基于这种软件的修改无偿贡献版权给该软件。这样,围绕该软件的所有代码的版权都集中在发起开发人的手中。但MPL是允许修改和无偿使用的。MPL软件对链接没有要求。


LGPL

LGPL(GNU Lesser General Public License)

LGPL是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL 允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。

但是如果修改LGPL协议的代码或者衍生,则所有修改的代码,涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用,但不适合希望以LGPL协议代码为基础,通过修改和衍生的方式做二次开发的商业软件采用。

GPL/LGPL都保障原作者的知识产权,避免有人利用开源代码复制并开发类似的产品


MIT

The MIT License

MIT是和BSD一样宽范的许可协议,源自麻省理工学院(Massachusetts Institute of Technology, MIT),又称“X许可协议”(X License)或“X11许可协议”(X11 License)。作者只想保留版权,而无任何其他了限制。MIT与BSD类似,但是比BSD协议更加宽松,是目前最少限制的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。使用MIT的软件项目有:jquery、Node.js。

MIT与BSD类似,但是比BSD协议更加宽松,是目前最少限制的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息,被许可人有权利使用、复制、修改、合并、出版发行、散布、再许可和/或贩售软件及软件的副本,及授予被供应人同等权利,但是在软件和软件的所有副本中都必须包含以上著作权声明和本许可声明。适用商业软件。使用MIT的软件项目有:jquery、Node.js。

MIT 协议是所有开源许可中最宽松的一个,除了必须包含许可声明外,再无任何限制。


总结


参考资料

https://jokerliang.com/developers-will-know-5-kinds-of-open-source-licenses.html
https://guizimo.blog.csdn.net/article/details/105801442
https://fuhanghang.blog.csdn.net/article/details/84035846
https://blog.csdn.net/qietingfengsong/article/details/124745148