LGPL 和 Java

作者：David Turner

本文写于 2004 年 11 月，当时 LGPLv2.1 是该许可证的最新版本。此后，LGPLv3 已发布。本文的主要观点对于 LGPLv3 仍然适用，但一些细节，例如章节编号，已经发生了变化。

FSF 的立场一直认为，将应用程序动态链接到库会创建一个同时派生自库代码和应用程序代码的单一作品。GPL 要求所有衍生作品都必须在 GPL 的条款下作为一个整体授权，这种效果可以描述为“世袭的”。因此，如果应用程序链接到根据 GPL 授权的库，则该应用程序也必须根据 GPL 授权。相比之下，根据 GNU 宽通用公共许可证 (LGPL) 授权的库可以链接到专有应用程序。

在 2003 年 7 月，Slashdot 发布了一篇报道，声称我曾说过在 Java 的情况下，LGPL 没有按预期工作。这个报道是基于对发送到 [email protected] 的问题的回复的误解，并且许多在 Slashdot 报道中澄清此问题的尝试都没有成功。从那以后，我通过 [email protected] 和个人电子邮件收到了许多关于该报道的问题。

FSF 的立场始终保持不变：LGPL 可以与所有已知的编程语言（包括 Java）按预期工作。链接到 LGPL 库的应用程序无需根据 LGPL 发布。应用程序只需要遵守 LGPL 第 6 节中的要求：允许将库的新版本链接到应用程序；并允许进行逆向工程来调试此问题。

Java 的典型安排是，应用程序使用的每个库都作为单独的 JAR（Java 存档）文件分发。应用程序使用 Java 的“import”功能来访问这些库中的类。编译应用程序时，会根据库检查函数签名，从而创建链接。然后，该应用程序通常是该库的衍生作品。因此，该库的版权所有者必须授权分发该作品。LGPL 允许这种分发。

如果您分发导入 LGPL 库的 Java 应用程序，则很容易遵守 LGPL。您的应用程序的许可证需要允许用户修改库，并对您的代码进行逆向工程以调试这些修改。这并不意味着您需要提供源代码或有关应用程序内部的任何详细信息。当然，用户对库所做的一些更改可能会破坏接口，导致该库无法与您的应用程序一起使用。您无需担心这一点 - 修改库的人有责任使其正常工作。

当您将库与您的应用程序一起分发（或单独分发）时，您需要包含库的源代码。但是，如果您的应用程序反而要求用户自行获取库，则您无需提供库的源代码。

从 LGPL 的角度来看，Java 和 C 之间的唯一区别是 Java 是一种面向对象的语言，支持继承。LGPL 没有针对继承的特殊规定，因为不需要任何特殊规定。继承以与传统链接相同的方式创建衍生作品，并且 LGPL 允许这种类型的衍生作品，就像它允许普通的函数调用一样。