内容


GPLv3:新版本的 General Public License 对于软件开发人员意味着什么

法院在过去的十年中,软件开发实践中最惊人的变更之一是“复合”软件系统的构建 —— 一种由自产的、开源的和第三方组件构成的组合,这使得开发团队可以快速地交付先进、全面的解决方案。然而,不受监管地使用开放源码和第三方组件增加了风险。这种方式容易因此侵犯知识产权,产生未知的特许权义务,增加维护成本,并引入未经确认的安全漏洞。

在本文中,我将介绍由创建复合软件系统而引起的复杂性问题的相关背景,并阐述最新版本的 General Public License (GPLv3) 在许多重要的领域如何影响开发监管(governance)。

背景

开源软件是极好的资源,因为它让开发人员复用现有的代码来满足具体的需求,而不是从零开始写新的软件。还有额外的好处是,能满足用户和开发人员需求的开源组件会持续存活,并随着时间的推移,会由许多不同的人对现存代码进行持续的审查和改进。渐渐地,所开发的软件将演进为错误更少(bug-free)、更有用,而且更健壮。

开源代码在众多开源项目中开发。就在写作本文的时候,已经有超过 180,000 个独立的开源项目(尽管不是所有的项目都是活动的),并且每天都在产生着更多的开源项目。根据定义,开源代码是共享的,因此,开源项目一般存放在可公共访问的 Web 上(尽管最初的时候代码是通过磁带和电子公告板进行共享的,并且有时可以从其他来源,例如从图书中获得)。大量的 Web 站点存有开源项目。我的公司,黑鸭软件 (Black Duck Software),已经确认出超过 3000 个下载站点,它们包含了超过 4 亿 8 千 5 百万个开源文件。

自从 2006 年 1 月以来,开源软件许可领域中有史以来最大的争论一直围绕着 GNU General Public License (GPL) v3 的制定。1991 年发布的 GPLv2 是监管开源代码的最知名且使用最广泛的许可证之一。它被应用于 Linux 内核以及许多其他被广泛使用的开源项目。在全球范围内,GPLv2 已经影响了数以千计的公司以及它们的应用程序开发团队,他们将 GPL 监管的代码作为它们产品的一部分。GPL 的基本权益是任何人均可以使用、修改和再分发由许可证监管的代码,约定 1) 任何分发副本都包含一份许可证的副本,并且 2) 衍生产品的所有源代码都是可自由获得的。

版本 3 如何扩展 GPL 的适用范围

在经过多个月的制定之后,GNU General Public License 版本 3 (GPLv3) 由自由软件基金会 (Free Software Foundation, FSF) 于 2007 年 6 月 29 日正式发布。GPLv3 的术语与 GPLv2 相似,但扩展了 GPL 的适用范围,甚至更深入涉及到像专利和数字版权管理这样的领域。GPLv3 在四个关键的方面(分别涉及互惠权益、数字版权管理、专利,和许可证兼容性)包含了影响软件开发的条款。以下是这些条款的简要概括:

互惠权益(衍生产品)

同 GPLv2 一样,GPLv3 是互惠的许可证。这意味着如果应用程序加入了 GPL 所监管的代码,或者,是使用了“基于 GPL 监管代码的产品”,并且因此而产生的应用程序是用于分发的,那么它必须在 GPL 下分发。GPL 本身规定,任何分发副本都必须包括其源代码和 GPL 许可证副本。多年来,对于在软件这一前提下“基于……的产品”或“衍生产品”这两个术语的含义有相当多的争议。举例来说,Free Software Foundation 认为动态地链接文件也产生了衍生产品。因而,在他们的世界观里,即使将您的专有代码链接到 GPL 监管的 .DLL 文件或其他共享的库中,都应该强制将源代码的公开发布。这种诠释释无疑令开发组织在使用 GPL 许可的代码用作开发过程一部分的问题上小心谨慎。

GPLv3 在关于衍生产品具体由什么构成的问题上增加了更多的透明度。举例来说,GPLv3 规定,如果程序是“特别设计成”使用 GPL 监管的库的,那么该库即被认为是整体产品的一部分,并且整个应用程序受 GPL 监管。然而,如果可以使用另一个库将 GPL 库完全置换(也即,如果应用程序不是“特别设计成”使用 GPL 库的),那么该库就不是整体产品的一部分,并且不会受许可证的监管。

数字版权管理(嵌入式设备)

“数字版权管理” (Digital Rights Management, DRM) 描述了一种技术方法,通过它,消费型设备的发行人可以防止用户将篡改的代码部署到设备上。FSF 想要定义 DRM 的含义,至少对于涉及 GPLv3 的代码。要这样做,GPLv3 包含了以下内容:首先,许可证禁止将 GPLv3 本身用作 DRM 的一部分。其次,FSF 增加了条款,用于确保任何用户可以修改安装在消费型设备上的 GPLv3 代码,以及在设备上重新加载代码被修改过的版本。除了提供 GPLv3 之下源代码的义务以外,许可证还要求发行人提供在可应用的设备上重新加载已修改代码所需的所有安装信息。虽然有一些内在的局限性,但 GPLv3 的 DRM 条款将很自然地有利于消费型设备的制造者和发行人,这是由于它们一旦使用了 GPLv3 代码而履行相应义务,从而获得的宽松政策。

专利(再分发代码)

新的许可证提供了与可能应用于已开发代码的专利义务相关的指南。GPLv3 包含了一个广泛的扩散专利许可 (expressed patent license)。简单地说,这意味着如果开发人员修改了 GPL 代码并且重新发布它,该开发人员即自动地向所有可能应用于整个应用程序的专利授予专利许可证。任何衍生产品都因此得益于此专利许可证。通过这种方式,FSF 试图确保用户拥有任何已被修改的 GPL 监管代码的广泛专利版权。GPLv3 还包含了“专利保护”条款,意思是,如果 GPL 代码 (GPL'd code) 的用户提出了任何基于该代码的专利声明,那么该用户将丧失他们对这一 GPL 下代码所拥有的 GPL 许可证。

许可证兼容性(多重许可证问题)

GPL 版本 3 并不是要取代版本 2。它们将并存,因此开源项目可以选择在任一许可证版本下发布他们的代码。GPLv2 下的大部分代码可以被用户转换为 GPLv3(这是在 GPLv2 下通常被允许的惯例)。然而,一些项目 —— 最著名的是 Linux 内核 —— 不是在包含这种权限的许可证版本下发布的。那些项目不计划在 GPLv3 下发布他们的项目。

GPLv3 中其他的许可证兼容性条款是同样需慎重对待的。新的许可证向开发人员提供了可以向许可证添加某些规定的额外条款的权利,从而令其代码与其他开源许可证兼容。开发人员一直在申请这个权利,而现在,举例来说,只要将所需的条款添加到他们自己所制定的 GPLv3 版本中,就可以将流行的 Apache 许可证所监管的代码和在 GPL 下编写的代码进行结合。如果组织发布 GPLv3 代码,那么它们将需要明了那些额外的条件。

最后,GPLv3 包含了让开发人员将 GPLv3 代码与 Affero 许可证涵盖的代码相结合的语言。Affero 许可证去掉开发人员在 GPL 中发现的一个“漏洞”,即如果的应用程序是基于 Web 的(例如在基于 Web 的搜索引擎中,等等),由于 GPL 要求开发人员发布源代码而带来的一个“漏洞”。虽然这个条件在 GPLv3 的正文中不存在,但是开发人员可以将 GPLv3 的代码与 Affero 代码相结合,而 Affero 条款将应用于整个产品。

结论

对于进行异构代码汇集和代码复用的应用程序开发团队来说,GPLv3 许可证的复杂性说明了对代码组件管理和监管的需求。由于有了这些对 GPL 最新的变更,应用程序开发人员、经理,及其法律顾问必须研究这些变更的含义,并且制定关于如何最佳地在他们的项目中包含基于 GPLv3 代码的决策。

要了解对引入 GPLv3 的进一步分析,请参见 www.BlackDuckSoftware.com 的 Open Source License Resource Center

关于 Black Duck Software

Black Duck Software 软件提供产品和服务,用于通过受控地使用开源和第三方代码来加速软件开发。Black Duck Software 令公司能够缩短投放市场的时间 (time-to-market),并且减少开发和维护成本,同时减少了与复用相关的风险和挑战;还包括隐藏许可证义务、安全脆弱点和版本扩散。公司的总部设在波士顿附近,并且在旧金山、阿姆斯特丹和香港设有办公室,并且有遍布全球的分布合作伙伴。要了解更多信息,请访问 www.blackducksoftware.com


相关主题

  • 您可以参阅本文在 develperWorks 全球网站上的 英文原文
static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=301439
ArticleTitle=GPLv3:新版本的 General Public License 对于软件开发人员意味着什么
publish-date=04152008