完整word版开源许可协议.docx
《完整word版开源许可协议.docx》由会员分享，可在线阅读，更多相关《完整word版开源许可协议.docx（22页珍藏版）》请在冰豆网上搜索。
完整word版开源许可协议
开源许可协议
（初稿）
河南新创元信息网络有限公司
研发部
文件标识：
Q/XCY-ZD-02-XXXV0.1.0.0
应用部门：
研发部
保存期限：
永久
文档修订历史记录
日期
版本
说明
作者
审批人
V1.0
翻译文档
王晓晖
1目的
为了让开发人员能够正确合法的使用开源软件，避免因为不小心而触犯到相关法律法规，产生不必要的法律纠纷，现对开源界的几大开原协议进行了翻译和整理。
2开源许可协议定义
自由软件/开源软件是自由的，免费的，源代码开放的，我们可自由下载安装和使用。
同时，为了维护作者和贡献者的合法权利，保证这些软件不被一些商业机构或个人窃取，影响软件的发展，开源社区开发出了各种的开源许可协议。
其中主要分三大类。
OSI-ApprovedOpenSource：
被开放源码组织（www.opensource.org）所批准的开放源码授权协议。
如常见的Apache，GPL，LGPL，MITLicence，都属于OSI-Approved的授权协议，OSI的要求之一是二进制文件和源代码的自由发放。
Other/ProprietaryLicense：
其他的，私有的授权协议。
指软件作者提供源代码，但是对软件的分发和发布有其他的限制。
PublicDomain：
公共域授权。
将软件授权为公共域，表示作者完全放弃版权，任何人都可以随意使用。
大部分开源工程都属于OSI-ApprovedOpenSource，下面对常见的License做简单的介绍。
3开源许可协议介绍
3.1GNUGPL
GNU有两种协议其中一种为GeneralPublicLicence（GPL），该协议有可能是开源界最常用的许可模式。
GPL保证了所有开发者的权利，同时为使用者提供了足够的复制，分发，修改的权利。
主要条款如下：
1.使用者可以将软件自由的复制到任何地方。
2.使用者可以以任何方式自由的分发，下载。
注意分发的时候需要提供源代码和二进制文件。
3.使用者可以盈利，基于GPL的软件允许商业化销售，但不允许封闭源代码。
4.如果使用者对遵循GPL的软件进行任何改动和/或再次开发并予以发布，则使用者的产品必须继承GPL协议，不允许封闭源代码。
GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。
这也就是为什么我们能用免费的各种linux，包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。
但对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。
GPL3.0详见附录4.1GPL3.0协议。
3.2GNULGPL
GNU还有另外一种协议，叫做LGPL（LesserGeneralPublicLicence），它对产品所保留的权利比GPL少，总的来说，LGPL适合那些用于非GPL或非开源产品的开源类库或框架。
因为GPL要求，使用了GPL代码的产品必须也使用GPL协议，开发者不允许将GPL代码用于商业产品。
而LGPL绕过了这一限制。
1.基于LGPL的软件也允许商业化销售，但不允许封闭源代码。
2.如果您对遵循LGPL的软件进行任何改动和/或再次开发并予以发布，则您的产品必须继承LGPL协议，不允许封闭源代码。
但是如果您的程序对遵循LGPL的软件进行任何连接、调用而不是包含，则允许封闭源代码。
如果修改LGPL协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。
因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。
具体条款详见LGPL2.1协议。
3.3BSD
BSD授权许可证（FreeBSDCopyrightInformation）具有多种授权许可证。
其中BSD在软件分发方面的限制比别的开源协议（如GNUGPL）要少。
该协议有多种版本，最主要的版本有两个，新BSD协议与简单BSD协议，这两种协议经过修正，都和GPL兼容，并为开源组织所认可。
简单BSD协议主要条款如下：
1.使用者可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。
2.如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
3.如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
4.不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
新版（也称“三句版”）BSD许可证规定，只要软件的版权申明和许可证的免责条款得以保存，软件可以以任何目的不受限制地分发。
该许可证还包含如下条款：
即未经许可，不得以软件贡献者的名字为软件的衍生产品做代言。
这一条款正是新版BSD许可证与简版BSD许可证之间的主要区别。
3.4Apachelicense.2.0
ApacheLicence是著名的非盈利开源组织Apache采用的协议。
Apache协议2.0和别的开源协议相比，除了为用户提供版权许可之外，还有专利许可，对于那些涉及专利内容的开发者而言，该协议最适合。
以下为ApacheLicence的详细介绍：
1.需要授予使用代码的用户一份ApacheLicence。
一旦被授予许可，使用者可以无限期的使用。
2.如果使用者修改了代码，需要再被修改的文件中说明。
3.在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
4.如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有ApacheLicence。
你可以在Notice中增加自己的许可，但不可以表现为对ApacheLicence构成更改。
以下是该授权关于对工作中使用的说明和限制：
如果在工作中需要应用该授权，请附上如下样板式说明，以[]围起来，来替换你自己的说明信息。
（不要包含括弧）文本通常被适当的文件语法格式所包围。
我们也建议，一个文件或者类名和特定目的的描述，一起被包含在印刷页上，该印刷页作为一个简单的第三方文档授权证明。
下图1为授权的文档格式。
图1
3.5MIT许可协议（MITLicense）
在所有常用的开源许可协议中，MIT许可协议最为简短，可能也最为广泛。
它的条款非常松散，比起大部分其它许可协议来说更加宽松。
其基本条款如下：
1.使用者可以随意使用，复制，修改这个软件。
没有人能够阻止你在任何工程里使用它，你可以复制任意次数、以任何形式，或按你的愿望修改它。
2.使用者可以向外免费发放，或出售。
你可以随意的分发它，没有任何限制。
3.唯一的限制是使用者必须接受协议条款。
即软件必须附带版权和许可协议。
4.MIT协议是目前最少限制的协议。
它基本上就是任何人可以对这个协议下的软件的做任何的事情，只要你能认可这个协议。
3.6知识共享协议
知识共享（CreativeCommons，简称CC）许可协议并非完全的开源许可协议，但设计类项目也常常使用。
有各种不同的CC许可协议可供使用，每种授予特定的权利。
一个CC许可证包含四个基本部分，每部分即可单独生效，又可联合使用。
简述如下：
1.署名,使用者必须按照作者指定的方式对作品进行署名。
除此之外，作品可被复制、分发、拷贝以及以其它方式使用。
2.相同方式共享，即只能基于相同的CC许可证对作品进行修改、分发等。
3.非商业性，作品可被修改、分发等，但不得以商业为目的进行。
关于什么构成商业行为，许可证条款并未提供清晰的定义，因此使用者可能需要在自己的项目里给予澄清。
比如说，有人认为“非商业”只是简单地意味着你不能出售作品，也有人认为你不能把作品放到一个带广告的网站上，还有人认为只有当牟利发生时才能称为“商业”。
4.禁止衍生，即使用者可以拷贝和分发授权作品，但不得以任何方式修改、或基于原作进行创作。
如上所述，CC许可证的各个部分可以联合使用。
最为严格的许可证为“署名-非商业-禁止衍生”许可证，即使用者可以自由分享作品，但不得修改或收费，同时必须按照作者指定的方式为作品署名。
这对那些一方面希望发布作品，另一方面又希望多多少少保留对作品使用方式的控制权的作者来说，颇为不错。
限制最少的CC许可证是“署名”许可证，即只要按照作者指定的方式为作品署名，就可以用作品做任何事。
CC许可证在设计类作品中的应用要比在开发中的应用多，但并没有限制你在开发中使用它，只是要清楚各部分条款的细节。
3.7CPL（CommonPublicLiecense）vesion1.0
CPL是IBM提出的并通过了OSI（OpenSourceInitiative）批准的开源协议。
主要用于一些IBM或跟IBM相关的开源软件/项目中。
如很著名的Java开发环境Eclipse、RIA开发平台OpenLaszlo等。
CPL也是一项对商业应用友好的协议。
它允许使用者对源码进行任意的使用、复制、分发、传播、展示、修改以及改后做闭源的二次商业发布，这点跟BSD很类似，也属于自由度比较高的开源协议。
但是，需要遵循以下条款：
1.当使用者将源码的整体或部分再次开源发布的时候，必须继续遵循CPL开源协议来发布，而不能改用其他协议发布。
除非你得到了原“源码”Owner的授权。
2.CPL协议下，使用者可以将源码不做任何修改来商业发布。
但如果要将修改后的源码开源，而且当你再发布的是ObjectCode的时候，你必须声明它的SourceCode是可以获取的，而且要告知获取方法。
3.当使用者需要将CPL下的源码作为一部分跟其他私有的源码混和着成为一个项目发布的时候，可以将整个项目/产品以私人的协议发布，但要声明哪一部分代码是CPL下的，而且声明那部分代码继续遵循CPL。
独立的模块（SeparateModule），不需要开源。
3.8MPL协议
MPL是TheMozillaPublicLicense的简写，是1998年初Netscape的Mozilla小组为其开源软件项目设计的软件许可证。
MPL许可证出现的最重要原因就是，Netscape公司认为GPL许可证没有很好地平衡开发者对源代码的需求和他们利用源代码获得的利益。
同著名的GPL许可证和BSD许可证相比，MPL在许多权利与义务的约定方面与它们相同（因为都是符合OSIA认定的开源软件许可证）。
但是，相比而言MPL还有以下几个显著的不同之处:
1.MPL允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者。
这种授权维护了商业软件的利益，它要求基于这种软件得修改无偿贡献版权给该软件。
这样，围绕该软件得所有代码得版权都集中在发起开发人得手中。
但MPL是无偿使用得。
MPL软件对链接没有要求。
2.MPL要求对于经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来，以保证其他人可以在MPL的条款下共享源代码。
但是，在MPL许可证中对“发布”的定义是“以源代码方式发布的文件”，这就意味着MPL允许一个企业在自己已有的源代码库上加一个接口，除了接口程序的源代码以MPL许可证的形式对外许可外，源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。
这些，就为借鉴别人的源代码用做自己商业软件开的行为留了一个豁口。
3.MPL许可证第三条第7款中允许使用者将经过MPL许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序。
4.对软件专利的态度，MPL许可证不像GPL许可证那样明确表示反对软件专利，但是却明确要求源代码的提供
升级会员 