四大开源协议比较:BSD、Apache、GPL、LGPL
现今存在的开源协议很多，而经过Open Source Initiative组织通过批准的开源协议目前有58种。我们现在常见的开源协议如BSD, GPL, LGPL,MIT等都是OSI批准的协议。如果要开源自己的代码，最好也是选择这些被批准的开源协议。
四种最常用的开源协议及它们的适用范围
一、BSD开源协议（original BSD license、FreeBSD license、Original BSD license）
BSD开源协议是一个给于使用者很大自由的协议。基本上使用者可以”为所欲为”,可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。
但”为所欲为”的前提当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：
如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
BSD 代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。
二、Apache Licence 2.0（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构成更改。
5. Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。
三、LGPL（GNU Lesser General Public License）
LGPL是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。
但是如果修改LGPL协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。
四、GPL（GNU General Public License）
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)制定和发布。
我们很熟悉的Linux就是采用了GPL。GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux，包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。
GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用，修改后的代码或者衍生代码)GPL 协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题，还可以享受免费的优势。
由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议，对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。
其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。
GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品。
在自由软件所使用的各种许可证之中，最为人们注意的也许是通用性公开许可证(General Public License，简称GPL)。
GPL同其它的自由软件许可证一样，许可社会公众享有：运行、复制软件的自由，发行传播软件的自由，获得软件源码的自由，改进软件并将自己作出的改进版本向社会发行传播的自由。
GPL还规定：只要这种修改文本在整体上或者其某个部分来源于遵循GPL的程序，该修改文本的 整体就必须按照GPL流通，不仅该修改文本的源码必须向社会公开，而且对于这种修改文本的流通不准许附加修改者自己作出的限制。因此，一项遵循GPL流通 的程序不能同非自由的软件合并。GPL所表达的这种流通规则称为copyleft，表示与copyright(版权)的概念“相左”。
GPL协议最主要的几个原则：
1、确保软件自始至终都以开放源代码形式发布，保护开发成果不被窃取用作商业发售。任何一套软 件，只要其中使用了受 GPL 协议保护的第三方软件的源程序，并向非开发人员发布时，软件本身也就自动成为受 GPL 保护并且约束的实体。也就是说，此时它必须开放源代码。
2、GPL 大致就是一个左侧版权（Copyleft，或译为“反版权”、“版权属左”、“版权所无”、“版责”等）的体现。你可以去掉所有原作的版权 信息，只要你保持开源，并且随源代码、二进制版附上 GPL 的许可证就行，让后人可以很明确地得知此软件的授权信息。GPL 精髓就是，只要使软件在完整开源 的情况下，尽可能使使用者得到自由发挥的空间，使软件得到更快更好的发展。
3、无论软件以何种形式发布，都必须同时附上源代码。例如在 Web 上提供下载，就必须在二进制版本（如果有的话）下载的同一个页面，清楚地提供源代码下载的链接。如果以光盘形式发布，就必须同时附上源文件的光盘。
4、开发或维护遵循 GPL 协议开发的软件的公司或个人，可以对使用者收取一定的服务费用。但还是一句老话——必须无偿提供软件的完整源代码，不得将源代码与服务做捆绑或任何变相捆绑销售。
· 基于 GPL 的软件允许商业化销售，但不允许封闭源代码。
· 如果您对遵循 GPL 的软件进行任何改动和/或再次开发并予以发布，则您的产品必须继承 GPL 协议，不允许封闭源代码。
· 基于 LGPL 的软件也允许商业化销售，但不允许封闭源代码。
· 如果您对遵循 LGPL 的软件进行任何改动和/或再次开发并予以发布，则您的产品必须继承 LGPL 协议，不允许封闭源代码。但是如果您的程序对遵循 LGPL 的软件进行任何连接、调用而不是包含，则允许封闭源代码。
GPL(General Public License)和LGPL( Lesser General Public License)是GNU的两种License。越来越多的自由软件(Free Software)使用GPL作为其授权声明，如果对GPL一点都不了解，有可能在使用自由软件时违反了GPL的授权。如果是个人或不正规的公司倒也无所 谓，但如果是有规模的公司，恐怕会有被起诉的风险。
在使用Log4cpp时我想到了授权的事情，于是有了兴趣对GPL做一下了解。这是必要的，因为公司也维护了一个验证过的自由软件库，里面包含的自由软件除了功能上是可靠的，另外就是一定可以被私有使用的，否则后果很严重(黎叔很生气!)。
Log4cpp最初的版本使用GPL作为授权声明的，在0.2.1版本以后改用更为宽松的 LGPL。LGPL最初是Library GPL的缩写，后来改称作Lesser GPL，即为更宽松的GPL。当一个自由软件使用GPL声明时，该软件的使用者有权重新发布、修改该软件，并得到该软件的源代码；但只要使用者在其程序中 使用了该自由软件，或者是使用修改后的软件，那么使用者的程序也必须公布其源代码，同时允许别人发布、修改。也就是说，使用GPL声明下的的自由软件开发 出来的新软件也一定是自由软件。
LGPL是GPL的变种，也是GNU为了得到更多的甚至是商用软件开发商的支持而提出的。与 GPL的最大不同是，可以私有使用LGPL授权的自由软件，开发出来的新软件可以是私有的而不需要是自由软件。所以任何公司在使用自由软件之前应该保证在 LGPL或其它GPL变种的授权下。
Richard Stallman关于GPL和LGPL的论述：
为什么你不应该使用LGPL发布你的下一个库
GNU计划在使用库时有两个首要的许可证.一个是GNU LGPL(库GPL);另一个是普通的GNU GPL.选择不同的许可有很大的不同:选择LGPL允许在私有程序中使用该库;选择普通的GPL则只允许在自由软件中使用它.
关于哪一种许可证对指定的库是最好的这一问题实际上是一个策略问题,它取决于实际情况.当前,大多数的GNU库被采用LGPL,这意味着我们只使用着其中的一个策略,而忽略了另一个. 所以现在我们在寻求更多以普通的GPL许可证形式发布的库.
私有软件开发者有金钱上的优势;自由软件开发者需要相互之间利用各自的优势.对一个库采用普通的GPL对自由软件开发者的优势要大于对私有软件开发者: 他们可以使用的库对于私有软件开发者是不可利用的.
使用普通的GPL并不是对于所有的库都有好处.在某些情况下更有理由来使用LGPL.最常见的情况就是当一个自由库的特性可以很容易地被私有软件以其他可替代库来实现.在这种情况下,库不能给与自由软件任何特别的优势,因而最好还是为LGPL发布该库.
这也就是为什么我们为GNU C 库选择LGPL.总之,有很多的其他C库；我们使用GPL发布该库,将迫使私有软件开发者不得不使用其它的库--对他们来说这不成问题,而我们则有了麻烦.
然而,当一个库所提供的功能是非常独特的时候,如GNU Readline, 情况就大不一样了. Readline库可实现输入编辑和记录交互式程序操作,这在别处通常是不可多得. 在GPL下发布它并限制它只能在自由程序中使用, 这我们的社团是一个重要的促进.至少今天某个应用程序之所以是自由软件，只是因为它必需要用到Readline.
如果我们收集一些强大的、私有软件中没有相类似东西的、采用GPL的库,它们将提供一系列有用 的模块用于新的自由软件的构造. 这对于将来的自由软件开发将是一个显著的优势, 一些项目将为了使用这些库而考虑使软件自由化. 大学的项目是易于被影响的；而且今天，随着某些公司开始考虑使软件自由化, 甚至一些商业项目也会由此受到影响.
私有软件开发者试图否认自由竞争的重要性, 他们会拼命说服作者不要将库使用GPL来发布. 例如,他们会呼吁利己主义,信誓旦旦地说如果我们让他们在私有软件产品中使用代码，将有“更多的用户”用到该库. 流行是一种诱惑,它使一个库开发者倾向于相信这种观点：社会首先需要的是促进一种库的流行;.
但是我们不应该听从这种诱惑,因为如果我们联合起来,我们可以做得更好.我们这些自由软件开发 者应该相互支持. 通过发布只能为自由软件使用的库,我们可以互相帮助，使彼此的自由软件包优于其它的私有替代品. 整个自由软件运动将会有更多的机会,因为自由软件作为一个整体将会在竞争中表现更佳.
因为"LGPL(Library GPL)"的称呼传达了关于这一问题的错误观点,我们计划将称呼改为"次级GPL(Lesser GPL)".事实上要更换名称要花一定的时间,但你不必再等--你可以现在就发布应用GPL许可证的库.
