GPL LGPL Apache2.0 BSD 开源协议扫盲帖

BSD (Berkeley Software Distribution,伯克利软件套件)是Unix的衍生系统,在1977至1995年间由加州大学伯克利分校开发和发布的。

  历史上, BSD曾经被认为是UNIX的一支——"BSD UNIX", 因为它和AT&T UNIX操作系统共享基础代码和设计。在20世纪80年代,BSD广泛的被工作站级别的厂商所接受,并且衍生出了许多变形的UNIX授权软件。比较著名的例子如DEC的Ultrix,以及Sun公司的SunOS。这可以归功于BSD License相对而言比较地宽松,并且大多数这时成立的科技公司的创始人本身对UNIX系统的熟悉。

  1990年代,BSD很大程度上被System V4.x版以及OSF/1系统所取代,晚期的BSD版本为几个开源软件的开发提供了平台并且一直沿用至今。

  今天,“BSD”并不特指任何一个BSD衍生版本,而是类UNIX操作系统中的一个分支的总称。

在射手播放器和QQ影音为GPL吵得不可开交的时候,CBer应该少一些无知的谩骂,多学习一下开源许可证的基本知识。要骂也要骂到点子上,别不分是非,指着别人脚骂别人鼻子。在中国这样一个几乎完全不尊重版权,开源软件处于萌芽发展的国家,开源是一个及其冒险的选择,你做出的产品顷刻之间便会被人抄袭。在中国,选择开源是需要勇气的,既然选择了它,就选择了坦然面对这个残酷的现实,开源可不是简单开放了源代码了事就可以了的。

首 先,开源并不代表放弃自身的权力,相反,开源软件之所以存在,正是它非常注重这种权力,并且把这种权力赋予了软件的所有使用者。小心的选择许可证是开发开 源软件的第一步,也是每一个开源软件作者所必须要了解的,这代表了你对你的软件的最基本态度。很多的时候,这背后也隐藏着某种商业策略,特别是有商业公司 支持的项目。

比如Android为什么是Apache 2.0而不是LGPL/GPL发布?为什么Linux是以GPL发布?其中绝对不是简简单单的看哪个许可证用得多就选择哪个,而是深思熟虑的结果。千万不 要小看这个选择,一个许可证之于软件就相当于价值观之于普通人,代表了这个软件的基本品性。一个错误的许可证选择可能会直接导致整个项目的失 败,XFree86就是一个好例子,所以,选择许可证是一件小心、谨慎的事情。

各种开源的许可证主要的限制还是在redistribution(发布),所以个人/商业公司开发的软件包含了GPL的代码,只要你不发布,是可以任意使用的。

GPL

这里不想再解释长篇的GPL译文和更长的FAQ。 简单说,GPL软件的使用者有权力得到软件的代码,只要使用了GPL,在发布(redistribution)的时候,整个项目也必须是GPL的,即主程 序和静态链接的库(Linux的.a和Windows的.lib)必须是GPL的,动态链接库(Linux的.so,Windows的.dll)必须是比 GPL兼容的。所谓GPL兼容,也就是GPL软件中可以使用的库,这些许可证必须比GPL弱(如LGPL,BSD),而不能是某个商业许可证。这里有一个 兼容列表 List of FSF approved software licenses。正因如此,GPL是带有很强的传染性,只要你的软件使用了GPL的代码,那么就请以GPL开放源代码吧,并且你的项目中也不能有任何和GPL不兼容的库。

LGPL

GPL 带有很强的传染性,那么如果一个库使用GPL发布,那么使用这个库的所有软件也必须使用GPL发布,这对不想开放源代码的商业软件来讲是致命的打击——你 可以不使用其他的库,但最基本的libc是无论如何绕不开的,如果libc是以GPL发布,就相当于所有软件必须以GPL发布了。所 以,LGPL(Lesser GPL)诞生了。LGPL定义为,在以LGPL发布的库的基础上开发新的库的时候,新的库必须以LGPL发布,但是如果仅仅是动态链接,那么则不受任何限 制。这样商业软件就可以随意的使用LGPL的库了。因此,LGPL也具有传染性,但限制在在其基础上开发的库上,而并不限制使用它的程序本身——它的传染 性远小于GPL。

BSD、Apache 2.0

相对GPL/LGPL的开放源代码,BSD,Apache 2.0就宽松许多——商业软件可以任意的使用BSD,Apache 2.0发布的软件代码,而不需要开放源代码,只需要提及代码的原出处就可以了。BSD和Apache 2.0提及的方式稍有不同,具体可以参考协议的详细内容。它们是GPL兼容的。

了解了几种常用许可证的异同,再来看许可证的选择。

Android 使用宽松的Apache 2.0发布,因为Google作为一个商业公司,并不想失去商业软件的支持,它希望团结一切可以团结的力量加入的Android的开发中来,壮大自己的阵 营,使用Apache 2.0就无可厚非了。而Google本身,并没有丧失对Android的控制权,不会担心另外一个公司拿走了Android的代码开发出一个闭源 Android的对手。因为,只要Android不断的出新版,社区不停的跟进,并且不停的修改API,其他基于Android开发的公司不得不把自己的 Patch提回到主干上,否则,必然将耗费大量人力物力在维护自己的Patch上(钱这方面你斗得过Google?),得不偿失。而且,闭源之后,与整个 社区为敌,作为一个定位软件平台的项目,会流失大量应用软件开发者,以小博大,任何一个商业公司都不会干这种胜算不高的蠢事。

在看以 GPL发布的Linux为什么比以BSD发布的FreeBSD成功。其实正是因为GPL的传染性。当一个开发人员在Linux基础上开发一个新功能之后, 不得不以GPL开放源代码,贡献回Linux,这样Linux本身才能越来也越壮大而且留住了相当的开发人员,形成了一个 优秀软件->很多使用者和贡献者->贡献->更优秀的软件->更多的使用者和贡献者... 的良性循环。

正如每一个成功的男人背后都有一个女人,每一个成功的开源软件背后都有一个符合它策略的开源许可证。许可证明确的版权划分,明确的版权划分为软件发展提供 了一个良好的环境。正是因为老外重视版权,天天为版权争吵,才会有一个良好的商业软件和自由软件大环境。相对的,漠视版权的中国无论商业还是开源软件,才 会沦落到毫无创新能力,只能给外国打打下手,作点边角外包的境地。

最后,回到射手和QQ,他们都使用的ffmpeg作为解码器。 ffmpeg本身是LGPL的,使用它开发闭源软件是无可厚非的。但是ffmpeg有部分可选GPL的解码器主要是xvid和x264,由于GPL的传染 性,打开了可选的GPL解码器后的ffmpeg也成了GPL的,所以,基于ffmpeg的射手播放器和QQ影音从法律上讲,必须以 GPL发 布源代码,这个是强制的,不是可选项。射手的申明中引用的GPL FAQ的话已经很明确了,GPL软件中使用的动态链接库必须是GPL兼容的,也就是说,射手的字幕模块(它是动态链接到射手播放器本身),也必须是使用 GPL兼容的许可证发布,闭源显然是一个错误。

射手播放器的作者Tomasen发现了这个错误之后,很快开放了这部分的代码,弥补了自己的失误,这为射手播放器以后的发展扫清了一个大障碍,下一个障碍 是把非GPL兼容的CoreAVC商业解码器踢出发行包,这不是一个GPL软件该有的东西。理清了许可证,和赋予开发者的权力,才有可能吸引到开发者。

时间: 2024-10-25 11:49:54

GPL LGPL Apache2.0 BSD 开源协议扫盲帖的相关文章

四大开源协议比较:BSD、Apache、GPL、LGPL

现今存在的开源协议很多,而经过Open Source Initiative组织通过批准的开源协议目前有58种.我们现在常见的开源协议如BSD, GPL, LGPL,MIT等都是OSI批准的协议.如果要开源自己的代码,最好也是选择这些被批准的开源协议. 这里我们来看四种最常用的开源协议及它们的适用范围,供那些准备开源或者使用开源产品的开发人员/厂家参考. BSD开源协议(original BSD license.FreeBSD license.Original BSD license) BSD开源

五种开源协议的比较(BSD,Apache,GPL,LGPL,MIT) – 整理

当Adobe.Microsoft.Sun等一系列巨头开始表现出对"开源"的青睐时,"开源"的时代即将到来! 最初来自:sinoprise.com/read.php?tid-662-page-e-fpage-1.html(遗憾的是这个链接已经打不开了),我基本未改动,只是进行了一些排版和整理.参考文献:http://www.fsf.org/licensing/licenses/ 现今存在的开源协议很多,而经过Open Source Initiative组织通过批准的开

开源协议BSD的汉化版

找一份中文版的开源许可真费劲,花一阵功夫才在DotNetNuke翻译的网站上看到这一段: 任何获得本软件副本及相关文档文件(下面简称为"软件")的个人都可以免费获得不受限制处置本软件的权限,包括不受限制地使用.复制.修改.合并.出版.分发.重新许可或者销售本软件的副本,并且在满足下述条件时,允许本软件的受让人获得下述权限: 在本软件的所有或者重要部分中包含上述版权公告信息和本权限公告信息. 本软件不提供保证,不包含任何类型的保证(无论是明指的还是暗喻的),包含但不限于关于本软件的适销性

Java程序员需要了解的五种开源协议

五种开源协议的比较(BSD,Apache,GPL,LGPL,MIT). 当Adobe.Microsoft.Sun等一系列巨头开始表现出对"开源"的青睐时,"开源"的时代即将到来! 现今存在的开源协议很多,而经过Open Source Initiative组织通过批准的开源协议目前有58种(http://www.opensource.org/licenses/alphabetical).我们在常见的开源协议如BSD, GPL, LGPL,MIT等都是OSI批准的协议.

实用文章:常用开源协议详细解析

原文:http://www.cnbeta.com/articles/28880.htm 开源在今天的软件业已经很普遍,但开源是否意味着使用者可以对开源后的代码为所欲为呢?答案是否定的.开源运动同样有自己的游戏规则和道德准则.不遵行这些规则不但损害开源运动的健康发展,也会对违规者造成名誉和市场上的损失,更可能陷入法律纠纷和赔偿. 首先,要对几个概念有所了解: 1. Contributors 和 Recipients Contributors 指的是对某个开源软件或项目提供了代码(包括最初的或者修改

各种开源协议介绍

现今存在的开源协议很多,而经过Open Source Initiative组织通过批准的开源协议目前有58种(http://www.opensource.org/licenses/alphabetical).我们在常见的开源协议如BSD, GPL, LGPL, MIT等都是OSI批准的协议.如果要开源自己的代码,最好也是选择这些被批准的开源协议. BSD开源协议 BSD开源协议是一个给于使用者很大自由的协议.基本上使用者可以"为所欲为",可以自由的使用,修改源代码,也可以将修改后的代码

开源协议的区分

开发中经常遇到要使用第三方类库, 查看类库的协议保证要求闭源的商业软件的利益是必备基本功,下面也是参考了网上的文章. BSD开源协议(original BSD license.FreeBSD license.Original BSD license) BSD开源协议是一个给于使用者很大自由的协议.基本上使用者可以"为所欲为",可以自由的使用,修改源代码,也可以将修改后的代码作为开源或者专有软件再发布. 但"为所欲为"的前提当你发布使用了BSD协议的代码,或则以BSD

五种开源协议(GPL,LGPL,BSD,MIT,Apache)介绍

商业化的软件应该主要选用MIT或者Apache license的开源系统作为插件. 什么是许可协议? 什么是许可,当你为你的产品签发许可,你是在出让自己的权利,不过,你仍然拥有版权和专利(如果申请了的话),许可的目的是,向使用你产品的人提供 一定的权限. 不管产品是免费向公众分发,还是出售,制定一份许可协议非常有用,否则,对于前者,你相当于放弃了自己所有的权利,任何人都没有义务表明你的原始作 者身份,对于后者,你将不得不花费比开发更多的精力用来逐个处理用户的授权问题. 而开源许可协议使这些事情变

[转载]五种开源协议(GPL,LGPL,BSD,MIT,Apache)

转自mic_hero的博客 什么是许可协议? 什么是许可,当你为你的产品签发许可,你是在出让自己的权利,不过,你仍然拥有版权和专利(如果申请了的话),许可的目的是,向使用你产品的人提供 一定的权限. 不管产品是免费向公众分发,还是出售,制定一份许可协议非常有用,否则,对于前者,你相当于放弃了自己所有的权利,任何人都没有义务表明你的原始作 者身份,对于后者,你将不得不花费比开发更多的精力用来逐个处理用户的授权问题. 而开源许可协议使这些事情变得简单,开发者很容易向一个项目贡献自己的代码,它还可以保