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

Matzにっき


2004-07-09 [長年日記]

_ 健康診断

年に一度の健康診断。身長、体重、視力、聴力、血圧、心電図、血液検査、胸部X線、胃X線。

バリウムおいしくない。来年は胃カメラだ(げんなり)。

_ Estraier

昨日、Estraierでauthor属性の検索ができないとか書いたら、 さっそく平林さんからメールをいただいた。近いうちに対応していただけそう。ありたがいことだ。

追記

改めて調べたらEstlaier 1.2.16が出てるじゃありませんか、今まで1.2.7なんてのを使ってました。 メールオーガナイザーを作ろうと思った時に入手したのに、もうこんなに進歩してるとは。 いつのまにか正規表現やワイルドカードでも検索できるようになってるし。

_ [Morg]フロントエンド

昨日の時点で、関連検索以外のバックエンドはほぼ動いたので、 今日からフロントエンドを作ろう、と思っているのだが、 今までバックエンドのことばかり考えていて、 フロントエンドはイメージが固まってないので、 またしばらくはぐたぐたと脳内で考える日々になるのかもしれない。

なんか、いつだって何日も(あるいは何ヶ月も、何年も)ぐだぐたと考えないと、 コーディングに入れないのは年取ったせいだろうか。

追記

結局、フロントエンドには手をつけず関連検索を実装しました。

_ [OSS]風博士

Debianのパッケージが更新されたので、0.1.7にアップグレードする。 すばらしい。

今までFirefoxと交代で使っていたが、これ一本に集約できそうな気がする。

すばらしい点

  • 履歴内検索(Estrailerを使っている)
  • Firefoxよりもきびきび動く。
  • メモリ消費量も少ない
  • テキストエリアからEditerを起動できる(私の場合はemacsclient)。Firefoxでもmozexでできたけど。

気に入らない点

  • IM(kinput2)使用中でも、キーアクセラレータが優先される。 私の場合、C-n, C-p, C-oを解除しないと使えなかった。
  • C-jのExtractSelectedLinksで、明示的に選択しないと開けない。 どうせなら、「保存」と同様最初からチェックが入っていてほしい。
  • メニューなどのフォントがfirefox-locale-jaよりも汚い。 これは風博士自身ではなく、Debianパッケージの問題だろう。

しかし、気に入らない点も些細なことばかりなので、我慢できる。

_ [OSS]フォークと互換性

Sun Microsystemsという企業がどのような経営判断するかどうかは、 私の手に余るので、「オープンソースプロジェクトのフォークと互換性」という点に絞って考えたい。

ここ数日いただいたコメントからは、 なんとなく「オープンソースではメンテナが望まないフォークが発生して、互換性を維持できなくなるケースがある」という暗黙の過程があるような気がする。

たとえば、

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

[mimiさんのコメント]

あるいは

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

[HAさんのコメント]

あるいは

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

[Mr.orzさんのコメント]

とか。

Mr.orzさんのコメントを取り上げてみれば、 前半の「互換性がでかい(重要ということか?)」というのは十分に理解できるのだが、 「forkをおそれる」というのはどういうことを想定しているのだろうか。 どのような事態が発生することをおそれているのだろうか。

オープンソース化しなくても新バージョンを出せば互換性問題の危険はあるし、 オープンソース化しても、勝手に「新バージョン」がリリースされるわけじゃない。 フォークはあるかもしれないが(めったにないけど)、 そんな場合でも「そのフォークはうちは知りません」の一言で済むはずだ。

オープンソースではフォークを禁止することはできない、これは事実だ。

しかし、メンテナが互換性を維持したいと望んでいるのに、 フォークなどの理由によって互換性の問題が発生するようなケースがあるのだろうか。 より厳密には、オープンソースだからという理由で互換性の問題が発生しやすくなることがあるだろうか。 私には想像できない。

私は「オープンソースが原因で互換性の問題は発生しない」と思っていて、 7月6日のエントリでも7月7日のエントリでも、 その理由を説明してきたはずだ。もちろん、あれでは「ゼロであること」を証明できてはいないが、 それはムリな相談だろう。やや危険なたとえを使うと、交通事故の可能性はゼロではないが人は車に乗るわけだし。

これは「オープンソースで互換性の問題が新たに発生しない」という意味で、 逆に言うと「オープンソースでなくても互換性の問題は発生する」と読み替えてもかまわない。

かつて「メンテナが望まないフォークが発生して、互換性を維持できなくなったケース」あったのだろうか。 これからありえるのだろうか。それともFUDにすぎないのか。

それをはっきりさせたいと思っているのだ。 もし、具体的なイメージはなく、ただ単におそれているだけならばかばかしい。

企業が自分のプロダクトをオープンソースにするもしないも、その企業の自由だ。 オープンソースというやり方を信じられない。結構。 オープンソースにしない方がビジネス上有利だと思うから。結構。 苦労して開発したソースは秘密にしたい。それも結構だ。

しかし、「オープンソース化すると互換性が損なわれるから」などという、 事実でないことを理由にしてほしくない。


言語の互換性問題と言えば、各種「方言」問題がある。たとえばPascalはいろいろ方言があり、 結局ある方言(コンパイラ)用のプログラムは、別のコンパイラでは動かない(ので結局別の言語と同じ)というような。

でも、このような方言問題の原因は、オープンソースではなく、 不完全な(あるいは曖昧な)言語仕様とそれに基づいた独自実装によるのではないか。 オープンソースの処理系があれば独自実装の必要性は薄れ、むしろ方言問題は回避できるのではないか。

Javaについては、おそらくはマイクロソフトの「J++ショック」が尾を引いているのかもしれない。

気持ちは想像できるが、その問題はSunのJDKのライセンスをオープンソースにしないことでは回避できない。

SunがJDKをオープンソースにしようとしまいと、 やろうと思えば、今日存在しているオープンソースJavaコンパイラ(たとえばgcj)を改造して、 Java方言を作るのは簡単だ。


私の知る範囲でプロジェクトのフォークが発生するのは次のような理由だ。

  • 進歩の方向に意見の対立が発生し、意見の調整ができなかった。

    この場合には「本家」はそのまま存続するので、本家についての互換性は問題ではない。 分家と本家との間には互換性の問題はあるが、これはオープンソースに限らない(独自実装とか方言とかの問題)。

  • メンテナがメンテナンスを放棄したが、後継者が複数登場し、一本化ができなかった。

    「本家」が放棄されているので、少なくとも互換性は問題にならない。

あと、可能性としては「ただフォークしたかった」というものもあるのかもしれない。

オープンソースでフォークが発生すると、重複した作業が発生するので、 リソースの無駄づかいが起きるし、進歩が阻害される傾向があるので、 望ましくない。しかし、たとえ発生したとしても、すくなくとも「互換性」の問題は発生しない。

ありがたいことに、フォークというのはめったに起きない事態だ。 これはオープンソースプロジェクトではオーナーシップが尊重されていることを反映しているだろう。

_ 期日前投票

日曜日は用事があるので、役場で期日前投票を行う。 国民の権利であり、義務だから。

もっとも青木自民党参議院幹事長を擁する島根県では結果が見えているわけで、 投票行動に対する動機づけが希薄なのは確かなのだが。

本日のツッコミ(全28件) [ツッコミを入れる]
_ soda (2004-07-09 20:13)

> 私の知る範囲でプロジェクトのフォークが発生するのは次のような理由だ。<br>> 進歩の方向に意見の対立が発生し、意見の調整ができなかった。<br><br>Sun が恐れているのはまさにこれでしょう。<br><br>> この場合には「本家」はそのまま存続するので、本家についての互換性は問<br>> 題ではない。<br><br>これは建前論で、実質的には問題あるのでは?<br>ライセンスをオープンソースライセンスに変更した結果、Sun の Java 実装を<br>ベースにしたソフトウェアを用いて Microsoft や IBM が本気で Java 言語<br>仕様のフォークを試みた場合を想定した上で、「本家はそのまま存続するので<br>互換性は問題ではない」というのは、あんまり意味があるセリフだとは思えま<br>せん。<br><br>現実に、Microsoft 版 Java が広く使われ、その結果 Microsoft VM でしか<br>動かない Java を用いたイントラネットシステムがあちこちで使われていた<br>わけですし。

_ とーりすがり (2004-07-09 21:16)

ひょっとしてオープンソースに強い思い入れのある Matzさんは「オープンソースにしたら互換性に問題がでる」という McNealy氏の発言を見てトサカに来ちゃったって事なんでしょうか?

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

>これは建前論で、実質的には問題あるのでは? <br><br>問題があっても、それは「オープンソースだから発生した問題」で<br>はありませんよね。事実、「MS JVM」問題ではSunのJDKは利用して<br>なかったわけだし。だから、「互換性」はオープンソース化しない<br>理由としては不適切じゃないかと。<br><br>「オープンソース化したら、そういう問題が発生しやすくなる」と<br>いう主張なら理解できなくもないですが、Sunと対抗してJavaをコ<br>ントロールするつもりのある企業なら、マイクロソフトのように<br>Sunのコードを使わずとも自前で「独自Java」を作れるでしょうし、<br>それだけの力がないとJavaコミュニティ全体に影響を与えられない<br>のではないかと思います。<br><br>>McNealy氏の発言を見てトサカに来ちゃったって事なんでしょうか? <br><br>反発したのは事実ですが、別に「オープンソースをけがした」とか<br>いうような理由じゃなく、事実に反する(と私に思える)発言だから<br>反発したわけです。

_ soda (2004-07-09 22:35)

> 「MS JVM」問題ではSunのJDKは利用してなかったわけだし。<br>> だから、「互換性」はオープンソース化しない理由としては<br>> 不適切じゃないかと。<br><br>そうは思いません。<br>Microsoft は Sun の JVM をベースに独自に変更をした VM<br>を利用していたわけですよね? だからこそ、Sun は Java の<br>ライセンス条件に違反したとして Microsoft を訴えることが<br>できたわけですし、この裁判の和解金として、Microsoft か<br>ら7億ドルにもおよぶ現金を得ることができたわけです。<br><br>もし、Java がオープンソースのライセンスを利用してた<br>としたら、Sun は Microsoft を訴えることができなかった<br>わけですし、今頃 Microsoft 仕様の Java がデファクト<br>スタンダードになっていたのは間違いないと思います。<br>(Netscape ではなく Internet Explorer がスタンダード<br>になったように)

_ とーりすがり (2004-07-09 23:09)

たしかに McNealy氏の発言はマトモに考察すると事実に反するのかもしれませんが、そもそも Java をオープンソースにしない言い訳が欲しかっただけであって「オープンソースにしたら互換性に問題がでる」という部分にそれほど重要な意味があるとは思えません。あえて言えば Java から J++ -> C# へと fork していった過去を思い出させて JavaユーザのアンチMicrosoftな心(?)を揺さぶる作戦なのかもしれない、と思うぐらいです。仮に Sun が本気で「オープンソースにしたら互換性に問題がでる」と考えているとすると、今後オープンソースになる(?) Java3D やら既にオープンソースになっている OpenOffice には互換性に問題が出てもよいと考えている事になりますし。

_ soda (2004-07-09 23:18)

> 仮に Sun が本気で「オープンソースにしたら互換性に問題がでる」と考え<br>> ているとすると、今後オープンソースになる(?) Java3D やら既にオープン<br>> ソースになっている OpenOffice には互換性に問題が出てもよいと考えてい<br>> る事になりますし。<br><br>このあたりは、オープンソースにすることによるメリットとデメリットの<br>トレードオフでしょう。<br><br>OpenOffice に関しては、基本的機能においてまだコミュニティによる<br>開発の援助を当てできる部分が沢山残っていて、かつこれから普及も<br>目指さなければいけない立場にあります。この状況では、プロジェクト<br>のフォークに関する懸念よりも、オープンソース化のメリットの方が<br>大きいと考えるのは自然です。<br><br>これに対し、Java は言語のコア部分については、既に十分な機能を持って<br>いて、かつ普及も十分しているわけです。オープンソース化することに<br>よって「Sunにとって」どれくらいメリットがあるかは疑わしいのでは?

_ まつもと (2004-07-09 23:38)

MicrosoftとSunのライセンス(1996年3月)と合意内容(2001年1月お<br>よび2004年4月)の詳細は公表されていないはずです。だから、実際<br>のところ、なにをもって「違反」と見なしたのかは明らかではない<br>と思います。<br><br>確かに、Sunが当初からJDKにオープンソースのライセンスを適用し<br>ていれば、Javaは我々の知る歴史とは違う歴史をたどったろうとは<br>思います。しかし、JDK(実装)をオープンソースにしたとしても、<br>Sunが「Java compatible」の商標の権利など「言語の権利」を手放<br>したとは思えませんし、それほど簡単に<br><br>>今頃 Microsoft 仕様の Java がデファクト<br>>スタンダードになっていたのは間違いないと思います。 <br><br>とは言い切れないのではないでしょうか。そもそもオープンソース<br>であれば、自らの権利の放棄を嫌忌するMicrosoftは手を出さなかっ<br>たかもしれませんし。<br><br>いや、素人が安易に「歴史のif」を語るのは危険かもしれません<br>ね。実際にはJDKが公開された時点では「オープンソース」という<br>言葉は存在せず、企業が重要なプロダクトのソースコードに自由な<br>ライセンスを適用させることが正気だとは思われなかった時代だっ<br>たのですから。<br><br>まとめ<br><br> * MicrosoftとSunの争いはライセンス違反が原因ですが、そのラ<br> イセンスの内容は明らかではありません。おそらくはJDKのソー<br> スコードを流用したことは主要な原因ではなく、ライセンスの<br> 中に含まれていただろう「Javaの互換性を保証する」という条<br> 項をマイクロソフトが無視したせいではないかと想像します。<br><br> * JDKをオープンソースにしていれば、Microsoftはライセンス違<br> 反なしに改変したJDKを配布できたでしょう。しかし、Sunとの<br> 間に別の訴訟が発生していたでしょう(商標とは特許とか不当競<br> 争の制限とか独占禁止とか)。泥沼は一緒だったと想像します。<br><br> あ、でも補償金の支払い額はずっと少なくなったかも。<br><br> * いずれにしても「オープンソース だ か ら 互換性の問題が起<br> きる」という理由にはならないと思います。

_ まつもと (2004-07-09 23:54)

とーりすがりさん:<br>> そもそも Java をオープンソースにしない言い訳が欲しかっただけであって<br><br>それならそれでもっと良い言い訳にしてほしかったわけです。何度<br>も繰り返しているように Sun はどうでもよいのですが、「オープ<br>ンソースにすると互換性に不安が出るんだってよ」というような<br>FUDの蔓延は避けたいので。<br><br>> 「オープンソースにしたら互換性に問題がでる」という部分にそれほど重要<br>> な意味があるとは思えません。<br><br>みんながみんなそう思ってくれればよいのですが。みなさんのコメ<br>ントを読んでいると、このFUDは思った以上に普及してそうです。<br><br>sodaさん:<br>>Java は言語のコア部分については、既に十分な機能を持って<br>>いて、かつ普及も十分しているわけです。オープンソース化することに<br>>よって「Sunにとって」どれくらいメリットがあるかは疑わしいのでは?<br><br>「Sunにとってメリットがない」というのは、私にとっては十分な<br>「言い訳」です。最初からそれだけ言ってくれればいいのに、「互<br>換性」なんて言うから私がこんなところでぶつぶつ言うわけです。<br><br>しかし、「Sunにとってメリットがない」で納得しない人が多いか<br>らこそ、何度も何度もオープンソース化の要望が持ち上がるんでしょ<br>うけどね。

_ 別のとーりすがり (2004-07-10 00:19)

ここを見ていると大した理由もなくオープンソース化を要求する人がいるらしいというFUDの方が余程広まりそうですが。<br>あ、FUDじゃない?<br>結局最後まで"SUN"が"Java"をオープンソースにする理由は提示されなかったようで。それなら全て一般論として述べられればよかったのでは。

_ murayama (2004-07-10 00:38)

はじめまして。<br><br>これまでの議論を読んでいると以下のように思えます。<br><br>結局のところSUNからすれば、<br>「Javaをオープンソースにすることによる具体的なメリットが見えない」からオープンソースにしたくはない。<br>しかし、このことを正直にJava Developer (かつオープンソース擁護者)に言えば、<br>「SUNは、やはりJavaを独占しようとしている。JCPによるオープンな開発なんてウソっぱちじゃないか!」(誇張表現です)<br>と反発されるであろうことが予測される。<br>だからSUNは金看板として「互換性」を持ち出すことで、<br>Java Developer達に言い訳をした。<br><br>まつもと氏からすれば、<br>SUNは己の望みを正当化するためにオープンソースそのものに<br>問題があるように述べ、Java Developer達からの盾代わりにした。<br>SUNはある意味、事実とも虚偽とも取れる発言をした。<br>SUNは、<br>「オープンソースの在り方はSUNがJavaに対して望んでいるものではない。」<br>そうはっきり言えば良いのに…と、まつもと氏は思っている。<br><br>…こんな風に解釈できるのですが、いかがなものでしょうか?

_ soda (2004-07-10 00:59)

> Sunが「Java compatible」の商標の権利など「言語の権利」を手放<br>> したとは思えませんし、<br><br>Microsoft の立場に対抗するのに、商標権は全く役に立たないでしょう。<br>Netscape の持っていたブラウザのシェアを Internet Explorer で<br>乗っとるのに商標権は全く不要だったわけで。<br>必要なのは、商標よりも、使い物になる実装と、市場で持つ力の<br>方だと思います。そして、Microsoft はデスクトップの世界では、<br>圧倒的な市場支配力を持っているわけです。<br><br>> > 今頃 Microsoft 仕様の Java がデファクト<br>> > スタンダードになっていたのは間違いないと思います。 <br><br>> とは言い切れないのではないでしょうか。そもそもオープンソース<br>> であれば、自らの権利の放棄を嫌忌するMicrosoftは手を出さなかっ<br>> たかもしれませんし。<br><br>そんなことは全くないと思います。Microsoft が配布している SFU の<br>中にはGPL のプロダクツ (gcc, binutils, ...) だって入ってますよ。<br><br>> 実際にはJDKが公開された時点では「オープンソース」という<br>> 言葉は存在せず、企業が重要なプロダクトのソースコードに自由な<br>> ライセンスを適用させることが正気だとは思われなかった時代だっ<br>> たのですから。<br><br>オープンソースという言葉こそなかったかもしれませんが、「正気だ<br>とは思われなかった時代」というのは全くの記憶違いでしょう。<br>UNIX 関係の企業にとって、Java が開発された時点で、現在オープン<br>ソースという言葉で呼ばれる概念は既に当たり前のものでした。<br>たとえば X11 も、オープンソースという言葉ができるよりはるか昔に、<br>UNIX系企業のお金で(それ以外からのお金もありますが)開発され、<br>オープンソースのライセンスで配布されていました。もちろん X11 の<br>中には Sun が寄贈したコードも含まれています。<br>X11 だけが例外ではありません。たとえば<br>ftp://ftp.sra.co.jp/pub/net/sunrpc/rpc3.9/ は Sun によって<br>1987年にオープンソースのライセンスで配布されたソフトウェア<br>であり、現在も glibc や BSD 系の libc に、このソフトウェアの<br>直系の子孫となるコードが含まれています。<br><br>> * MicrosoftとSunの争いはライセンス違反が原因ですが、そのラ<br>> イセンスの内容は明らかではありません。おそらくはJDKのソー<br>> スコードを流用したことは主要な原因ではなく、ライセンスの<br>> 中に含まれていただろう「Javaの互換性を保証する」という条<br>> 項をマイクロソフトが無視したせいではないかと想像します。<br><br>その通りです。そして、オープンソースライセンスの特徴の一つは<br>「改変の自由を保証する」ことにあります。もし Sun が Java に<br>オープンソースを採用していたら、Microsoft を止める手段は全く<br>なかっただろうというのが私の意見です。<br><br>> * JDKをオープンソースにしていれば、Microsoftはライセンス違<br>> 反なしに改変したJDKを配布できたでしょう。しかし、Sunとの<br>> 間に別の訴訟が発生していたでしょう(商標とは特許とか不当競<br>> 争の制限とか独占禁止とか)。<br><br>・デスクトップで圧倒的な市場支配力を持っている Microsoft には、<br> Java という商標を利用する必要は全くありませんから、商標は<br> 問題になりません。<br>・オープンソースで配布したソフトウェアの中身について、特許権で<br> 訴えるのは無理だと思います。そのソフトウェアに特許に関係する事項<br> が含まれていたにせよ、ライセンスで、無償の利用と、改変したもの<br> を自由に配布する権利を保証してしまっているわけですから。<br>・不当競争に関しては、仕様の異なるソフトウェアを配布することに<br> 対して、この名目でで訴えるのは不可能では? そもそもオープン<br> ソースライセンスを使うということは、仕様の異なるソフトウェアの<br> 配布を公けに認めることに等しいわけですから。<br>・独占禁止については、Java のケースでどう適用できるのか、良く<br> 分かりません。あんなに明らかであると思われた対 Netscape の<br> 独占禁止訴訟であっても、Microsoft は実質無傷で切り抜けることが<br> できたこともお忘れなく…<br><br>> いずれにしても「オープンソース だ か ら 互換性の問題が起<br>> きる」という理由にはならないと思います。<br><br>どうもこれが分かりません。改変の自由を保証する (つまり互換性を<br>保証できない) ことは、オープンソースライセンスの特徴の一つです。<br>もし、互換性を絶対に保証したかったら、この点に関してどうしても<br>オープンソースライセンスの基準と矛盾してしまうは、誰の目で見ても<br>明らかだと思うのですが…

_ まつもと (2004-07-10 12:25)

murayamaさんへ:<br><br> 私の主張はだいたいそんな感じです。<br><br>「別のとーりすがり」さんへ:<br><br> 「全て一般論として述べられればよかったのでは」というのは、そ<br> の通りかもしれません。私の表現や筋道の立て方の戦略に問題があっ<br> たかもしれません。私は別にSunの行動には不満を持っていなくて、<br> あの特定の発言だけ問題視していたのが伝わらなかった人もいた<br> ようです。<br><br>sodaさんへ:<br><br> 「歴史のif」には意味がないような気がしますから、ここでは2<br> 点だけ。<br><br> 「正気」について。JDKがリリースされた90年代前半でも確かに<br> フリーソフトウェアを支援・貢献する企業はSunを含めてたくさ<br> んありましたが、<br><br> * 自らが主体的に開発した<br> * 「重要な」つまり企業としてのメインストリームに属する<br><br> ようなプロダクトをフリーソフトウェアにした例はなかったと思<br> いますし、そのような行為はやはり正気とは思われなかったので<br> はないかと思います。Xは多くの企業から支援を受けましたが、<br> 元々MITで開発されたものですし、rpcなどはSun全体からは瑣末<br> なプロダクトでしょうし。<br><br> 当時のSunにとってのJavaくらい「重要な」ものでもフリーソフ<br> トウェアにすることは「普通(or 正気の範囲内)」であり、私が<br> それを知らなかっただけってことはないと思うのですが。<br><br> 「絶対の互換性の保証」について。フォークを禁止できない以上、<br> 「互換性のないフォーク」の登場の可能性は否定できません。そ<br> ういう意味では「絶対の互換性の保証」はおっしゃるようにオー<br> プンソースの基準と矛盾します。しかし、そもそも「絶対の」互<br> 換性の保証なんてありえないだろうと私は思っているのです。オー<br> プンソースでなくても「互換品」の登場はいくらでも起きている<br> わけですし。まったく独立した実装まで考えるとオープンソース<br> は関係ないだろうということです。<br><br> 今回マイクロソフトはたまたま事前にライセンス契約を結んでい<br> たので、訴訟になりましたが、もし彼らがSunとライセンスを結<br> ばず、ソースコードを流用せず、商標も用いず、「非互換なJava」<br> を提供していたら、Javaがオープンソースじゃなくてもsodaさん<br> が予想する状況が現実化していたことでしょう。いや、「歴史の<br> if」は避けるんでしたね。<br><br> オープンソースにすることで、ソースコードを流用した「フォー<br> ク(非互換品)」を作りやすくなるのは事実かもしれませんが、実<br> 際には、そういう事例はかなり少ないですよね。むしろ、互換性<br> を気にしない(私のような)メンテナによるバージョン間の互換性<br> 問題の方がはるかに多い。

_ knok (2004-07-10 12:37)

オープンソース化による Sun のメリットというと、「さまざまなアーキテク<br>チャに porting される可能性がある」ということがあると思うんですが、実<br>際に Sun がそれをうれしいと思うかどうかは聞いてみないとわからないとこ<br>ろですね。<br><br>まあ FreeBSD の例をみるに、十分な検証をした上で「互換性がある」と太鼓<br>判を押せないものを勝手に配布されるのはいやだと思っていそうな感じもしま<br>すが。

_ matznaga (2004-07-10 13:00)

投票行動に対する動機について。<br>昔京都府知事選で候補者の一人が自社公共民相乗り、対立候補は神戸市長選のポスターをマジックインクで京都府知事選に書き換えたポスターを使っている、おまけに朝から土砂降りの雨。ってことがありました。おかげで確か当日の投票率は 15%程度。それでもちゃんと投票に行きましたけど。<br>まして、今回の状況は青木と言えども安心は出来ない状況であると思いたい。(と言いつつ富山は自民が取るんだろうな。でも明日は選挙に行くぞ。まあ四十九日の法要をすませてからだが)

_ soda (2004-07-11 00:23)

まつもとさん<br>> もし彼らがSunとライセンスを結ばず、ソースコードを流用せず、<br>> 商標も用いず、「非互換なJava」を提供していたら、Javaが<br>> オープンソースじゃなくてもsodaさんが予想する状況が現実化<br>> していたことでしょう。<br><br>これがまさに .NET なわけです。ソースをスクラッチからおこす<br>必要があったために出遅れて、今のところは、特にサーバーサイド<br>では、Java に差をつけられています。<br>しかし Windows が標準的に .NET を搭載して出荷する時代がきたら、<br>クライアントサイドは .NET に制覇される可能性が十分にあります。<br>そして、もし Java が最初からオープンソース・ライセンスを使って<br>いたら、Microsoft は一からソースを起こす必要がなかったわけです<br>から、出遅れもなかったわけです。<br><br>> オープンソースにすることで、ソースコードを流用した「フォー<br>> ク(非互換品)」を作りやすくなるのは事実かもしれませんが、実<br>> 際には、そういう事例はかなり少ないですよね。<br><br>非営利組織がメンテしている限りは、フォークしない方が開発<br>リソースが集中できるので、フォークしない方向にバイアスが<br>かかります。(それでも、仕様や実装で意見が対立するとフォーク<br>してしまうことがあるんですが。)<br>これに対し、複数の営利組織がメンテしている場合は、差別化を<br>計るため、改変を防ぐようにライセンスで制限しない限り、フォーク<br>する方向のバイアスがかかります。他社と同じものを売っていたの<br>では、付加価値がつけづらいわけですから。<br>UNIX で起きたのがまさにこれです。Sun は UI vs OSF の争いで<br>さんざん苦労してきたわけですから、同じ轍を踏むまいと考えて<br>しまうのは当然でしょう。<br><br>野首さん<br>> まあ FreeBSD の例をみるに、十分な検証をした上で「互換性がある」<br>> と太鼓判を押せないものを勝手に配布されるのはいやだと思ってい<br>> そうな感じもしますが。<br><br>実際のところ、Sun は無償配布される OS へのポーティングには、<br>非積極的だと思います。(理由は、おそらく複数あると思います。<br>営利企業としては、必ずしも間違った方針だとは言えません。)<br>FreeBSD は、そもそも Sun から検証を受けられるようになるまでで、<br>さんざん苦労していたようです。検証を受けられるようになったのは、<br>Sun 社内に FreeBSD に好意的な人がいて助けてくれたせいもあったん<br>じゃなかったかな… (かなり間接的な伝聞ですが…)<br>これは NetBSD も同じで、検証を受けたいんだけども受けられないと<br>いうことで、FreeBSD の Java チームの人に助けてもらってると<br>聞いたことがあります。(これも間接的な伝聞です。)<br>i386以外のアーキテクチャ向けの Linux では、こういう問題は出て<br>ないんでしょうか?<br><br>ですから、NetBSD を使っている私としては、Java がオープンソース<br>ライセンスになれば、こういう問題がなくなるので実際のところは<br>ありがたいんです。<br>でも、別にオープンソースにする必要もないんです。ライセンスは<br>現在のままで、もっと自由に検証を受けさせてもらえるだけで、今の<br>問題は解決します。<br><br>現在の問題を解決することを優先するのなら、Sun にとってより受け入れ<br>やすい解決策を探る方向に議論が行くと思うんですが、実際にはオープン<br>ソースか否かの二元論の議論しか見ないわけで、実際に困ってない人は<br>優雅でいいなあと思ったりしてしまうわけです。

_ soda (2004-07-11 01:18)

書き忘れましたが、ソースは公開されているので、<br>現在のままのライセンスでも移植作業はできますし、<br>実際、FreeBSDで行なわれた作業をベースにしたもの<br>が、NetBSDにも移植されています。<br>http://cvs.sourceforge.net/viewcvs.py/pkgsrc-wip/wip/jdk14/

_ Mr.orz (2004-07-11 14:31)

>「メンテナが望まないフォークが発生して、互換性を維持できなくなったケース」<br><br>正確には、メンテナ→オリジネータですね。<br>で「かつてあったか」→少なくとも著名なケースはない(と思います)<br>「今後あるか?」→可能性としてある以上、企業としては何らかの対策が必要かと(でないと経営責任になる)<br><br>GPLがフォークについての懸念を法的処置してないのに対して、たとえば、LaTexライセンスあたりはうまく処理していると思います。また昨年12月リリースのモノはデキもいいし。<br><br>> 苦労して開発したソースは秘密にしたい。それも結構だ。<br><br>という方向ではなく、ソースは公開するが改変についてはライセンスで一定の歯止めをかける(原則改変自由だが、不合理な非互換フォーク※を避ける)というのは可能です。<br><br>※わたくしは、非互換でも合理的なversion-up なら「やむなし」という考えです。

_ knok (2004-07-12 10:12)

i386以外のLinuxでの Java の状況というと、いくつかのベンダが<br>Sun の認定を受けてリリースしているようです。<br>初期の英語版 Zaurus には Insignia の Jeode というのが乗っていました。<br>しかし新しいものには Sun の PersonalJava が入っているようです。<br>もしかしたら作っているのは Metrowerks かもしれません。<br>このへんについては疎いです。<br><br>Debian 的には Moving Java to Main http://java.debian.net/ という<br>運動をしてる人達がいます。このへんで main に移動できているものは<br>多分 i386 以外でも動くと思います。

_ まつもと (2004-07-12 12:23)

まず、Mr.orzさんのコメントについては、12日の日記で触れるつも<br>りです。<br><br>sodaさん<br>>これがまさに .NET なわけです。ソースをスクラッチからおこす<br>>必要があったために出遅れて、今のところは、特にサーバーサイド<br>>では、Java に差をつけられています。<br><br>.NETが遅れたのは「ソースをスクラッチから起こす必要」のためで<br>はなく、「Javaではない、Microsoftにふさわしいクロスランゲー<br>ジプラットフォーム」の策定に時間がかかり過ぎたせいではないで<br>しょうか。オープンソースのJVMやJavaコンパイラの存在や、.NET<br>の仕様決定後のMonoやdotGNUのキャッチアップの速度から考えると。<br><br>おっしゃるように「Windows が標準的に .NET を搭載して出荷する<br>時代がきたら、クライアントサイドは .NET に制覇される可能性が<br>十分」にあるだろうとは思いますが、.NETはJavaとは互換性もない<br>ので、もはや純粋に異なるプラットフォーム間の競争に過ぎず、今<br>回の議論とは直接関係ないのではないでしょうか。<br><br>「非営利組織がメンテしているとフォークしない方にバイアスがか<br>かり、営利組織がメンテしていると(差別化のため)フォークする方<br>にバイアスがかかる」というのは確かにあるのかもしれませんが、<br>これも別にオープンソースかどうかとは関係のない話です。<br><br>むしろ、オープンソースソフトウェアでは差別化を行うため改良を<br>行いフォークを作っても、改良した部分を開示してしまえば安易に<br>取り込まれてしまうため、フォークによる差別化はかえって行われ<br>にくいと思います。<br><br>注目される存在には、常に「互換品」がつきまといます。Intel<br>に対するAMDやTransmeta、IBMに対する富士通、NECに対するエプソ<br>ン、Microsoft Officeに対するOpenoffice.org、KDEに対するGNOME<br>などなど。あるものは十分に互換性が高く、あるものは互換性が不<br>十分で問題が発生することもあります。これはオープンソースかど<br>うかとは関係がありません。<br><br>要するに、sodaさんの提示されたことひとつひとつは確かに正しい<br>ことでしょうが、私の述べている「オープンソースだからといって<br>互換性が減ることにはならない」ということとは直接関係せず、反<br>証ではないように思います。<br><br>>ですから、NetBSD を使っている私としては、Java がオープンソース<br>>ライセンスになれば、こういう問題がなくなるので実際のところは<br>>ありがたいんです。<br><br>Javaがオープンソースになっても、NetBSD対応の「修正版」が検証<br>を受けられなければ問題は残るのではないですか。Sunから配布さ<br>れる本体にNetBSD用のパッチが取り込まれない限り。オープンソー<br>スになろうがなるまいが、どのパッチを取り込み、どのプラット<br>フォームに対応するかどうかはメンテナが決めることですよね。オー<br>プンソース化されても、Sunは私みたいに安易にはパッチを取り込<br>まないような気がします。<br><br>>でも、別にオープンソースにする必要もないんです。ライセンスは<br>>現在のままで、もっと自由に検証を受けさせてもらえるだけで、今の<br>>問題は解決します。<br><br>上記のことがありますから、「sodaさんの問題」に対する解決策は、<br>オープンソース化では全然なくて「検証の自由化」なのでしょう。<br>そして、私はそのことについてはまったく扱っていません。検証の<br>自由化、されたらいいですね。<br><br>>現在の問題を解決することを優先するのなら、Sun にとってより受け入れ<br>>やすい解決策を探る方向に議論が行くと思うんですが、実際にはオープン<br>>ソースか否かの二元論の議論しか見ないわけで、実際に困ってない人は<br>>優雅でいいなあと思ったりしてしまうわけです。<br><br>私自身は「JDKがオープンソースになろうとどっちでも構わない」<br>し、「Sunがなくなっても困らない、さみしいけど」という人です<br>から、実際「優雅な困ってない人」です。<br><br>でも、Javaな人たちは優雅ではいられないでしょうから、ぜひとも<br>「Javaの諸問題の解決策は実は検証の自由化である」と声をあげる<br>べきではないでしょうか。あげてるのかもしれないけど。私は応援<br>します。私じゃ役に立ちそうにはないけれども。

_ mimi (2004-07-13 12:38)

オープン化してもしなくても互換性の問題はたいしたことはないと思われます。<br> ただ、オープン化する前より増える。増えた分をどう捕らえるか?<br> <br>互換性の問題はこんな感じで解決?されるのでは、<br>ある機能を実装する場合、A,B,,,,と複数の互換性のないものが乱立する。そして、そのうちひとつに集約される。<br>主流にならなかった実装を、中にはしばらく使う人もいる。<br>オープン化しなかった場合、この複数の実装が広まることがない(捨てられた実装を使い続ける人も当然いない)<br><br>メンテナが望んでいた実装がのこるかどうかは運しだい。<br>メンテナが捨てられて実装にこだわれば、互換性を維持できなくなるケースになるのかな?

_ soda (2004-07-15 23:10)

だいぶ間が空いてしまいましたが(すいません)、こっちに<br>書きます。<br><br>松本さん:<br>> .NETが遅れたのは「ソースをスクラッチから起こす必要」のためで<br>> はなく、「Javaではない、Microsoftにふさわしいクロスランゲー<br>> ジプラットフォーム」の策定に時間がかかり過ぎたせいではないで<br>> しょうか。<br><br>それも理由の一つとしてあるでしょう。<br>でもJava が最初からオープンソースだったら、スクラッチから<br>JVM その他を書き起こすのと比べて、Microsoftははるかに簡単に<br>フォークすることができ、しかも訴訟で負ける危険は少なかったと<br>いう点に変わりはないですよね?<br><br>> むしろ、オープンソースソフトウェアでは差別化を行うため改良を<br>> 行いフォークを作っても、改良した部分を開示してしまえば安易に<br>> 取り込まれてしまうため、フォークによる差別化はかえって行われ<br>> にくいと思います。<br><br>それはオープンソースというよりGPLの話ですね。BSD系ライセンス<br>では、改良の開示の必要はありませんから、これは成り立ちません。<br>もちろん、SunがJavaに関してGPLを使うという選択肢はありますし、<br>もし実際にオープンソースライセンスを用いるなら、GPL的なソース<br>開示条項をつけて、かつ(Qtのように)クローズドなデュアルライセンス<br>にするというのは、良い手だと思います。この場合、おそらくMicrosoft<br>によるフォークは阻止できるのではないかと思います。しかし、IBM<br>あたりがGPLの元でフォークを試みたとしたら、阻止できない可能性が<br>十分あるというのが個人的意見です。<br><br>> 要するに、sodaさんの提示されたことひとつひとつは確かに正しい<br>> ことでしょうが、私の述べている「オープンソースだからといって<br>> 互換性が減ることにはならない」ということとは直接関係せず、反<br>> 証ではないように思います。<br><br>うーん、残念ながらここは同意に至ることはできそうにないですね。<br>松本さんが書かれていることは、どれも「オープンソースであって<br>もフォークしないことがある」ということに過ぎないように私には<br>思われます。それではSunの求める「フォークを全くしない」という<br>ことの証明には不十分であるというのが私の意見です。<br><br>> Javaがオープンソースになっても、NetBSD対応の「修正版」が検証<br>> を受けられなければ問題は残るのではないですか。Sunから配布さ<br>> れる本体にNetBSD用のパッチが取り込まれない限り。オープンソー<br>> スになろうがなるまいが、どのパッチを取り込み、どのプラット<br>> フォームに対応するかどうかはメンテナが決めることですよね。オー<br>> プンソース化されても、Sunは私みたいに安易にはパッチを取り込<br>> まないような気がします<br><br>ここは誤解があるようです。<br>まず、Sun から配布される本体にNetBSD用のパッチが取り込まれる<br>ことは特に期待していません (もちろん、取り込まれることは<br>大歓迎ですが)。<br><br>問題は、現状では、NetBSD ネイティブの Java 実行環境が、<br>バイナリの形で再配布できないことにあります。<br>オープンソースライセンスになるか(この場合、勝手にバイナリを<br>作って再配布できます)、あるいは検証を通れば(この場合、検証を<br>通ったバイナリを再配布できます)、この問題は解決します。<br><br>mimiさん<br>> メンテナが望んでいた実装がのこるかどうかは運しだい。<br><br>そうなんですよね…<br>なんでもそうなんですが、良く練られた仕様だから広まるとは<br>限らず、むしろ求められたタイミングで世に出たものの方が、<br>正しくなくても広まることが良くあります。<br>これに関して Lisp コミュニティの立場から反省的に書いた<br>文書として、Richard Gabriel による The Rise of "Worse is Better"<br>があります。<br>和訳: http://cl.aist-nara.ac.jp/~daiti-m/text/worse-is-better-ja.html<br>Richard Gabriel は、Lucid にいたころ Emacs と XEmacs のフォーク<br>を、当事者として体験しています。(Lucid は、XEmacs の変更点を<br>FSF に寄贈しようとしたんですが、バッファの構造に関する技術的な<br>論点で合意が得られず、フォークを余儀なくされました。)<br>また、Richard Gabriel は Java 言語のデザイナの一人でもあり、<br>Java で用いられている Sun Community Source License のポリシーを<br>定めた人物でもあります。<br>http://wwws.sun.com/software/communitysource/principles.html

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

sodaさん<br>>でもJava が最初からオープンソースだったら、スクラッチから<br>>JVM その他を書き起こすのと比べて、Microsoftははるかに簡単に<br>>フォークすることができ、しかも訴訟で負ける危険は少なかったと<br>>いう点に変わりはないですよね?<br><br>「もし仮にJavaが最初からオープンソースだったら」という話は、<br>変数が多すぎて有意義な推測はできないと思いますし、正直、あん<br>まり興味が持てません。オープンソースにした場合にどのライセン<br>スを選んだかでも変わるでしょうし、その歴史においてSunと<br>Microsoftがどのようなライセンス契約を結んだのか、あるいはそ<br>もそも結ばなかったかも分かりませんし。<br><br>私が関心があるのは、現在の状況でSunがJDKをオープンソース化す<br>るとしたら、障害となる問題はなにか、です。で、Sun自身は「互<br>換性」と言っているようなのですが、個人的にはそれは疑っていま<br>す。つまり、<br><br> * オープンソース化によって「Java言語の互換性」が守れなくな<br> ることはない。実装(JDK)をオープンソース化しても、言語の<br> 互換性を維持する別の手段が用意できる(標準とか認証とか)。<br><br> * 上記の互換性維持の努力にかかわらず、実質的にJavaの互換性<br> を損なうためには、「SunのJava」とは微妙に挙動の異なる別<br> 実装が普及すれば良い。それには「SunのJDK」がオープンソー<br> スである必要はない。<br><br> * オープンソース化によって、技術的にはフォークが作りやすく<br> なるのは事実だが、適切にライセンスを選択すればオープンソー<br> スであってもそのような問題のほとんどは解消できるだろう。<br><br>ということから、現時点でJDKをオープンソース化しても、「Java<br>言語の互換性」の問題は増加しないと思っています。<br><br>JDKをオープンソース化しなかった場合の問題は、私よりもsodaさ<br>んの方がご存じですよね。Sunがその問題を気にするかどうかはと<br>もかくとして。<br><br>>松本さんが書かれていることは、どれも「オープンソースであって<br>>もフォークしないことがある」ということに過ぎないように私には<br>>思われます。それではSunの求める「フォークを全くしない」という<br>>ことの証明には不十分であるというのが私の意見です。<br><br>私の言いたいことは「オープンソースであってもフォークしないこ<br>とがある」ではなくて、「フォークしても問題が起きる可能性は十<br>分少ない(or 少なくできる)」です。同じことに聞こえますか。<br><br>ところで、Sunは「(JDKからの)フォークを全くしない」ことを求め<br>ているのですか。「Sunのソースコードに基づいたフォークを完全<br>に禁止する」ためにはソースコードを公開しない、あるいは修正し<br>たソースコードの再配布を禁止するしかないでしょう。<br><br>私はSunが求めているのは「Java言語の互換性」だと思っていまし<br>た。また、「フォークをしない」ことと「言語の互換性」の違いを<br>理解できる程度には賢明であると。私はSunに対して過大な期待を<br>していたのでしょうか。

_ soda (2004-07-16 02:01)

> * オープンソース化によって「Java言語の互換性」が守れなくな<br>> ることはない。実装(JDK)をオープンソース化しても、言語の<br>> 互換性を維持する別の手段が用意できる(標準とか認証とか)。 <br><br>標準化は、それに参加する団体すべてで合意ができるという<br>前提が成り立たないと不可能です。<br>また、たとえ標準化に成功しても、今度は標準化されてない<br>部分での拡張の競争が始まるわけで、標準化だけで完全な互換性が<br>得られることはありえません。<br>今回の改訂を見ても、Java言語の機能には、まだ大きな変動が<br>起きているわけで、そういう時代には、むしろ互換性のない<br>拡張の間で競争が起きる方が自然です。(特に差別化をしたい<br>企業の間では)<br><br>また、認証は互換性を保つ手段としては非力です。<br>オープンソースライセンスのもとでは、認証で得られるのは<br>せいぜい商標程度ですから、商標よりも強力なマーケティング<br>手段のある組織は、単に認証を無視すれば良いだけです。<br>また、認証を受けている場合も、認証ソフトウェアの検証機能外の<br>拡張機能については野放しになります。<br><br>> * 上記の互換性維持の努力にかかわらず、実質的にJavaの互換性<br>> を損なうためには、「SunのJava」とは微妙に挙動の異なる別<br>> 実装が普及すれば良い。それには「SunのJDK」がオープンソー<br>> スである必要はない。<br><br>松本さん自身が書かれている通り、オープンソースにすると、<br>フォークが起きやすくなるのが、Sun から見た問題点なわけです。<br><br>> * オープンソース化によって、技術的にはフォークが作りやすく<br>> なるのは事実だが、適切にライセンスを選択すればオープンソー<br>> スであってもそのような問題のほとんどは解消できるだろう。 <br><br>ここは賛成できません。<br>GPLにしてもBSDライセンスにしてもフォークは実際に起きている<br>わけで、オープンソースライセンスである限り、(改変の自由と<br>再配布の自由を保証する必要がありますから) ライセンスによって<br>フォークを防ぐことは不可能でしょう。<br>もちろん、オープンソースではないライセンスなら、直接の派生で<br>あるソフトウェアに関しては、フォークを防ぐことが可能です。<br><br>> 私の言いたいことは「オープンソースであってもフォークしないこ<br>> とがある」ではなくて、「フォークしても問題が起きる可能性は十<br>> 分少ない(or 少なくできる)」です。同じことに聞こえますか。 <br><br>私は、フォークしたプロジェクト間で厳密に互換性が保たれている<br>例を全く知りませんから、「問題が起きる可能性は十分少なくできる」<br>とは思いません。<br>標準化に成功しているソフトウェアであっても、標準化の範囲外での<br>互換性のない拡張は当然あるわけですし。<br><br>> ところで、Sunは「(JDKからの)フォークを全くしない」ことを求め<br>> ているのですか。<br><br>上でも書いた<br>http://wwws.sun.com/software/communitysource/principles.html<br>を見てもお分かりいただけると思いますが、Java のライセンスの<br>主要な目標の一つとして「There is clear control over compatibility.」<br>があるのは間違いありません。この文書は単なる政治屋が書いたもの<br>ではなく、Richard Gabriel と Bill Joy という生粋のハッカーが<br>書いた文書ですから、信用していいと思います。<br>なお正確に言うと、フォークに関しては、ライセンスに基づく限り<br>自由です。例えば研究目的で実験的拡張をするのなら、今のライセンスでも<br>何の問題もないと思います。<br><br>> 「フォークをしない」ことと「言語の互換性」の違いを理解できる<br>> 程度には賢明であると。<br><br>たぶん、松本さんがここで求めてる互換性というのは、「標準化された<br>範囲内での互換性」なんでしょう。それに対し Sun が求めている<br>互換性は、「標準範囲外で、複数の異なる機能拡張が広まることがない<br>厳密な互換性」なんでしょう。後者の互換性については、オープン<br>ソースライセンスにしないことが、今でもまだ役に立ちます。<br><br>> 私はSunに対して過大な期待をしていたのでしょうか。 <br><br>Richard Gabriel と Bill Joy は、ともにプロジェクトのフォークで<br>痛い思いをしているわけですから (Richard Gabriel の場合は、<br>XEmacs 以前の Lisp の時代にも、フォークとその後の Common Lisp<br>仕様の策定で大変な苦労をしています)、これまでの経験の違いで<br>フォークに対する姿勢が違うんだと思います。

_ まつもと (2004-07-16 10:44)

sodaさん<br>>たぶん、松本さんがここで求めてる互換性というのは、「標準化された<br>>範囲内での互換性」なんでしょう。それに対し Sun が求めている<br>>互換性は、「標準範囲外で、複数の異なる機能拡張が広まることがない<br>>厳密な互換性」なんでしょう。後者の互換性については、オープン<br>>ソースライセンスにしないことが、今でもまだ役に立ちます。<br><br>私の求めている互換性についてはその通りです。<br><br>「標準範囲外で、複数の異なる機能拡張が広まることがない厳密な<br>互換性」なんてものはそもそも不可能ではありませんか。「今でも<br>まだ役に立つ」とおっしゃるのは、フォークの発生を禁止できれば<br>独立した実装を作るためにはコストがかかるから、というのが理由<br>だと推測しますが(それ以外の理由は思いつかない)、現在ではSun<br>のソースコードを流用しないJDK相当は揃ってきている(と私は思っ<br>ている) ので、やる気がある人(または企業)がいればフォークが発<br>生しなくても互換性問題は起きうるはずです。<br><br>現時点のJavaに関して言えば、<br><br> * JDKのソースコードを既に公開していて<br> * オープンソースでないために問題が発生していると感じている<br> 開発者がある程度存在していて<br> * オープンソースにしてもしなくても「互換品」の危険性は大差<br> ない<br><br>ので、オープンソースにするリスクは小さくなっているように思い<br>ます。「最初からJDKをオープンソースにすべきであったか」とか、<br>別の前提の議論なら違う話になるかもしれませんが。<br><br>確かに別実装(フォークであるかどうかに関らず)が発生すると「標<br>準範囲外の互換性」までは維持できないので、できれば存在しなけ<br>れば良いという気持ちは理解できますし、別実装の登場を遅らせる<br>ためにオープンソースにしないと言う戦略が有効な局面もあると思<br>います。が、現在のJavaはそういう状況ではないのではないでしょ<br>うか。<br><br>後は、Sunが「オープンソース化を望むユーザの声」とか「大差な<br>い(が小差はあるかも)」とかをどう評価するかですよね。<br><br> ------------<br> <br>将来Javaに限らない「オープンソース一般と互換性の問題」につい<br>て考える人のために、念のため書き添えておくと、Javaは「write<br>once, run everywhere」という標語を守るため、互換性に対しての<br>要求が特に厳しいのですが、一般のソフトウェアについていえば、<br>かなり厳しい互換性が問われるケースでもどこまでが「互換性が保<br>証されている範囲か」が定義されていれば、それをはみだすものが<br>あってもさほど問題にはならないと考えています。

_ soda (2004-07-16 22:38)

> というのが理由だと推測しますが<br><br>そうです。<br><br>> やる気がある人(または企業)がいればフォークが発生しなくて<br>> も互換性問題は起きうるはずです。<br><br>もちろんそうです。<br>そして「役に立つ」というのは、この問題が発生するのに必要な<br>労力が増える/敷居が高くなるという意味で、役に立つという<br>意味です。<br><br>> 後は、Sunが「オープンソース化を望むユーザの声」とか「大差な<br>> い(が小差はあるかも)」とかをどう評価するかですよね。 <br><br>まず、「オープンソース化を望むユーザ」が、なぜそう望んでいる<br>のかを知る必要があるんではないでしょうか。再配布が必要ないので<br>あれば、ソースを改変したいという要求には現状のライセンスのまま<br>で答えられます。<br>また、NetBSD ユーザのように、再配布を必要としている場合に<br>ついても、検証を簡単に受けられるようにすれば、ライセンスを改変<br>することなく、対応できます。<br>Java 言語の正式な仕様策定に関わりたいというユーザは、<br>Java Community Process (www.jcp.org) に参加すれば可能ですから、<br>ライセンスの問題とは独立しています。<br>(どういう参加の仕方をするかによって、できることは変わるようですが)<br><br>結局、オープンソース化を本当に必要としているユーザというのは、<br>検証に通らなかったり、あるいは独自の拡張機能を持っていたりする<br>版を再配布したいユーザのように思われます。<br>それはすなわち、Sun が避けたい非互換性をもたらすユーザでは<br>ないでしょうか。

_ まつもと (2004-07-17 01:39)

オープンソース化しなくても、現状でもそれに近いメリットをすで<br>に提供している、ただ検証をもっと自由化してほしい、というのが<br>sodaさんの意見なのだと読みました。その気持ちは理解できます。<br><br>しかし、オープンソース化して欲しい理由と言うのはそれぞれなの<br>で、「結局、オープンソース化を本当に必要としているユーザとい<br>うのは、検証に通らなかったり、あるいは独自の拡張機能を持って<br>いたりする版を再配布したいユーザ」であり、「すなわち、Sun が<br>避けたい非互換性をもたらすユーザ」という結論はあまりに早急な<br>のではないでしょうか。<br><br>たとえば、別に非互換な仕様を広めたいと思っているわけでなくて<br>も、JCPに提出するための仕様を実験するため、JDKを改造し、広く<br>試してもらおうと思えば再配布が必要になります。また、Sunにとっ<br>ては想像したくもないかもしれませんが、Sunに万が一のことがあっ<br>てもJavaのソースコードへのアクセスが保証されるのは開発者にとっ<br>て安心感を提供できるかもしれません。<br><br>まあ、私としてもオープンソース化することによって「Sunに直接<br>メリットがある」とは思っていませんので、Sunがとるべき選択に<br>ついてどうこういうつもりはありませんが。<br><br>とはいうものの、SunはSolarisをオープンソース化すると発表して<br>おきながらその後具体的なプランを出してきていないとか、Javaの<br>オープンソース化は拒否しておいてJava Enterprise Systemのオー<br>プンソース化計画を明らかにしたりと、行動が一貫していないよう<br>に感じます。これはSunという企業が、「オープンソースの波」に<br>乗ろうか乗るまいか迷っていることの現れではないでしょうか。そ<br>のような躊躇の「言い訳」として使われている「互換性」をそれほ<br>ど真正直にとらえるのもどうかと思います。<br><br>私としては、この一件で人々が「オープンソース化すると互換性の<br>問題が発生する」という印象を持つのは避けたいと思っていますか<br>ら、そこについてだけはこだわりたいと思っています。

_ soda (2004-07-17 02:48)

> SunはSolarisをオープンソース化すると発表しておきながらその後<br>> 具体的なプランを出してきていないとか、<br><br>この方針決定はたかだか一ヶ月ほど前の話ですから、現時点でどうこう<br>いうのは、まだ早いと思います。Solaris に関しては、SCO や Novell<br>の持つ UNIX ソースライセンスとのからみがありますから、Sun だけ<br>で決められる話ではないですし。<br><br>> Javaのオープンソース化は拒否しておいてJava Enterprise System<br>> のオープンソース化計画を明らかにしたりと、行動が一貫していない<br>> ように感じます。これはSunという企業が、「オープンソースの波」に<br>> 乗ろうか乗るまいか迷っていることの現れではないでしょうか。<br><br>たとえば IBM も、JFS や RCU をオープンソースにしながら、DB2 や<br>AIX 本体に関しては全くそういった動きを示してないわけですが、<br>IBM も行動が一貫しておらず、迷っている最中なのでしょうか?<br><br>営利企業の場合、オープンソースにするメリットがあるかないかを、<br>個々の製品ごとに評価するのは当たり前ですから、それをもって<br>一貫してないと考えるのは、おかしいと私は思います。<br><br>オープンソース化しているソフトウェアの量から言えば、IBM よりも<br>Sun の方がはるかに多いのに (例えば OpenOffice は、それ単体だけで<br>JFS や RCU などを合わせたものよりもはるかに巨大なサイズです)、<br>なぜか世の中では IBM より Sun に対する風あたりの方が大きいみたい<br>です。おそらく、単に PR 能力の点で IBM が優れてるってことなん<br>でしょうけど。

_ まつもと (2004-07-17 09:47)

sodaさん<br>>なぜか世の中では IBM より Sun に対する風あたりの方が大きいみたい<br>>です。おそらく、単に PR 能力の点で IBM が優れてるってことなん<br>>でしょうけど。<br><br>その点には同意します。<br>Sunの今後を見守ります。

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

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

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