我需要在 AGPLv3 许可下提供源代码访问权限吗?

549 位读者喜欢这篇文章。
Platform wars: software patents in a new light

Opensource.com

The GNU Affero 通用公共许可证第 3 版 (AGPLv3) 是一种copyleft许可证,几乎与 GPLv3 相同。这两个许可证具有相同的 copyleft 范围,但在一个重要方面存在实质性差异。AGPLv3 的第 13 节规定了 GPLv2 或 GPLv3 中不存在的附加条件

尽管本许可证有任何其他规定,如果您修改了程序,您的修改版本必须显著地为所有通过计算机网络远程与程序交互的用户(如果您的版本支持此类交互)提供机会,通过从网络服务器免费提供对相应源代码的访问,并通过一些标准或习惯的软件复制便利方式,来接收您的版本的相应源代码。

此条件旨在主要应用于现在被认为是 SaaS 部署的情况,尽管“通过计算机网络远程交互”的范围或许应理解为涵盖超出传统 SaaS 的情况。其目的是为了弥补普通 GPL 中感知到的漏洞,即在用户使用作为 Web 服务提供的功能,但没有发生提供该功能的代码分发的环境中。因此,第 13 节提供了超出 GPLv2 第 3 节以及 GPLv3 和 AGPLv3 第 6 节中包含的目标代码分发触发要求的附加源代码披露要求。

经常被误解的是,AGPLv3 第 13 节中的源代码要求仅在 AGPLv3 软件已被“您”(例如,提供网络服务的实体)修改时才会被触发。我的理解是,只要“您”不修改 AGPLv3 代码,该许可证就不应被理解为要求以第 13 节规定的方式访问相应源代码。在我看来,许多未修改和标准部署的 AGPL 下的软件模块根本不会触发第 13 节,尽管即使许可证没有要求,但提供源代码也是一个好主意。

如何解释 AGPL 的条款和条件,包括 AGPL 软件是否已被修改,可能需要根据具体用例的事实和细节进行法律分析。

标签
Picture of Jeffrey Robert Kaufman
Jeffrey R. Kaufman 是 Red Hat 公司(全球领先的开源软件解决方案提供商)的高级商业顾问(开源法律团队)。Jeffrey 还担任北卡罗来纳大学法学院的兼职教授。

9 条评论

既然 GPL 要求提供源代码访问权限,并且 AGPLv3 第 13 节是一个*附加*条件(专门添加用于弥补类似 SaaS 软件中的漏洞),这是否意味着 AGPLv3 也要求提供源代码访问权限,无论是否修改过?

请参阅我的其他评论。如果没有第 13 节规定来下载相应的源代码,并且您使用未修改的代码,则 AGPLv3 与 GPLv3 没有什么不同:您可能正在传播,但您没有转让,并且 copyleft 是由转让触发的,而不是由传播触发的,当您不分发副本时,恕我直言。

回复 ,作者 Amol Khiste (未验证)

两个例子:文档管理系统以 AGPL 许可的 war 文件形式出现。在这种情况下,您按原样使用受版权保护的作品。您向系统添加文档,也许您更改了一些设置等等。这种使用不会导致任何这些文档或设置变成开源的。但是,假设您正在使用 AGPL 库作为基本组件创建自己的文档管理系统,您正在以需要版权许可的方式创建基于该 AGPL 库的作品。根据第 0 条,这符合修改的条件,因为您正在创建“基于”早期作品的作品。我引用: “修改”作品意味着以需要版权许可的方式从作品中复制或改编作品的全部或部分,而不是制作精确副本。由此产生的作品被称为早期作品的“修改版本”或“基于”早期作品的作品。在这种情况下,问“AGPL 的哪一部分说明了...”是没有意义的,因为 AGPL 引用了版权法,其中说“以需要版权许可的方式”。

回复 ,作者 Philippe Ombredanne

哦,我现在明白了——这是一种尝试,旨在使 AGPL 中的“修改”与 GPL 本身中的“修改”含义不同,这样您就可以做一些在 GPL 中会被认为是“修改”(因此触发 copyleft)的事情,并声称它们不构成 AGPL 中额外条款意义上的“修改”(因此不会触发 copyleft),这样您就可以将 AGPL 代码合并到更大的闭源程序中,并仍然保持闭源。

是的,祝你好运。实际上,不,祝你倒霉——如果有人尝试这样做并试图在法庭上为它辩护,我希望他们彻底失败,损失所有金钱。我认为我们可以相当肯定地说,AGPL 的作者会希望面对这种诡辩时也能如此,如果看起来这种躲避在法律上有一点点可能奏效,他们将在未来修补许可证以阻止它。

回复 ,作者 Philippe Ombredanne

不。它弥补的是与此不同的“漏洞”。如果您没有修改它,您就没有义务提供源代码。用户可以从您获取源代码的任何地方获取源代码。

话虽如此,如果您没有修改它,您也没有什么要保护的,因此这对您来说没有任何损失,并且至少提供一个指向 Github 或其他任何地方的链接将是一种友好的姿态。

回复 ,作者 Amol Khiste (未验证)

恕我直言,事情并不像您说的那么简单。
“不修改”仍然不会消除 AGPL 的 copyleft 效应,如果它是您程序的一部分。
因此,如果转让的作品(意味着您的程序)与 AGPL 库链接,仍然必须以源代码的整体形式提供。第 13 节提到了链接,并且在我看来与第 1 节“相应源代码”(基本上是程序运行所需的一切...)有关。

由此可见,您实际上并没有修改原始 AGPL 部分,但仍然有义务公开整个组合作品的源代码 :)

除非原始 AGPL 部分被聚合(第 5 节)或它们不是第 1 节中定义的“相应源代码”,否则以上所有内容都是必需的。

如果您不同意,我很乐意讨论,该许可证非常复杂...!

关键点在于 AGPL 的“网络 copyleft”是由转让触发的。而使用未修改的代码(即使在公共 Web 应用程序中)不是转让,充其量只是传播,在这种情况下,copyleft 不会被触发。恕我直言,这是一个微妙但至关重要的区别。

回复 ,作者 jk

如果您的解释是正确的,那么您就将 AGPL“降级”为 LGPL,而这并不是 AGPL 的目的。我不是律师,但我懂数学。在数学中,您可以使用“归谬法”来证明或证伪某些事物。假设您是对的,并且公司 A 可以在闭源 Web 应用程序中使用 AGPL 库 X,只要公司 A 不修改库 X 的单个字节。如果是这样,那么修改任何 AGPL 库都不会导致共享源代码的义务,因为人们总是可以引入中间人来应用修改。公司 A 可以使用中间人 B 来应用所需的修改。中间人 B 创建库 Y,它是修改后的库 X。中间人 B 在 AGPL 下发布库 Y(他应该这样做)。现在,如果您的说法是正确的,那么公司 A 现在可以在闭源应用程序中使用修改后的库 X(又名库 Y),并且您已经在 AGPL 中打了一个洞,使其在服务器端应用程序的上下文中降级为 LGPL。既然在 Web 应用程序中使用时,AGPL 等于 LGPL 是荒谬的,那么您的初始前提一定是错误的,您同意吗?您是否同意 AGPL 中没有这样的漏洞?

© . All rights reserved.