开源软件许可协议

合集下载

几种常见的开源软件许可协议(GPL,LGPL,ApacheLicense,BSD)

几种常见的开源软件许可协议(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还规定了衍生作品需要开放源代码,并明确指出版权和许可证。

开源许可协议

开源许可协议

开源许可协议协议名称:开源许可协议一、背景介绍开源许可协议是一种法律文档,用于规定软件开辟者和用户之间的权利和义务。

该协议允许软件的源代码被公开、复制、修改和分发,以促进创新和共享。

二、定义1. 开源软件:指遵循开源许可协议的软件,其源代码可被公开访问、使用、复制、修改和分发。

2. 软件开辟者:指创建、维护和修改开源软件的个人或者组织。

3. 用户:指使用、复制、修改和分发开源软件的个人或者组织。

三、协议内容1. 授权许可:软件开辟者向用户授予非排他性、免费的许可,允许用户使用、复制、修改和分发开源软件的源代码和二进制文件。

2. 源代码公开:软件开辟者应将开源软件的源代码公开,以便用户可以获得并进行修改和分发。

3. 修改和派生作品:用户可以基于开源软件的源代码创建修改和派生作品,但必须遵守本协议,并将修改后的代码和派生作品公开。

4. 分发要求:用户在分发开源软件时,必须附带本协议、版权声明、免责声明和其他相关文件,并保留原始作者的署名。

5. 商业使用:用户可以将开源软件用于商业目的,但在分发时仍需遵守本协议的要求。

6. 免责声明:软件开辟者对开源软件的使用、复制、修改和分发不承担任何责任,包括但不限于质量、稳定性、适合性等方面的责任。

7. 专利授权:软件开辟者声明对其拥有的相关专利,授予用户非排他性、免费的授权,以便用户可以使用、复制、修改和分发开源软件。

四、适合范围本协议适合于所有开源软件的使用、复制、修改和分发。

五、协议变更软件开辟者有权随时修改本协议的内容,并通过公开途径通知用户。

用户在继续使用、复制、修改和分发开源软件时,视为接受并遵守修改后的协议。

六、争议解决任何因本协议引起的争议,应通过友好商议解决。

如商议不成,双方允许将争议提交至有管辖权的法院解决。

七、其他条款1. 本协议不得违反任何适合的法律法规。

2. 本协议的任何条款无效或者不可执行,不影响其他条款的效力。

3. 本协议不构成软件开辟者和用户之间的代理、合伙、雇佣或者其他类似关系。

开源许可协议

开源许可协议

开源许可协议协议名称:开源许可协议一、背景和目的本开源许可协议(以下简称“本协议”)旨在规定软件开源的条件和限制,以促进开源社区的发展和共享。

本协议适用于任何开源软件项目,旨在确保开发者和用户之间的权益平衡和合作。

二、定义1. “软件”指代在本协议下进行开源许可的计算机程序、代码库、脚本和相关文档。

2. “开源”指代以自由和开放的方式发布和分发软件,允许用户查看、使用、修改和分发软件的权利。

三、许可条件1. 授予许可:软件的开发者在符合本协议的前提下,授予所有用户免费使用、复制、修改和分发软件的权利。

2. 版权声明:用户在分发或发布软件时,必须保留软件的原始版权声明和本协议的副本。

3. 开源代码:用户在分发软件时,必须提供软件的源代码或以其他公开的方式提供访问软件源代码的机会。

四、权利和义务1. 开发者权利:软件的开发者保留对软件的所有权利,并拥有决定软件的许可方式和条件的权力。

2. 用户权利:用户可以自由使用、复制、修改和分发软件,但必须遵守本协议的规定。

3. 共享义务:用户在分发或发布软件时,必须遵守本协议的规定,并确保接收者能够获得软件的源代码和本协议的副本。

五、责任和免责1. 免责声明:软件是按照“现状”提供,开发者不对软件的适用性、稳定性和安全性提供任何明示或暗示的保证。

2. 资源分配:开发者不承担因软件使用或分发而导致的任何直接或间接的损失或责任。

3. 维护义务:开发者不负责为用户提供软件的支持和维护服务,用户可以依靠开源社区的支持和贡献。

六、协议变更1. 变更通知:开发者有权随时修改本协议的内容,并通过适当的方式向用户发布变更通知。

2. 适用版本:用户可以选择继续使用旧版本的软件,但对于新版本的软件,用户必须遵守最新的协议。

七、争议解决1. 协商解决:对于本协议的解释和执行产生的争议,双方应通过友好协商解决。

2. 管辖法律:本协议受中华人民共和国法律管辖。

八、其他条款1. 效力范围:本协议的任何条款无效或不可执行,不影响其他条款的效力。

列举常见的开源协议简述其许可证的规则

列举常见的开源协议简述其许可证的规则

列举常见的开源协议简述其许可证的规则常见的开源协议有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许可证要求在分发软件时必须包含原始的许可证和版权声明。

需要注意的是,以上介绍的仅是常见的开源协议之一,实际上还有许多其他开源协议,每个协议都有其独特的许可证规则。

选择适合自己项目的开源协议时,需要仔细研究和理解相应的许可证规则,并确保符合规范进行软件的使用、复制、修改和分发。

开源许可协议

开源许可协议

开源许可协议一、引言本协议旨在规范软件的开源许可,促进开源社区的发展和合作。

以下是协议的具体内容:二、定义1. 开源软件:指根据本协议要求,以开放源代码形式发布的软件。

2. 软件作者:指开发、设计、编写软件的个人或团体。

3. 用户:指任何个人或组织使用开源软件的人。

三、许可授权1. 软件作者授权用户以免费、非独占、永久的方式使用、复制、修改、分发和传播软件。

2. 用户在遵守以下条件的前提下,可以享有上述授权:a. 在软件的副本中包含版权声明和许可声明。

b. 在对软件进行修改时,必须标明修改的地方,并保留原始版权声明和许可声明。

c. 任何以源代码形式分发软件的衍生作品,必须使用相同的许可证授权。

d. 在分发软件的二进制形式时,必须提供源代码或者明确指示如何获取源代码。

e. 未经软件作者明确许可,不得将软件用于商业目的。

四、免责条款1. 软件作者不对软件的适用性、稳定性和安全性提供任何保证。

2. 用户在使用软件时,需自行承担风险,软件作者不对因使用软件而导致的任何损失或损害负责。

五、知识产权保护1. 软件作者保留软件的全部知识产权。

2. 用户不得删除或修改软件中的任何版权声明、商标或其他知识产权标识。

六、争议解决1. 本协议的解释和适用以及与本协议有关的争议,应依据中国法律进行解释和处理。

2. 若用户违反本协议的任何规定,软件作者有权随时终止用户对软件的使用权。

七、其他1. 本协议自双方达成一致并签署之日起生效,有效期为永久。

2. 若本协议的任何条款被认定为无效或不可执行,不影响其他条款的效力。

3. 本协议的修改需经软件作者和用户双方达成一致,并以书面形式确认。

八、协议终止1. 用户违反本协议中的任何规定,软件作者有权终止用户对软件的使用权。

2. 本协议终止后,用户需停止使用软件,并删除所有已复制、下载或安装的软件副本。

九、协议的变更和补充1. 软件作者有权随时修改本协议的内容,并通过适当的方式通知用户。

gpl协议书范文

gpl协议书范文

gpl协议书范文GPL协议是一种开源软件许可协议,它保证了每个用户都有权利使用、修改和分发软件。

下面是一个关于GPL协议的范文,长度超过1000字:GPL许可协议书本GPL许可协议(以下简称“本协议”)由一方被授权人(以下简称“你”或“你的”)与另一方自由软件基金会(以下简称“FSF”)共同签署,并约定以下条款和条件。

一、定义1. “软件”:指本许可协议所涉及的自由软件2. “复制”:指在计算机文件或其他媒介上制作软件的拷贝或重现3. “修改”:指对软件进行任何改动、改编、增加或减少的行为4. “派生作品”:指由软件及其修改或以软件为基础创作而得出的作品5. “分发”:指向其他人提供复制、修改或派生作品的行为6. “使用”:指以软件运行程序的行为二、软件的使用权1. 你有权复制和分发软件的原始版本,并修改软件的源代码。

如果你第一次分发的是经过修改的软件,你必须将修改后的源代码和相应文档一并分发。

2. 你有权分发由软件生成的派生作品,无论是否经过修改,包括二进制形式的派生作品。

但在分发时,你必须确保派生作品采用了适当的许可协议。

3. 你有权使用软件或派生作品,无论是以源代码形式还是以二进制形式。

三、软件的修改和分发1. 当你修改软件时,你需要提供清晰准确的通知,明确标注修改内容,并在你的修改中保留原始版本作者的著作权和许可声明。

2. 你无权将修改后的软件作为原始软件的替代品分发。

只有在满足以下条件时,你才可以收费分发软件:(1)你提供原始或修改后的软件的源代码,(2)你提供软件的修改历史记录,(3)你不得要求任何额外费用,但可以要求补偿你提供或支持软件的开销。

3. 如果你已经向他人分发了修改后的软件或派生作品,你需要告知他们他们有权进一步分发该软件,并确保他们了解本协议的条款。

四、软件的授权1. 你授予任何使用、复制、分发和修改软件的权利,但前提是他们也遵守本协议。

2. 如果他人使用了软件的一部分或全部,他们必须在软件中明确标注你的著作权和许可声明。

开源协议书范本

开源协议书范本

开源协议书范本甲方(开源方):_____________________乙方(使用方):_____________________鉴于甲方拥有某项软件的知识产权,并愿意将该软件以开源的方式提供给公众使用,乙方希望使用甲方提供的开源软件。

为了明确双方的权利和义务,甲乙双方本着平等、自愿、互利的原则,经协商一致,特订立本协议书。

第一条定义1.1 开源软件:指甲方提供给乙方使用的,按照本协议书规定条件可以自由使用的软件及其相关文档。

1.2 修改:指对开源软件的源代码进行增加、删除或改动的行为。

1.3 分发:指将开源软件或其修改后的版本以任何形式提供给他人使用,包括但不限于出售、出租、出借、网络传输等。

第二条开源软件的授权2.1 甲方同意按照本协议书的规定,授权乙方使用开源软件。

2.2 乙方同意按照本协议书的规定使用开源软件,并遵守甲方提供的开源许可证的规定。

第三条使用限制3.1 乙方不得将开源软件用于任何违法活动。

3.2 乙方不得未经甲方书面同意,将开源软件用于商业目的。

3.3 乙方不得删除或修改开源软件中的版权声明、商标或其他标识。

第四条修改和分发4.1 乙方有权对开源软件进行修改,但修改后的软件仍需遵守本协议书的规定。

4.2 乙方可以将修改后的软件分发给第三方,但必须确保第三方遵守本协议书的规定。

第五条保证和免责声明5.1 甲方保证其拥有开源软件的知识产权,并有权授权乙方使用。

5.2 甲方不对开源软件的适用性、稳定性、安全性等做出任何明示或暗示的保证。

5.3 乙方使用开源软件的风险由乙方自行承担。

第六条协议的变更和终止6.1 本协议书的任何变更和补充均需双方书面同意。

6.2 如乙方违反本协议书的规定,甲方有权随时终止本协议书。

第七条争议解决7.1 本协议书在执行过程中发生的任何争议,双方应通过友好协商解决。

7.2 如果协商不成,任何一方均可向甲方所在地的人民法院提起诉讼。

第八条其他8.1 本协议书一式两份,甲乙双方各执一份,具有同等法律效力。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

开源软件许可协议多数人没有注意到开源软件许可的存在,这是因为它不同于传统的书面签字或上网点击那样“接受许可”的方式。

开源软件的许可协议是开放的,只要具有相应行为就可“默认”接受的许可;但如“被许可人”不遵守有关许可条件,许可随时会被终止,“被许可人”持有开源软件的权利将自动终止,并需承担违约责任的风险。

BSD、GPL、LGPL、MPL是应用最为普遍的四种典型的自由/开源软件的许可协议(占自由/开源软件全部许可协议的80%以上)。

BSD许可证BSD是一种自由软件,其许可协议为FreeBSD。

FreeBSD的主要规定是:公开BSD的源码,可让你自由获得、复制、修改、分发BSD原创软件作品(源码);也可在BSD公开的源码基础上衍生你的软件作品。

衍生的软件作品(其源码)可以公开,也可不公开。

在你进行修改或衍生时,必须对哪些是你所获得的BSD原创软件作品所实行的BSD许可证,哪些是你在其上进行的再开发,或生成你自己的许可证,要区分清楚。

当你依法处理的作品再分发时,必须作出相应的版权声明,列出相应条件,并表明BSD拒绝担保的声明。

对于获得的BSD原创软件作品(源码)的版权(所有权)要明确表示出来,如标明它是加州大学伯克利分校的(=regents of the University of California, =University of Ca lifornia, Berkeley),即其版权属于加州大学“董事”和“贡献者”,或“所有者” (owner),并标明BSD许可证发布时间(如=1998),而且你要对使用BSD 的原创软件作品向版权所有者(owner)表示感谢(这些标明都要让你的用户知道)。

如果你把获得的这些BSD原创软件作品看成是你自己的“自主知识产权”,那无异于“剽窃”。

至于你衍生的软件作品,可以公开,也可以不公开(其实微软也使用了很多BSD的原创作品,但微软的衍生作品不公开)。

必须明确,BSD软件版权所有者或贡献者是以“AS IS”(即“保持原样”)方式提供的。

在你再开发的衍生作品中,未获得预先特定许可时,不得用伯克利<组织>或贡献者的名字来为你背书;原创作品版权所有者或贡献者均不对你使用、修改、再传播、再发行的BSD原创作品以及你的衍生作品提供任何直接或隐含的担保,同时也不承担相应的责任。

GPL许可多数自由/开源软件采用通用许可协议:GNU/GPL(GNU General Public License,简称GPL),这是自由软件基金会(Free Software Foundation,FSF)发布的一个软件授权许可证。

现有40000个版本/方案(Projects)采用 GPLV2。

Linus Tovalds将Linux在GUN/GPL下发布,自由软件基金会将Linux作为GUN操作系统的内核。

GPL承认软件作品作者的著作权(所有权),同时也要求作者必须允许任何人(或用户,或“你”)享有对其作品使用、复制、修改、衍生、发行的自由权利;作为一个限制条件,GPL还要求用户不能改变软件的授权协议(即要将GPL向各级用户传递下去),要求用户在对该软件作品作出的修改或制作衍生作品并进行再发行时,都要一贯遵守GPL规则;如果执行GPL协议的原创软件是自由软件,则该自由软件经过修改或衍生后的软件也应是自由软件;自由软件在作二进制整体运行时,不允许一部分软件的源码是开源的,另一部分的源码是闭源的,即不允许出现混合源码的现象。

GPL协议还规定,不得使用其它许可证进行再发布。

GPL协议是一个开放的协议,是在原创软件作品上实施“使用、复制、修改、衍生、发行”等相应行为时出现的“默认接受”的许可。

“默认许可”是执行GPL协议的一大特点,不同于常规签署协议许可的做法。

如果有人对自由/开源软件进行修改、衍生、再发行时使之闭源,从而改变了自由软件的性质和形态,那就违反了GPL协议。

有人认为:“在开源领域违反GPL协议的行为就相当于在传统版权中的‘盗版’性质,同样可称为侵犯知识产权,要予以打击”;也有人认为:“如果违反了GPL协议,GPL协议在其再发行、再传播过程中就自动终止,这时如果还要按‘GPL规则’继续自由索取原创软件源码,而在进行衍生闭源后再发行,将遭致法律风险”。

GPL许可协议是由自由软件基金会制定的。

执行GPL规则的软件作品其版权理论上属于该软件作品的“作者”或“开发者”,以及“修改者”或“贡献者”,他们可统称为版权“所有者”。

GPL虽然认承作者对其软件作品的所有权,但由于自由/开源软件是由全球志愿者集体开发的成果,开源社区的组织也较为自由松散,因此其版权或著作权的所有者似乎不可能明确认定为某些个人或某个社区。

有人认为:对“自由/开源软件作品来说,迄今尚未被全球软件组织或软件工作者公认是拥有一种可执行的版权”。

对linux内核(Kernel),版权所有者们委托Linus Tovalds作为版权所有者的代表。

几天前,OSDL首席执行官 Stuart Cohen告诉我,Linus 代表内核全体所有者持有的版权是“右版(CopyRight)”,我对此怀疑,似应为“左版(CopyLeft)”。

国内个别企业,根据GPL规则将自由获得的开源软件,在进行修改、衍生后,在再发行自己的版本时,将之变成违反GPL规则的闭源软件,这不但可看成具有负面影响的道德问题,还可能将面临侵犯知识产权遭受法律追诉的风险。

Ubuntu(社区)的Linux发布版是移植、剪裁Debian(社区)的软件资源进行再开发、再发布的成果。

今年3月,Ubuntu的创始人Mark Shuttleworth对我说,Ubuntu在向社会、市场提供Linux发布版时,要取得Debian的“授权”(并向Debian支付相应费用)。

我想这个“授权”不是“版权”的“授权”,是Ubuntu为了要不断取得Debian的软件资源、纠错升级、设计思想、技术诀窍、运作经验等方面的“支持”而采取的相应措施。

RedHat公司也认为,如果有人对RH发布版进行修改而不遵守GPL规则,则对修改后的软件,RedHat概不负责,不提供支持、服务,包括不提供补丁、升级及其他服务事项。

但RedHat对自己的发布版则保证提供及时完善的支持和服务。

LGPLLGPL,早期称之为“库级-GPL”(Lib-GPL),后来称之为“轻型-GPL”(Light-GPL)或“宽松-GPL”(Lesser-GPL),它不同于GPL许可证,在执行LGPL许可证时,允许库函数可以自由地联接到私有软件。

MPLMPL的版权理论上也属于其原创软件作品的原始开发者与后续修改者、贡献者,通常由(属Mozilla开源社区)代管。

MPL包含四个不同的许可证,在使用中要注意协调好许可证之间的冲突。

BSD开源协议(Berkeley Software Distribution )BSD开源协议是一个给予使用者很大自由的协议.基本上使用者可以“为所欲为”可以自由的使用,修改源代码,也可以将修改后的代码作为开源或者专有软件再发布.但“为所欲为”的前提当你发布使用了BSD协议的代码,或则以BSD协议代码为基础做二次开发自己的产品时,需要满足三个条件:1. 如果再发布的产品中包含源代码,则在源代码中必须带有原来代码中的BSD协议.2. 如果再发布的只是二进制类库/软件,则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议.3. 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广.其实这几个规则约定的目的也只是达到一个目的:是他人的东西,别人以BSD开源了,你就不能不做任何声明而占为己有,更不能用他人的名义来做商业推广.你只对你自己的东西拥有绝对控制权.举个例子,你用开源代码(A)修改或做其他增添之后,产生了产品B,这时候,你对B的控制由你自己决定,你可以用任何协议再开源,也可以闭源商业发布. 但,因为如果B中包含了A或A的一部分(一点都不包含就不叫修改了),那你在B产品的版权声明中,必须有提到你有使用到 A ,并且附带上 A 的开源协议.而且不能做商业推广的时候将 B 冠以原开源作者的名义以促进商业推广.BSD代码鼓励代码共享,但需要尊重代码作者的著作权.BSD由于允许使用者修改和重新发布代码,也允许使用或在BSD代码上开发商业软件发布和销售,因此是对商业集成很友好的协议.而很多的公司企业在选用开源产品的时候都首选BSD协议,因为可以完全控制这些第三方的代码,在必要的时候可以修改或者二次开发.Apache Licence 2.0Apache Licence是著名的非盈利开源组织Apache采用的协议.该协议和BSD类似,同样鼓励代码共享和尊重原作者的著作权,同样允许代码修改,再发布(作为开源或商业软件).需要满足的条件也和BSD类似:1. 需要给代码的用户一份Apache Licence2. 如果你修改了代码,需要再被修改的文件中说明.3. 在延伸的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的协议,商标,专利声明和其他原来作者规定需要包含的说明.4. 如果再发布的产品中包含一个Notice文件,则在Notice文件中需要带有Apache Licence.你可以在Notice中增加自己的许可,但不可以表现为对Apache Licence构成更改.Apache Licence也是对商业应用友好的许可.使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售.GPL (Gun General Public License)vesion 2.0 1991我们很熟悉的Linux就是采用了GPL.GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样.GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用,但不允许修改后和衍生的代码做为闭源的商业软件发布和销售.这也就是为什么我们能用免费的各种linux,包括商业公司的linux和linux上各种各样的由个人,组织,以及商业软件公司开发的免费软件了.GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用,修改后的代码或者衍生代码)GPL 协议的产品,则该软件产品必须也采用GPL协议,既必须也是开源和免费.这就是所谓的“传染性”.GPL协议的产品作为一个单独的产品使用没有任何问题,还可以享受免费的优势.由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议,对于使用GPL协议的开源代码,商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础.最常见的开源协议,使用它作为授权协议的有大名鼎鼎的Linux .GPL最显著的两个特点就是网上称为的“病毒性传播”和“不允许闭源的商业发布”.所谓的“病毒性传播”,指的是,GPL规定,所有从GPL协议授权的源码衍生出来的(即上面提到的Derivative Module),或者要跟GPL授权的源码混着用的Project,都要遵循GPL协议,就像病毒一样,粘上了关系,就“中毒”了.GPL这样规定的目的是,保证在GPL协议保护下的产品,不会再受到其他协议或者授权的约束.即让跟GPL有关系的源码都能免费获取.举个例子,如果你的改进的Linux中使用了GPL授权下的开源模块(也必须使用,你不可能自己重新去做个内核吧,如果做出来了,你也没必要叫Linux了.),那么你整个Linux产品也必须遵循GPL协议去开源,不能以其他方式去开源发布,更不允许闭源发布.这样一来,就不会出现这样一个Linux--这个功能是GPL协议授权的,可以免费获取源码,而另外一个功能是其他协议下的,拿不到源码.这点规定对使用或者研究该产品的人来说,是一个极大的便利.而“不允许闭源商业发布”指的是,在GPL授权下,你的软件产品可以商业发布,拿去卖钱,但是在这同时,你也必须将该产品的源码以GPL协议方式开源发布出去,供他人免费获取.也许有人会迷惑,拿去卖,又同时开源,那谁来买阿?这个产品怎么赚钱呢??这就涉及到开源产品的商业模式的问题了,想了解相关一些信息的话,可以看看以上我给出链接的一些文章.至于后面,可能会写一篇关于开源项目的商业模式的随笔.GPL协议下的商业发布的一个关键点就像Java 视线论坛的Robbin所说的,GPL是针对软件源代码的版权,而不是针对软件编译后二进制版本的版权.你有权免费获得软件的源代码,但是你没有权力免费获得软件的二进制发行版本.GP对软件发行版本唯一的限制就是:你的发行版本必须把完整的源代码一同提供.它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似.LGPLLGPL是GPL的一个为主要为类库使用设计的开源协议.和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同. LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码.这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售.但是如果修改LGPL协议的代码或者衍生,则所有修改的代码,涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议.因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用,但不适合希望以LGPL协议代码为基础,通过修改和衍生的方式做二次开发的商业软件采用.GPL/LGPL都保障原作者的知识产权,避免有人利用开源代码复制并开发类似的产品.CPL(Common Public Liecense) vesion 1.0CPL是IBM 提出的并通过了OSI(Open Source Initiative)批准的开源协议.主要用于一些IBM或跟IBM相关的开源软件/项目中.如很著名的Java开发环境Eclipse 、RIA开发平台Open Laszlo等.CPL也是一项对商业应用友好的协议.它允许Recipients 对源码进行任意的使用、复制、分发、传播、展示、修改以及改后做闭源的二次商业发布,这点跟BSD 很类似,也属于自由度比较高的开源协议.但是,需要遵循:1. 当一个Contributors将源码的整体或部分再次开源发布的时候,必须继续遵循CPL开源协议来发布,而不能改用其他协议发布.除非你得到了原“源码”Owner 的授权.2. CPL协议下,你可以将源码不做任何修改来商业发布.但如果你要将修改后的源码其开源,而且当你再发布的是Object Code的时候,你必须声明它的Source Code 是可以获取的,而且要告知获取方法.3. 当你需要将CPL下的源码作为一部分跟其他私有的源码混和着成为一个Project 发布的时候,你可以将整个Project/Product 以私人的协议发布,但要声明哪一部分代码是CPL下的,而且声明那部分代码继续遵循CPL.4. 独立的模块(Separate Module),不需要开源.。

相关文档
最新文档