　人気の高いオープンソースのオフィススイートの最新版となる「OpenOffice.org 2.0」（OO.o 2.0）は現在、ベータテストの終盤を迎えている。新バージョンでは、速度およびMicrosoft Officeとの互換性の両面で改善が施されているが、フリーソフトウェアファンの中には、SunのJava技術が用いられていることに異論を唱える人もいる（関連記事参照）。

　OO.o 2.0は、そのコンセプト文書「StarOffice/OpenOffice.org "Q" Product Concept」に基づいてデザインされた。このコンセプトの狙いは「Microsoft Officeとの相互運用性を低コストで実現すること」および「顧客にとって特に重要な部分のパフォーマンスを改善すること」であり、「最も顕著な改善点は、起動時間の短縮とドキュメントをオープン／保存するのにかかる時間の短縮である」と同文書は記している。

　Ziff Davis Internetが実施した非公式なテストから判断すると、OO.oの後期ベータ版はこれらの目的を達成しているようだ。

　しかしフリーソフトウェア陣営からは、オープンソースプロジェクトであるOO.oが、Sun Microsystemsのプロプライエタリなプログラミング言語であるJavaに依存しすぎているのは問題だという声も聞かれる。

　一部のOO.o支持者らによると、こういった批判は、熱狂的なフリーソフトウェア信奉者の誤解やMicrosoftの宣伝、あるいはOO.oに反対する勢力によるエセ草の根運動（“サクラ”を雇って運動が盛り上がっているように演出すること）による結果だとしているが、フリーソフトウェアコミュニティーにはOO.oに対する具体的な批判も幾つかあるようだ。

　この対立を明白に示す証拠として、FSF（Free Software Foundation）が、「非フリーのJavaプラットフォームを必要としないOpenOfficeバージョンのメンテナンスを担当するボランティアを募集中」であることが挙げられる。

　このプロジェクトを担当するボランティアは、FSFの創設者であるリチャード・M・ストールマン氏に連絡するよう求められている。

　フリーソフトウェア支持者らが特に批判しているのが、OO.o 2.0の一部機能がSun独自のJavaコードを使用している点だ。具体的には、「Base」（Microsoft Accessに似た新しいデータベース管理プログラム）および「Writer」（OO.oのワープロソフト）のドキュメントウィザードでJavaが使用されている。

　OO.oの従来バージョンでもJavaが使われていたが、利用範囲はずっと小さく、Javaベースのデータベース用のJDBC（Java Database Connect）ドライバのサポートといったマイナーな分野に限定されていた。

　しかし最新版のOO.oに含まれているJavaコードは、GCJ（GNU Compiler for Java Programming Language）などのオープンソースJavaコンパイラでうまくコンパイルすることができない。

　Red HatなどのLinuxベンダーやUbuntuなどのコミュニティー系Linuxディストリビューターは、SunのコンパイラプログラムではなくGCJを利用している。

マイルストーンに到達

　OO.oは基本的にC++で記述されている。OO.oのオープンソースAPI（Application Programming Interface）は、オープンソースライセンスであるLGPL（Lesser General Public License）およびSISSL（Sun Industry Standards Source License）の下でライセンスされている。OO.oのコード自体も、LGPLおよびSISSLの両ライセンス方式に基づいて提供されている。

　OO.oプロジェクトは最近、「マイルストーン」ビルドに到達した。このビルドは「OpenOffice.org Developer Snapshot Build 1.9.m100」と呼ばれる。

　これは、OO.oのリリースが間近であることを意味するが、そのような段階で、FSFはJavaの使用に反対する立場を、SunのJavaに依存しないバージョンを開発するボランティアの募集という形で具体化したわけである。

　またFSFは最近、Javaのフリーバージョンを開発するようフリーソフトウェアコミュニティーに呼びかけた。

　ストールマン氏は、「Java Trap」（Javaの罠）と題された論文の中で、こういったオープンソースプロジェクトでJavaを使うことに対する批判を展開している。

　「SunのJavaプラットフォーム上でJavaプログラムを開発すれば、無意識にSun独自の機能を利用しがちである。気づいたときには、もう何カ月もその機能を使っていて、プログラムを書き直すのに、さらに多くの月日がかかるという可能性もある。『最初からやり直すのは大変だ』ということになるわけだ。あなたのプログラムは“Javaの罠”に落ちたのである。そのプログラムはフリーソフトウェアの世界では使えないのだ」とストールマン氏は記している。

　その一方で、「オープンソース版のJavaを使用するよりも、RubyやPythonといったまったく異なる言語でこれらのコンポーネントを書き直せばよい」と提案する人もいる。

　さらに一歩進んで、OO.oをGCJに対応させるフィックスを作成したプログラマーもいる。

　Red Hatでワードプロセッシングを担当するプログラマーのカオラン・マクナマラ氏は、このようなフィックスを開発した。

　Sunの関係者は、「OO.o 2.0はGCJに問題なく対応する。Red Hatはバグレポートを提出するなど、この取り組みに多大な貢献をしてくれた」と話している。

　また、OO.oはJVM（Java Virtual Machine）なしでも動作するが、JVMがあればそれを利用するようになっており、SunのJVM 5.0を使用すると非常に高いパフォーマンスが得られることが分かっている。

　OO.oの品質保証プロジェクトの共同リーダーを務めるスコット・カー氏は、「OO.oはJVMなしできちんと動作するが、JVMが存在する場合には、そのJVMでどんな機能がサポートされているか確認するために、そして各種の機能を実行するためにチェックを行わなければならない。このチェックはJVMが存在する場合にのみ実行される」と指摘する。

　RedMonkのソフトウェアアナリスト、スティーブン・オグレーディ氏は、「企業での採用動向に大きな影響があるとは思わない。現時点で、OO.oはOfficeに代わる選択肢として最も信頼されている製品だからだ」と話す。

　「ストールマン氏らの取り組みは一定の支持を集めるだろうが、現在のOO.oのコードベースの性質と規模を考えれば、少なくとも短期的には、信頼されるフリーソフトウェアの代替物を開発するのは難しい。Javaの使用が一部の断片的な機能に限定されていれば大したことはないだろうが、Open Office Baseのようなプラットフォーム的なものになれば、移植に要する作業は半端ではなさそうだ」（オグレーディ氏）

原文へのリンク