开源协议

一．GNU 和 Linux 的关系

GNU项目(GNU Project)开始于1984年，是由自由软件基金（Free Software Foundation，FSF）资助的一个项目，目标是开发一个自由的、UNIX类型的操作系统，称为GNU系统。GNU是“GNUs Not UNIX”的首字母缩写，目前使用Linux内核的各种GNU操作系统应用非常广泛。

GNU项目已经开发了许多高质量的编程工具，包括emacs编辑器、GNU C 和C++编译器（GCC和G++），这些编译器可以在任何计算机系统上运行。所有的GNU软件和派生工作均遵循GNU通用公共许可证（GPL）的规定。Linux的开发使用了许多GNU工具。Linux系统上用于实现POSIX.2标准的工具几乎都是GNU项目开发的，Linux系统的许多内容也是GNU项目开发的，其中包括：

符合POSIX标准的操作系统shell和外围工具。

C语言编译器和其他软件开发工具及函数库。

X Window窗口系统。

各种应用软件，包括字处理软件、图像处理软件等。

各种Internet软件，包括FTP服务器、WWW服务器等。

关系数据库管理系统等。

2. GPL

GPL(General Public License，通用公共许可证)是一种软件许可证，其主要目标是保证软件对所有的用户来说是自由的，和软件是否免费无关。GPL通过如下途径实现这一目标：

它要求软件以源代码的形式发布，并规定任何用户能够以源代码的形式将软件复制或发布给别的用户。

它提醒每个用户，对于该软件不提供任何形式的担保。

如果用户的软件使用了受GPL保护的任何软件的一部分，那么该软件就继承了GPL软件，并因此而成为GPL软件，也就是说必须随应用程序一起发布源代码。

GPL不排斥对自由软件进行商业性质的包装和发行，也不限制在自由软件的基础上打包发行其他非自由软件。

遵照GPL的软件并不是可以任意传播的，这些软件通常都有正式的版权。GPL在发布软件或者复制软件时声明限制条件。但是，从用户的角度考虑，这些根本不能算是限制条件，相反用户只会从中受益，因为用户可以确保获得源代码。

尽管Linux内核也属于GPL范畴，但GPL并不适用于通过系统调用而使用内核服务的应用程序，通常把这种应用程序看做是内核的正常使用。

如果准备以二进制的形式发布应用软件（像大多数商业软件那样），则必须确保自己的程序未使用GPL保护的任何软件。当然，如果软件通过函数调用使用了别的软件，则不受这一限制。目前，很多程序库受另一种GNU公共许可证（即LGPL）的保护，LGPL将在下面介绍。

Linux系统中关于GPL的声明保存在各目录下的名为COPYING的文件里，打开文件可查看GPL的内容。

3. LGPL

GNU LGPL（Library General Public License，程序库公共许可证）是一种关于函数库使用的许可证。LGPL允许用户在自己的应用程序中使用其他程序库，即使不公开自己程序的源代码也可以，但必须确保能够获得所使用的程序库的源代码，而且，LGPL还允许用户对这些程序库进行修改。

在Linux系统中，LGPL的内容保存在名为COPYING.LIB的文件中。如果安装了Linux内核的源程序，则在任意一个源程序目录下都可以找到COPYING.LIB文件的一个拷贝。

大多数Linux程序库，包括C语言的程序库（libc.a），都属于LGPL范畴。因此，如果在Linux环境下，使用GCC编译器建立自己的应用程序，程序所链接的多数程序库都是受LGPL保护的。如果想以二进制的形式发布应用软件，则必须要遵循LGPL的有关规定。

遵循LGPL的一种方法是，随应用程序一起发布目标代码以及可以将这些目标代码和受LGPL保护的程序库链接起来的makefile文件。在使用这类应用程序时，用户必须通过其他途径获得所需的程序库，然后根据makefile文件生成最终的可执行程序。

遵循LGPL的比较好的另一种方法是使用动态链接。使用动态链接时，应用程序在运行时调用函数库中的函数。应用程序本身和函数库是不同的实体，因而应用程序只需遵循动态链接库的使用方式，就可以像使用自己的函数一样使用函数库中的函数，而且，当函数库更新后，还可以直接使用更新后的函数库。在使用这类应用程序时，用户必须首先获得所需的程序库的动态链接库（如libc.a），然后直接运行应用程序即可。

必须注意，某些库和应用程序属于GPL而不是LGPL的范畴。例如，常用的GNU dbm（即 gdbm）数据库类的程序库就是非常著名的GPL库；GNU bison 分析器生成程序是另一个实用的GPL工具，因此，如果使用bison生成代码，所得的代码也适用于GPL。

在GPL范畴之外，也有gdbm 和 GNU bison 的相应替代物。例如，对于数据库类的程序库，可以使用Berkeley数据库db来替代gdbm；对于分析器生成器，可以使用yacc来替代bison。

查了一下这两者的定义，好像GPL很难被商业软件所应用，它要求调用它的库的code也得GPL，全部开放，并且一同发布，不能直接link。以后使用开源的东西得小心了。

而LGPL则允许link，只需要有所声明，同时还允许customer更改第三方的库，重新link。自由度比较大。

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

　　我们很熟悉的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都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品。

BSD开源协议

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

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

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

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

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

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

Apache Licence 2.0

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

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

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

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

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

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

MIT

MIT是和BSD一样宽范的许可协议,作者只想保留版权,而无任何其他了限制.也就是说,你必须在你的发行版里包含原许可协议的声明,无论你是以二进制发布的还是以源代码发布的.

二：如何选择开源协议

近几年开源项目越发普及，很多商业软件都逐渐引入开源项目。由于我负责的产品线采用了不少开源项目（主要是C++、Java、Python），这几年就经常会碰到开源项目选型的问题（从几个具有类似功能的开源软件项目中进行抉择）。今天我就大概聊一下自己的几点看法，供大伙儿参考。

　　●License（授权协议）

　　License是很多人容易忽略的一个问题，所以我们先来聊一下License的问题。因为公司里面开发的软件基本上都属于商业软件，根据开源协议和商业的冲突程度，可以分为三种：非常友好、不太友好、很敌对。下面分别介绍一下：

　　先说说“很敌对”的协议：GPL。GPL和商业软件是严重冲突的。通俗地说，如果某个软件产品使用了某个基于GPL协议的库，则这个产品必须也使用 GPL协议发布（这就是大名鼎鼎的GPL传染性）。因此，一旦发现某个开源项目是遵从GPL协议的，即使功能再强再好用，也只好忍痛割爱了。在此郑重提醒大伙儿，切莫抱侥幸心理，偷偷使用。一旦被雪亮的群众眼睛所发现，不光害了自己的名节，公司的名节也不保。

　　由于GPL对于商业软件太不友好，估计当年很多开源库的作者怨声载道。GNU组织为了缓和一下矛盾，搞出了一个折衷的LGPL协议。这个协议相对GPL来说，宽松了一些：商业软件在不修改代码的前提下，可以在产品中使用LGPL的开源库。所以LGPL属于商业“不太友好”的协议。

　　最后来说一下“非常友好”的协议，比较出名的有这几种：BSD、MPL、Apache、MIT。这些协议不但允许项目的使用者使用开源库，还允许对开源库进行修改并重新分发。因此用起来特别爽。上述这几个协议在细节上有些小差异，大伙儿可以去它们官网瞧一下。

　　另外，有些开源软件使用公共域授权（Public Domain，具体定义详见这里）。简单说，就是不作任何限制，软件的使用者可以为所欲为 :)

　　上面提到的几种协议都是知名协议。还有少数开源项目不是采用知名协议，而是自己搞了一套协议。如果你碰到这种情况，就得硬着头皮认真读一遍协议上的洋文，看看它对于使用者有些什么限制了。

　　●技术层面的因素

　　由于技术层面的考量和你所开发的软件密切相关，因此这方面的评判依据千差万别。我只能挑几个比较通用的说一下。

　　假如你开发的是跨平台的项目，那么你选择开源项目就得考虑它支持哪些平台（操作系统、数据库等）。如果你想支持的平台它不能支持，那就赶紧另找一个。

　　有时候编译器的支持也是考虑的指标之一。比如我在“C++的可移植性和跨平台开发”里面提到的老式编译器问题。再比如我曾经实施一个Java项目，用户的环境是JDK1.4。那么有些用了Java 1.5新语法的开源库就不能使用。

　　假如你开发的软件是性能敏感的，那选型的时候就要测试一下几个候选项目的性能指标。

　　现在安全问题越来越严重。如果你比较在意安全性的话，还得顺便调查一下候选项目是否有安全问题（比如缓冲区溢出的bug、比如跨站脚本注入等）。

　　●普及程度（用户的人气）

　　所谓的普及程度，就是看开源项目的用户占有率。当然大伙儿不是搞市场调查的，花钱请市场调查公司也不现实。简单的办法就是用搜索引擎大致搜一下，就能看出几个候选项目使用的广泛度了。

　　还有另外一个判断普及程度的方式，就是看某个开源项目是否被知名的软件或者公司采用。比如Firefox（算是知名软件）采用Sqlite来存储页面缓存，这至少可以从侧面反映出Sqlite项目的优秀程度。

　　对于若干个候选项目，显然要优先考虑普及度高的那个。因为某个项目普及度高，至少说明（但不绝对）它比较成熟、稳定、安全。而且用的人多了之后，相应的文档也会多一些，碰到问题也容易找到人咨询。

　　●活跃程度（开发的人气）

　　这里说的"活跃"，是指开发层面。一般来说，一个项目越活越，则新功能的推出越快，对提交bug的响应也越快。有些项目，由于开发人员不再继续开发（可能开发人员厌倦了、可能开发人员太忙了），从而导致活跃度很低。

　　不过也有例外。有些项目由于已经非常完善了，因此反而活跃程度很低。我印象当中bzip2最近几年就很少有更新。

　　●其它的风险

　　最后来说说一些其它的风险。一般来说，只有当前几个因素都差不多的时候，才会来考虑其它风险。

　　有些项目过于依赖个人英雄主义，靠1-2个大牛完成整个项目。一旦大牛出现意外，导致整个项目受到严重影响。典型的例子就是ReiserFS文件系统的创始人Hans Reiser。这位老兄由于谋杀妻子的罪名成立，被判入狱15年（对IT八卦有兴趣的同学可以看这里）。导致ReiserFS项目受到严重影响。

　　还有些开源项目被商业公司收购后，由于种种原因（商业、管理、政治等）导致该开源项目受到不利影响。比如上星期听说Michael Widenius（MySQL共同创始人）和Marten Mickos（MySQL前CEO）从Sun离职。再加上去年10月走掉了的David Axmark（MySQL共同创始人）。估计对MySQL的影响不小。

　　上述提到的几个考量指标，越前面的，权重越高。你在选型时需要综合考虑这几个因素。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/superbeck/archive/2009/02/16/3895465.aspx