标签 GPL 下的文章

本文由高级咨询师薛亮据自由软件基金会(FSF)的英文原文翻译而成,这篇常见问题解答澄清了在使用 GNU 许可证中遇到许多问题,对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。

  1. 关于 GNU 项目、自由软件基金会(FSF)及其许可证的基本问题
  2. 对于 GNU 许可证的一般了解
  3. 在您的程序中使用 GNU 许可证
  4. 依据GNU许可证分发程序
  5. 在编写其他程序时采用依据 GNU 许可证发布的程序
  6. 将作品与依据 GNU 许可证发布的代码相结合
  7. 关于违反 GNU 许可证的问题

4 依据GNU许可证分发程序

4.1 我可以仅用二进制形式发布一个遵循 GPL 的程序的修改版本吗?

不可以。GPL 的要旨是所有修改版本必须是自由软件——这意味着修改版本的源代码必须可供用户使用。

4.2 我从网上下载了二进制文件。如果我分发该副本,我必须也要获取源代码并分发?

是的。一般规则是,如果您分发二进制文件,则还必须分发完整的相应源代码。您收到索取源代码书面文件的例外情况非常有限。

4.3 我想通过物理媒体分发二进制文件,但不附带源代码。我可以通过 FTP 提供源代码吗?

GPL v3 允许这种行为;有关详细信息,请参阅条款 6(b)。依据 GPL v2,您可以径自通过 FTP 提供源代码,大多数用户将从那里获得。然而,如果他们中的任何人宁愿通过邮件获取以物理媒体承载的源代码,那么您需要为之提供。

如果您通过 FTP 分发二进制文件,则应通过 FTP 分发源代码

4.4 我的朋友获取了一个遵循 GPL 的二进制文件和承诺提供源代码的书面文件,并为我提供了副本。我可以自己使用这个书面文件来获取源代码吗?

是的,你可以。该书面文件必须对拥有其所相伴的二进制文件的所有人开放。这就是为什么 GPL 说你的朋友必须给你一份这个书面文件的副本以及这个二进制文件的副本,所以你可以使用该书面文件索取源代码。

4.5 我可以将二进制文件放在我的互联网服务器上,并将源代码放在不同的网站上吗?

可以。第 6(d)条允许这样做。但是,您必须提供明确指示,以利于人们依次来获取源代码,并且必须注意,只要你的目标代码还在分发,就要确保源代码仍然可用。

4.6 我想以二进制形式分发一个遵循 GPL 的程序的扩展版本,是否分发原始版本的源代码就足够了?

不可以,您必须提供与二进制文件对应的源代码。对应的源代码意味着用户可以从中重建相同的二进制文件。

自由软件的一部分理念是用户应该可以访问他们使用的程序的源代码。使用您的版本的用户应该可以访问您的版本的源代码。

GPL 的一个主要目标是建立自由世界,确保对自由程序的改进本身是自由的。如果您发布一个改进版本的遵循 GPL 的程序,您必须依据 GPL 发布改进的源代码。

4.7 我想分发二进制文件,但不太方便分发完整的源代码。我是否可以向用户提供来自与该二进制文件对应的“标准”版本的diff?

这是一个很好的想法,但是这种提供源代码的方法并没有真正做到这一点。

一年之后想要获取源代码的用户可能无法从当时的其他站点获取正确的版本。标准分发站点可能有一个较新的版本,但相同的diff 可能无法与该版本一起使用。

所以你需要为二进制文件提供完整的源代码,而不仅仅是 diff。

4.8 我可以在网络服务器上发布二进制文件,但是仅向索取的用户发送源代码吗?

如果您在网络服务器上提供二进制对象代码,则必须在网络服务器上提供对应源代码。执行此操作的最简单方法是将它们发布在同一台服务器上,但如果需要,您可以提供从其它服务器甚至版本控制系统获取源代码的说明。不管你做什么,源代码都应该像目标代码一样容易访问。这些全部在 GPL v3 的第 6(d)节中进行了具体说明。

您提供的源代码必须完全对应于二进制文件。特别是,您必须确保它们是相同版本的程序——不是旧版本,也不是新版本。

4.9 如何确保每个下载二进制文件的用户都能获得源代码?

你不必确定这一点。只要您使源代码和二进制文件可用,以便用户可以看到可用的内容并获取所需的内容,那么您已经完成了所需的操作。是否下载源代码取决于用户。

我们对再分发者的要求旨在确保用户可以获得源代码,而不是强迫用户即使在不需要的情况下也要下载源代码。

4.10 GPL 要求我提供可以构建成与我正在分发的二进制文件的精确哈希值相匹配的二进制文件的源代码吗?

完全对应的源代码意味着二进制文件依赖该源代码生成,但这并不意味着您的工具必须能够创建一个与您正在分发的二进制文件的精确哈希值相同的二进制文件。在某些情况下,可能(几乎)不可能使用正在分发的二进制文件的精确哈希值从源代码构建二进制文件——考虑以下示例:系统可能会将时间戳放在二进制文件中;或者程序可能是针对不同的(甚至未发行的)编译器版本构建的。

4.11 我是否可以发布一个遵循某许可证的程序,该许可证表示您可以依据 GPL 分发修改后的版本,但是您不能分发遵循 GPL 的原始版本?

不可以,这样的许可证是自相矛盾的。我们来看看它对用户的影响。

假设我从原始版本(称为版本 A)开始,添加一些代码(让我们假设它是 1000 行),并依据 GPL 发布修改版本(称为 B 版本)。GPL 说任何人都可以再次更改 B 版本,并依据 GPL 发布修改结果。我(或其他人)可以删除那 1000 行代码,生成与版本 A 代码相同的但遵循 GPL 的 C 版本。

通过在许可证中明确表示我不允许删除版本 B 中的那些行,重制成与遵循 GPL 的 A 版本相同的东西,您可以尝试阻止该路径。但实际上许可证表示现在我不能完全以 GPL 允许的所有方式使用版本 B。换句话说,许可证实际上不允许用户发布诸如遵循 GPL 的 B 版本这样的修改版本。

4.12 我刚刚发现一家公司有一份 GPL 程序的副本,获取该副本需支付费用。他们会因为不能在互联网上提供副本而违反 GPL 吗?

不会,GPL 不要求任何人使用互联网进行分发。它也不要求任何人特意去再分发程序。而且(一个特殊情况之外),即使有人决定再分发该程序,GPL 也不会要求他必须特意向您或其他人分发副本。

GPL 要求的是,如果他愿意,他必须有权将副本分发给你。一旦版权所有者将程序的副本分发给某人,如果某人认为合适,那么该人可以将程序再分发给您或任何其他人。

4.13 一家公司正在网站上运行一个 GPL 程序的修改版本。GPL 规定他们是否必须发布修改后的源代码?

GPL 允许任何人进行修改并使用修改版本,而无需将其分发给他人。(这里所说的)这家公司的做法是一个特例。 因此,公司不必发布修改后的源代码。

人们必须能够自由地对程序进行修改并自用,而无需发布这些修改。然而,将程序放在服务器上以供公众访问很难说是“自用”,因此要求在这种特殊情况下发布源代码是合法的。希望解决这个问题的开发人员可以为其程序适用 GNU Affero GPL,该许可证专门为网络服务器使用场景而设计。

4.14 在一个组织或公司中制作和使用多个副本构成“分发”吗?

不构成,在这种情况下,组织只是为自己制作副本。因此,公司或其他组织可以开发修改后的版本,并通过自己的设施安装该版本,但不得允许员工向外发布该修改版本。

但是,当组织将副本转移给其他组织或个人时,即构成分发。特别是,向承包商提供副本以便在场外使用,构成了分发。

4.15 如果有人窃取包含 GPL 程序的 CD,GPL 是否授予小偷再分发该版本的权利?

如果该版本已经在其他地方被发布,那么依据 GPL,这个小偷可能确实有权利制作副本并将其再分发,但是如果小偷因为窃取 CD 而被监禁,那么他们可能必须等到释放才能这样做。

如果相关版本未被公开发布并被公司视为其商业秘密,则根据其他情况,发布该版本可能会违反商业秘密法。GPL 对此没有进行改变。如果公司试图发布其版本,并仍将其视为商业秘密,则会违反 GPL,但如果公司尚未发布此版本,则不会发生此类违规。

4.16 如果一家公司将副本作为商业秘密分发会构成违规吗?

如果该公司向您分发副本并声称是商业秘密,则该公司违反了 GPL,必须停止分发。请注意这与上述盗窃案有何不同;该公司没有故意在副本被盗后分发副本,所以在这种情况下,该公司没有违反 GPL。

4.17 我在使用 GPL 程序的源代码时是否具有 “合理使用” fair use 权限?

是的,您有。“合理使用”是在没有任何特别许可的情况下允许的使用。 由于您不需要开发人员的许可来进行这种使用,无论开发人员在许可证或其他地方对此怎么说,您都可以执行此操作,无论该许可证是 GNU GPL 还是其他自由软件许可证。

但是,请注意,没有全世界范围普适的合理使用原则;什么样的用途被认为“合理”因国而异。

4.18 将副本移至控股的附属公司会构成分发吗?

副本移至/移自附属公司是否构成“分发”需要根据恰当管辖区的版权法依据个案确定。GPL 没有也不能逾越当地法律。美国版权法关于这一点的规定并不完全清楚,但似乎并不将此视为分发。

如果在某些国家,这被视为分发,而附属公司必须得到再分发程序的权利,这不会有实际的区别。附属公司由母公司控制;无论有没有权利,除非母公司决定这样做,否则附属公司不会再分发该程序。

4.19 软件安装程序可以要求用户通过点击来同意 GPL 协议吗?如果我获得一些遵循 GPL 的软件,我必须同意什么吗?

一些软件安装系统有一个地方要求您点击或以其他方式表示同意 GPL 的条款。这不是必须的,也不是禁止的。无论是否点击, GPL 的规则保持不变。

只是同意 GPL 不要求您承担任何义务。仅使用依据 GPL 进行许可的软件,您不需要同意任何事项。只有您修改或分发软件时,您才有义务。如果点击同意 GPL 真的打扰了你,没有任何东西能阻止你修改该 GPL 软件把这个步骤删除掉。

4.20 我想将 GPL 软件与某种安装软件捆绑在一起。该安装程序是否需要具有与 GPL 兼容的许可证?

不需要。安装程序及其安装的文件是单独的作品。因此,GPL 的条款不适用于安装软件。

4.21 GPL 软件的一些分发者要求将我囊括在其伞式的最终用户许可协议(EULA)中或作为下载过程的一部分,以“代表和保证”我位于美国,或者我打算依据相关出口管制法律分发软件。为什么他们这样做,是否违反了分发者在 GPL 下的义务?

这不违反 GPL。那些分发者(几乎都是销售自由软件分发版本和相关服务的商业企业)正在努力降低自己的法律风险,而不是控制您的行为。如果分发者故意将软件出口到某些国家或将软件提供给可能会进行这种出口行为的第三方,美国的出口管制法可能会要求分发者承担责任。分发者通过向客户和被分发软件的其他人要求做出这些声明,一旦被监管机构问及他们是否知道其分发的软件流至何方,分发者可以借此保护自己。分发者并不限制您可以用软件做什么,只是避免他们对您所做的任何事情负责。因为分发者没有对软件施加额外的限制,所以他们不违反 GPL v3 的第 10 节或 GPL v2 的第 6 节。

自由软件基金会(FSF)反对将美国出口管制法律适用于自由软件。这些法律不仅与软件自由的总体目标不符,而且达不到合理的政府目的,因为目前几乎每个国家都可以使用自由软件并且应该一直都能使用,包括没有出口管制法律的国家以及参与美国领导的贸易禁运的国家。所以没有一个国家的政府实际上被美国的出口管制法律剥夺了使用自由软件的权利,就我们而言,不管其政府的政策如何,每个国家的公民都不应该被剥夺使用自由软件的权利。自由软件基金会发布的所有 GPL 软件的副本可以通过我们获得,而不对您居住地点或您打算做什么进行任何限制。同时,自由软件基金会理解位于美国的商业分发者遵守美国法律的愿望。他们有权选择将自由软件的特定副本分发给谁;该权利的行使不违反 GPL,除非他们增加超出 GPL 许可的合同限制。

4.22 GPL v3 第 6 节的开头说,如果我也符合第 6 节的条件,我可以“按照第 4 节和第 5 节的规定”,以目标代码的形式传递其覆盖的作品。这是什么意思?

这意味着您传递源代码的所有权限和条件也适用于传递目标代码:您可以收取费用,您必须保持版权声明不变,等等。

4.23 我公司拥有很多专利。多年来,我们遵循“GPL 第 2 版或更新版本”的项目提供了代码,项目本身已按相同的条款进行了分发。如果用户决定将项目代码(包含我公司的贡献)适用 GPL v3,那意味着我已经自动向该用户授予 GPL v3 中的明确专利许可?

不是,当您 传递 convey 遵循 GPL 的软件时,您必须遵守该许可证特定版本的条款和条件。当您这样做时,该版本定义了您拥有的义务。如果用户也可以选择使用更新版本的 GPL,那仅仅是他们拥有的额外权限——它不需要您满足 GPL 更新版本条款的要求。

不要因为答案是 NO 就认为可以用你的专利来威胁社区(LCTT 译注:感谢“西米宜家”的指正)。在许多国家,根据 GPL v2 分发软件为接收人提供了隐含的专利许可,以行使 GPL 中的权利。即使没有,任何考虑强制执行专利的人都是社区的敌人,我们将捍卫自己免受这种攻击。

4.24 如果我分发了一个遵循 GPL v3 的程序,我可以提供一个一旦用户修改程序则无效的保修吗?

可以。就像用户一旦修改设备中的软件就不需要保证设备安全一样,您不需要提供涵盖所有可能通过遵循 GPL v3 的软件进行的活动的保修。

4.25 如果我给公司同事一份遵循 GPL v3 的程序的副本,是否构成了我将该副本 “传递” convey 给该同事?

只要您在公司的工作中使用软件,而不是个人使用该软件,那么答案是否定的。副本属于公司,不属于您或同事。这种复制是 传播 propagation 而不是 传递 convey ,因为公司没有将副本提供给他人。

4.26 如果我通过链接至版本控制系统(例如 CVS 或 Subversion)中的源代码存储库方式提供源代码,而在 FTP 服务器上提供二进制文件,这种做法符合 GPL v3 吗?

只要源码签出过程不会变得繁重或存在其他限制,这是可以接受的。任何可以下载目标代码的人也应该可以使用公开的自由软件客户端从版本控制系统中签出源代码。应向用户提供清晰方便的说明,说明如何获取其下载的确切目标代码的源代码——毕竟,他们可能不一定需要最新的开发代码。

4.27 在 用户产品 User Product 中传递遵循 GPL v3 的软件的用户,是否可以使用远程认证来防止用户修改该软件?

不可以。当软件在用户产品中传递时,必须与源文件一起提供的“安装信息”的定义中明确表示:“该信息必须足以确保修改的目标代码的继续运行在任何情况下都不会仅仅因为修改过而被阻止或干扰。“如果设备以某种方式使用远程认证,则安装信息必须为您修改的软件报告自身的合法性提供一些方法。

4.28 GPL v3 中的“通过网络进行通信的规则和协议”是什么意思?

这是指可以通过网络发送的流量规则。例如,如果每天可以发送到服务器的请求数量或者您可以在某处上传的文件大小有限制,如果不遵守这些限制,则可能会拒绝您对这些资源的访问。

这些规则不包括任何与网络上传播的数据无关的内容。例如,如果网络上的服务器将用户消息发送到您的设备,则您对网络的访问无法被拒绝,因为您修改了该软件以使其不显示消息。

4.29 依据 GPL v3 提供安装信息的分发者不需要为产品提供“支持服务”。 所谓的“支持服务”具体是指哪些?

这其中包括设备制造商提供的帮助您安装、使用或排除故障的服务。如果设备依赖于访问 Web 服务或类似技术才能正常运行,则通常仍然可以使用修改版本,但须符合第 6 节中关于访问网络的条款。


译者介绍:薛亮,集慧智佳知识产权咨询公司高级咨询师,擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析,致力于为互联网企业、高科技公司提供知识产权咨询服务。

提要:对于开源软件来说,其许可证信息内嵌在源代码中。为了降低复杂性,您可以生成不同的视图。

您可以通过查看源代码找到开源软件的许可证信息。为了满足不同的需求,可以生成关于该许可证信息的不同视图或报告。

尽管直接在源代码中提供许可证信息并不是开源软件的必要条件,但是这样做的实际好处显而易见。由于开源许可证促进了软件的传播,与代码一起传输的许可证信息简化了管理过程,即使代码接收人通过间接方式获得代码,也可以使他随时可以获得权限声明。

什么是许可证条款?

在源码树中嵌入许可证信息的价值被低估了。让我们暂停一下,反思一下这种常见做法是多么有用。

什么是许可证条款呢? 对于许多开源软件来说,有一个简单的答案:一个许可证文本包含整个软件的所有许可证信息。但是开源的力量在于,它推动了其他开发者在这个起点之上进行构建,而这个过程会使许可证信息复杂化。

开源软件可以被扩展、再利用,或者与其他软件结合使用。与机械设备不同,不同群体之间的合作更具挑战性,复杂软件从许多人的工作中受益是切实可行的。开源许可证提供了促进这种开发动态的权限。具有复杂历史的软件也可能具有复杂的许可证信息。

考虑下面的例子:有人写了一个新的程序,在每个源文件中包含一个版权声明,声明该软件根据 Apache 2.0 版许可证进行许可,并且在源码树的根目录中包含 Apache 许可证文本。之后,添加了一个具有不同的版权声明的文件,以及一个 BSD 2 句版许可证副本的文件。然后,添加了一个新的子目录,其中文件具有 Apache 许可证声明,但具有标识不同版权所有者的版权声明。再之后,一个 MIT 许可证的副本添加到了新的子目录中,该子目录包含了版权声明与 MIT 许可证文件中相同的文件,但没有任何其他许可证指示信息。

这个例子表明,嵌入在源码树中的许可证信息可能很复杂而且很详细。根目录和/或各个子目录中都可能有许可证文本。一些源文件可能有许可证通知;其他源文件可能不会有。也许会有版权声明来识别各种版权所有者。但是,在不丢失信息的前提下将法律文本从代码中分离出来似乎是不可能的。因此,源代码即是许可证。

从源码树的角度来看,上面例子中对许可证信息的解释是非常简单的。但是,要在简单、明确的独立声明中获取许可证信息将是一件困难的事情。截取了源代码中所有许可证信息的许可证声明会比源代码更短,但这将是不方便的——谁会希望得到如此高度详细的单独声明?大多数用户可能会更喜欢一个概要,虽然不完整,但其获取的关键点符合自己的特定意图和敏感性要求。

用视图来概括许可证信息

对于“许可证条款是什么”这个问题,用整个源码树副本来回答可能没什么用,因为它过于庞杂和分散。大多数人只想要一个概要。但这面临一个挑战:当许可证信息比较复杂时,人们需要不同的概要,因为他们对于什么是重要的有不同的定义。

对于某些人来说,对以下问题回答“是”可能是足够的:该软件 1)是否根据一个或多个开源许可证获得许可,2)其被组装和许可后是否使得其分发和使用与所有这些许可证一致? 其他人可能需要所有许可证的列表,或者他们可能想要查看哪个软件组件对应于哪个许可证。还有一些人可能想要一个逐个组件的列表来标识任何 左版 copyleft 许可证(也许自己要做深入的左版合规研究)。 有些人可能有兴趣看到所有版权声明和软件组件的相关列表。

单一的概要可能不会满足所有人的利益。简单地将概要具体化可能会减少它对一些人的效用,而对其他人则显得不足。因此,需要将源代码中包含的许可证信息展现为不同的 “视图” views 。这里使用的“视图”术语可以视为与在数据库中使用它相似。或者,您也可以将“视图”看作是 “报告” reports

考虑将源代码作为许可证有一个优势,并且可以从中提取多个不同的视图。

您可能会尝试创建一个“全能”概要,从中可以创建其他较短的概要。但是以中间状态表达许可证信息至少有三个缺点:

  1. 时机:主概要的维护人员可能无法按计划进行更新。
  2. 版本:主概要可能基于与您使用的软件不同的版本。
  3. 质量:您的视图继承了主概要的错误和评判性。

因此,根据需要直接从您使用的源码树版本生成您的首选视图是有价值的。

有工具可以生成视图。按需视图的生成取决于工具。许可证信息展示的清晰(或混乱)程度会促进(或妨碍)该工具的功效。我们不需要许可证信息的特定机器编码,但是我们应该充分利用众多经验来源,以既可以被人读取,也可以被机器提取的方式来表达信息。

Jeff Kaufman 在他的文章《开源软件许可证合规的经济高效模型》中指出:由于源代码包含许可证信息,因此分发源代码是满足某些许可证要求的有效方式。

将所有许可证信息嵌入到源码树中是最佳实践。如果您发现源码树中没有显示许可证信息,请考虑通过提交错误报告来改进该项目,建议将该信息添加到源码树中。

源代码即是许可证。从完整的记录中,可以生成许可证信息的视图。工具可以将许可证信息提取到各种报告中,以满足特定需求或敏感性要求。

为了获得这个愿景的全部好处,我们还有工作要做。您对工具状态以及许可证信息展现有什么看法呢?


作者简介:Scott Peterson 是红帽公司法律团队成员。很久以前,一位工程师就一个叫做 GPL 的奇怪文件向 Scott 征询法律建议,这个致命的问题让 Scott 走上了探索包括技术标准和开源软件在内的协同开发法律问题的纠结之路。

译者简介:薛亮,集慧智佳知识产权咨询公司高级咨询师,擅长专利检索、专利分析、竞争对手跟踪、FTO分析、开源软件知识产权风险分析,致力于为互联网企业、高科技公司提供知识产权咨询服务。

2017 年 11 月 18 日至 19 日,2017 中国开源年会在上海交大召开,来自集慧智佳的高级咨询师薛亮在开源治理分论坛上发表了题为《ABC 时代 GPL 许可证传染性问题探讨》的演讲,现将演讲的内容进行整理和补充,以飨读者。

我们目前所处的时代被称为“ABC(AI、Big Data、Cloud)时代”,也是大量采用开源软件的时代。在这个过程中,不可避免地会遇到开源软件合规的问题,而其中最让人感到困惑的,可以说就是 GPL 许可证传染性问题。那么 GPL 软件是不是真的像传说中的避之唯恐不及,其传染性风险令人谈之色变呢?本次演讲和大家简要探讨一下 GPL 传染性问题。

演讲内容主要包括四个部分,第一部分为“从合规到牟利”,简要介绍目前开源软件合规环境的变化情况。第二部分为“ GPL 传染性判断”,介绍从实务角度考虑,GPL 传染性判断的流程、方法和原则。第三部分为“MongoDB 案例”,介绍了采用 AGPL 许可证的 MongoDB 案例。第四部分为“开源智慧专栏”,简单介绍集慧智佳与 Linux 中国合作开办的“开源智慧专栏”。

第一部分题目为“从合规到牟利”,介绍了近些年开源软件合规和诉讼态势发生的变化,已经从单纯的“寻求合规”转变为“追求牟利”,而这种变化使得开源软件用户的合规风险变得越来越严重。

以最为严格的 GPL 许可证来说,自由软件基金会和自由软件管理机构是全球推行 GPL 许可的主要机构,其追求的主要目标之一是实现 GPL 的合规,对于那些在无意中违反 GPL 许可证的行为,本着“惩前毖后,治病救人”的原则,大多数还是以教育和帮助为主,并不会刻意追求罚款、赔偿等。

但是,随着开源软件合规和诉讼生态的发展,涌现了更多类型的新玩家。根据国外律师的观察,除了诸如 SFLC、SFC 等传统的合规机构之外,近年来出现了比较激进的例如 McHardy 这样的 版权流氓 Copyright Troll ,或者说是 GPL 牟利者,其主要目标已经从合规转变为牟利,要求对违规行为颁发禁令或进行赔偿。

根据“开源智慧专栏”发表的翻译文章《如何应对开源软件的版权牟利者? 开源律师说这样做!》,GPL 牟利者 McHardy 已经骚扰了 50 多个目标,据说有些国内企业也在其中。

面对越来越复杂的开源软件合规态势,作为开源软件用户来说,对于许可证合规问题,需要引起重视,而 GPL 传染性显然是其中最让人头疼的问题。

第二部分我们具体探讨一下“GPL 传染性判断”,主要是根据我们的研究和实务经验,对于如何评估和判断GPL软件的传染性进行梳理和总结。

对于软件企业的技术人员来说,开源代码是否好用,是他们选用开源代码的重要标准之一,而不会过多考虑许可证问题。但对于企业的合规和法律部门来说,自己企业的技术人员使用了哪些开源软件,这些开源软件采用哪些许可证,则是需要进行排查和梳理,做到心中有数。而对于采用 GPL 许可证的软件,为了避免传染性,是不是必须简单地“一刀切”,绝对禁止使用呢?

我们认为,根据 GPL 软件类型和使用场景的不同,其传染性风险也存在不同。其中一个关键的分界点,在于自用与分发。

自用的范畴比较广泛,在公司个人、部门使用,甚至在公司内部分发,都可以自由使用。

对于编译器、解释器等工具类软件,其主要作用是对代码进行加工,可以归为自用的范畴,但也要区分 GPL 工具类软件是否将自身代码混进其所加工的代码。例如 GCC 是 GPL 编译器,但使用 GCC 不会感染被编译的源文件。

对于采用 GPL、LGPL 许可证的软件,如果放在服务器/云上以 SaaS 方式对外提供服务,也可以算作自用的范畴。但是,采用 AGPL 许可证的软件除外,AGPL 专门针对 SaaS 方式进行约束。

我们接着再来看分发,对于一些必须分发出去的 GPL 软件,其类型也有多种。对于一些相对独立的软件,需要注意与自有代码是各自独立还是复杂的糅合,是否构成了结合作品。对于诸如 MQTT 等协议实现类的软件,其实现方式有多种,可以选择采用宽松许可证的开源软件。许多开源软件也采用双重授权,如果担心开源版本的风险问题,可以选择花钱购买其商业授权版本。

对于自有代码与 GPL 软件的链接/混合,也分几种情况。例如对于自有模块 A 和 GPL 模块 B,需要根据两者之间的通信亲密程度以及传输数据的复杂程度,判断两者是否构成了结合作品。对于 GPL 插件,需要分析自有代码主程序对其调用的方式,判断是否造成传染。

对于自有代码与 GPL 库的链接,根据 GPL 许可证,无论是采用静态链接或动态链接方式,都会造成自有代码被传染,必须进行公开。而之后发表的 LGPL 许可证,则对 GPL 库的链接稍微放松了限制。由于 LGPL 专门针对库而制定,采用 LGPL 的库相对来说应该已经考虑了对调用程序的影响,更容易避免被“传染”。

我们再来看一下“自用”,GNU 官方问答对于自用的解释非常宽泛,在一个企业集团的总公司、分公司、子公司等使用,都可以算作自用的范畴,不构成分发。

对于采用 GPL、LGPL 许可证的软件,如果放在服务器/云上以 SaaS 方式对外提供服务,不构成分发,但如果将其部署在用户终端上,则构成分发,带来传染性问题。

对于采用 AGPL 许可证的软件,即便是运行在服务器/云上,如果后续用户对其源代码进行了修改,也必须将修改版本发布出来。

需要注意的是,某个GPL软件的使用场景如果发生变化,之前对其传染性风险的判断也有可能变化,需要根据新的使用场景重新评估。

第三部分我们来看一个案例,MongoDB 是一个非常典型的使用 AGPL 许可证的开源软件。国外有文章甚至开玩笑说,正是因为有了 MongoDB,人们对 AGPL 许可证的看法有了明显改变,从 “never use AGPL” 转变成 “never use AGPL except for Mongo DB”。

具体看一下 MongoDB 的许可政策。MongoDB 的数据库部分采用严格的 AGPL v3.0 许可证,并且是双重许可,用户既可以选择开源版本,也可以选择商业授权版本。MongoDB 的驱动部分则采用宽松的 Apache v2.0 许可证。

通过对数据库和驱动分别适用不同的许可证,MongoDB 在坚守其自由软件本质的同时,也为用户大开方便之门。

其中需要注意,如果用户修改了 MongoDB 核心数据库的源代码,则必须将修改版本发布出来,回馈给社区。

反之,如果用户的程序仅是使用 MongoDB 数据库,没有对数据库源代码进行修改,则不必发布该用户程序。Copyleft 仅适用于 mongod 和 mongos 数据库,而驱动则采用 Apache 许可证,所以用户的程序如果通过 MongoDB 官方推荐的驱动与数据库进行交互,也不被视为 AGPL 范畴下的结合作品,而是单独的程序或作品,无需担心被传染。

从 MongoDB 这个案例可以看出,一些开源软件的著作权人为了保护和推广自己的开源项目,可以说是“煞费苦心”,绞尽脑汁地在许可证方面进行精巧的设计,给出一些“例外声明”,为用户“开后门”,让用户可以相对比较放心地使用,推动了这些开源软件的迅速普及。

“开源智慧专栏”由集慧智佳与国内领先的开源社区 Linux 中国合作创办,聚焦开源软件的知识产权问题,旨在传播域外动态,梳理经典判例,翻译重要文本,关注行业热点,分享实务经验。

在第三部分简要介绍了 GPL 传染性判断的方法和原则,其主要依据是自由软件基金会发布的 GPL 许可证官方问答。我们也对这个问题进行了翻译,陆续发表在本专栏中。此外,对于此前闹得沸沸扬扬的 Facebook 公司 react 许可证事件,我们也进行了实时的跟踪和解读。

以上所列为本专栏从创办至今所发表的文章列表,大家可以登录 Linux 中国的“开源智慧专栏”查看,或者扫描关注微信公众号,接收实时推送的相关文章。

最后,简单介绍一下我本人。我所供职的单位——集慧智佳是中国第一家在新三板挂牌(838286)的知识产权咨询公司,对开源知识产权问题一直进行持续的跟踪和研究,曾承担国家级的开源知识产权研究课题,并为国内知名的互联网软件企业提供开源知识产权风险排查服务。

我在集慧智佳互联网事业部担任高级咨询师,擅长专利检索、专利分析、专利布局、竞争对手跟踪、FTO 调查、开源软件知识产权风险分析;长期为联想、中国移动、海尔、东软等互联网企业、高科技公司提供知识产权咨询服务;担任“开源智慧专栏”主要撰稿人。

  • 2017 年 10 月 14 日,在 GNOME 2017 亚洲峰会上发表题为《开源软件的知识产权风险》演讲。
  • 2017 年 11 月 18 日,在 2017 中国开源年会上发表题为《ABC 时代 GPL 许可证传染性问题探讨》演讲(PDF)。

欢迎大家围绕开源软件知识产权问题与我进行交流!

本文由高级咨询师薛亮据自由软件基金会(FSF)的英文原文翻译而成,这篇常见问题解答澄清了在使用 GNU 许可证中遇到许多问题,对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。

  1. 关于 GNU 项目、自由软件基金会(FSF)及其许可证的基本问题
  2. 对于 GNU 许可证的一般了解
  3. 在您的程序中使用 GNU 许可证
  4. 依据 GNU 许可证分发程序
  5. 在编写其他程序时采用依据 GNU 许可证发布的程序
  6. 将作品与依据 GNU 许可证发布的代码相结合
  7. 关于违反 GNU 许可证的问题

3、在您的程序中使用 GNU 许可证

3.1 如何从 (L)GPLv2 升级到 (L)GPLv3?

首先,在您的软件包中包含新版本的许可证。如果您在项目中使用 LGPL v3,请确保一同包含了 GPL v3 和 LGPL v3 的副本,因为 LGPL v3 现在被写成在 GPL v3 基础上的一系列附加许可。

其次,将所有现有的 v2 许可证 通知 notice (通常位于每个文件的顶部)替换为“如何使用 GNU 许可证”上新的推荐文本。它更加面向未来,因为它不再包括 FSF 的邮政地址。

当然,任何涉及软件包许可证的描述性的文本(如在 README中)也应该被适当更新。

3.2 您能一步一步地指导我如何将GPL应用到我的程序吗?

请参阅 GPL 说明书页面

3.3 为什么我要使用 GNU GPL,而不是其他自由软件许可证?(同 1.3)

使用 GNU GPL 将要求所有发布的改进版本都是自由软件。这意味着您可以避免与您自己作品的专有修改版本进行竞争的风险。不过,在某些特殊情况下,最好使用一个更宽松的许可证

3.4 为什么 GPL 要求程序的每个副本必须包含 GPL 许可证副本?(同 2.14)

作品包含许可证副本至关重要,因此获得程序副本的每个人都可以知道他们的权利是什么。

包括一个指向许可证的 URL,而不是将许可证本身包含在内,这是一种看起来很诱人的做法。但是您不能确定该 URL 在五年或十年后仍然有效。二十年后,我们今天所知道的 URL 们可能已不复存在。

不管网络将发生什么样的变化,确保拥有该程序副本的人员能够继续看到 GPL 许可证的唯一方法是,将许可证的副本包含在该程序中。

3.5 只需将 GNU GPL 的副本放在我的存储库中就可以了吗?

仅将 GNU GPL 的副本放在存储库中的文件中,并不能明确地声明可以依据 GNU GPL 使用同一存储库中的代码。如果没有这样的声明,并不能完全清楚地表明许可证中的权限真的可以适用于任何特定的源文件。一个明确的声明将消除所有的疑问。

文件仅包含许可证文本,而没有一个声明规定某些其他文件被该许可证覆盖,类似于文件包含一个其他任何地方都不会调用的子例程。但这种相似之处并不完美:律师和法院可能应用常识得出结论,因为您希望以 GPL 方式许可代码,所以您必定要将GNU GPL 的副本放在那里。或许律师和法院不会这样做。但为什么要留下不确定性呢?

每个源文件中都应该包括声明文本。只要能够伴随代码,程序的 README 文件中的清晰声明从法律上来说就足够了,但是它们很容易分离。所以,为什么要给您的代码许可证带来不确定性的风险呢?

这与 GNU GPL 的具体内容无关。对于任何自由许可证来说都是正确的。

3.6 为什么要在每个源文件中放置许可证 通知 notice

您应该在每个源文件的起始处放置通知,说明它所携带的许可证,以避免代码与其许可证被断开的风险。如果您存储库的 README 文件声明源文件遵循 GNU GPL,如果有人将该文件复制到另一个程序,会发生什么呢? 其他上下文可能无法表明该文件的许可证是什么。它似乎有一些其他许可证,或根本没有许可证(这将使代码变成非自由软件)。

在每个源文件的开始添加版权声明和许可证通知很容易,造成这种混乱的可能性不大。

这与 GNU GPL 的具体内容无关。对于任何自由许可证来说都是正确的。

3.7 如果作品不是很长,那该怎么办?(同 2.15)

如果整个软件包中只有很少的代码——我们使用的基准是不到 300 行,那么您可以使用一个宽松的许可证,而不是像 GNU GPL 这样的左版许可证(除非代码特别重要)。我们建议这种情况使用 Apache 许可证 2.0

3.8 为了节省空间,我是否可以省略 GPL 的引言部分,或者省略如何在自己的程序上使用 GPL 的 指导 instructions 部分吗?(同 2.21)

引言和指导是 GNU GPL 的组成部分,不能省略。事实上,GPL 是受版权保护的,其许可证规定只能逐字复制整个 GPL。(您可以使用法律条款制作另一个许可证,但该许可证不再是 GNU GPL。)

引言和指导部分共约 1000 字,不到 GPL 总文字数量的 1/5。除非软件包本身很小,否则引言和指导不会对软件包的大小产生大幅度的改变。在软件包很小的情况下,您可以使用一个简单的 全权 all-permissive 许可证,而不是 GNU GPL。

3.9 如何获得我的程序的版权,以便依据 GPL 发布?

根据 《伯尔尼公约》 Berne Convention ,所有书写成文的内容都将自动受版权保护。所以你没有必要做任何事情来“获得”你所写代码的版权——只要没有其他人声称拥有你的作品。

不过,在美国注册版权是一个很好的主意。这将给你在美国应对侵权者带来更多的影响力。

其他人可能声称拥有版权的情况是,如果您是雇员或学生;那么雇主或学校可能会声称你为他们做了工作,并且版权属于他们。他们是否存在有效的权利主张将取决于你所居住地方的法律,以及你的雇佣合同和你所做的工作。如果有任何疑问,最好咨询律师。

如果您认为雇主或学校可能会提出权利主张,您可以通过获得公司或学校适当授权的官员签署的版权免责声明来明确解决该问题。(您的直接上司或教授通常无权签署此免责声明。)

3.10 如果我的学校想将我自己的程序应用到学校的专有软件产品,我该怎么办?

现在许多大学试图通过限制他们所开发的知识和信息的使用来筹集资金,其实际上与商业业务有所不同。 (参见刊载于 2000 年 3 月 《大西洋月刊》 Atlantic Monthly 《受缚的大学》 The Kept University ,该文章对这个问题及其影响进行了一般性的讨论。)

如果您在某种程度上认为您的学校可能拒绝允许您的程序作为自由软件发布,最好尽早提出这个问题。程序越接近于有用的作品,行政部门越有动机从你手里拿回该程序,并在没有你的情况下完成它。在更早的阶段,你有更多的影响力。

所以我们建议你在程序只进行一半的时候接触他们,说:“如果你同意将它作为自由软件发布,我会完成它。”不要以为这是虚张声势。要取得胜利,你必须有勇气说:“我的程序如果不能成为自由软件,我宁愿不把它写出来。”

3.11 我想发布一个我依据 GNU GPL 编写的程序,但是我想在非自由程序中使用相同的代码。

发布一个非自由程序总是有道德上的污点,但从法律上来说没有任何障碍阻止你这样做。如果您是代码的版权所有者,您可以在不同时间以各种不同的非独占许可证发布。

3.12 依据 GPL 分发的程序的开发人员是否可以将其授权给另一方专用?

不可以,因为公众已经有权利使用遵循 GPL 的该程序,这个权利是不能撤销的。

3.13 美国政府可以依据 GNU GPL 发布一个程序吗?

如果这个程序是由美国联邦政府雇员在雇用过程中编写的,那么它是处于公有领域,这意味着它不受版权保护。由于GNU GPL是基于版权的许可证,所以这样的程序不能依据 GNU GPL 发布。(它仍然可以是自由软件,公有领域的程序是自由软件。)

不过,当美国联邦政府机构使用承包商来开发软件时,那就是不同的情况。合同可以要求承包商依据 GNU GPL 进行发布(GNU Ada 是以这种方式开发的)。或者合同可以将版权 分配 assign 给政府机构,然后政府机构可以依据 GNU GPL 发布该软件。

3.14 美国政府可否对遵循 GPL 的程序进行改进并发布?

可以。如果这些改进是由美国政府雇员在雇佣期间编写的,那么这些改进属于公有领域。不过,GNU GPL 仍然涵盖了整体的改进版本。在这种情况下没有问题。

如果美国政府使用承包商来完成这项工作,那么改进本身可以被 GPL 覆盖。

3.15 程序里为什么要说“GPL 的版本 3 或任何更新的版本”?

随着时间的推移,我们会不断更改 GPL——有时要澄清一下,有时允许以前不允许的某些用途,有时会收紧要求。(最后两次更改是在 2007 年和 1991 年。)当我们更新 GPL 时,在每个程序中使用这个“间接指针”可以让我们有可能针对整个 GNU 软件集合更改分发条款。

如果每个程序缺少间接指针,我们将被迫与许多版权持有者进行长时间的讨论,这在事实上是不可能实现的。在实践中,为 GNU 软件制定统一分发条款的机会将为零。

假设一个程序里说“GPL 的版本 3 或任何更新的版本”,并且一个新版本的 GPL 被发布。如果新的 GPL 版本提供了额外的许可,那么该权限将立即提供给程序的所有用户。但是,如果新的 GPL 版本要求更严格,则不会对使用当前版本的程序形成限制,因为该程序仍然可以依据 GPL 版本 3 进行使用。当程序里说“GPL 的版本 3 或任何更新的版本”,用户将被永远允许使用它,甚至可以依据 GPL 版本 3 的条款进行更改,即使在后续版本的 GPL 可用后也是如此。

如果GPL的新版本中更严格的要求不需要被现有软件遵守,那么它还有用吗?一旦 GPL 版本 4 可用,大多数遵循 GPL 的程序的开发人员将发布其程序的后续版本,阐明其采用“GPL 的版本 4 或任何更新的版本”。那么用户将不得不遵循 GPL 版本 4 中更严格的要求,以便使用程序的后续版本。

然而,开发人员没有义务这样做;如果这是他们的偏好,开发人员可以继续被允许使用以前版本的 GPL。

3.16 使用一个声明某个程序只能依据最新版本的 GNU GPL 进行使用的许可证是个好主意吗?

您不应该这样做,原因是它可能会导致未来某一天自动撤回用户以前拥有的一些权限。

假设一个程序是在 2000 年依据“最新的 GPL 版本”进行发布。当时,人们可以依据 GPL 版本 2 使用它。在 2007 年发布 GPL 版本 3 的那一天,每个人都将被迫不得不依据 GPL 版本 3 使用该程序。

有些用户甚至可能不知道 GPL 版本 3——但是他们将被要求使用它。他们可能会无意中违反该程序的许可证,只因为他们没有得到 GPL 版本 3发布的消息。这不是个对待别人的好方法。

除非因为违规,我们认为收回已经授予的权限是错误的做法。如果您的自由可以被撤销,那么这不是真正的自由。因此,如果您获得遵循某个版本许可证的某个版本程序的副本,则应始终具有该版本许可证授予的权限。依据“GPL 的版本 N 或任何更新的版本”进行发布维护了该原则。

3.17 有没有一些方法可以让使用我的程序的人们得到的输出物遵循 GPL?例如,如果我的程序用于开发硬件设计,我可以要求这些设计必须是自由的吗?

一般来说,这在法律上是不可能的;针对人们通过使用您的程序获取数据形成的输出物如何使用,版权法并没有赋予您任何发言权。如果用户使用您的程序输入或转换自己的数据,输出物的版权属于他,而不是您。更一般来说,当程序将其输入物转换成其他形式时,输出物的版权状态将继承其得以生成的输入物的版权状态。

所以您对输出物的使用拥有发言权的唯一方式是输出物的实质部分(或多或少)是从您程序的文本中复制出来。例如,如果我们在这种具体情况下没有例外,那么Bison的一部分输出物(参见问题 5.2)将被 GNU GPL 所涵盖。

所以,即使没有技术原因,您也可以人为制作一个程序,将某些文本复制到其输出物中。但是,如果复制的文本没有实际用途,用户可以简单地从输出物中删除该文本,并且仅使用其余的内容。那么他就不必满足重新分发所复制文本的条件。

3.18 手册为什么不使用 GPL 许可证?(同 1.7)

手册也可以使用 GPL 许可证,但对于手册来说,最好使用 GFDL(自由文本授权,GNU Free Documentation License)许可证。

GPL 是为软件程序设计的,它包含许多复杂的条款,对于程序来说至关重要;但对于图书或手册来说,这将是麻烦和不必要的。例如,任何人如果(以 GPL)出版纸质图书,就要么必须为每份印刷版本配置该图书的机器可读形式“源代码”,或提供书面文件,表明将稍后发送“源代码”。

同时,GFDL 中包含了帮助免费手册的出版商从销售副本中获利的条款,例如,出售封面文字。 背书 Endorsements 部分的特殊规则使得 GFDL 可以作为官方标准。修改版本的手册是被允许的,但该修改版本不能被标记为“该标准”。

使用 GFDL,我们允许对手册中涵盖其技术主题的文本进行修改。能够修改技术部分非常重要,因为修改程序的人理所当然地要去修改对应的文档。人们有这样做的自由,它是一种道德责任。我们的手册还包括阐述我们对自由软件政治立场的部分。我们将它们标记为 “不变量” invariant ,使得它们不被更改或删除。 GFDL 中也为这些“不变部分”做出了规定。

3.19 GPL 如何适用于字体?

字体许可是一个复杂的问题,需要认真考虑。以下许可证例外是试验性的,但被批准用于一般用途。我们欢迎关于这个问题的建议——请参阅这个解释性文章,并写邮件到 [email protected]

要使用此例外,请将该文本添加到软件包中的每个文件的许可证通知中(尽可能),在文本末尾说明该文件依据 GNU GPL 分发:

作为一个特殊的例外,如果您创建一个使用此字体的文档,并将该字体或该字体未更改的部分嵌入到文档中,则此字体本身不会导致生成的文档被 GNU 通用公共许可证 GNU General Public License 覆盖。然而,这个例外不会使文档可能被 GNU 通用公共许可证涵盖的任何其他原因无效。如果您修改此字体,您可以将此例外扩展到您的字体版本,但是您没有义务这样做。如果您不想这样做,请从您的版本中删除此例外声明。

3.20 我正在编写一个网站维护系统(有人称之为“内容管理系统”)或者是其他一些从模板生成网页的应用程序。我应该为这些模板使用什么许可证?

模板很小,不值得使用 左版 copyleft 来保护它们。在小作品上使用左版通常是无害的,但模板是一种特殊情况,因为它们与应用程序用户提供的数据结合使用,并且其组合被分发。因此,我们建议您以简单的许可条款许可您的模板。

一些模板调用 JavaScript 函数。由于 JavaScript 通常是不一般的作品,因此它值得用左版保护。由于模板与用户数据相结合,因此模板 + 用户数据 + JavaScript 可能被版权法看作是一个作品。需要在 JavaScript(受左版保护)和用户代码(通常遵循不兼容的条款)之间划清界限。

以下是执行此操作的 JavaScript 代码的一种例外:

作为 GPL 的一个特殊例外,仅对此代码进行函数调用并且为此目的通过引用将其包括在内的 HTML 文件,将被视为版权法意义下的单独作品。此外,此代码的版权所有者可以让您将该代码与依据 GNU LGPL 发布的自由软件库相结合。您可以按照此代码所遵循的 GNU GPL 条款以及此库所遵循的 LGPL 条款复制和分发这样一个系统。如果您修改此代码,则可以将此例外扩展到您的代码版本,但是您没有义务这样做。如果您不想这样做,请从您的版本中删除此例外声明。

3.21 我可以发布一个使用非自由工具开发的遵循 GPL 的程序吗?

您使用什么程序来编辑、编译、研究、记录源代码,通常对于该源代码的许可问题没有任何影响。

但是,如果将非自由库与源代码链接,那么它就是一个您需要进行处理的问题。它不阻碍依据GPL发布源代码,但是如果这些库不符合 “系统库” system library 例外情况,那么您应该附加一个明确的通知,允许您的程序与它们进行链接。有关使用 GPL 不兼容库的 FAQ 条目提供了如何执行此操作的更多信息。

3.22 我使用公钥加密来对我的代码进行签名,以确保其真实性。GPL v3 是否强制要求我发布我的私人签名密钥?

否。只有在您将遵循 GPL 的软件传递给用户产品之中,您才需要发布签名密钥,并且其硬件会在功能启动之前检查该软件来获得有效的密码签名。在这种具体情况下,您将被要求提供密钥给任何拥有该设备的人员,使其按照要求在设备上签名并安装修改后的软件,以便其运行。如果具体每个设备使用不同的密钥,那么您只需要为每个购买者提供相应的密钥。

3.23 GPL v3 是否要求投票人能够修改在投票机中运行的软件?(同 2.41)

不要求。企业分发包含遵循 GPL v3 软件的设备,最多只需要为拥有目标代码副本的人提供软件的源代码和安装信息。使用投票机(如同任何其他信息亭一样)的选民不能拥有它,甚至不能暂时拥有,所以选民也不能拥有二进制软件。

不过,请注意,投票是一个非常特殊的情况。仅仅因为计算机中的软件是自由软件,并不意味着您可以信任计算机,并进行投票。我们认为电脑不值得信任,不能被用作投票。投票应在纸上进行。

3.24 GPL v3 中的担保和免责声明似乎是依据美国法律的。我可以将自己的免责声明添加到我自己的代码中吗?

可以。GPL v3 第 7 节允许您添加自己的免责声明,具体来说是 7(a)。

3.25 我的程序具有非视觉性的交互式用户界面。如何遵守 GPL v3 中的 适当法律声明 Appropriate Legal Notices 要求?

所有您需要做的是确保适当法律声明对于您界面中的用户来说唾手可得。例如,如果您已经编写了一个音频接口,您可以包括一个大声朗读该声明的命令。

明确是避免许可歧义的关键所在。

在许可证的过去、当前和未来版本如何适用于软件程序方面,GPL 系列许可证在开源许可证中可谓独树一帜。如果不能完全理解其中独有的许可证特性,开源软件开发人员可能会无意中造成混淆。

GPL 许可证在其许可证的条款和条件中阐明了许可证版本如何适用于该程序。GPL v2(第 9 条)写到:

“每个版本都有一个独特的版本号,如果该程序指定了其适用的许可证的版本号以及‘任何更新的版本’,则可以选择遵循由 自由软件基金会 Free Software Foundation 发布的该版本或之后任何更新版本的条款和条件。如果该程序未指定许可证的版本号,则可以选择自由软件基金会以前发布的任何版本。”

GPL v3 第 14 条与 GPL v2 中的上述条款非常相似。

多年以来,我看到很多开源项目表示遵循 GPL 许可证,但却没有明确指出版本号,同时也没有将整个 GPL 许可证(例如,v2 或 v3)副本囊括在程序内。取决于您是许可人还是被许可人等因素,这其中造成的含混不清可能对您有益或有害。

许可证的模糊如何产生影响

例如,假设应用程序的许可证声明:“本程序遵循 GPL 许可证”,并且包含整个 GPL v3 许可证的副本。由于该项目没有明确说明适用该许可证的哪个版本号,所以合理的解释是自由软件基金会发布的所有版本 GPL 许可证都适用——v3、v2 甚至 v1!

依据 GPL v3 第 14 条的下述文本可以合乎情理地做出上述理解。

“如果该程序未指定 GNU GPL 的版本号,则可以选择由自由软件基金会发布的任何版本。”

另一方面,将 GPL 特定版本的完整副本(还可能包括许可证标题块中的 GPL 版本号)包含在程序中,可以被解释为在实质上传递了特定版本的许可证。在这个例子中,那就是 GPL v3 版本并且只有 GPL v3 版本,因为 v3 中没有“任何更新的版本”的条款。

如何避免许可歧义

为了避免这种许可歧义,您应该写得非常明确。如果您只想适用 GPL v3,应该明确地声明:“本程序仅遵循 GPL v3”,并提供整个 GPL v3 许可证副本。或者,如果您希望适用 GPL v3 或之后更新的版本,请明确声明:“本程序遵循 GPL v3 或其之后更新的版本”。最后,如果您真的想要适用任何版本的 GPL 许可证,您可以提供 GPL v3 许可证,并表示:“本程序遵循由自由软件基金会发布的任何版本的 GPL 许可证”。

无论您选择哪种授权方式,都应该非常明确,让每个人都能理解您的真正意图。


作者简介:Jeffrey R. Kaufman是全球领先的开源软件解决方案供应商Red Hat公司的开源知识产权律师,还担任托马斯杰斐逊法学院(Thomas Jefferson School of Law)的兼职教授。在任职Red Hat之前,Jeffrey曾担任高通公司(Qualcomm Incorporated)的专利顾问,为首席科学家办公室(Office of the Chief Scientist)提供开源事务咨询。

译者简介:薛亮,集慧智佳知识产权咨询公司高级咨询师,擅长专利检索、专利分析、竞争对手跟踪、FTO分析、开源软件知识产权风险分析,致力于为互联网企业、高科技公司提供知识产权咨询服务。


via: https://opensource.com/article/17/11/avoiding-gpl-confusion

作者:Jeffrey Robert Kaufman 译者:薛亮 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

提要:Linux 社区的许多开发人员对 GPL 许可证牟利者 Patrick McHardy 的行为表示担忧,美国资深开源律师对一些常见问题进行解答,并对如何应对版权牟利行为提出了建议。

针对 Patrick McHardy 强制要求 Linux 分发者遵循 GPL 许可证的举动,开源社区许多人士表示了担忧。基于与 McHardy 行动相关的公开信息,以及开源合规维权的一些法律原则,美国资深开源律师对一些常见问题进行了解答。

Patrick Mchardy 是谁? McHardy 是 Netfilter 核心开发团队的前任负责人。 Netfilter 是 Linux 内核中的一个实用程序,可以执行各种网络功能,例如改善网络地址转换(NAT),NAT 是将 Internet 协议地址转换为另一个 IP 地址的过程。对于维护 Linux 系统的安全性来说,控制网络流量至关重要。

McHardy 对 Linux 有多少贡献?

这不是一个容易回答的问题。首先,评估贡献的重要性并不容易;我们能做的就是查看 提交 commit 的数量和大小。其次,即使去跟踪提交,跟踪机制也不完美。 Git 有一个 blame 功能,跟踪谁在名义上向 Git 数据库提交了哪些代码行。Git 的 blame 功能可以使用诸如 cregit 这样的工具,以更具细粒度的水平来报告提交,从而在文件级别上对贡献度有一个更准确的认知。Git 的 blame 机制和 cregit 是非常实用的,因为它们都使用公开易得的信息,而信息只需要被正确解释。

结合 cregit 和 blame 进行分析可以帮助评估 McHardy 的潜在贡献。例如:

  • 他的大部分贡献似乎是在 2006 年到 2008 年和 2012 年期间。
  • 在 McHardy 包含其版权声明的大约 135 个文件中,只有 1/3 的文件是 McHardy 贡献了该文件代码的 50% 或以上。
  • 他的贡献看起来不到内核代码的 0.25%。

McHardy 的大部分贡献似乎都给了 Netfilter;然而,blame 机制可能并不总能还原全貌。例如,提交者可以 签入 check in 许多行代码,但只进行细微修改,也可以签入其他人编写或拥有的代码。由于这些原因,提交者的作者身份可能被过低或过多报告。

在 2002 年之前对内核贡献的记录对于识别贡献者来说不是特别有用,因为在当时,Linus Torvalds 签入了所有代码。 McHardy 的贡献直到 2004 年才开始。

Hellwig 诉 VMware 一案中出现了使用开发存储库的元数据确认版权所有权的困难。法院可能不愿意接受这样的信息来作为证明作者身份的证据。

McHardy 在 Linux 内核中拥有哪些版权?

大型项目(如 Linux 内核)的版权归属复杂。这就像一个拼凑的被子。当开发者对内核做出贡献时,他们不签署任何贡献协议或版权转让协议。GPL 涵盖了他们的贡献,软件副本的接收人根据 GPL 直接从所有作者获得许可。内核项目使用一个名为 “原始开发者证书” Developer Certificate of Origin 的文件,该文件不授予任何版权许可。贡献者的个人权利与在项目中的权利作为整体并存。 所以,像 McHardy 这样的作者一般都会拥有他所创作的作品的版权,但并不享有整个内核的版权。

什么是 “社区维权” community enforcement

由于大型项目(如 Linux 内核)的所有权常常分散在许多作者手中,所以个体所有者可以采取不符合社区目标的维权行动。虽然社区可能会对如何以最好的方式来鼓励遵守 GPL 条款有很多看法,但大多数人认为维权应该是非正式的(不是通过诉讼),而且主要目标应该是合规(而不是惩罚)。例如, 软件自由保护组织 Software Freedom Conservancy (SFC)已经颁布了一些社区维权原则,其中优选合规,而不是寻求诉讼或赔偿金。对于非正式行为何时应该成为诉讼,或维权者应该要求赔偿多少钱,没有明确的规定。然而,Linux 社区的大多数开发人员将诉讼视为最后的手段,并不愿意采取法律行动,而与真正希望合规的用户进行合作。

为什么这么多的开源诉讼在德国提交?

一些寻求进行开源许可证维权的原告已经向德国法院提交权利主张。在德国有一些在美国或其他 普通法 common law 国家没有能够确切与之类比的寻求法律诉讼的手段。

  • Abmahnung “警告” warning :“警告”是索赔人要求被告停止做某事的要求。在版权语境下,这是版权所有者发出的一封信函,要求所述侵权人停止侵权。这些信件是由律师而不是法庭签发的,通常是德国版权维权行动的第一步。在美国,最接近的方式应该是 警告信 cease and desist letter
  • Unterlassungserklaerung “停止声明” cease and desist declaration “禁止声明” declaration of injunction :“警告”通常会附有“停止声明”。这种“声明”就像合同一样,签署的话会要求被告人承担其它并不存在的法律义务。特别是,该声明可能包含 GPL 本身并不要求的义务。在德国,这样一份文件通常包含针对不合规进行惩罚的内容。在美国,类似的做法是和解协议,但和解协议很少规定违约的处罚方式,事实上在美国,合同中的“处罚”可能无法强制执行。“声明”不是法院命令,但如果被告签字,可以获得法院命令的法定效力。所以,在征求律师法律意见之前签字往往不是一个好主意。在考虑如何应对寄出停止声明的原告时,还有其他方法,包括提出修改后的处罚或义务较少的声明。此外,由于停止声明可能包含不公开的要求,签署这些文件也可能产生额外的困难,例如限制原告寻求其他被告支持或向社区公开索赔人的权利主张。
    更多详情参见:abmahnung.org/unterlassungserklaerung/
  • Einstweilige Verfügung(“ 临时禁令 interim injunction ”或“ 初步禁令 preliminary injunction ”):“临时禁令”是一项类似美国临时禁令的法院命令。虽然没有要求原告在向法院提出“临时禁令”之前发出“警告”,但在被告对“警告”或“声明”不作出回应时,鼓励原告寻求“临时禁令”。侵犯版权的临时禁令可以处以 25 万欧元罚款或 6 个月的监禁。相比之下,在美国,侵犯版权的刑事处罚极为罕见,必须由政府而不是私人机构追究。此外,在美国,法院也没有为未来的侵权行为提供补救措施,它们只是要求被告停止现行的侵权行为或者支付损害赔偿金。在德国, 单方 ex parte 也可以提出临时禁令,这意味着原告可以在没有被告听证的情况下向法院提出申请,而且可以在没有被告参与的情况下发出临时禁令。如果您收到“警告”,并怀疑原告可能会随之提出 “临时禁令”,可以向法院抢先提出 “异议” opposition
    更多详情参见:Abmahnung.org
  • Widerspruch “异议” opposition “反驳” contradiction :“异议”是被告向法院提出否决“临时禁令”的机会。
    更多详情参见:这篇德国法院命令的英文翻译

McHardy 发起了多少权利主张?

由于许多德国法庭案件缺乏公开记录,因此很难确定 McHardy 的确切行动数量。据说 McHardy 已经接触了超过 50 个维权目标。有关详细信息,请参阅 “源码控制” Source Code Control 《2016 年开源社区 7 个显著的法律进展》 7 Notable Legal Developments in Open Source in 2016 。这并不一定意味着有 50 起诉讼,而是可能意味着 50 起威胁要提起诉讼的要求。但是,很难用公开信息来核实这个说法。有关详细信息,请参阅 《开源生态系统的诉讼和合规》 Litigation and Compliance in the Open Source Ecosystem

为什么社区没有去阻止 McHardy?

包括软件自由保护组织在内的各种社区成员已经开始试图说服 McHardy 改变策略,但到目前为止还没有成功。 Netfilter 项目最近发布了一个许可问答,解决大家对 McHardy 行为担忧的问题。

我们可以做些什么来阻止 McHardy 和其他版权牟利者?

这个问题没有确定的答案,也许没有办法能完全阻止他们。但是,这些建议可能会减少版权牟利者的数量。

  • 尽可能遵守开源许可证。目前有足够的资源来学习如何遵守许可证,以及如何在贵公司设立开源合规计划。例如:

  • 在寻求法律意见之前不要签署 “停止声明” Unterlassungserklärung 如上所述,停止声明可能让您承担 GPL 身没有的义务和处罚。不要与版权牟利者合作。你可以使自己成为一个更难攻克的目标,并争取社区其他目标的帮助。
  • 支持开源开发。作者不应该诉诸投机来谋生。使用开源软件的公司不应该期望开源开发人员免费开发软件,他们应该筹集资金支持重要项目。
  • 学会识别版权牟利者。了解社区导向的 GPL 维权与版权勒索之间的一般差异。面向社区的维权一般旨在通过教育和帮助实现 GPL 合规,同时尊重用户的自由。相比之下,牟利行为可能侧重以不加考究和漫无目的的权力主张和威胁要提起法律诉讼来获得经济利益。注意确认优先考虑经济利益的权利主张,警惕不合理的损害赔偿金。
  • 公开权利主张。如果你是一个牟利者的目标,并且可以选择公开其权利主张,那就公开它,通过阻碍对方的行动来帮助你和其他人。作为开源社区的成员,我们都有义务向那些企图以诉讼拖垮社区的牟利者们提出反对,因为问题能够以更恰当和更少争议的方式解决。

作者简介:Heather Meeker 是 O’Melveny & Myers 硅谷办公室的合伙人,为客户提供技术交易和知识产权方面的建议,是国际知名的开源软件许可专家。Heather 于 2016 年获得加州律师协会知识产权先锋奖。 《最佳律师》 Best Lawyers 将她提名为 2018 年年度 IT 律师。

译者简介:张琳,集慧智佳知识产权咨询公司分析师,专业德语,辅修法律。