简介

Copyleft 的概念和许可机制

根据我们与社区和企业的合作经验,目前存在很多对 GNU 许可证条款和核心概念的误解。在本节我们会介绍许可证的各个功能部分如何实践copyleft的基本概念,之后我们对每一个license的具体条款以及这些条款如何赋予特定合规义务也作出解释。只要您以许可证的本意及其核心概念为基本参照点来看问题,既使一开始看起来随意或不合理的条款也会变得容易理解了。

“作品”和 Copyleft

版权法保护的单元是“作品”。从这个意义上来说,许可证所述的“作品”是任何可获得版权保护或受版权法条款约束的事物。GNU许可证则将作品的范围运用到了极致。根据 GPL 协议,任何“作品”或“基于作品的作品”都受许可证约束(包括完整对应源码要求),除非适用特定排除条款。律师之间经常会就这一原则产生理论上或推断性的争议,因为“作品”并不是计算机编程的单元。在判断某一“程序”、“目标码”、“功能”、“库”或其他任何软件单元在与其他 GPL 代码组合后是否属于“作品”的一部分时,我们必须解答的问题恰恰无法在版权法中以相同的技术术语直接获得答案。律师在此问题上的结论往往基于根据文学或艺术版权情况制定的规则在不同的计算机编程情况下的应用。关键在于 GNU GPL 许可证旨在“保护到当地版权法认可的“基于作品的作品”的每一个版本,但仅此而已”,适用于本地版权法认可的“基于作品的作品”的所有版本(但不包括未来版本)。

对于此范围,GNU GPL 许可证表明其条款适用于所许可的作品,并延伸至“基于该程序”的所有作品。GPLv2 是美国律师为美国读者编写的许可证,其中提到:



遗憾的是,这种形式的解释没有帮助,反而导致数年来大家一直在讨论“衍生作品”法律原则(美国的概念)对软件所起的作用,但毫无结果(美国法院也基本上没有提供任何指导)。所以在GPLv3协议中,我们及我们自由软件基金会的客户决定放弃所有对美国“衍生作品”的解释,转而回到基本概念:GPL协议涉及获许可的作品以及所有基于该作品的所有作品,其中,“基于该作品”被定义为在版权允许的情况下任何对被许可作品的修改或引入。

但是GNU GPL类的许可证确认:许可证以外的范围对保护开发者权利来说非常重要,正如许可证本身界定的范围对保护用户权利至关重要。当一个开发者的作品 “隔离并独立” 于任何GPL类软件代码时,则 Copyleft 义务不适用于该单独分发的作品,尽管该作品本可以与GPL软件结合。GPL类许可证并非要将copyleft效力延伸至超出版权范围,正像GPLv2 §2以如下文字所确认的:

```如果识别出(其他软件代码的)部分代码并非基于“软件”生成,且有合理理由认为这些代码是隔离并独立存在的,那么本许可证及其条款不适用于作为独立作品分发的这部分代码。但是,如果这部分代码是整个作品的一部分,而整个作品都是基于copyleft“程序”生成,那么这个作品的整体都应合规本许可证。

GPLv3 §5 在保护开发者对此类作品的权利方面更进一步,其中有关防止 Copyleft 过度应用的规定如下:

当本许可证所涉作品(covered work)与其他隔离且独立的作品存放于同一个存储或分发介质上,但该独立作品并非所涉作品的延伸,也不会与此所涉作品结合成为一个更大的程序,且这一组合及由此产生的版权不超出单独作品给用户的使用范围和法律权利时,这种组合叫做“集合”。在集合中的所涉作品不会导致本协议适用于集合中的其他部分。

GPL类许可证清晰阐明copyleft的范围限制为版权范围内,而不是像有时暗示的那样以在“早期绑定(early binding)”编程语言中将软件代码的“动态链接(dynamic linking)”与“静态链接(static linking)”区分开来这种方式进行解释。偶尔会有人提出,对于与GPL代码“动态”链接的子程序(subroutine),其链接本身不属于主作品的copyleft范围。这其实是误解。两个软件组件结合到一起形成一个作品时(无论是主要程序与一些子程序库的结合、两个有各自方法(method)的对象(object)的结合,还是一个程序和一个“插件(plugin)”的结合),如果这种结合需要获得组件版权所有人的许可,但没有获得,或者虽然获得了但未合规许可证条款,则此结合会对该组件版权所有人构成侵权。在与GPL或AGPL组件结合时,该结合作为整体必须且只能合规copyleft的要求,否则不能使用GPL组件。而无论是在分发可执行文件前通过链接器连接,还是在运行时通过操作系统内核连接以便共享库来提高执行效率,或者以运行语言“后期绑定”引用(如Java程序),都没有影响。③

自动向下游授予许可

每次分发 GPL 程序时,接收者会自动依据相关 GPL 条款从每个上游许可人处获得一个许可证。只要分发的作品中包含其他版权所有人的素材,这些版权所有人就都是上游许可人。这相当于是一个三维(而非线性)许可权利。该作品的每个接收者都默认或直接从每位许可人处获得许可。

这一自动向下游授予许可的机制是 Copyleft 得以运行的核心。每个许可人独立授予许可,而且每个许可人都可在遭到侵权后独立终止该许可。在 GPLv2 协议下,受到侵犯的许可会自动终止,而在 GPLv3 协议下,违反许可证协议的一方可能可在许可终止前进行补救。侵权方的下游用户只要未侵权,其获得的许可就仍然有效,因为他们是从所有的上游权利人处直接获得许可,而不依赖于分发软件的侵权方所授予的许可。基于相同原因,任何侵权人既使再获得一份该程序副本,也无法获得任何新许可权利。也就是说,一旦该程序的任何上游许可人终止了授予侵权人的许可,该侵权人就无法再自动获得新许可,即使再获得一份该软件也不行。

预防附加限制

用户的自由如果受到copyleft以外的额外条款限制就不会得到保护,因此要实现GPL许可证的目标,绝不能放弃“不得附加限制”这一原则。GPLv2要求只有GPLv2协议才能适用于基于GPLv2的作品。GPLv3在第7条列举了几条允许的附加条款,但也仅可在特定情形下对许可证进行非常有限的变更。除了这几项例外情况外,严格适用“不得附加限制”原则。正因如此,要求同意或格式协议(包括“点击同意”这类安装程序)均违反GPL协议。

施加矛盾条款

“不得附加限制”原则旨在避免 Copyleft 软件在分享过程中遭到故意修改。但如果某一方受到特定限制,而该限制又无法体现在许可证中,怎么办?例如,如果 A 无权将其从 C 处获得的所有程序权利传递给 B,则 B 得到的权利就比 GPL 本应赋予其的少,因为法律结论永远是 A

③请注意,LGPL 对静态或动态链接模块和所涉作品的要求不尽相同。有关详情,请参见下文。

授予的权利不可能超出其本身所获得的权利。为了用户利益,GNU GPL 许可证解决了此难题:如果施加的法定条件(因法院裁决或接受其他机构的法定限制而受约束)阻止您授予 GPL 许可证中的所有权利,那么您就不能分发该程序。Copyleft 许可证不允许以任何外部法定条件为由不合规 GPL 条款。

此原则与“施加予盾条款”在专利许可等方面也很重要。如果您接受的专利许可包含比相关 GNU GPL 许可证更具限制性的条款,则该专利许可中的矛盾条款将阻止您分发整个程序。这并不是基于专利权的存在或主张,也不是因为提供与 GPL 不兼容的专利许可导致产生这一规定,而是您对这些条款的接受或者施加此类规定的法院裁决造成了这一情境。