常见开源协议比较

常见的开源协议及它们的适用范围

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也是对商业应用友好的许可。使用者也可以在需要的时候修

改代码来满足需要并作为开源或商业产品发布/销售。

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

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

MIT

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

的还是以源代码发布的.

CPAL

开源许可证——普通公共属性许可证

(Common Public Attribution License),本质上其是由Mozilla公共许可证(MPL)加入新的条款构成.该许可要求开发者对软件进行标记。

MPL

MPL是The Mozilla Public License的简写，是1998年初Netscape的Mozilla 小组为其开源软件项目设计的软件许可证。MPL License（Mozilla Public License）允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者。这种授

权维护了商业软件的利益，，它要求基于这种软件的修改无偿贡献版权给该软件。这样，围绕该软件的所有代码得版权都集中在发起开发人得手中。但MPL是允许

修改，无偿使用的。MPL软件对链接没有要求。(要求假如你修改了一个基于MPL

协议的源代码，则必须列入或公开你所做的修改，假如其他源代码不是基于MPL

则不需要公开其源代码)

MPL许可证出现的最重要原因就是，Netscape公司认为GPL许可证没有很好地平衡开发者对源代码的需求和他们利用源代码获得的利益。同著名的GPL许可

证和BSD许可证相比，MPL在许多权利与义务的约定方面与它们相同（因为都是符合OSIA认定的开源软件许可证）。但是，相比而言MPL还有以下几个显著的不同

之处:

◆MPL虽然要求对于经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来，以保证其他人可以在MPL的条款下共享源代码。但是，在MPL

许可证中对“发布”的定义是“以源代码方式发布的文件”，这就意味着MPL允许一个企业在自己已有的源代码库上加一个接口，除了接口程序的源代码以MPL许

可证的形式对外许可外，源代码库中的源代码就可以不用MPL许可证的方式强制

对外许可。这些，就为借鉴别人的源代码用做自己商业软件开发的行为留了一个

豁口。

◆MPL许可证第三条第7款中允许被许可人将经过MPL许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序。

◆对软件专利的态度，MPL许可证不像GPL许可证那样明确表示反对软件专利，但是却明确要求源代码的提供者不能提供已经受专利保护的源代码（除非他

本人是专利权人，并书面向公众免费许可这些源代码），也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。

您在自己的作品上使用知识共享许可协议，并不意味着放弃您的著作权，而是在特定的条件下将您的部分权利授予公共领域内的使用者。哪些特定的条件呢？您可以在此处看到所有知识共享许可协议及其简单的介绍。所有的许可协议都要

求您以作者或者许可人的名义署名。您可以将以下的选项进行组合、搭配，由此

将构成我们的六套核心知识共享许可协议。

1、是否允许他人对自己享有著作权的作品及演绎作品进行复制、发行、展览、表演、放映、广播或通过信息网络向公众传播，但在这些过程中对方必须保

留您对原作品的署名。

2、是否允许他人对您享有著作权的作品及演绎作品进行复制、发行、展览、表演、放映、广播或通过信息网络向公众传播，但仅限于非商业性目的。

3、是否允许他人对您的作品原封不动地进行复制、发行、展览、表演、放映、广播或通过信息网络向公众传播，但不得进行演绎创作。

4、只有在他人对演绎作品使用与您的原作品相同的许可协议的情况下，您才允许他人发行其演绎作品。

QPL

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

Com

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

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

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

IBM

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

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

明确假如源代码中含有专利权，源代码专利权人将复制、使用的专有权利向公众许可。

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

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

Jab

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

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

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

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

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

Linux 开源协议

Linux 开源协议 现今存在的开源协议很多，而经过Open Source Initiative组织通过批准的开源协议目前有58种（https://www.sodocs.net/doc/b715409911.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 对开发开源软件的开发者们在权利上进行了周详的认可和保障。本质上讲，它允许用户对软件进行合法的拷贝，传播和修改。这意味着你可以： ?随意复制。 把它拷贝到你自己的服务器上、你的客户的服务器上、你自己的电脑上，基本上任 何你能想到的地方。对你拷贝的数量也没有任何限制。（译者按：中国人用盗版用 惯了，估计对这点会很不以为然。） ?随意传播。 在你的网站上做一个下载链接进行下载。拷贝到你的移动硬盘里送人。把原代码打 印出来，站在屋顶散发（最好别这样做，会浪费纸，而且影响环境清洁）。

授权合同范本(完整版)

合同编号：YT-FS-3660-18 授权合同范本(完整版) Clarify Each Clause Under The Cooperation Framework, And Formulate It According To The Agreement Reached By The Parties Through Consensus, Which Is Legally Binding On The Parties. 互惠互利共同繁荣 Mutual Benefit And Common Prosperity

授权合同范本(完整版) 备注：该合同书文本主要阐明合作框架下每个条款，并根据当事人一致协商达成协议，同时也明确各方的权利和义务，对当事人具有法律约束力而制定。文档可根据实际情况进行修改和使用。 企业的授权经营(licensing)实际是一种通过与其他被授权方企业签订有关技术、管理、销售、工程承包等方面的合约，取得对该企业的某种管理控制权。其需要签定许可证合同 1、许可证合同的含义 许可证合同，又称特许权合同，或技术授权。指授权方与被授权方签订合同，允许被授权方使用授权方独有的注册商标(trademark)、专利(patent)以及技术诀窍(know-how)等。 2、许可证合同的转让费用 在许可证合同中，被授权方应按合同约定的金额，向授权方支付专利权费(royalty)。该费有两种支付方式，即定额支付和比率支付。 3、许可证合同的限制性条款

授权方为了保护自身的利益，往往在许可证合同中加入一些限制性条款。这些条款主要有： ①产量及品质的限制。对利用授权的商标、专利和技术诀窍生产的产品产量水平进行限制，并为了保证产品的质量，授权方拥有对被授权方企业生产过程的监督权; ②产品销售地区的限制。授权方公司为了防止被授权方企业侵害自己在被授权方以外地区的利益，通常在许可证合同中规定被授权方企业不得越区从事生产和销售活动; ③原材料、零部件采购的限制。在许可证合同中，授权方公司规定，被授权方企业生产被授权产品时，应从授权方公司或由其指定的供给商，购置所需的原材料和零部件。 酒类授权销售合同范本(1) 卖方： 买方： 为保护买卖双方的合法权益，买卖双方根据《中

apache2.0开源协议

竭诚为您提供优质文档/双击可除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协议和

授权合同协议书范本

编号：_____________授权合同 甲方：________________________________________________ 乙方：___________________________ 签订日期：_______年______月______日

甲方（单位）： 法定代表人： 乙方（员工）： 身份证号： 上述双方经平等自愿协商，签订本合同以共同遵守。 第1条合同主旨 乙方作为甲方人员，在职权范围内享有一定权利和义务，双方就权利义务进行约定。 第2条材料保管 2.1 甲方将相关物品移交给乙方保管，具体以附件“材料移交清单”为准。 2.2 乙方应妥善保管相关物品；如乙方委托或转交其它人员保管，仍应由乙方对保管负责。 2.3 甲方有权随时要求乙方全部或部分归还相关物品。归还物品时，甲方或甲方指派的人员应进行签收，签收单作为乙方归还上述物品的依据。 第3条授权范围 3.1 乙方职权范围为以下所列： 3.1.1 。 3.1.2 。 上述职权范围内的事宜，乙方有权处理，并相应使用公章及证照对外签约。本合同另有特别约定的，应首先遵守特别约定。

3.2 乙方行使职权时，应同时遵守下列约定： 3.2.1 涉及金额或价值超过元的，或导致甲方（或分公司）承担责任可能超过该标准的，需经总经理书面批准。 如果数项业务为一个整体或同一类，应该合并计算金额。 3.2.2 公司总经理或乙方上级要求乙方必须事先获得批准的，应按该要求执行。 3.2.3 公司制度对审批流程有规定的，应执行该规定。 3.2.4 公章仅限在乙方所在部门或分支机构的经营及活动范围内的合同及文件上使用，并不得代表甲方对外签署合同、作出担保/承诺及签署其它文件。 3.2.5 如乙方对职权范围或授权范围存在疑问的，可向甲方总经理询问，由甲方总经理进行解释。 3.3 乙方违反上述限制或超出职权范围的签章，甲方有权不予认可，对外不发生法律效力；导致甲方受到损失的，应由乙方自行承担责任。 第4条乙方下属人员管理 4.1 乙方职权范围内下属人员的聘用，由乙方提名并建议其薪资标准，报经甲方总经理批准后，由甲方人事部门负责签订劳动合同。 4.2 乙方不得私自聘用人员。乙方未经上述程序私自聘用人员，造成甲方损失的，乙方应承担赔偿责任。 第5条双方其它权利义务 5.1 甲方权利义务 5.1.1 甲方有权随时单方面决定对保管范围、授权范围、授权期限等进行变更；有权随时通知收回由乙方保管的公章、营业执照、公司章程等证照或文件。

网络授权合同书范本专业版(合同范本)

网络授权合同书范本专业版 (合同范本) Effectively restrain the parties’ actions and ensure that the legitimate rights and interests of the state, collectives and individuals are not harmed ( 合同范本 ) 甲方：______________________ 乙方：______________________ 日期：_______年_____月_____日 编号：MZ-HT-045241

网络授权合同书范本专业版(合同范本) 甲方： 法定代表人： 地址： 电话： 邮箱： 乙方： 法定代表人： 地址： 电话： 邮箱： 甲方授权乙方在网络店铺销售产品并提供服务，双方在平等互利、共同发展、诚实信用的原则下，经充分协商签订本协议。

一、授权 甲方在合同有效期内授权乙方为本合同产品的网络销售商，负责网络销售工作。 二、甲方的责任和义务 1、甲方保证是中国境内的合法经营者，已经取得国家法定部门颁发的营业执照和其它必要的销售许可。本合同须加盖合同双方的公章并由双方法人代表或受法人代表委托的代理人签字，代理人签署时必须出具法人代表授权委托书。 2、甲方授权乙方代理网络销售服务的产品必须与甲方提交的图片、质量、品种、规格等说明完全一致。结算价格如有变动，甲方须在_____个工作日内通知乙方。 3、甲方需及时通过网络或电话等通讯手段通知乙方上架新商品、下架缺货商品。 三、乙方的义务和权利 1、乙方承诺尽力通过自己的互联网资源推广甲方正面形象、合理的商务信息和网络销售服务的甲方商品。

开源协议

开源界的 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

授权合同范本

授权合同范本 甲方： 乙方： 为使甲方xxxxx产品全面推向市场，取得良好的社会效益和经济效益，双方本着合法、公正、互利、协商一致的原则，签订本合同书，以资双方信守。 一、代理产品，区域、期限： 1、代理产品名称： 2、代理区域：辖区范围内 3、代理期限：年，自本协议签订之日起至年月日止，合同期满后，双方中意可续约，在同等条件下，乙方有优先代理权。 二、双方责任、权利： （一）甲方： 1、自本协议签订之日起，乙方成为甲方在市场销售合法总代理商，甲方别得在乙方代理区域内另设总代理商。 2、甲方根据本合同之约定治理乙方代理区域的经营活动，协助乙方做好区域内营销推广工作。 3、甲方保证乙方货款到账12小时内发出货品（特殊订货除外），并保证产品长期供应。 4、甲方提供相关的产品证书和文件资料等。 5、甲方保证产品质量，对产品实行三个月内包换，一年保修，终身维护的质保答应。 6、甲方积极配合乙方进行销售人员的业务技能培训。 7、甲方授于乙方“代理授权书”并享受调价时的库存差价补偿与其它优惠措施。 （二）乙方责任、权利： 1、乙方应依照当地实际事情自行完善经营甲方产品的各项手续。 2、乙方在授权区域内依法经营，仔细负责地完成甲方授权代理事项，做好销售工作，因乙方别依法经营，违反代理协议书而造成的一切经济损失，由乙方承担。 3、乙方必须贯彻，融汇甲方营销理念，同意甲方的业务培训，服从甲方的营销指导及考核。 4、乙方必须具备一批高素养的销售人员，在所属区域内，建立自己的销售络，与甲方并且进行络化经营，并经常性，有针对性开展一系列的促销宣传活动。 5、协议生效后，乙方能够以甲方总代理或办事处的名义对外宣传。 6、乙方负责在代理区域内本产品的广告宣传及费用，设计光盘由甲方提供，依法办理产品有关宣传手续，做到合法经营。 三、总代理商从事的业务范围： 1、区域内二级代理商的建立。 2、区域内零售市场的建设，以及产品的批发，终端销售。 3、紧密与工程商合作，或与房地产商及需求单位直接合作。 4、经常进行宣传促销活动。 四、代理条件： 1、乙方必须是注册合法的公司或经营单位，具有固定的经营场所，有一定的市场经营络。 2、乙方必须向甲方提供企业有关资质（企业营业执照、工程施工资质证、销售许可证）。 3、乙方必须完成甲方对其区域规定的首批进货额，季度进货额。 4、签约后，乙方在半年内必须完成（50%以上）区域内的市场营销络建设， 5、乙方与区域内代理商，二级经销商等所签订的合作协议由甲方、乙方、经销方三方

开源许可协议

开源许可协议 （初稿） 河南新创元信息网络有限公司 研发部 文档修订历史记录

目录 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/b715409911.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) ，该协议有可能是

各种开源协议说明(License)

各种开源协议说明 许多开发者和设计者希望把他们的作品作为开源项目共享，他们希望其他人能够利用和共享他们的代码。而各种开源社区就是因为这个原因而充满活力。开源软件可以用于你能想象得到的任何应用程序，许多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，这个协议除了为用户提供版权许可之外，还有专利许

授权协议书范本

授权协议书 协议代码： 甲方： 乙方： 经甲乙双方友好协商，就甲方授权乙方为职业技能鉴定考试培训点一事达成如下协议： 一、合作双方： 1、甲方，是政府认可的职业技能鉴定机构。 2、乙方，是符合设立考试培训点要求的教学机构。 二、关于合作： 1、合作项目：甲方开发的所有职业技能鉴定项目。 2、合作期限：自本协议签订之日起至 2010年 12 月 30 日止。 3、合作名义：全国职业资格考试认证中心###考试培训管理处。 4、合作限制：乙方不得到甲方已授权的高校内部或甲方已独家授权的地区从事招生工作。 三、甲方的责任： 1、负责证书的合法性。向乙方提供国家职业标准或考试大纲。 2、建立教材库、师资库和题库，免费提供海报、传单、报名表等相关材料。 3、发放准考证、组织命题、组织考试、组织评分阅卷，颁发职业资格证书。 4、建立国家职业资格考试网(https://www.sodocs.net/doc/b715409911.html,)，提供证书查询及发布相关信息的平台。 四、乙方的责任 1、乙方自主招生，自负盈亏。 2、组织学员报名并提供考前培训。

3、安排学员参加甲方鉴定项目的统一考试。 4、招生项目、聘用教师、所选教材需及时向甲方备案 5、乙方开展工作时所发生的纠纷或事故由乙方自行解决，甲方不承担任何法律责任。 五、双方收支分配 1、甲乙双方的收支分配标准由双方根据具体情况具体协商。 2、乙方依据甲方《关于全国考试认证统一收费标准的通知》的规定，进行适当调整后定相应收费标准。 3、如有特殊原因，乙方请甲方安排师资授课的话，乙方只承担授课教师的路费和讲课金。 六、其他事项：甲乙双方就履行本协议发生纠纷，应通过协商解决;协商不成的，依法向甲方所在地的人民法院起诉。 七、未尽事宜，双方另行协商。本协议一式两份，甲乙双方各执一份。 甲方：乙方： 代表：代表： 日期：日期：

五种常见软件开源协议介绍-GPL、LGPL、BSD、Apache、MIT

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构成更改。

用户授权协议范本(标准版)2020

编号：HL202047516 用户授权协议范本(标准版)2020 The content of this contract is only a reference for both parties. You must read the listed terms carefully when using it. The content of the contract will be adjusted according to the actual situation of both parties and should not be directly applied. 甲方：_______________________ 乙方：_______________________ 签订日期：_____年____月_____日

用户授权协议 《用户授权协议》（以下简称“本协议”）是______________（中国）网络技术有限公司（以下简称“______________”）与用户（以下简称“您”）所订立的有效合约。您通过网络页面点击确认或以其他方式选择接受本协议，即表 示您与______________已达成协议并同意接受本协议的全部约定内容。 在接受本协议之前，请您仔细阅读本协议的全部内容（特别是以粗体下划 线标注的内容）。如您不同意本协议的内容，或无法准确理解本协议任何条款 的含义，请不要进行确认及后续操作。如果您对本协议有疑问的，请通过 ______________客服渠道进行询问，其将向您解释。 1、您授权______________将您的______________账户/会员号及相关信息等传递给第三方，用于第三方为您提供服务。页面提示上可能会展示具体授权对象、授权字段名称、范围等，授权字段通过加密通道传递给第三方。______________会要求该第三方依法使用您的上述信息，并应对您的信息保密。 2、您理解，______________是中立平台的提供者，第三方服务由该第三方 独立运营并独立承担全部责任。因该第三方服务或其使用您的信息产生的纠纷，或第三方服务违反相关法律法规或本协议约定，或您在使用第三方服务过程中 遭受的损失，请您和第三方协商解决。

开源许可协议说明

开源许可协议说明 如今开源的软件已经越来越被广泛使用，各种专利纠纷也越来越多。工作上要求对开源协议的理解也很迫切，做技术架构是每一个技术人员最渴望的职责，但要做好初级的技术架构工作首先要对各种各样的开源协议有深入了解，知道什么开源软件是工作在什么协议之下，对自己的产品有什么影响。这篇博文将讲解开源协议的相关知识。 首先要弄懂一些基本概念： 1 什么是许可协议？ 什么是许可，当你为你的产品签发许可，你是在出让自己的权利，不过，你仍然拥有版权和专利（如果申请了的话），许可的目的是，向使用你产品的人提供一定的权限。 不管产品是免费向公众分发，还是出售，制定一份许可协议非常有用，否则，对于前者，你相当于放弃了自己所有的权利，任何人都没有义务表明你的原始作者身份，对于后者，你将不得不花费比开发更多的精力用来逐个处理用户的授权问题。 而开源技术许可协议使这些事情变得简单，开发者很容易向一个项目贡献自己的代码，它还可以保护你原始作者的身份，使你至少获得认可，开源许可协议还可以阻止其它人将某个产品据为己有。 2. 常用开源协议 GPL(GNU General Public License) 我们很熟悉的Linux就是采用了GPL。GPL协议和BSD，Apache Licence等鼓励代码重用的 许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux，包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。 GPL协议的主要内容是只要在一个软件中使用(”使用”指类库引用，修改后的代码或者衍生代码)GPL协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题，还可以享受免费的优势。GPL协议最主要的几个原则：

授权协议书范本通用版

授权协议书范本通用版 Effectively restrain the parties’ actions and ensure that the legitimate rights and interests of the state, collectives and individuals are not harmed ( 协议范本 ) 甲方：______________________ 乙方：______________________ 日期：_______年_____月_____日 编号：MZ-HT-025330

授权协议书范本通用版 授权协议书范本（一） 委托人：;身份证号码：;联系电话. 受托人：;身份证号码：；联系电话. 就中关村证券股份有限公司行政清理工作组（以下简称“中关村证券清理组”）个人债权人申报登记债权的事宜，委托人对受托人授权如下： 1、授权受托人代理委托人向中关村证券清理组提交并接收申报债权的有关资料； 2、授权受托人代理委托人根据《中关村证券股份有限公司债权登记公告》的规定办理向中关村证券清理组申报登记债权的其他事宜。 本授权委托书自委托人签字之日生效。

委托人（签字）： 受托人（签字）： 年月日 授权协议书范本（二） 委托人：姓名__________性别___年龄____身份证编号 ________________ 受托人：姓名__________性别____年龄____身份证编号 ________________ 兹委托受托人____________为我的代理人，全权代表我办理下列事项： 一、************** 二、************** 代理人在其权限范围内签署的一切有关文件，我均予承认，()由此在法律上产生的权利、义务均由委托人享有和承担。 代理人有（或无）转委托权。 委托人：（签名或盖章）

授权委托协议书范本

授权委托协议书范本 授权方： 地址： 法定代表人： 被授权方： 地址： 法定代表人： 营业执照号： 一，授权依据 本授权委托书依据上述双方于________年____月____日共同签署并已生效的（填写合同编号，名称）出具。 二，授权范围 （一）授权的地域范围 本《授权委托书》只适用于省市范围内办理授权事项之用，超越授权地域范围使用本《授权委托书》均属无效使用，不对授权方产生任何法律效力，一切后果由被授权方自行承担。 （二）授权的事项范围 授权方兹授权被授权方在授权地域范围内从事如下事项： （详细按照授权依据上的授权事项进行填写） 在上述授权事项范围内，被授权方通过合法方式代表授权方从事活动的，其法律后果方由授权方承担，否则被授权方任何超越授权事项行事或以不合法的方式行事的，产生的一切后果概由被授权方自行承担。 三，授权期限 1，本授权委托书的有效期为年，自至止。 2，授权方在授权期限内合法提前撤销授权的，授权亦自行终止，本《授权委托书》失效。 3，授权期限到期，本《授权委托书》失效。 授权期限到期或授权被授权方提前撤销后，被授权方仍以授权方名义行事的，对授权方不产生任何法律效力，一切后果由被授权单位自行承担。 四，其他 1，本《授权委托书》自授权期限开始之日起生效。 2，本《授权委托书》一式二份，双方各持一份，均具有同等法律效力。 3，本《授权委托书》未尽事宜，按双方签署的（就是填写授权依据）执行。 4，本《授权委托书》不得擅自转借，涂改或复印，否则无效。 5，本《授权委托书》失效后，被授权方需将《授权委托书》退回授权方。 授权方：（盖章） ________年____月____日

nginx,开源协议

竭诚为您提供优质文档/双击可除 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

开源软件授权协议详解(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软件对链接没有要求。