Oracle が JVM のプロ (または何とでも呼ぶ) バージョンを有料にする意向を発表し、IBM が OpenJDK をサポートする意向を発表したことに関する現在の進展により、多くの Java 開発者にとって状況は非常に複雑になっています。私たちは Java で多くの作業を行っており、これまでライセンス条件の選択に問題はありませんでした。IBM がサポートを提供する OpenJDK に切り替える必要があるようです。しかし、OpenJDK は GPL V2 であり、私の知る限り、GPL V2 にリンクするコードはすべて GPL V2 でなければなりません。また、さらに大きくなる JNI コードもいくつかあります。これらの事実を考えると、OpenJDK を使用してソフトウェアを実行する場合、ライセンスを GPL に切り替える必要があるということですか? 言うまでもなく、これは私たちのライセンスとビジネスモデルのセットアップ全体を吹き飛ばすでしょう.
3 に答える
OpenJDKのライセンスは「GPLv2」ではなく、「クラスパス例外のあるGPLv2」です。引用:
特別な例外として、このライブラリの著作権所有者は、このライブラリを独立したモジュールとリンクして、これらの独立したモジュールのライセンス条件に関係なく、実行可能ファイルを作成し、選択した条件で結果の実行可能ファイルをコピーして配布することを許可します。リンクされた独立したモジュールごとに、そのモジュールのライセンスの条件も満たしていることを条件とします。独立したモジュールは、このライブラリから派生したものでも、このライブラリに基づいたものでもないモジュールです。
OpenJDK を JVM として使用する場合、ソース コードを開く必要がありますか?
絶対違う。
OpenJDK ベースの JVM を使用する商用のクローズド ソース Java アプリケーションが数多くあります。@Chris Lercherが言及している「クラスパス例外」は、これを特に合法的にします。
ちなみに、「クラスパス例外」は、特に GNU クラスパス ライブラリ (Java SE ライブラリのクリーンルームでの再実装) を使用して独自の/クローズド ソース アプリケーションを実行できるようにするために、FSF の弁護士によって考案されました。したがって、名前...
心配する必要があるのは、次のような場合だけです。
- 実装で OpenJDK コード ベースを利用するクローズド ソース JVM。
- 変更のためのソース コードを含まない、OpenJDK クラスの変更されたコピーを含むクローズド ソース アプリケーション。
- Classpath 例外としてマークされていない特定の OpenJDK GPLv2 クラスにリンクするクローズド ソース アプリケーション。
OpenJDK 11 では、最後のカテゴリは、とにかく OpenJDK ディストリビューションに含まれていない多数の「テスト」クラスと、アプリケーションにリンクしてはならない (おそらくリンクできない) 内部クラスで構成されているようです。これらのクラスは簡単に識別できます。「Classpath」という単語ではなく「GNU」という単語を含む Java ソース ファイルを OpenJDK ソース ツリーで検索します。
OpenJDK Java コード ベースのかなりの部分が、寛容なオープン ソース ライセンスを持つサードパーティ コードであることは注目に値します。これらのクラスへのリンクは許可されています。
OpenJDK をクローズドソースにバンドルすることは問題ではありません。GPL では、GPL ソフトウェアのバイナリをクローズド ソース ソフトウェアのバイナリと共に配布することが許可されています。
クラスパス例外の最初の行を読んでください。クラスパスの例外は、ライブラリ全体には適用されないようです。
Sun Microsystems, Inc. によって配布される特定のソース ファイルは、次の明確化および GPL の特別な例外の対象となりますが、Sun が特定のソース ファイルのヘッダーに「Sun は、この特定のファイルを「クラスパスの対象として指定する」という言葉を明示的に含めている場合に限ります。 「このコードに付随する LICENSE ファイルで Sun が提供する例外。」