开源协议比较(BSD,Apache,GPL,LGPL,AGPL,MIT)

Love The Way You Lie 2022-11-28 13:17 468阅读 0赞

现今存在的开源协议很多，而经过Open Source Initiative组织通过批准的开源协议目前有 [80种][80]：[https://opensource.org/licenses/alphabetical][https_opensource.org_licenses_alphabetical]

我们在常见的开源协议如BSD, Apache, GPL, LGPL, MIT等都是OSI批准的协议。如果要开源自己的代码，最好也是选择这些被批准的开源协议。

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

# 1、授权协议有什么作用： #

授权协议就是授予你使用或修改软件等权利，由于软件受到著作权保护，未经授权使用即是侵犯著作权，属于违法行为，所以同意或签署软件授权协议是你使用或修改软件的前提条件。  
既然是**授权协议**，我们可以知道，这个东西分为两部分：授权和协议。你可以简单的理解为权利和义务。  
       授权即是指权利，指出你有哪些权利，例如在自己的电脑上安装、使用、重新编译发布、作为一部分嵌入在自己的软件项目中一并发布、或是修改再发布。  
       协议即是指义务，指出你有哪些义务，例如不允许反向工程，不允许开外挂，不允许修改，不允许作为自己软件项目的一部分发布，必须在使用此软件的项目中标注使用了这项技术。  
       如果你不遵守自己的义务（违背协议），那么你的授权就是无效的，即涉嫌侵犯著作权了。

# 2、授权协议有哪些种类？ #

主要可以分为开源和不开源（事实上收费和不收费的软件授权协议区别不大，下文详谈），下面分两种情况分别讨论：

## 2.1 闭源软件许可协议 ##

不开源的软件，一般都有一个类似于最终用户许可协议的东西，这个协议大体上都会包含这样一些内容：  
禁止把软件给别人用、禁止对软件反向工程、禁止或允许将软件作为自己项目的一部分发布，以及免责条款，例如操作不当导致自己的数据丢失等等。  
       免费收费共享之间的区别主要是授权协议的取得，例如免费软件一般是自由下载，然后安装的时候同意协议（下一步、下一步、下一步）即行安装。  
       收费软件一般不提供自由下载，或者下载后，必须通过付费获得授权，且同意授权协议，才能继续使用。  
共享软件提供自由下载，到一定期限后，或者需要使用额外的功能，通过付费获得扩展授权使用。

## 2.2 开源软件许可协议 ##

问题中列举的协议主要都是开源协议。  
       对于不开源软件而言，虽然授权协议都大同小异，但每个公司的授权协议，甚至不同的发行地的协议都有所不同。这是因为这些商业软件公司都拥有专业的销售和法律团队，授权协议关系到他们的核心业务，所以聘用非常专业的团队处理。

但对于开源软件而言，作者大多数是苦逼的程序员，根本没有能力聘用专业的法律顾问，有程序员搞出了一个比较完善的授权许可协议，大家就都拿来用，把里面的软件名字改改就好了。所以后来逐渐形成了几大开源授权协议，如GPL、Apache、BSD等。值得注意的是，这些开源授权协议文本本身也受著作权法保护，不过他们一般又都以开放的协议发布，允许大家随意拿来当作自己软件的授权协议。

比起不开源软件，大多数开源授权协议都比较简单，开源的特点就是开放源代码，**这里的开放，并不是指随软件一并附上源代码的意思，而是源代码也给你了，你看着办吧。**  
  
**       允不允许修改源代码，是开源软件和不开源软件的根本的区别。**这里顺便谈一下还有一种灰色地带的软件，即随软件一并附上源代码，但你只能看不能摸，**这类软件一般不认为是开源软件**。譬如说Windows就对政府开放了部分源代码，或是.NET Framework之前使用的MS-RL。

开源软件的授权协议必须包含的权利是软件源代码的修改、演绎权，否则不是开源软件。所以各大协议主要是在义务上各有区别，譬如说GPL协议要求，基于该软件开发的任何软件，都必须以GPL协议发布，这也就是**开源感染**。也就是说你要用这个开源软件，就必须把你自己的软件变成开源的。

GPL这种感染太狠了，会限制使用GPL协议发布的软件所适用的范围，全部的商业软件，和大部分的免费软件都不能使用GPL协议发布的东西。这与开源的精神**开放**相悖。所以大家又提出了很多不那么严苛的协议。如Apache就不强求基于该协议软件开发的软件以相同协议发布，仅仅要求署名。这样，以Apache发布的软件就可以作为商业软件的一部分。

# 3. GPL、BSD、MIT、Mozilla、Apache和LGPL之中做选择 #

![format_png][]

# 4. 协议介绍 #

## 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类似：

*  需要给代码的用户一份Apache Licence
 *  如果你修改了代码，需要再被修改的文件中说明。
 *  在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
 *  如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。

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

## GPL（GNU General Public License）通用性公开许可证 ##

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

GPL规定：只要这种修改文本在整体上或者其某个部分来源于遵循GPL的程序，该修改文本的 整体就必须按照GPL流通，不仅该修改文本的源码必须向社会公开，而且对于这种修改文本的流通不准许附加修改者自己作出的限制。因此，一项遵循GPL流通 的程序不能同非自由的软件合并。GPL所表达的这种流通规则称为`copyleft`，表示与copyright(版权)的概念“相左”。

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

*  确保软件自始至终都以开放源代码形式发布，保护开发成果不被窃取用作商业发售。任何一套软 件，只要其中使用了受 GPL 协议保护的第三方软件的源程序，并向非开发人员发布时，软件本身也就自动成为受 GPL 保护并且约束的实体。也就是说，此时它必须开放源代码。
 *  GPL 大致就是一个左侧版权（Copyleft，或译为“反版权”、“版权属左”、“版权所无”、“版责”等）的体现。你可以去掉所有原作的版权 信息，只要你保持开源，并且随源代码、二进制版附上 GPL 的许可证就行，让后人可以很明确地得知此软件的授权信息。GPL 精髓就是，只要使软件在完整开源 的情况下，尽可能使使用者得到自由发挥的空间，使软件得到更快更好的发展。
 *  无论软件以何种形式发布，都必须同时附上源代码。例如在 Web 上提供下载，就必须在二进制版本（如果有的话）下载的同一个页面，清楚地提供源代码下载的链接。如果以光盘形式发布，就必须同时附上源文件的光盘。
 *  开发或维护遵循 GPL 协议开发的软件的公司或个人，可以对使用者收取一定的服务费用。但还是一句老话——必须无偿提供软件的完整源代码，不得将源代码与服务做捆绑或任何变相捆绑销售。

GPL 只是规定用户在获取你的程序的时候必须可以获得源代码，但并没有规定必须免费，因此理论上说，你仍然可以收取费用。如果你的确需要发布你的程序，但又不想开源，规避 GPL 的方法是通过 LPC 或者 RPC 间接调用库里的接口。只要库和你的程序不运行在同一进程下，就不需要开源。

另外，你需要区分 GPL 和 LGPL。LGPL 的要求比 GPL 低，你可以动态链接一个 LGPL 的库而不需要开源你自己的程序，而 GPL 是不行的。

### LGPL（GNU Lesser General Public License）宽松公共许可证 ###

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

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

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

### AGPL 协议（Affero General Public License） ###

GPL（2.x ~ 3.x） 协议还有一个非常大的“漏洞”，就是软件“发布” 才必须开源。也就是说，我的软件不发布，即使使用 GPL (2.x ~ 3.x) 也可以不用开源。随着以Google为代表的软件作为服务的互联网公司的兴起，它们的“不分发软件，为客户提供网络服务”的商业模式就不受GPL协议的约束

AGPL则增加了对此做法的约束：

AGPL = GPL + 一条限制

一条限制：如果使用AGPL许可的软件与用户通过网络进行交互，也需要提供源代码给用户，所有的修改也要给用户。

## MIT（MIT） ##

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

*  被授权人有权利使用、复制、修改、合并、出版发行、散布、再授权及贩售软体及软体的副本。
 *  被授权人可根据程式的需要修改授权条款为适当的内容。
 *  在软件和软件的所有副本中都必须包含版权声明和许可声明

## Zlib/Libpng协议 ##

基于该软件的原样使用，作者不负责使用该软件照成的任何损失。

该软件修改后的版本将受到以下限制：

*  不能歪曲原软件的著作权
 *  修改后的软件不能歪曲为原版软件
 *  不能删除源码中的协议许可内容

如果发布二进制代码可以不用附上源代码。

## MPL（The Mozilla Public License）Mozilla公共许可证 ##

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与其他协议的兼容性 ###

不像那些较严格的Copyleft许可证，使用MPL授权的源代码可以在一个复杂的软件中与任何其他的许可协议相结合，只要仍满足MPL许可协议中3.3节的规定即可。这意味着在一份给定的源文件里面，必须全部的源代码都以MPL授权，否则就所有源代码均以其他方式授权。

MPL第二版与Apache许可证以及GPL第二版或更新、LGPL2.1版或更新，及AGPL第三版或更新兼容。而1.1版因为有“一些复杂的限制”造成与GPL的不兼容（从而阻止升级到MPL 2.0）。

## ##

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

*参考文献：*  
[http://www.fsf.org/licensing/licenses/][http_www.fsf.org_licensing_licenses]  
[https://my.oschina.net/yangsheng/blog/190917][https_my.oschina.net_yangsheng_blog_190917]  
[http://www.ruanyifeng.com/blog/2011/05/how\_to\_choose\_free\_software\_licenses.html][http_www.ruanyifeng.com_blog_2011_05_how_to_choose_free_software_licenses.html]  
[https://www.jianshu.com/p/549a06ed25d4][https_www.jianshu.com_p_549a06ed25d4]

[https://www.zhihu.com/question/19962512][https_www.zhihu.com_question_19962512]

[80]: http://www.opensource.org/licenses/alphabetical
[https_opensource.org_licenses_alphabetical]: https://opensource.org/licenses/alphabetical
[format_png]: /images/20221124/7e1a16c23eae4e6eb86b02ef02530b1c.png
[http_www.fsf.org_licensing_licenses]: http://www.fsf.org/licensing/licenses/
[https_my.oschina.net_yangsheng_blog_190917]: https://my.oschina.net/yangsheng/blog/190917
[http_www.ruanyifeng.com_blog_2011_05_how_to_choose_free_software_licenses.html]: http://www.ruanyifeng.com/blog/2011/05/how_to_choose_free_software_licenses.html
[https_www.jianshu.com_p_549a06ed25d4]: https://www.jianshu.com/p/549a06ed25d4
[https_www.zhihu.com_question_19962512]: https://www.zhihu.com/question/19962512