レベル: 中級 Robert McMillan (bob@linux-mag.com), Editor-at-large, Linux Magazine
2002年 4月 01日 何週間か前のJavaOneに関する情報を知っている方であれば、おそらく、オープン・ソース・ソフトウェアのJava Community Processへの参加に関する困難を、SunおよびApache Software Foundationがどのように解決したか耳にされたことでしょう。しかし、大半のJava開発者は、その詳細な内容をまだあまりご存じないでしょう。その内容を明らかにし、そのような変更がオープン・ソースの開発者とJavaコミュニティーにとってどのような意味を持つのかを理解するために、developerWorks は、Java Community ProcessのApacheの代表者であるJason Hunter氏にインタビューを行い、現在の状況について説明してもらいました。
Jason Hunter氏
JDOM Java XMLモデリング・ライブラリーの開発者としてよく知られているJason Hunter氏は、オープン・ソースのプロジェクトがより容易にJava標準化プロセスに参加できるよう、1年以上にわたって献身的な活動を行ってきました。
developerWorks: なぜこのような活動に携わるようになったのですか。
Hunter: 私はJCP (Java Community Process) に対するApacheの代表者です。Apacheの抱えていた問題の大半は、Apacheが、JSR (Java Specification Request) のオープン・ソースの実装を提供したり、オープン・ソースのRI (リファレンス実装) やTCK (Test Compatibility Kit) のホストをサポートしたり、オープン・ソースのRIやTCKを持つJSRのリード役を望むことによって、JCPに参加しようとしたために起きたものです。JCPでの作業を試みるうちに、法律問題、機密性の問題、そして、テストの有効性の問題が存在することに私たちは気付きました。
これらの問題は、私自身のプロジェクトであるJDOMにも影響を与えました。多くの人がJDOMをコアJDKまたはJ2EEで動かすことに興味を持ち、JSRプロセスにJDOMを通すことが、それを可能にする最もよい方法であったため、私は、JDOMをJSR-102として提出しました。これにより、JCPがオープン・ソースのRIやTCKを許可するかどうかという点に関して、多くの法律上の問題が発生しました。Sunの法務部門からは、それは違法であるというような回答が来ましたが、その回答は、それを担当した弁護士によって、また、それらの弁護士がどのような態度でそれらの文書に目を通したかによって、大きく左右されているようでした。
dW: それはいつごろのことですか。
Hunter: 1年以上前のことです。ソースに依存しないオープンな実装を行うことには多少なりとも障害がある、ということは私も知っていましたし、よく知られていることでした。しかし、少なくともスペック・リードは、「これが私のリファレンス実装です。これはオープン・ソースです。これを利用して自由に構築を行ってください」と言うこともできると思っていました。それがApacheのやり方です。つまり、「これがApacheのWebサーバーです。きわめて優れた機能を備えていますが、どうぞこの上にさまざまな機能やサポートを付加して自由に商用製品を構築してください」というのがApacheのやり方です。
dW: 当時実装を試みていたJSRのスペック・リードだったのですね。
Hunter: そうです。スペック・リードとして他の人たちと作業ができ、このライセンスのもとで、自分の望むことはすべて行うことができたこと、しかし、その後になって「それはできない」と言われたこと、これらは驚くべきことでした。その多くは、法解釈に関することが必ずしもイエスかノーで答えられるものではない、というのが理由でした。その文書は、非常に長く複雑なものであり、何年もかけて追加された法律表現のつぎはぎのようなものでした。その文書を理解するのはとても困難だったため、オープン・ソースのRIとTCKを許可するというSunの法解釈が公開されたとき、私たちはたいへん喜びました (参考文献を参照)。法律問題は、社内に弁護士を持たないオープン・ソースの開発者にとって常に悩みの種です。法律問題に関して、彼らはどのような結果が起きるかを推測しなければなりません。それはまるで量子物理学のようなものです。
dW: オープン・ソースJSRの実装の障害となった問題は何ですか。
Hunter: 障害となった問題は主に3つありました。1つは、Sunが使用していたJSRの仕様ライセンスの問題です。それは基本的に、「これは著作権で保護されている。実装にあたっては、それをベースとしたものを使用することになるため、それに関するライセンス条件のいくつかについてはこちらの指示に従うこと」という内容でした。Sunのライセンス条件は、それぞれの著作権ライセンスによって互換性を保証しなければならないというものであり、それができないオープン・ソースのライセンスにとっては妨げとなるものでした。これは、SunのこれからのJSR、および、これまでの主なJSRに関して強調されているところです。
2つ目の問題は、「共用コード」と呼ばれるものの存在であり、この問題は、現在でも多少残っています。共用コードの要件は、「実装でこのコードそのものを使用しない限り、このJSRを実装することはできない」というものです。SwingとJavaベリファイヤーの2つが、その例です。共用コードはテストの難しいものに使用されていたため、その互換性を保証する唯一の方法は、同じコード・ベースを使用するということでした。その点は納得のいくことですが、しかし、「準独立」の実装をリリースするためのライセンスは、共用コードのライセンスに従うものとされていました。そのため、共用コードを持つJSRを実装する場合、それがオープン・ソースの実装に対する妨げとなりました。現在進行中のJSPA (Java Specification Participation Agreement) のドラフトにおいては、共用コードの著作権ライセンスは、Apache型のオープン・ソースのライセンスを禁じてはいません。
そして3つ目の問題は、Test Compatibility Kit (TCK) の使用が必要であり、そのためにSunとのライセンス交渉が必要であったということです。Sunは、オープン・ソースの実装の禁止を、TCKを使用するための条件としてあげました。
dW: TCKは、JSRのリードによるものですか。それともSunによるものですか。
Hunter: それはそれらのリードによるもので、私たちが検討しているもののすべては、Sunがリード役となってきました。いや、おそらくすべてではないにせよ、重要なJSRの大半はこれまでのところSunのリードによるものです。Sunのライセンス条件がきわめて重要なのは、そのような理由のためです。
dW: そして、その点がまだ明確になっていないということですね。Sunとの合意ができたとしても、他のJSRリードが、オープン・ソースのプロジェクトのテストをサポートするかどうかははっきりしていないようですね。
Hunter: 私は、サポートされるようになると強く信じています。これらの問題に関するやりとりでは、私がかかわったほぼすべての人々が、それを支持していました。ただし、Sunとの問題を解決しなければならないことは確かですが。
「互換性」対「オープン性」
次は、「互換性」対「オープン性」に関する話題に移ります。
dW: Sunにとっての懸念事項は、何だったのでしょうか。
Hunter: たとえば、オープン・ソースのTCKを持つということは、誰でもTCKを変更できるということを意味し、それはもはやTCKではなくなってしまうというような、ある程度の誤解があったのだと思います。そのため、そのような誤解を解くことが必要でした。Sunと協力して、互換性を損なうことなくオープン・ソースの実装が可能であることを示す必要がありました。計画的な変更を行うことによって、互換性を確保することができるはずです。TCKのより広い可用性と、堅固なJSR実装の広い可用性は、Javaのポータビリティーに貢献するでしょう。
コード・ベースとバイナリーには違いがあります。あなたの実装が対象とするバイナリーであるTCKバイナリー (「黄金の」TCK) の公開は、スペック・リードの役割です。そのようなTCKのコード・ベースはオープン・ソースですが、たとえば、TCKからテストを削除するようなことは誰にもできません。
私はこれまで、オープン・ソースに関するクラスをたくさん受け持ってきましたが、そのクラスで私が「Apache Webサーバーを変更できるのは誰ですか」という質問をすると、受講生は皆、「Apacheの担当者だけ」と答えます。そこで私は、「でも、オープン・ソースなのでしょう。誰でも変更できるはずでは？」と聞き返すと、そこでようやく理解できたようで、ほとんどの受講生が「なるほど、誰でも変更できます」と答えます。そこで私は、今度はこう尋ねます。「では、誰でもWebサーバーを変更できるとしたら、どのようにしてセキュリティーを確保するのですか」。さあ、よく考えてください。答えは、「Apache Software Foundation」です。これは、Apacheのコード・ツリーを維持し、Apache Webサーバーのビルドを公開するものです。そこでは、コード・ツリーへのアクセスは (投票による実力主義によって) 制限され、すべての変更に対してピア・レビューが行われます。ソースをダウンロードし、それぞれのマシンでそれを変更することができますが、それ以上Apacheの作成を行うことはできず、また、ライセンスの制限によって、そのサーバーをApacheと呼ぶこともできません。TCKに関してもこれと同じです。TCKを維持する権限を持つ信頼できるグループを設けることができ、また、公式ビルドを作成する権限はスペック・リードが持ちます。TCKのコードの改良はそのバグを見つけることから始まりますが、公式のコード・ツリーのルールに適応しなければ、それは公式のツリーとはならず、また、スペック・リードがビルドでそれらを承認しない限り公式のビルドとはなりません。
Javaプラットフォームのオープン化
インタビューの締めくくりに、Javaプラットフォームのオープン化がJavaコミュニティーにとってどのような意味を持つのかについて、Jason氏の意見を聞きました。
dW: このような変更全体に関して興味深いことの1つは、それがより広いJavaコミュニティーに対して与える影響です。この変更によって、他のプロジェクトや企業も、オープン・ソース・コードの公開を行うようになるでしょうか。
Hunter: 確かに今までもオープン・ソースに対する要望はありましたが、その実現には至りませんでした。それは、企業が法律上のリスクを嫌うためです。スペックの著作権がそのスペックの実装のライセンスにも影響するという考えには、疑問の余地があります。それに関しては、法廷での審理が行われたこともなく、私が相談した弁護士もすべてそのような経験はないと言っていました。Sunの弁護士のみがそのような考えを支持するか、または、少なくともそのような考えを公言しているのです。しかし、企業の立場からすれば、やはりリスクを冒すようなことはしないでしょう。オープン・ソースの団体は比較的そのような訴訟に慣れていますが、企業の場合はそうではありません。オープン・ソースの実装をサポートする企業が増えるのはすばらしいことです。
dW: これらの変更による影響が現実に表われると、Javaプラットフォームは十分にオープンなものとなるでしょうか。
Hunter: 理論的には、将来的にはコアJDKの場合も含みJSRのオープン・ソースの実装が実現すれば、幾つかの団体がそれに対して取り組むことになるでしょう。オープン・ソースの実装はマインドシェアやマーケットシェアを多く集めるため、団体がそれを行うことによって、Sunもそれに対して関心を示し、第三者の実装がオープンになるよりも、むしろSunのリファレンス実装がオープンになるでしょう。APIの変更を行う際にそれに関する意見を聞く場所、というイメージをオープン・ソースJavaに対して持っている人もいます。そして、それがOKであれば変更が行われます。それに対する、あまり大きな支持はないと思いますが、しかし、私としてはそれでいいと思います。そこにレビュー・プロセスがあり、また、それが実装の仕様のように行われるということに関しては、私は別にそれでいいと思います。人々にとって非常に重要なバグがたくさんあるのですから、Javaのコアがある程度オープン・ソース化され、信頼できる人々によるパフォーマンスの改善やバグの特定が可能となるのであれば、それはよいことでしょう。しかし、修正を行うコードへのアクセスが人々には与えられていません。
SCSL (Sun Community Source License) に関しては、さほど大きな成果はありませんでした。大きなタールボールのダウンロードが必要であり、変更の読み込み/追跡を行うための実際のCVSを持つこととはかなり異なります。それは、その変更を行うまでに、他の誰かが何らかの変更をすでに行っているためです。
関心は常に、互換性を損なうことではなく、互換性の確保に向けられていました。3つの問題が原因となって、オープン・ソースの開発者は、そのスペック・ライセンスについて、また、互換性の問題となる可能性のある共用コードに関して考慮することなく、また、Sunが許可していなかったためにTCKを利用することもできませんでした。そして、それにより互換性が損なわれる結果となりました。これからはこれらを利用できるようになり、互換性の確保も可能となるでしょう。
このように、以前には懸念もありましたが、このようなオープン・ソースへの関心は、互換性の面にも有益であることが明らかです。実装がオープン・ソースであるというだけで、互換性を損なうことが堂々と許されるということではありません。互換性の確保に著作権ライセンスが役立つという考えをSunは依然として持っており、オープン・ソースであるかどうかにかかわらず、互換性から逸脱するようなインプリメンターに対しては監視の目を光らせています。私たちはそれらの問題が法廷で審理され、法廷の支持を得ることができるかどうかを見ることができるでしょう。そして、法廷の支持が得られる可能性がまったくないとも言い切れないでしょう。
dW: そこでSunは、それらがApacheに影響するという理由で、十数件のJSRに関するライセンス条件の変更を約束したのですね。それ以外に何かありますか。
Hunter: 私たちはSunと協力して、Apacheにとって最も重要なものを簡単なリストとしてまとめました。Sunは実際に、他の団体にも重要であると思われるJSRの追加も行いました。彼らが「少なくともこれらのJSRは、法律上の理由で今すぐ変更が必要である」と言うように私たちは努めました。
dW: Sunはなぜ、自分たちがリードであるすべてのJSRを変更しないのでしょうか。
Hunter: 彼らは、今後のJSRでそれを行うとしています。以前のJSRに関しては、キャパシティーに限界があったのではないかと思います。彼らは、過去のJSRに関しては最も目立つ部分を変更し、何か変更が必要な箇所に関しては、次回の改訂でそれを行うという考えでしょう。
Sunが既に与えられたリストの枠を越えた行動にでた場合、それは、それを示すきわめて明白な良い兆候と見ることができます。これからも彼らが本当にすべてのJSRに継続してかかわっていくとするなら、ライセンス条件があまり明確なものにならない可能性があります。それらが明確になるとすれば、それもまたよい兆候です。そして、もし明確にならないならば、それは私たちの懸念材料となるでしょう。Apacheが求めている最も重要なアクションの1つは、J2EE 1.4のライセンス交付です。それによって、独立した互換性のあるオープン・ソースの実装が可能となります。「J2EEの中のJSRの1つがまだ変更されていないので、J2EE 1.4は実装できません」というようなやり方であれば、これは悪い兆候といえるでしょう。
dW: では、これがJava Community Processにかかわる最後の問題ですか。
Hunter: これは、私たちとのかかわりに関する最後の問題でしょう。完全に合意に至れば、提案の評価、コミュニティー・レビュー・ドラフトの評価、テクノロジーの監視など、当初行いたかったことを行うことができます。JSRの提案を助けリードをしてください。またJSRの実装をサポートしてください。テクノロジーの開発と標準の実装、それがApacheの行うべきことです。弁護士を介して法律上の問題として争うことは、できる限り避けたいのです。皆もおそらくそう思うでしょう。
参考文献
著者について
記事の評価
| 
