如果您的解释是正确的，您就将 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 中不存在这样的漏洞？
两个例子：一个文档管理系统作为一个由 AGPL 覆盖的 war 文件出现。 在这种情况下，您正在按原样使用受版权保护的作品。 您将文档添加到系统中，也许您更改了一些设置等等。 这种使用不会导致任何这些文档或设置变为开源。 但是，假设您正在使用 AGPL 库作为基本组件创建自己的文档管理系统，那么您正在创建一个基于该 AGPL 库的作品，这需要版权许可。 根据第 0 条，这符合修改的条件，因为您正在创建一个“基于”早期作品的作品。 我引用：对作品进行“修改”是指以需要版权许可的方式复制或改编作品的全部或部分，而不是制作完全相同的副本。 生成的作品被称为早期作品的“修改版本”或“基于”早期作品的作品。 在这种情况下，问“AGPL 的哪个地方说了...”是没有意义的，因为 AGPL 在“以需要版权许可的方式”时引用了版权法。
如果您的解释是正确的，您就将 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 中不存在这样的漏洞？