先日のブログ記事でHenn Idan氏が，Oracle Javaをコンテナで使用することはOracleのライセンス契約に違反しているのではないか，という問題を提起した。この記事は，発端となったAlpine Linux用のJavaの再コンパイルバージョンを推奨するツイートに対して，Oracleライセンスに対する明確な違反ではないか，とBen Evans氏が指摘したことを受けて提起されたものだ。
OpenJDKはGPLライセンス下で公開されているが，java.comでダウンロード提供される OracleJDKのコンパイル済バイナリには，これとは違うバイナリライセンスが適用されている。コードの著作権はOracleが所持しているため，Oracleには，GPL管理外のバージョンをリリースする権限があるのだ。また，Oracleの提供するJREにも，AppletプラグインやGUIをプラットフォームに依存しない方法でローンチする手段であるJava WebStartなど，独自のテクノロジが含まれている。さらに，開発目的では自由に使用可能だが，業務的な利用には別途ライセンスが必要なFlight RecorderやMission Controlなどの機能も同梱されている。
Java SE Oracleバイナリコードライセンス契約書では，業務使用ライセンスを次のように定めている(JDK, JREに共通)。
2. 使用許諾。 本契約の定める条件(補足ライセンス条項のJavaテクノロジ制限事項を含むが，それに限定されない)の下で，Oracleは，目的をプログラム実行に限定した，完全かつ改変されない本ソフトウェアを内部で複製ないし利用する，非独占的かつ譲渡不能な限定的ライセンスを無償で付与します。
ライセンスが非譲渡であるため，ソフトウェアの配布や，配布を受けた者のソフトウェア利用は認められない。
ソフトウェアの再配布に関しては，限定付きでその権利を付与する，次のような追加の補足ライセンス項目もある。
C. ソフトウェアの再配布許諾。本契約の定める条件，およびREADMEファイルに明記された制限と例外(本補足条項の再配布に関するJavaテクノロジ制限事項を含むが，それに限定されない)の下で，Oracleは，以下の項目を条件として，完全かつ改変されていない本ソフトウェアを複製ないし再配布する，非独占的かつ譲渡不能な限定的ライセンスを無償で付与します。(i) 本ソフトウェアを完全かつ改変されない状態で，プログラムのバンドルの一部として，プログラムの実行のみを目的に配布すること，(ii) プログラムが本ソフトウェアに重要かつ中心的な機能を加えていること，(iii) 本ソフトウェアのコンポーネントの置き換えを目的として，追加ソフトウェアの配布を行なわないこと，(iv) 本ソフトウェアに含まれる，いかなる所有権表示や通知も削除ないし変更しないこと，(v) (a) 本契約の完全かつ改変されていない複製である，あるいは(b) 本契約に含まれる条項に一致する，Oracleの権利を保護し，セクションHに記述された通達を含むライセンス契約の下においてのみ，本ソフトウェアの配布を行なうこと，(vi) すべてのプログラムおよび/またはソフトウェアの利用あるいは再配布に起因する，第三者からの請求，訴訟，法的措置に関連して発生する，あらゆる損害，コスト，賠償，和解金および/または費用(弁護士費用を含む)について，Oracleとそのライセンサの保護と賠償を行なうことに同意すること。本セクションCで規定されるライセンスは，セクションGに記載されているソフトウェアには適用されない。
法的責任や賠償の話は別としても(気になる向きもあるかも知れないが)，ライセンスそれ自体としては，Javaテクノロジの使用をプログラム実行という目的でのみ認めているのである(さらにそのプログラムは，単純なJavaランチャのようなものであってはならない)。従って，Javaランタイムを製品に同梱して配布することは認められるはずであっても，Dcokerコンテナにおいて，JavaランタイムがJavaアプリケーションとは別のコンテナイメージの中にあるような場合は，この条件を満たしていない可能性があるのだ。
(セクションGには，Oracle Premier Supportが提供するセキュリティパッチに関する制約が定義されているが，参考程度に述べられているだけであって，標準的なJavaの再配布自体の正当性に影響を与えるものではない。さらにセクションEでは，出版社が印刷された書籍や定期刊行物とともに，電子メディア上にJDKを含む権利が定義されている – 書籍にCDが添付されていた頃のことを覚えているだろうか？そもそも紙でできた書籍や，CDといったものが記憶にあるだろうか？)
その一方で，再配布可能ファイルを認める，次のような追加の補足事項もある。
D. 再配布可能ファイルの配布許可。本契約の定める条件およびREADMEファイルに明記された制限および例外(本補足条項の再配布に関するJavaテクノロジ制限事項を含むが，それに限定されない)の下でOracleは，以下を条件として，READMEファイルで再頒布可能と明確に指定されたファイル(“再配布可能ファイル”)を複製ないし再配布する，非独占的かつ譲渡不能な限定的ライセンスを無償で付与します。(i)完全かつ改変されていない再配布可能ファイルを，プログラムの一部としてバンドルしてのみ配布すること，(ii) プログラムが再配布可能ファイルに対して重大かつ重要な機能を加えること，(iii) 再配布可能ファイルのコンポーネントの置き換えを目的として，追加ソフトウェアの配布を行なわないこと，(iv) 本ソフトウェアに含まれるいかなる所有権表示や通知を削除または変更しないこと，(v) (a) 本契約の完全かつ改変されていない複製である，あるいは(b) 本契約に含まれる条項に一致するOracleの権利を保護し，セクションHに記述されている通達を含むライセンス契約の下でのみ，本ソフトウェアの配布を行なうこと，すべてのプログラムおよび/またはソフトウェアの利用あるいは再配布に起因する第三者からの請求，訴訟，法的措置に関して発生する，あらゆる損害，コスト，賠償，和解金および/または費用(弁護士費用を含む)について，Oracleとそのライセンサの保護と賠償を行なうことに同意すること。本セクションDで規定されるライセンスは，セクションGに記載されているソフトウェアには適用されない。
OracleのREADMEファイルにはOracleのWebサイトの参照が含まれていて，さらに別のREADMEファイルがリンクされるようになっている。(これらのファイルがJDKあるいはJREの一部として配布されていない点は，READMEファイルの内容に時系列的なトレーサビリティが不在であるという点で，何らかの問題となる可能性がある。)現行バージョンであるJDK 8には，リリースバージョンの再配布に関するセクションがある(ベータ版およびプレリリース版は再配布不可)。
Java SEプラットフォーム製品のOracleバイナリコードライセンス契約書の条項および条件を遵守する限りにおいて，ソフトウェア(および再配布可能として下記に同定されたソフトウェアの一部)の複製と再配布を行なうことができます。
ここで用語として使われている”ベンダ(vendors)”とは，JRE(Java Runtime Environment)を自身のプログラムと合わせて配布するライセンスを持ったライセンシ，開発者，独立系ソフトウェアベンダ(ISV)を指します。
ベンダは，Java SEプラットフォーム製品のOracleバイナリコードライセンス契約に従わなくてはなりません。
JDKとJREいずれの配布においても，それぞれ必須およびオプションファイルがある。
必須ファイルとオプションファイル
JRE(Java Runtime Environment)を構成するファイルは２つのカテゴリ，すなわち必須とオプショナルに分類されます。オプションファイルは，ベンダの判断でJREの再配布から除外することも可能です。
...
JREを再配布する場合の必須ファイルとオプションファイルの詳細については，JRE Readmeを参照してください。
JRE Readmeでは，Oracleのバイナリコード契約書の下で，ソフトウェアのバージョン(およびその一部)を複製，配布する権利が提供されている。例えばJavaFXは，jre/extのコンテンツとして除外することが可能だ。オプションファイル以外はすべて必須ファイルであり，JREと合わせて配布する必要がある。また，JDKにはJREを同梱して配布しなければならない。
これらのファイルが対象としているのは，バージョン８以前のJDKおよびJREである。バージョン９以降のJDKとJREでは，ファイルの再編成が実施された結果として，除外可能なファイルと必須ファイルに関する契約の内容が以前とは異なっている。いくつかのファイル，例えばCAcert証明書ファイルなどについては，証明の変更に対して最新版を維持するための更新が認められるようになった。
また，Javaに備えられた40ビットのキー強度という，限定的な形式のセキュリティに対しては，役に立たない代物だという指摘が以前からあり，実際にもデグレード攻撃の的になってきた(BEASTやPOODLEなど)が，Unlimited Strength Cryptographyアップグレードを使ったアップグレードが可能になった。ただしこれには再配布が認められていないため，ユーザに直接ダウンロードするように求める必要がある。
暗号化強度に制限のないことを示す，これら無制限強度バージョンのファイルについては，適格国に居住することを条件に，JDKのWebサイトから入手可能です。適格国にお住まいの方々は，この無制限強度バージョンをダウンロードして，暗号強度jarファイルを無制限強度ファイルに置き換えることができます。
最新のアプリケーションの大部分は，初期状態で適切な暗号化レベルを備えることが求められると考えられるため，他の実行環境が再配布可能であったとしても，セキュリティの欠如は重大な問題となる可能性がある。これはOracleJDKに限らず，OpenJDKを使用する場合も問題になるかも知れない。
sudo apt-get install openjdk-8-jre あるいは su -c "yum install java-1.8.0-openjdk" を実行することで，不特定のリモートリポジトリから入手可能なOpenJDKのバージョンがある。Debianの(おそらくUbuntuも)最新バージョンはopenjdk-7で，openjdk-8はテスト用，openjdk-9は試験段階として公開されている。これらはOracleが作成したものではないので，サポートを受けることはできない。さらに，パッチの適用対象となるのか，あるいはどのタグからビルドされたものであるのかが，必ずしも明確ではない。
Henn Idan氏はこれを，怪しげな食べ物(Mystery Meat) – 出所や起源，経緯が分からない – だと説明した。それに対してAzul Systems創設者のGil Tene氏は，JavaディストリビューションはJava TCK(Testing Compatibility Kit)でテストされているため，使用しても安全なはずだ，とフォローしている。氏はAzulのOpen JDKビルドに関して，どのバージョンからビルドされたものかを確認するための証明と，TCKをパスしたことの宣誓が添付されている点を強調する。(AzulはJava TCKライセンシの１社である。)
Henn Idan氏がブログ記事で指摘した問題のひとつは，OpenJDKの安定版リリースが未公開であるがために，DockerのopenjdkイメージのビルドにDebianの不安定なバージョンが使用されている，という事実だ。従って，このベースリポジトリから入手したDockerイメージを基盤とするのは，DebianによるJava適合性など既存テストが実施されたという確証のないリリースを使用することになる。DebianとしてはJava 8を提供していないので，現段階では認証について関心を持っていないのかも知れない。しかしながら，Dockerの提供するdocker/openjdkリポジトリは，正規入手可能なディストリビューションのひとつであるという解釈もできる。かつてJDK部品の再配布に関して提起された問題は別としても，正規のDockerイメージがDebianの提供する不安定なバージョンに基づいたものであるという事実は，それ自体が懸念すべきことだ。
最後に残るのは，OracleのJDKを自動的にダウンロードするようなDockderファイルを記述，ないし利用することの合法性に関する疑問だ。OracleからのJavaのダウンロードに“同意する”とクリックしたようにクッキーの値を設定すれば，ターゲットシステムへのJDK(あるいはJRE)の自動ダウンロードとインストールが可能になる。Dockerファイルそれ自体がOracleのライセンス権に反している訳ではないが，ダウンロードしたイメージには再配布の権利はない。Dockerクライアントはこのコマンドの実行結果を利用してイメージのスナップショット構築を行なうが，アプリケーションのファイルが確定する前に，別の場所(例えばDocker Hub)へのダウンロードが可能になるため，最終的なイメージそれ自体が権利侵害になる可能性がある。これらの権利は必ずしも譲渡可能ではないため，こうして作成されたOracleイメージの利用者にも，Oracleの著作権を侵害する可能性があるのだ。
Javaユーザが潜在的問題を回避するためには，Ubuntu, Debian, Centos用のJava 6, 7, 8ベースの認証済みDockerイメージを公開しているZuluのように，TCK認定されたJavaランタイムを代わりに使用するという方法もある。あるいはZuluリポジトリを，パッケージリポジトリのソースリストに加えてもよいだろう。それらとは別に(Azulではサポートされていないが)，小型のAlpine Linux用のJREとJDKも提供されている。ここで注意が必要なのは，Zuluの利用条項に次のような追加項目があることだ。
米商務省，OFAC，その他の政府機関の政府機関の定める輸出管理法令ないし規制に反した製品の使用(あるいは第三者への許可)，あるいは本製品およびその一部の転送，送信，輸出，あるいは再輸出が許可されないことにも同意するものとします。
Docker Hubをベースとしたビルドに対しては，この制約を遵守させる手段が存在しないため，その方法で配布されたイメージは使用できない可能性がある。これらの条項が，OpenJDKのGPLによる次のような条項と矛盾するのかどうかも定かではないのだ。
ここで認められた権利を受けたものによる権利の行使に対して，制約を加えることはできません。
Javaに関するこれらの議論に対して，著作権保有者からの公式な意思表明は確認されていない。しかしながら，コンテナの普及，ソフトウェアディストリビューションのモジュール化，コンテナ層のディストリビューションの独立化に伴って，これらイメージの公開リポジトリへの提供者およびユーザの双方が，法的措置の対象となる可能性のあることは間違いない。これを回避するには，中立的立場からの法的助言を求めることが必要になる。
InfoQのこの記事は情報の要約であり，法的助言とみなされるべきものではない。今後の状況の変化や再評価によって，本記事の内容も修正ないし更新される可能性がある。
この記事を評価
- 編集者評
- 編集長対応