«前の日記(2004-07-06) 最新 次の日記(2004-07-08)» 編集

Matzにっき


2004-07-07 七夕 [長年日記]

_ [OSS]オープンソースによる互換性の喪失

mimiさんからのツッコミをいただいたが、 十分に理解できた自信がない。

オープンソース化されれば、差別化、重視になるでしょう。
一部のコミュニティが互換性を無視することに対してコミットして、互換性は失われる方向になる。
オープンソース化すると、誰にも互換性の維持はできない。
と考えています。

分からなかったのは、

  • 「差別化、重視」とは、誰が、何を、どのように、行うことを想定しているのか。
  • 「コミュニティの一部が互換性を無視することに対してコミットする」とは、 誰が、何を、どのように、行うことを想定しているのか。

という点だ。

前者についていえば、あるオープンソースプロジェクトに対して「差別化を行う」ということは、 差別化できる存在を新たに作る、すなわちフォークを意味すると思われる。 それ以外の差別化はオープンソースであるなしに関らず発生するからだ。 しかし、実際にはフォークはめったに起きないし、 起きたとしてもどちらのプロジェクトが「正当」であるかは明らかなので、 互換性を重視する人がどちらを選ぶかは明白だ。

後者については、「コミュニティの一部が互換性を無視することに対してコミットする」という表現は、 やはりフォークを想起させる。 たとえオープンソースであろうとも、プロジェクト管理者(JavaならSun)が望まない修正は取り込まれないし、 ローカルパッチは決して広く受け入れられないからだ。 結局はフォークを心配しているのね。 しかし、上に述べたように、フォークは重大な問題ではありえない。

想定できる問題として「互換性はないが、より優れたフォーク」が登場した場合に 発生しうる混乱があるが、これは心配しなくてもいいんじゃないかなあ。 フォークが発生したとしても、まずフォークした方は長期的には生存できないと思う。 Sunやその他の人々がJDKに注力しているリソースを考えると、 それを越えるのは容易ではないし、そんなことを考えるのはマイクロソフトくらいだ。

それもArtisticライセンスのようにプログラム名を担保するとか、登録商標を駆使するとかで、 少なくとも「Javaの名前」は守れるだろう。 名前が違ってしまえば、それは「Javaに似たなにか」であり、 違うものであるのでそもそも互換性は問題ではない(それがC#か)。

多くのオープンソースプロジェクトが互換性を重視していないのは事実だが、 それはそれだけのコストを払っていない(払いたくない)からであって、 オープンソースだからではない。 Sunは互換性維持のためにこれまで十分コストを払ってきたと思うし、 その努力にはオープンソース化してもあいかわらず有効だと思う。

と、いうことで楽観的な私の結論は、

  • オープンソースかどうかと、互換性の維持のコストはほとんど関係ない

である。

mimiさんには「オープンソース化すると、誰にも互換性の維持はできない」という結論を出す 論拠なり、実例なりがあるのだろうか。 Javaくらいのプロジェクトだとフォークが頻繁に起きることが予想できる理由がある、とか。

それから、現状のJDKはGosling自身の言葉のように

「われわれは、(Javaの)ソースコードをコミュニティーに提供することで、多大な恩恵を受けている。唯一の難点は、ライセンス条件が一部の人が望むより、少し面倒だという点だ」

であり、ソースコードは入手可能で、ライセンス上の問題以外はオープンソースとさして変わりはない。 もっとも、その問題が重要だと考える「開発者」は多いだろう。 逆に上記のHotWiredが声を聞いた「ユーザ」にとっては技術上の些細な点に過ぎない。

私は、この「ライセンス上の面倒」の解決は、 Sunにとって大きなメリットがあり、デメリットはほとんどないのではないか、 と私は思うんだけど、どうなんだろうねえ。

本日のツッコミ(全12件) [ツッコミを入れる]
_ さる (2004-07-07 15:32)

何故最初から最後までまつもとさん(もしくはどこかのオープンソース開発者)が影響をうけるメリットとデメリットではなく、SUNのメリット、デメリットについて論じられているのでしょう…。<br>これはオープンソース推進のための政治的発言なのでしょうか。<br>さるなみの頭ではよくわかりません…。

_ まつもと (2004-07-07 15:42)

オープンソース化を渋るSunの真意が知りたいので考察を試みてい<br>るわけです。ま、いくら考察しても推測するだけで「知る」ことが<br>できるわけじゃありませんけどね。<br><br>私自身について語らないのは、私はSunのいかなる決定に影響を受<br>けないからです。私自身にはメリットもデメリットもないので。<br>知りもしない他人の気持ちを代弁するつもりもありませんし。

_ ごうこ (2004-07-07 22:56)

オープンソースの言語に限定した場合、枝わかれしたものってあるのでしょうか。わたしが思い付くのはgccですが、意外と少なさそうですね。

_ taiji (2004-07-08 00:08)

言語ではないですが、Meadowなんかもforkしたものですね。でも、本家のリリース+Meadow Featureで、ほぼ互換性は保たれているケースだと思います。

_ HA (2004-07-08 00:33)

私は、仮にJAVAをオープンソースとした場合、SUNがリーダーシップを取れなくなってしまう「可能性がゼロでない」のを恐れているように感じます。<br>些細な分岐がSUNに変わる本流となりえないとは言い切れないところに躊躇しているんじゃなかろうかと推測してます。

_ JAru (2004-07-08 03:51)

SWTがデフォルトのJavaとがができると、SunのJava戦略は完全に終わってしまうからとか。

_ さる (2004-07-08 08:10)

結局、オープンソースは素晴らしい、オープンソースが善だ、という二元論を展開されているのでしょうか?<br>そうであれば納得します。<br>>私見だが、SunはJavaのコア(JDK)をオープンソース化した方がメリットが多いと思う<br>>Sunにとって大きなメリットがあり、デメリットはほとんどないのではないか<br>具体的な項目を挙げずにメリットがあるとだけ書かれたものを考察と仰るのは<br>実際にオープンソースで言語を開発されている方の論としてはあまりにお寒いのでは。

_ まつもと (2004-07-08 08:51)

ここでは、どのような二元論も展開した覚えはありませんが。<br><br>っていうか、私は「オープンソースは善」なんて思ってなくて、実<br>際には「オープンソースの方が有利な局面はみなが思っているより<br>多い」くらいですかね。そういう意味では「すばらしい」とは思っ<br>てますね。<br><br>「具体的な項目を挙げずにメリットがあるとだけ書かれた」とのこ<br>とですが、この「メリット」は「オープンソースのメリット」全般<br>を指していると考えてください。それについては他でもいろいろ書<br>かれているので、繰り返す必要を感じませんでした。<br><br>私がこのエントリで述べたかったことは、Sunがデメリットである<br>と自ら述べている「互換性の喪失」はさして重大な問題でないこと<br>です。Sun以外にも「互換性の喪失」を理由にオープンソース化を<br>躊躇しているケースがあるそうなので、ここはきちんとさせておき<br>たいと思っていました。<br><br>さるさんが、「実際にオープンソースで言語を開発」している私に<br>なにを期待してくださっていたのかは分かりませんが、私の意図は<br>そういうことです。<br><br>直メールで、フォークを避けるためのLaTeX Project Public License 1.3<br><br> http://www.latex-project.org/lppl/lppl-1-3.txt<br><br>のようなライセンスもあると教えていただきました。LPPL 1.2は<br>GPLコンパチではなかったのですが、(私が読んだ限りでは)1.3は<br>OSD準拠でGPLと矛盾しないような気がします。いや、GPLコンパチ<br>の方はFSFの見解を聞いてみないとほんとのところは分からないけ<br>れども。

_ Xelloss (2004-07-08 09:10)

Linuxのカーネルのように正統Java仕様はSunのJavaであり、その他は派生もしくは異端JavaであるからJavaの名前を使うことを禁じる、もしくは正統ではないと言及する必要がある。というのはどうでしょう?

_ まつもと (2004-07-08 09:29)

アリだと思います>Xellosさん<br><br>上で私が「Artisticライセンスのようにプログラム名を担保するとか、登録商標を駆使するとか」と書いたのは、そういうのを意識してのことです。

_ KL (2004-07-08 12:22)

「オープンソース化を渋るSunの真意」というと、Javaは自社のサーバとサービスをそれなりに売るための釣り道具以上でも以下でもないから、という身も蓋もない理由しか思いつかないのですが。Solarisは、ほとんどSparcのサーバしか売れないのとこれまでSunや富士通しか扱ってないのとでオープンソースでOKでも、Javaは色々なプレイヤーが参加しておりかつ市場価値ももっと大きいので手綱を握る利益も大きいのは明白です。日本の企業がCurlを支援してましたが、Javaで競合するよりCurlならうちだよと言える方がある意味独占状態で楽というのと同じ話です。純粋にソフトウェアだけの話なら商標とかソフトウェアライセンスとかで解決する道もあるかもしれませんが(Sunにとっては)そもそもそういう話ではないんじゃないですかね。まあ、互換性という言葉も曖昧でややこしいのでそんな理由を持ち出すべきでなかったということかもしれませんが。http://www.theregister.co.uk/2004/07/01/sun_open_source_java/<br>のコラムが、Sunの事情やオープンソース支持者とのズレを解説していて、オープンソース化されるとコストが上がるという話は議論の余地有りとしても、他は結構参考になります。<br><br>それから、Javaのforkを行う利益と力のある者としては、今回Sunにオープンソース化を要求したIBMが容易に想起されます。IBMじゃなかったら、既にJavaの実装と市場シェアとを持っている他のアプリケーションサーバのメーカーです。オープンソースの方からは、Mono+IKVMもありますし。で、Javaの名前だけ守れても、実態で負けているのでは客もそんなに馬鹿ではないですから空洞化して話にならないと思うのですが。<br><br>もちろん、まつもとさんがあえてこの話題を取り上げるのは、Javaは、同じサーバ/サービスを売る道具でも、IBMがオープンソースにしていないDB2やWebSphereと違って、プログラミング言語でもあり、インフラなので、公開のメリットが大きいことからSunの姿勢を疑問視しているのだと思います。がしかし、Sunのような複合企業にとっては現実問題として不採算を被る分野があるという現実的見通しがあるはずで、だからThe RegisterのコラムはSunは非効率な垂直的企業だというウォール街からの批判を引いてますが、Sunが実際にNetscapeのように潰れるなりしない限り結論のでないSun特有の問題で、だから決定が難しい筈です。Javaのオープンソース化によってSunが経営的に生き延びる確固たる見込みがあるというなら別ですが多分無いんでしょう。

_ Mr.orz (2004-07-09 14:30)

言語系とか(TEXなんかも含めて)は、これまで蓄積してきたソース・スクリプト(コンパイラ・インタープリタ側からみると「データ」)の互換性がでかいですよね?<br>だから「forkをおそれる」という企業のスタンスはよく理解できます。<br>「旧バージョンで動いていたプログラムが新バージョンで動かない」というサポートはとても面倒。ましてや「新バージョンはウチじゃなくて別のコミュニティで勝手にコミットしてるんですがーーorz」なんて間抜けな対応したくないでしょうし。

お名前:
E-mail:
コメント:
[]

«前の日記(2004-07-06) 最新 次の日記(2004-07-08)» 編集

track feed Matzにっき Creative Commons License This work is licensed under a Creative Commons License.