Java Programming Language

Stephen Colebourne氏が自身のブログにおいて次の3つの記事を公開した。タイトルどおり、Java 7はいらない、という内容だ。

• No more Java 7
• Shedding new light on No Java SE 7 JSR
• Sun, Apache & IP - in pictures!

4年ほど以前の話になるが、Apacheは2005年5月14日(米国時間)、J2SE 5のオープンソースソフトウェア実装をめざしてHarmonyプロジェクトを開始した。しかし開発はリリース直前で頓挫する。それはJavaとしてリリースするためにクリアすべき互換試験キットの利用に制限が設けられていたためだ。この条項はOSSでプロダクトを公開するというApacheの方針とは相容れないため、Apacheは契約を結ばず文句を言いつづけてきた。そして2年が経過したが、状況はよくなっていないというわけだ。

Apacheはその態度をJSRで明確に示してきた。この問題が解決するまではJSRの投票で反対票を表明し続けるというのだ。

• Java Servlet 3.0、最初の提案を追加 - ASFは投票を棄権、その理由は?
• Java Servlet 3.0機能概要、賛成多数で通過もASFは反対票
• Java EE 6、最初の承認プロセスを通過 - ASFはついに反対票

そうこうしている間にもJava実装はOpenJDKとしてGPLのもとで公開されるようになった。ライセンス的に公開されていなかった部分も実装され、名実共にOSS Javaになったはずだったが、そこには狡猾な仕組みがあるとStephen Colebourne氏は指摘する。

Javaの仕様を実装したと名乗るには互換試験にクリアする必要があるが、このコードには使用分野制限条項が盛り込まれている。この条項の内容自体はそう大したものではなくなぜ用意したのか頭をひねりたくなる内容だが、使用分野制限条項そのものに問題があるという。この条項があるために互換試験キットを使ったソースコードに同条項を追加する必要があり、この条項はOSSライセンスとは相容れない内容になっているためOSSとしては公開できないというわけだ。

Stephen Colebourne氏はNo more Java 7のなかで「Next release - JDK 7, not Java 7」という言葉を使って状況を象徴的に説明している。Java SEは結局のところ1社に制御されておりもはやオープンスタンダートではないという。実装はOSSでも仕様がオープンとして実現できないように互換試験キットに罠が設けられているから、という理由だ。仮にSun MicrosystemsがJava SEに関してその意図は持っていないとしても、Java EEやServlets、JMSについてはどうなんだと疑問を呈し、今まさにオープンスタンダードについて考慮すべきときだと述べている。

なお方向性は異なるが、Apacheの取り組みやポリシーとは異なる取り組みをしてきたOSSプロジェクトもある。FreeBSD FoundationはSunとライセンスを締結してJavaの移植と互換試験のクリア、バイナリパッケージでの提供を実施してきた。同移植の成果は最終的にOpenJDKにマージされ、OpenJDKのMac OS Xへの移植のベースとしても使われている。