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

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

Opensource.com

GNU Affero 通用公共许可证版本 3 (AGPLv3) 是一种著作权许可证,几乎与 GPLv3 完全相同。两种许可证具有相同的著作权范围,但在一个重要方面存在实质性差异。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 没有区别:您可能正在传播,但您没有传达,并且著作权是由传达触发的,而不是由在您不分发副本时传播触发的,恕我直言。

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

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

回复 ,作者:Philippe Ombredanne

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

是的,祝你好运。实际上,不,祝你倒霉——如果有人尝试这样做并试图在法庭上为它辩护,我希望他们崩溃、烧毁并失去所有金钱。我认为我们可以相当肯定地说,AGPL 的作者会希望面对这种诡辩时也能遇到类似的情况,并且如果看起来这种规避在法律上有一丝机会奏效,他们将在未来修补许可证以阻止它。

回复 ,作者:Philippe Ombredanne

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

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

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

依我拙见,这不像您说的那么简单。
“不修改”仍然不会消除 AGPL 的著作权效应,如果它是您程序的一部分。
因此,如果与 AGPL 库链接,则传达的作品(意味着您的程序)仍然必须以源代码的形式整体提供。第 13 节提到链接,并且在我看来,它与第 1 节“相应源代码”(基本上是程序运行所需的任何内容...)有关。

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

除非原始 AGPL 部分被聚合(第 5 节)或它们不是第 1 节所指的“相应源代码”,否则需要满足上述所有条件。

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

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

回复 ,作者: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.