Dec 15, 2015 ruochenxing open source license

各种开源协议简述

开源协议的种类

现今存在的开源协议很多,而经过Open Source Initiative 组织通过批准的开源协议目前有60多种http://www.opensource.org/licenses/alphabetical。我们在常见的开源协议如BSD, GPL, LGPL,MIT等都是OSI批准的协议。

Apache License, 2.0(Apache-2.0)

Apache Lience允许使用者修改和重新发布代码(以其他协议形式),允许闭源商业发布和销售。 Apache Lience鼓励代码共享和尊重原作者的著作权。 使用Apache Licence协议,需要遵守以下规则:

  • 需要给代码的用户一份Apache Lience;
  • 如果你修改了代码,需要在被修改的文件中说明;
  • 在延伸的代码中(修改或衍生的代码)需要带有原来代码中的协议、商标、专利声明和其他原来作者规定需要包含的说明。
  • 如果再发布的产品中包含了Notice文件,则需要在Notice文件中带有Apache Lience。你可以在Notice中增加自己的许可,但不可以表现为对Apache Lience构成更改。

除了这些条件它还有这些好处:

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

使用apache Licence vesion 2.0协议的开源软件有:Hadoop 、apache httpserver、Spring Framework、MongoDB 。

GPL (GNU General Public License)

它的主要内容为:只要在一个软件中使用(“使用”指类库引用或者修改后的代码) GPL 协议的产品,则该软件产品必须也采用GPL协议,既必须也是开源和免费。这个协议就不太适合商用软件,或者准备使用GPL开源组件的商用项目。基于这个协议的项目,极大的提高了开源软件的数量。 使用GPL协议,需要遵守以下规则:

  • 确保软件自始至终都以开放源代码形式发布,保护开发成果不被窃取用作商业发售。任何一套软 件,只要其中使用了受 GPL 协议保护的第三方软件的源程序,并向非开发人员发布时,软件本身也就自动成为受 GPL 保护并且约束的实体。也就是说,此时它必须开放源代码。
  • GPL 大致就是一个左侧版权(Copyleft,或译为“反版权”、“版权属左”、“版权所无”、“版责”等)的体现。你可以去掉所有原作的版权 信息,只要你保持开源,并且随源代码、二进制版附上 GPL 的许可证就行,让后人可以很明确地得知此软件的授权信息。GPL 精髓就是,只要使软件在完整开源 的情况下,尽可能使使用者得到自由发挥的空间,使软件得到更快更好的发展。
  • 无论软件以何种形式发布,都必须同时附上源代码。例如在 Web 上提供下载,就必须在二进制版本(如果有的话)下载的同一个页面,清楚地提供源代码下载的链接。如果以光盘形式发布,就必须同时附上源文件的光盘。
  • 开发或维护遵循 GPL 协议开发的软件的公司或个人,可以对使用者收取一定的服务费用。但还是一句老话——必须无偿提供软件的完整源代码,不得将源代码与服务做捆绑或任何变相捆绑销售。

目前用的多的是GPLV1,GPLV2。这两个什么区别看后面那张树形图。采用这个协议的开源软件有:Linux、 MySQL。

LGPL (GNU Library or “Lesser” General Public License)

由于GPL太严格,限制了很多商用软件使用GPL组件才推出了这个LGPL。LGPL允许商业软件通过引用类库的方式使用LGPL组件(不直接使用源代码),这样可以不需要开源商业软件的代码。但是如果要修改原始组件的代码,则涉及修改部分的代码和基于原来代码衍生的代码都必须采用LGPL协议。LGPL不适合以LGPL协议为基础的代码进行二次开发的商业软件,但是商用软件可以采用编译后的类库引用就不需要公开源代码了。 采用这个协议的开源软件有: JBoss、 FCKeditor 、 Hibernate。之前extjs就因为从LGPL转换到GPL带来了不少的震动。

BSD开源协议(Berkerley Software Distribution)

目前分为BSD 3-Clause和BSD 2-Clause。顾名思义,3-Clause包含3个条款,2-Clause只有两个。 这个协议相对上面两个协议宽松很多,允许使用者修改和重新发布代码,也允许使用或在BSD代码基础上开发商业软件发布和销售,因此是适用于商业软件的。 =使用者别太高兴,使用时还必须做到满足三个条件(2-Clause则不带第3条):

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

适用BSD协议的开源软件有: nginx、CruiseControl、Redis。 要点:商业软件可以使用,也可以修改使用BSD协议的代码。

MIT (MIT license)

源自麻省理工学院(Massachusetts Institute of Technology, MIT),又称X11协议。MIT与BSD类似,但是比BSD协议更加宽松,是目前最少限制的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。使用MIT的软件项目有:jquery、Node.js。 要点:商业软件可以使用,也可以修改MIT协议的代码,甚至可以出售MIT协议的代码。

MPL (Mozilla Public License 1.1)

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

EPL (Eclipse Public License 1.0)

EPL允许Recipients任意使用、复制、分发、传播、展示、修改以及改后闭源的二次商业发布。

使用EPL协议,需要遵守以下规则:

  • 当一个Contributors将源码的整体或部分再次开源发布的时候,必须继续遵循EPL开源协议来发布,而不能改用其他协议发布.除非你得到了原“源码”Owner 的授权;
  • EPL协议下,你可以将源码不做任何修改来商业发布.但如果你要发布修改后的源码,或者当你再发布的是Object Code的时候,你必须声明它的Source Code是可以获取的,而且要告知获取方法;
  • 当你需要将EPL下的源码作为一部分跟其他私有的源码混和着成为一个Project发布的时候,你可以将整个Project/Product以私人的协议发布,但要声明哪一部分代码是EPL下的,而且声明那部分代码继续遵循EPL;
  • 独立的模块(Separate Module),不需要开源。

要点:商业软件可以使用,也可以修改EPL协议的代码,但要承担代码产生的侵权责任。

协议的区别

下面的树形图很好阐述了当前主流许可协议的区别: opensource1 opensource2 这里是目前github上项目采用的开源协议的比例分布: opensource2

Share this post

Search widget

Timeline

Friendly Links