简介

GPLv2

GPLv2 发布于 1991 年,在 24 年后仍然是所有自由软件许可证类型中最为广泛使用的一种。⑤ GPLv2 的前序部分主要重申了许可人的社会意图。在前序部分和许可证的第一节中都可以找到如下要求:源码或二进制代码作品在分发时必须附随完整的许可证文本,以确保用户实际注意到其权利。针对此要求引发的合规投诉在所有投诉中所占的比例非常大,这主要是因为用户在购买实体产品后未获得有关存在 GPL 软件和适用许可条款的信息。最有效的合规管理方式是在编译、打包和分发软件时将许可文本视为“生成目标”,以便许可文本能够与软件的其他附随文件一起,在一个产品包中经过同样的生成和认证阶段(与二进制代码本身的生成、测试和打包方式一样)。很多与 SFLC 合作的公司都已通过类似方式在这些节点或类似节点完美地解决了合规问题。这些公司中不乏业务形式多样的大型公司,其内部有半独立的业务部门来制造和分发包含 GPL 软件的产品。

( ⑤http://www.blackducksoftware.com/resources/data/top20opensourcelicenses.)

GPLv2 许可证开头提出的另一项合规义务是不得修改许可证文本。偶尔会有分发者想要删除许可证中的文字,或者对条款增加救济或其他“辅助”条款,这都会带来合规问题。与 GNU 家族的其他许可证一样,GPLv2 是自由软件基金会的版权作品,只允许原文复制。

第 1 节:复制和分发未经修改的程序版本

本节讨论原样复制和分发所收到程序的权利,规定如下:

  • 在显著位置显示正确的版权声明;

  • 保留或增加软件维保免责声明,除非您愿意提供维保服务,这当然也是可以的;

  • 保留所有关于 GPLv2 的声明;以及

  • 提供许可证本身的文本。

与美国流行的观点正好相反(直到 1978 年,想要获得版权保护都必须有版权声明),伯尔尼公约规定,版权的保护不需要声明和登记。在美国和世界上的大多数国家/地区,代码一旦写成,每个开发者就拥有其所编写的代码的版权。不过版权声明和在美国登记仍然具有一定法律效果。几乎所有自由软件许可证都要求增加并保留版权声明。有关维护版权声明的最佳实践详细信息,请参见 SFLC 的“在自由软件项目中管理版权信息”一文。⑥

(⑥http://softwarefreedom.org/resources/2012/ManagingCopyrightInformation. html.)

第 2 节:修改程序和分发修改版程序

第 2 节是 GPLv2 中 Copyleft 内容的核心部分。此节直接要求修改后的程序版本必须以同样的许可条件进行分发。修改权是 4 项基本权利之一,因此 GPLv2 保护而非限制这一权利。如第 2 节所述,GPL 程序的任何修改版本事实上都属于“基于程序的作品”,只能依据 GPLv2 所包含的条款分发,不得适用任何其他条款。

第 2(a) 条要求所有修改版本必须作出标记,指明修改内容、修改日期和修改人身份的基本信息。在源码中以合理形式标记这些信息即可实现合规。这并不是要求提供源码版控制系统中的所有可用信息,也不需要替换目标码层的更改记录(changelog)或类似文件。正确的合规方式可帮助程序员在使用或审核某个特定源码文件时了解该文件来自项目或程序软件的哪个版本,从而跟踪近期实质修改记录。

另外,为了保护他人的法律声明,第 2(c) 条规定如果修改前的程序“在运行时通常会交互式读取命令”并显示或打印出法律信息,那么所有版权声明、维保免责声明、修改标记和许可文本链接都必须在交互式应用中显示或打印出来。例如,GNU Debugger、gdb 或 GNU zile。

GPLv2 §2 不仅包含合规要求本身,也阐明了不适用 Copyleft 的情况。§2 的另外三段在意图及实践方面对 Copyleft 的范围进行了限制。第 2 节明确规定,如果非 GPL 许可人的作者编写了隔离且独立的作品,而且该作品可能以有效形式与 GPL 软件组合,则 GPLv2 无意将 Copyleft 范围延伸至完全由该作者编写的代码。如果此类隔离且独立的作品是单独分发的,或者仅与 GPL 软件集合于同一软件分发介质(例如 DVD 或 USB 盘)上,许可证明确表示对此类代码放弃任何 Copyleft 义务。只有当这一先前隔离的作品与 GPL 代码组合为一个新的“基于软件的作品”,或该作品并非独立而是必须与 GPL 代码组合才能执行时,Copyleft 义务才适用于该新作品。⑦ 在集合情境中,许可证明确规定该集合不可基于保护伞许可证发布,保护伞许可证会禁止用户按照每个软件各自的许可证行使权利。

( ⑦其中涵盖针对违规的所有主要侵权责任。间接版权责任会以其他方式附上。假设我创建了某件 GPL 作品的专有增强版并单独交付、宣传版本有效性并鼓励下游用户制作和再分发侵权组合作品(包括专有增强版和原始 GPL 作品),那么一旦发生此类主要侵权行为,GPL 许可版权持有人能够以版权侵权为由向我提起索赔。有关详情,请参阅 MGM Studios, Inc. v. Grokster, Ltd., 545 U.S. 913 (2005)。)

第 3 节:以目标码形式复制和分发经过修改或未修改的程序

GPLv2 §3 规定了分发可执行或二进制版本作品的条款。尽管 §2 是 Copyleft 的核心条款,但 §3 规定了最重要的合规义务。如果没有可构建的源码,用户无法学习、理解、修改和分享软件,因此 §3 要求分发者提供源码。§3 中描述了 3 种主要合规方法:

1.如果 GPL 程序的可执行版本可在网上复制获取,其完整对应源码也应在“同一”位置找到,以供用户复制;

2.如果 GPL 程序的可执行版本是通过物理介质分发的,其完整对应源码应通过同一介质或者 DVD 或 USB 存储卡等介质随附于该程序分发;

3.以前述或其他方式分发的可执行软件也可附随书面要约,即表示愿意提供完整对应源码的声明,其有效期应至少为 3 年。如果您只是单纯转发他人 GPL 代码包的非营利分发者,而该代码包仅随附书面要约,并不包含源码,那么您也可分发您所收到的书面要约。有关符合规定的书面源码提供要约示例,请参见附件 1。

什么是“完整对应源码”?首先,源码指“可用于修改作品的首选代码形式”。对于解释型计算机语言(包括外壳脚本、Perl、Javascript 和 APL 等),可用于修改作品的首选代码形式可能只有一种。(不过请注意,压缩、最小化、模糊化以及对代码的其他编译可能导致“非源码形式”的作品产生。)

如 §3 所述,完整“对应”源码包括源码、构建脚本、生成文件、配置文件和其他必要素材,这些必要素材可将程序构建为与可执行文件完全一致的版本,也可用于修改源码并构建修改版本。缺少构建准确交付版本的任何必要元素都意味着分发的源码不完整且不“对应”。无法用于修改和重建修改版本的“对应”源码(例如因为过于模糊化而无法实际修改)也不视为“完整”。

此完整要求包括系统库文件例外规定,§3 中的相关定义如下:

通常随运行可执行程序的操作系统主要组件(编译器、内核等)一起分发的代码(无论是源码还是二进制代码),除非组件本身与该可执行程序一起分发。

此例外规定旨在让分发者可不向下游用户交付行使权利时不需要的代码,因为可推定用户已获得作为操作环境一部分的此类代码。

未提供或未表示愿意提供完整对应源码是最常发生的违规问题。针对商业分发者的所有社区诉讼案件都与此相关。核实分发者为应对合规要求而提供的源码是否完整且对应也是合规维权中最繁杂困难的一部分。所有这些问题都源自管理不到位。分发者不保留嵌入其产品的二进制程序的源码,而且缺乏知晓如何构建软件组件的人力资源。在这之后,对于遭到修改并分发的作品,如果原版权所有人想要获得源码,各组织也不知道如何提供,或者只能提供不完整或不全面的代码,这体现了各方的无助和无知,而这两项都不是合法理由.

其实这类问题本不应或不必发生。如果完整对应源码的原始码同时也是软件生成过程中的“构建目标”,那么只要生成二进制代码就同时会产生完整对应源码,这源码就不应该丢失。只要组件能够被生成,其编程知识就不应该离开其编程组织。在网络上提供面向公众的源码也可作为产品发货或交付生产的一部分自动完成。在与全球各类公司的合作中,我们经常发现在软件开发过程中进行一些相对简单且成本较低的改进就可完全消除违规问题,而这些违规问题可能会躲过“合规”工具的审查,导致后续花费更多来进行补救。

使用书面要约虽然可推迟提供源码的时间,但从长远来看会增加合规成本。既使已停止分发产品,该要约也必须持续至少三年。这也可能使“任意方”有权要求完整对应源码,既使其并未获取二进制代码。

对于 GPL 程序的商业分发者来说,既使只是再分发他人所编的程序,也受到 GPL 条款的约束。在这种情况下,仅转发从上游许可人或供应商处收到的相同源码书面要约并不足以满足合规要求,而且也别期望用户可从您的供应商处获得源码。此时,建议您行使用户权利,向供应商索要为您提供的所有 GPL 程序的完整对应源码,这一过程最好可自动完成。收到这些完整对应源码后,将其与您的产品一起转发便可确保符合许可证规定。

GPLv3 协议中的第 6 节条款为等效条款,用于处理以非源码形式传递源码的问题。

第 4 节

第 4 节直接规定了“不得附加限制”概念,同时禁止依据非 GPLv2 协议进行分许可。此处所述禁止值得注意。尽管通常认为只有在分发 GPL 代码时才会产生 Copyleft 义务,但这种观点是不正确的。分许可是一种单独行为,也会产生 Copyleft 义务。

在本世纪二十年代前,从理论上来说几乎不可能在分许可过程中不遵守 GPLv2 协议。但现在则并非如此。“软件即服务”的“云”产品(其中虚拟服务器组按效用计费出售)已经带来了严重的违规问题。提供此类虚拟化服务器产品的公司与用户之间的协议往往声称“许可”用户使用虚拟化服务器组中的软件,而这些软件几乎总包含 GPL 操作系统组件,这就导致这些组件适用与 GPL 不一致的分许可条款。要避免这一问题,其实无需利用技术或编程。

GPLv3 协议完全禁止分许可,详情请参见下文。GPLv3 软件在“云”或“软件即服务”上的部署可在技术上完全达到合规要求,但也可能因为错误分包而导致侵权。

GPLv2 协议的第 4 节规定,如果违背条款,则自动终止许可。此规定在 GPLv3 §8 中有所变动,详情请参见下文。因为一旦侵权,许可便会自动终止,所以要想在这之后获得重新分发权利,必须获得版权所有人的重新授权(根据 GPLv3 协议,可以自动进行此过程)。尽管社区版权持有人对于依据侵权人的请求恢复其分发权一直持一致的合作态度,但由于从事版权运营的盈利机构更多使用的是 GPLv2 协议,因此未来不可避免地会出现一些在分发权自动终止后需要支付巨额费用才能恢复该权利的案例。因为自动终止许可后会立即产生禁令,因此依赖于 GPLv2 版权营利的非社区版权所有人可能会通过自动终止许可获得不公平优势。正因如此,商业分发者现在应倾向于从上游技术供应商处获得 GPLv3 许可,而不是 GPLv2 许可。

第 5 节:无需接受许可

英国的普通法传统在 500 多年前就已将“许可”定义为产权持有人授权非拥有者使用其产权的单方面许可,这一定义一直沿用至今。在传统法学院课程中,教师通常会以宴会邀请为例来解释许可定义。例如,如果我邀请你来我家共进晚餐,但当你跨进门内时我起诉你非法入侵,那么你的抗辩理由就是“许可”,即我允许你进门的单方许可。在全球法律分析中,将许可证混淆为契约的观点普遍存在,因为在许多其他法律体系(包括那些声称源自罗马法律的法律体系)中,还未认可非契约性的单方面义务概念。(不过也不能控告受邀前往某地的人非法入侵。)GNU 许可是普通法意义上的许可:具有限制的单方面版权许可。GPLv2 §5 陈述了这一经常产生争议但又不容置疑的法律概念区别。一方无需接受许可,另一方也不寻求其接受。不仅用户无需通过点击生效或其他程序接受许可,而且许可证中授权的许可条款还禁止施加此类附加条件。根据 §4 和 §5 的规定,需要明确避免通过合同形式、接受程序、认同监测或任何其他活动将单方面许可转变成双边义务。

第 6 节:自动向下游授予许可

此节便是 GPLv2 协议中的“自动向下游授予许可”条款。每次再分发 GPL 程序时,接收者都会自动从各原许可人处获得许可,从而在合规许可证条件的前提下,对软件进行复制、分发或修改。如上所述,无需采取任何措施来确保下游接收者接受许可证条款。这样做可使每位版权持有人与每位下游再分发者在代码分发链条上都具有对应的法律关系或直接关系,从而产生两种法律效果。首先,如 §6 所述,即使直接上游供应商因违反许可证而导致许可终止,只要用户本人合规,就仍然有权对软件执行包括修改和再分发在内的所有操作。用户所拥有的许可权并不取决于上游提供者是否合规,因为用户的许可证是由版权持有人直接下发的。其次,一旦许可自动终止,即使从其他供应商处再获取软件也无法恢复权利:许可权限只能由原许可人授予,如果原许可人自动终止了许可,则任何中间许可证持有人都无法恢复这些已终止的权利。

如 §6 明确规定,许可人不可强制第三方代码接收者或分发者履行合规义务。被许可人从原许可人处获得或失去许可都取决于其自身行为。

第 7 节

此节条款用于处理以下问题:许可人因为义务冲突而不能传递许可证所保证的自由权利。合规第 7 节条款意味着,如果适用于您的条件与许可证要求相冲突,则您无法且不得使用本许可证再分发他人的代码。因此,如果您具有其他法律义务,则不得再分发该程序或基于该程序的作品,除非版权持有人授予您附加许可。

术语“适用于您的条件”对解读 GPLv2 协议第 7 节条款至关重要。如果法院裁决或其他和解协议要求您接受一些条件,则这些条件便属于“适用于您的条件”。所以,如果某强制许可或法院调解协议包含按销售单元进行许可计费或禁止向下游转售等条款,则产生第 7 节中所述的义务。接受专利许可或签署限制权利的任何其他合同也会产生相同效果。

因此,合规 GPLv2 §7 条款涉及的是法律审查,而不是技术或编程实践。据我们所知,社区组织以前并未因用户违反第 7 节条款而提起过诉讼或辩论程序,但在实践中我们经常与各公司讨论是否应取消或修订其之前已签署的某些协议条款,以免出现 §7 所述问题。

GPLv2 协议第 7 节的另一关键作用是避免在专利纠纷中达成不同的和解协议。如果某和解协议只允许和解方在无专利风险的情况下分发 GPL 软件,则不属于有效限制,只有禁止下游方再分发才属于真正的限制。毫无疑问,这样做限制了 GPL 协议所赋予的权利,导致与第 7 节条款冲突。