开源协议许可证浅析

如今开源的软件已经越来越被广泛使用，各种专利纠纷也越来越多。工作上要求对开源协议的理解也很迫切，做技术架构是每一个技术人员最渴望的职责，但要做好初级的技术架构工作首先要对各种各样的开源协议有深入了解，知道什么开源软件是工作在什么协议之下，对自己的产品有什么影响。这篇博文将讲解开源协议的相关知识（将不定期更新）

首先要弄懂一些基本概念：

 

1  什么是许可协议？

 

 

什么是许可，当你为你的产品签发许可，你是在出让自己的权利，不过，你仍然拥有版权和专利（如果申请了的话），许可的目的是，向使用你产品的人提供一定的权限。

不管产品是免费向公众分发，还是出售，制定一份许可协议非常有用，否则，对于前者，你相当于放弃了自己所有的权利，任何人都没有义务表明你的原始作者身份，对于后者，你将不得不花费比开发更多的精力用来逐个处理用户的授权问题。

而开源技术许可协议使这些事情变得简单，开发者很容易向一个项目贡献自己的代码，它还可以保护你原始作者的身份，使你至少获得认可，开源许可协议还可以阻止其它人将某个产品据为己有。

 

2.  Contributors 和 Recipients， Source Code 和 Object Code， Derivative Module 和 Separate Module

      Contributors 指的是对某个开源软件或项目提供了代码(包括最初的或者修改过的)发布的人或者实体(团队、公司、组织等),Contributors 按照参与某个软件开源的时间先后,可以分为 an initial Contributor 和 subsequent Contributors .

　　Recipients指的是开源软件或项目的获取者,显然,subsequent Contributors 也属于 Recipients之列.

     Source Code 指的是各种语言写成的源代码,通过Source Code,结合文档, 可以了解到整个软件的体系结构及具体到某个功能函数的实现方法等.
　　Object Code 指的是Source Code 经过编译之后,生成的类似于“类库”一样的,提供各种接口供他人使用的目标码,按我的理解,它就是像常见的DLL、ActiveX、OCX控件性质的东西.(不知道这样理解对不对)
　　分清楚这两个概念的目的在于,有些开源,只发布Object Code ,当然,大多数发布的是Source Code.很多协议也对 “你发布的是哪种Code的时候应该怎样”,有着明确的约束.

      Derivative Module 指的是,依托或包含“最初的”或者“从别人处获取的”开源代码而产生的代码,是原“源代码”的增强(不等于增加)、改善和延续的模块,意为“衍生模块”.

　　Separate Module 指的是,参考或借助原“源代码”,开发出的独立的,不包含、不依赖于原“源代码模块”,意为“独立的模块”.理解这两个概念的目的在于,很多协议对涉及到商业发布的时候,会有哪些是衍生的,哪些是独立的,有着明确的商业发布规定.

　　现今存在的开源协议很多,而经过Open Source Initiative组织通过批准的开源协议目前有58种.我们在常见的开源协议如BSD, GPL, LGPL,MIT等都是OSI批准的协议.如果要开源自己的代码,最好也是选择这些被批准的开源协议.
　　这里我们来看四种最常用的开源协议及它们的适用范围,供那些准备开源或者使用开源产品的开发人员/厂家参考.

3. 常用开源协议

GPL(GNU General Public License)

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

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

GPL协议最主要的几个原则：

 

1、确保软件自始至终都以开放源代码形式发布，保护开发成果不被窃取用作商业发售。任何一套软 件，只要其中使用了受 GPL 协议保护的第三方软件的源程序，并向非开发人员发布时，软件本身也就自动成为受 GPL 保护并且约束的实体。也就是说，此时它必须开放源代码。

2、GPL 大致就是一个左侧版权（Copyleft，或译为“反版权”、“版权属左”、“版权所无”、“版责”等）的体现。你可以去掉所有原作的版权 信息，只要你保持开源，并且随源代码、二进制版附上 GPL 的许可证就行，让后人可以很明确地得知此软件的授权信息。GPL 精髓就是，只要使软件在完整开源 的情况下，尽可能使使用者得到自由发挥的空间，使软件得到更快更好的发展。

3、无论软件以何种形式发布，都必须同时附上源代码。例如在 Web 上提供下载，就必须在二进制版本（如果有的话）下载的同一个页面，清楚地提供源代码下载的链接。如果以光盘形式发布，就必须同时附上源文件的光盘。

4、开发或维护遵循 GPL 协议开发的软件的公司或个人，可以对使用者收取一定的服务费用。但还是一句老话——必须无偿提供软件的完整源代码，不得将源代码与服务做捆绑或任何变相捆绑销售。

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

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

小结： 商业软件不能使用GPL协议的代码。

 

LGPL(GNU Lesser General Public License)

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

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

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

小结： 商业软件可以使用，但不能修改LGPL协议的代码。

AGPL(GNU Affero General Public License)

AGPL是GPL的一个补充, 在GPL的基础上加了一些限制。

 

AGPL这个协议的制定是为了避免一个GPL/LGPL协议中的漏洞，称之为 Web Service Loopwhole。
这主要是由于 GPL是针对传统的软件分发模式的商业模式(以微软为代表), 如果你使用的GPL的代码作为
基础完成你自己的软件，如果你要分发你的软件，你的软件必须也是GPL的。随着以Google为代表的软件
作为服务的互联网公司的兴起，它们的“不分发软件，为客户提供网络服务”的商业模式就不受GPL协议的
约束，所以Google公司在构筑他的搜索引擎的时候可以随心所欲的拿现有的GPL协议的开源代码，无需开
源他的修改成果。AGPL协议在GPL协议的基础上加上了这个约束。

小结： 商业软件不能使用AGPL协议的代码。

 

BSD(original BSD license、FreeBSD license、Original BSD license)

 

BSD开源协议是一个给予使用者很大自由的协议.基本上使用者可以“为所欲为”可以自由的使用,修改源代码,也可以将修改后的代码作为开源或者专有软件再发布.但“为所欲为”的前提当你发布使用了BSD协议的代码,或则以BSD协议代码为基础做二次开发自己的产品时,需要满足三个条件:

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

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

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

　　其实这几个规则约定的目的也只是达到一个目的:是他人的东西,别人以BSD开源了,你就不能不做任何声明而占为己有,更不能用他人的名义来做商业推广.你只对你自己的东西拥有绝对控制权.

　　举个例子,你用开源代码(A)修改或做其他增添之后,产生了产品B,这时候,你对B的控制由你自己决定,你可以用任何协议再开源,也可以闭源商业发布.但,因为如果B中包含了A或A的一部分(一点都不包含就不叫修改了),那你在B产品的版权声明中,必须有提到你有使用到 A ,并且附带上 A 的开源协议.而且不能做商业推广的时候将B 冠以原开源作者的名义以促进商业推广.

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

小结:商业软件可以使用，也可以修改使用BSD协议的代码。

 

 

MIT

 

　　MIT 协议可能是几大开源协议中最宽松的一个，核心条款是：

　　该软件及其相关文档对所有人免费，可以任意处置，包括使用，复制，修改，合并，发表，分发，再授权，或者销售。唯一的限制是，软件中必须包含上述版权和许可提示。

　　这意味着：

　　你可以自由使用，复制，修改，可以用于自己的项目。可以免费分发或用来盈利。唯一的限制是必须包含许可声明。MIT 协议是所有开源许可中最宽松的一个，除了必须包含许可声明外，再无任何限制。

小结： 商业软件可以使用，也可以修改使用MIT协议的代码。

 

ASL(Apache License， Version 2.0、Apache License， Version
1.1、Apache License， Version 1.0)

 

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

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

　　2. 如果你修改了代码,需要再被修改的文件中说明.

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

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

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

 

MPL开源协议(The Mozilla Public License)

 

 

MPL是The Mozilla Public License的简写，是1998年初Netscape的 Mozilla小组为其开源软件项目设计的软件许可证。MPL许可证出现的最重要原因就是，Netscape公司认为GPL许可证没有很好地平衡开发者对 源代码的需求和他们利用源代码获得的利益。同著名的GPL许可证和BSD许可证相比，MPL在许多权利与义务的约定方面与它们相同（因为都是符合OSIA 认定的开源软件许可证）。但是，相比而言MPL还有以下几个显著的不同之处:

MPL虽然要求对于经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来，以保证其他人可以在MPL的条款下共享源代码。但是，在MPL 许可证中对“发布”的定义是“以源代码方式发布的文件”，这就意味着MPL允许一个企业在自己已有的源代码库上加一个接口，除了接口程序的源代码以MPL 许可证的形式对外许可外，源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。这些，就为借鉴别人的源代码用做自己商业软件开发的行为留了一个 豁口。 
MPL许可证第三条第7款中允许被许可人将经过MPL许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序。 
对软件专利的态度，MPL许可证不像GPL许可证那样明确表示反对软件专利，但是却明确要求源代码的提供者不能提供已经受专利保护的源代码（除非他本人是 专利权人，并书面向公众免费许可这些源代码），也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。 
对源代码的定义 
而在MPL（1.1版本）许可证中，对源代码的定义是:“源代码指的是对作品进行修改最优先择 取的形式，它包括:所有模块的所有源程序，加上有关的接口的定义，加上控制可执行作品的安装和编译的‘原本’（原文为‘Script’），或者不是与初始 源代码显著不同的源代码就是被源代码贡献者选择的从公共领域可以得到的程序代码。” 
MPL许可证第3条有专门的一款是关于对源代码修改进行描述的规定，就是要求所有再发布者都得有一个专门的文件就对源代码程序修改的时间和修改的方式有描述。

小结：商业软件可以使用，也可以修改MPL协议的代码，但修改后的代码版权归软件的发起者。

CDDL（Common Development and Distribution License）
CDDL（Common Development and Distribution License，通用开发与销售许可）开源协议，是MPL（Mozilla Public License）的扩展协议，它允许公共版权使用，无专利费，并提供专利保护，可集成于商业软件中，允许自行发布许可。
小结：商业软件可以使用，也可以修改CDDL协议的代码。

 

CPL(Common Public Liecense) vesion 1.0

　　CPL是IBM 提出的并通过了OSI(Open Source Initiative)批准的开源协议.主要用于一些IBM或跟IBM相关的开源软件/项目中.如很著名的Java开发环境 Eclipse 、RIA开发平台Open Laszlo等.

　　CPL也是一项对商业应用友好的协议.它允许 Recipients 对源码进行任意的使用、复制、分发、传播、展示、修改以及改后做闭源的二次商业发布,这点跟 BSD 很类似,也属于自由度比较高的开源协议.但是,需要遵循:

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

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

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

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

小结：商业软件可以使用，也可以修改Common协议的代码，但要承担代码产生的侵权责任。

总结： 

 

按照使用条件的不同，开源软件许可证可以分为三类（严苛程度递减）

　　1． 使用该开源软件的代码再散布（redistribute）时，源码也必须以相同许可证公开。

　　代表许可类型：GPL， AGPL

　　2． 使用该开源软件的代码并且对开源代码有所修改后再散布时，源码必须以相同许可证公开。

　　代表许可类型：LGPL， CPL，CDDL， CPL，MPL等

　　3． 使用该开源软件的代码（包括修改）再散布（redistribute）时，没有特殊限制，只需要明记许可。

　　代表许可类型：ASL， BSD，MIT等

 -----------------------------------------------------------------

自从自由软件之父理查德·斯托曼（Richard Stallman）发起的GNU(GNU's not uinix:说实在的，我也不知道他想表达什么) 运动，开源运动如火如荼的发展起来，现在开源已经成为常态了。至少开发人员应该或多或少的知道一点，但是基本上所有的开发都应该使用过开源产品，例如我们最常用的apache。

由于理查德·斯托曼的认知，认为软件应该就是应该自由和开放的，开发人员应该很容易获得源代码以及进行改动，再把改动之后的源代码发布出来，就这么简单的一个想法，在加上Linus Torvalds 等牛逼黑客的加入，GNU影响力越来越大。GNU发布了GPL协议，这个协议和当初创世人的理念有关。

 

GPL(General Public License)协议主要特点：

• 所有的源代码都是公开的，可以自由使用。但是是有版权的
• 如果对GPL的开源代码进行修改，就必须把修改之后的代码进行开源
• 如果引用了GPL的代码库，就必须开源你引用部分的代码。相当于你的代码中如果有一行代码引入了GPL协议的库函数，就必须把整个代码开源。就是所说的传染性
• 如果使用的是GPL产品，没有上面的限制。这个说实在的，我觉得真不好界定。例如java中的openjdk，如果你只是使用他的编译器编译你的java程序，是没有必要开源你的java程序
• GPL是free（自由的），但是是可以收费的。我们经常认为开源的就是免费的，这个是不对的。

从上面的限制来看，GPL开源协议还是有很大的传染性的。如果一个商业公司引用了开源代码或者库函数，就必须开源引用它的整个代码。有一些公司不愿意开源咋办，就不能用了。毕竟对于商业公司来说，代码是我的资产，我没有必要开源，所以这个协议对商业公司不是很友好

LGPL（GNU Lesser General Public License):是GPL的变种，这个是宽松的GPL，对于商业公司比较友好，如果使用了LGPL的库，可以不开源的你的代码。与GPL的最大不同是，可以私有使用LGPL授权的自由软件，开发出来的新软件可以是私有的而不需要是自由软件。所以任何公司在使用自由软件之前应该保证在LGPL或其它GPL变种的授权下。

 

BSD(FreeBSD Copyright Information)：这个算是宽松的协议了，你可以使用和修改它的源代码，注明使用了他就可以了，你自己的代码是可以私有的。只要别侵权就可以，比如直接copy了源代码，说是你自己写的，这样就不对了。

 

Apache Licene：这个和BSD差不多，但是要注意几点，如果修改了源代码，要注明修改了什么。开源代码的商标，专利，所有权都要保留的，不能说修改了开源apache 协议的开源代码，就直接把代码的作者写成你，这样是不对的。发布产品的时候，对于自己修改的apache 开源代码，不能够变成其他的开源协议。

 

MIT：这个说实在的，我个人见的比较少，这个算是最自由的协议了，和BSD一样，但是修改了MIT源码，可以加入自己的授权。 

常用的也就上面几种

 

下面来看看 android的问题

由于android 使用linux的代码库，按照道理来说，android必须以GPL的协议进行开源，但是考虑到GPL对商业上非常不友好，一旦有公司想优化andorid，对android进行定制，也必须开源这一部分代码。但是google怎么做的了，这个是另外一个篇文章分析里面的一部分

“Linux kernel 的版权是 GPL。

这下问题来了：如果你是硬件厂商，希望你的硬件能在 Linux kernel 下运作，那么就必须要有驱动程序。如果驱动程序的程序代码公开，等于硬件规格也公开的差不多了。许多厂商不愿意这么做，所以就提供编好的驱动程序，但不提供原始码。

Android 的重点就是商业应用，Google采用了一些手法来绕过这问题。他们把驱动程序移到 "userspace"，也就是说，把驱动程序变成在 Linux kernel 上头跑，而不是一起跑的东西，这样就可以避过GPL。然后，在 kernel 这边开个小门，让本来不能直接控制到硬件的 "userspace" 程序也可以碰得到，这样只要把"开个小门"的程序代码公布就行啦。”

所以阿里云OS也应该避免不了，至少要公开这个后门部门的源代码，所以按照道理来说，阿里云要公开这一部分代码，貌似没有公开，好奇它是怎么绕开的。

 

下面是一些常用的开源产品的授权协议：

tomcat:Apache Licene

android:Apache Licene

spring:Apache Licene

openjdk:GPL

Mysql:GPL

Jquery:MIT（貌似是最近改的）

JBoss:LGPL

Nginx:BSD

 

http://www.cnblogs.com/aigongsi/archive/2012/09/25/2701919.html

转自:http://blog.csdn.net/kindazrael/article/details/7055275