从FFmpeg耻辱榜看开源软件的“潜规则”

话题：FFmpeg是一个开源免费跨平台的视频和音频流方案，属于自由软件，采用LGPL或GPL许可证。2009年，韩国名软KMPlayer被FFmpeg开源项目发现使用了它们的代码和二进制文件，但没有按照规定/惯例开放相应说明/源码。被人举报后，KMPlayer进入了FFmpeg官网上的耻辱黑名单。最近，国内也有同样的产品被列入黑名单。您认为，国内开发者应如何遵守开源界的基本规则和潜规则？





请尊重开源软件作者

（约定: 这里的开源软件是指自由、开源软件）







龙辉，咨询顾问。关注自由、开源软件, 饲养着灰狐 http://huihoo.com
因为最近需要转换一个视频文件，我第一时间想到了MediaCoder——一个开源的音频/视频批量转码工具，因为几年前接触过这款软件，觉得挺不错，有很多的用户和支持者。可是这次发现它已经在几年前就闭源了，而且连sourceforge.net的项目主页和文件存档都没有了，我感到很遗憾。

我觉得这件事并非一个特例，而是一个普遍现象。

做开发的朋友都很清楚，开源软件是个巨大的宝库。在开源世界里几乎能找到所有商业软件的替代品，大部分开源软件也都能满足你的需要。甚至有很多开源软件已远远超过了商业软件，如Linux、GCC、Apache HTTPD等。

现在开发人员每天都在使用大量的开源软件，但很少人会想到回馈和贡献。同时还出现这样的现象，一些开发者和软件企业在封装大量开源软件后就贴上自己的商标，说成是自主知识产权的东西。

这里需要提醒的是：我们在使用开源软件时要遵循相关的许可协议、以及一些开源界普遍存在的规则，不要把优秀的开源软件整合在一起分发后就没有任何的声明和感谢了，这样不好，这是对开源软件作者的不尊重。

开源软件有很多的许可协议可以采用，常用的有GPL、LGPL、BSD、Apache等，个人和企业可根据自己的实际情况加以选择。对于非代码资料如文档、视频等可采用创作共用CC版权协议。一些商业化公司也开始将它们自己的技术文档以CC的方式进行更加广泛的传播和分发。

对企业来说，公开一些东西不太现实，但企业完全可以在自己产品的版权信息里引入第三方开源软件的版权申明，这点对企业来讲并不难。

Google、Facebook等互联网巨头在这方面都做得不错。虽然最近Google Android和Linux Kernel社区出现了一些问题，但Google仍在不断地发布自己的开源项目，丰富开发者社区，方便更多的开发者。或许有人觉得这些开源软件是这些公司里过时或不好的东西才放出来的，但不可否认，我们确实从这些项目中获得了很多帮助。国内很多公司也在模仿和跟进，但开放的程度仍然很低，希望能早点看到更高质量的东西发布出来。而不要整天都在喊开放这个、开放那个、开放平台什么的，我们需要实实在在的开放和诚意。

如果个人开发者能将自己认为不错的作品和项目开放出去，并得到用户认可，那一定是件很快乐的事情，也是开发者自身能力的极好体现，对其职业发展也是有帮助的。个人或团队在有一定技术储备后可考虑成立公司并提供开源软件的商业化服务。国外这样成功的公司很多，如Rea Hat、JBoss、MySQL等。国内的环境与国外的环境无法相比，成功的几率和机会相对少，但也不妨尝试一下。

大型企业，尤其是大型互联网企业也可以考虑在主流的开源项目上部署一些兵力，并鼓励其员工更多参与到开源项目中来，提高公司在开源项目中的贡献量，进而提高其在开源项目中的话语权并扮演重要角色。毕竟现在是一个开放的时代，想自己把一个封闭的东西玩大很难，必须有开放的心态去应对各种变化。Red Hat、Novell、Google等在Linux Kernel里就扮演着重要角色，这对自身的发展起到了关键作用，值得国内领先的互联网企业借鉴。一些有实力的公司可以雇用专职人员参与到这些项目中来，淘宝网就挖来了王文彬博士和章文嵩博士，可以理解为这是淘宝网在Java、Linux方面的人才部署。

接下来看看国内几个成功的开源项目，如：SkyEye仿真器项目，Linux Virtual Server（可能是国内最成功的开源项目），这些项目的发起人都有很高的学历背景和技术水平，对开源运动有着深刻认识。其主持的开源项目国际化程度非常高，影响力比较大，这些项目也多数围绕Linux展开。而基于Windows平台的开源软件却没有什么值得称道的。其实，Windows平台的开源软件有着巨大市场，但在国内的发展却并不理想，本来MediaCoder有这个可能，可是它错误选择了闭源，挺可惜。个人觉得Windows平台的开源项目可从客户端软件入手，因为这样的产品用户覆盖面很广，只要产品好用，一定能得到极好的推广，有兴趣的朋友可以从开源浏览器、开源影音播放器、开源即时通信等有广泛用户基础的产品入手。尤其是开源即时通信，这块虽是QQ的地盘，但若能给用户提供另外一个选择，这将会是件非常有意义、非常酷的事。

最后，我想提醒大家在使用开源软件时遵循相关许可协议，请尊重开源软件作者，尊重他人也就是尊重自己。




开源软件著作权与许可证剖析



冯晓焰，英特尔开源软件技术中心 中国首席开源科学家
一两个月前，国内的一些开源社区论坛上纷纷扬扬出现了许多有关国内某著名公司内嵌媒体播放器产品涉嫌与开源软件许可证冲突，及来自国内的某著名播放器开源项目被列入FFmpeg耻辱榜名单的消息。围绕这些消息有诸多的讨论，笔者恰巧因为工作性质，积累了一定经验，希望与大家分享。当然有关软件著作权和许可证的问题更多是法律问题，笔者以下的这些经验与看法，更多是从技术人员角度出发。在应对较复杂的情况时，应通过咨询专业人士（如律师）得到法律上正确的答案。

首先，著作权保护的是表现形式。软件源代码及二进制可执行文件、 用户界面、文档及帮 助等都可以是保护对象。著作权不保护思想，软件的具体算法（思想、处理过程、操作方法或者数学概念）就不在保护之列。算法可以通过专利进行保护。

软件著作权保护期长。事实上，自计算机及软件出现以来，至今所有的软件都还处在著作权保护之下。

软件的著作权自从软件完成以后，自动产生，并不需要经过著作权登记步骤，也并不需要如“©著作权所有”等形式的专门说明。有些开发者在参考一些标准算法时，可能会直接引入参考书中的范例程序，即使没有著作权保护的声明，这也多半会引发侵犯著作权的风险，除非在书中明确说明“作者自动放弃对本书的所有范例程序的著作权，允许读者自由引用”等，或仅仅为教学目的而引用。



陈绪，英特尔开源软件技术中心 中国开源战略经理
软件应用应当遵守许可证的条款。只有软件著作权的拥有者或者获得再许可权利的被许可人才可以指定或改变软件许可证的条款（但再许可的条款不得超出原许可的范围）。

开源软件著作权通过不同的开源软件许可证得到保护，目前不同开源项目采用的开源软件许可证虽然有多种，但主要可分为两种类型：一种是Reciprocal Licenses, 例如 GPL和类GPL；另一种是Permissive Licenses, 例如BSD，MIT及Apache。GPL（GNU General Public License）及LGPL（Lesser GPL）是开源软件项目采用最多的软件许可证。据统计，在SourceForge上的开源软件有超过70%的都是采用GPL或LGPL，包括Linux内核，GNU Toolchain 在内的许多重要的开源软件项目都是采用GPL/LGPL许可证。限于篇幅原因本文主要围绕GPL/LGPL进行讨论。

GPL/LGPL具体条款有数百行，作为软件开发人员没有必要仔细阅读每一条款，但是必须了解以下特性，这样可以帮助我们在涉及开源软件开发的早期阶段避开可能出现的著作权陷阱。

GPL/LGPL有版本2和版本3的区别，版本2在1991年公布，版本3则在2007年公布。它们在大多数条款上都是一致的，其区别主要在对专利的处理、关于对动态链接的认识以及更为复杂的Anti-Tivo问题上。在以下讨论中如果没有明确指明版本，则认为对所有版本适用。如果有区别，则会指明版本。

所有的GPL/LGPL软件在提供源代码的前提下可以被自由复制、使用及分发，而不管是为商业目的还是非商业目的。值得注意的是，所提供的源代码必须是完全的，除了包括源程序外还必须包括编译链接脚本，可以编译链接直至产生二进制可执行代码。同时，要求必须在进行分发的同时提供源代码。可以在提供二进制可执行程序的同一个软件包中提供，也可以在提供下载软件的网页上包括下载源代码的URL，当然也可以提供一纸承诺，阐明在用户要求时，用何种方式可以提供源代码。后一种方式一般不为我们所推荐，因为软件分发主体必须保证在用户使用分发软件的生命周期内一直遵守承诺，这提高了软件分发的成本。另外还必须注意的是，不管所分发软件的原作者或上一级分发者是谁，提供源代码的主体必须是分发者，而不能将责任追溯。

基于GPL/LGPL派生的软件必须保持GPL/LGPL许可条款，这通常称作GPL/LGPL的“Copy Left”特性。在这里，派生的定义是我们需要特别注意的。一般来说，直接包含/使用被保护的软件的源代码，复制部分源代码等，明显可以列为派生一类。将某软件源代码从一种程序设计语言一行对应一行“翻译”成另一种程序设计语言再进行编译链接，同样是派生。针对GPL，还有一种隐含的派生是对运行库的链接。静态链接是非常明确的派生。动态链接技术则在GPL版本2与版本3之间有区别。版本2由于发布较早，其似实动态链接技术还没有广泛采用，因此没有定义。版本3则非常明确认为是派生，必须遵守GPL的开放源代码要求。

GPL/LGPL之间的差别在于LGPL大多数情况下适用于作为运行库的软件许可，程序仅与LGPL代码进行链接，而不直接将其作为程序的一部分时，此时允许程序保持自己的原有许可证，而不认为是派生软件。

GPL版本3除了对动态链接给出明确说法外，对专利也有明确定义，认为遵从GPL版本3的软件的专利，自动赋予软件的使用/分发者专利的使用权，前提是软件的使用/分发者遵从GPL版本3的所有条款。相应地，GPL版本2在此处没有明确定义，法律上较为模糊。GPL版本3与版本2的另一个重大区别在于所谓的“Anti-Tivo”条款：针对消费类产品，GPL版本3要求除了提供源代码外，还必须提供安装信息。与对源代码的要求类似，安装信息必须是完全的，甚至包括数码签名等一些安全必需的信息，以便使用者能有足够信息进行重新安装。

如上所述，GPL尤其是GPL版本2中还有一些条款不甚明确，导致了一些法律上的歧义，我们必须引起注意。另外值得指出的是，针对一些GPL条款，开源软件社区与法律界有不同的解释。其中最为明显的就是GPL版本2中的动态链接问题。法律界认为GPL版本2没有给出明确说法，因此法律上是模糊的。但是开源软件社区的态度是明确的，动态链接导致派生，因此必须GPL你的代码。所以GPL版本3就进行了如此的定义。一个直接的例子就是：因为Linux内核遵从GPL版本2，因此所有的Linux内核态设备驱动程序在开源社区内都被认为是Linux内核的派生必须开源。

或许有一些开源软件的使用/分发者在某种程度上违反了相应的软件许可证，可是发现并没有付出什么代价，会有违反了也不过如此的想法。这确实也可能是一种事实。但是这并不代表就没有问题，像文章开头提到的开源软件耻辱榜就是一种“道德法庭”。另外更可能发生的是，因为违法者在经济上还比较弱小，法律诉讼并不能给软件著作权拥有者带来很大的经济利益，所以著作权拥有者可能在一边静观事态发展。一旦发现，违法者在经济上有了极大发展，能够带来足够经济利益，诉讼就会发生。前几年，业界所熟知的SCO诉IBM案即是一例。撇开这个案子的复杂历史渊源，这里想强调的是IBM成为被告的原因之一是有买单的能力。因此，我们的企业尤其是大企业特别要注意这个问题，因为你们更容易陷入这种法律诉讼。如果你是一家小企业，相信你也想过有做大做强的那一天，同样不希望官司缠身。

除了GPL之外，还有这种“Copy Left”特性的软件许可证包括Mozilla Public License（MPL），Eclipse Public License（EPL）等，笔者也并不完全了解其中所有条款，也就不再一一叙述了。与GPL的这种“Copy Left”类软件许可相对应，还有一类更为自由的软件，其中以FreeBSD最为典型，包括Apache License，MIT License等。它们除了可以自由使用、分发外，并不要求再分发时必须开源，使用者甚至可以自由选择新的开源软件或专有软件许可证。英特尔公司的开源的EFI Framework项目即是采用FreeBSD的一例。

还有一个常见的问题是双许可证问题，软件可能同时具有开源软件许可证如GPL及私有软件许可证。在这种情况下，软件的使用/分发者拥有自由的权利选择任意许可证。需要说明的是，一旦选定许可证，就必须遵守。而且，同时只能选择其中之一，而不是选择两个中的条款进行混合。假定有一种软件库同时具有GPL及私有软件许可证，如果开发者基于其上开发的应用程序不想开源，那么意味着开发者选择了私有软件许可，开发者就有可能需要支付相应的私有软件许可费用。如果开发者不想支付费用，那么意味着开发者选择了GPL，开发者开发的应用程序就必须以GPL作为许可证等，必须开源。有相当多的开源软件项目的商业模式是建立在双软件许可证的基础上的。

希望我们国内的开源软件开发人员和爱好者能更多地关注软件著作权和许可证问题。首先，这是一个法律问题，作为开发人员需要了解，在碰到新问题时，如果不确信，通常可通过咨询知识产权方面的律师得到答案，而不是想当然，以免带来不必要损失。