[en] English   [de] Deutsch   [fr] français   [ja] 日本語   [pl] polski   [pt-br] português   [ru] русский   [zh-cn] 简体中文  

这是针对英文原版页面的中文翻译。

LGPL 和 Java

David Turner

本文撰写于 2004 年 11 月,当时 LGPLv2.1 是最新的许可证版本。随后,LGPLv3 发布。本文的主要观点对 LGPLv3 来说也是正确的,但是其中一些细节,诸如章节号等,有些变化。

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 允许此类衍生作品的方式和常规函数调用也是一样的。

最顶

[FSF 标志]“自由软件基金会(FSF)是一个非盈利组织。我们的使命是在全球范围内促进计算机用户的自由。我们捍卫所有软件用户的权利。”

加入 购物