「Java技術はオープンソースになるべきである」。この意見に異を唱える人はあまりいないだろう。では,次の意見はどうだろう。「Java技術の互換性維持よりも,オープンソース実装を自由に利用できることが優先されるべきである」。こう言われて即座にイエスかノーか,回答できるだろうか。この問いかけの中にJava技術とオープンソースをめぐる問題点が集約されているといっていい。この記事では,最近の動向も含めて,Java技術とオープンソースとの関係を見ていく。

 Javaとオープンソースをめぐっては,過去に様々な経緯があった(関連記事を記事末尾にまとめた)。つい最近では,2月25日にIBMのエマージングテクノロジー担当副社長Rod Smith氏がSun Microsystems社のRob Gingell副社長に「JavaをオープンソースにするならIBMは協力する」との公開書簡を出し,これをめぐって米国メディアが様々な記事を書き立てている(関連記事)。

 4月2日のSunとMicrosoftの和解という衝撃的な事件(関連記事)の後には,「Javaのオープンソース化の可能性はどうなるのか」に言及した記事も出ている(記事の例)。

 SunとMicrosoftの和解がJava技術のオープンソース化を加速するか,減速させるのか,二つの意見がある。筆者は,どちらかといえば「加速する」,との意見だ。SunがJava技術を手放さない理由の一つがMicrosoftの存在だったからだ。そして,Java技術が互換性維持にこだわっているのもMicrosoftがいたからだ。Sunとオープンソース・コミュニティの間との摩擦の原因を作ったのはMicrosoftだといっていい。それなら,Microsoftと和解した今こそ,SunがJavaをオープンソースにする良いチャンスではないか?

Sunとオープンソース・コミュニティの摩擦の背後にあるもの

 Java技術のオープンソース化は,昨日や今日に出てきた話題ではない。1998年のSCSL(Sun Community Source License)の発表とJCP(Java Community Process)の設立以来続いている(関連記事)。その過程でSunはJava技術のコントロールを徐々に手放してきた。だが,オープンソース・コミュニティが期待するほどには手放さなかった。Sunとオープンソース・コミュニティとの間には,常に摩擦があったのはそのためだ。

 SunはJava技術仕様の知的所有権を所持し,Java技術の使用策定団体JCPの特権的なメンバーである。だが,Java技術の仕様を策定し,開発しているのは,産業界のプレーヤー各社が集まったJCPである。この事情が,Javaとオープンソースとの関係をややこしくしている。批判にさらされるのは常にSunだが,Sunは常に「それはJCPの問題だ」と回答する。話は噛み合わないままだ。

 SCSLはJava技術のソースコード開示ライセンスで,発表当時には「Javaをオープンソースにする」という表現を使っていた。ただし,オープンソース・コミュニティからはオープンソース・ライセンスとしては認められなかった。互換性の検証を義務付け,利用料金の徴収を前提とするなど,オープンソースの理念である「自由な利用」からはほど遠い内容だったからだ。

 特に,互換性の検証を義務付けた点は,Java技術のオープンソース実装を作っている団体にとっては大問題だった。2002年にはApache Software FoundationとSunが合意に達し,非営利団体に関してはオープンソース実装の互換性検証に関する費用をSunが負担することにした。これは前進ではあった。ただし互換性テストを義務付けるという制度自体への不満はまだ残っている。

互換性維持に神経質だった背後には「Microsoftの影」があった

 Java技術のオープンソース実装にも互換性テストを義務付けたことは,Sunとオープンソース・プロジェクトとの間のトラブルの原因となりがちだった。Linuxでも,Apacheでも,別に互換性の問題は出てないではないか,なぜJava技術は互換性テストに縛られているんだ,というわけである。

 この問題の互換性テストを義務付けた大きな理由は,「Microsoftの影」である。JCPの大きな狙いは,産業界が納得するやり方でJava技術を発展させ,しかも「分派」の乱立を防ぐことにある。

 その背景には,Java技術の登場後のある時期に,Microsoftが実際にJavaの「分派」の普及を図っていたという経緯がある。Microsoftは1995年にJava技術をライセンスすると同時に,同社のCOM技術との統合を図った。Internet Explorer3.0以降や,Windows98以降に搭載されたMicrosoftのJava仮想マシンは,SunのJava技術との100%の互換性がなかった。このため,SunはMicrosoftを1997年にライセンス契約違反として訴えた(関連記事)。この訴訟をきっかけとして両社は争い続け,ようやく今月の4月2日に和解した。それまでの間,SunはMicrosoftという「仮想敵」を想定して戦略を立てていたといってよい。

 実際,2000年のJavaOneでの講演で,Scott McNealy氏は「Sunは,Java技術の知的所有権を保有しているが,それは知的所有権まで公開してしまうとMicrosoftのような企業に「盗まれる」おそれがあるからだ」という意味の発言をしている。

 さて,ここで冒頭の問いかけに戻りたい。MicrosoftとSunが和解した今,Microsoftが敵対的な行動(非互換のJava技術を作って広める)をしないのなら,もはや互換性維持に神経質にならなくてもよいはずだ。Microsoftと和解した今こそ,SunはJava技術の縛りを解き放つチャンスではないか?

現実解はApache Jakartaプロジェクトか

 現実には,Microsoftとの問題が完全に片づいたとしても,SunがJava技術での地位を急に手放すことは考えにくい。Java技術はSunの経営資源でもあるからだ。新たに社長兼COOに就任したJonathan Schwartz氏は,天才肌の経営者である。Java開発部門の売却といったアナリストが考えがちな平凡な戦略を取るとは考えにくい。むしろ,これからJava技術の成果を刈り取る戦略を打ち出すと考える方が自然だし,現にそうしつつある。

 ではSunの事情のためにJavaのオープンソース化が無理なのかといえば,そうではない。実はすでに材料がある。

 多くのオープンソース・プロジェクトは,優れた実装を作って普及させることで,結果的には「分派の乱立」を防いできたといえる。もしJ2EEアプリケーション・サーバーの良い実装がオープンソースになり,デファクト・スタンダードになったなら,問題はほとんど解決したのも同然だ。

 ヒントとなるのはTomcatの存在である。Tomcatは,Sunが提供したソースコードを元に,Apache Jakartaプロジェクトが開発したServlet実装である(関連記事)。JCPの手続きに従って仕様策定や互換性テストが行われている。そしてTomcatはデファクト・スタンダードである。

 こう考えると要注目なのはApache Jakartaプロジェクトが構築中のJ2EE完全準拠の「Geronimo」である(関連記事)。Tomcatのような品質でJ2EEアプリケーション実装が登場してきたなら,事実上のJ2EEのオープンソース化が達成できたといえる。

 Geronimoの登場までにはあと数年かかる。その間は,J2EEのオープンソース化を求める声は高まっていく。あるいは,Sunの立場を変更するような「制度改革」もあるかもしれない。事実上のオープンソース化が先か,制度改革が先かは分からないが,Java技術はオープンソース化の方向にあるのだ。

(星 暁雄=日経BP Javaプロジェクト)

Javaとオープンソース――関連記事一覧

Javaはどこまでオープンになったのか――新ライセンス・モデルを探る
1998年にSunが発表したJava技術のソースコード開示ライセンスSCSLについて分析した記事。完全なオープンソース・ライセンスとは異なる。
Javaは誰のもの? JavaOne2000で見えてきた新展開
2000年のJavaOneカンファレンスから,JCP2.0を推進するSunの思惑について分析。
Javaがオープン化に向け前進
2002年のJavaOneで,Apache Software FoundationとSunが合意した件を報道。日経コンピュータ2002年4月22日号から。
変曲点にきたJavaOne2002――キーワードはWebサービスと「end-to-end」,JCPとオープンソース
2002年のJavaOneカンファレンス報告。Javaの知的所有権に関するSunの見解を分析している。
Javaの解放: Jason Hunter氏へのインタビュー
2002年,SunとApache Software FoundationはJavaオープンソース実装の開発を推進するうえでの合意をした。その背景を語っている。
Javaオープンソース化への圧力が強まる--3通の「公開書簡」から
2004年1月から2月にかけて,「公開書簡」が米国メディアを賑わした。その背景を分析。