五种开源协议的比较
五种开源协议的比较(BSD,Apache,GPL,LGPL,MIT)
当Adobe、Microsoft、Sun等一系列巨头开始表现出对”开源”的青睐时，”开源”的时代即将到来！
最初来自：https://www.sodocs.net/doc/e018447649.html,/read.php?tid-662-page-e-fpage-1.html（遗憾的是这个链接已经打不开了），我基本未改动，只是进行了一些排版和整理。
参考文献：https://www.sodocs.net/doc/e018447649.html,/licensing/licenses/
现今存在的开源协议很多，而经过Open Source Initiative组织通过批准的开源协议目前有58种
（https://www.sodocs.net/doc/e018447649.html,/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采用的协议。该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。需要满足的条件也和BSD类似：
1.需要给代码的用户一份Apache Licence
2.如果你修改了代码，需要再被修改的文件中说明。
3.在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来
作者规定需要包含的说明。
4.如果再发布的产品中包含一个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严格要求使用了GPL类库的软件产品必须使用GPL协议，对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。
其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。
LGPL（GNU Lesser General Public License）
LGPL是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。
但是如果修改LGPL协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL 协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。
GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品
MIT（MIT）
MIT是和BSD一样宽范的许可协议,作者只想保留版权,而无任何其他了限制.也就是说,你必须在你的发行版里包含原许可协议的声明,无论你是以二进制发布的还是以源代码发布的.
Linux 开源协议 现今存在的开源协议很多，而经过Open Source Initiative组织通过批准的开源协议目前有58种（https://www.sodocs.net/doc/e018447649.html,/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.0 Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD 类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。需要满足的条件也和BSD类似： ●需要给代码的用户一份Apache Licence。 ●如果你修改了代码，需要再被修改的文件中说明。 ●在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标， 专利声明和其他原来作者规定需要包含的说明。 ●如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成 更改。 Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。 3．GPL（GNU General Public License） 大家很熟悉的Linux就是采用了GPL。GPL协议和BSD，Apache Licence等鼓
开源软件许可协议简介 很多软件开发者和设计者都有将自己的软件作品以开源的形式公之于众的想法。他们希望其他人也可以分享自己的作品，使用自己的作品。开源社区之所以能蓬勃发展就是因为人们有这样的愿望。开源软件如此的丰富，任何你能想到的应用领域里都能找到它们的身影。大部分的设计人员都已经把使用开源软件和开源代码作为日常工作不可缺少的一部分了(WordPress, Drupal 和许多其它的内容管理系统都是开源软件)。 但是很多的软件作者和设计者都对各种不同的开源许可协议的内容和含义不甚了了。当你选择了某种开源许可协议时，你都放弃了哪些权力？在没有能明白各种开源协议的确切含义前，在不知道它们最适用于什么情况下时，软件开发者不可能在关于哪个许可协议最适合自己的软件的问题上做出准确的抉择。 什么是软件许可协议？ 关于究竟什么是许可协议的问题上有很多事实而非的说法。当你给软件附上许可证时，意味着你将保留对软件的所有权利。你将对你的作品拥有原创版权(或者是专利权，如果你申请到了)。许可协议用来授权其他人具有某种使用你的作品的权利。 依靠许可协议将你的作品对外开源或者对你的作品的各个方面逐一进行授权，是一个不错的方法。一旦对外开源，你将失去所有对你的作品的版权，别人也没有义务将你标注为作品的原创者或捐献者。而我说的后一种情况里，估计你需要从设计和开发的工作中抽出更多的时间来处理遇到的各种侵权问题。 开源许可协议使人们免去了研究那些专业的许可条款的麻烦，使人们更方便的对开源项目贡献出自己的代码。而且它还能保护你作为作品的原创作者，确保你至少拥有由于贡献参与而带来的署名荣誉。它还能用来阻止其他人企图声明对你的作品拥有所有权的行为。 GNU General Public License 通用公共许可协议 GNU General Public Licence 通用公共许可协议 (GPL) 可以说是在开源项目中使用最广泛的一种协议来。 GPL 对开发开源软件的开发者们在权利上进行了周详的认可和保障。本质上讲，它允许用户对软件进行合法的拷贝，传播和修改。这意味着你可以： ?随意复制。 把它拷贝到你自己的服务器上、你的客户的服务器上、你自己的电脑上，基本上任 何你能想到的地方。对你拷贝的数量也没有任何限制。（译者按：中国人用盗版用 惯了，估计对这点会很不以为然。） ?随意传播。 在你的网站上做一个下载链接进行下载。拷贝到你的移动硬盘里送人。把原代码打 印出来，站在屋顶散发（最好别这样做，会浪费纸，而且影响环境清洁）。
竭诚为您提供优质文档/双击可除apache2.0开源协议 篇一：常见开源协议比较 常见的开源协议及它们的适用范围 bsd bsd开源协议是一个给于使用者很大自由的协议。基本上使用者可以”为所欲为”,可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。 但”为所欲为”的前提当你发布使用了bsd协议的代码，或则以bsd协议代码为基础做二次开发自己的产品时，需要满足三个条件： 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的bsd协议。如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的bsd协议。 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。bsd代码鼓励代码共享，但需要尊重代码作者的著作权。bsd由于允许使用者修改和重新发布代码，也允许使用或在bsd代码上开发商业软件发布和销售，因此是对
商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选bsd协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。 apachelicence2.0 apachelicence是著名的非盈利开源组织apache采用的协议。该协议和bsd类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。需要满足的条件也和bsd类似： 需要给代码的用户一份apachelicence 如果你修改了代码，需要再被修改的文件中说明。 在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协 议，商标，专利声明和其他原来作者规定需要包含的说明。 如果再发布的产品中包含一个notice文件，则在notice 文件中需要带有apachelicence。你可以在notice中增加自己的许可，但不可以表现为对apachelicence构成更改。 apachelicence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。 gpl 我们很熟悉的linux就是采用了gpl。gpl协议和
开源界的 5 大开源许可协议 作者: its|发布: 2010-3-30 (13:33)|阅读: 7987|评论: 0|静态地址|内容源码 越来越多的开发者与设计者希望将自己的产品开源，以便其他人可以在他们的代码基础上做更多事，开源社区也因此充满生机。在我们所能想到的应用领域，都有开源软件存在（象 WordPress，Drupal 这些开源CMS）。然而很多人对开源许可并不了解，本文介绍开源领域常用的几种许可协议以及它们之间的区别。 什么是许可协议？ 什么是许可，当你为你的产品签发许可，你是在出让自己的权利，不过，你仍然拥有版权和专利（如果申请了的话），许可的目的是，向使用你产品的人提供一定的权限。 不管产品是免费向公众分发，还是出售，制定一份许可协议非常有用，否则，对于前者，你相当于放弃了自己所有的权利，任何人都没有义务表明你的原始作者身份，对于后者，你将不得不花费比开发更多的精力用来逐个处理用户的授权问题。 而开源许可协议使这些事情变得简单，开发者很容易向一个项目贡献自己的代码，它还可以保护你原始作者的身份，使你至少获得认可，开源许可协议还可以阻止其它人将某个产品据为己有。以下是开源界的 5 大许可协议。
GNU GPL GNU General Public Licence(GPL) 有可能是开源界最常用的许可模式。GPL 保证了所有开发者的权利，同时为使用者提供了足够的复制，分发，修改的权利： ?可自由复制 你可以将软件复制到你的电脑，你客户的电脑，或者任何地方。复制份数没有任何限制。 ?可自由分发 在你的网站提供下载，拷贝到U盘送人，或者将源代码打印出来从窗户扔 出去（环保起见，请别这样做）。 ?可以用来盈利 你可以在分发软件的时候收费，但你必须在收费前向你的客户提供该软件的 GNU GPL 许可协议，以便让他们知道，他们可以从别的渠道免费得到 这份软件，以及你收费的理由。 ?可自由修改 如果你想添加或删除某个功能，没问题，如果你想在别的项目中使用部分代码，也没问题，唯一的要求是，使用了这段代码的项目也必须使用 GPL 协议。 需要注意的是，分发的时候，需要明确提供源代码和二进制文件，另外，用于某些程序的某些协议有一些问题和限制，你可以看一下@PierreJoye写的Practical Guide to GPL Compliance一文。使用 GPL 协议，你必须在源代码代码中包含相应信息，以及协议本身。 GNU LGPL GNU 还有另外一种协议，叫做 LGPL （Lesser General Public Licence），它对产品所保留的权利比 GPL 少，总的来说，LGPL 适合那些用于非 GPL 或非开源产品的开源类库或框架。因为 GPL 要求，使用了 GPL 代码的产品必须也使用GPL 协议，开发者不允许将 GPL 代码用于商业产品。LGPL 绕过了这一限制。 BSD BSD 在软件分发方面的限制比别的开源协议（如 GNU GPL）要少。该协议有多种版本，最主要的版本有两个，新 BSD 协议与简单 BSD 协议，这两种协议经过修正，都和 GPL 兼容，并为开源组织所认可。 新 BSD 协议（3条款协议）在软件分发方面，除需要包含一份版权提示和免责声明之外，没有任何限制。另外，该协议还禁止拿开发者的名义为衍生产品背书，但简单 BSD 协议删除了这一条款。 MIT
开源许可协议 （初稿） 河南新创元信息网络有限公司 研发部 文档修订历史记录
目录 1目的 (1) 2开源许可协议定义 (1) 3开源许可协议介绍 (1) 3.1GNU GPL (1) 3.2GNU LGPL (2) 3.3BSD (3) 3.4Apache license. 2.0 (3) 3.5MIT许可协议（MIT License） (4) 3.6知识共享协议 (4) 3.7CPL(Common Public Liecense) vesion 1.0 (5) 3.8 MPL协议 (6) 3.9CDDL协议 (7) 4附录 (8) 4.1GPL3.0协议 (8) 4.1.1导言 (8) 4.1.2条款和条件 (9) 4.1.3如何在您的新程序中应用这些条款？ (19) 4.2 LGPL 2.1协议 (21) 4.2.1导言 (21) 4.2.2条款和条件 (23)
1目的 为了让开发人员能够正确合法的使用开源软件，避免因为不小心而触犯到相关法律法规，产生不必要的法律纠纷，现对开源界的几大开原协议进行了翻译和整理。 2开源许可协议定义 自由软件/开源软件是自由的，免费的，源代码开放的，我们可自由下载安装和使用。同时，为了维护作者和贡献者的合法权利，保证这些软件不被一些商业机构或个人窃取，影响软件的发展，开源社区开发出了各种的开源许可协议。其中主要分三大类。 OSI-Approved Open Source：被开放源码组织（https://www.sodocs.net/doc/e018447649.html,）所批准的开放源码授权协议。如常见的Apache，GPL，LGPL，MIT Licence，都属于 OSI-Approved的授权协议，OSI 的要求之一是二进制文件和源代码的自由发放。 Other/Proprietary License：其他的，私有的授权协议。指软件作者提供源代码，但是对软件的分发和发布有其他的限制。 Public Domain：公共域授权。将软件授权为公共域，表示作者完全放弃版权，任何人都可以随意使用。 大部分开源工程都属于OSI-Approved Open Source，下面对常见的License做简单的介绍。 3开源许可协议介绍 3.1GNU GPL GNU有两种协议其中一种为General Public Licence (GPL) ，该协议有可能是
各种开源协议说明 许多开发者和设计者希望把他们的作品作为开源项目共享，他们希望其他人能够利用和共享他们的代码。而各种开源社区就是因为这个原因而充满活力。开源软件可以用于你能想象得到的任何应用程序，许多web设计人员使用开源软件作为开发基础（例如 WordPress，Drupal等等许多CMS系统都是开源的）。 但是许多开发者和设计者并没有对开源License有清楚的了解，不清楚当他们选择开发自己的源代码时，他们有什么权利。如果不知道明确的 License的内容，他们就不知道如何做出最明智的选择，如何做对他们最有利。 对于中国的开发者来说，因为中国发达的盗版文化，泛滥的盗版软件，大部分人恐怕都完全没有License或者版权这个概念，都是奉行拿来主义。如果我们一直都是这样的话，中国软件何来进步。所以对于国内的开发者来说，第一课就是应该学习如何使用和遵守License。 什么是License 许多混乱就始于你不知道License到底是什么，到底有什么含义。当你对你的产品使用License时，并不意味着你放弃了任何权利，你依然对其拥有原著作权。License只是授予他们于特定权利来使用你的产品。 License只是把你的作品释放到公有领域，或者给各个拷贝赋予权限。也意味着你放弃了版权收入，别人也没有义务把你列为原作者或贡献者。 开放源代码许可协议更容易为他人作出贡献，而不必寻求特别的许可。它也可以保护你作为原创者的权利，至少确认了你的贡献。它还可以保证你的工作不为别人所剽窃。 GNU General Public License GNU General Public License （GPL）的可能是开源项目最常用的许可证。GPL赋予和保证了开源项目开发者广泛的权利。基本上，它允许用户合法复制，分发和修改软件。这意味着你可以： 复制软件 复制软件到自己的服务器，客户端的服务器，你自己的电脑，几乎任何你想要的地方，而且没有数量限制。 发布软件
一．每个协议分别找出一个使用该协议的开源软件。 1.GPL，全称GNU General Public License。它的主要内容为：只要在一个软件中使用(“使用”指类库引用或者修改后的代码) GPL 协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和免费。这个协议就不太适合商用软件，或者准备使用GPL开源组件 的商用项目。基于这个协议的项目，极大的提高了开源软件的数量。 采用这个协议的开源软件有：Linux、MySQL 。 2.LGPL，全称GNU Lesser General Public License 次通用公共许可协议。LGPL允许商业软件通过引用类库的方式使用LGPL组件（不直接使用源代码），这样可以不需要开源商业软件的代码。但是如果要修改原始组件的代码，则涉及修改部分的代码和基于原来代码衍生的代码都必须采用LGPL协议。LGPL不适合以LGPL协议为基础的代码进行二次开发的商业软件，但是商用软件可以采用编译后的类库引用就不需要公开源代码了。 采用这个协议的开源软件有：JBoss、FCKeditor 、Hibernate。 3. BSD，全称Berkeley Software Distribution。这个协议允许使用者修改和重新发布代码，也允许使用或在BSD代码基础上开发商业软件发布和销售，因此是适用于商业软件 的。 ?使用时还必须做到满足三个条件： 1）如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。 2）如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。 3）不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。 ?适用BSD协议的开源软件有：nginx、CruiseControl、Redis。 4 MIT，源自麻省理工学院（Massachusetts Institute of Technology, MIT），又称X11协议。 MIT与BSD类似，但是比BSD协议更加宽松，是目前最少限制的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。使用MIT的软件项目有：jquery、Node.js。 5. apache Licence vesion 2.0，这个协议除了为用户提供版权许可之外，还有专利许
2、LGPL LGPL是GPL的一个为主要为类库使用设计的开源协议。LGPL允许商业软件通过类库引用（link）方式使用LGPL类库而不需要开源商业软件的代码。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。 3、BSD BSD开源协议是一个给于使用者很大自由的协议。基本上使用者可以自由的使 用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。
当使用了BSD协议的代码，或者以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件： 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD 协议。 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中 包含原来代码中的BSD协议。 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。 因此，很多公司企业在选择开源软件的时候都首选BSD协议，因为可以完全控制这些第三方的代码，而且在必要的时候可以进行修改或者二次开发。 4、Apache License Apache Licence 2.0（Apache License, Version 2.0、Apache License, V ersion 1.1、Apache License, Version 1.0） Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BS D类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布 （作为开源或商业软件）。需要满足的条件也和BSD类似： 需要给代码的用户一份Apache Licence 如果你修改了代码，需要再被修改的文件中说明。 在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有A pache Licence。你可以在Notice中增加自己的许可，但不可以表现为对Apach e Licence构成更改。
开源许可协议说明 如今开源的软件已经越来越被广泛使用，各种专利纠纷也越来越多。工作上要求对开源协议的理解也很迫切，做技术架构是每一个技术人员最渴望的职责，但要做好初级的技术架构工作首先要对各种各样的开源协议有深入了解，知道什么开源软件是工作在什么协议之下，对自己的产品有什么影响。这篇博文将讲解开源协议的相关知识。 首先要弄懂一些基本概念： 1 什么是许可协议？ 什么是许可，当你为你的产品签发许可，你是在出让自己的权利，不过，你仍然拥有版权和专利（如果申请了的话），许可的目的是，向使用你产品的人提供一定的权限。 不管产品是免费向公众分发，还是出售，制定一份许可协议非常有用，否则，对于前者，你相当于放弃了自己所有的权利，任何人都没有义务表明你的原始作者身份，对于后者，你将不得不花费比开发更多的精力用来逐个处理用户的授权问题。 而开源技术许可协议使这些事情变得简单，开发者很容易向一个项目贡献自己的代码，它还可以保护你原始作者的身份，使你至少获得认可，开源许可协议还可以阻止其它人将某个产品据为己有。 2. 常用开源协议 GPL(GNU General Public License) 我们很熟悉的Linux就是采用了GPL。GPL协议和BSD，Apache Licence等鼓励代码重用的 许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux，包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。 GPL协议的主要内容是只要在一个软件中使用(”使用”指类库引用，修改后的代码或者衍生代码)GPL协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题，还可以享受免费的优势。GPL协议最主要的几个原则：
竭诚为您提供优质文档/双击可除 nginx,开源协议 篇一：开源协议 一．每个协议分别找出一个使用该协议的开源软件。 1.gpl，全称gnugeneralpubliclicense。它的主要内容为：只要在一个软件中使用(“使用”指类库引用或者修改后的代码)gpl协议的产品，则该软件产品必须也采用gpl协议，既必须也是开源和免费。这个协议就不太适合商用软件，或者准备使用gpl开源组件的商用项目。基于这个协议的项目，极大的提高了开源软件的数量。 采用这个协议的开源软件有：linux、mysql。 2.lgpl，全称gnulessergeneralpubliclicense次通用公共许可协议。lgpl允许商业软件通过引用类库的方式使用lgpl组件（不直接使用源代码），这样可以不需要开源商业软件的代码。但是如果要修改原始组件的代码，则涉及修改部分的代码和基于原来代码衍生的代码都必须采用lgpl协议。lgpl不适合以lgpl协议为基础的代码进行二次开发的商业软件，但是商用软件可以采用编译后的类库引用就不需要公开源代码了。
采用这个协议的开源软件有：jboss、Fckeditor、hibernate。3.bsd，全称berkeleysoftwaredistribution。这个协议允许使用者修改和重新发布代码，也允许使用或在bsd代码基础上开发商业软件发布和销售，因此是适用于商业软件的。 使用时还必须做到满足三个条件： 1）如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的bsd协议。 2）如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的bsd协议。3）不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。 适用bsd协议的开源软件有：nginx、cruisecontrol、Redis。 4mit，源自麻省理工学院（massachusettsinstituteoftechnology,mit），又称x11 协议。mit与bsd类似，但是比bsd协议更加宽松，是目前最少限制的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。使用mit 的软件项目有：jquery、node.js。 5.apachelicencevesion2.0，这个协议除了为用户提供版权许可之外，还有专利许
开源软件授权协议详解(GPLMPLLGPLBSDApache LicenceCreative Commons 开源软件授权协议详解（GPL/MPL/LGPL/BSD/Apache Licence/Creative Commons/MIT）开源在今天的软件业已经很普遍，但开源是否意味着使用者可以对开源后的代码为所欲为呢?答案是否 定的。 开源运动同样有自己的游戏规则和道德准则。 不遵行这些规则不但损害开源运动的健康发展，也会对违规者造 成名誉和市场上的损失，更可能陷入法律纠纷和赔偿。 现今存在的开源协议很多，而经过Open SourceInitiative组织 通过批准的开源协议目前有58种。 我们在常见的开源协议如BSD,GPL,LGPL,MIT等都是OSI批准的协议。 如果要开源自己的代码，最好也是选择这些被批准的开源协议。 强开源约束授权GPL（GNU General Public License）我们很熟 悉的Linux就是采用了GPL。 GPL协议和BSD，Apache Licence等鼓励代码重用的许可很不一样。 GPL的出发点是代码的开源/使用和引用/修改/衍生代码的开源/ 使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。
这也就是为什么我们能用的各种linux，包括商业公司的linux 和linux上各种各样的由个人，组织，以及商业软件公司开发的软件了。 GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用，修改后的代码或者衍生代码)GPL协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和。 这就是所谓的”传染性”。 GPL协议的产品作为一个单独的产品使用没有任何问题，还可以享受的优势。 由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议，对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。 其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。 弱开源约束授权MPL License（Mozilla PublicLicense）允许重发布、修改，但要求修改后的代码版权归软件的发起者。 这种授权维护了商业软件的利益，，它要求基于这种软件的修改无偿贡献版权给该软件。 这样，围绕该软件的所有代码得版权都集中在发起开发人得手中。 但MPL是允许修改，无偿使用的。 MPL软件对链接没有要求。
开源软件许可协议 多数人没有注意到开源软件许可的存在，这是因为它不同于传统的书面签字或上网点击那样“接受许可”的方式。开源软件的许可协议是开放的，只要具有相应行为就可“默认”接受的许可；但如“被许可人”不遵守有关许可条件，许可随时会被终止，“被许可人”持有开源软件的权利将自动终止，并需承担违约责任的风险。 BSD、GPL、LGPL、MPL是应用最为普遍的四种典型的自由/开源软件的许可协议(占自由/开源软件全部许可协议的80%以上)。 BSD许可证 BSD是一种自由软件，其许可协议为FreeBSD。FreeBSD的主要规定是： 公开BSD的源码，可让你自由获得、复制、修改、分发BSD原创软件作品(源码)；也可在BSD公开的源码基础上衍生你的软件作品。衍生的软件作品(其源码)可以公开，也可不公开。 在你进行修改或衍生时，必须对哪些是你所获得的BSD原创软件作品所实行的BSD许可证，哪些是你在其上进行的再开发，或生成你自己的许可证，要区分清楚。当你依法处理的作品再分发时，必须作出相应的版权声明，列出相应条件，并表明BSD拒绝担保的声明。对于获得的BSD原创软件作品(源码)的版权(所有权)要明确表示出来，如标明它是加州大学伯克利分校的 (=regents of the University of California, =University of Ca lifornia, Berkeley)，即其版权属于加州大学“董事”和“贡献者”，或“所有者” (owner)，并标明BSD许可证发布时间(如=1998)，而且你要对使用BSD 的原创软件作品向版权所有者(owner)表示感谢(这些标明都要让你的用户知道)。如果你把获得的这些BSD原创软件作品看成是你自己的“自主知识产权”，那无异于“剽窃”。至于你衍生的软件作品，可以公开，也可以不公开(其实微软也使用了很多BSD的原创作品，但微软的衍生作品不公开)。 必须明确，BSD软件版权所有者或贡献者是以“AS IS”(即“保持原样”)方式提供的。在你再开发的衍生作品中，未获得预先特定许可时，不得用伯克利<组织>或贡献者的名字来为你背书；原创作品版权所有者或贡献者均不对你使用、修改、再传播、再发行的BSD原创作品以及你的衍生作品提供任何直接或隐含的担保，同时也不承担相应的责任。 GPL许可 多数自由/开源软件采用通用许可协议： GNU/GPL(GNU General Public License，简称GPL)，这是自由软件基金会(Free Software Foundation，FSF)发布的一个软件授权许可证。现有40000
竭诚为您提供优质文档/双击可除 bsd,开源协议 篇一：常见开源协议比较 常见的开源协议及它们的适用范围 bsd bsd开源协议是一个给于使用者很大自由的协议。基本上使用者可以”为所欲为”,可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。 但”为所欲为”的前提当你发布使用了bsd协议的代码，或则以bsd协议代码为基础做二次开发自己的产品时，需要满足三个条件： 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的bsd协议。如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的bsd协议。 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。bsd代码鼓励代码共享，但需要尊重代码作者的著作权。bsd由于允许使用者修改和重新发布代码，也允许使用或在bsd代码上开发商业软件发布和销售，因此是对
商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选bsd协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。 apachelicence2.0 apachelicence是著名的非盈利开源组织apache采用的协议。该协议和bsd类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。需要满足的条件也和bsd类似： 需要给代码的用户一份apachelicence 如果你修改了代码，需要再被修改的文件中说明。 在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协 议，商标，专利声明和其他原来作者规定需要包含的说明。 如果再发布的产品中包含一个notice文件，则在notice 文件中需要带有apachelicence。你可以在notice中增加自己的许可，但不可以表现为对apachelicence构成更改。 apachelicence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。 gpl 我们很熟悉的linux就是采用了gpl。gpl协议和
GPL GPL授予程序接受人以下权利，或称“自由”： * 以任何目的运行此程序的自由 * 以学习程序工作机理为目的，对程序进行修改的自由（能得到源代码是前提） * 再发行复制件的自由 * 改进此程序，并公开发布改进的自由（能得到源代码是前提） 相反地，随版权所有软件的最终用户许可证几乎从不授予用户任何权利（除了使用的权利），甚至可能限制法律允许的行为，比如逆向工程。 GPL与其他一些更“许可的”自由软件许可证（比如BSD许可证）相比，主要区别就在于GPL寻求确保上述自由能在复制件及演绎作品中得到保障。它通过一种由Stallman发明的叫copyleft的法律机制实现，即要求GPL程序的演绎作品也要在GPL之下。相反，BSD式的许可证并不禁止演绎作品变成版权所有软件。 copyleft GPL不会授予许可证接受人无限的权利。再发行权的授予需要许可证接受人开放软件的源代码，及所有修改。且复制件、修改版本，都必须以GPL为许可证。 这些要求就是copyleft，它的基础就是作品在法律上版权所有。由于它版权所有，许可证接受人就无权进行修改和再发行（除合理使用），除非它有一个copyleft条款。如果某人想行使通常被法律所禁止的权利，只需同意GPL的条款。相反地，如果某人发行软件违反了GPL（比如不开放源代码），他就有可能被原作者起诉。 copyleft利用版权法来达到与其相反的目的：copyleft给人不可剥夺的权利，而不是版权法所规定的诸多限制。这也是GPL被称作“被黑的版权法”的原因。
许多GPL软件发行者都把源代码与可执行程序捆绑起来。另一方式就是以物理介质（比如CD）为载体提供源代码。在实践中，许多GPL软件都是在互联网上发行的，源代码也有许多可以FTP方式得到。 copyleft只在程序再发行时发生效力。对软件的修改可以不公开或开放源代码，只要不发行。注意copyleft只对软件有效力，而对软件的输出并无效力（除非输出的是软件本身）。不过这在GPL版本3中可能会有改动。 LGPL GNU宽通用公共许可证，简称LGPL(GNU Lesser General Public License)，被用于一些(但不是全部)GNU程序库。这个许可证以前被称为GNU库(Library)通用公共许可证。 LGPL是GPL的变种，也是GNU为了得到更多的甚至是商用软件开发商的支持而提出的。与GPL的最大不同是，可以私有使用LGPL授权的自由软件，开发出来的新软件可以是私有的而不需要是自由软件。所以任何公司在使用自由软件之前应该保证在LGPL或其它GPL变种的授权下。 Apache License Apache License是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布(作为开源或商业软件)。需要满足的条件： * 需要给代码的用户一份Apache License * 如果你修改了代码，需要再被修改的文件中说明 * 在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议、商标、专利声明和其他原来作者规定需要包含的说明 * 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache License。你可以在Notice中增加自己的许可，但不可以表现为对Apache License构成更改 Apache License也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。 BSD
竭诚为您提供优质文档/双击可除 lgpl开源协议 篇一：几种开源协议介绍 开源在今天的软件业已经很普遍，但开源是否意味着使用者可以对开源后的代码为所欲为呢？答案是否定的。开源运动同样有自己的游戏规则和道德准则。不遵行这些规则不但损害开源运动的健康发展，也会对违规者造成名誉和市场上的损失，更可能陷入法律纠纷和赔偿。 现今存在的开源协议很多，而经过opensourceinitiative组织通过批准的开源协议目前有58种。我们在常见的开源协议如bsd,gpl,lgpl,mit等都是osi 批准的协议。如果要开源自己的代码，最好也是选择这些被批准的开源协议。 几个常见的开源协议： bsd开源协议 bsd开源协议是一个给于使用者很大自由的协议。基本上使用者可以”为所欲为”,可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。 但”为所欲为”的前提当你发布使用了bsd协议的代码，
或则以bsd协议代码为基础做二次开发自己的产品时，需要满足三个条件： 1．如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的bsd协议。 2．如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的bsd协议。 3．不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。 bsd代码鼓励代码共享，但需要尊重代码作者的著作权。bsd由于允许使用者修改和重新发布代码，也允许使用或在bsd代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选bsd协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。 apachelicence2.0 apachelicence是著名的非盈利开源组织apache采用的协议。该协议和bsd类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。需要满足的条件也和bsd类似： 1．需要给代码的用户一份apachelicence 2．如果你修改了代码，需要再被修改的文件中说明。 3．在延伸的代码中（修改和有源代码衍生的代码中）
五种开源协议的比较 (BSD,APACHE,GPL,LGPL,MIT)–整 理
最初来自：https://www.sodocs.net/doc/e018447649.html,/READ.PHP?TID-662-PAGE-E-FPAGE-1.HTML（遗憾 的是这个链接已经打不开了），我基本未改动，只是进行了一些排版和整理。 参考文献：https://www.sodocs.net/doc/e018447649.html,/LICENSING/LICENSES/
当 Adobe、Microsoft、Sun 等一系列巨头开始表现出对”开源”的青睐时，”开源”的时代即将到来！ 现今存在的开源协议很多，而经过 Open Source Initiative 组织通过批准的开源协议目前有 58 种 （https://www.sodocs.net/doc/e018447649.html,/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 采用的协议。该协议和 BSD 类似，同样鼓励代码共享和 尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。需要满足的条件也和 BSD 类 似：
几种开源SIP协议栈对比 几种开源SIP协议栈对比 随着VoIP和NGN技术的发展，H.323时代即将过渡到SIP时代，在H.323的开源协议栈中，Openh323占统治地位，它把一个复杂而又先进的H.323协议栈展现在普通程序员的眼前，为H.323普及立下了汗马功劳。而然当在SIP时代，则出现了群雄割据的状况，SIP相对于H.323简单，灵活，于是各种协议栈层出不穷，下面将详细对比最具有代表性的5个开源项目：OPAL,VOCAL,sipX,ReSIProcate,oSIP 1、OPAL OPAL是Open Phone Abstraction Library，是Openh323的下一个版本，它仍然使用了Openh323的体系结构，并在其基础上进行扩展，同时实现了SIP,H.323，但在音频和视频的编码和传输部分有较大改动。OPAL初衷设计是包含任何电话通信协议，所以其底层进行了高度的抽象化，所以也能够很容易的支持MGCP,PSTN和将来会出现的协议。不过由于Openh323的最后一个版本还在开发中，所以原本6月发布的OPAL也被推迟，现有的OPAL还非常不完善，BUG也非常多，不
过相信以Openh323的开发班底，一定能让OPAL十分优秀。 CVS : :pserver:anonymous@https://www.sodocs.net/doc/e018447649.html,:/cvsroot/openh323/opal Language : C++ VxWorks port : Yes Win32 port : Yes Linux port : Yes Supports RFC 3261 : Yes Supports RFC 2327 : Yes Supports RFC 3264 : Yes Supports RFC 3263 : No Supports RFC 3515 : Yes Supports RFC 3262 : No Supports RFC 3311 : No TCP : Yes UDP : Yes SIZE : 8MB License : MPL Document : None Samples : UA,GK 2、VOCAL VOCAL是https://www.sodocs.net/doc/e018447649.html,开发的SIP系统，VOCAL应该是目前功能最完善，
当Adobe、Microsoft、Sun等一系列巨头开始表现出对”开源”的青睐时，”开源”的时代即将到来！ 最初来自：https://www.sodocs.net/doc/e018447649.html,/read.php?tid-662-page-e-fpage-1.html（遗憾的是这个链接已经打不开了），我基本未改动，只是进行了一些排版和整理。 参考文献：https://www.sodocs.net/doc/e018447649.html,/licensing/licenses/ 现今存在的开源协议很多，而经过Open Source Initiative组织通过批准的开源协议目前有58种 （https://www.sodocs.net/doc/e018447649.html,/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采用的协议。该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。需要满足的条件也和BSD 类似： 1. 需要给代码的用户一份Apache Licence 2. 如果你修改了代码，需要再被修改的文件中说明。 3. 在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明 和其他原来作者规定需要包含的说明。 4. 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可 以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。 Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。