Chinaunix首页 | 论坛 | 博客
  • 博客访问: 160988
  • 博文数量: 34
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 378
  • 用 户 组: 普通用户
  • 注册时间: 2017-01-17 11:19
个人简介

人的一生犹如负重致远,不可急躁。 以不自由为常事,则不觉不足。 心生欲望时,应回顾贫困之日。 心怀宽恕,视怒如敌,则能无视长久。 只知胜而不知敗,必害其身。 责人不如责己,不及胜于过之。

文章分类

全部博文(34)

文章存档

2018年(2)

2017年(32)

我的朋友

分类: IT职场

2017-03-01 17:33:06

开源协议

1  主流的开源协议

开源协议,如今的开源协议达到60多种,其中主流的包括以下这些BSD、AL2.0、GPL、LGPL、MPL、MIT、EPL等协议。

2  开源协议介绍

       下面对BSD、AL2.0、GPL、LGPL、MPL、MIT、EPL等开源协议简单介绍。

2.1  BSD开源协议

       BSD是Berkly Software Distribution的简称,BSD许可证原先是用在加州大学柏克利分校发表的各个4.4BSD/4.4BSD-Lite版本上面的,后来也就逐渐沿用下来。1979年加州大学伯克利分校发布了BSD Unix,被称为开放源代码的先驱,BSD许可证就是随着BSD Unix发展起来的。BSD许可证被Apache和BSD操作系统等开源软件所采纳。

BSD开源协议主要包括FreeBSD license、Original BSD license,是一个给于使用者很大自由的协议。可以自由的使用,修改源代码,也可以将修改后的代码作为开源或者专有软件再发布。

使用BSD开源协议必须满足下面条件:

1、  如果再发布的产品中包含源代码,则在源代码中必须带有原来代码中的BSD协议。

2、  如果再发布的只是二进制类库/软件,则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。

3、  不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。

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

开源软件有: nginx、CruiseControl、Redis。

2.2  AL2.0开源协议

       AL2.0是Apache Licence 2.0简写,AL2.0开源协议主要包括Apache License, Version 2.0 、Apache License, Version 1.1 、Apache License, Version 1.0,Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似,同样鼓励代码共享和尊重原作者的著作权,同样允许代码修改,可以作为(开源或商业软件)再发布。

使用AL2.0开源协议必须满足下面条件:

1、  需要给代码的用户一份Apache Licence。

2、  如果你修改了代码,需要在被修改的文件中说明。

3、  在延伸的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的协议,商标,专利声明和其他原来作者规定需要包含的说明。

4、  如果再发布的产品中包含一个Notice文件,则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可,但不可以表现为对Apache Licence构成更改。

Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。

AL2.0协议原文:

开源软件有:Hadoop 、apache httpserver、Spring Framework、MongoDB。

2.3  GPL

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

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

由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议,商业软件或者对代码有保密要求的部门就不适合集成/采用GPL协议的开源代码作为类库和二次开发的基础。其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。

GPL是最严格和最彻底的开源协议。使用该协议最重要的代表就是Linux操作系统了,当然也包括一众跑在Linux上的软件,像著名的图像处理软件GIMP等也采用了GPL协议。

       开源软件有:Linux、Mysql。

2.4  LGPL

       LGPL是GNU Library General Public License简称,后改为GNU Lesser General Public License,可以理解为“函数库公共许可证”或者“较宽松公共许可证”。由于GPL太严格,限制了很多商用软件使用GPL组件才推出了这个LGPL。

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

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

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

       开源软件有:JBoss、FCKeditor、Hibernate。

2.5  MPL

       MPL是The Mozilla Public License,是1998年初Netscape的Mozilla小组为其开源软件项目设计的软件许可证。MPL许可证出现的最重要原因就是,Netscape公司认为GPL许可证没有很好地平衡开发者对源代码的需求和他们利用源代码获得的利益。同著名的GPL许可证和BSD许可证相比,MPL在许多权利与义务的约定方面与它们相同(因为都是符合OSIA 认定的开源软件许可证)。

       MPL还有以下几个显著的不同之处:

1、  MPL虽然要求对于经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来,以保证其他人可以在MPL的条款下共享源代码。但是,在MPL许可证中对“发布”的定义是“以源代码方式发布的文件”,这就意味着MPL允许一个企业在自己已有的源代码库上加一个接口,除了接口程序的源代码以MPL许可证的形式对外许可外,源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。这些,就为借鉴别人的源代码用做自己商业软件开发的行为留了一个豁口。

2、  MPL许可证第三条第7款中允许被许可人将经过MPL许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序。

3、  对软件专利的态度,MPL许可证不像GPL许可证那样明确表示反对软件专利,但是却明确要求源代码的提供者不能提供已经受专利保护的源代码(除非他本人是专利权人,并书面向公众免费许可这些源代码),也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。

开源软件有:Mozilla基金会下面的浏览器Firefox、FTP工具Firezilla、邮件处理软件Thunderbird、大名鼎鼎的BUG管理系统Buglzilla等。

2.6  MIT

       MIT是麻省理工学院(Massachusetts Institute of Technology,MIT)的英文简称,MIT是和BSD一样宽范的许可协议,作者只想保留版权,而无任何其他了限制。也就是说,你必须在你的发行版里包含原许可协议的声明,无论你是以二进制发布的还是以源代码发布的。

       被授权人的权利和义务:

1、  被授权人有权利使用、复制、修改、合并、出版发行、散布、再授权及贩售软件及软件的副本。

2、  被授权人可根据程序的需要修改授权条款为适当的内容。

3、  在软件和软件的所有副本中都必须包含版权声明和许可声明。

开源软件有:ssh连接软件PuTTY、X Windows System (X11)、Expat, Mono开发平台库,Ruby on Rails, Lua 5.0 onwards等

2.7  EPL

       EPL是Eclipse Public License 1.0简写,使用EPL协议需要遵守以下规则:

1、  当一个Contributors将源码的整体或部分再次开源发布的时候,必须继续遵循EPL开源协议来发布,而不能改用其他协议发布。除非你得到了“源码”Owner的授权。

2、  EPL协议下,你可以将源码不做任何修改来商业发布。但如果你要发布修改后的源码,或者当你再发布的是Object Code的时候,你必须声明它的Source Code是可以获取的,而且要告知获取方法。

3、  当你需要将EPL下的源码作为一部分跟其他私有的源码混和着成为一个Project发布的时候,你可以将整个Project/Product以私人的协议发布,但要声明哪一部分代码是EPL下的,而且声明那部分代码继续遵循EPL。

4、  独立的模块(Separate Module),不需要开源。

5、  EPL允许Recipients任意使用、复制、分发、传播、展示、修改以及改后闭源的二次商业发布。商业软件可以使用,也可以修改EPL协议的代码,但要承担代码产生的侵权责任。


3  开源协议如何选择

可以根据下图帮助你选择合适的开源协议:




4  开源协议的意义

       开源软件现在已经成为整个互联网的基础。包括Linux操作系统、主流Web服务器、常用的浏览器引擎、网络传输加密、大数据挖掘等都离不开开源。而开源运动可以持续下去的保证就是这些开源协议。虽然这些协议看上去只是一纸文书,并没有太多强制力。但正是这些看上去很奇怪的协议促进了整个软件行业的发展,使得很多开源软件成为最重的软件,而开源也成为最重要的一种开发方式。


阅读(2088) | 评论(0) | 转发(0) |
0

上一篇:Java线程池

下一篇:Java单例模式

给主人留下些什么吧!~~