开源软件协议列表
几种常见的开源软件许可协议（GPL,LGPL,ApacheLicense,BSD）
⼏种常见的开源软件许可协议（GPL,LGPL,ApacheLicense,BSD）GPLGPL授予程序接受⼈以下权利，或称“⾃由”：* 以任何⽬的运⾏此程序的⾃由* 以学习程序⼯作机理为⽬的，对程序进⾏修改的⾃由（能得到源代码是前提）* 再发⾏复制件的⾃由* 改进此程序，并公开发布改进的⾃由（能得到源代码是前提）相反地，随版权所有软件的最终⽤户许可证⼏乎从不授予⽤户任何权利（除了使⽤的权利），甚⾄可能限制法律允许的⾏为，⽐如逆向⼯程。
GPL与其他⼀些更“许可的”⾃由软件许可证（⽐如BSD许可证）相⽐，主要区别就在于GPL寻求确保上述⾃由能在复制件及演绎作品中得到保障。
它通过⼀种由Stallman发明的叫copyleft的法律机制实现，即要求GPL程序的演绎作品也要在GPL之下。
相反，BSD式的许可证并不禁⽌演绎作品变成版权所有软件。
GPL不会授予许可证接受⼈⽆限的权利。
再发⾏权的授予需要许可证接受⼈开放软件的源代码，及所有修改。
且复制件、修改版本，都必须以GPL为许可证。
这些要求就是copyleft，它的基础就是作品在法律上版权所有。
由于它版权所有，许可证接受⼈就⽆权进⾏修改和再发⾏（除合理使⽤），除⾮它有⼀个copyleft条款。
如果某⼈想⾏使通常被法律所禁⽌的权利，只需同意GPL的条款。
相反地，如果某⼈发⾏软件违反了GPL（⽐如不开放源代码），他就有可能被原作者起诉。
copyleft利⽤版权法来达到与其相反的⽬的：copyleft给⼈不可剥夺的权利，⽽不是版权法所规定的诸多限制。
这也是GPL被称作“被⿊的版权法”的原因。
许多GPL软件发⾏者都把源代码与可执⾏程序捆绑起来。
另⼀⽅式就是以物理介质（⽐如CD）为载体提供源代码。
在实践中，许多GPL软件都是在互联⽹上发⾏的，源代码也有许多可以FTP⽅式得到。
copyleft只在程序再发⾏时发⽣效⼒。
对软件的修改可以不公开或开放源代码，只要不发⾏。
注意copyleft只对软件有效⼒，⽽对软件的输出并⽆效⼒（除⾮输出的是软件本⾝）。
列举常见的开源协议简述其许可证的规则
列举常见的开源协议简述其许可证的规则常见的开源协议主要包括GNU通用公共许可证（GNU General Public License, GPL）、MIT许可证、BSD许可证、Apache许可证和Mozilla公共许可证等。
下面将对这些开源协议的许可证规则进行简述。
1.GNU通用公共许可证（GPL）GPL是最常用的开源协议之一，其主要目的是保护软件的使用者自由并鼓励共享。
GPL要求基于该许可证发布的软件及其衍生作品也必须采用GPL进行发布，即采用GPL许可证的软件只能使用GPL许可证进行分发，这也被称为“传染性”。
同时，GPL也要求对于对源代码所做的修改和衍生工作的发布都必须开放源代码，并明确指出软件的版权和许可证。
2.MIT许可证MIT许可证是一种相对较为宽松的开源许可证。
其核心条款要求将软件的版权和许可证信息包含在软件副本的所有拷贝或实质部分中。
这意味着在使用、复制、修改、合并、发布、分发、再许可及销售这些软件时，只需在源代码或二进制副本的所有拷贝中包含原始许可证即可，不需要开放源代码。
3.BSD许可证BSD许可证是一系列类似的许可证，如BSD 2-Clause License、BSD3-Clause License等。
这些许可证都较为宽松，允许使用、复制、修改、合并、发布、分发和再许可，同时要求在软件的所有拷贝、实质部分及相关文档中必须包含原始许可证的版权声明。
4. Apache许可证Apache许可证也是一种较为宽松的许可证，类似于BSD许可证。
除了允许使用、复制、修改、合并、发布、分发和再许可外，Apache许可证还要求在软件的所有拷贝中保留原始的版权声明和许可声明，并提供对源代码控制的访问。
5. Mozilla公共许可证Mozilla公共许可证是一种主要应用于Mozilla项目的开源许可证。
它对于源代码的控制较为严格，要求在任何衍生作品中都必须以MPL许可证进行发布。
同时，MPL还规定了衍生作品需要开放源代码，并明确指出版权和许可证。
列举常见的开源协议简述其许可证的规则
列举常见的开源协议简述其许可证的规则常见的开源协议有GNU通用公共许可证（GPL）、BSD许可证、MIT许可证、Apache许可证等。
接下来我将对这些协议进行逐一介绍，并简述其许可证规则。
1.GNU通用公共许可证（GPL）：GPL是一种针对自由软件的开源协议。
它强调在使用、复制、修改和分发软件时的自由。
根据GPL许可证规则，任何使用GPL软件的个人或组织都必须将其修改后的软件以同样的GPL许可证分发。
这意味着如果您使用了GPL许可证的软件而进行了修改，您必须对修改后的软件提供源代码，并允许其他人以任意方式使用、复制、修改和分发。
不允许将GPL软件与非自由软件结合使用。
2.BSD许可证：BSD许可证是一种相对宽松的许可证，允许用户以自由的方式使用、复制、修改和分发软件。
相比于GPL许可证，BSD许可证较少对软件的使用做限制，用户可以将BSD许可证软件与非自由软件结合。
BSD许可证规则要求在分发软件时必须包含原始的许可证和版权声明。
3.MIT许可证：MIT许可证也是一种宽松的开源许可证。
与BSD许可证类似，MIT许可证允许用户自由使用、复制、修改和分发软件，同时也允许将软件与非自由软件结合。
MIT许可证规则要求在分发软件时必须包含原始的许可证和版权声明。
4. Apache许可证：Apache许可证是一种被广泛使用的开源许可证，适用于多种类型的软件。
Apache许可证允许用户自由使用、复制、修改和分发软件，同时也允许将软件与非自由软件结合。
与BSD和MIT许可证类似，Apache许可证要求在分发软件时必须包含原始的许可证和版权声明。
需要注意的是，以上介绍的仅是常见的开源协议之一，实际上还有许多其他开源协议，每个协议都有其独特的许可证规则。
选择适合自己项目的开源协议时，需要仔细研究和理解相应的许可证规则，并确保符合规范进行软件的使用、复制、修改和分发。
几种常见开源版权的资料
几种常见开源版权的资料 现今存在的开源协议很多，而经过Open Source Initiative组织通过批准的开源协议目前有58种（）。
我们在常见的开源协议如BSD、GPL、LGPL、MIT等都是OSI批准的协议。
这里我们来看五种常用的开源协议及它们的适用范围，供大家参考。
BSDBSD开源协议（original B SD license、FreeBSD license、Original BSD license）BSD开源协议是一个给予使用者很大自由的协议。
基本上使用者可以“为所欲为”,可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。
但“为所欲为”的前提当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD 协议。
如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
BSD 代码鼓励代码共享，但需要尊重代码作者的著作权。
BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。
而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。
Apache LicenceApache Licence 2.0（Apache License, Version 2.0、Apache License, Version 1.1、Apache License, Version 1.0）Apache Licence是著名的非盈利开源组织Apache采用的协议。
该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。
开源协议的具体条款
开源协议的具体条款
开源协议是指一类软件授权协议，它允许其他人查阅、使用、修改、复制源代码、以及根据源代码创建的派生作品，而不需要经过原作者的特别授权。
此类协议通常是基于版权法律的，因此这些条款都非常重要，下面是具体的开源协议条款：
1. BSD协议
BSD协议有三种不同类型的条款：BSD-2，BSD-3和原始版本。
通常情况下，人们使用的是BSD-3条款，因为它对使用者的限制较少。
- 条件：必须包含版权声明和许可声明。
- 限制：无，使用者可以自由地使用、复制、修改和再分发代码。
2. GPL协议
GPL协议有两个版本：GPLv2和GPLv3。
GPLv3版本比早期版本更严格，它要求所有的派生作品都必须采用GPLv3发布。
- 条件：所有的派生作品必须使用GPL协议发布，并且包含相应的版权和执照信息。
- 限制：不允许闭源派生产品。
3. Apache协议
Apache协议的重点在于保护原作者的知识产权，以及保证使用者的免责和免责条款。
- 限制：对于使用者来说，没有具体的限制。
对于开发人员来说，必须声明他们所做的任何更改，以及在捐赠代码时必须遵守特定的规定。
4. MIT协议
MIT协议是一种非常宽松的开源许可协议，允许源代码和二进制代码被自由使用、修改和分发，而且无需要局限于特定的许可协议。
总体来说，无论使用哪种开源协议，都需要注意条款和限制条件。
开源协议的最终目标是保护原作者和使用者的利益，以便鼓励更多的合作和创新。
APL GPL等协议
许可协议BSD GPL MPL LGPL APL、MIT开源许可协议很多，这里说说他们的区别，以及使用相关代码需要考虑的协议约束。
、开源软件的授权许可都是基于开源许可协议的，常见的开源许可协议有GPL、LGPL、APL、BSD、MIT、Mozilla Public License、Creative Commons、Eclipse Public License 1.0等。
它们之前有很多相同的地方，也有很多不同的地方，本文将分析一下这些协议之间的区别。
GPL（GNU General Public License），使用源软件的类库引用（源代码）、改变（修改了源代码）的新软件，也必须采用GPL进行授权。
就是说，只要使用了GPL开源软件的源代码或拿它的源代码进行了修改而编写的新的软件，也必须加入到GPL的阵营。
很明显，不能拿GPL 授权的开源东东来做商业软件。
这个协议有个好处，就是极大增加了使用GPL的软件的数量。
采用GPL授权的软件有：Linux、MySQL等。
LGPL（Lesser GPL），相比GPL的严格，LGPL要温和很多。
可以通过引用类库的方式（不是直接使用源代码）拿LGPL授权的东东来重新开发商业软件。
如果是要修改源代码，是相应的修改和衍生出来的代码都要使用LGPL开放源代码。
采用LGPL的软件有：JBoss、Hibernate、FCKeditor等。
APL（apache Licence vesion 2.0），适用于商业软件，允许修改代码后再发布（不用开放源代码）。
采用APL的软件有Hadoop、Apache HttpServer等。
BSD（Berkeley Software Distribution），这个协议的要求很宽松，允许他人修改和重新发布代码，可以在此基础上开发出商业软件进行销售。
所以，此协议适用于商业软件。
采用BSD 协议的软件最著名的有nginx。
MIT（Massachusetts Institute of Technology），又称X11协议。
各种开源协议说明
各种开源协议说明开源协议是一种法律许可证，它规定了开放源代码软件的使用和分发条件。
这些协议确保了源代码的访问权，并且允许开发者修改和重新分发软件。
在详细介绍几种常见的开源协议前，值得注意的是，任何组织或个人使用开源软件时都应仔细阅读和理解相关协议的条款。
下面，我将介绍几种常见的开源协议。
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还规定了软件使用和分发方面的条款。
总的来说，开源协议以不同的形式和方式保障了开放源代码软件的自由和灵活性。
开发者可以根据自己的需求选择适合的开源许可证，以保护其软件的使用和分发权利。
然而，无论使用哪种开源许可证，都需要严格遵守相关协议的条款，以确保合法合规地使用和分发开源软件。
常见的开源协议
常见的开源协议开源协议甲方：（公司/个人名称）地址：（公司地址/个人地址）法定代表人/负责人：（姓名）联系方式：（电话/邮箱）乙方：（公司/个人名称）地址：（公司地址/个人地址）法定代表人/负责人：（姓名）联系方式：（电话/邮箱）双方身份甲方是（公司/个人名称）的所有者或授权管有该代码；乙方是使用该代码的用户。
权利甲方有权在遵守本协议的前提下授权乙方使用该代码；乙方有权使用该代码。
义务甲方必须保证该代码完全符合中国相关法律法规，并为代码质量负责；乙方必须遵守本协议的约定，并保证不侵犯相关法律法规及他人权益。
代码开放甲方授权乙方将该代码用于商业或非商业领域，但是乙方必须在此基础上保留原有版权和作者信息，禁止私自修改和传播。
履行方式甲方将该代码以开源形式发布于xxx 平台，乙方可自由下载使用，并在符合本协议的前提下进行修改。
期限该协议自双方签字之日起生效，有效期为永久。
违约责任若甲方违反本协议规定，乙方有权要求甲方承担相应的赔偿责任；若乙方违反本协议规定，甲方有权要求乙方承担相应的法律责任。
相关法律法规本协议遵守中华人民共和国的相关法律法规。
权利和义务双方有权相互要求对方履行本协议所规定的义务。
法律效力和可执行性本协议所规定的各项条款是符合中华人民共和国相关法律法规的，并具有律师的法律效力和可执行性。
其他如本协议中所未涉及的相关事项，双方应协商解决。
本协议一式两份，自双方签字盖章之日起生效。
甲方（签字/盖章）：乙方（签字/盖章）：日期：日期：。
常用的开源协议
以下是一些常用的开源协议：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基金会采用的一种开源许可证，允许用户使用、修改和分发软件，同时对于衍生作品也有特定的规定。
请注意，每种许可证都有其独特的条款和限制，因此在选择和使用开源软件时应仔细阅读和理解相关许可证的内容，并根据项目需求进行选择。
此外，由于法律和许可证可能会随时间而变化，请在使用开源软件前查阅最新的许可证版本和法律条文。
列举常见的开源协议、简述其许可证的规则
列举常见的开源协议、简述其许可证的规则
常见的开源协议包括：
1.GPL（GNU通用公共许可证）：该协议要求任何使用或修改代码的
人都必须以相同的许可证公开发行他们的代码。
因此，该类型的许可证被
称为“强的副本左协议”。
2.LGPL（GNU较宽松公共许可证）：该协议允许第三方使用和修改代
码的代码库，但并不要求他们为其代码的任何修改或衍生物公开发行。
3.MIT许可证：该许可证允许获得原始代码的任何人随意使用、修改、分发，甚至将其商业化，同时无需支付任何费用或遵守任何其他规则。
因此，MIT许可证被视为“非常宽松”的许可证之一。
4.BSD许可证：该许可证与MIT许可证非常相似，也允许获得原始代
码的任何人随意使用和修改，同时无需支付任何费用或遵守任何其他规则。
但与MIT许可证不同的是，BSD许可证还允许第三方使用代码库的商标。
5. Apache许可证：该许可证要求任何使用和修改代码的人都必须遵
守“反盗版”条款，以确保他们不会对代码进行意外篡改或破坏。
该许可
证还要求第三方声明他们所做的任何修改或衍生物，并给予原始代码以合
理的赞誉。
开源软件协议 软件服务协议(汇总6篇)
开源软件协议软件服务协议(汇总6篇)开源软件协议篇一甲方：乙方：甲乙双方经友好协商，甲方决定向乙方购买“_______餐饮_______系统软件”及其配套产品，乙方负责为甲方部署本系统，根据《中华人民共和国民法典》及其他法律法规签订本合同，并由双方共同恪守。
条款如下：第一条合同履行条件及部署准备1、经甲乙双方协商，合同自签订起即生效。
合同生效后，乙方将于_______年___月___日开始在甲方现场部署相应产品。
2、如因甲方工程进度等原因造成乙方现场安装时间变动，甲方应至少提前_______日，以书面形式(含邮件、传真)通知乙方，合同中规定的安装时间做相应调整。
3、部署系统前，甲方有责任配合乙方，确定设备在甲方现场的部署位置，以双方确认的《项目部署表》为最终依据。
4、乙方系统安装实施过程中，甲方有责任保障现场电力、网络等配套设备正常运转，如需改动《项目部署表》中的相关事项，必须事先通知乙方。
5、如在合同履行期间，甲方提出硬件设备方面的增删、变更或其他修改，以双方签字确认的《设备变更表》为最终依据，合同金额也做相应调整。
6、如在合同履行期间，甲方对软件产品提出功能修改、增补或新的开发需求，须由双方共同签订《需求确认表》，合同金额也做相应调整。
第二条服务及培训1、乙方在系统部署实施后，对甲方相关人员进行一次全面、集中地产品培训，培训以双方签订的《培训计划书》为依据，双方均有义务遵照《培训计划书》进行相关培训。
2、乙方为甲方提供一年内免费维护和技术支持服务，一年免费售后期自双方签署《盯场记录》时间开始计算。
(2)甲方人员故意或因工作疏忽而引起的产品意外损毁;(4)甲方人员在未予书面(含邮件、传真)知会或咨询乙方人员的情况下，邀请第三方人员对产品、设备进行的维护、调整、改动而引起的故障损失。
4、在免费售后期内，乙方一共可向甲方免费提供两次全面、集中地产品培训(包括系统部署实施完成后的一次)。
超出两次免费培训后，如甲方因营业原因需要乙方提供产品培训服务，应按与乙方共同签订《培训计划书》进行安排，并以——元/次价格向乙方支付培训费用。
开源软件授权协议详解(GPLMPLLGPLB
开源运动同样有自己的游戏规则和道德准则。
不遵行这些规则不但损害开源运动的健康发展，也会对违规者造成名誉和市场上的损失，更可能陷入法律纠纷和赔偿。
现今存在的开源协议很多，而经过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 是允许修改，无偿使用的。
开源界的5大开源许可协议
越来越多的开发者与设计者希望将自己的产品开源，以便其他人可以在他们的代码基础上做更多事，开源社区也因此充满生机。
在我们所能想到的应用领域，都有开源软件存在（象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一文。
常见开源协议范文
常见开源协议范文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要求源代码必须开放，同时还允许使用者将衍生作品以其他开源协议发布。
这些开源协议各有特点，用户可以根据自己的需求和对软件的开放程度的要求，选择适合自己的开源许可证。
无论选择哪种许可证，开源协议都提供了一种通过共享和合作来促进软件开发和创新的方式，有助于推动开源社区的发展和成长。
五种开源协议书
五种开源协议书甲方（版权持有者）：________________________地址：______________________________________联系方式：__________________________________乙方（使用者/贡献者）：____________________地址：______________________________________联系方式：__________________________________鉴于甲方是以下开源软件的版权持有者，乙方希望使用或贡献该开源软件，甲乙双方本着平等自愿、诚实信用的原则，经协商一致，就开源软件的使用和贡献事宜达成如下协议：第一条定义1.1 开源软件：指甲方拥有或控制的，以开源许可证形式发布的软件。
1.2 开源许可证：指甲方选择的，用于规范乙方使用和贡献开源软件的法律文件。
1.3 贡献：指乙方对开源软件进行的修改、增强、翻译、注释或其他形式的创造性工作。
第二条开源许可证的选择2.1 甲方选择以下开源许可证之一，用于规范乙方的使用和贡献行为： - MIT许可证- Apache许可证2.0- GNU通用公共许可证（GPL）版本3- BSD许可证- Mozilla公共许可证2.0第三条权利与义务3.1 甲方的权利与义务：3.1.1 甲方保证其对开源软件拥有合法的版权或相应的授权。
3.1.2 甲方有权根据开源许可证的规定，对乙方的使用和贡献行为进行监督和管理。
3.2 乙方的权利与义务：3.2.1 乙方有权根据本协议和开源许可证的规定，使用和贡献开源软件。
3.2.2 乙方在使用和贡献开源软件时，应遵守开源许可证的规定，不得侵犯甲方或第三方的合法权益。
第四条贡献的提交与处理4.1 乙方提交的贡献应符合甲方设定的格式和标准。
4.2 甲方有权决定是否接受乙方的贡献，并在必要时要求乙方进行修改。
第五条知识产权5.1 乙方贡献的知识产权归甲方所有，除非开源许可证有其他规定。
五种开源协议的比较(BSD, Apache, GPL, LGPL, MIT)
五种开源协议的比较（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 采用的协议。
五种开源协议的比较
五种开源协议的比较(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 协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。
软件开源协议书范本
软件开源协议书范本甲方（开源软件提供方）：[甲方全称]乙方（开源软件使用方）：[乙方全称]鉴于甲方是[软件名称]软件的著作权人，拥有该软件的完整知识产权；乙方希望使用甲方提供的开源软件，双方本着平等互利、诚实信用的原则，就乙方使用甲方提供的开源软件达成如下协议：一、软件授权1. 甲方同意按照本协议的条款和条件，授权乙方非独占性、不可转让的使用权，允许乙方使用、复制、修改和分发[软件名称]软件。
2. 乙方同意仅在本协议规定的范围内使用[软件名称]软件，并遵守所有适用的法律法规。
二、使用限制1. 乙方不得将[软件名称]软件用于任何非法目的，包括但不限于侵犯第三方知识产权、违反相关法律法规等。
2. 乙方不得对[软件名称]软件进行反向工程、反编译或以其他方式尝试获取软件的源代码，除非法律另有规定或甲方书面同意。
三、知识产权1. 甲方声明并保证其对[软件名称]软件拥有完整的知识产权，包括但不限于著作权、商标权、专利权等。
2. 乙方在使用[软件名称]软件过程中产生的任何衍生作品，其知识产权归甲方所有，除非双方另有书面约定。
四、免责声明1. [软件名称]软件按“现状”提供，甲方不提供任何形式的保证，包括但不限于适销性、特定用途的适用性或不侵犯第三方权利的保证。
2. 甲方不对因使用[软件名称]软件而导致的任何直接、间接、偶然、特殊或后果性的损害负责，包括但不限于利润损失、业务中断、商业信息丢失或其他经济损失。
五、协议的修改和终止1. 本协议的任何修改和补充均需双方书面同意。
2. 如乙方违反本协议的任何条款，甲方有权立即终止本协议，并要求乙方停止使用[软件名称]软件。
六、法律适用与争议解决1. 本协议的订立、效力、解释、履行和争议解决均适用[国家/地区]法律。
2. 因本协议引起的或与本协议有关的任何争议，双方应首先通过友好协商解决；协商不成时，任何一方均可向甲方所在地的有管辖权的人民法院提起诉讼。
七、其他1. 本协议自双方授权代表签字盖章之日起生效，有效期至[协议有效期]。
软件开发工具开源协议
软件开发工具开源协议合同编号：__________甲方（授权方）：____________地址：_____________________联系方式：_________________电子邮箱：_________________乙方（被授权方）：____________地址：_____________________联系方式：_________________电子邮箱：_________________第一章定义与术语1.1 “本协议”指本软件开发工具开源协议。
1.2 “甲方”指拥有软件开发工具知识产权的授权方。
1.3 “乙方”指接受甲方授权的被授权方。
1.4 “软件”指甲方所拥有的软件开发工具。
1.5 “开源协议”指本协议中规定的关于软件开源使用的条款和条件。
第二章授权范围2.1 甲方在此授予乙方在全球范围内，非独占、不可转让、可撤销的开源使用许可，以使用、复制、修改、分发和展示软件。
2.2 乙方在使用、复制、修改、分发和展示软件的过程中，必须遵守以下条款：2.2.1 保留软件中包含的版权声明和许可协议；2.2.2 在软件的任何修改版本中，必须明确标注乙方为修改方；2.2.3 不得对软件进行任何形式的商业性销售或出租。
第三章责任与义务3.1 甲方应保证：3.1.1 甲方拥有软件的知识产权，有权授予乙方开源使用许可；3.1.2 软件不含有任何可能导致第三方侵权或违反法律法规的成分。
3.2 乙方应保证：3.2.1 在使用、复制、修改、分发和展示软件的过程中，遵守本协议的各项规定；3.2.2 不得利用软件从事任何违法活动；3.2.3 在软件的修改版本中，确保修改内容不侵犯他人的知识产权。
第四章知识产权4.1 软件的知识产权归甲方所有，乙方不得对软件的知识产权提出任何权利主张。
4.2 乙方在修改、分发和展示软件的过程中，应尊重并保留原软件中的知识产权声明。
4.3 乙方对软件的修改版本，应承担相应的知识产权责任。
开源软件协议列表
软件名称
开源协议
是否可以修改
WWW服务
Apache
Apache Licence
需要在被修改的文件中说明
Nginx
Emailຫໍສະໝຸດ Postfix TMail Qmail James DixieMail CRSMail Tomcat
JBoss
BSD-like GPL GPL Apache Licence Free Free Apache License LGPL CDDL Apache License LGPL
Eclipse
可以
Netbeans IntelliJ IDEA Community Edition Ant 构建工具 Maven JUnit 测试和缺陷管理 Bugfree Bugzilla CVS CSV SVN Git Log4J 日志系统 SLF4J JavaScript库 Jquery Apache Hadoop CDH HBase hive Zookeeper Impala 云计算 Fastdfs Nutch Lucene Solr Openldap Ganglia Keepalived
需要
贡献者也不可以移除或变更任何包含在程序中 的版权声明。每个贡献者必须证明自己为贡献 的创始人，无论如何要以一种方式使后继接受 者能够适度地辨识出贡献的创始人。软件商业 发布者可能要接受某些关于最终用户、商业伙 伴等等的责任。当本许可证被用于程序的商业 目的的时候，那些包含了以商业产品形式提供 的程序的贡献者必须以一种方式确保不会对其 他贡献者造成潜在的赔偿责任。因此，如果一 个含有商业产品形式的程序的贡献者，这样的 贡献者（称“商业贡献者”）要同意保卫每一 个其他贡献者并
可以，必须开源、免费
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
可以，必须开源、免费
修改后必须遵循LGPL协议 可以
中间件
Glassfish Spring Hibernate
MySql PostGreSql Ingres r3 MAX DB
GPL MIT CATOSL GPL 可以，必须在你的发行版里包含原 许可协议的声明 否
数据库
Firebird
MPL
可以
Eclipse 开发工具
类型
软件名称
开pache Licence
需要在被修改的文件中说明
Nginx
Postfix TMail Qmail James DixieMail CRSMail Tomcat
JBoss
BSD-like GPL GPL Apache Licence Free Free Apache License LGPL CDDL Apache License LGPL
需要
贡献者也不可以移除或变更任何包含在程序中 的版权声明。每个贡献者必须证明自己为贡献 的创始人，无论如何要以一种方式使后继接受 者能够适度地辨识出贡献的创始人。软件商业 发布者可能要接受某些关于最终用户、商业伙 伴等等的责任。当本许可证被用于程序的商业 目的的时候，那些包含了以商业产品形式提供 的程序的贡献者必须以一种方式确保不会对其 他贡献者造成潜在的赔偿责任。因此，如果一 个含有商业产品形式的程序的贡献者，这样的 贡献者（称“商业贡献者”）要同意保卫每一 个其他贡献者并
CDDL&GPL2.0 有版权 Apache License Apache License GNU GNU MPL GNU Apache License GNU Apache License GNU MIT Apache License Apache License Apache License Apache License Apache License Apache License GPL Apache License Apache License Apache License OpenLDAP BSD 否
修改后是否要开源 在延伸的代码中（修改和有源代 码衍生的代码中）需要带有原来 代码中的协议，商标，专利声明 和其他原来作者规定需要包含的 说明 必须开源、免费
基于此的软件是否需要开源 如果再发布的产品中包含一个Notice文件， 则在Notice文件中需要带有Apache Licence 。你可以在Notice中增加自己的许可，但不 可以表现为对Apache Licence构成更改 开源、免费
修改后必须遵循LGPL协议 不必将你的私有源文件共享
允许商业软件通过类库引用（link）方式使用 LGPL类库而不需要开源商业软件的代码 不需要
如果你在非开源项目使用（即软件不打算开放 源代码），且该软件用来销售，则需要向 mysql支付相应license费用 不需要，必须在你的发行版里包 不需要，只需保留版权 含原许可协议的声明 取得此授权的人可以查看Ingres r3数据库的 源代码，并免费下载该软件 MPL虽然要求对于经MPL许可 证发布的源代码的修改也要以 MPL许可证的方式再许可出来， 以保证其他人可以在MPL的条款 下共享源代码。但是，在MPL许 可证中对“发布”的定义是“以 MPL许可证第三条第7款中允许被许可人将经 源代码方式发布的文件”，这就 过MPL许可证获得的源代码同自己其他类型 意味着MPL允许一个企业在自己 的代码混合得到自己的软件程序。 已有的源代码库上加一个接口， 除了接口程序的源代码以MPL许 可证的形式对外许可外，源代码 库中的源代码就可以不用MPL许 可证的方式强制对外许可。
Eclipse
可以
Netbeans IntelliJ IDEA Community Edition Ant 构建工具 Maven JUnit 测试和缺陷管理 Bugfree Bugzilla CVS CSV SVN Git Log4J 日志系统 SLF4J JavaScript库 Jquery Apache Hadoop CDH HBase hive Zookeeper Impala 云计算 Fastdfs Nutch Lucene Solr Openldap Ganglia Keepalived