开源协议介绍.doc

开源协议介绍.doc。该协议和BSD类似z同样鼓励代码共享和尊重原作者的著作权,同样允许代码修改,再发布(作为开源或商业软件X需要满足的条件也和BSD类似:1需要给代码的用户一份ApacheLicence2如果你修改了代码,需要在被修改的文件中说明。3在延伸的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的协议,商标,专利声明和其他原来作者规定需要包含的说明。4如果再发布的产品中包含一个Notice文件,则在Notice文件中需要带有ApacheLicenceo你可以在Notice中增加自己的许可,但不可以表现为对ApacheLicence构成更改。ApacheLicence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。英文原文:enses/LICENSE-(MozillaPublicLicense)协议MPL是TheMozillaPublicLicense的简写,scape的Mozilla小组为其开源软件项目设计的软件许可证。scape公司认为GPL许可证没有很好地平衡开发者对源代码的需求和他们利用源代码获得的利益。同著名的GPL许可证和BSD许可证相比,MPL在许多权利与义务的约定方面与它们相同(因为都是符合OSIA认定的开源软件许可证1但是,相比而言MPL还有以下几个显著的不同之处:♦MPL虽然要求对于经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来,以保证其他人可以在MPL的条款下共享源代码。但是,在MPL许可证中对"发布"的定义是"以源代码方式发布的文件〃,这就意味着MPL允许一个企业在自己已有的源代码库上加一个接口,除了接口程序的源代码以MPL许可证的形式对外许可外,源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。这些,就为借鉴别人的源代码用做自己商业软件开发的行为留了一个豁口。■MPL许可证第三条第7款中允许被许可人将经过MPL许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序。♦对软件专利的态度,MPL许可证不像GPL许可证那样明确表示反对软件专利,但是却明确要求源代码的提供者不能提供已经受专利保护的源代码(除非他本人是专利权人,并书面向公众免费许可这些源代码),也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。♦对源代码的定义而在MPL()许可证中,对源代码的定义是:"源代码指的是对作品进行修改最优先择取的形式,它包括:所有模块的所有源程序,加上有关的接口的定义,加上控制可执行作品的安装和编译的’原本’(原文为’Script'),或者不是与初始源代码显著不同的源代码就是被源代码贡献者选择的从公共领域可以得到的程序代码♦MPL许可证第3条有专门的一款是关于对源代码修改进行描述的规定,就是要求所有再发布者都得有一个专门的文件就对源代码程序修改的时间和修改的方式有描述。英文原文:/MPL-(MassachusettsInstituteofTechnology,MIT)又称「X条款」(XLicense)或「Xll条款」(XllLicense)MIT内容与三条款BSD许可证(3-clauseBSDlicense)内容颇为近似,但是赋予软体被授权人更大的权利与更少的限制。被授权人有权利使用、复制、修改、合并、出版发行、散布、再授权及贩售软体及软体的副本。被授权人可根据程式的需要修改授权条款为适当的内容。在软件和软件的所有副本中都必须包含版权声明和许可声明。此授权条款并非属copyleft的自由软体授权条款,允许在自由/开放源码软体或非自由软体(proprietarysoftware)所使用。此亦为MIT与BSD(TheBSDlicense,3-clauseBSDlicense)本质上不同处。MIT条款可与其他授权条款并存。另外,MIT条款也是自由软体基金会(FSF)所认可的自由软体授权条款,与GPL相容。协议英文原文:enses/mit-。它不是自由软体基金会所发布,并且不能适用于使用GNULGPL的软体——只有GNULGPL英文原文的版本才行。然而,我们希望这份翻译能帮助中文的使用者更了解GNULGPL。,(C)1991,1999FreeSoftwareFoundation,,Suite330,Boston,MA02111-1307