为什么要代码开源
一般而言一个真正优秀的项目往往很难凭一己之力开发出来,除了那些实力可以吊打整个银河系的coder(膜拜)。开源代码最成功的先例就是linux OS,对于开源的linux OS,用户可以通过网络或其他途径免费获得,并可以任意修改其源代码。这是其他的操作系统所做不到的。正是由于这一点,来自全世界的无数程序员参与了Linux的修改、编写工作,程序员可以根据自己的兴趣和灵感对其进行改变,这让Linux吸收了无数程序员的精华,不断壮大。 手机操作系统Android的蓬勃发展也离不开开源的助推力,这样的例子数不胜数。
开源协议
GPL
GPL,是GNU General Public License的缩写,是GNU通用公共授权非正式的中文翻译。它并非由自由软件基金会所发表,亦非使用GNU通用公共授权的软件的法定发布条款─只有GNU通用公共授权英文原文的版本始具有此等效力。
GPL协议最主要的几个原则:
1、确保软件自始至终都以开放源代码形式发布,保护开发成果不被窃取用作商业发售。任何一套软件,只要其中使用了受 GPL 协议保护的第三方软件的源程序,并向非开发人员发布时,软件本身也就自动成为受 GPL 保护并且约束的实体。也就是说,此时它必须开放源代码。
2、GPL 大致就是一个左侧版权(Copyleft,或译为“反版权”、“版权属左”、“版权所无”、“版责”等)的体现。你可以去掉所有原作的版权 信息,只要你保持开源,并且随源代码、二进制版附上 GPL 的许可证就行,让后人可以很明确地得知此软件的授权信息。GPL 精髓就是,只要使软件在完整开源 的情况下,尽可能使使用者得到自由发挥的空间,使软件得到更快更好的发展。
3、无论软件以何种形式发布,都必须同时附上源代码。例如在 Web 上提供下载,就必须在二进制版本(如果有的话)下载的同一个页面,清楚地提供源代码下载的链接。如果以光盘形式发布,就必须同时附上源文件的光盘。
4、开发或维护遵循 GPL 协议开发的软件的公司或个人,可以对使用者收取一定的服务费用。但还是一句老话——必须无偿提供软件的完整源代码,不得将源代码与服务做捆绑或任何变相捆绑销售。
MPL
MPL是The Mozilla Public License的简写,是1998年初Netscape的 Mozilla小组为其开源软件项目设计的软件许可证。MPL许可证出现的最重要原因就是,Netscape公司认为GPL许可证没有很好地平衡开发者对源代码的需求和他们利用源代码获得的利益。同著名的GPL许可证和BSD许可证相比,MPL在许多权利与义务的约定方面与它们相同(因为都是符合OSIA认定的开源软件许可证)。但是,相比而言MPL还有以下几个显著的不同之处:
MPL虽然要求对于经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来,以保证其他人可以在MPL的条款下共享源代码。但是,在MPL许可证中对“发布”的定义是“以源代码方式发布的文件”,这就意味着MPL允许一个企业在自己已有的源代码库上加一个接口,除了接口程序的源代码以MPL许可证的形式对外许可外,源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。这些,就为借鉴别人的源代码用做自己商业软件开发的行为留了一个活口。
MPL许可证第三条第7款中允许被许可人将经过MPL许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序。
对软件专利的态度,MPL许可证不像GPL许可证那样明确表示反对软件专利,但是却明确要求源代码的提供者不能提供已经受专利保护的源代码(除非他本人是专利权人,并书面向公众免费许可这些源代码),也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。
对源代码的定义
而在MPL(1.1版本)许可证中,对源代码的定义是:“源代码指的是对作品进行修改最优先择取的形式,它包括:所有模块的所有源程序,加上有关的接口的定义,加上控制可执行作品的安装和编译的‘原本’(原文为‘Script’),或者不是与初始源代码显著不同的源代码就是被源代码贡献者选择的从公共领域可以得到的程序代码。”MPL许可证第3条有专门的一款是关于对源代码修改进行描述的规定,就是要求所有再发布者都得有一个专门的文件就对源代码程序修改的时间和修改的方式有描述。
BSD
BSD许可证原先是用在加州大学柏克利分校发表的各个4.4BSD/4.4BSD-Lite版本上面(BSD是Berkly Software Distribution的简写)的,后来也就逐渐沿用下来。1979年加州大学伯克利分校发布了BSD Unix,被称为开放源代码的先驱,BSD许可证就是随着BSD Unix发展起来的。BSD许可证被Apache和BSD操作系统等开源软件所采纳。
相较于GPL许可证和MPL许可证的严格性,BSD许可证就宽松许多了,一样是只需要附上许可证的原文,不过比较有趣的是,它还要求所有进一步开发者将自己的版权资料放上去,所以拿到以BSD许可证发行的软件可能会遇到一个小状况,就是这些版权资料许可证占的空间比程序还大。
QPL
QPL是The Qt Public License的简称,是挪威一家机构创设的。QPL许可证的基本要求是获得源代码、修改源代码,并可将修改从原始代码中分离出来;修改可以按照作者的意愿被组合到新版本中;二进制代码可以和原始代码同名,这一点对于动态连接库来说尤其重要;任何人都可以修正错误,这对于系统的发布者来说很关键;修改过的软件可以按照满足QPL许可证基本要求的任何开源软件许可证进行发布。
QNCL
QNCL许可证是Qt Non Commercial License的简称,是QPL许可证的“兄弟版”,就像GPL许可证与LGPL许可证的关系一样,QNCL许可证比QPL许可证更严格一些。
在修改和发布方面的规定,QNCL许可证与QPL许可证是一样的,差异就在于软件的范围方面,或者说在连接方面。QNCL许可证规定“假如一个应用程序给你提供了一个入口,使你有权使用QNCL许可证下的软件的功能开发程序、重复使用程序的某一部分或其他软件的某一部分,那么对该应用程序的使用视为是使用QNCL许可证下的软件的行为,该应用程序应受到QNCL许可证的约束”。QNCL许可证比QPL许可证更严格之处在于,QNCL许可证像GPL许可证那样,完全禁止根据本许可证得到的开放源码软件与其他非系统库函数连接的软件以其他许可方式一起发布。
Jab
Jabber许可证的全称是Jabber Open Source License,由美国Jabber.Com, Inc.公司提供。Jabber许可证在源代码的复制、发行规定方面基本上和其他许可证没有什么特别,但有一些细节规定值得借鉴:
可以将通过该许可证获得的源代码及修改过的源代码与其他类型的不受该许可证约束的代码结合,以新产品的形式发布,只要其中经该许可证获得的源代码及修改过的源代码能以与该许可证的要求类似的、符合OSI认证的其他开源软件许可证的方式发布。
明确了需将源代码置于公众可以得到的状态的时间至少应为12个月。
第三方对法定权利的声明。假如使用者发现通过本许可证获得的源代码及应用程序接口中有一方拥有的知识产权,应单独在源码的发布时冠以“LEGAL”为抬头的声明,写明知识产权权利要求的细节,提请源代码的接受者知道自己获得了哪些知识产权的授权,让源码的接受者知道如何与知识产权权利人联系。
细化了该许可证终止的情形,包括不按该许可证的要求发布和使用源代码、发生专利侵权诉讼。
Com
规定可以将源代码及修改过的源代码与其他类型的不受本许可证约束的代码结合,以新产品的形式发布,只要其中经该许可证获得的源代码及修改过的源代码能按该许可证的要求发布即可。
细化了该许可证终止的情形,包括发生专利侵权诉讼。
明确了一个独立承担责任的原则,就是假如按该许可证使用源代码的使用者将获得的源代码应用于商业使用,那么他就要对在商业应用中出现的由于使用该源代码程序而产生的侵权诉讼承担完全责任。这一条规定是比较特殊的,绝大多数开源软件许可证都不这么要求。
IBM
IBM许可证的全称是IBM Public License。在满足OSIA开源软件许可证认证标准的前提下,IBM许可证还有如下一些细节性规定:
明确了专利授权。一般的开源软件都明确源代码的版权人将自己的修改权、复制权等版权权利向公众许可,但保留署名权,而IBM许可证在此基础上还明确假如源代码中含有专利权,源代码专利权人将复制、使用的专有权利向公众许可。
细化了该许可证终止的情形,包括不按该许可证的要求发布和使用源代码、发生专利侵权诉讼等。
像Common许可证一样,IBM许可证也明确了独立承担责任原则,即假如按该许可证使用源代码的使用者将获得的源代码应用于商业使用,那么他就要对在商业应用中出现的、由于使用该源代码程序而产生的侵权诉讼承担完全责任。
开源协议的选择
世界上的开源许可证,大概有上百种。很少有人搞得清楚它们的区别。即使在最流行的六种—-GPL、BSD、MIT、Mozilla、Apache和LGPL—-之中做选择,也很复杂。乌克兰程序员Paul Bagwell,画了一张分析图,说明应该怎么选择。这是我见过的最简单的讲解,只用两分钟,你就能搞清楚这六种许可证之间的最大区别。
开源大法好,开源得永生