LGPL 和 Java

David Turner 著

---

FSF 一直以来的立场都是如果把应用和库动态的连接到一起，就构成了一个由库代码和应用代码共同创建的单一衍生作品。GPL 许可证要求所有衍生作品都要作为一个整体遵循 GPL 的条款，这个效果可以用 “遗传” 一词来描述。因此，如果一个应用连接到一个按照 GPL 发布的库，那么该应用也必须按照 GPL 授权。反之，按照 GNU 宽通用公共许可证（LGPL）授权的库可以被专有的应用连接。

在 2003 年 7 月，Slashdot 发表了一篇文章，声称我说 LGPL 对 Java 而言不是按照预想的方式执行的。该文章基于一篇对发给 licensing@gnu.org 的问题回复的错误理解之上，而且对 Slashdot 文章的多次澄清努力都未能奏效。此后，我收到了关于此文的众多疑问，有发到 licensing@gnu.org 的，也有发到我的私人邮箱的。

FSF 的立场始终如一：LGPL 对所有已知编程语言都一样，包括 Java。连接 LGPL 库的应用不一定要按照 LGPL 授权。该应用只需遵循 LGPL 第 6 节中的要求：允许新的库版本连接到该应用；并且允许使用反向工程的方法来调试。

Java 程序的典型配置是应用用到的每个库都以一个独立的 JAR（Java Archive）文件来分发。应用使用 Java 的 “import” 机制来访问库中的类。当应用编译之后，系统根据库的签名来创建链接。那么应用一般来说就是库的一个衍生作品。因此，库的版权所有者必须授权该作品的发布。LGPL 允许这样的发布。

如果你发布的 Java 应用要导入 LGPL 库，那么它很容易符合 LGPL 许可证的要求。你应用的许可证需要允许用户修改该库，并且允许通过对你的代码进行反向工程来调试这些修改。这并不意味着你需要提供源代码或你应用的内部详解。你不必担心这些——修改库的人负责让这一切能够正常工作。

当你和应用一起发布库（或者单独发布库）时，你需要包含库的源代码。但是如果你的应用需要用户自己去获取库，那么你就不需要提供库的源代码。

从 LGPL 的角度来看，Java 和 C 的区别只在于 Java 是一种面向对象的语言，它支持继承。LGPL 对继承并没有特殊的要求，因为没有必要。继承创造衍生作品的方式和传统连接是一样的，并且 LGPL 允许此类衍生作品的方式和常规函数调用也是一样的。