开源Liecense介绍

开源在今天的软件业已经很普遍，但开源是否意味着使用者可以对开源后的代码为所欲为呢？答案是否定的。开源运动同样有自己的游戏规则和道德准则。不遵行这些规则不但损害开源运动的健康发展，也会对违规者造成名誉和市场上的损失，更可能陷入法律纠纷和赔偿。

现今存在的开源协议很多，而经过 Open Source Initiative 组织通过批准的开源协议目前有 58 种。我们在常见的开源协议如 BSD, GPL, LGPL,MIT 等都是 OSI 批准的协议。如果要开源自己的代码，最好也是选择这些被批准的开源协议。

  这里我们来看四种最常用的开源协议及它们的适用范围，供那些准备开源或者使用开源产品的开发人员 / 厂家参考。      

 

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

BSD 开源协议  

 

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

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

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

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

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

 

Apache Licence 2.0

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

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

2．  如果你修改了代码，需要再被修改的文件中说明。

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

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

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

 

GPL

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

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

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

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

LGPL

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

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

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

 

（ 1 ） Contributors   和  Recipients
Contributors     指的是对某个开源软件或项目提供了代码（包括最初的或者修改过的）发布的人或者实体（团队、公司、组织等）， Contributors   按照参与某个软件开源的时间先后，可以分为 an  initial  Contributor   和  subsequent  Contributors   。
Recipients 指的是开源软件或项目的获取者，显然， subsequent  Contributors   也属于  Recipients 之列。

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

（ 3 ） Derivative  Module   和  Separate  Module
Derivative  Module   指的是，依托或包含 “ 最初的 ” 或者 “ 从别人处获取的 ” 开源代码而产生的代码，是原 “ 源代码 ” 的增强（不等于增加）、改善和延续的模块，意为 “ 衍生模块 ” 。
Separate  Module   指的是，参考或借助原 “ 源代码 ” ，开发出的独立的，不包含、不依赖于原 “ 源代码模块 ” ，意为 “ 独立的模块 ” 。
理解这两个概念的目的在于，很多协议对涉及到商业发布的时候，会有哪些是衍生的，哪些是独立的，有着明确的商业发布规定。
       接下来，说说常见的几种协议吧。其实上面我给出的几篇文章的链接里面对一些常见的开源协议已经有比较清晰的描述了，我这里也只是加人了个人的一些理解，希望对接触得少的人有一定的帮助吧。
GPL （ Gun  General  Public  License ）  vesion  2.0    1991
       最常见的开源协议，使用它作为授权协议的有大名鼎鼎的  Linux   。 GPL 最显著的两个特点就是网上称为的 “ 病毒性传播 ” 和 “ 不允许闭源的商业发布 ” 。
        所谓的 “ 病毒性传播 ” ，指的是， GPL 规定，所有从 GPL 协议授权的源码衍生出来的（即上面提到的 DerivativeModule ），或者要跟 GPL 授权的源码混着用的 Project ，都要遵循 GPL 协议，就像病毒一样，粘上了关系，就 “ 中毒 ” 了。 GPL 这样规定的目的是，保证在 GPL 协议保护下的产品，不会再受到其他协议或者授权的约束。即让跟 GPL 有关系的源码都能免费获取。举个例子，如果你的改进的 Linux 中使用了 GPL 授权下的开源模块（也必须使用，你不可能自己重新去做个内核吧，如果做出来了，你也没必要叫 Linux 了。），那么你整个 Linux 产品也必须遵循  GPL 协议去开源，不能以其他方式去开源发布，更不允许闭源发布。这样一来，就不会出现这样一个 Linux －－这个功能是 GPL 协议授权的，可以免费获取源码，而另外一个功能是其他协议下的，拿不到源码。这点规定对使用或者研究该产品的人来说，是一个极大的便利。
        而 “ 不允许闭源商业发布 ” 指的是，在  GPL 授权下，你的软件产品可以商业发布，拿去卖钱，但是在这同时，你也必须将该产品的源码以 GPL 协议方式开源发布出去，供他人免费获取。也许有人会迷惑，拿去卖，又同时开源，那谁来买阿？这个产品怎么赚钱呢？？这就涉及到开源产品的商业模式的问题了，想了解相关一些信息的话，可以看看以上我给出链接的一些文章。至于后面，可能会写一篇关于开源项目的商业模式的随笔。
      GPL 协议下的商业发布的一个关键点就像  Java   视线论坛的  Robbin 所说的， GPL 是针对软件源代码的版权，而不是针对软件编译后二进制版本的版权。你有权免费获得软件的源代码，但是你没有权力免费获得软件的二进制发行版本。 GPL 对软件发行版本唯一的限制就是：你的发行版本必须把完整的源代码一同提供。

BSD （ Berkeley  Software  Distribution ）
       跟 GPL 有很大的不同， BSD 协议是给予人很大的自由的一种开源协议。其最大的特点是， Recipients   几乎可以对源码 “ 为所欲为 ” ，可以自由地修改，自由地使用，修改后再以其他方式再发布（商业或者开源）。但，你做这些事情的时候，还是得遵循以下规则：
       1 ．   如果再发布的产品中包含原 “ 源代码 ” ，则在原 “ 源代码 ” 中必须带有原来代码中的 BSD 协议。  
       2 ．   如果再发布的只是二进制类库 / 软件（ Object  Code  /  Product ），则需要在类库 / 软件的文档和版权声明中包含原来代码中的 BSD 协议。  
       3 ．   不可以用开源代码的作者 / 机构名字和原来产品的名字做市场推广。  
        其实这几个规则约定的目的也只是达到一个目的：是他人的东西，别人以 BSD 开源了，你就不能不做任何声明而占为己有，更不能用他人的名义来做商业推广。你只对你自己的东西拥有绝对控制权。
        举个例子，你用开源代码（ A ）修改或做其他增添之后，产生了产品 B ，这时候，你对 B 的控制由你自己决定，你可以用任何协议再开源，也可以闭源商业发布。但，因为如果 B 中包含了 A 或 A 的一部分（一点都不包含就不叫修改了），那你在 B 产品的版权声明中，必须有提到你有使用到 A   ，并且附带上  A   的开源协议。而且不能做商业推广的时候   将  B   冠以   原开源作者的名义以促进商业推广。
      BSD 代码鼓励代码共享，但需要尊重代码作者的著作权。 BSD 由于允许使用者修改和重新发布代码，也允许使用或在 BSD 代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选 BSD 协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。  

Apache  Licence    vesion  2.0  
Apache  Licence   是著名的非盈利开源组织  Apache   采用的协议。该协议和 BSD 类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。需要满足的条件也和 BSD 类似：（配备英文原文，方便更准确理解）  
1 ．   需要给  Recipients   一份 Apache  Licence  
      （ You  must  give  any  other  recipients  of  the  Work  or  DerivativeWorks  a  copy  of  this  License ）
2 ．   如果你修改了代码，需要在被修改的文件中进行说明。
    （ You  must  cause  any  modified  files  to  carry  prominent  noticesstating  that  You  changed  the  files ）  
3 ．   在 Derivative  Module 中（修改和包含源代码而衍生的代码）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。  
    （ You  must  retain,  in  the  Source  form  of  any  DerivativeWorks  that  You  distribute,    all  copyright,  patent,  trademark,  and  attribution  noticesfrom  the  Source  form  of  the  Work,    excluding  those  notices  that  do  not  pertain  to  anypart  of  the  Derivative  Works ）
4 ．   如果再发布的产品中包含一个 Notice 文件，则在 Notice 文件中需要带有 Apache  Licence 。你可以在 Notice 中增加自己的许可，但不可以表现为对 ApacheLicence 构成更改。
   Apache  Licence 也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布 / 销售。  

    LGPL  
     LGPL   是 GPL 的一个为主要为类库使用设计的开源协议。和 GPL 要求任何使用 / 修改 / 衍生之 GPL 类库的的软件必须采用 GPL 协议不同。 LGPL 允许商业软件通过类库引用 (link) 方式使用 LGPL 类库而不需要开源商业软件的代码。这使得采用 LGPL 协议的开源代码可以被商业软件作为类库引用并发布和销售。  
      但是如果修改 LGPL 协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用 LGPL 协议。因此 LGPL 协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以 LGPL 协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。

    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 协议下，你可以将源码不做任何修改来商业发布。但如果你要将修改后的源码其开源，而且当你再发布的是 ObjectCode   的时候，你必须声明   它的 Source  Code   是可以获取的，而且要告知获取方法
     3. 当你需要将  CPL   下的源码作为一部分跟其他私有的源码混和着成为一个  Project 发布的时候，你可以将整个 Project/Product   以私人的协议发布，但要声明哪一部分代码是 CPL 下的，而且声明那部分代码继续遵循 CPL 。

   4. 独立的模块（ Separate  Module ），不需要开源