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 ファイルの中に入れてしまうのは、彼らの言い分では黒なようだ。もし、コードを公開したくないのなら、止めておいた方が無難そうだ。

前回。