五种开源协议的比较(BSD,APACHE,GPL,LGPL,MIT)–整理

Linux 开源协议现今存在的开源协议很多，而经过Open Source Initiative组织通过批准的开源协议目前有58种（/licenses /alphabetical）。

常见的开源协议如BSD、GPL、LGPL和MIT等都是OSI批准的协议。

如果要开源自己的代码，最好也是选择这些被批准的开源协议。

这里介绍四种最常用的开源协议及它们的适用范围，供那些准备开源或者使用开源产品的读者参考。

1．BSD开源协议（original BSD license、FreeBSD license、Original BSD license）BSD开源协议是一个给于使用者很大自由的协议。

基本上使用者可以“为所欲为”，可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。

但“为所欲为”的前提当你发布使用了BSD协议的代码，或则以BSD 协议代码为基础做二次开发自己的产品时，需要满足三个条件：●如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。

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

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

BSD代码鼓励代码共享，但需要尊重代码作者的著作权。

BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。

而很多的公司企业在选用开源产品的时候都首选BSD 协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。

2．Apache Licence 2.0Apache Licence是著名的非盈利开源组织Apache采用的协议。

该协议和BSD 类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。

需要满足的条件也和BSD类似：●需要给代码的用户一份Apache Licence。

各种开源协议说明开源协议是一种法律许可证，它规定了开放源代码软件的使用和分发条件。

这些协议确保了源代码的访问权，并且允许开发者修改和重新分发软件。

在详细介绍几种常见的开源协议前，值得注意的是，任何组织或个人使用开源软件时都应仔细阅读和理解相关协议的条款。

下面，我将介绍几种常见的开源协议。

1. GNU通用公共许可证（GNU General Public License，GPL）：GPL是最常见的开源许可证之一，它要求任何以GPL许可的代码修改或衍生的代码也必须采用GPL许可证进行分发。

这使得GPL成为一种“传染性”许可证，因为它保护被许可软件的自由，并要求所有修改的代码都保持开源。

因此，如果一个开源项目使用了GPL许可证，该项目的整个代码库都必须遵循GPL许可证。

2.MIT许可证：3. Apache许可证：Apache许可证是一个比较灵活的开源许可证，它鼓励自由使用、修改和重新分发。

与MIT许可证不同的是，Apache许可证要求用户在修改的代码中包含原始许可证和版权声明。

此外，该许可证还规定了与软件相关的使用、专利权和商标权等方面的额外条款。

4.BSD许可证：5. Mozilla公共许可证（MPL）：MPL是一种兼容GPL和LGPL的开源许可证，它要求修改MPL软件的代码也必须采用MPL进行分发。

然而，MPL允许将MPL软件与其他许可证的代码进行组合和分发，只要相关组件保持独立。

MPL还规定了软件使用和分发方面的条款。

总的来说，开源协议以不同的形式和方式保障了开放源代码软件的自由和灵活性。

开发者可以根据自己的需求选择适合的开源许可证，以保护其软件的使用和分发权利。

然而，无论使用哪种开源许可证，都需要严格遵守相关协议的条款，以确保合法合规地使用和分发开源软件。

以下是一些常用的开源协议：1. GNU通用公共许可证（GNU General Public License，GPL）：这是最广泛使用的开源许可证之一，它明确规定了用户对软件的自由使用、修改和传播的权利，同时要求任何基于该软件的衍生作品也必须遵循相同的开源条款。

2. MIT许可证（MIT License）：这是一种简洁而灵活的开源许可证，允许用户自由地使用、复制、修改、合并、发布和再授权软件。

它较为宽松，仅要求在软件的所有副本中包含版权声明和许可声明。

3. Apache许可证（Apache License）：这是Apache软件基金会所采用的开源许可证，允许用户在保持原始许可证条件下自由使用、修改、分发和销售软件。

与GPL 相比，Apache许可证更加商业友好。

4. BSD许可证（BSD License）：这是一系列类似的开源许可证，如BSD 2-Clause License和BSD 3-Clause License 等。

BSD许可证相对宽松，允许用户自由使用、修改和分发软件，同时要求在衍生作品中保留原始许可证和版权声明。

5. Mozilla公共许可证（Mozilla Public License，MPL）：这是由Mozilla基金会创建的一种开源许可证，主要用于保护Mozilla Firefox等开源软件。

它要求使用、修改和分发软件的衍生作品时必须遵循相同的许可证。

6. Eclipse公共许可证（Eclipse Public License，EPL）：这是Eclipse基金会采用的一种开源许可证，允许用户使用、修改和分发软件，同时对于衍生作品也有特定的规定。

请注意，每种许可证都有其独特的条款和限制，因此在选择和使用开源软件时应仔细阅读和理解相关许可证的内容，并根据项目需求进行选择。

此外，由于法律和许可证可能会随时间而变化，请在使用开源软件前查阅最新的许可证版本和法律条文。

开源软件协议（MITBSDApacheLGPLMPLGPL） 大家好，我是痞子衡，是正经搞技术的痞子。

今天痞子衡给大家讲的是关于开源软件协议基本知识。

牛顿曾说过：“如果我比别人看得更远,那是因为我站在巨人的肩上”。

在软件开发中如果说也存在巨人的肩膀让我们站，我想这个巨人应该就是开源软件。

一个优秀的软件开发人员应该能够善于学习和利用开源软件来加速自己的开发，而为了正确地使用开源软件，我们必须要了解开源软件协议，今天我们就来聊一聊开源软件协议这个话题。

1.开源软件是什么？ 所谓“开源软件”（open-source software），字面上理解就是开放源代码的软件，即在软件发行的时候，附上软件的源代码，并授权允许用户更改/自由再散布/衍生著作权。

开源软件通常是有copyright（著作权）的，它的License（许可证）可能包含这样一些额外的限制：刻意的保护它的开放源码状态，著者身份的公告，或者开发的控制。

提及开源软件，通常会想到两个形容词：免费、自由。

开源软件大多是免费的（但也并不排斥商业收费），开源软件的使用往往也是相对自由的（自由度取决于其License）。

因此常常会与开源软件造成混淆和误解的有另外两个概念：“免费软件”、“自由软件”免费软件：免费提供给用户使用的软件，通常并不包含公开其源码的内容。

自由软件：在反著作权，倡导软件这种知识产品应该免费共享的思想下诞生的软件，当然必须是要开放源代码的。

一个专用的名词copyleft（著佐权）就是用来形容这种软件。

除了前面介绍的3种类型软件之外，还有一种概念：“商业软件”，即被用作商品以达到营利目的收费软件，这种软件一般不会包含源码，并且受各种严苛的版权限制。

从上面的介绍可以看出，自由软件与商业软件是完全对立的，而开源软件就是自由软件与商业软件的折中，它既继承了“自由软件”所提倡的知识共享的理念，同时又允许人们以专利的形式从知识产品中谋取利益，从而保护了人们生产、创造知识产品的积极性。

GPLGPL授予程序接受人以下权利，或称“自由”：* 以任何目的运行此程序的自由* 以学习程序工作机理为目的，对程序进行修改的自由（能得到源代码是前提）* 再发行复制件的自由* 改进此程序，并公开发布改进的自由（能得到源代码是前提）相反地，随版权所有软件的最终用户许可证几乎从不授予用户任何权利（除了使用的权利），甚至可能限制法律允许的行为，比如逆向工程。

GPL与其他一些更“许可的”自由软件许可证（比如BSD许可证）相比，主要区别就在于GPL寻求确保上述自由能在复制件及演绎作品中得到保障。

它通过一种由Stallman发明的叫copyleft的法律机制实现，即要求GPL程序的演绎作品也要在GPL之下。

相反，BSD式的许可证并不禁止演绎作品变成版权所有软件。

copyleftGPL不会授予许可证接受人无限的权利。

再发行权的授予需要许可证接受人开放软件的源代码，及所有修改。

且复制件、修改版本，都必须以GPL为许可证。

这些要求就是copyleft，它的基础就是作品在法律上版权所有。

由于它版权所有，许可证接受人就无权进行修改和再发行（除合理使用），除非它有一个copyleft条款。

如果某人想行使通常被法律所禁止的权利，只需同意GPL的条款。

相反地，如果某人发行软件违反了GPL（比如不开放源代码），他就有可能被原作者起诉。

copyleft利用版权法来达到与其相反的目的：copyleft给人不可剥夺的权利，而不是版权法所规定的诸多限制。

这也是GPL被称作“被黑的版权法”的原因。

许多GPL软件发行者都把源代码与可执行程序捆绑起来。

另一方式就是以物理介质（比如CD）为载体提供源代码。

在实践中，许多GPL软件都是在互联网上发行的，源代码也有许多可以FTP方式得到。

copyleft只在程序再发行时发生效力。

对软件的修改可以不公开或开放源代码，只要不发行。

注意copyleft只对软件有效力，而对软件的输出并无效力（除非输出的是软件本身）。

开源运动同样有自己的游戏规则和道德准则。

不遵行这些规则不但损害开源运动的健康发展，也会对违规者造成名誉和市场上的损失，更可能陷入法律纠纷和赔偿。

现今存在的开源协议很多，而经过Open Sourcel ni tiative组织通过批准的开源协议目前有58 种。

我们在常见的开源协议如BSD,GPL,LGPL,M等都是OSI批准的协议。

如果要开源自己的代码，最好也是选择这些被批准的开源协议。

强开源约束授权GPL(GNU General Public Licens)e 我们很熟悉的Linux 就是采用了GPL。

GPL协议和BSD Ap ache Lice nee等鼓励代码重用的许可很不一样。

GPL的出发点是代码的开源/使用和引用/修改/衍生代码的开源/使用, 但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。

这也就是为什么我们能用的各种linux，包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的软件了。

GPL协议的主要内容是只要在一个软件中使用(使用”指类库引用，修改后的代码或者衍生代码)GPL协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和。

这就是所谓的”传染性”。

GPL协议的产品作为一个单独的产品使用没有任何问题，还可以享受的优势。

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

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

弱开源约束授权MPL License（Mozilla PublicLicense允许重发布、修改, 但要求修改后的代码版权归软件的发起者。

这种授权维护了商业软件的利益，，它要求基于这种软件的修改无偿贡献版权给该软件。

这样，围绕该软件的所有代码得版权都集中在发起开发人得手中。

但MPL 是允许修改，无偿使用的。

开源运动同样有自己的游戏规则和道德准则不遵行这些规则不但损害开源运动的健康发展，也会对违规者造成名誉和市场上的损失，更可能陷入法律纠纷和赔偿。

现今存在的开源协议很多，而经过Open SourceInitiative 组织通过批准的开源协议目前有58 种。

我们在常见的开源协议如BSD,GPL,LGPL,M等都是OSI批准的协议。

如果要开源自己的代码，最好也是选择这些被批准的开源协议。

强开源约束授权GPL (GNU Ge neral Public Lice ns)我们很熟悉的Li nux就是采用了GPL。

GPL协议和BSD, Apache Lice nee等鼓励代码重用的许可很不一样。

GPL的出发点是代码的开源/使用和引用/修改/衍生代码的开源/使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。

这也就是为什么我们能用的各种linux,包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的软件了。

GPL协议的主要内容是只要在一个软件中使用(使用”指类库引用，修改后的代码或者衍生代码)GPL协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和。

这就是所谓的”传染性”。

GPL协议的产品作为一个单独的产品使用没有任何问题，还可以享受的优势。

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

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

弱开源约束授权MPL License(Mozilla PublicLicense允许重发布、修改，但要求修改后的代码版权归软件的发起者。

这种授权维护了商业软件的利益，，它要求基于这种软件的修改无偿贡献版权给该软件。

这样，围绕该软件的所有代码得版权都集中在发起开发人得手中。

但MPL是允许修改，无偿使用的。

开源在今天的软件业已经很普遍，但开源是否意味着使用者可以对开源后的代码为所欲为呢？答案是否定的。

开源运动同样有自己的游戏规则和道德准则。

不遵行这些规则不但损害开源运动的健康发展，也会对违规者造成名誉和市场上的损失，更可能陷入法律纠纷和赔偿。

现今存在的开源协议很多，而经过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.0Apache Licence是著名的非盈利开源组织Apache采用的协议。

该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。

需要满足的条件也和BSD类似：1．需要给代码的用户一份Apache Licence2．如果你修改了代码，需要再被修改的文件中说明。

越来越多的开发者与设计者希望将自己的产品开源，以便其他人可以在他们的代码基础上做更多事，开源社区也因此充满生机。

在我们所能想到的应用领域，都有开源软件存在（象WordPress，Drupal 这些开源CMS）。

然而很多人对开源许可并不了解，本文介绍开源领域常用的几种许可协议以及它们之间的区别。

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

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

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

以下是开源界的5 大许可协议：GNU GPLGNU General Public Licence (GPL) 有可能是开源界最常用的许可模式。

GPL 保证了所有开发者的权利，同时为使用者提供了足够的复制，分发，修改的权利：1.可自由复制你可以将软件复制到你的电脑，你客户的电脑，或者任何地方。

复制份数没有任何限制。

2.可自由分发在你的网站提供下载，拷贝到U盘送人，或者将源代码打印出来从窗户扔出去（环保起见，请别这样做）。

3.可以用来盈利你可以在分发软件的时候收费，但你必须在收费前向你的客户提供该软件的GNU GPL 许可协议，以便让他们知道，他们可以从别的渠道免费得到这份软件，以及你收费的理由。

4.可自由修改如果你想添加或删除某个功能，没问题，如果你想在别的项目中使用部分代码，也没问题，唯一的要求是，使用了这段代码的项目也必须使用GPL 协议。

需要注意的是，分发的时候，需要明确提供源代码和二进制文件，另外，用于某些程序的某些协议有一些问题和限制，你可以看一下@PierreJoye写的Practical Guide to GPL Compliance一文。

常见的开源协议及它们的适用范围BSDBSD开源协议是一个给于使用者很大自由的协议。

基本上使用者可以”为所欲为”,可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。

但”为所欲为”的前提当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD 协议。

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

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

BSD代码鼓励代码共享，但需要尊重代码作者的著作权。

BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。

而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。

Apache Licence 2.0Apache Licence是著名的非盈利开源组织Apache采用的协议。

该协议和BSD 类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。

需要满足的条件也和BSD类似：需要给代码的用户一份Apache Licence如果你修改了代码，需要再被修改的文件中说明。

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

如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。

你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。

Apache Licence也是对商业应用友好的许可。

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

GPL我们很熟悉的Linux就是采用了GPL。

常见开源协议范文1. GNU通用公共许可证（GNU General Public License，GPL）GPL是一种基于版权法的开源协议，它保护用户的权益，强调软件的自由、开放和共享。

GPL要求源代码必须开放并且继承自GPL的衍生作品也必须遵守GPL。

2. BSD许可证（BSD License）BSD是一种非常宽松的开源许可证，在使用者满足一些基本要求的前提下，允许自由地使用、修改和再发布软件。

BSD许可证要求在再发布软件时，必须包含原始的许可证和版权声明。

3. MIT许可证（MIT License）MIT是一种非常简洁和宽松的开源许可证，允许自由地使用、修改和再发布软件。

与BSD许可证类似，MIT许可证也要求在再发布软件时，必须包含原始的许可证和版权声明。

4. Apache许可证（Apache License）Apache许可证是由Apache软件基金会开发的一种开源许可证，允许使用者自由地使用、修改和再发布软件。

Apache许可证还提供了额外的专利授权，以保护使用者免受可能存在的专利侵权诉讼。

5. Eclipse公共许可证（Eclipse Public License，EPL）EPL是一种基于GPL的开源许可证，在保护开发者和使用者的自由的同时，还鼓励商业软件的开发和整合。

EPL要求源代码必须开放，但不要求继承者的衍生作品也必须遵守EPL。

6. Mozilla公共许可证（Mozilla Public License，MPL）MPL是由Mozilla基金会开发的一种开源许可证，它是一种混合许可证，结合了GPL和BSD的特点。

MPL要求源代码必须开放，同时还允许使用者将衍生作品以其他开源协议发布。

这些开源协议各有特点，用户可以根据自己的需求和对软件的开放程度的要求，选择适合自己的开源许可证。

无论选择哪种许可证，开源协议都提供了一种通过共享和合作来促进软件开发和创新的方式，有助于推动开源社区的发展和成长。

python开源协议的种类Python开源协议有多种种类，下面我将从不同角度来介绍这些协议。

1. GNU通用公共许可证（GNU General Public License，GPL），这是一种最为广泛使用的开源协议之一。

它要求任何使用、修改和分发软件的人都必须开放源代码，并将其派生作品同样以GPL协议发布。

2. MIT许可证，这是一种宽松的开源协议，允许使用、修改和分发软件，同时不要求开放源代码。

这使得MIT许可证非常受欢迎，许多知名的开源软件都采用了这种协议。

3. Apache许可证，Apache许可证也是一种广泛使用的开源协议。

它要求使用、修改和分发软件时必须保留版权声明，并且提供原始许可证和免责声明。

Apache许可证也允许将派生作品以其他许可证发布。

4. BSD许可证，BSD许可证是一系列类似的协议，包括BSD 2-Clause License和BSD 3-Clause License等。

这些协议允许使用、修改和分发软件，同时要求保留版权声明和免责声明。

BSD许可证相对宽松，适用于商业和非商业项目。

5. Mozilla公共许可证（MPL），MPL是一种开源协议，要求使用、修改和分发软件时必须开放源代码，并且派生作品必须以MPL协议发布。

MPL还允许将软件与其他许可证进行组合。

6. Eclipse公共许可证（EPL），EPL是一种开源协议，类似于MPL。

它要求使用、修改和分发软件时必须开放源代码，并且派生作品必须以EPL协议发布。

EPL还允许将软件与其他许可证进行组合。

这些是Python开源协议的一些常见种类，每种协议都有其特点和适用范围。

开发者在选择协议时需要根据项目的需求、目标和法律要求来进行权衡和决策。

五种开源协议的比较（BSD, Apache, GPL, LGPL, MIT）2010-03-22 11:31当 Adobe、Microsoft、Sun 等一系列巨头开始表现出对”开源”的青睐时，”开源”的时代即将到来！现今存在的开源协议很多，而经过 Open Source Initiative 组织通过批准的开源协议目前有 58 种（/licenses/alphabetical）。

我们在常见的开源协议如 BSD, GPL, LGPL, MIT 等都是 OSI 批准的协议。

如果要开源自己的代码，最好也是选择这些被批准的开源协议。

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

BSD 开源协议（original BSD license、FreeBSD license、Original BSD license）BSD 开源协议是一个给于使用者很大自由的协议。

基本上使用者可以”为所欲为”,可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。

但”为所欲为”的前提当你发布使用了 BSD 协议的代码，或则以 BSD 协议代码为基础做二次开发自己的产品时，需要满足三个条件：1.如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD 协议。

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

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

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 采用的协议。

⼀张图看懂开源许可协议，开源许可证GPL、BSD、MIT、Mozilla、Apache和L。

<h1><span class="link_title"><a href="/testcs_dn/article/details/38496107">⼀张图看懂开源许可协议，开源许可证GPL、BSD、MIT、Mozilla、Apache和LGPL的区别</a></span></h1><script type="text/javascript">$(function () {try{var lib = eval("("+$("#lib").attr("value")+")");var html = "";if (lib.err == 0) {$.each(lib.data, function (i) {var obj = lib.data[i];//html += '<img src="' + obj.logo + '"/>' + + "&nbsp;&nbsp;";html += ' <a href="' + obj.url + '" target="_blank">';html += ' <img src="' + obj.logo + '">';html += ' <em><b>' + + '</b></em>';html += ' </a>';});if (html != "") {setTimeout(function () {$("#lib").html(html);$("#embody").show();}, 100);}}} catch (err){ }});</script>⾸先借⽤有⼼⼈⼠的⼀张相当直观清晰的图来划分各种协议：开源许可证GPL、BSD、MIT、Mozilla、Apache和LGPL的区别<div class="readall_box csdn-tracking-statistics tracking-click readall_box_nobg" data-pid="blog" data-mod="popu_596" style="display: none;"><div class="read_more_mask"></div><a class="btn btn-large btn-gray-fred read_more_btn" target="_self">阅读全⽂</a></div><div class="csdn-tracking-statistics" data-pid="blog" data-mod="popu_222"><a href="javascript:void(0);" target="_blank">&nbsp;</a> </div><div class="csdn-tracking-statistics" data-pid="blog" data-mod="popu_223"> <a href="javascript:void(0);" target="_blank">&nbsp;</a></div><div id="digg" articleid="38496107"></div><script type="text/javascript">function btndigga() {$(".csdn-tracking-statistics[data-mod='popu_222'] a").click();}function btnburya() {$(".csdn-tracking-statistics[data-mod='popu_223'] a").click();}</script>上⼀篇下⼀篇<div style="clear:both; height:10px;"></div>。

五种开源协议的比较(BSD,Apache,GPL,LGPL,MIT)当Adobe、Microsoft、Sun等一系列巨头开始表现出对”开源”的青睐时，”开源”的时代即将到来！最初来自：/read.php?tid-662-page-e-fpage-1.html（遗憾的是这个链接已经打不开了），我基本未改动，只是进行了一些排版和整理。

参考文献：/licensing/licenses/现今存在的开源协议很多，而经过Open Source Initiative组织通过批准的开源协议目前有58种（/licenses/alphabetical）。

我们在常见的开源协议如BSD, GPL, LGPL,MIT等都是OSI 批准的协议。

如果要开源自己的代码，最好也是选择这些被批准的开源协议。

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

BSD开源协议（original BSD license、FreeBSD license、Original BSD license）BSD开源协议是一个给于使用者很大自由的协议。

基本上使用者可以”为所欲为”,可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。

但”为所欲为”的前提当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：1.如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。

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

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

BSD 代码鼓励代码共享，但需要尊重代码作者的著作权。

BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD 代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。

而很多的公司企业在选用开源产品的时候都首选BSD 协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。

开源运动同样有自己的游戏规则和道德准则不遵行这些规则不但损害开源运动的健康发展，也会对违规者造成名誉和市场上的损失，更可能陷入法律纠纷和赔偿。

现今存在的开源协议很多，而经过Open SourceInitiative 组织通过批准的开源协议目前有58 种。

我们在常见的开源协议如BSD,GPL,LGPL,M等都是OSI批准的协议。

如果要开源自己的代码，最好也是选择这些被批准的开源协议。

强开源约束授权GPL (GNU Ge neral Public Lice ns)我们很熟悉的Li nux就是采用了GPL。

GPL协议和BSD, Apache Lice nee等鼓励代码重用的许可很不一样。

GPL的出发点是代码的开源/使用和引用/修改/衍生代码的开源/使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。

这也就是为什么我们能用的各种linux,包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的软件了。

GPL协议的主要内容是只要在一个软件中使用(使用”指类库引用，修改后的代码或者衍生代码)GPL协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和。

这就是所谓的”传染性”。

GPL协议的产品作为一个单独的产品使用没有任何问题，还可以享受的优势。

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

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

弱开源约束授权MPL License(Mozilla PublicLicense允许重发布、修改，但要求修改后的代码版权归软件的发起者。

这种授权维护了商业软件的利益，，它要求基于这种软件的修改无偿贡献版权给该软件。

这样，围绕该软件的所有代码得版权都集中在发起开发人得手中。

但MPL是允许修改，无偿使用的。