各种开源协议

出处：http://www.open-open.com/solution/view/1319816219625

现今存在的开源协议很多，而经过Open Source Initiative组织通过批准的开源协议目前有58种（http://www.opensource.org/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等类似。

关于开源协议GPL　V2和V3

单从开源行业的GPL协议上来看，似乎开源linux产品上的一切是可以无条件的开放和共享的，但是从实际的操作来看，在GPL相对的许可授权之下，又有其相对封闭的一面，就这次的GPL v2到GPL v3的修订改版来说，正是GPL协议“封闭”一面的具体体现。

根据GPL v2的相关规定：只要这种修改文本在整体上或者其某个部分来源于遵循GPL的程序，该修改文本的整体就必须按照GPL流通，不仅该修改文本的源码必须向社 会公开，而且对于这种修改文本的流通不准许附加修改者自己作出的限制。而在GPL v3的修订草案中，不仅要求用户公布修改的源代码，还要求公布相关硬件，恰恰是这一条，由于触及和其他相关数字版权管理(DRM)及其产品的关系，并且也 由于有和开源精神相违的地方，所以备受争议，甚至因此也遭到了有着“LINUX之父”之称的托瓦尔兹的反对。

从表面上看，GPL v2到GPL v3的升级之困只不过是对协议修订过程中某一条款的分歧，而更为严重的是在两种协议都合法存在的前提下，具体的开源软件或者开源产品的所有者有权选择是遵 循GPL v2协议还是恪守GPL v3协议，因此冲突也就来了，这种冲突正如中科红旗的CTO郑忠源描述的那样：“世界有如此多软件都在GPL v2的约束之下，而自由软件是集合全世界程序员劳动，即使是贡献一行代码，如果该程序员只同意这一代码只遵循GPL v2之下，就不能随便去修改协议。如果计划将软件转移到GPL v3之下，理论上讲，必须征得所有代码人的同意。但是目前还很难确定有多少开发人员愿意转移到新版本之下，如果有的人愿意转，有的人不愿意转，这其中就有 很多的麻烦；而如果多数人都不愿意改变，那这一事情也许就无声无息……”

通过业内人士的精辟描述，相信大家一定对开源行业和开源软件产品有了一个全新的认识吧，就那熟悉的LINUX系统来说，虽然表面上看起来大家有权按 照自己的需要和目的进行任意的改写重组，但是在诸多的独立程序面前，别人是只能共享使用，而无权修改的，当然获得授权就另当别论了。而就GPL v2到GPL v3的协议升级来说，这种协议的选择上的分歧实际上也是开源行业里一种观念认知上的相左，到底谁的选择是正确的？绝对不是一两句话能说得清的，尤其是在各 种利益交织之下。

情势之下，开源社区的GPL v2与GPL v3选择之困很现实的会在相当一段时间内给这个行业及其产品造成“兼容问题”，说白了就是两种协议以及两种协议之下的矛盾，不管是人的还是产品的都将会持 续下去，而这种僵持对整个开源行业来说未必是一件好事，最起码从“精神”方面来说这个行业已经在开始分道扬镳。

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

开源协议

出处： http://www.cnblogs.com/Wayou/p/how_to_choose_a_license.html

相信很多刚踏入软件这个行业的小伙伴一如当初的我，对开源软件的各种协议不甚了解被搞昏了头脑。毕竟对于一个新生程序员来说，如何写好代码才是亟待解决的问题，无暇了解这些。随着你项目做得多了代码写得多了，你会发现编码过程中会不时用到其他人的成果，一个项目下来多少会引入一些优秀的库，别人放在公网上开源的DLL，以及一些算法等等。细心的你会注意到即使只是一小段代码，优秀的作者都在最开始会简单地附上一段关于许可的声明，或者说是协议比如"Licensed under the MIT license"，并且一些博客也会标明"此文章发表在CC协议下"。而如果我们Copy了别人的代码或者文字同时没注意这些的话，在国外法律意识特别强的环境下，我们的作品会因触犯别人的权益而违法。因为好多开源协议最低要求是使用者需要保留原作者对代码的声明，不声不响地就拿来用了必然导致恶果。

所以开源不等于免费，开源也不等于没有约束。

何为License

License是软件的授权许可，里面详尽表述了你获得代码后拥有的权利，可以对别人的作品进行何种操作，何种操作又是被禁止的。软件协议可分为开源和商业。当然本文要讨论的当然是开源协议。

对于商业协议，或者叫法律声明、许可协议，每个软件会有自己的一套行文，由软件作者或专门律师撰写。这是什么惊为天人的东西嘛还得请专门的律师。因为涉及到以后侵权打官司这种事情，这种商业条款的行文是非常严谨而讲究的，记得以前看到句调侃的话：'如果法律文件不写得那么生涩难懂，律师们就没饭吃了'，就是说任何文字一旦上升到法律的层次，不要说你接受完了九年义务教育，就是考了个专八也会觉得英语白学了，直接的法律协议什么的那不是给常人看的。而至于法律条款缘何会晦涩难懂，这个偏题有点偏远了，可以查看这里了解。看累了？下面是欢乐时刻，奉上一个协议相关的Joke（笑崩！苹果iOS7升级协议条款中员工神吐槽）。

你丫知道么？这已经是46页，肯定没人读的。我敢打赌大概只有5个人点了"条款和协议"，所以我们想扯点啥就扯点啥吧。 Apple总部5楼的那个tony总是浑身一股沙丁鱼味 有人给我们寄点啥2b向的邮件，我们都得很文艺的用"i笑了"的方式回复。这是我们的工作规定 还记得当年关于Apple Studio的版权合法性争议么？想知道我们怎么摆平的？我们把披头士乐队买下来了。他们中活着的现在没事来给我们唱两曲解解闷，死了的，我们想办法像Miku的3D投影那样，设法在二次元给他们来个复活 我们餐厅永远只卖苹果东西：苹果，苹果汁，苹果煎饼，苹果棒糖。。。不想丢工作的话我们只能吃这些，而哥恰好对苹果过敏，哥现在正处于饿的神志不清乱敲键盘的节奏。 我们伪造了登月真相。其实美国人登月是2008年的事情，我们向你们洗脑它发生在1969，我们绝对有这种洗脑的本事。如果有人发现我知道的太多了，我就会被查水表，但是没关系，没人会看这页。

 

所以对于大多数人来说，不用自己花大把时间去写许可协议，选择一分广为流传的开源协议是个不错的选择，如果你的作品是开源的话，这样省时又省心。

选择一分协议的好处

你的作品如果不是定性为全商业性质，可以考虑选择一分流行度比较高的开源协议。具体来说的话，你肯定希望作品能够被多数人分享查阅吧，不但提高自己业界的知名度，同时也方便了需要的人为开源做出了贡献。换句话说，你不分享出来的话你的作品的意义何在呢（当然，自己捣腾的私人东西还是自己保留吧）？可是一旦你把你的代码贴出来，这就表示任何人都可以看到并获取，之后发生的事情你无法控制，有的人或许稍微修改一下放进自己的代码中，有的把你的软件改个名字拿去贩卖，有的甚至会拿去把作者名字改为自己然后拿去找工作什么的，而不会有人知道这个作品的原作者，背后辛勤付出了的人。所以为了公开分享你的代码，同时又让你对代码保留一定权利，在作品中声明一个许可协议是非常有必要的，这是很多新人所忽略的问题，同时很多人在使用别人的劳动成果时也会忽视协议的存在，这样不好。所以你会看到我的博客里面时不时会给出连接指向来源页面，同时文末也会列出所有参考过的文章。我相信我做到了这点，别人在转载我的文章的时候，也可以做到这点，这样营造出来的氛围一定会非常和谐，互相尊重/Show Respect。

多说一句，一个事实让你了解国外开发者在尊重他人劳动成果方面做得是如何的到位，如果A的作品是因为B的作品的启发而来，A甚至都没有使用B任何一句代码，但A会在他的作品里面指明是受到了B的启发"Inspired by XXX link :http://www.blah.com"。

当然有人会觉得，有了一分协议声明在那里，我就需要鸟你么，我拿来用了把作者名字去掉同时还要加上我的名字，你咬我？！这是后话，只是在利益很小的情况下，或者作者不知情的情况下，作者不会追究什么责任，但如果你的产品做成功了，那就不一定了。另外就是，有协议和没声明协议的裸代码是有非常重要区别的，一般作品当中没声明协议的默认为Copy right的，也就是版权保留。此种情况表明他人没有任何授权，不得复制分发修改使用等等，但一如上面所讨论的，这样的话还何来开源，何来分享呢。有了协议的声明，在未来你的维权上面会方便很多，让你的作品在分享的同时保留了自身的一些权利。

快速选择

目前流行的开源协议有很多，并且同一款协议有很多变种，比如你或许看到过' CC Attribution-NoDerivs',' CC Attribution-NonCommercial'同属CC协议（后面会有介绍）。如此纷繁的协议该如何选择？协议太宽松会导致作者丧失对作品的很多权利，太严格又不便于使用者使用及作品的传播。所以除了协议多之外，你还要考虑你对作品想保留哪些权利，放开哪些限制。

如果你不想了解太多，只是想要一个简直直接的答案，下面给出的建议或许适合你。下方关于协议的选择及表格来自GitHub choosealicence项目。

简单宽松的协议

如果你只想要一个简单点的协议不想太麻烦的话。

MIT协议相对宽松但还是抓住了要点的。此协议允许别人以任何方式使用你的代码同时署名原作者，但原作者不承担代码使用后的风险，当然也没有技术支持的义务。jQuery和Rails就是MIT协议。

考虑有专利的情况

如果你的作品中涉及到专利相关。

Apache协议也是个相对宽松与MIT类似的协议，但它简单指明了作品归属者对用户专利上的一些授权（我的理解是软件作品中含有专利，但它授权你可以免费使用）。Apache服务器，SVN还有NuGet等是使用的Apache协议。

代码分享与促进

如果你在乎作品的传播和别人的修改，希望别人也以相同的协议分享出来。

GPL（V2或V3）是一种版本自由的协议（可以参照copy right来理解，后者是版本保留，那copyleft便是版权自由，或者无版权，但无版权不代表你可以不遵守软件中声明的协议）。此协议要求代码分发者或者以此代码为基础开发出来的衍生作品需要以同样的协议来发布。此协议的版本3与版本2相近，只是多3中加了条对于不支持修改后代码运行的硬件的限制（没太明白此句话的内涵）。

各协议授权详情

下面是更多开源协议的一个表格任君选择，总有一款是你的菜。

不过先来了解一些下方表格中出现的用词的解释：

• 协议和版权信息(License and copyright notice)：在代码中保留作者提供的协议和版权信息
• 声明变更(State Changes)：在代码中声明对原来代码的重大修改及变更
• 公开源码(Disclose Source)：代码必需公开。如果是基于LGPL协议 下，则只需使用的开源代码公开，不必将整个软件源码公开
• 库引用(Library usage)：该库可以用于商业软件中
• 责任承担(Hold Liable)：代码的作者承担代码使用后的风险及产生的后果
• 商标使用(Use Trademark)：可以使用作者的姓名，作品的Logo，或商标
• 附加协议(Sublicensing)：允许在软件分发传播过程中附加上原来没有的协议条款等

协议	描述	要求	允许	禁止
Apache	一个较宽松且简明地指出了专利授权的协议。	协议和版权信息 声明变更	商用 分发 修改 专利授权 私用 附加协议	责任承担（禁止让作者承担责任，可以理解为免责） 商标使用
GPL	此协议是应用最为广泛的开源协议，拥有较强的版权自由( copyleft )要求。衍生代码的分发需开源并且也要遵守此协议。此协议有许多变种，不同变种的要求略有不同。	公开源码 协议和版权信息 声明变更	商用 分发 修改 专利授权 私用	责任承担 附加协议
MIT	宽松简单且精要的一个协议。在适当标明来源及免责的情况下，它允许你对代码进行任何形式的使用。	协议和版权信息	商用 分发 修改 私用 附加协议	责任承担
Artistic	Perl社区尤为钟爱此协议。要求更改后的软件不能影响原软件的使用。	协议和版权信息 声明变更	商用 分发 修改 私用 附加协议	责任承担 商标使用
BSD	较为宽松的协议，包含两个变种BSD 2-Clause 和BSD 3-Clause，两者都与MIT协议只存在细微差异。	协议和版权信息	商用 分发 修改 私用 附加协议	责任承担
Eclipse	对商用非常友好的一种协议，可以用于软件的商业授权。包含对专利的优雅授权，并且也可以对相关代码应用商业协议。	公开源码 协议和版权信息	商用 分发 修改 专利授权 私用 附加协议	责任承担
LGPL	主要用于一些代码库。衍生代码可以以此协议发布（言下之意你可以用其他协议），但与此协议相关的代码必需遵循此协议。	公开源码 库引用 协议和版权信息	商用 分发 修改 专利授权 私用 附加协议	责任承担
Mozilla	Mozilla Public License(MPL 2.0)是由Mozilla基金创建维护的。此协议旨在较为宽松的BSD协议和更加互惠的GPL协议中寻找一个折衷点。	公开源码 协议和版权信息	商用 分发 修改 专利授权 私用 附加协议	责任承担 商标使用
No license	你保留所有权利，不允许他人分发，复制或者创造衍生物。当你将代码发表在一些网站上时需要遵守该网站的协议，此协议可能包含了一些对你劳动成果的授权许可。比如你将代码发布到GitHub，那么你就必需同意别人可以查看和Fork你的代码。	协议和版权信息	商用 私用	分发 修改 附加协议
Public domain dedication	在许多国家，默认版权归作者自动拥有，所以Unlicense协议提供了一种通用的模板，此协议表明你放弃版权，将劳动成果无私贡献出来。你将丧失对作品的全部权利，包括在MIT/X11中定义的无担保权利。	N/A	商用 分发 修改 私用	责任承担

 

非代码类作品的协议

上面各协议只是针对软件或代码作品，如果你的作品不是代码，比如视频，音乐，图片，文章等，共享于公众之前，也最好声明一下协议以保证自己的权益不被侵犯。针对非代码的数字作品的协议，最通用的莫过于Creative Commons(也是你经常在别人博客下面可以看到的CC协议)协议。所以现在你见到博客园别人文章下面的签名就不会感到陌生了。

 

无协议

你没有义务也没人非要你必需在自己的代码作品里面加上一个开源协议。但一如上文所讨论过的优点，如果你想把代码分享出来，最好还是选择一个适合的开源协议，这样别人用着放心。

 

出处： http://baike.baidu.com/link?url=31W-VzhlcYrTqmSdnO_69Ep9F0mPBVxPJMgLEvoxW65nYMiBbzOeAbFerhbEU7riqJlKdo7f07VbUrVUexcryK

开源协议

  编辑

本词条缺少 名片图，补充相关内容使词条更完整，还能快速升级，赶紧来 编辑吧！

LGPL许可证是LESSER GENERAL PUBLIC LICENSE的简写，也叫LIBRARY GENERAL PUBLIC LICENSE，中文译为“较宽松公共许可证”或者“函数库公共许可证”。该许可证适用于一些由 自由软件基金会与其它决定使用此许可证的软件作者所特殊设计的软件软件包─比如函数库（即Library）。

中文名

开源协议

外文名

LESSER GENERAL PUBLIC LICENSE的

别    名

LGPL许可证

例    如

函数库

目录

1. 1 简介
2. 2 MPL
3. 3 BSD
4. 4 QPL
5. 5 QNCL

1. 6 Jab
2. 7 Com
3. 8 IBM
4. 9 协议比较
5. ▪ BSD

1. ▪ AL2.0
2. ▪ GPL
3. ▪ LGPL
4. ▪ MIT

简介

编辑

除了大家比较熟悉的 GPL协议之外，开源界还有很多许可证，如 LGPL许可证、 BSD许可证等，下面就来一一介绍。

LGPL许可证，也是自由软件联盟 GNU开源软件许可证的一种，大部分的  GNU软件，包括一些函数库，是受到原来的 GPL许可证保护的。而LGPL许可证，适用于特殊设计的函数库，且与原来的通用公共许可证有很大的不同，给予了被许可人较为宽松的权利，所以叫“较宽松公共许可证”。在特定的函数库中使用它，以准许非自由的程序可以与这些函数库连结。

当一个程序与一个函数库连结，不论是 静态连结或使用共享函数库，二者的结合可以合理地说是结合的作品，一个原来的函数库的衍生品。因此，原来的通用公共许可证只有在整个结合品满足其自由的标准时，才允许连结。较宽松通用公共许可则以更宽松的标准允许其它程序代码与本函数库连结。例如，在少数情况下，可能会有特殊的需要而鼓励大家尽可能广泛地使用特定的函数库，因而使它成为实际上的标准。为了达到此目标，必须允许非自由的程序使用此函数库。一个较常发生的情况是，一个自由的函数库与一个被广泛使用的非自由函数库做相同的工作，在此情况下，限制只有自由软件可以使用此自由函数库不会有多少好处，故我们使用了 LGPL许可证。

在其他情况下，允许非自由程序使用特定的函数库，可以让更多的人们使用 自由软件的大部分。例如，允许非自由程序使用GNU C函数库，可以让更多的人们使用整个 GNU作业系统，以及它的变形， GNU/Linux操作系统。

尽管LGPL许可证对使用者的自由保护是较少的，但它却能确保与此函数库连结的程序的使用者拥有自由，而且具有使用修改过的函数库版本来执行该程序的必要方法。

MPL

编辑

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条有专门的一款是关于对 源代码修改进行描述的规定，就是要求所有再发布者都得有一个专门的文件就对源代码程序修改的时间和修改的方式有描述。

BSD

编辑

BSD许可证原先是用在加州大学柏克利分校发表的各个4.4BSD/4.4BSD-Lite版本上面（BSD是Berkly Software Distribution的简写）的，后来也就逐渐沿用下来。1979年加州大学伯克利分校发布了BSD Unix，被称为 开放源代码的先驱，BSD许可证就是随着BSD Unix发展起来的。 BSD许可证被 Apache和 BSD操作系统等开源软件所采纳。

相较于 GPL许可证和MPL许可证的严格性，BSD许可证就宽松许多了，一样是只需要附上许可证的原文，不过比较有趣的是，它还要求所有进一步开发者将自己的版权资料放上去，所以拿到以BSD许可证发行的软件可能会遇到一个小状况，就是这些版权资料许可证占的空间比程序还大。

QPL

编辑

QPL是The Qt Public License的简称，是挪威一家机构创设的。QPL许可证的基本要求是获得 源代码、修改源代码，并可将修改从原始代码中分离出来;修改可以按照作者的意愿被组合到新版本中; 二进制代码可以和原始代码同名，这一点对于 动态连接库来说尤其重要;任何人都可以修正错误，这对于系统的发布者来说很关键;修改过的软件可以按照满足QPL许可证基本要求的任何开源软件许可证进行发布。

QNCL

编辑

QNCL许可证是Qt Non Commercial License的简称，是QPL许可证的“兄弟版”，就像 GPL许可证与 LGPL许可证的关系一样， QNCL许可证比QPL许可证更严格一些。

在修改和发布方面的规定，QNCL许可证与QPL许可证是一样的，差异就在于软件的范围方面，或者说在连接方面。QNCL许可证规定“假如一个应用程序给你提供了一个入口，使你有权使用QNCL许可证下的软件的功能开发程序、重复使用程序的某一部分或其他软件的某一部分，那么对该应用程序的使用视为是使用QNCL许可证下的软件的行为，该应用程序应受到QNCL许可证的约束”。QNCL许可证比QPL许可证更严格之处在于， QNCL许可证像 GPL许可证那样，完全禁止根据本许可证得到的 开放源码软件与其他非系统库函数连接的软件以其他许可方式一起发布。

Jab

编辑

Jabber许可证的全称是Jabber Open Source License，由美国Jabber.Com, Inc.公司提供。 Jabber许可证在 源代码的复制、发行规定方面基本上和其他许可证没有什么特别，但有一些细节规定值得借鉴:

◆ 可以将通过该许可证获得的源代码及修改过的源代码与其他类型的不受该许可证约束的代码结合，以新产品的形式发布，只要其中经该许可证获得的源代码及修改过的源代码能以与该许可证的要求类似的、符合OSI认证的其他开源软件许可证的方式发布。

◆ 明确了需将源代码置于公众可以得到的状态的时间至少应为12个月。

◆ 第三方对法定权利的声明。假如使用者发现通过本许可证获得的 源代码及 应用程序接口中有一方拥有的知识产权，应单独在 源码的发布时冠以“LEGAL”为抬头的声明，写明知识产权权利要求的细节，提请源代码的接受者知道自己获得了哪些知识产权的授权，让源码的接受者知道如何与知识产权权利人联系。

◆ 细化了该许可证终止的情形，包括不按该许可证的要求发布和使用源代码、发生 专利侵权诉讼。

Com

编辑

◆ 规定可以将 源代码及修改过的源代码与其他类型的不受本许可证约束的代码结合，以新产品的形式发布，只要其中经该许可证获得的源代码及修改过的源代码能按该许可证的要求发布即可。

◆ 细化了该许可证终止的情形，包括发生 专利侵权诉讼。

◆ 明确了一个独立承担责任的原则，就是假如按该许可证使用源代码的使用者将获得的源代码应用于商业使用，那么他就要对在商业应用中出现的由于使用该源代码程序而产生的侵权诉讼承担完全责任。这一条规定是比较特殊的，绝大多数开源软件许可证都不这么要求。

IBM

编辑

IBM许可证的全称是IBM Public License。在满足OSIA开源软件许可证认证标准的前提下， IBM许可证还有如下一些细节性规定:

◆ 明确了 专利授权。一般的开源软件都明确源代码的版权人将自己的修改权、 复制权等版权权利向公众许可，但保留 署名权，而IBM许可证在此基础上还明确假如源代码中含有 专利权，源代码 专利权人将复制、使用的专有权利向公众许可。

◆ 细化了该许可证终止的情形，包括不按该许可证的要求发布和使用源代码、发生 专利侵权诉讼等。

◆ 像 Common许可证一样，IBM许可证也明确了独立承担责任原则，即假如按该许可证使用源代码的使用者将获得的源代码应用于商业使用，那么他就要对在商业应用中出现的、由于使用该 源代码程序而产生的侵权 诉讼承担完全责任。

协议比较

编辑

BSD

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

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

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

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

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

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

AL2.0

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

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

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

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

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

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

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

MIT

MIT是和 BSD一样宽范的许可协议，作者只想保留版权，而无任何其它的限制。也就是说，你必须在你的发行版里包含原许可协议的声明，无论你是以 二进制发布的还是以 源代码发布的。 MIT协议又称麻省理工学院许可证，最初由麻省理工学院开发。被授权人权利：1、被授权人有权利使用、复制、修改、合并、出版发行、散布、再授权及贩售软件及软件的副本。2、被授权人可根据程式的需要修改授权条款为适当的内容。被授权人义务：在软件和软件的所有副本中都必须包含版权声明和许可声明。