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アーカイブ)ファイルとして配布することです。アプリケーションはJavaの“import”機能を使って、これらのライブラリからクラスにアクセスします。アプリケーションがコンパイルされると、関数シグネチャがライブラリに対して確認され、リンクが作られます。この時、アプリケーションは一般にライブラリの派生作品となります。ですから、ライブラリの著作権者が、この作品の配布を認可する必要があります。LGPLはこの配布を認めます。

LGPLのライブラリをインポートするJavaアプリケーションを配布する場合、LGPLに従うのは簡単です。アプリケーションのライセンスは、ユーザにライブラリの改変を許し、これらの変更のデバッグのためにあなたのコードのリバース・エンジニアリングを許す必要があります。これは、ソースコードや、アプリケーションの内部の詳細について提供する必要を意味しません。もちろん、ユーザがライブラリに対して行い得る変更には、インタフェースを犯すものもあり得ますから、ライブラリをアプリケーションとともには動かなくしてしまうものもあるでしょう。これについては心配する必要はありません。ライブラリを変更する人々に、それを動くようにする責任があるのです。

ライブラリをアプリケーションとともに(あるいはそれだけで)配布する場合、ライブラリのソースコードを含める必要があります。しかし、アプリケーションがユーザ自身にライブラリを取得することを要求する場合、ライブラリのソースコードを提供する必要はありません。

LGPLの観点からのJavaとCの違いは、ただ一つ、Javaはオブジェクト指向言語で、継承をサポートすることです。LGPLは、特に必要ないので継承について特別な規程は何もありません。継承は伝統的なリンクと同じ方法で派生作品を作り、LGPLはこの種の派生作品を通常の関数呼び出しに認めるのと同じ方法で認めます。