The LGPL and Java: Java で LGPL のライブラリを利用する場合のライセンス: uyota 匠の一手

Java プログラムで LGPL で公開されているライブラリを利用したときに従わなければいけない事項の説明は The LGPL and Java が一番良さそうだ。何より、GNU 自身から出されているので、自らの主張は歪曲することなく含まれていると思われる。ただ、彼らの主張することが全て法的に正しいと解釈されるのかは、私には判断がつかない。

Java NetBeans で構築した GUI には LGPL のライブラリが否応無しに同包されるので、最低限でも LGPL に沿ったライセンスにする必要が出てくる。そこで、全文引用し、重点を訳してみる。 訳さなかった部分は打ち消し線を引いている。

This article was written in November 2004, when LGPLv2.1 was the most current version of the license. Since then, LGPLv3 has been published. The main points of this article remain true about LGPLv3, but some of the details, such as section numbers, have changed.

この文章は、LGPLv2 が最新だった 2004 年 11 月に書かれたもので、その後に LGPLv3 が発行されました。しかし、章番号など詳細な部分が変わることがあっても、この文章の本質的は意味は変わっていません。

It has always been the FSF's position that dynamically linking applications to libraries creates a single work derived from both the library code and the application code. The GPL requires that all derivative works be licensed under the GPL, an effect which can be described as “hereditary.” So, if an application links to a library licensed under the GPL, the application too must be licensed under the GPL. By contrast, libraries licensed under the GNU Lesser General Public License (LGPL) may be linked to proprietary applications.

FSF において、動的ライブラリを用いて動作するプログラムは派生物 (derived) だという見方をとっています。GPL は全ての派生物が GPL ライセンスに従うことを必須としています。そのため、GPL ライブラリを用いる場合には、アプリケーションも GPL に従わなければいけません。それに引き替え、LGPL ライブラリは私有ソフトウェアでの利用も許可しています。

In July of 2003, Slashdot published a story claiming that I had claimed that the LGPL did not function as intended in the case of Java. This story was based on a misunderstanding of a response to a question sent to [email protected], and many attempts to clarify the issue in the Slashdot story did not get across. I have recieved numerous questions about the story since, via both [email protected] and personal email.

FSF's position has remained constant throughout: the LGPL works as intended with all known programming languages, including Java. Applications which link to LGPL libraries need not be released under the LGPL. Applications need only follow the requirements in section 6 of the LGPL: allow new versions of the library to be linked with the application; and allow reverse engineering to debug this.

FSF の取る立場は一貫して変わっていません。LGPL は Java を含めた全ての言語に体して有効です。LGPL ライブラリにリンクするプログラムは LGPL に縛られる必要はありません。そのようなプログラムは、LGPL の第六章に従う必要があるだけです。つまり、新しいバージョンのライブラリとリンクできる様にするのと、デバッグの為のリバースエンジニアリングを許可することです。

The typical arrangement for Java is that each library an application uses is distributed as a separate JAR (Java Archive) file. Applications use Java's “import” functionality to access classes from these libraries. When the application is compiled, function signatures are checked against the library, creating a link. The application is then generally a derivative work of the library. So, the copyright holder for the library must authorize distribution of the work. The LGPL permits this distribution.

一般的な Java プログラムでは、ライブラリは個別の jar ファイルによって配布されます。Java の import はこれらのライブラリの class ファイルにアクセスするのに用いられます。プログラムがコンパイルされた時に、このライブラリのインターフェースが調べられ、結合されます。その為、このプログラムはライブラリの派生物として見なされます。この著作物の権利者であるライブラリの作者はこのライブラリの再配布を認めます。そして、LGPL はこの配布を許可します。

If you distribute a Java application that imports LGPL libraries, it's easy to comply with the LGPL. Your application's license needs to allow users to modify the library, and reverse engineer your code to debug these modifications. This doesn't mean you need to provide source code or any details about the internals of your application. Of course, some changes the users may make to the library may break the interface, rendering the library unable to work with your application. You don't need to worry about that—people who modify the library are responsible for making it work.

もし、あなたの Java プログラムが LGPL ライブラリを import した場合は LGPL に従います。あなたのライセンスは自由にライブラリを変更することを認めなければいけず、そのための手段としてリバースエンジニアリングをすることを許可しなければいけません。しかし、これはソースコードを配布したり、プログラムの詳細を公開しなければいけないという事ではありません。

When you distribute the library with your application (or on its own), you need to include source code for the library. But if your application instead requires users to obtain the library on their own, you don't need to provide source code for the library.

もし、あなたのアプリケーションと共にライブラリを配布するのであれば、ライブラリのソースも提供しなければなりません。しかし、もし使い手自身にライブラリを取得してもらうのであれば、ライブラリのコードを提供する必要はありません。

The only difference between Java and C from the LGPL's perspective is that Java is an object-oriented language, supporting inheritance. The LGPL contains no special provisions for inheritance, because none are needed. Inheritance creates derivative works in the same way as traditional linking, and the LGPL permits this type of derivative work in the same way as it permits ordinary function calls.

Java 言語と C 言語の大きな違いは、Java 言語はオブジェクト指向言語であり、継承をサポートすることです。。LGPL は継承に対して特別な扱いはしません。継承はただ単に従来の言語の様に派生物を生成するだけです。LGPL はこの様な物も従来の関数呼出しと同じように扱います。

つまりは、要約すると「LGPL のライブラリを個々の jar ファイルとして使う分には、自らのプログラムのライセンスは自由に決められる。そして、ライブラリも自分のプログラムと共に提供するのであれば、ライブラリのコードも提供する必要がある。もし、各自に取得させるのであれば、ライブラリのコードも要らない。」ぐらいだろう。

jar ファイルを一度分解し、プログラムの jar ファイルの中に入れてしまうのは、彼らの言い分では黒なようだ。もし、コードを公開したくないのなら、止めておいた方が無難そうだ。

前回。