BSD / MIT / Apache Licence
这3个协议都是比较自由的协议,源代码可以拿来修改,并商用,而自己的其他代码不需要开源。
BSD是"Berkeley Software Distribution"的缩写,意思是"伯克利软件发行版"。
BSD开源协议是一个给予使用者很大自由的协议。基本上使用者可以"为所欲为",可以自由的使用,修改源代码,也可以将修改后的代码作为开源或者专有软件再发布。但"为所欲为"的前提是当你发布使用了BSD协议的代码,或者以BSD协议代码为基础做二次开发自己的产品时,需要满足三个条件:1.如果再发布的产品中包含源代码,则在源代码中必须带有原来代码中的BSD协议。2.如果再发布的只是二进制类库/软件,则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。3.不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
协议介绍
BSD开源协议(original BSD license、FreeBSD license、Original BSD license)是一个给于使用者很大自由的协议,BSD 代码鼓励代码共享,但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码,也允许使用或在BSD代码上开发商业软件发布和销售,因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议,因为可以完全控制这些第三方的代码,在必要的时候可以修改或者二次开发。
MIT是和BSD一样宽范的许可协议,源自麻省理工学院(Massachusetts Institute of Technology, MIT),又称X11协议。
作者只想保留版权,而无任何其他了限制。MIT与BSD类似,但是比BSD协议更加宽松,是目前最少限制的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。使用MIT的软件项目有:jquery、Node.js。
MIT与BSD类似,但是比BSD协议更加宽松,是目前最少限制的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。
Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似,同样鼓励代码共享和尊重原作者的著作权,同样允许代码修改,再发布(作为开源或商业软件)。
用一句话概括 Apache License 就是,你可以用这代码,但是如果开源你必须保留我写的声明;你可以改我的代码,但是如果开源你必须写清楚你改了哪些;你可以加新的协议要求,但不能与我所公布的协议要求产生冲突;你用这代码干什么我不管,但是你不能让我承担任何责任。
--------------------------
自由软件通用的GPL协议
GPL 是 GNU General Public License (GNU 通用公共许可证)的缩写形式;LGPL 是 GNU Lesser General Public License (GNU 宽通用公共许可证)的缩写形式,旧称 GNU Library General Public License (GNU 库通用公共许可证);GFDL 是 GNU Free Documentation License (GNU 自由文档许可证)的缩写形式。它们是自由软件(Free Software)的通用版权认证协议,由自由软件基金会(FSF)制定和发布。
* 基于 GPL 的软件允许商业化销售,但不允许封闭源代码。
* 如果您对遵循 GPL 的软件进行任何改动和/或再次开发并予以发布,则您的产品必须继承 GPL 协议,不允许封闭源代码。
* 基于 LGPL 的软件也允许商业化销售,但不允许封闭源代码。
* 如果您对遵循 LGPL 的软件进行任何改动和/或再次开发并予以发布,则您的产品必须继承 LGPL 协议,不允许封闭源代码。但是如果您的程序对遵循 LGPL 的软件进行任何连接、调用而不是包含,则允许封闭源代码。
GPL(General Public License)和LGPL( Lesser General Public License)是GNU的两种License。越来越多的自由软件(Free Software)使用GPL作为其授权声明,如果对GPL一点都不了解,有可能在使用自由软件时违反了GPL的授权。如果是个人或不正规的公司倒也无所 谓,但如果是有规模的公司,恐怕会有被起诉的风险。
LGPL是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL 允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。
但是如果修改LGPL协议的代码或者衍生,则所有修改的代码,涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用,但不适合希望以LGPL协议代码为基础,通过修改和衍生的方式做二次开发的商业软件采用。
GNU C库选择的是LGPL。
如果你使用动态链接的形式链接到LGPL包括的库时,那么,不受限制,你可以以任何形式或许可证发布你的应用程序,商业的、非商业的、开源的、非开源的,随你。
如果你因某种原因必须静态链接一个基于 LGPL 协议发布的库(一下我们简称为 LGPL 库),那么,你有义务进行下面的工作:
你必须在你的文档中说明,你的程序中使用了 LGPL 库,并且说明这个库是基于 LGPL 发布的;
你必须在你的应用程序发布中包含一份 LGPL协议,通常就是那个文本文件;
你必须开放使用了 LGPL 库代码的所有代码,例如某些封装器。但是,其他使用这些封装器的代码就不需要开放了;
你必须包含你的应用程序的余下部分的目标文件(通常就是我们所说的 .o 等等),或者是其他等价的文件。源代码并不是必须的。
为了自由软件的发展,使用GPL协议貌似是更好的选择,让大家都使用基于GPL协议的软件来构建自己的软件,然后自己的软件也变成GPL协议,可以供其他人来继续使用。
在使用过程中,代码开放,能更好的发现问题和解决问题,使整个生态不断演化和前进。
听起来很好,但很多软件不会选择开发源码,比如很多商用软件或私有软件。这些软件在选择某个软件库时,如果是GPL协议,那可能就会考虑选择其他替代品,或者自己开发,除非这个功能过于特殊。
那这样的话,实际上就限制了自由软件的使用和发展,显然需要调整一下。这时使用LGPL协议,使用库文件不需要开放源码,就会是更好的选择。
当一个库所提供的功能是非常独特的时候,如GNU Readline, 情况就大不一样了. Readline库可实现输入编辑和记录交互式程序操作,这在别处通常是不可多得. 在GPL下发布它并限制它只能在自由程序中使用, 这我们的社团是一个重要的促进.至少今天某个应用程序之所以是自由软件,只是因为它必需要用到Readline.
如果我们收集一些强大的、私有软件中没有相类似东西的、采用GPL的库,它们将提供一系列有用 的模块用于新的自由软件的构造. 这对于将来的自由软件开发将是一个显著的优势, 一些项目将为了使用这些库而考虑使软件自由化. 大学的项目是易于被影响的;而且今天,随着某些公司开始考虑使软件自由化, 甚至一些商业项目也会由此受到影响.
那么选择逻辑来了:
1,如果你的软件需要引用开源软件,而你不想自己的代码开源。你可以选择MIT、BSD、Apache和LGPL。
1.1 MIT和BSD的区别是,MIT可以用原作者的名字进行促销。
1.2 Apache的区别是,你对开源软件做了改动,然后还要进行开源的话,需要把修改的内容描述清楚。
1.3 LGPL不同之处,你只能使用二进制库文件进行链接,而不需要开放源码。但一旦进行修改或衍生,就要采用LGPL协议。
所以LGPL协议不适合对有些开源软件进行二次开发,因为你开发了,要开源,但别人用库就可以,不用开源它的代码。
2,如果你的软件需要引用开源软件,而你自己的代码也可以开源,你可以选择GPL。(当然MIT、BSD和Apache也可以用)
GPL是有传染性的,你代码里使用、引用或衍生GPL协议的代码,那你也要遵循GPL协议,开源自己的代码。
附上一个帮助选择License的网站: