BT

OpenJDKはAndroid開発にどのように影響するか

作者: Abel Avram , 翻訳者 吉田 英人 投稿日 2016年2月18日 |

原文(投稿日:2016/01/08)へのリンク

今回の記事では,GoogleがAndroidの将来バージョンでOpenJDKを採用することに対して,Webで見られる反応をいくつか取り上げて紹介する。

我々は昨年末,GoogleがAndroidのJavaライブラリを,従来のHarmony実装からOpenJDKにリプレースすることを決定したとお伝えした(詳細はこちら)。Googleのこの決定は,クリスマスシーズンに発表されたにも関わらず,Web上にさまざまな反響を引き起こした。ここではその中のいくつかを要約して紹介する。

GoogleがOpenJDKへのスイッチを決めたことは,このGitチケットを見る限り,コード上は少なくとも2015年2月までさかのぼることができる。この問題にメディアが注目する原因となった12月のコードコミットには,重要なライセンス変更が含まれていた。Android Nの新しいJavaライブラリが,それまでのApache License 2.0 (APL)からGNU GPL 2の下にライセンスされて,次のような著作権表記が加えられたのだ: “Copyright (c) 1997, 2011, Oracle and/or its affiliates. All rights reserved.”

Mozillaの前CTOであるAndreas Gal氏は,“Oracle Sinks Its Claws into Android(OracleがAndroidに爪を立てる)”という仰々しい題名の記事の中で,GoogleがHarmonyとApacheライセンスの使用を長く続けてきた理由について,次のように主張した。

APLのコードを使用し,変更しても,その内容を公開する義務はありません。 言い換えれば,独自の変更や改良を行なうことが可能なのです。LGPL下のGNU libcでは,これはできないことです。Googleがなぜこれを重要だと考えたのか,私には確信があります。Firefox OSのローンチ活動の一環として,Googleと仕事をした同じチップベンダやOEMに話を聞いて,その理由を知っているからです。シリコンベンダやOEMはソフトウェアレベルでの差別化を望みますから,Androidコードのスタック全体に手を加えようとします。特にシリコンベンダは,独自のシリコンを活かすためにライブラリコードを改変することも少なくありませんし,自分たちの行なった変更を公開したがらないのが普通です。それが彼らを守る堀であり,アドバンテージなのです。

Gal氏の記事へのコメントとして,OEM企業の従業員だというBob Ross氏が,APLとGPLの微妙な違いについて説明している。

libcoreには手を入れません。この場合のオープンソース化に伴う問題点は,少なくとも私の経験した限りでは,シークレットよりもオーバーヘッドの大きさに関するものです。

Software Freedom Conservancyの現代表で,FSF(Free Software Foundation)の理事会メンバでもあるBradley M. Kuhn氏は,GPLがAndroid開発に影響を与える可能性について,彼らとは違う意見を持っている。“Sun, Oracle, Android, Google and JDK Copyleft FUD”と題した先日の記事で氏は,OpenJDKがGNUプラスクラスパス例外(Classpath exception)という,“極めて弱い”ライセンスを採用している事実について注意を促している。 Kuhn氏がその設計と命名に関わったクラスパス例外は,すべてのプログラムの使用と再配布が自由になるというcopyleft保護に,Javaエコシステム全体が“感染”することを防止するためのものだ。従ってOpenJDKを使用することは,ライセンスの面ではHarmonyと大きく違わない,とKuhn氏は説明する。

それならば,OracleのGPL+Classpath例外ライセンスのJDKを使用する場合,ApacheライセンスのJavaユーザスペースとはどのように違ってくるのでしょう?大きな違いはありません!Androidの再配布はすでに,カーネル部分のcopyleft義務に強く拘束されています。WebKitがLGPLであることも忘れてはなりません。Andoirdに関してはすでに一定のcopyleft遵守義務が存在しているのです。従って再配布物がこれらを満たしているのであれば,使用するJDKコードに比較的弱い要件を追加することによる新たな作業は,それほど多くありません。

一方でGal氏は,これによって今後,OracleがAndroidに対して影響力を持つようになるのではないかと考えている。単にライセンスの問題ではなく,Javaのロードマップや商標,契約,特許という面からだ。

Oracleがソースコード以上のコントロール権を持っている以上,OpenJDKの自由度は刑務所と同じようなものです。塀の高さはどの程度かを投票したり,塀を作ることに協力することはできますが,塀の中に入った以上,そこから出られるかどうかを決めるのはOracleだけです。OpenJDKのロードマップの大部分はOracleが所有しています。互換性要件や商標,既存の契約,API著作権(Oracle対Google)などを通じて,OracleはOpenJDKの進む方向をほぼ完全にコントロールしているのです。

Gal氏の記事に寄せられたコメントの何件かは,OracleがOpenJDKに対して好意的でない動きをしたとしても,Googleがそれをフォークして自分たちが望む開発を行なうことは阻止できないと指摘している。

Gal氏はさらに,Androidの“前途多難”を予測する。

このような技術やコードに関する不安はすべて,Androidの戦術面に大きな影を投げ掛けることになります。文字通り数百万行のコードが変更されますし,Open JDKの実装は,これまでGoogleが使用していたHarmonyに対して,正確性あるいはパフォーマンス動向において微妙に違います。Googleが更新した日付処理に関する境界条件テストがこちらにありますが,Harmonyの動作がOracleのOpenJDKと異なっているため,テストを修正しなくてはなりませんでした。

アプリのエコシステムは,このように流動的な砂の上にあります。Androidのアプリストアには,Java標準クラスに依存するアプリが数百万あります。テストが修正されなくてはならないのと同様,OpenJDKへの移行による微妙な差異によって,動作に支障をきたすアプリも現れてくるでしょう。

この重大な変化が背景で起きているため,Android Nが予定通り登場するかどうかを予測することも非常に難しくなっています。飛行中にエンジンを交換しようというのですから,クラッシュしないことが最優先課題になるでしょう。スケジュールを守れるかどうかを考える余裕は,それほどないはずです。

Brendan Eich氏はGal氏の意見をツィートで支持している: “詳しいことはまだ分かりませんが,コード変更によってコストとリスクが増加するという@andreasgalの意見に同意します。”

Codename One共同創設者のShai Almog氏は,GoogleとAndroidの開発者の今後に課題のあることには同意しながらも,それらはGal氏やEich氏の指摘するほどの難題ではないとした上で,OpenJDKを使用することのメリットの方を指摘している。

ユーザに直接メリットのある変更はいくつかありますが,ソフトウェア開発の変更は大部分がそうではありません。すべての言語あるいはAPI機能が,すべての開発者の利益になる訳でもないのです。

コードベースが統一されることと,セキュリティ監査の対象となるコードベースが統一化されることは,ユーザにとってはプラスになるでしょう。それによって,数多くの標準JavaツールがAndroidでも使えるようになるかも知れません ....

確かにGoogleは苦労するでしょう。影響を受けるアプリも多少はあるかも知れませんが,どちらもマシュマロの時に比べれば小さなものですし,問題の多くを軽減するためのツールをGoogleは持っています(SDKのバージョンで分かるように)。

GoogleがOpenJDKを採用したのには,Oracleと係争中の訴訟が何か関係しているのではないか,という疑問もあるが,Kuhn氏は今回の決定の背景にある理由について,技術的なものだと考えている。

ある業界アナリスト(Javaの分野で10年以上の経験を持つ)は私に,今回の決定は主に技術的なものだと言いました。Androidユーザ向けのアプリケーション作成者は(間違いなく)新しいJava言語実装を望むでしょうし,適切にライセンスされたフリーソフトウェアが存在したからこそ,APIユーザが技術的に欲しているものを提供し,メンテナンスの負担を軽減するために,Googleはより優れたコードベースへと技術的にスイッチするのだというのです。これは説得力のある意見だと思います。その専門家が言うほどショッキングなものではなくても,おそらくは技術的な理由が主な動機でしょう。

オペレーティングシステムの将来のバージョンにOpenJDKを使用したAndroidについて,その影響をすべて評価するのは時期尚早だろう。Oracleの動向と,Googleとの訴訟の行方に左右されるからだ。APIインターフェースに著作権が適用されるかはまだ明らかでない。法律と裁判所がそれを明確にしなくてはならないのだ。JavaとCで記述されたAndroidコードの一部は,既存のライブラリを開始点としてコードを削除することで再構築されてきたが,インターフェースあるいはヘッダファイルはそのまま残っている。この方法に問題はないだろうか?それはまだ分からない。OpenJDKの採用によってGoogleは,OracleからAndroidを保護するためのライセンスの適用と特許権を所持することになり,いくつかの問題が軽減されることには間違いない。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション
サイト全般について
バグ
広告
記事
Marketing
InfoQ.com and all content copyright © 2006-2016 C4Media Inc. InfoQ.com and 株式会社豆蔵 InfoQ Japan hosted at Contegix, the best ISP we've ever worked with.
プライバシー
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.