根据 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
杰弗里·R·考夫曼是世界领先的开源软件解决方案提供商 Red Hat, Inc. 的高级商业顾问(开源法律团队)。杰弗里还担任北卡罗来纳大学法学院的兼职教授。

9 条评论

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

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

回复 ,作者:阿莫尔·基斯特 (未验证)

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

回复 ,作者:菲利普·翁布雷丹

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

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

回复 ,作者:菲利普·翁布雷丹

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

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

回复 ,作者:阿莫尔·基斯特 (未验证)

依我拙见,事情并不像您说的那么简单。
“不修改”仍然不会消除 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.