«前の日記(2004年07月07日) 最新 次の日記(2004年07月09日)» 編集

Matzにっき


2004年07月08日 [長年日記]

_ [OSS]SunがJavaをオープンソース化した方が良い4つの理由

KLさんから貴重なツッコミをいただいた。少々長いが、全文を引用する。

「オープンソース化を渋るSunの真意」というと、Javaは自社のサーバとサービスをそれなりに売るための釣り道具以上でも以下でもないから、という身も蓋もない理由しか思いつかないのですが。Solarisは、ほとんどSparcのサーバしか売れないのとこれまでSunや富士通しか扱ってないのとでオープンソースでOKでも、Javaは色々なプレイヤーが参加しておりかつ市場価値ももっと大きいので手綱を握る利益も大きいのは明白です。日本の企業がCurlを支援してましたが、Javaで競合するよりCurlならうちだよと言える方がある意味独占状態で楽というのと同じ話です。純粋にソフトウェアだけの話なら商標とかソフトウェアライセンスとかで解決する道もあるかもしれませんが(Sunにとっては)そもそもそういう話ではないんじゃないですかね。まあ、互換性という言葉も曖昧でややこしいのでそんな理由を持ち出すべきでなかったということかもしれませんが。http://www.theregister.co.uk/2004/07/01/sun_open_source_java/ のコラムが、Sunの事情やオープンソース支持者とのズレを解説していて、オープンソース化されるとコストが上がるという話は議論の余地有りとしても、他は結構参考になります。

それから、Javaのforkを行う利益と力のある者としては、今回Sunにオープンソース化を要求したIBMが容易に想起されます。IBMじゃなかったら、既にJavaの実装と市場シェアとを持っている他のアプリケーションサーバのメーカーです。オープンソースの方からは、Mono+IKVMもありますし。で、Javaの名前だけ守れても、実態で負けているのでは客もそんなに馬鹿ではないですから空洞化して話にならないと思うのですが。

もちろん、まつもとさんがあえてこの話題を取り上げるのは、Javaは、同じサーバ/サービスを売る道具でも、IBMがオープンソースにしていないDB2やWebSphereと違って、プログラミング言語でもあり、インフラなので、公開のメリットが大きいことからSunの姿勢を疑問視しているのだと思います。がしかし、Sunのような複合企業にとっては現実問題として不採算を被る分野があるという現実的見通しがあるはずで、だからThe RegisterのコラムはSunは非効率な垂直的企業だというウォール街からの批判を引いてますが、Sunが実際にNetscapeのように潰れるなりしない限り結論のでないSun特有の問題で、だから決定が難しい筈です。Javaのオープンソース化によってSunが経営的に生き延びる確固たる見込みがあるというなら別ですが多分無いんでしょう。

まず、Sunがオープンソースを渋る真意はなにかというと、白状すると本当に分からない。

表向きには「互換性」ということになっているが、 Sunの連中が馬鹿だとは思わないので、 昨日までに述べた「本当はそれほど重大でない」ことは理解しているのではないかと思う。 それでもなおオープンソース化しない理由はなにか。

まあ、Sunは今までにフリーソフトウェアに対する貢献はあったとはいうものの、 全体としては別に特別「オープンソース(フリーソフトウェア)に熱心な会社」であったわけではないので(非難しているわけではない。数年前までは企業としては当然の態度だ。過去の貢献を考えれば上出来のほうだと思う)、 誰か頑固な幹部がいるというだけのことかもしれない。

それはそれとして、私が個人的に思うSunがJava(JDK)をオープンソース化した方が良いと思う理由をリストしてみよう。

  1. 私がJavaのオープンソース化を取り上げる最大の理由は、プログラミング言語であるからではなく、 「すでにソースが公開されているのにオープンソースでない」点だ。 いくら私でも今までずっと公開していなかったものを、 「オープンソースこそすべてだ、それ以外に道はない」などと叫んでむりやり公開させるつもりはない。 しかし、Javaに関しては今公開されているものをそのままに、 「不自由なライセンス条項」を変更するだけで良いはずだ。 今、JDKはすべてSunの資産でライセンス変更に伴う面倒な権利関係は発生しないと思うのだが。 その点、非公開のCurlとは事情が違う。
  2. SunのJDKがオープンソース化されなくても、 すでに他のJVM実装が存在し、その中にはオープンソースのものも存在する。 ライセンスを自由にすることで、現状それらに分散しているリソースを集約し、 より速い発展が期待できる(というか、もっと早くオープンソース化してれば、 こんなに無駄なことにはならなかったのに)。
  3. すでに述べた理由により、(Sun自身が捨てない限り)フォークはまず起きない。 たとえ起きたとしてもSun自身の地位が今以上に悪くなる心配はない。 今でもたとえばKaffe VMに非互換性があるかもしれないが、それでSunを責める人はいない。
  4. たとえ今後もJava自身をオープンソース化しなくても、Sunのビジネスには利しない。 現状でも「Javaビジネス」の市場シェアを得ているのはIBMなどSun以外の会社である。 むしろ積極的にオープンソース化することにより、 より良い「ブランド」を獲得できる可能性がある。

というわけで、たいしたコストなしに進歩を加速できるメリットがあると思うんだが。

KLさんは「実態で負けていては」とおっしゃるが、 それはオープンソース化してもしなくても同じことだと思う。

だが、仮にSunが「将来、Java(JDK)を商品にしたい」思っていたとしたら、 オープンソース化に抵抗があるかもしれない。 商用版を出したとたんに、 オープンソース版からフォークが発生するのを止められないから。 これが隠された真の理由だったりして。

ただ、それはあまり賢明な判断には思えないなあ。 まず売れないし(「言語ビジネスは死屍累々」を思い出そう)、 ブランドイメージは傷つくし、 それに結局オープンソースな別実装の登場を禁止することはできないし(既にあるし)。

結局は「勢いのない」Sunにとって、 「Javaのオープンソース化によってSunが経営的に生き延びる確固たる見込みがある」かどうかが、 選択の分かれ目だろう。 でも、Sunの現状は構造的なものだからねえ。

Java関連ってSunの売り上げのどのくらいを占めているんだろう。 たぶん、微々たるものだと思うのだが。 だから、Javaをオープンソースにしても、しなくても、状況が厳しいことには変わらないんじゃないかな。

だったら、むしろ積極的にオープンソースを前面に出してブランドイメージの改善を図った方が....。

ここまでこじれてからだと難しいかな。

Sunが潰れるとさみしいな、困りはしないけど。この「困らない」ってのがSunの現状を反映してそう。

_ [morg]バックエンドほぼ完了

全部で1000行ほどか。結局、Estraierの検索はRubyだけで実現できず(そりゃそうだ)、 Cでちょっとした(150行ほど)拡張ライブラリを書く必要があった。あとはSimilarity Searchは手つかずだけど。 これは特徴的単語の抽出が思ったよりも難しかったので、後回し。

ところで、EstraierってMIME文書のサブジェクト(title属性)とか差出人(author属性)とかは、 検索の対象にならないのね。メール検索としては、かなり使い勝手が悪い。 あんまり、ローカルハックをしたくはないんだけどなあ。

とかいってると、平林さんが新しいバージョンをリリースしてくださるかも。


«前の日記(2004年07月07日) 最新 次の日記(2004年07月09日)» 編集