私自身はビル・ゲイツをはじめとするマイクロソフト幹部がオープンソースを目の敵にするのを見て、 「意見は異なるが気持ちは分かる」と思ってきた。 彼らにとってはオープンソースと言うのは都合が悪いので、反発するのは当然だ。 彼らに対して別に怒りは覚えない。
しかし、このマクニーリーの発言は、もし伝えられている通りならば、かなり強い反発を覚える。
自らは「オープン」であることの重要性を唱えながら、
「顧客は互換性を求めている。彼らのだれひとり、オープンソース化を望んでいない。単にメディアが騒いでいるだけ」とマクニーリー氏は一蹴する。
という発言には、オープンソース化がもたらすもの、 すなわち「自由」の重要さはまるで眼中にないようだ。
しばらく前、専制君主はこう言ったであろう。
「臣民は賢明な統治を求めている。彼らのだれひとり、民主主義を望んでいない。」
そういう主張ならそれはそれで構わない。が、それなら自由の擁護者のような顔をしないでほしい。
追記:
通りすがりさんのツッコミ:
規格をオープンにする，という意味でのしばらく前に流行った「オープンシス テム」のコミュニティの盟主だと主張するのだったら，理解できるような気が します．
どうなんでしょうね。少なくとも「オープンソース」の「オープン」じゃないことは確かですが。
なんたって
ジョナサン・シュワルツ社長兼COOに言わせれば、MicrosoftはWindowsでデスクトップを支配し、Red Hatは「トリッキーな手」でLinuxを支配する、どちらもプロプライエタリな技術のベンダー。仕様を公開し、さまざまな実装の登場を促して市場を拡大してきたSunとは相容れない存在だ。
とおっしゃるわけだから。
あるいは、仕様をオープンにすることは「オープン」だが、 実装をオープンにすること彼らの定義では「オープン」ではない、とか。 実装オープンじゃ「さまざまな実装の登場を促す」ことにはならないものな。 そりゃ、Sunとは相容れないかも。
うーん、そんな会社じゃなかったと思ってたんだけどなあ。
ところで「トリッキーな手」ってどんな手？
追記2:
個人的には↓の意見に賛成。
http://diary.imou.to/~AoiMoe/2004.07/early.html#2004.07.02_s02
まぁ、Sunの発言にいろいろ突っ込みどころがあるのも事実ではあるのですが……。
Sunが「オープンシステムの盟主であった」ことは肯定します。 個別の企業にはそれぞれの折り合いの付け方があることも。
私はただ、かつてオープンシステムの盟主であったSunが、 オープンソースの波には乗り損ねて、 なお「オープンコミュニティの盟主」をアピールするのを揶揄しているだけですから。
乗り損ねたのなら(あるいは乗りたくないなら)、乗らなければ良い。 むしろマイクロソフトのように積極的にオープンソースに対立してくれた方が、潔い印象があります。
私は今はSunの顧客じゃないんで、それ以上は断言できませんが、 Sunのトップが「顧客は互換性を求めている。彼らのだれひとり、オープンソース化を望んでいない。単にメディアが騒いでいるだけ」と叫ぶのを聞いて、多くの人が思うのは、「ああ、そうか。Javaのオープンソース化は不要なんだ」じゃなくて、「ああ、そうか。SunはJavaをオープンソース化したくないんだ(理由は知らんけど)」じゃないかと感じます。
むしろ、そんな発言は顧客の声を本当に聞こうとする企業のトップからは聞かれないんじゃないかと思うので、 私はかえって「Sunは本当に顧客の声を重視しているのかな」という印象も持ちます。 確かに薄い根拠しかないですが、あくまでも印象ですから。
この記事を読んで、積極的にSunの顧客になりたいと思うようになった人って、いないんじゃないかなあ。 もちろん、記事というフィルタのせいであることは否定できませんが。
勢いのなくなった企業トップの発言は、SunにしてもSCOにしても、ツッコミどころ満載で読むのが楽しいものです。 SunとSCOを一緒にしたら迷惑に思うかもしれないけど(どっちが？)。
論文も書いてないのに、こんなことしてていいのか、という気持ちを感じつつも、 メールオーガナイザーのバックエンドの設計はできたみたい。
結局、インデックス登録はEstraierを直接使い、 検索は適当なAPIがないので、QDBMを使うということになった。
その他に、インデックスデータベース、スレッドデータベース、ラベルデータベースが必要だが、 これらもQDBMを使う。
これから実装だな。(Emacsの)フロントエンドは手つかずだから先は遠いなあ。
うちでヒマそうにしていた下の二人の子供を連れて、山奥の公園に。
この公園は、ちらほらと遊具が置いてあり、かつ、近くのたんぼではおたまじゃくしなどが見れるので、 なかなか面白いスポット。子供たちもはしゃいでいた。
するとたんぼでコオイムシを見つけた子がいた。 私は街中で育ったので、あまり虫などをつかまえたりしなかったので、 実物を見たのは初めてだ。確か、絶滅危惧種だったような気がしたので、 観察した後、そっと逃がしてやった
うちに帰って調べてみると、山口県では準絶滅危惧扱い、広島では20年ぶりに見つかって新聞記事になっている。ほとほと田舎に住んでいるものだ。
現実逃避は続く。いやあ、さすがにあらかじめさんざん考えていただけに、さくさく実装できる。 今日だけでメールの取り込みプログラムはほとんど完成した。
もっとも、最重要なのは以下にいかにメールを表示し、検索するかという点なのだが。
ところで、Rubyである程度以上の規模のアプリケーションプログラムを書くのはすごい久しぶりな気がする。
CNET Japanより。
SunはJavaをオープンソースにするかどうかで悩んでいるらしい。
Javaの生みの親で同ソフトを管理しているSunは、Javaをオープンソース化することにより、同ソフトにとって最も重要な互換性が損なわれるのではないか、との懸念を表明している。
その根拠は
Sunは、JavaにUnixやLinuxと同じ轍を踏ませたくないと考えている。両ソフトは管理が甘かったため様々な亜種が誕生し、結果的に両者の互換性は失われてしまった。
SunのバイスプレジデントでJavaの主要な開発者であるJames Goslingは、JavaOneで行なわれた議論の中で、「私はUnix戦争を生き延びた」と述べ、さらに「私はLinuxの細部に至るまで全てを愛しているが、Linuxは再び同じ問題に直面している。これまでに数多くのLinuxディストリービューションが開発され、互いに大変似てはいるものの、それぞれ異なっており苛立ちを覚える」と語った。
なのだそうだ。
では、少々考察してみよう。仮にSunが持つJavaをオープンソース化することに対する懸念は「互換性が損なわれる可能性」だけだとする。ほんとは違うかもしれないけど。
まず、オープンソース化しなければ、Sun以外の要因による互換性問題は発生しないのか。
Sunのプロダクトにおいては確かにその通りだが、今やJavaに関連する技術は数多くあり、 その中の多くはSunによってコントロールされていない。 しかし、顧客の求めている互換性は、Sunのプロダクトの範囲でだけ互換性が維持されているかどうかではなく、 Javaに関連するテクノロジー全体での互換性ではないだろうか。 それらに互換性の問題が発生するかどうかは、Sunだけの努力では制御不能だ。
よって、互換性が維持できるかどうかは、コミュニティ全体が互換性に対してどれだけコミットしているかどうかで決まり、オープンソースであるかどうかによっては決まらないように思う。
次に、オープンソース化すると互換性の維持に必要なコミットメントが増大するかどうか考えてみよう。
彼らの反論ではUnixやLinuxはそのような例だという。本当にそうか。
まず、Unixについてだが、これらは元々オープンソースではなかった。 初期のUnixはAT&Tとライセンスを結ばなければ利用できなかったし、 詳しい事情は識者に任せるが、System VとBSDの「分裂」を産んだのも、オープンソースが原因ではなかったと思う。
またUnix間の非互換性を増大させたのは、 SunのSunOS、IBMのAIX、DECのUltrix、HPのHP-UXなど各種ベンダーによるソースが公開されなかった独自の拡張によるのではないか。すくなくともこれをもって「オープンソースが非互換性を増長させる」という結論は得られない。
では、Linuxはどうか。ここでの互換性は、
これまでに数多くのLinuxディストリービューションが開発され、互いに大変似てはいるものの、それぞれ異なっており苛立ちを覚える
ということなので、カーネルのバージョン間の互換性ではなく、 ディストリビューション間の違いであるとする。
当初、Linuxのカーネル以外の部分はまったく標準化の努力が行われていなかった。 なんとなく伝統的なUnixっぽいファイル階層やブートシーケンスが採用されていたので、 ディストリビューションごとに多くの違いがあったのは事実だ。
しかし、これはLinuxというものがオープンソースであったことが原因というよりは、 むしろ互換性のための動機づけや努力が希薄であったことを示すだけではないだろうか。 FHS(File Hierarchy Standard)などが定義された現在では、本質的な違いは少なくなっていて、 ディストリビューションの違いはパッケージセットや管理ツールの違いであり、 一般に「差別化」と呼ばれる好ましい違いに収まりつつあるのではないだろうか(まだ不完全かもしれないが)。
最後にプロジェクトの分裂についても考えてみよう。 オープンソースプロジェクトはプロジェクトの分裂を禁止することはできない。 しかし、分裂したプロジェクトのうち、どちらが選ばれるかは信頼によって決まると思う。
今までSunがJavaに対してしてきたことは、おおむね信頼にあたると多くの人が考えているのではないだろうか。 では、だれかがJavaを「奪おう」としても、Sunが引き続き信頼に足る行動を続けている限り、 たとえオープンソース化しても、SunのJavaの地位は安泰ではないだろうか。
SunにはSunの資産を自由にする当然の権利があり、 また、私はJavaがオープンソース化されようと、されまいとどっちでもよいのだが、 SunはJava自身を売っているわけではなくて(確かそうだよね？)、 また契約さえすればソースコードも無償で配ってるはずなので(確かそうだよね？)、 オープンソース化しないのは「無駄な抵抗」に見える。
となると、最初に否定した「互換性への懸念」以外の真の理由があるんじゃないかと考えちゃうんだが、 邪推のしすぎかなあ。
追記:
まとめると、
上のCNET記事にトラックバックしようとしたが失敗したようだ。 トラックバックリストに反映されない。www.rubyist.netの引っ越しのときにトラックバック機能に問題が発生したか、とも思ったが、「Matzにっき」自身へのトラックバックは成功する。なんだろう？
元々Sunって会社は「互換性命」というタイプの会社じゃない。
ハードウェアについて見れば、Sun3(モトローラ)からSun4(Sparc)では全然違っていた。 同じSparcアーキテクチャでもsun4cとかsun4mとかあって互換性はなかったように思う。 Sun1やSun2は実機を見たことはないけど、ハードウェア互換性があったとは思えない。
ソフトウェア(OS)はもっと顕著で、まるっきりBSDだったSunOS 3.xから、 なんとなくSystem V風味のSunOS 4.xに変わった時には、私を含めて多くの開発者が不満を覚えたものだ。 しかも、SunOS 4.xはバージョンが進むたびにBSDから遠ざかっていった。
しかし、我々は甘かった。Solaris(SunOS 5.x)が登場した時に、 SunOS 4.xはまだBSDっぽかったんだなあとふりかえることになろうとは、想像もできなかったのだから。
私はかつてそういう「酷い目」にあったものだから、Sunから「互換性重視」という言葉を聞いて、 どういう風に思ったらよいのか迷っている。
どうしても後者の受け取り方をしてしまうのか恨み節だろうか。
ま、私自身はほんとは互換性をそんなに重視するヒトじゃないし*1、 SunOSの変化についての文句は「互換性がなくなったから」じゃなくて、 「自分の好みじゃない方に変化したから」なんだけど。
互換性と言えばIBMだろう。ソフトウェアプラットフォームとしての汎用機の寿命は半端じゃない。 使いたいかと言われれば、それは違うと答えるけど。
*1 Rubyを見れば分かるか
mimiさんからのツッコミをいただいたが、 十分に理解できた自信がない。
オープンソース化されれば、差別化、重視になるでしょう。
一部のコミュニティが互換性を無視することに対してコミットして、互換性は失われる方向になる。
オープンソース化すると、誰にも互換性の維持はできない。
と考えています。
分からなかったのは、
という点だ。
前者についていえば、あるオープンソースプロジェクトに対して「差別化を行う」ということは、 差別化できる存在を新たに作る、すなわちフォークを意味すると思われる。 それ以外の差別化はオープンソースであるなしに関らず発生するからだ。 しかし、実際にはフォークはめったに起きないし、 起きたとしてもどちらのプロジェクトが「正当」であるかは明らかなので、 互換性を重視する人がどちらを選ぶかは明白だ。
後者については、「コミュニティの一部が互換性を無視することに対してコミットする」という表現は、 やはりフォークを想起させる。 たとえオープンソースであろうとも、プロジェクト管理者(JavaならSun)が望まない修正は取り込まれないし、 ローカルパッチは決して広く受け入れられないからだ。 結局はフォークを心配しているのね。 しかし、上に述べたように、フォークは重大な問題ではありえない。
想定できる問題として「互換性はないが、より優れたフォーク」が登場した場合に 発生しうる混乱があるが、これは心配しなくてもいいんじゃないかなあ。 フォークが発生したとしても、まずフォークした方は長期的には生存できないと思う。 Sunやその他の人々がJDKに注力しているリソースを考えると、 それを越えるのは容易ではないし、そんなことを考えるのはマイクロソフトくらいだ。
それもArtisticライセンスのようにプログラム名を担保するとか、登録商標を駆使するとかで、 少なくとも「Javaの名前」は守れるだろう。 名前が違ってしまえば、それは「Javaに似たなにか」であり、 違うものであるのでそもそも互換性は問題ではない(それがC#か)。
多くのオープンソースプロジェクトが互換性を重視していないのは事実だが、 それはそれだけのコストを払っていない(払いたくない)からであって、 オープンソースだからではない。 Sunは互換性維持のためにこれまで十分コストを払ってきたと思うし、 その努力にはオープンソース化してもあいかわらず有効だと思う。
と、いうことで楽観的な私の結論は、
である。
mimiさんには「オープンソース化すると、誰にも互換性の維持はできない」という結論を出す 論拠なり、実例なりがあるのだろうか。 Javaくらいのプロジェクトだとフォークが頻繁に起きることが予想できる理由がある、とか。
それから、現状のJDKはGosling自身の言葉のように
「われわれは、(Javaの)ソースコードをコミュニティーに提供することで、多大な恩恵を受けている。唯一の難点は、ライセンス条件が一部の人が望むより、少し面倒だという点だ」
であり、ソースコードは入手可能で、ライセンス上の問題以外はオープンソースとさして変わりはない。 もっとも、その問題が重要だと考える「開発者」は多いだろう。 逆に上記のHotWiredが声を聞いた「ユーザ」にとっては技術上の些細な点に過ぎない。
私は、この「ライセンス上の面倒」の解決は、 Sunにとって大きなメリットがあり、デメリットはほとんどないのではないか、 と私は思うんだけど、どうなんだろうねえ。
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)をオープンソース化した方が良いと思う理由をリストしてみよう。
というわけで、たいしたコストなしに進歩を加速できるメリットがあると思うんだが。
KLさんは「実態で負けていては」とおっしゃるが、 それはオープンソース化してもしなくても同じことだと思う。
だが、仮にSunが「将来、Java(JDK)を商品にしたい」思っていたとしたら、 オープンソース化に抵抗があるかもしれない。 商用版を出したとたんに、 オープンソース版からフォークが発生するのを止められないから。 これが隠された真の理由だったりして。
ただ、それはあまり賢明な判断には思えないなあ。 まず売れないし(「言語ビジネスは死屍累々」を思い出そう)、 ブランドイメージは傷つくし、 それに結局オープンソースな別実装の登場を禁止することはできないし(既にあるし)。
結局は「勢いのない」Sunにとって、 「Javaのオープンソース化によってSunが経営的に生き延びる確固たる見込みがある」かどうかが、 選択の分かれ目だろう。 でも、Sunの現状は構造的なものだからねえ。
Java関連ってSunの売り上げのどのくらいを占めているんだろう。 たぶん、微々たるものだと思うのだが。 だから、Javaをオープンソースにしても、しなくても、状況が厳しいことには変わらないんじゃないかな。
だったら、むしろ積極的にオープンソースを前面に出してブランドイメージの改善を図った方が....。
ここまでこじれてからだと難しいかな。
Sunが潰れるとさみしいな、困りはしないけど。この「困らない」ってのがSunの現状を反映してそう。
全部で1000行ほどか。結局、Estraierの検索はRubyだけで実現できず(そりゃそうだ)、 Cでちょっとした(150行ほど)拡張ライブラリを書く必要があった。あとはSimilarity Searchは手つかずだけど。 これは特徴的単語の抽出が思ったよりも難しかったので、後回し。
ところで、EstraierってMIME文書のサブジェクト(title属性)とか差出人(author属性)とかは、 検索の対象にならないのね。メール検索としては、かなり使い勝手が悪い。 あんまり、ローカルハックをしたくはないんだけどなあ。
とかいってると、平林さんが新しいバージョンをリリースしてくださるかも。
昨日、Estraierでauthor属性の検索ができないとか書いたら、 さっそく平林さんからメールをいただいた。近いうちに対応していただけそう。ありたがいことだ。
追記
改めて調べたらEstlaier 1.2.16が出てるじゃありませんか、今まで1.2.7なんてのを使ってました。 メールオーガナイザーを作ろうと思った時に入手したのに、もうこんなに進歩してるとは。 いつのまにか正規表現やワイルドカードでも検索できるようになってるし。
昨日の時点で、関連検索以外のバックエンドはほぼ動いたので、 今日からフロントエンドを作ろう、と思っているのだが、 今までバックエンドのことばかり考えていて、 フロントエンドはイメージが固まってないので、 またしばらくはぐたぐたと脳内で考える日々になるのかもしれない。
なんか、いつだって何日も(あるいは何ヶ月も、何年も)ぐだぐたと考えないと、 コーディングに入れないのは年取ったせいだろうか。
追記
結局、フロントエンドには手をつけず関連検索を実装しました。
Debianのパッケージが更新されたので、0.1.7にアップグレードする。 すばらしい。
今までFirefoxと交代で使っていたが、これ一本に集約できそうな気がする。
すばらしい点
気に入らない点
しかし、気に入らない点も些細なことばかりなので、我慢できる。
Sun Microsystemsという企業がどのような経営判断するかどうかは、 私の手に余るので、「オープンソースプロジェクトのフォークと互換性」という点に絞って考えたい。
ここ数日いただいたコメントからは、 なんとなく「オープンソースではメンテナが望まないフォークが発生して、互換性を維持できなくなるケースがある」という暗黙の過程があるような気がする。
たとえば、
オープンソース化されれば、差別化、重視になるでしょう。
一部のコミュニティが互換性を無視することに対してコミットして、互換性は失われる方向になる。
オープンソース化すると、誰にも互換性の維持はできない。
あるいは
私は、仮にJAVAをオープンソースとした場合、SUNがリーダーシップを取れなくなってしまう「可能性がゼロでない」のを恐れているように感じます。 些細な分岐がSUNに変わる本流となりえないとは言い切れないところに躊躇しているんじゃなかろうかと推測してます。
あるいは
言語系とか（TEXなんかも含めて）は、これまで蓄積してきたソース・スクリプト（コンパイラ・インタープリタ側からみると「データ」）の互換性がでかいですよね？ だから「forkをおそれる」という企業のスタンスはよく理解できます。 「旧バージョンで動いていたプログラムが新バージョンで動かない」というサポートはとても面倒。ましてや「新バージョンはウチじゃなくて別のコミュニティで勝手にコミットしてるんですがーーorz」なんて間抜けな対応したくないでしょうし。
とか。
Mr.orzさんのコメントを取り上げてみれば、 前半の「互換性がでかい(重要ということか？)」というのは十分に理解できるのだが、 「forkをおそれる」というのはどういうことを想定しているのだろうか。 どのような事態が発生することをおそれているのだろうか。
オープンソース化しなくても新バージョンを出せば互換性問題の危険はあるし、 オープンソース化しても、勝手に「新バージョン」がリリースされるわけじゃない。 フォークはあるかもしれないが(めったにないけど)、 そんな場合でも「そのフォークはうちは知りません」の一言で済むはずだ。
オープンソースではフォークを禁止することはできない、これは事実だ。
しかし、メンテナが互換性を維持したいと望んでいるのに、 フォークなどの理由によって互換性の問題が発生するようなケースがあるのだろうか。 より厳密には、オープンソースだからという理由で互換性の問題が発生しやすくなることがあるだろうか。 私には想像できない。
私は「オープンソースが原因で互換性の問題は発生しない」と思っていて、 7月6日のエントリでも7月7日のエントリでも、 その理由を説明してきたはずだ。もちろん、あれでは「ゼロであること」を証明できてはいないが、 それはムリな相談だろう。やや危険なたとえを使うと、交通事故の可能性はゼロではないが人は車に乗るわけだし。
これは「オープンソースで互換性の問題が新たに発生しない」という意味で、 逆に言うと「オープンソースでなくても互換性の問題は発生する」と読み替えてもかまわない。
かつて「メンテナが望まないフォークが発生して、互換性を維持できなくなったケース」あったのだろうか。 これからありえるのだろうか。それともFUDにすぎないのか。
それをはっきりさせたいと思っているのだ。 もし、具体的なイメージはなく、ただ単におそれているだけならばかばかしい。
企業が自分のプロダクトをオープンソースにするもしないも、その企業の自由だ。 オープンソースというやり方を信じられない。結構。 オープンソースにしない方がビジネス上有利だと思うから。結構。 苦労して開発したソースは秘密にしたい。それも結構だ。
しかし、「オープンソース化すると互換性が損なわれるから」などという、 事実でないことを理由にしてほしくない。
言語の互換性問題と言えば、各種「方言」問題がある。たとえばPascalはいろいろ方言があり、 結局ある方言(コンパイラ)用のプログラムは、別のコンパイラでは動かない(ので結局別の言語と同じ)というような。
でも、このような方言問題の原因は、オープンソースではなく、 不完全な(あるいは曖昧な)言語仕様とそれに基づいた独自実装によるのではないか。 オープンソースの処理系があれば独自実装の必要性は薄れ、むしろ方言問題は回避できるのではないか。
Javaについては、おそらくはマイクロソフトの「J++ショック」が尾を引いているのかもしれない。
気持ちは想像できるが、その問題はSunのJDKのライセンスをオープンソースにしないことでは回避できない。
SunがJDKをオープンソースにしようとしまいと、 やろうと思えば、今日存在しているオープンソースJavaコンパイラ(たとえばgcj)を改造して、 Java方言を作るのは簡単だ。
私の知る範囲でプロジェクトのフォークが発生するのは次のような理由だ。
進歩の方向に意見の対立が発生し、意見の調整ができなかった。
この場合には「本家」はそのまま存続するので、本家についての互換性は問題ではない。 分家と本家との間には互換性の問題はあるが、これはオープンソースに限らない(独自実装とか方言とかの問題)。
メンテナがメンテナンスを放棄したが、後継者が複数登場し、一本化ができなかった。
「本家」が放棄されているので、少なくとも互換性は問題にならない。
あと、可能性としては「ただフォークしたかった」というものもあるのかもしれない。
オープンソースでフォークが発生すると、重複した作業が発生するので、 リソースの無駄づかいが起きるし、進歩が阻害される傾向があるので、 望ましくない。しかし、たとえ発生したとしても、すくなくとも「互換性」の問題は発生しない。
ありがたいことに、フォークというのはめったに起きない事態だ。 これはオープンソースプロジェクトではオーナーシップが尊重されていることを反映しているだろう。
日曜日は用事があるので、役場で期日前投票を行う。 国民の権利であり、義務だから。
もっとも青木自民党参議院幹事長を擁する島根県では結果が見えているわけで、 投票行動に対する動機づけが希薄なのは確かなのだが。
休日の午前をどこで過ごすか。子供が大きくなってくると、年齢のばらつきもあるし、それぞれにやりたいことも違うし、一緒に行動することが難しくなってくる。うちはしぶしぶでもついて来るのでまだマシだと思うけど。
しかし、今日の図書館行きは全員が賛成した。まあ、みんな本は好きだし(ジャンルはばらばらだけど)いろんな本があるからねえ。手近で一番大きい図書館ということで、松江市立図書館へ。県立図書館の方が大きいのかな、行ったことないけど。
子供向けのプログラミングの本とか、普段見かけないような本も一杯眺めたし、 知的所有権の本なんかも興味を引かれたけど、 借りてきたのは結局『400204162X』(全５巻)であった。 4001155729はまだ入荷してないみたい。
結局、全員でなんと17冊も借りたのだった。そんなに読めるのか。
岡山で会議。途中、ひどい雷が鳴り、どしゃぶりになった。 金曜は松江がひどい天気だったが、山陰と山陽では時差があるのか。 松江と同様、すぐにやんだので被害を受けなかったけど。
いずれにしても今日で中国地方は梅雨明けだったらしい。
今日の収穫はミニトマトが９個。
しかし、気長に対応する必要があるものだな。 これだけのものを得るために何ヶ月もかけるなんて。 いや、あんまり手はかけてないけど、普段相手にしている ソフトウェアやらインターネットやらとは時間の流れ方が違うようだ。
ちょっと新鮮。
Mr.orzによるツッコミが理解できていない。
>「メンテナが望まないフォークが発生して、互換性を維持できなくなったケース」
正確には、メンテナ→オリジネータですね。
で「かつてあったか」→少なくとも著名なケースはない（と思います）
「今後あるか？」→可能性としてある以上、企業としては何らかの対策が必要かと（でないと経営責任になる）
いや、オリジネータから引き継がれている可能性もあるので、メンテナで良いでしょう。
さて、互換性が維持できない可能性があるということであるが、 いったいどういう事態を想定しているのか想像ができない。おそらくは私の想像力が貧困なのであろうが。
「可能性を否定する」のはなかなか難しいので、 日本が沈没する可能性も、私が明日バスに轢かれる可能性も否定できない。 明らかに予測可能な事態に対策を行わなかった場合には経営責任になるだろうとは思う。 きちんとした企業では飛行機が落ちても大丈夫なように経営陣を複数の便に分散させるということだし。
しかし、ここでMr.orzやその他の方々が「予想している可能性」とは、具体的にはどういう事態なのか。
時々発生する「互換性の低い互換品」問題はオープンソースとは直接関係がない。
既に述べたが、注目を集めるプロダクトには互換品が登場することが多い。 IBM汎用機、インテルx86プロセッサ、NEC PC98、Microsoft Office。 場合によっては特許、商標、ライセンス、不当競争防止法などで疎外できることもあるが、 いつも互換品を留めることができるとは限らない。
互換品が登場した場合、差別化のためなんらかの差異が加えられることが多い。 性能や価格など互換性に問題のない差別化であれば問題はないが、 しばしば新機能(たとえばAMDの3DNow!)だったりして、 プロセッサによって動いたり動かなかったりすると悲しいことが起きる(こともある)。
あるいは互換性が不十分で問題が発生することもある。 これは単なる努力不足であろうけど。
さて、オープンソースであった場合、この互換性問題はどうなるか。 変化するのか、しないのか。
まず、オープンソースであるので、その定義からソースコードが自由に利用可能で、 かつ、修正したものの再配布が可能である。 これだけを見ると、ちょっと修正した非互換なソフトウェアが蔓延し、 互換性の保証を行うことが困難になる可能性を感じるのかもしれない。
しかし、そんなことは起きない。
あるソフトウェアAが存在し、なんらかの事情により、そのソースコードを改変した 「似ているが非互換」なソフトウェアBとCが登場したとする。 オープンソースライセンスでは(たとえLaTeXライセンス1.3を利用したとしても)、 これを禁止することはできない。
しかし、BやCをオープンソースにすること、BやCがAを起源にすることと、 またBやCがAに対してどのような修正を行ったか明示することを求めることは可能だ。 実際、GPLをはじめ多くのライセンスはそれを要求している。
であれば、もしBやCがAに対する差別化を目標としていても、 Aと、BやCの区別を明確にすることが可能であれば、 ユーザにとっては通常の互換品との差はまったくない。
開発者にとってみれば、 BやCがどのような変更を加えたかの開示要求が可能なので、 差別化を目指したBやCの良いものはAに取り込んでもよし、 そうでなければ放置してもよい。 取り込むかどうかの選択権がAにあるぶん、 通常の互換品よりも望ましい事態とさえいえるかもしれない。
というのが私の感じるところなのだが、Mr.orzが
GPLがフォークについての懸念を法的処置してないのに対して、たとえば、LaTexライセンスあたりはうまく処理していると思います。また昨年１２月リリースのモノはデキもいいし。
とおっしゃる真意はいかに。
私はGPLがフォークについて扱っていないのは、 そもそも懸念でないからだと思っている。 LaTeXライセンス(1.3)については、私にはOSD準拠にみえるが確証はないし、 GPLコンパチかどうかも(まだ)明確でないわけだから、 かえって(別の)リスクが高いのではないかと思っている。
ソースは公開するが改変についてはライセンスで一定の歯止めをかける（原則改変自由だが、不合理な非互換フォーク※を避ける）というのは可能です。
※わたくしは、非互換でも合理的なversion-up なら「やむなし」という考えです。
これも具体的なイメージが湧かない。 禁止したい「不合理な非互換フォーク」や、「やむなし」である「合理的な非互換version up」とは、 誰による、どのようなものなのだろうか。
Estraierで関連検索をしようと思えば、あらかじめestindex relateを実行しておく必要がある。
しかし、ソースを見る限りではこれは別にバッチで行う必要はなさそうだ。 ある文書に対して関連検索を要求された時にはじめてoddocscores()を呼び出し、 重要キーワードを得てから、 それらキーワードを(OR検索で)含む文書に対してふたたびoddocscores()でキーワードを取得して、 それらのベクトルの比較を行えば、eagerにスコアを求めておく必要はない。
ということで、estindex.cを切った張ったして、30分ほどでオンデマンドにスコア計算をする(_scoreに結果を保存する)コードが完成した。estindex relateを実行しなくてもキーワード抽出や、関連検索が動いているみたいだ。
ということで、平林さん、いかがでしょう。次期Estraierにはオンデマンドスコアリングを導入してみては。 ただ、_dateデータベースを更新してないんでなんかまずいことが起きるかも。
禁止したいForkの一例はMSのJavaとか。
MS JVMを選んだユーザの気持ちとしてはForkかどうかはどうでもよくて、「 互換かどうか」だけが重要だったのではないでしょうか。 そして、「非互換な互換品」MSJVMはSunとしては嬉しくなかったでしょうし、 できるものなら禁止したかったでしょう。 で、たまたまライセンス上可能だったから禁止したと。
でも、同じことはIntel x86プロセッサにも言えませんか。 IntelはAMD(あるいはTransmeta)の「互換品」は禁止したかったんじゃないかと思います。 けど、できなかった。
想像力は大切。ありすぎるのも困るけど、
ええ、困ってます。 ですから、貧しい私に想像力を適用した結果を具体的に示してくださると助かります。
Mr.orz(「Mr.」と「さん」を同時につけるのは変ですよね)
この点、わたくしは、「ＧＰＬというのはヌケの多い隙だらけの契約」と読んでます
この点、私は「GPLは契約ではない。著作権行使方法の宣言である」と読んでます。 日本でもアメリカでも誰からも文句が出ない形でGPLを契約として成立させるのは無理があるような気がします。 そういう意味では「契約としてヌケ」があっても障害ではないと思っています。
言語処理とかTEXのようなフォーマット言語だと、ユーザからすると「一度書 いた資産が将来もそのまま使えるか」がとでも重要（企業にとっては、市場 規模を決めるファクタ）。しかも、「version-upによって過去の資産が使え なくなってしまった」というのは「私が明日バスに轢かれる可能性」よりは るかに高いものであって、経営上きちんと予測して対処すべき責任（予測し て対策を練らなければ重過失）と考えます。
まだ分かりません。ソフトウェアは自発的には進化しないので、 ここでの「過去の資産が使えなくなる」ような「version-up」とは誰かが行うものなのですよね。 原著作者が行うのであれば、たとえ互換性がなくてもそれは自分の責任であり、 それは少なくとも原著者にとっては「合理的な非互換」であったと考えます。
他者が行うのであれば、
原著者にできるのは、 a)どのような改変が誰によって行われたかを明示すること、 b)再配布を行う時には、修正したものもオープンソースとして開示すること、 を要求することなどであり、それはLPPL 1.3でも、GPLでも可能である、 と思います。LPPL1.3では第６項と第１０項がそれを述 べており、GPL2では第２項がそれに当たると思います。
メンテナの交代が明示されているぶん、LPPLの方がこの点ではわかりやすいとは思いますが、 GPLだから重大の問題が発生する(企業責任が問われる)ほどのことはないと思います。
むしろ、LPPLが(まだ)「OSI認証」でないことによる、 「本当にオープンソースと呼んでもよいの、問題はないの」という不安、 GPLコンパチかどうか(まだ)確認されていないことによる、 「GPLソフトウェアとリンクしてもよいのか」という不安(特に後者)があるので、 私だったら現時点ではLPPL 1.3は薦めません。
ところで、GPLのヌケである「ソースとバイナリの価格づけの関係」というのは、 第１項の
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
という部分でしょうか。 配布方法として磁気テープが一般的であった時代を感じさせる表現ではありますが、 「ヌケ」とまでは思いませんでした。
GPLが現在の状況に合わない点がまったくないとは断言できません。 おそらくはいくつもあることでしょう。 しかし、運用上問題があるほど合わない点にはまだ気がついていません。 ご教示いただけるとさいわいです。
時代に合わないと言えば、刑法なんかも成立が古いだけに変な表現が残ってますよね。
オリジネータの著作権法的な地位をGPLよりは一歩あげ、オリジネータはすべての改変情報を知ることができる、（改変は自由であるものの）正式な改変であるか否かはオリジネータが決定できる、という点で、forkに対するユーザの懸念とオープンソースにより享受できる利益は両立できると考えます。
具体的にどのようなライセンスを考えていらっしゃるのか分かりませんが、 GPLでも上にあげたa)とb)の要求があるので、 全ての改変情報を知ることは可能で、それらの変更を取り込むことも可能だと思います。
わざわざGPLよりも「地位をあげる」ということは、原著作者になにか新しい権利を付与したいのでしょうか。 強すぎる権利は全体の自由を減らすのではないかと懸念しますが、 これはまた別の機会に話しましょう。
個人的には、forkは仕方ないことだし、起こり得ることで、その可能性をことさら恐れるに足らないほど低いと言う必要は無いと思います。開発者中心の世界ではむしろ適度な競争になって良いことでもあるでしょう。ただ、企業の方針としてフォークを避けたいと考えることも妥当ですし、それに対する説得力のある反論は、「フォークは滅多に起こらない」ではなく、「フォークしてもメリットがありますよ」の線なんじゃないかとの印象を持ちました。
私の言いたかったことは「互換品の登場は禁止できない」でしたが、 「フォークは滅多に起こらない」って言ってますね、確かに。
フォークのメリットと言えば「フォークが起きても競争が促進されるのでメリットがある」というところでしょうか。 特にオープンソースの場合、改良の融通ができるのでより速い速度の進歩が可能ですし。
あっという間に次の〆切が来る。原稿書きが本職の人はもっと大変だろうなあ。
9月号のテーマは「tDiary」。 なんかtDiaryの特徴と紹介とか、tdiary-mode.elの改造とか、全然Rubyじゃない話ばかりなんですけど。
まあ、いいか。
今回の記事の対象はtDiary 2.0なんだけど、実際に私が使っているのは1.5.5(改造版)だったりするので、 原稿を書いてから確認したら、2.0では当てはまらないこととかが何箇所かあった。あぶない、あぶない。
某学会から頼まれていた某論文の査読に取り掛かる。
とはいうものの、査読なんて初めての経験だし、 なんといっても査読をするどころか、査読を受けたことさえないのに、なにをすればよいのか。
とりあえずは、ガイドを読みつつ手探りでコメントを書く。
いや、どうしても突っ込みたくなったので。
これに対して同社は、同条項はMicrosoftがソフトを安心して開発するために必要で、違法ではないと主張する。「ソフトの構造はどんどん複雑になり、技術も多岐にわたっている。特許侵害の心配なく開発できる環境を整えるのは重要だ」（マイクロソフトの法務・政策企画統括本部の平野高志執行役法務・政策統括本部長）。
「Microsoftがソフトを安心して開発する」のは、 Microsoftにとって都合が良いのは確かだし、 より競争力を高めるためには「重要」で「必要」かもしれない。
いいよな、独占的市場支配力を持つ企業は。 特許が邪魔なら特許権の行使を制限してしまえる。 「いやなら、Windowsのライセンスを結ばなくてもいいんだよ」だって。
オープンソース陣営も類似の方法で特許権の行使を制限できないだろうか。
無理そうだな。
エンターブレインから荷物が届く。 RGSSなる名称でRuby 1.8.1(正規表現エンジンは鬼車)が組み込まれているそうだ。
小さな字で「Ruby (c) 1993-2003 Yukihiro Matsumoto All Rights Reserved」と書いてあるのが誇らしい。
とはいうものの、これの必須システム構成を満たすPCを持ってないんだけど。
もうちょっとコンピュータに投資すべきか。
米子訪問。今日のテーマは「系図」。
『マタイによる福音書』１章にもあるように、古代の人は自分の系図を大切にした。 自分がどのような血統で世にあり、 自分の存在は過去の先祖のおかげであることを自覚することは重要である*1。
それから、1840年生まれの曽々祖父から始まる「まつもと家」の先祖の話を少し。 曽祖母、祖母、父と続く流れにはさまざまな歴史とドラマがあった。 我々も時々は先祖のことを思い返そう。彼らのために祈ろう。
とかいうような話。
神権会では労働の話。「私の作ってるソフトは各国の言語が使えるようなものだ」とかいうような話が飛び出す。 ずいぶん以前の『クローズアップ現代』の内容をそのまま反映したようなコメントだが、 嘘ではないから否定するわけにもいかないし、とはいえ、そのまま肯定するのもなんだか違う気が。
この機会にM17Nを再開させようかなあ。
実家に立ち寄ってから、帰る。
*1 やりすぎると選民思想になるけど
いつから海の日がハッピーマンデー対応に。
教会主催のダンスパーティ。子供が出し物としてダンスを発表するということでついていく。 あとはバンブーダンス(竹の間をとぶのね)を手伝ったり。
社交ダンスの方はもう10年以上踊っていないので、すっかりステップとかを忘れている。 ジルバ、ブルース、ワルツくらいならかろうじて体が動くけど、ひどくぎこちない。 結局ほとんど壁の花。
でも、ちょっと懐かしかったな。
恒例の温泉解放日。玉造温泉の15件の温泉宿のいずれにも無料で入浴できる。
夏休みに入った子供たちを連れて、今日は「ホテル玉泉」に。 ここは気持ちよかった。
まだ全制覇には遠いな。
温泉に入った後、食事をして、書店に立ち寄ったら、 コンピュータ関係書籍のコーナーで、「まつもとさんですか」、と声をかけられた。
「はあ？」
びっくりしたが、地元の大学生なのだそうだ。以前、島大で講演した時にも来てたそうだ。 おちおち立ち読みもしてられないな(苦笑)。
私のまわりをちょろちょろしている息子を見て、彼は「君のことも日記で読んでるよ」。 私の日記の読者ってあんまり具体的にイメージできてなかったので、ちょっと不思議な感覚。
玉湯町青年部による夏祭りに顔を出す。といっても露店がいくつかでているだけなんだが。
子供たちは金魚すくいに挑戦。息子は結局私が代わりにすくう破目になった。 しかし、驚いたのは次女が私よりも多くつかまえたことだ。隠された才能。
えーと、逆ギレですか？
BSDの方が好きって人は多いだろうし、その方がより自由だと感じる人もいるだろう。
また、GPLではプロプライエタリなソフトウェアには組み込めないのだから、 「目的を問わずソースコードを再利用する自由」はGPLにないというも事実だ。
とはいうものの、これはやっぱりひどいんじゃないかと。
個人的には、 これからソフトウェアをオープンソースとして公開する時にどのライセンスを選んだらよいか迷ったら、 とりあえずGPLを勧める。
その理由は
というものだ。
もちろん、それ以外の理由があって(たとえばBSDライセンス・ラブとか)積極的に 別のライセンスを選びたい人は、なんの引け目もなくそれを選べばよいと思う。
Satherの話をきっかけに、 静的型言語好きの前田くんと、 静的型について議論する。
Rubyなんて動的型の代表みたいな言語を作っている私だが、 実は昔はEiffelの影響を受けて静的型オブジェクト指向言語至上主義だったのだ。 卒論で作った言語も静的型言語だったし。
静的型のメリットと言えば、以下のようなものであろう。
最適化しやすい。
型情報が分かっていれば、 動的結合を省略して直接呼び出しを行ったり、 式の展開・畳み込みを行う余地がある。 Rubyみたいな言語を作ってると「お前は最適化にウラミでもあるのか」というくらい最適化しにくい。
間違いが検出しやすい。
型情報で全部の間違いが検出できるわけではないが、 単純なタイプミスやロジックミスが型の不整合として検出できるのは、 「実行してみないと分からない」動的言語よりも嬉しい
もちろん、どちらも嬉しいのだが、スクリプト言語が台頭した背景を考えてみると、 実行効率に貢献する「最適化」よりも開発高率に貢献する「間違いの検出」の方が重要度が高いといえるような気がする。
しかし、実際には最近登場する言語の多くは動的な性質を多く持ち、動的な型を持つ言語である。 静的型言語の方が優れているとはいちがいには言えない。
静的型のデメリットはこんな感じだろうか。
全ての変数に型を書くのは面倒くさい
たくさん書くことでチェックに使える情報を増やしているわけだから当然と言えば当然だ。 ただ、代入による型伝搬(Satherにある)や型推論(MLやHaskellにある)で軽減することができる。
柔軟性が減る
たとえば、Rubyであればwriteメソッドを持つオブジェクトならなんでも出力先にできるが、 静的型言語ではそのような柔軟性は困難だ。 いや、interfaceのようなものを用意してそれを継承すれば理屈では可能だが、 実際にはあまり活用されていないようだ。
ということは、実行効率にはとりあえずこだわらず、 できるだけ(動的型言語に近いレベルで)簡潔に記述でき、 かつ柔軟性を減らさないような型の運用を積極的に支援するような静的型言語の登場する余地はあるのではないか。
たとえば、こんな感じで。
なかなか面白い言語になると思うのだが。たぶん私はRubyと心中すると思うけど、 若い人には新しい発想の言語を作り出してほしい。
うーむ、langsmithネタかな。
既存のCGIプログラムの修正を最低限にしてFastCGI対応にする方法について。
以前、こんなトリックを書いたことがあります。
require 'cgi'
require 'fcgi.so'
class CGI
class Fast<CGI
CONTINUATION = []
def Fast::new(*args)
at_exit do
if CONTINUATION[0]
CONTINUATION[0].call
end
end
callcc do |c|
CONTINUATION[0] = c
end
fcgi = FCGI::accept
unless fcgi
CONTINUATION[0] = nil
exit
end
$defout = fcgi.out
super(*args)
end
end
end
「require 'cgi'」を「require 'fcgi'」に変更し、 「CGI.new」を「CGI::Fast.new」に書き換えるだけで かなりのCGIがそのまま動作するのではないかと思います。
もうちょっと手を加えれば、CGI.newのままでもいけるようにできるかな。
継続を使った数少ない実用的な例かも。
笹田くんのYARV(Yet Another Ruby VM)が未踏ユースに通ったと言う報告を受ける。
めでたい。これでRiteの実行系は任せることができるかもしれない。 楽できる。というか、モノをつくり出す能力が減退しているので、 笹田くんのような若い力はありがたい。
未踏ユース公募結果を見ると、 「Ruby.NET コンパイラの開発」なんてのが見受けられる。 面白そうだけど、実用的なのができるかなあ。これも見守ることにしよう。
「日本語プログラミング言語の開発」のようなのもあって、 面白そうだけど、既存のものと一線を画すようなものが作れるだろうか。
「ユース」だからいいのか。
2週間前に借りた本を返しに、松江市立図書館へ。 そのまま、県立図書館に行ってみる。
まあ、田舎の図書館だから。
そういえば、米子には昔「JC図書館」という小さな図書館があって(今でもあるのか)、 私が子供のころには愛用していた。小さいから蔵書は少ないんだけど、 子供向けSFが充実していて、毎日のように読んでいたっけか。
最初に断っておくが、私は「迷ったらGPL」と言っているが、別にGPL至上主義でもなんでもない。 実際に、RubyはGPLソフトウェアではない。
そんな私からBSDライセンスを見ると、すばらしい点が多いと思う。短いので全文引用する
Copyright (c) The Regents of the University of California. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
要するに「私が書いたということだけ明記してくれれば、後はなにをしても構いません」というニュアンスだ。 「私が書いたもので私だけ利益を独占するのではなく、全人類の資産として活用してほしい」と解釈してもよいのではないだろうか。しれは高尚な精神であり、尊敬に値する。
しかし、高尚な態度には時としてコストが伴う。それがたとえばGPLコードをBSDライセンスのコードに取り込めない点だ。しかし、他人の「所有物」の権利を勝手に取り去ることはできないから当たり前のことだ。 「私には高尚な理想があるから」というのは理由にならない。
だから、BSDライセンス・ラブの人がやるべきことは、 「GPLには(私に都合の良い)自由がない」と文句つけることではなく、 「我々の高尚な理想に君も賛同しよう」と啓蒙することではないか。
確かにGPLにすると、 たまに「BSDライセンスソフトウェアに取り込めないからライセンスを緩めてくれ」というメールをもらってうっとうしいというデメリットがある。 しかし、いやなら黙殺すればよいことで、 BSDライセンスを選択してGPLソフトウェアを取り込めないというデメリットとは比較しようがない。
幸いにしてほとんどオープンソースライセンスはGPLコンパチなので、
BSDライセンスをはじめとしてGPLコンパチのオープンソースライセンスは多いので、
GPLソフトウェアに対してソースコードを取り込むことに対する制限は(逆の場合よりも)少ない。
どのライセンスにしたらよいか迷うような、ライセンスについてあまり難しいことを考えたくない人は、 とりあえず実利的な点からも、GPLを選択しておいた方が良いと思う。
もちろん、BSDの高尚な理想に賛同して、人類全体により積極的に貢献したい人は、 (そのコストを理解しつつ)BSDライセンス(または類似物)を使ってほしい。
追記:
あのー、ほとんどのオープンソースライセンスはGPLコンパチってのはいくら何でも強弁が過ぎてるのではないですか？
確かに。「ほとんど」はあまりにも軽率な物言いでしたね。訂正します。
松江出席。転出していった友人が出張のついでということで訪ねてくる。懐かしい。
娘と面接。少々話した後、囲碁とオセロを一局ずつ。 しかし、囲碁はルールを完璧に忘れてるぞ。整地はどうやってやるんだっけか。
emacs lispでメールオーガナイザーのフロントエンドを作ろうと思ったが、 バックエンドのバグを見つけてしまい、そっちにかかりっきり。
Estraierのバージョンを1.2.17にあげる。 以前、要望していた属性も検索対象に含めるオプションが増えていてハッピー。
..が、重い。いや、風博士から起動されるestindexが重い。 私の非力なマシンが悲鳴を上げる。っていうか、Ｘ落ちちゃったし。
ソースを見るにg_idle_add()でestsearch_update_index()を登録しているのだが、 この頻度が高すぎるようだ。同時にいくつもいくつもestindex registerとestindex relateが動いている。
しょうがないので、estsearch_update_index()をちょっとハックして、 前回の起動から１時間たっていない場合にはestindexを起動しないようにした。
でも、本来なら風博士はキャッシュに新たに入ったファイルが分かっているのだから、 estindex register -list - にファイル名を渡すとかでもっと軽くできるんじゃないかなあ。
出るのは時間の問題だと思ってたけど、やっぱり登場したね、オープンソースソフトウェアの資格試験。
シルバーとかいうグレードがあるので、オラクルの試験をイメージしてるんだろうなあ。 「ゴールド」も来年以降登場予定だそうだが、そのうち「プラチナ」も出てくるんじゃないかと。
ここで「じゃあRubyも」なんて冗談を言うのは常なんだが、 実際考えてみるとこの試験そのものはビジネスとしてはおいしくない。
受験料は1万3000円(税別)だそうだから、1000人受けても売り上げは、1,300万。 試験問題を用意し、会場を準備し、試験を運営することを考えたら、とてもわりに合わない。
もともとのお題目通り「資格を取得することで技術者が客観的な評価を受けられ、企業も的確な人材を確保できるようになるという効果」の効果しか期待できないだろう。いや、それで十分なんだけど。
こういうことをしようという人が登場するということは、 PostgreSQLは市場に認知されてきているということなんだろう。
ビジネスとしておいしくないといえば、 「ゼンド、PHPのオンライン教育コースを提供開始」も同様。
価格は9万円（税別）。同社では年間200名の受講を目指す。
ということじゃ、1800万だものね。これも「技術者を増やす」ということを主眼に捉える必要がある。
資格試験も教育もビジネスは甘くないってことか。
もっとも、うちの会社も「Rubyの教育」には参入計画がある。 もっとほそぼそとした感じだけど。
タイムリーなタイトル。が、内容はそうでもない。
この記事を書いたMary E. Tyler女史(たぶんね)は、
では、自分のプロジェクトに最も適したオープンソース・ライセンスを選ぶにはどうすればよいだろう。
と期待させておいて、OSIの顧問弁護士であるLawrence Rosen氏にインタビューする。
彼の最終的な答えはこうだ。
「多数の企業に多数のライセンスがあるので、それぞれの違いと、自社製品にどう適用されるかをよく考える必要がありますね」と、Rosenは注意を促す。「フリーサイズの万能ソリューションはありません」
ま、確かにそうだわな。どのライセンスも利点・欠点があり、 全ての人のニーズを満たすライセンスはなさそうだ。 というか、さすが弁護士のセンセイ、言うことにソツがない。失言の多い私は見習わなくっちゃな。
ライセンスの選択にあたって、私の経験から言えるのは以下のようなことだ。
独自ライセンスを避ける
私はRubyに対してGPLと独自ライセンスのデュアルライセンスを選択したが、これは間違いであった。 ライセンスの条文を考えるのはプログラミングに類似した側面があるので楽しいのだが、 実利的に考えると独自のライセンスには問題が多い。
ライセンスに穴がないことを示しにくい。
いろいろな人によって検討されているライセンスなら存在しないであろう穴が、 独自ライセンスには残っている可能性が高い。
読む人が結局何ができて何ができないのか判断にしにくい
たとえばBSDならなにができる、GPLならなにが禁止されるのかは ちょっと調べれば(厳密ではなくても)だいたい分かるし、 相談する相手もそれなりに見つかるだろう。 だが、ユーザは独自ライセンスだとその辺に確信がもてずに、 直接訪ねることになるだろう。ライセンスに関する質問が世界中から来るのはうっとうしい。
同様の理由から、独自ではなくてもあまり知られていないライセンスを選ぶのはお薦めしがたい。
ライセンスの変更は大変
全てのコードの著作権を一人で所有している時にはライセンスの変更はなんでもない。
しかし、プロジェクトが進んで送られてきたパッチを取り込んだり、 メンテナが複数になったりすると、厳密には全員の承諾をとらないとライセンスの変更はできないことになる。 ライセンスの変更を行う可能性がある場合には、 貢献する人ときちんと合意を取っていないと面倒なことが起きないと言う保証はない。 そういう問題を避けるため、FSF、MySQL ABなどの組織・企業は コードを貢献する人から必ず承諾を取っている。
GPLを「再利用されるコード」に適用するのは慎重に
先日、「迷ったらGPL」と言ったのは私だが、 再利用されることを目的としたコードにはGPLは向かないことを指摘しなかったのは手落ちだ。
この記事にもあるように、 GPLの「派生物」の定義はちょっと広い(ほとんどの人のセンスでは広すぎる)ので、 再利用されることを目的としたコード(要するにライブラリ)がGPLであると、 利用したコードにもGPL互換のライセンスを適用せざるをえない。
世の中には自分のソフトウェアにGPLを適用することを嫌う人も多いし、 あるいはさまざまな事情によりGPL互換ライセンスを使えない人もいる。 再利用されることを目的とするコードは使ってもらってナンボだと思うので、 結果的に間口を狭めるGPLよりは違うライセンスを採用した方が望ましいと思う。 BSDライセンスとか、MITライセンスとか、LGPLとか。
もっとも、「GPLの布教」のためにあえてライブラリにGPLを適用する人もいると思う。 私にはそういう人を止める権利も手段もない。
一方、スタンドアローンのプログラムでは、利用そのものはオープンソースライセンスでは制限されないので、 この件については心配する必要はない。
自分の立ち位置に近いライセンスを
ライブラリでなくてもコードの融通は発生するものだ。 あっちのソースを見たり、こっちのソースからコピーしたりする行為が自由にできるのが理想的だ。 そういう意味では自分が所属するコミュニティや参考にしたいプロジェクトなどが選んだライセンスと 揃えておく方が実利的だろう。 Javaな人たちにはApacheライセンス、BSDハッカーにはBSDライセンスということになろうか。
とりあえずそういうものが思いつかない人(先日の「迷ったら〜」の対象者)は、 GPLソフトウェアの蓄積が大きい*1ので、 GPLを選んどくとよいんじゃないかな。
私個人の考えでは、特に企業が自社ソフトウェアをオープンソース化する場合にはGPLが向いていると思う、 特に他の理由がなければ。 RMSの本意とは違うかもしれないが、GPLを使えば競合他社を牽制することができるし、 MySQL ABやTrolltechのようにライセンスを使い分けるビジネスもありえるし。
あと、法的な確信が得たい人は、どうぞ弁護士に相談してくださいませ。
*1 以前受けた忠告に従いfreshmeat.netで調べると18433プロジェクト、一方、BSDはオリジナル、修正版を合わせて1995プロジェクト
.NET上のPython処理系IronPythonがとうとう公開された。 オレゴン州ポートランドで開催中のOSCON 2004にあわせての公開らしい。
で、さっそくソースを読んでみるが、大変読みにくい。 C#に慣れてないってのもあるけど、 C#のリフレクションとIronPythonのリフレクションとが渾然一体となっていて 区別が付けにくいのがつらいところだ。
どうやら、メソッドは生成したILのコードをdelegateとして保持しておいて、 それを直接呼び出しているらしい。だから、メソッド呼び出しは、
という手順のようだ。確かに呼び出しにはリフレクションを使っていないが、 これで速いんだろうか。まあ、もともとのCPythonのセマンティクスも同じようなものなんで、 大丈夫なのかな。
そういえば、Jythonのソースは読んでないな(Java嫌い)。
LL Weekendが近づいているので、私の担当分Language Updateについてまとめようとするが、 今年(去年のLLから最近まで)は、言語仕様については進歩があんまりないことに気がついた。
一体、私はこの１年なにをしてたんだ(日記を書いてました)。
しかたがない、あと10日ほどの間にでっち上げるのはどうだろう。作者の強み。
国際化(M17N)の1.9への取り込み
どうせこの夏、論文に書くために、再実装＋1.9へのマージを予定していたので、前倒しする、とか。
メソッドコンビネーション
こっちは完全な新機能なので互換性の問題はない。が、効率の良い実装が大変なんだよねえ。 で、前田くんと議論したが...その結果は後で。
やっぱ無理があるかな。
というわけで、メソッドコンビネーションだ。
メソッドコンビネーションは、メソッドの前と後ろにフックをかけることを許すものだ。 CLOSで提供されている機能で、 一種のアスペクト指向と呼んでもよいかも。 というか、AspectJのGregor Kiczalesは元々CLOSのデザイナーでもあるから、 メソッドコンビネーションなどから発展してアスペクト指向が生まれたと言うべきだろうな。
これの効率の良い実装は難しい。 現在のRubyの実装を大きく変えないですむと嬉しい、という条件をつけるとなおさらだ。
思いついたのは(だれでも思いつきそうだが)、CLOSのメソッドコンビネーションが
という順序になっているのを、
という順序の変更を考えてみた。 CLOSとは確かに違うが、別にまったく同じであることにこだわるほど、CLOSに忠誠を誓っているわけではない。
とはいえ、primaryメソッドでsuperが呼ばれなければ、beforeメソッドやafterメソッドが一切呼ばれない点は、 嬉しくないこともあるだろう。すぐに考えついたのは、たとえばロギング機能をこれで実装しようとしたら、 includeでは(beforeメソッドなどは明示的にsuperを使わないと呼ばれないので)役に立たないと言う点だ。
これはincludeが(仮想的な)スーパークラスを追加するものだからいけないわけだ。 たとえばSatherのようなcode inlcusionであれば、同じレベルなので問題はない。 とはいえ、いまさらincludeの意味を変えるわけにはいかないので、 新しいオペレーション(かmoduleのような別物)を導入する必要があるなあ....。
などと、次々と考えが発散するのであった。でも、上記のアイディアはけっこう魅力的だなあ。 問題は「新しいオペレーション」の名前だな。ほんとはincludeが最適だと思うけど、 これは変えられそうにないし、「埋め込み」とかを意味する単語だといいのかな。
前田くんは「expand」を提案していた。include, extend, expand...、 うーん、一度慣れてしまえば、それなりにいいかも。
妻が腰痛に苦しむので、自宅作業で家事も行うことにした。 こんなに痛そうにしていたこともない。
が、夏休みってのはコンピュータ使ってても、子供が入れ代わり立ち代わりやってきて仕事が進みやしない。 能率悪すぎ。
しかも、この日は午後から小学校の地区プール解放日で、監視員の当番が当たっていたりするのだ。 いくらパラソルの下だとはいえ、2時間、屋外で暑い思いをするのはインドア派の私には辛いわ。
頭痛がするようになってしまった。
今日はかずひこさんの引っ越しだったのだが、 おかげで会社に行けなかった。
月曜からは真面目に仕事しよう。そうしよう。
Paul Grahamの新しいエッセイ(翻訳はshiroさん)。 ハッカーの生態について。
まあ、当たってると思う。もし私が本当にハッカーだったとしたら、だけど。
この業界、一番重要なリソースは人間だ、 というわけで、Rubyに関連する活動を見てこの人はと思う人に目をつけておいて、 「仕事を探してる」というタイミングで適切に声をかけるようにしている。
私の紹介で(株)ネットワーク応用通信研究所に入社した人も多いが、 そういう人たちはうちの宝だと思っている。きっと社長もそう思ってるんじゃないかな。
そのうち、Rubyとかオープンソースとかの梁山泊みたいになるといいなあと思っているのだ。 そのためにも本業は安泰でないとな。
しかし、油断していてはいけない。 同じようなポジションをグッデイの前田さんも 狙っているに違いない(笑)。
今日は海辺でバーベキューの予定であったが、台風来週のため中止に。 子供たちはちょっと残念そう。でも、波にさらわれてもいかんしなあ。