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

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

Opensource.com

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, Inc. 的高级商业律师(开源法律团队),Red Hat, Inc. 是全球领先的开源软件解决方案提供商。Jeffrey 还担任北卡罗来纳大学法学院的兼职教授。

9 条评论

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

请参阅我的其他评论。如果在没有第 13 节规定的情况下下载相应的源代码,并且您使用未修改的代码,则 AGPLv3 与 GPLv3 没有区别:您可能正在传播,但您没有传递,并且 copyleft 是由传递而不是传播触发的,当您不分发副本时,IMHO。

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

两个例子:一个文档管理系统以 war 文件的形式出现,并受 AGPL 保护。在这种情况下,您按原样使用受版权保护的作品。您向系统中添加文档,也许您更改了一些设置等等。这种使用不会导致任何这些文档或设置变成开源。但是,假设您正在使用 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。由于 AGPL 在 Web 应用程序中使用时等于 LGPL 是荒谬的,因此您的初始前提一定是错误的,您不同意吗?您是否同意 AGPL 中没有这样的漏洞?

知识共享许可协议本作品根据知识共享署名-相同方式共享 4.0 国际许可协议获得许可。
© . All rights reserved.