Matzにっき

_ [教会]安息日

ひさびさの松江の教会。前回は5月4日。

いくつか知らない顔が増えている。このご時世でも宗教に関心をもってくれる人が日本に残っていることは、 ありがたいというか、希望が持てるというか。

甥っ子も１ヶ月もたつとだいぶ人間らしくなってた。

_ 昼寝

教会からの帰りに遠まわりして出雲空港に寄り、置いてきてた車をとってくる。 さすがに2台ないと不便だから。

その後、遅い昼食をいただき、昼寝。なんと３時間以上もねてしまった。 目が覚めると暗くなってた。こういうのは昼寝とは言いません。

_ [車][UI]エラーは饒舌に

夕べのことだが、松江駅まで妻に迎えにきてもらった。

で、帰ろうとするとエンジンがかからない。バッテリーが上がったかと思ってちょっと焦った。 しかし、ルームランプはつくし、ワイパーは動くし、電圧は下がってはいないようだ。

おかしいと思って、席を交代して見るとシフトが[D]ポジションのままだった。 普段、マニュアルを運転している彼女は停車時に[P]ポジションにするのを忘れていたのだった。 なんの表示もなくエンジンがかからないので、理由が分かるのに時間がかかってしまった。

教訓: エラーのときにはユーザにあれこれ推測させないようにできるだけ多くの情報を与えましょう。

_ [日記]祝１ヶ月

5月１日にこの「Matzにっき」を書きはじめてからちょうど１ヶ月がたちました。

その間には「XMLとYAML」とか「42件」とか 「ソフトウェアの自由」とか、 いろいろと楽しいこともありました。 「絵本読み聞かせ」や「メイド」については 反応があったことそのものが意外でした。 けっこう私の意図とは違った解釈をされる方もいらっしゃいましたが、それはそれと言うことでしょう。

これほどたくさんの人が読んでくださっているというのも驚きでした。 これを励みにこれからもくだらない文章を書いていこうと思います。

今後ともよろしく。

_ [本] 『ツバサ』＋『×××HOLIC』 ≒ 『バイオレンス・ジャック』

というネタを温めていたのだが、どこかの日記で同じような記述を見つけてしまった (しかし、再び探すも見つからない)。くやしい。

要するに「作家は(晩年に)自分の複数の作品世界をリンクした作品を書きたがる」傾向があって、 個人的にはその典型例から「バイオレンス・ジャック症候群」と呼んでいたのだ。 ってCLAMPってまだ若いんでないかと。

ここは是非、モノリスとオーバーロードとラーマと軌道エレベータが同時に出てくる作品が読みたいものだ。 クラーク先生はご存命だから、まだ間に合うはず。

あるいはロボット３原則とファウンデーションが同時に出てくる作品を...。

え？ もうあるって？ やっぱり。

_ [OSS] オープンソースとフリーソフトウェア

「オープンソースソフトウェア」という単語から 「ソースが公開されているソフトウェア」という定義を捏造してしまう輩には もはや辟易しているのだが、 これに対しては地道な啓蒙活動を続けるしかない。

「オープンソース」って単語にはきちんとした定義があるんですよ。以上。

こうやって「俺定義」を気長に潰していくしかない。 うるさいと思われても、気づくたびに指摘していくことになろう。

しかし、オープンソースソフトウェアとフリーソフトウェアって実際のところ、なにがどう違うのだろうか？

ストールマン的な観点に立てば、最大の違いは

• 自由をどれだけ前面に出すかが違う。「オープン」には自由という意味合いが薄い。

だろう。しかし、「オープンソース運動」の陣営だって自由を気にしていないわけじゃない。 本当に気にしていなかったら「オープンソースの定義」は 単純に「ソースが入手できるソフトウェア」であったことだろう。 自由は「オープンソース運動」にも必須なのだ。

ただ、技術的な問題から「オープンソース」の方がちょっと広い*1 ということはある。

以前、このような「違いの定義」を聞いたことがある。

オープンソース

「バザール式」開発体制の必要要件

フリーソフトウェア

自由を押し進める社会活動

しかし、私自身の考えとしては

オープンソース

利用者の視点

フリーソフトウェア

開発者の視点

じゃないかなあ、と感じている。

開発者は自分のソフトウェアをフリーソフトウェアにするかどうかを決めることができる。 誰かに尋ねる必要はない。そして、「ソフトウェア開発者よ、自由を分かち合え」と叫ぶのが、 フリーソフトウェア運動である。

一方、自分が開発していないソフトウェアについて、そのソフトウェア開発者が自由を人々に与えようという 意思があるのかないのか判定するのは難しい。聞いてみれば良いといっても、 いつも連絡が付くとは限らないし、その人の自由の定義が人と違っていて意思の疎通に苦労するかもしれない。 こういう場合には客観的な基準が必要だ。その客観的な基準がOSDであり、その基準を満たすソフトウェアを 推奨しようというのがオープンソース運動である。

なんてことを考えたのだが、これだけではまだ「オープンソース運動」の全部を説明しきれないなあ。

_ [OSS] 日本発オープンソース支援

元々の久米氏の講演に関して 「日本発オープンソースソフトウェアなんて捉え方に意味はない」 という発言を散見するような気がする。 たとえば、八田さんの「日本発のオープンソース」という幻想における

という発言などがこの種のものの典型だろう。

確かに国際協調があたりまえのオープンソースソフトウェアで 日本という国籍をうんぬんするのは意味がないという主張は正しい。

しかし、私は久米氏が「日本発」という表現を使った時の意図は少々違うのではないかと考えている。 ここでは私の勝手な推測を述べておいて、 私の考えが正しいかどうかは今月25日に本人に直接お会いした時にうかがうとしよう。

まず、最初に注目すべきだと私が考えるのは「経済産業省、商務情報局情報処理振興課・課長補佐」という 久米氏の肩書きである。 要するに彼は官僚であり、 日本国が行政としていかなる見識を持ち、 いかなる行動を取るべきかというのがその視点の基礎となるのではないか。

「政策」という文脈においては「日本」というポジションは絶対不可欠である。 国民の税金を用いる以上、最終的には国民に利益が還元される行動が要求される。

そういう制約の下で「(国の)支援の対象になりえるオープンソースソフトウェア」という観点で 「日本発オープンソースソフトウェア」を捉えていて、 それがまだまだ少ないと感じていた、ということではないだろうか。

ここでは「まだ少ない」と彼が感じたということだけに注目し、 「42件」という数字とか、リストの妥当性についてはおくこととする。

では、残る疑問はふたつだ。日本政府の行動として

• オープンソースを支援することは妥当か
• 「国産」オープンソースを支援することは妥当か

オープンソースを支援することは妥当か

「政府は放っておいてくれ」という意見も聞こえるが、別に支援の押売りをしようというわけではない。 問題は支援を受ける側ではなく、支援する側にある。 つまり、「国がオープンソースプロジェクトを支援することが正当化できるか」ということだ。

単純化して、投入した金額以上の経済的効果が見込めるかと言い換えてもよい。 そうでなければ、税金の無駄づかいと非難されるだろう。

オープンソースソフトウェアが進展することによって、期待できる経済効果としては、

• ソフトウェア輸入超過の軽減

  商用ソフトウェアの多くは海外製でソフトウェアの分野では大幅な輸入超過が続いている。 オープンソースソフトウェアは輸出にはならないが、少なくとも資金流出にはならない。

• ソフトウェア産業構造の変化の促進

  海外製ソフトウェアを中心にサービスを構築していくだけでは、 国内にノウハウは残らず、将来の産業空洞化が懸念される。 オープンソースソフトウェアにより重要なノウハウが公開される。 そのノウハウ(というかソースコード)を用いて、より高度なテクノロジーが実現される

• (国内の)IT化促進

  十分な機能・性能を持ったオープンソースソフトウェアにより、 システム構築の費用が低減されれば、資金をより高度なIT化に向けることができ、 国内産業の競争力が増加する。

などが考えられるだろう。私は経済は素人以下なので、どれも「かもしれない」を付けて読んでほしい。 投資以上の経済効果がありそうだ、と感じていただければ十分だ。検証は専門家がするだろう。

いち開発者としては、正当であれば国からの支援であろうが、企業からの支援だろうが受けたいと思っている。 また事実、私は国からも企業からも支援を受けたことがある。

「国産」オープンソースを支援することは妥当か

開発者の視点からは、八田さんの言う通り「日本発」に意味はない。 プロジェクトを開始した時点の開発者が日本人であるかどうかとか、 意思決定者の過半数が日本人とかいうような適当な規準を定めても、 「だからなんなの？」という結末になるのは目に見えている。

しかし、「経済省が(おそらくはIPAや産総研を通じて)オープンソースソフトウェアを支援する」という文脈では、 おそらく支援を受けるオープンソースソフトウェアの多くは 「日本発」とか「国産」という言葉で表現されてもおかしくないようなものになるだろう。

• 日本の事情

  日本特有の事情や問題に対応するソフトウェアや機能は、 日本の事情に精通した開発者によって行われなければならないだろう。 オープンソースソフトウェアが日本において最大の効果を発揮するために これらの事情に対応するソフトウェアの開発を支援することには意味がある。

  事実、久米氏も言及していた「オープンソフトウェア活用基盤整備事業」はそのような趣旨であった(なんで「オープンソフトウェア」だったんだろう？ きっと理由があるに違いない)。

• 国内技術の育成

  今のままOSなど基盤となるソフトウェアを海外から輸入するままでは、 ソフトウェア・インフラストラクチャに関する実践的な技術がブラックボックス化し、海外に握られてしまう懸念がある。 そうならないためにも日本人のソフトウェア技術者育成に貢献することに意味がある。

• 資金の還流

  投下した資金は日本国内で使っていただけるのがありがたいわけで、 支援を受ける人が日本人(または国内に住む人)というのはそれなりに意味がある。

要するに「国産オープンソースソフトウェア」を支援するのではなく、 「日本のオープンソース開発者」を支援するということか。

話はこの後「ではいかなる形の支援が適切か」という方向に進むはずだが、 実はまだそこまでは考察できていないのだった。

_ [OSS] 俺定義

まただ。

なんて言わないでくれよ。彼にとっては「マイクロソフトシェアードソース」もオープンソースなんだろうか。

「オープンソースの俺定義をしている文書のリスト」でも作って、 晒す必要があるのだろうか。

あと、すくなくとも私にとっては

は、「感謝の表現」でもなんでもありません。それはアナタの「仕事」です。 相互運用性が重要なソフトウェアでもフィードバックがなければ感謝にはならないでしょう。

そのような活動をしてくださるのはご自由ですし、むしろお勧めしますが、 それと「感謝」を混同しない方が嬉しいです。

「オープンソース」も「フリーソフトウェア」も別に感謝なんか要求してないんですから、 エセ感謝を表明して自己満足されるよりも、 「実際には感謝を示してなんかいないんですけどね」 とかいう態度の方が正直で好感が持てます。

ついでに「いつか貢献できたら」という気持ちが見えると好感度アップです。

_ [Ruby] コミットミス

いやんなっちゃう、またコンパイルできないコードをコミットしちゃった。

発生手順は以下の通り。

• バグを修正する。今回のは[ruby-core:01113]
• コンパイル・テストして修正を確認
• 無駄な変数があったので削る(ここまで自宅)
• オフィスで1日過ごす
• 帰宅前、「今日の修正をコミットしてなかったな」と気づく
• コミット(最後の修正を確認してないことを忘れている)
• コミット終了後コンパイル→エラー
• 目が点になる
• あわてて修正し、再コミット

あ〜あ。皆さんは真似しないでくださいね。

_ [OSS]オープンソース俺定義リスト

を作って晒す必要があるか などと言っていたら、鵜飼さんが作ってくださった。

見つけたら、みんなでリストに追加しよう。

_ [OSS]開発者と利用者

<URL:http://www2u.biglobe.ne.jp/~hsaka/bbs.cgi?month=200306#20030602214801.02048>

「利用者」というのは誤解を生みやすい単語である。 私はいつもやっちゃうのだが、この「利用者」は「ソフトウェア利用者」ではなくって、 「ソースコード利用者」である。

だいたい、フリーソフトウェア開発者の住んでいる世界ではエンドユーザはおぼろげにしか見えないもので、 純粋なエンドユーザ(お客さま)たる利用者は意識の外にいることが多いのだ。 結局、ソースコードを中心とした世界なのだな。

しかし、本来は開発者とエンドユーザの間に

• ソースコードを利用し
• エンドユーザに貢献し
• 対価をもらい
• 開発者に還元する

中間層たる存在がいてしかるべきなのだ。それが、ディストリビュータとか、 システムインテグレータとかいう人々のはずで、そういう人のおかげで、 開発者はエンドユーザとのコミュニケーションに苦労することなく保護される、 ....はずなのに、そういう連中がまっさきに「誤解し」、「定義をねじ曲げ」、「開発者に苦労をかける」 っていうのはどういうワケ？

この人たちがもっとしっかりしてたら、私だってこんな駄文を書いてないで、 Rubyの開発に専念できるのに。

ぷんぷん。

_ [車]タイヤ交換

朝、放置していた前輪のタイヤ交換を行おうとする。

が、サイドブレーキを引き忘れていて、ジャッキを倒してしまう。 おなかを地面につけて伏せている愛車。目が点になる。バカだ。

カーレスキューさん、ありがとう。もうこんな失敗はしません。

_ 献血

した。400ml。前回は11月19日だったらしい。

_ [OSS]開発者の憂鬱

私: なんだってボクがこんなこと(啓蒙)しなくちゃいけないんだ。
妻: それ、誰かに頼まれたの？
私: いや、そういうわけじゃないけど。
妻: じゃあ、それしないとアナタが困るの？
私: いや、直接的には困らないだろうなあ。
妻: じゃあ、やらなくてもいいんじゃない？
私: いや、そういうわけには。
妻: 結局、やりたいのね。
私: そういうことになるのかなあ。
妻: じゃあ、文句言ってもしょうがないわね。

昨日の「開発者と利用者」という文章について、 ツッコミをいただいた。意訳すると

ってことだと思う。「Rubyの開発に専念しろ」ってことかもしれない。 まあ、そっちの方が喜ぶ人は多いと思うんだけどね。

そもそも啓蒙が必要なのか

私は必要だと思ってる。

フリーソフトウェア開発者の基盤は脆弱だ。 ほとんどの開発者は自分の少ない余分の時間から開発時間を捻出している。 しかし、ソフトウェアが大規模化、高機能化し、複雑になってきたり、 ユーザーベースが増えていろいろな状況で使われるようになってくると だんだん片手間では追いつかなくなる。バザール型開発といいつつも、 結局は中心にいる個人への負担は少なくない。 少なくとも私はそうだった。

とはいえ 現状では、片手間で面倒見切れなくなったプロジェクトを抱える開発者の キャリアパス(っていうんだろうか)がない。 結局は、進化のスピードをゆるめるか、プロジェクトをあきらめるか、 誰か熱心な協力者が現れる幸運を祈るかぐらいだろう。

私は運がよかった。1997年、ちょうどRubyが片手間では面倒見切れなくなる直前に 今の会社に拾ってもらえたので。スポンサーの登場により、私はRubyの開発にほぼ専念できた。

しかし、今の日本にそんな幸運な開発者が何人いるだろうか。 今の日本に積極的にフリーソフトウェア開発者を(フリーソフトウェアを開発するために)雇用する企業が何社あるだろうか。

このままでは、日本からは

• 片手間で保守できる程度のフリーソフトウェア
• 運のいい開発者によるごく少数の規模の大きいフリーソフトウェア

しか誕生しないことになる。いくら小さくて便利なソフトウェアも重要だとはいえ、 「ビジネス」ということまで考えると高機能なソフトウェアももっともっと必要だ。

これはよくない。 ソフトウェアの自由のある社会を実現したいという私の野望の大きな障害となる可能性がある。

だから、啓蒙する必要があるのだ。

なぜまつもとが啓蒙するのか

いや、本当は私じゃない人がやってくれるのが望ましいわけで、 こーんな、

• オープンソースの俺定義に抗議する
• オープンソースの正しい定義を繰り返し宣べる
• オープンソースの誤解を説く
• オープンソースの効用を説く
• ソフトウェアの自由を宣べ伝える

なんてなことは、他の人に任せたい。

私自身も最終的には啓蒙は「中間層」の人の仕事だと思ってる。 でも、

• 現在の中間層の人(の多く)には余裕がない
• 現在の中間層の人(の多く)には知識がない
• 現在の中間層の人(の多く)には誤解がある
• 現在の中間層の人(の一部)には邪念がある

し、実際に期待するほどの啓蒙は行ってくれていない(ような気がする)。

まあ、フリーソフトウェアはタダだし、 手を伸ばせばタダで手に入るものに支援とか投資とかイミないよね、 という考えも理解できないでもない。

んが、このまま放置してたらトキみたいに手遅れになってから、 「フリーソフトウェア開発者を保護せよ」とか「レッドデータブックに登録だ」とかいう 話になるに違いない。いや、なればまだマシかな。

そういう危機になってはじめて本気になってくれるのかもしれない。 でも、その時までに失われてしまったものが取り返せるわけじゃないんだよね。

というわけで、「俺が代わりにやってやる。まつもとはRubyに専念しとけ」って名乗りを上げてくれる人が出るまでは、やっぱり続けないとなあ、と思う今日この頃であった。

いや、たいしたことはしてないんだけど、実際。

_ [OSS]俺定義リスト

が不満な人たちもいるようだ、スラッシュドットによると。

いわく、「原理主義的」で「攻撃的」で「啓蒙に失敗してる」んだそうだ。 もう好きに言ってよ。

まあ、反発を受けることがあるのは覚悟の上だし、それくらいでないとアピールしないのは承知してるけど、 やっぱりへこむなあ。

みんな、自由なんてどうでもよいのね。

_ [家族]温泉

息子のリクエストに応えてひさびさに温泉に行く。

歩いて数分のところにあるのにすごく久しぶりな気がする。 どうせ温泉街にあるのだから、自宅にまで温泉が引いてあればいいのに。 実際、うちの前の道路には「湯」というマークの点検口が。

_ [本]『エルマーのぼうけん』ふたたび

同じ本をなんども読みたがる息子は『エルマーのぼうけん』を また読んでもらっている。そしてまるで最初に読んでもらった時のように、わくわくしながら聞いている。

むしろ事前に知識があるぶん「ぼくはこの先知ってるんだもんね」という優越感のようなものを感じているようだ。 いや、この先を知っているのはきみのお父さんもなんですけど...。

とはいえ、本を読み返す楽しみってのは確かにあるよなあ。久しぶりになにか読み返すか。 たとえば『未来の二つの顔』とかどうだろう。

う、星野之宣によるコミックが出てるのか。欲しいな。

_ [OSS]反『オープンソースの定義』原理主義者

しかし、どうして「オープンソース」という単語の定義としてOSDを使うという主張が批判を受けるのか。 その発想の過程に興味がある。 なぜそこまで「オープンソース俺定義」を守りたいのか。

OSD準拠のオープンソースを守ることのメリットについては 八田さんの記事が詳しい。

では、この定義でない似非オープンソースを守ることに意義はあるのか。 批判する動機はなんなのか。

• どこかで聞いたオープンソースという言葉の語感から捏造した俺定義を使い続けたい。
• あるいは自分が誤解していたと認めたくない。
• オープンソースという単語から自由の意味合いを取り除きたい。 他人の自由はうとましい。
• いや、そんなことはどうでもよい。 他の人の記述を批判する態度が気に入らないから批判する。
• その他。

「他人の自由」そのものに反発する人ってのはそんなにいないと信じたいので、 スラッシュドットにそんな意図の人はいなかったと希望的に仮定すると、 その反発ってのは表現(だけ)によって引き起こされたのだろうか。

表現にカチンときて反発されたのだとしたら、 オープンソースのメリットなんてどーでもいいってことなのかなあ。

あと、オープンソースはすでに登録商標です。

_ [OSS]戦略を練る

いずれにしても気分が悪かったので、やり方を考え直してみよう。

オープンソース運動の成功は「オープンソース」という単語が正しく用いられるかどうかではない。 もちろん正しく使われるに越したことはないけど。

それよりもむしろ

• より多くのソフトウェアがオープンソース準拠のライセンスで公開されること
• より多くの人がオープンソースソフトウェアの開発に関心を持ち、支援すること

が成功といえるだろう。前者は開発者へのアピール、後者はいわゆる中間層へのアピールである。

匿名で意見を述べる人たちは(潜在的には開発者あるいは中間層なのかもしれないけど)、 匿名に隠れている間は、結局無責任なエンドユーザなので説得したり交渉したりする必要はない。

ということは、開発者には

• オープンソース化によるメリット
• オープンソース化によるデメリットの無さ

を紹介し、中間層には

• 「正しい」オープンソースビジネス
• 「正しい」オープンソース開発者支援

の事例を紹介するべきなのだろうか。

_ [OSS]開発者の不安

オープンソースでない無料ソフトウェアを開発している人々が、 正しいオープンソースにしない理由ってのはなんなんでしょうね。

もちろん、彼らを強制することはできないわけだが、 彼らの抱えている不安と誤解を解消することで、世の中の幸せの総和が増えるかもしれない。

_ 雷

ただいまの松江地方は雷が鳴っております。

_ [TV]『学園戦記ムリョウ』

以前、BSで放送していた時には見逃していて、 今回教育チャンネルで再放送しているものは録画しつつ見ている。

黒板がディスプレイ化し、ノートの代わりにノートPCを広げる教室の様子など、 近未来の表現がなかなか芸が細かいし、登場人物の性格が良いところが結構気に入っている。 話の展開ものんびりしつつ、少しずつ謎を深めていく感じで気持ちいい。

でも、録画が削除されちゃった関係で、2週ほど見逃していたら話が少々妙なことになっている。 いや、ストーリーとして宗教を扱うのは日本に限らずあちこちにあるんだけど、 このスタッフならもうちょっと別の流れでもきれいに話を進められたのではなかろうか。 神さまが宇宙人だったってのはいくらなんでも安易すぎ。

苦情を言うほど無粋ではないが、個人的にちょっとがっかりしたのは確か。 でも、そこはおいておいてもまだ面白いのだ。

_ [OSS]RubyライセンスとOSI承認

また聞きなのですが、sourceforge.jpにプロジェクト申請する際に、

と言われることがあるんだそうです。まあ、至極もっともです。

で、OSI承認の申請をしませんかと勧められました。承認されると OSIのリストに加えていただけるそうなのです。

申請の手順は<URL:http://www.opensource.org/docs/certification_mark.php>にあるそうです。

しかし、Rubyのライセンスは PerlのArtisticライセンスを少々いじってできているので、Artisticが持つ問題と類似の問題を抱えています。 よって、GPLとのデュアルライセンス以外の局面でまともに使えるとは考えていません。

GPLを適用した時点でOSD準拠ですから、 改めてOSI承認を求めて、単体では問題をはらんだライセンスをリストに追加する必要はないと思います。 GPLに抵抗があるだけなら、単純にBSDライセンスにした方が良いと思います。

Rubyのライセンスがあれなのは

• 開発当初のregex.cがGPLだったのでGPLを適用する必要があった
• でも、自分が書いたコードについてはより緩くしたかった

という理由ですから、そういう事情のないソフトウェアがRubyライセンスを適用する必然性はほとんどないと思います。 ということで、自分のソフトウェアに安易にRubyライセンスを適用しないように。 また、万が一必要があって適用することがあってもGPLとのデュアルライセンスを選択してくださいね。

なお、Riteでは以下のライセンスを採用するつもりです。 こっちは単体で適用するつもりなので、OSI承認なのかどうか調べないとな。

/*
 * Copyright (C) 2003 Yukihiro "matz" Matsumoto
 *
 * Permission is granted for use, copying, modification, distribution,
 * and distribution of modified versions of this work as long as the
 * above copyright notice is included.
 */

_ [OSS]Rubyライセンス

今書いたことですが、どうせ不可分なら、なひさんのおっしゃるように「Rubyライセンス」でデュアルを指すとしてしまった方が絶対いいですよね。なんでこんなことに気がつかなかったんだろう。 幸い、ライセンスの条文に「GPLまたは以下の条件」と書いてありますから、ますます都合が良いですね。

ということで、みなさんこれからRubyライセンスという時には 「GPLとのデュアルライセンスである」と覚えてくださいね。

まあ、いずれにしても現在積極的にRubyライセンスを利用する必然性はないんですけどね。

あ、白状すると昔は意味があると思ってました。不勉強でしたから。

_ [教会]岡山訪問

岡山で会議。夕べ夜更かししたせいで途中眠くて困る。

久米南の辺りで今月もまたツーリングの一団に遭遇。やはり岡山はツーリング人口が多いのか。 日差しがまぶしい。

会議では情報共有と水平展開が話題に。関係者全員がIT化されていないのが問題といえば問題だな。

_ [OSS]フリーソフトウェアライセンス診断

あなたが自分で開発したソフトウェアをフリーソフトウェアとして公開しようとしたとしよう。 その時にどのライセンスを選ぶか迷ってしまうかもしれない。たくさんあるしね。

ここではそんなあなたにどんなライセンスがぴったりか診断してあげよう*1。 そのためにはいくつかの質問に答えてもらう必要がある。

やってはいけないこと

ライセンスの選択として決してやってはいけないことは、自分用の新しいライセンスを作ることだ。 自分の経験から言って、これは避けた方が良い。俺ライセンスには危険がいっぱいだ。

• 実はGPLコンパチでなく、GPLソフトウェアとのリンクに問題が生じるかも
• 実はOSDコンパチでなく、フリーソフトウェアやオープンソースソフトウェアの条件を満たさないかも。
• 法的な不備がある、あるいは有効なライセンス文書でないかも
• そのライセンスを読んだ人が理解できず、結局問い合わせを受ける破目になるかも

既存のライセンスでは満足できないと思うことはあるかもしれないが、 既存のライセンスを選んだ方が無難だ。 既存のライセンスはそれなりに考えられているし、 広く知られているぶんだけみんなに理解してもらいやすい。

自分独自のこだわりというのは実はあんまり重要じゃないことが多い。 たとえば、私がRubyライセンスを定めた時には、 コードの一部を引用することについて明示的に許可したいと考えた。 しかし、実際にはBSDライセンスやGPLでも(少々明示的でないだけで)十分にカバーできる。

質問1

最初の質問は

である。もちろん、あなたには報酬はない。断りさえないかもしれない。

これが許せないと思うあなたはGPLを選択すべきである。 GPLならあなたのコードを組み込んだソフトウェアには同様にGPLを適用する必要がある。 ソース非公開で自由でないソフトウェアに利用される組み込まれる危険はない。

また、あなたは自分の書いたコードのライセンスを任意に設定できるので、 商用ソフトウェアに組み込みたい人が(有償で)特別のライセンスを結びたいと申し出るかもしれない。 いずれにしてもあなたに損はない。

質問2

これにYesと答えたあなたは当然GPLを選択すべきである。

その他のライセンス(の多く)は利用者がコードを自由でないソフトウェアに流用することを容認する。 これは結果として不自由なソフトウェアを容認し、間接的に支援することにつながる。 フリーソフトウェア運動に賛同するあなたにはGPLをお勧めする。

質問3

つい昨日「Rubyライセンスを選択する必然性はない」と書いたばかりだが、必然性のあるケースがひとつあった。 Rubyの一部として配布する場合にはRubyライセンスを選んだ方がいろいろ都合が良い。 異なるライセンスのものを混ぜるのはいろいろ面倒だからだ。

同様に他のソフトウェアと同時に使われる、また将来その一部になりえるソフトウェアの場合には ライセンスを揃えておいた方が得策だ。

最後に

ここにたどりついたあなたは自分のソースコードが自由な状態にあることには関心があっても、 そこからの派生物はどうなってもよいと考えているはずだ。

そういうあなたにはBSDライセンスまたはMITライセンスのいずれかをお勧めする。

知名度から考えるとBSDライセンスの方が誤解が少ないかもしれない。 BSDライセンスの場合、宣伝条項のない新しいものを選ぶこと(上記のリンクは新しいものである)。

Apacheライセンスは宣伝条項エンドユーザドキュメント条項を含むので選択すべきではない。エンドユーザドキュメント条項とは

3. The end-user documentation included with the
   redistribution, if any, must include the following
   acknowledgment:

      "This product includes software developed by the
      Apache Software Foundation (http://www.apache.org/)."

   Alternately, this acknowledgment may appear in the
   software itself, if and wherever such third-party
   acknowledgments normally appear.

のようなものだ。これがあるとたとえばディストリビューションのドキュメントには似たような告知を延々と書き連ねなければならない。これは結構不自由だ。

もしも、ユーザにオリジナルのソースコードの入手先を告知したいのであれば、 Sleepycatライセンスというものもある。 しかし、先にも述べたように独自のこだわりでマイナーなライセンスを選ぶリスクは覚悟しておくべきだ。 どうせ、昨今ソースコードの入手先はWebで検索すればすぐ分かるので告知は不要というのもひとつの考え方だ。

フリーソフトウェアのライセンスに関する判例は日米ともにほとんどない。 専門家の間でもこれらの文章の法的な有効性すら確定的ではないそうだ。 となると、ライセンス文書は「開発者が自分のコードをどう扱ってほしいのかの意思表明」と考えるべきだろう。

あなたは自分のコードをどう扱ってほしいのか、どう扱ってほしくないのか。

追記:

Apacheのこの条項はBSD宣伝条項とは違うのですね。勘違いしてました。 解説するなら条文くらいちゃんと読みなさい ＞ 自分。

見返してみるとBSD宣伝条項ほどダメージは深刻ではないですね。 ただ、それでも面倒なのは確かなので私はお勧めしません。

追記2:

拡充していくことができればこれに越したことはないと思います。 追加する質問や条件などは歓迎します。

_ メールリーダ妄想

私はここ10年以上メールリーダとしてcmailを使い続けているわけだが、 最近違った形のメールリーダが欲しいなと思っている。 以下のような条件を満たすMUAがあれば乗り換えちゃうかも。

• 文章作成はEmacs(Emacsフロントエンドを持つ)
• 数千(あるいは数万)通のメールでも(私のマシンで)さくさく動く
• Bayesianフィルタ的自動分類
• 全文検索機能

「Bayesianフィルタ的自動分類」ってのは、現在SpamかSpamでないかを判定するために使っているBayesian検定を 各フォルダごとに行うということだ。 「このメールは仕事用」とかフォルダに分類してくと 勝手に賢くなって仕事っぽいメールは適切なフォルダに分類してくれるというのが望ましい。 とはいえフォルダの数だけデータベースを持つというのはデータ量からも計算量からも富豪的過ぎるかなあ。

全文検索機能はある程度以上大量のメールを扱う時には必須になるだろう。 たぶん、検索結果を抽出した仮想フォルダのようなものも必要だと思う。

すでに似たような機能のMUAはありそうな気がするのだが、どうだろうか。

_ [OSS]オープンソース定義を拡大せよっ

通りすがりの人が指摘してくれたような 批判は スラッシュドットでもたくさんある珍しいものではない。 匿名ではないというところが見込みがあるけど。

しかし、以前にも書いたが、この人たちの思考の過程には興味がある。 いったいなにを主張したいのだろう。

前提となるのは以下の主張だろう。

これは、理解できる。私も同意する。ストールマンも最初からそう指摘しているし。

しかし、批判にはそれに続く以下の前提を含まれているように感じられる。

これはどういうことだろうか。この前提は正当なのだろうか、当然なのだろうか。 誤解しやすいから誤解してもよいのか、誤解を拡大再生産してよいのか。

世の中にはふたつの単語の合成語で個別の単語を組み合わせた意味と違う、 あるいは組み合わせた意味よりも狭い意味でしか使わない単語はいくらでもある。 違う例としては「ジャングル・ジム」(密林の体育館)、 狭い例としてはたださんのあげられた「携帯電話」がある。

携帯電話について

という主張はかなり滑稽に聞こえる。 正直なところ、私には「オープンソース批判」も同じように滑稽に聞こえるのだ。

そのような滑稽な主張を始めてしまう理由はなにか。興味深い。

_ [OSS]オープンソース定義を拡大せよっ(その2)

いや、批判派は「ソース」を「ソースコード」という意味にしか使っていないので生ぬるい。 技術者でない一般の人が「ソース」という単語を聞いて「ソースコード」なんて意味に捉えるはずがないだろう。 「ソース」といえば「源泉、源」である。

つまり、オープンソースというのは「出所が明らかであること」を意味するに決まっている*1。

要するに最近話題になっている「トレーサビリティ」を含む広い概念なのだ。 たとえば、この肉はどこの牧場から来てて、その父親と母親はどの牛でということまで、 すべてのソース(出所)がオープンなのである。

オープン万歳。

そして、すべてのニュースソースをオープンにする「オープンソース・ジャーナリズム」。

なんだかものすごいもののような気がする。守秘義務はないのか。

_ [OSS]なぜ「オープンソース」なのか

気が付いている人もいるかもしれないけれど、 私は微妙に「オープンソース」と「フリーソフトウェア」を使い分けている。

私の気持ちとしてはRubyはあくまでもフリーソフトウェアであり、 オープンソースソフトウェアはフリーソフトウェアを含むので *1、 オープンソースソフトウェアと呼ばれることを受け入れるというのが私のスタンスだ。

では、そんな私がなぜオープンソースという言葉の定義にこだわるか、といえば、それは実利のためである。

残念なことに企業はプログラマの自由には関心がない。 企業が一番に関心を持つのは、それは儲かるのか、ということだ。 これは事実で、Richard Stallmanの長年の闘争がビジネス的にはあまり成功していないことからも分かる。

しかし、フリーソフトウェアの開発スタイル(の一部)は実は企業にとってもメリットがあることを、 Eric Raymondは『伽藍とバザール』と続く論文で示すことに成功し、 それとともに「オープンソース」という単語も導入した。

これによって「オープンソースはビジネスになる(なりえる)」というコンセプトが生まれたのだ。

このコンセプトはほとんど武器を持たない我々フリーソフトウェア開発者にとって 「中間層」を刺激し、取り込むための重要な「道具」である。 しかも、その効力は(少なくとも日本では)まだ消え去ってはいない。 まだ使える道具なのだ。

この道具を手放すのは愚かだ。

私は、オープンソースというキーワードを利用して、 今以上にフリーソフトウェアに対する支援を引き出せると考えている。 また、フリーソフトウェアによるソフトウェアの自由がより豊かな社会を実現できるとも考えている。 そのためには、この道具にまだまだ効果的に働いてもらう必要があるのだ。

あくまでも推測だが、オープンソースはソース公開の意味しかないとする人は

• 不勉強
• あきらめている
• オープンソースという「道具」の破壊を意図している

のいずれかではないだろうか。

不勉強の人たちには教えれば良い。 なんか逆ギレしてる人たちもいるようだが、あきらめずに紹介し続けよう。 彼らは知らないだけなのだ。 オープンソースという言葉を正しく使う時にはメリットがあり、 そうでない時にはデメリットがあることを知らせよう。

あきらめている人たちには「あきらめるな」と伝えよう。 日本ではコンピュータ関係の層が薄いせいもあって 「オープンソース」という単語が一般社会には知られていない。 知られているにしても「なんか今までにないやり方」くらいのレベルでしかない。 少なくとも私の近くの非業界人は「全然知らない」か 「単語を聞いたことはある(が意味は知らない)」のいずれかであった。 どちらも(彼らが知りたいと思えば)正しい知識を教えるのは容易である。 一方、業界人にはオープンソースを正しく理解している人が一杯いる。 実はうるさいだけで「オープンソース＝ソース公開」だと頑固に考えている人こそ少数派なのではないか。 統計をとっていない以上そうでないと誰が言えよう。

言葉の「新しい意味」の導入を謀る人は、 その意味が本当に「もっとも良く使われている」ことを示す必要がある。 そうでなければ単なるFUDだ。我々は古い意味を守る側なのでその義務はない。

オープンソースという手法に反対し、破壊しようとしている人たちは、 決してその意図を明らかにしようとしないだろう。それは「陰謀」なのだから。 そういう人はいないかもしれない。でも、いるとしたら すでに「あきらめている人」のフリをして、我々もあきらめさせようとするだろう。 あきらめてはいけない。

最後に。「オープンソース」という言葉すべてについて言葉狩りをするのは意味がない。 「ケータイ」がPHSを含む時もあり、そうでない時もあるように、会話の中での オープンソースも文脈によって単なるソース公開を意味する時もあり、OSD準拠の時もあるだろう。 しかし、「オープンソース＝ソース公開だけ」という誤解を再生産するような記述や、 オープンソースという言葉の効力を損ねるような発言は指摘し続ける必要があると思うのだ。

_ [OSS]OSD Certified

アメリカではOpen Sourceが商標を取れなかったこともあって、1999年ごろOSD準拠のソフトウェアを OSI Certified Open Source Softwareと表示して明確にしようという戦略に変更したということは 知っている人も多いだろう。 私は最近まで知らなかったけど(ダメすぎ)。

でも、自分からOSI Certifiedと名乗るのはなんか違う気もする。 ここはいっそOSD準拠のライセンスを持つソフトウェアをOSIが一方的に

と認定してしまうのはどうだろう。んで、リストに追加しちゃうの。 こんなに膨大な数のソフトウェアがOSI Certified Open Sorce Softwareですって。

いいアイディアだと思うんだけどなあ。 Freshmeatあたりを利用すればすぐにできそうだし。

_ [OSS]ソース公開ソフトウェア

ところで、ソース公開しているけどOSD準拠でないソフトウェアってのはどんなものがあるだろう。

HORBのように作者の主張が強すぎて結果的にOSD準拠でなくなったもの、 Delegateのように勤務先の制約でOSD準拠でなくなったものは理解できる。 これを「気持ちだけオープンソース」ソフトウェアと呼んでみよう。

また、「マイクロソフトシェアードライセンス」のような 「見せるけど再配布はダメ」というのは、 セキュリティ検証の観点とオープンソースに対する対抗という観点の両方から理解できる。 呼ぶとしたら「オープンソース対抗」ソフトウェアかな。

それ以外にはどんなものがあるだろう？

深い理由はなかったとして、 それらをオープンソース化するように勧める良い手段は？

_ [OSS]オープンソースってなに？

たしかに、 オープンソースについて全然知らない人に説明する時に「だまってここを見よ」 というようなサイトがあれば便利ですよね。

私の知ってる中で一番良さそうなのは<URL:http://www.catch.jp/openoffice/open.htm>です。 ただ、私の感覚は人とはずれてるみたいなんですが。 たぶんこれなら大丈夫だと思うんだけど。

ほかにも良いサイトがあれば紹介してください。

_ [Ruby]Ruby 1.8.0 preview3

「オープンソース」などにかまけていたら、SeanがREXMLをコミットしてしまった。 REXMLがコミットされたらすぐにpreview3を出すと予告していたので、 作業が必要だ。

だいたい片づいているんだけど、Block/Procについては少々悩みが残っている。 あと、原稿の〆切が...。

_ [Ruby]BlockとProc

コードブロックをオブジェクト化したBlockと、 無名関数オブジェクトとしてのProcを分離しようというのが元々のアイディアなのだが、 使い勝手という点でやや難点がある。

要するに使い分けが難しいのだ。似過ぎていると言ってもよい。 Dave Thomasからもこの変更の導入直後に指摘を受けた。気持ちは分かる。

で、いくつか考えているのだが、結論は出ていない。が、私の考えの経過に興味を持つ人もいるだろうから、 ここの書き連ねておく。"Think out loud"だと思って読んでほしい。

BlockとProcの使い分けについて

当初の目的は上に述べた通り「コードブロックをオブジェクト化し たBlockと、無名関数オブジェクトとしてのProc」の分離である。 が、実際に使っていると混乱してきそうだ。

そこで生成の仕方を明確に分離することにした。 Block.newはブロックなしで指定すると現在のメソッドに与えられているブロック (yieldの対象)をオブジェクト化するが、 Procの方はブロックを与えなければ警告する(最終的にはエラー)。

これでProcはあくまでも関数オブジェクトでlambda, proc, Proc.newはブロックをくるんだ 関数オブジェクトを返すという意味づけができる。 最終的にはDave Thomasの提案に沿って「関数オブジェクトを作る構文」を導入してもよい。

あ、そうそう。この意味づけを強調するために近くBlockとProcの継承関係を外すつもりだ。 ところどころで見かける

p.kind_of?(Proc)

のようなコードは、今のうちに

p.respond_to?(:call)

に変更することをお勧めする。

互換性問題

Blockっていうのはかなり一般的な語彙なので、すでに使っている人がいるかもしれない。 というか、実際に問題が起こったケースもあるようだ。

Methodとの類推

無名の関数オブジェクトってメソッドオブジェクトたるMethodと似過ぎていると考えることもできる。 BlockとProcとMethodと、callで呼べる似たようなものが一杯あるのは望ましくないかも。 まあ、それぞれ生成方法が明確に異なっているから、Polymorphicに同じなら気にしないというのが Dynamic Typedな考え方なのかもしれないけど。

というわけで、最終解決案(の候補)

1.8.0では以下のいずれかになるのでは。

1. BlockとProcは親子ではない。BlockとProcとMethodがある。生成方法が異なる
2. Blockが残り、ProcはMethodとunifyされる。実装が大変。
3. BlockはProcに戻る。無名関数オブジェクトはMethodにunify。実装が大変。

リリースのタイミングを考えると最初のものが一番ありそうだなあ。

_ [原稿]Linux Magazine

もうそろそろ８月号の〆切が迫っています。 今月のテーマは「エクストリーム・プログラミング」にしようかと思ってます。 もはや「初等」でも「入門」でもありませんな。

今後の内容については〆切を乗り切った後、更なる考察が必要そうです。

_ [OSS]タダ働きが世界を動かす

essaさんによるわかりやすい解説。

しかし、私の文章はターゲットが明確でないのか。もうすこし検討の余地があるなあ。 実際には「開発者」と「中間層」しか対象にしてない文章でも 「エンドユーザ」的立場で読むと違う印象を与えるかも。

_ [XP]『エクストリーム・プログラミング入門』

というわけで、あらためて『XPエクストリーム・プログラミング入門』を読み返す。 少々泥縄ぎみ。

最初読んだ時には、えらいわかりにくいなあと思ったが、今回はわりとすんなり頭に入る。 「入門」とは書いてあるが、きっとある程度の知識と経験を要求する本なのだろう。 だが、このわかりにくさは翻訳のせいではないかと疑う。原書は読んでないけど。

『オブジェクト指向入門』ほどタイトルに偽りがあるわけではないが。 そういえばこれも翻訳の問題だ(原題は『Object-Oriented Software Construction(オブジェクト指向ソフトウェア構築)』。全然入門じゃないじゃん)。

_ [日記]ハッカーとしての立場

社内MLで

と書いたら、「Matzにっき」はHackerとしての立場で書いてるんじゃないの、と聞かれてしまった。

えーと、この日記は「Matzの日記」つまり私のいろいろな側面を反映してます。 Hackerとして書くこともあれば、父親として書くこともあります。 オープンソースのことを書いてる時には、 オープンソースエバンジェリストのつもりでいます。

エバンジェリスト(伝道師)といいながら、実際問題、上手に宣伝活動ができてるとはいいがたいけど、 すくなくとも話題を提供し人々に考える機会を与えることには成功したかも。 オープンソースに悪い印象を持つ人も出たみたいだけど。涙。

_ [OSS]立場による言葉の使い方

反省すべきは、私が文章を書く時に対象にしている相手の立場がはっきりしていなかったことだろう。 実際に予想以上にいろいろな人が私の文章を読み、いろいろな印象を持ったようだ。

で、私が「オープンソース」という単語に対してどのように接してほしいのか、 ということを立場ごとに書いてみることにした。これはもちろん私の希望であり、 強制されるたぐいのものではない。

また、あらゆる立場を網羅することは不可能なので、典型的な3つだけを考えてみた。

エンドユーザ

つまり、オープンソースソフトウェアのユーザである。 オープンソースソフトウェアを単に利用するだけで、別に開発に参加しようなんて考えてない。 タダなのはありがたいなあと考えているくらい。

このような人に対して期待することは 「オープンソース」ってのは単に「ソースを公開」以上の意味があるんだよ、 ってことだけ理解してほしい。OSDを理解する必要なんてない。 「それ以上」がどの程度かなんて知る必要もない。 「＋α」の部分があることを知ってもらうだけで十分だ。

開発者

ソフトウェア開発者にはもうすこし理解してほしいことがある。

それは自分のソフトウェアを一般に配布する時には、 バイナリ配布の無料ソフトウェアでもなく、 独自のライセンスのソフトウェアでもなく、 OSD準拠のライセンスを持つオープンソースソフトウェアにする方が結局は有利だ、ということだ。 これだけでいい。

なぜそうなるのかについては、これからおいおい「啓蒙文書」を書いていこうと思う。 とりあえずはEric Raymondの文章を読んどいてくれ。

中間層

「中間層」ってのは前にも説明した通り、開発者とエンドユーザをつなぐ役割の人のことだ。 たとえばディストリビュータだったり、システムインテグレータだったり、 シンクタンクの人だったり、官僚だったり、ベンチャー企業の人だったり、IT関係の記者だったり。 ベンチャーキャピタリストは...、入らないかな、もしかして。

そういうような人には期待することがひとつある。ひとつは、OSDの存在を理解してほしいことだ。 中身を完全に理解する必要はない。存在を忘れないでほしいだけだ。 ただ、「オープンソースとは」なんて説明をするときには自分勝手な定義を人に紹介しないで、 OSDへのリンクを張ってほしい。少なくとも「ソース公開＋α」であることだけが伝われば良い。

中間層にはこの期待に応える理由がある。前にも言ったが「オープンソース」という単語は道具である。 そして、それは誰のための道具かというと実は中間層にとってもっとも有効な道具なのである。 オープンソースって単語に残っている「今までと違う」イメージは、 キャピタリストからお金を取ってくるのに役立つかもしれない。 潜在的顧客に自分の優越性を印象づけるのに役立つかもしれない。

そのような道具の効力を維持するためには「オープンソース」という単語に なにか不思議な「＋α」があると思わせておく(って実際にあるんだけど)必要がある。

わざわざ自分の道具を捨てる必要はない。

これなら「OSD原理主義」などとみなされることはないかな。 べつにどう見なされてもいいんだけど、OSDに関しては原理主義じゃないしな。

私は開発者としてはフリーソフトウェア開発者で、 フリーソフトウェアであればOSDなんてどうでもよいと思う気持ちもある。 でも、まだ残っている「オープンソース」というコトバの効力を失わせず、幸福の総和を増やすためには この程度のことは最低限必要だろうと思っている。

_ [OSS]気持ちだけオープンソースソフトウェア

世の中には、ほとんどオープンソースソフトウェア (この場合は「ほとんどフリーソフトウェア」といったほうが良いかな)でありながら、 微妙な条件によってオープンソースソフトウェアと見なされない 「気持ちだけオープンソースソフトウェア」というのがある。

たとえば、バイナリの再配布を許さない *1 qmailなどのdjbソフトウェアや平和利用に使用目的を限るHORBなど。 原子力関係には使うなってライセンスもあったな。 うちの会社がかかわっているORCAプロジェクトもOSD準拠でない(精神は満たしている、らしい) ライセンスになっている *2。

そういう条件を付けたいのは本人の気持ちや事情の問題ではあるし、 なんとなくわからないでもないんだけど、 そういう条件のない「普通の」ライセンスにした方が、エンドユーザもコミュニティも中間層も楽になって、 幸せの総和が増えるんじゃないかと思う。

_ [言語]手話

手話による勉強会に参加する。あれはすでに別の言語だ。全然単語が覚えられない。

今日覚えた単語

• 木
• 実
• 食べる
• 本
• 見る
• 分かる
• 良い/悪い
• その他いろいろ。

しかし、きっとすぐに忘れてしまうだろう。というか、もう忘れているものもあるな。

_ [Linux] mozilla-firebird

今までMozillaを使っていましたが、今日からMozilla Firebirdに置き換えてみました。 たしかにちょっとだけ機敏に動くかな。 どうせメールリーダなどには使ってなかったので機能的にはこれで十分。

数日使って様子を見よう。

_ [OSS] 「オープンソース」の秘密

あ、そうか。別に俺定義を駆逐する必要はないんだ(どうせ無理だから)。 気負い過ぎていたかもしれない。

こういうのはどうだろう。

「オープンソース」でうまくやりたいなら、 オープンソースに隠されている「秘密」を知らないといけないんです。

ってのは。で、「うまくやりたい人」がその「秘密」を聞いてきたら、

うふふ、秘密です。

「オープンソースの定義」や その解説を研究したら分かるかも。

と返すのだ。自分で学んで得た知識は役に立つぞ、きっと。

口をあけて教えてもらえるのを待っている人は成功できない、と。 成功したいなら甘えてちゃいけないよね。

やりすぎ？ 不親切すぎるかなあ。

じゃあ、「本当に知りたいなら教えてあげます」は？

_ [OSS] エンドユーザへのスタンス

ユーザに対するスタンスですか。 前にも書いたように、 純粋なエンドユーザは「オープンソース」とは直接関係ないんです。

ですから、正直なところ私は純然たる「エンドユーザ」に対して どのようなスタンスを持つべきかということについて 結論を持っていないのです。

ちょっと考えてみよう。

まず「エンドユーザ」という言葉が指すものは「オープンソース」以上に広くて、 人によってとらえ方も違いそうで、そもそも「有意義なスタンス」が存在できるかということさえ疑問だ。

仮に「エンドユーザ」が単なるソフトウェアのユーザであった場合、彼らになにを伝えるべきか。

「ソフトウェアの自由」は現時点での彼らには意味がない。 彼らにとってソースコードはあってもなくても同じだ。 重要なのは「無料かどうか」しかない。 そのような彼らは「オープンソース」だろうが「フリーソフトウェア」だろうが、 無料ソフトウェアとしか捕らえないだろう。

しかし、そういう彼らもある時プログラミングに関心を持ち、 開発者の一員になるかもしれない。だから、彼らに今伝えるべきメッセージは、

「オープンソース」っていう今までにないやり方があって、 そのおかげでこのソフトが無料で手に入るんだよ。

でも、無料ってだけじゃなくて、 そのやり方でプログラムを作ると開発がすっごく「楽しい」んだって

ではないだろうか。ここで「楽しい」の部分は適宜「成功できる」とか良さそうな言葉に置き換えるとして。 要するに、将来に開発者になった時にじゃまにならない程度のメッセージを伝えれば良いということだ。

しかし、上のはかなり方便な説明だな。

• 「今までにない」はほんとじゃない
• ここで行ってるのは厳密には「オープンソース」ではなく、「バザール開発」ではないか

いかん。もうちょっとマシな説明を考えていく必要があるな。

_ [会社]新人歓迎会

中途入社の歓迎会。おなか一杯。服が煙草臭い。勘弁してほしい。

_ [OSS]オープンソースとバザール開発

たくさんのコメントありがとうございます。私にとっても刺激になります。

オープンソースはバザール的な要素を含むかということですが、 これは微妙です。というのも

• 少なくとも「オープンソースの定義」にはバザール開発を含まない
• その背景も「ソフトウェアの自由」であってバザール開発は含まない
• 全てのオープンソースソフトウェアの開発がバザール的とは限らない

という事実があり、また一方では

• 「オープンソース」のポジティブなイメージはバザール開発と不可分
• 「オープンソース」の楽しさにもバザール開発は不可欠

というも事実だからです。

_ [TV]スペイン語講座

ふと思い立ってNHK教育のスペイン語講座を眺める。 なんか理由は分かるような気がするけど。

...だめだ、やっぱり新しい言語は覚えられない。プログラミング言語ならまだ大丈夫だと思うんだけど。 でも、Haskellとか身についてないよなあ。

_ [OSS]エンドユーザに対するスタンス(その2)

ああ、エンドユーザとひとくちに言ってもレベルがそれぞれという罠。

1. 単なるユーザ。フィードバックのつもりもない
2. バグレポートなどフィードバックするつもりはあるユーザ
3. プログラムの改善に協力する(意見を言うなど)とか、もう少し積極的なユーザ
4. パッチを作るなど開発にかかわるユーザ(もう開発者か)
5. 開発者

で、(1)のレベルのユーザについては 前述のような「将来じゃまにならないようなメッセージ」が必要なんだろうなと思うんです。 あ、hsakaさんがおっしゃるようなrespectの気持ちはぜひ持ってほしいなと思います。 XPでもオープンソースでも日常生活でもrespectの気持ちは重要ですよね。

で、Tmbさんの意見である宣伝・広報活動については微妙*1な気持ちを持ってます。純粋に開発だけを考えるとユーザはそんなにたくさん必要ないんですよね。 むしろ、広がりすぎたコミュニティやいろんなタイプのユーザに振り回される危険性まであります。 船頭多くしてってやつですね。だから、開発者としての私は「そんなに要らない」と思ったり。 むやみに(1)から(2)への移行を勧めるのも考えものです。

しかし一方、ビジネスとして成立したり、有効な支援を受けたりするためには知名度や普及度が大いに関係します。 だから、オープンソースエバンジェリスト(自称)としての私は「ぜひ必要」と思ったりするんです。 かなり矛盾してます。まあ、開発者と中間層の立場をひとりで兼ねようとするから起きる矛盾なんですが。

ユーザ数についての暫定的な結論:

• 開発者はたくさんのユーザを必要としていない
• 中間層はたくさんのユーザを必要としている
• たくさんのユーザは中間層を通じて開発者に対する間接的なメリットになる

_ [OSS]ライセンスの適用

6月11日の記述に対するnaruseさんの意見は興味深いと思います*1。

乱暴に要約すると

• naruseさんは(理由があって)既存のライセンスを使っていない
  • 著作権表示についての細かい調整ができない
  • 改変したソフトウェアの扱いを制御したい
  • 日本語のライセンスにしたい
• ライセンスを適用する方法がいまいちわからない
  • 特にBSDライセンスの適用の仕方

ということだと思います。

前にも書きましたが、やっぱり独自ライセンスはお勧めしませんです。

結局は自分のエゴとユーザの利便性のどちらをとるかということなのだと思います。 もちろん開発者は自分が開発したソフトウェアに対していかような決定も行うことができます。 そして、開発者にはユーザに守ってもらいたいいろいろなことがあるのだと思います。

たとえば、

• 自分で使う分については著作権表示を削ってもかまわない、 けれど、改変したものについては著作権表示を残さないとダメ、
• ソフトウェアを改変していて原型が無くなったら著作権表示を削ってよい*2

気持ちは分かります。

10年前の私も自分の「願い」を表現したライセンスを作ったことがあります。しかし、私は問題ないと思えたこのライセンスは実はGPLコンパチではないのです。以前Stallmanから直接指摘されました。

GPLコンパチでないということは、上記のライセンス(GPLでない部分)だけを適用したソフトウェアは

• FSF的にはフリーソフトウェアでない
• GPLソフトウェアと合法的にリンクできない

ことを意味します。自分ではよかれと思ったことなのにこんな面倒なことになるとは。 しかもどこをどう直せば自分の「願い」を実現しつつGPLコンパチにできるのか、 そもそもそんなことが可能なのかさえさっぱりわからないのです。 こうなると私の願いはそんなに重要なものだったのだろうかという気になります。 実はどうでもいいことだったんじゃないかと。

簡単に言うと「他のライセンスと組み合わせても問題のないライセンスを作ることはとても難しい」ということです。 そして、オープンソースソフトウェア(フリーソフトウェアでもよいけど)はその性質上さまざまなソフトウェアと組み合わせられることがとても多いのです。

「オープンソース」の示唆するものの中には

開発者のエゴを抑えると開発者自身を含めてみんながハッピーになれる

ということもあるんじゃないかって気がします。

独自ライセンスで実現したい「開発者のエゴ」は妥協できないものなのでしょうか。 よくよく考えてみると独自ライセンスのデメリットほどは重大ではないのではないでしょうか。

個々のソフトウェアがそれぞれ違うライセンス条項で配布され、 なにができてなにができないのか個別に(場合によっては専門家に相談して)検討する必要がある 面倒な事態を拡大するよりは 広く知られているライセンスを利用した方が賢明ではないかと最近では考えています。

「できればやってほしい」ようなものはライセンスに取り込まず、 READMEなので「お願い」するって手があります。ライセンスは万能の武器ではないのです。 なにもかもライセンスで実現する必要はありません。

ライセンスの適用に関してはソースコード自身か添付文章で「このライセンスに従う」と宣言するだけで構わないと思います。ライセンスを発行する主体と著作権者はライセンス文書そのものか添付文書に記述することになると思います。 ソフトウェアの作成日はライセンスには必須ではありません。

それから、OSIにあるBSDライセンスには元々宣伝条項が含まれていません。修正は不要です。 テンプレートに従い名前と年を埋めるだけで完成です。

_ [Ruby]知られざるRuby

先日うちが取っている新聞(地方紙です)で、松江の古書店がネット販売を開始し、 地方の書店で死蔵されたり捨てられたりする運命の古書をまた「生かして」やれるのが嬉しい、 というような記事を読みました。

古書店がインターネットというのは全国的には全然珍しいことではないのですが、 こんな田舎でもそうなんだねえと少々感心して読んでいました。

しかし、後で分かったことには、その古書店の主人はうちの会社の後輩のお祖父さんで、 管理システムの一部は彼が構築したLinuxサーバ上のRubyで動作しているそうです。

世間は狭いというかなんというか。

_ 救急車

うちの近所には毎日のように救急車が来ます。

今日、歩いて温泉に行ったら今日も救急車が来て、温泉旅館に入っていきました。 うーむ。

温泉旅館といえば、お風呂とお酒が付き物だからなあ。 酔っぱらってお風呂に入るのは危険です。気をつけましょう。

_ [OSS]日本語ライセンス

気持ちは分かります。多くの人は英語なんか普段使いませんし。

ライセンスの非公式日本語訳の問題は、自分のソフトウェアのライセンスよりも 既存のソフトウェアのライセンスの解釈に用いる場合ではないかと思います。 誤訳があって他人の権利を間違って侵害してしまった場合に責任が取れないということですよね。

自分のライセンスに誰かが日本語訳したGPLやBSDライセンスをつけることの問題は、 それよりは少ないと思います。たとえば日本語・英語の両方を添付して、 翻訳間で矛盾があった場合には英語が優先とか書いとくと、 もしかして苦労が少ないかもしれませんね。

日本語ネーティブのオープンソースライセンスについては、 誰がコストを負担するかですね。 本当に安心して(？)裁判に耐えられるようなライセンス(というものが本当にありえるとして) を作るためにはきちんと弁護士に相談して契約文書として作る必要があると思いますが、 それには個人では負担したくないくらいのコストがかかるでしょう。 さらにオープンソースライセンスについて不安なく相談できる弁護士が日本に何人いるのか。

やはりその辺をきちんとするコストを負担できる中間層の育成が必要なのでしょうか。

Open Source Group Japanにて日本語訳を集める とうのは面白い考えですね。誰に頼めばいいんだろう。鵜飼さん？

フリーソフトウェアのライセンスは権利者の意志の表明の要素が強いと思います。 そもそも実際に裁判でどのくらい有効かさえよくわからないというのが正直なところではないでしょうか。

となると、

• 現状のまま。起きるかどうかわからない裁判に脅えるのは無意味。
• 現状のまま。契約文書の作成にかならず弁護士が必要なわけではない。
• 将来の不安を解消するため積極的に弁護士に相談する(30分5,000円？)。

などいろいろなレベルが考えられるわけですが、どうしたもんでしょうね。 起きてもない裁判の不安をあまり強調するのは 一種のFUD効果を持つわけですし。

p.s.

今のBSDライセンスのことを「修正BSDライセンス」と呼ぶのは一般的なんですか。 私は逆に古いのを「宣伝条項付きBSDライセンス」と呼んでました。

_ [news][OSS]洲本市がオープンソース開発支援

日経ITproから。しかし本文を読むと

兵庫県洲本市は2003年7月中旬に、オープンソース・ソフトを使ったシステムの開発支援プロジェクトを開始する。プロジェクト名は「OSCA（Open Source Community in Awaji）プロジェクト」。

ということで、こっちが本当なら「オープンソースソフトを使ったシステムの開発支援」 っていうのは「オープンソース開発支援」という単語から想起するものとはだいぶ違うような気がする。

いや、あらかじめ断っておくと私はこのことを非難するつもりはない*1。 彼らはいわゆる「中間層」になるのだから、私としては拡大はむしろ歓迎する。

あとは、このOSCAなるプロジェクトが、単にオープンソースソフトウェアを利用するだけでなく、 なんらかの形で貢献できるところまで配慮して発展していくことを強く望むものだ。

_ [news]PHPでもJava開発を

ZDnet Japanより。そのうちRubyとかもなにかしたいって話になるのかしら。 そういう話がくれば光栄だけど。

で、注目したのはそういうことではなく、非常に些細なこと。

新しい規格はいいアイデアだとするのは、Pythonスクリプティング言語の作者であるホイド・ファン・ロスュム氏。

え、誰？

あ、「Guido van Rossum」ってのはオランダ語では「ホイド・ファン・ロスュム」と発音するんですか？ 彼は今アメリカにいるし、みんな「グイード・バン・ロッサム」みたいに呼んでたのでそう思いこんでました。

かくのようにカタカナ表記は難しいということで。

_ [家族]プール

家族を連れて少し離れた温泉プールに遊びに行く。

2時間ほどつかっていた(泳いだとは言わない)のだが、結構くたびれた。 やはり運動不足で体力が落ちている。 しかし、少しは運動した気になったし、子供たちは満足したようだし、 温泉につかって気持ちがよかったし、なんか充実した気がする。

_ [教会]米子ワード大会

今日は父の日だが、母の日に続いてたまたま今日も米子に訪問する責任だった。 統計の数字上は優秀な成績に見える人々が実際には問題に悩んでいるとか、 いろいろ考えさせられることもあった。

なかなかに忙しい日であった。

_ [TV]サンダーバード

日曜に録画したサンダーバードを息子を保育園につれていく前に一緒に見る。

私は4歳くらいのときにサンダーバードに夢中だったそうなのだが、息子も感動してみていた。 娘たちはさっぱり興味がないようなので、こういうところに男女差が出るのか。 別にとりたてて男らしく育てたつもりはないのだが。

_ [本]CODE

とある野望のために『CODE』を購入する。 『CODE』といってもLessig教授のじゃなくて、Petzoldの。 もちろん、Creative Commonsは面白い考えだし、Lessig教授にも注目してはいるんだけど。

知らなかったけどPetzoldって人はWindows関係の本をたくさん出している人なのね。 で、『CODE』での説明は...うーん、私の好きなタイプじゃないなあ。 まあ、このような本が本当に必要な人に伝われば、私が好きかどうかは関係ないんだけど。

_ [Palm]ケース破損

ずっと ベルトにさげたケースにVisor Edgeを入れて便利に使ってきたのだが、先日とうとう破損してしまった。 で、しかたがないのでEdgeをかばんに入れているとそれはそれは不自由だ。 やはりいつも持っているということに意義があるのだなあ。

とうことで、明日東京に行った時にでもさっそく新しいのを購入しよう。 田舎ではそんなものはなかなか売っていないのだ。

_ チケット確保

来週の「オープンソース政策についての討論会」と７月のOSCONのチケットが確保できた。 席が取れないかも、とちょっと焦った。 こんどはもうちょっと早く行動を開始しよう。

_ [Ruby]BlockとProcとMethod

以前に

1.8.0では以下のいずれかになるのでは。

1. BlockとProcは親子ではない。BlockとProcとMethodがある。生成方法が異なる
2. Blockが残り、ProcはMethodとunifyされる。実装が大変。
3. BlockはProcに戻る。無名関数オブジェクトはMethodにunify。実装が大変。

などと書いたが、その後改めて検討した結果ProcのMethodのUnifyは無理であることが判明。 となると(2)や(3)は採用できない。

そこで原点に帰って考え直してみた。

元々の動機は「ブロック引数で得られる『ブロックオブジェクト』とlambdaで得られる『手続きオブジェクト』は違うものではないか」という疑問に対する対応だ。

実際このふたつは違うもので、異なる挙動が要求されている(仮に前者をBlock、後者をProcと呼ぶ)。

• Blockは引数チェックがゆるい。breakやnextが例外になる
• Procは引数チェックが厳しい。breakやnextは実行の中断

それが理由でこのふたつのオブジェクトを異なるクラスに分離しようと考えたのだ。 ところが、実際にCVS版でBlockとProcを分離したところ、

• このふたつは似過ぎていてユーザへの説明や使い分けが難しい

という注文が付いた。困った。

そこでしばらく考えたところ、なにもこの2種類のオブジェクトのクラスを分ける必要はないことに気がついた。

仮にlambdaの定義が

def lambda(&block)
  Proc.new{|*args|
    # 引数の数チェック
    begin
      block.call(*args)
    rescue LocalJumpError => e
      case e.reason
      when :break, :next, :return
        return e.exit_value
      end
      raise e
    end
  }
end

のようなものだったら、別に同じクラスで挙動が違うことは十分に説明できるだろう。 実際にはこのような形では実装しないし、arityの調整も行わなくちゃいけないけど、 あくまでも概念としては。

ということは、非互換の素であるBlockというクラスの導入も不要だし、 新しいクラスについての説明も、その使い分けも不要だ。

ということで、これをもって長らく悩んできた「Block/Proc問題」は解決ということにしよう。

あとは、20日午後5時(日本時間)を予定しているpreview3のリリースまで、きちんと準備していくだけだな。

_ [OSS]オープンソース裁判

ライセンスの話をしているとオープンソースに関する裁判についても話題になることが多い。

法律の素人の私がえらそうなことを言ってはいけないのかもしれないけど、 日常生活以上に裁判を心配する必要はないだろうと考えている。 また、裁判に関してライセンスはさほど役に立たないとも考えている。

オープンソースソフトウェアに関連して裁判が起きたケースはまだまだ少ないけれど、 考えられるパターンは以下のいくつかに大別できるように思う。

1. ソースコードの不正流用
2. ソフトウェア瑕疵に伴う損害賠償
3. 商標問題(MySQLとかUNIXとか)
4. 特許、トレードシークレットの不正使用(SCOのケース)

他のパターンがあるだろうか。

さて、これらを見てみると、(1)だけは開発者が訴えるケースで、残りが訴えられるケースだ。 訴えるケースについては後で考察しよう。

残りについてだが、まず(3)と(4)に関してはライセンスは全く関係ない。 よってライセンスをどのように選んでも避けようがない。 曖昧な「気をつけようね」以上の対応策はない。

それから(2)の損害賠償だが、多くのライセンスには無保証の文言が含まれているし、 たとえ含まれていなかったとしても、すべての情報が公開され、無償で提供されているソフトウェアについて 損害賠償が行える契約が締結されていると見なすことは困難だと思われる。 はっきりとしたことは専門家に聞かないといけないけど。

となると、ライセンスをどう選んでも訴えられることに関してはさほど差がないのではないだろうか。

最後に(1)の自分が訴える方だが、これは開発者の自発的なアクションなので好きに選んだらよい。 しかし、裁判という手段に訴えるよりは、ライセンス違反を広く公言して圧力をかける方が効果的ではないか、 という気がしている。

まとめ

• ライセンスの選択と訴えられることには実はあまり関係がない。
• 訴えられることをあまり心配するのは無駄。
• 裁判についてあまり心配しすぎることはFUD的要素を持つ(だからやめよう)。
• でも、最終的な判断は専門家に聞かないと(だれか相談に乗ってくれないかな)。

_ [会社]東京出張

朝から東京へ移動。

「IPAのオープンソフトウェア活用基盤整備事業」の説明会。 公的な資金を使うということはなかなか事務や証憑が面倒ではある。 まあ、「使い込み」とか「不正」とか言われてはかなわないのでしかたがない。

でも、やっぱり面倒だよお。

_ [PC]ノートパソコン

今使っているマシンのキーボードがくたびれてきたので、新しいマシンがほしいなあという気持ちになる。 もっともほしいなあと思うのはいつものことだし、貧乏症なのでなかなか買えないのだが。

より重要な問題は妥協できるマシンがないということだ。

• 1.5Kg以下で
• バッテリーがある程度持つ(3時間以上)
• ポインティングデバイスがトラックボールかトラックポイント
• 液晶プロジェクタにそのままつなげる
• 今よりは良いCPU、今よりも大きなdisk, RAM
• LinuxまたはFreeBSDが動く

という条件を満たすマシンが売ってないんだよねえ。

あえて満たしそうなのはVictorのInterlinkなんだけど、Linuxの動作に不安があるし、 横長ディスプレイがちゃんとプレゼンに使えるんだろうか。それに熱そう。

_ [生活]洗濯機が...

思い出した。夕べ寝ようと思って歯磨きのために洗面所に行ったのだ。

そしたら、洗面所が海だった。ぴちゃ。うわっ。

誰も聞いてないのに大声出しちゃったよ。洗面所の排水溝がつまるかなにかして、 洗濯機の水が逆流したらしい。うちのは乾燥機もついているので、生暖かい水が洗面所の床中に。

びしょびしょ。

ひとり深夜にタオルで床をふいていたのだ、１時間も。なんだかわびしかった。

_ [PC]ノートパソコン(その2)

洗濯機のことはもういいのだ。出張に行っている間に管理会社の人が直してくれたらしいので。 しかし、原因はよくわからない。「ほこりがつまっていました」とか言ってたらしいが、 このアパートにもう6年も住んでいるのにこんなことは初めてだ。

あるいは新しい洗濯機に問題が。とすると数ヶ月後にはまた同じことが起きるのかっ。 心配だ。ちっとも「もういいのだ」じゃないぞ。

ま、それはともかく。

せっかく東京に来ているし、東京事務所は秋葉原にあるので、 ゆうぞうさんに付き添ってもらって(田舎者には付き添いが必要らしい)電気屋に。

予定通り新しいPDAのケースを買って、ついでにノートパソコンを見て回る。

だめだ。ちゃんとしたマシンがない。 期待したInterlinkはやっぱりちょっとキーボードが小さすぎ。 妥協できそうなのは実は富士通のLOOX Sくらいなのだが、 これはCPUとメモリが現状と大差ない。 というかCrusoe 800MHzではP3 600MHzに負けるだろうな。

ACPI対応のことも考えると今は手を出さないほうが良いのかなあ。

_ [Ruby]宴会

都内某所で「ごとけんさんを囲む会」が開かれる。

時間を忘れて(約2名帰りそこねる)楽しい話をしました。 えーと、なに話したっけ。

• Interlinkはやっぱちっちゃいよねえ。
• 1.8.0にRDocは付くのか。つきません、すみません
• Rubiconは。相当品を1.8.1に。
• net/httpはGET以外に使いにくい。openとrequestとresponseを分離するべきじゃないか。
• コンピュータの歴史のうんちく話。昔コンパイラは自動プログラミングと呼ばれた、とか。

あとは忘れちゃった。適当に補足してください。

あと、高橋さん、『消えた少年たち』は私にとって反則です。 寝ないで読んじゃったじゃないですか。どうしてくれるんですか。＜ 自業自得です

書評はまたいずれ。しかし、一般受けはしないんじゃないかなあ。 私的には「どんぴしゃり」と「近親嫌悪」の合い交じった感情があります。

_ 兄弟

• 剛くんと光一くんは兄弟ではありません
• てつやさんとひろふみさんは兄弟ではありません
• けんたろうおにいさんとあゆみおねえさんは兄弟ではありません
• けんたろうさんとゆうぞうさんは兄弟です

秘密じゃないよね。

_ [Ruby]Constructor Method

Dave ThomasによるConstructor Methodの紹介ですが、 「コンストラクタをprivateにするのはどうか」という疑問の声を読みました (もう消えてしまったのでリンクできませんが)。

もちろんDaveがなにを考えていたのか分かりませんが、 私は「コンストラクタをprivateにする」価値があるケースはあると思います。

つまり、オブジェクトの複数の生成法があり、それぞれが同じように重要だった場合、 コンストラクタをprivateにしなければ、 「コンストラクタが採用している生成法がもっとも重要である」という 「正しくない暗黙のメッセージ」を与えてしまう可能性があります。 逆に言えばコンストラクタをprivateにすることにより、 「どれも同じように重要だ」という暗黙のメッセージを送ることになります。

良い設計というのは、こういう暗黙のメッセージが(意図してかどうかはともかく)、 うまく状況に即しているものではないのでしょうか。

_ [OSS]Bruce Perensを囲む会

経済産業省からお誘いのメールをいただき、さいわいにも東京にいたので、 経済産業省別館にて開かれた「Bruce Perensを囲む会」に参加しました。 お誘いのメールには「ランチミーティング」とありましたが、「ランチは出ません」とも書いてありました。 ランチタイムに開く会という意味だったようです。

で、行ってきました。言語は終始英語。 鵜飼さん、佐渡さん、八田さんなどをはじめとして(この業界で)有名な人もたくさんいました。

Perensの発表はなかなか説得力のあるものでした。たぶん、明日の内容と重複していると思うので、 どこかで資料が公表されるのではないでしょうか。

• ソフトウェアを(パッケージとして)売っている人はごく少数
• ほとんどの人はサービスを売っている
• 差別化につながらないソフトウェアは公開しても損はない。
• nerdsだけでなくsuitsにも語る人が必要
• あと、忘れちゃった

それから経済省のムラカミさんという方が話されました。

• 法的な問題と人材的な問題がある
• GPLの(日本法における)曖昧さがある
• それからソフトウェア特許
• 人材的な問題ではコミュニティの小ささ
• 大学をはじめとした訓練が必要

個人的には異論ありまくりなんですが、その点については後で本人と語りました(後述)。

集会後、Perensと個人的に話しました。

• Ruby知ってるよ。３冊くらい本も読んだし
• もっといろんなライブラリが揃うといいよね
• Brad Cox(Objective-C作者)からRubyのこと聞いたんだ

とかいうような話の後、Open Source Evangelistの備えるべき条件てどんなもんだろうか、 という質問をしました。

• ソフトウェア開発経験とビジネス経験があること
• nerdsの気持ちが分かり、nerdsから尊敬されること
• suitsの分かる言葉で話せ、suitsからも尊敬されること
• 「おかしい」と思ったことを文章にして発言するルートがあること

なるほど。Perens自身はElectricFenceやBusyBoxの開発経験があり、 また長らく映画業界(Pixer)にいたのでビジネスのことも分かるということなのでしょう。 こんな人、日本にいるかな。

最後にムラカミさんと話しました。私からは

• 日本のコミュニティの小ささは問題になってない
• 足りないのは開発者ではなく「中間層」
• 欲しいのはサクセスストーリーとエバンジェリスト

というような話をしました。ある程度納得していただいたようで、 方針の転換を検討するという建設的な意見をいただきました。

いやあ、よかった。

_ [OSS]VA Linux Forum

う、資料作り直したんですか。 新しい資料もみたいかも。私も引き合いに出されたそうだし。

今日のに出れなかったのは残念でした。もう、昨日で帰っちゃったし。

あ、そうそう。昨日もPerensは民主主義について語ってましたね。日本人はつい忘れちゃいますよね。

_ [Ruby]1.8.0 preview3

なんと明日リリース予定だというのに、たくさん問題が残っている。

• [ruby-list:36953]
• [ruby-list:37751]
• [ruby-dev:20284]
• [ruby-dev:20373]
• [ruby-dev:20360]
• [ruby-dev:20361]
• [ruby-dev:20370]

_ [Ruby]preview3リリース

今日の午後5時(日本時間)にリリースするなんて時間まで指定して予告したのに、 直前になってバグが見つかる。

• [ruby-core:01148]
• [ruby-talk:74006]

これを直すのでリリースは延期。あわてるとろくなことはないので月曜にしよう。

_ [家族]親子活動

次女の小学校の親子活動とやらに参加する。

講師の方からいろいろな遊びを指導される。 なんか事前にはストレッチ体操だと聞いていたのに、走ったり飛んだりえらいハードだっだ。 運動不足の体にはきついわ。最近体重も増えたし。

子供は大喜び。せっかく覚えたのでうちでもやってみよう。

_ [Ruby]European Ruby Conference

今日と明日はドイツのカールスルーエでEuropean Ruby Conferenceが開かれているはず。

私も招待されていたのだが、ちょっといろいろと都合がつかず断念した。 最初はNetMeetingとかで参加するなんて話をしていたのだが、 こちらで準備ができなかった。その後連絡がないのだがどうなってるんだろう。

_ [TV]SFアニメの宇宙観

えー、前にも話した『学園戦記ムリョウ』ですが、 最近は宇宙から敵がやってきて、それを迎え撃つなんて話になってきてます。

お約束ですが、わくわくするような展開です。また、生身のまま(学生服で！)地球の引力圏を脱出して 火星軌道まで飛んで行ってしまうキャラクタがいたりして、センス・オブ・ワンダーです。 大変よろしい。

しかし、セリフから感じられる宇宙観がちょっとヘンです。

という言葉から推測するに、火星軌道ってのは地球を取り囲んでいるワケ？

もしかして、天動説？ さすがにそれはないか。

あるいは、 「火星軌道」まで行くと火星が、「木星軌道」まで行くと木星が必ずあるところをみると、 地動説ではあるんだけど、いつも惑星直列の状態が成立してて、 外宇宙からの進入は常にこの列に沿って行われる必然がある、とか。 なんか外側の惑星はものすごい速度で公転してそうです。

でも、『ムリョウ』に限らずたいていのアニメではこういうイメージですよねえ。

追記

誤解があるといけないんだけど『ムリョウ』に文句を付けようという意図はほとんどないです。 単に、セリフと矛盾しない宇宙モデルを考えようという思考ゲームです。 作品に対する愛ゆえの行動だと解釈してください。

_ [教会]出雲支部

本日は出雲支部訪問。今月のお話のテーマは「奉仕」。

要旨は以下の通り。

教会ではいろいろな形で奉仕が求められるが、ときどき難しいことがある。 最大の難関は「利己心」である。 利己心とは漢字では「自分の利を求める心」だが、 実際には「自分の利だけを求める心」あるいは 「他人の利をうとましく思う気持ち」である。 しかし、利己心を抑えて奉仕する時、win-winの関係が成立し、 (すごく)長い目で見ると自分にも祝福がある。

使った聖句

• ヨシュア記4:10
• モーサヤ書2:17
• モーサヤ書2:21
• マタイ伝25:34-36

引用したことわざ

• 情けは人のためならず(本来の意味)
• 損して得とれ(ことわざか？)

_ [OSS]奉仕

さて、上記の話の構造はオープンソースにもあてはまる。 つまり利己心(あるいはエゴ)を抑えてオープンにすると長い目で見ると得するという構図だ。

しかし、私自身はオープンソース活動をあまり「奉仕」であるとは捉えていない。 また、そうであるとも言うつもりはない。

理由はいくつかあって、

• 「楽しみ」という直接的な見返りがある。趣味を奉仕とは言わないよね、普通。
• 私自身はオープンソース開発を生活の糧にしている(例外的だが)。
• オープンソース活動は「奉仕」であるという印象を与えると開発者に負担を強いる。
• その印象はまたビジネス活動に邪魔になる。

「オープンソース」という単語は暗黙にビジネスに結びついている。 だから「奉仕」のようなビジネスに結びつきにくいものとは距離を置いた方が望ましいような気がする、 イメージ戦略として。

というわけで、ことわざだけを再掲しよう。

• 情けは人のためならず
• 損して得とれ

_ [NTT]ADSL

私の住んでいるところは玉造といって、松江市の郊外にある温泉地だ。

ここは松江市ではない(玉湯町)ので、いろいろサービスが届かないことがある。 私にとって切実なのはいわゆるブロードバンドアクセスが提供されていない、という点だ。 だいたいコンピュータをろくに使いもしない実家が8M ADSLなのに、 どうしてまがりなりにも「コンピュータの専門家」ということになっている私が32kでアクセスせねばならんのか (それはもちろん引っ越しのときに玉造を選んだからです、自業自得)。

ある程度以上都市部から離れると、アクセスのための補助金が県から出るので、 かえってCATVやADSLのサービスが提供されている。ここは中途半端なのだ。 県は2003年度中に全市町村でブロードバンドアクセスが提供されるという目標を立てているのだが、 実際には今年度NTT西日本は島根県内で1箇所もADSLを新規開局していない。 こんなことで目標は実現できるのか。

ところが、先週ふとNTT西日本のページを眺めていると、 なんと「7月から玉湯町でADSLが提供」と書いてあるではないか、やった。 これで人並みな生活になる。うふふ。

単純な私は急に機嫌がよくなっていたのだが、今日になってNTT(マーケティングアクト)から電話があった。

NTT: 実はこの度、玉造でもADSLが提供されることになって...
私:  それはそれは待ってました。
NTT: 2,3日中にプレス発表になる予定なので、その時にまた案内します。
私:  でも、NTT西日本のページではもうとっくに発表してますよね。
NTT: え？  ....そうですか？

どうやら関連会社の間での情報連携に不備があるらしい。

_ [Ruby]1.8.0 preview3

昨日(23日)の夕方リリースした。で、リリース直前にもバグレポートがあったが、 リリース後にもいくつも見つかった。 いや、そのためのpreviewなんだけど、あいかわらずミスが多いよなあ。 ソフトウェア開発者として(性格に)致命的な欠陥があるのではないかと疑う。

_ [PC]ノートパソコン

ノートパソコンがどうこうとぐちぐちと書いていたら、 「IBMのThinkpad X31あたりはどうでしょう」というメールをいただく。

確かにやや重いが(1.68Kg)他の条件は満たしている。 でも、なんとなくS30あたりのIBMの実力から考えると

• もっと軽いか(1.5Kg以下)
• もっとバッテリーがもつか(10時間とか)

とか期待しちゃうんだけど、ぜいたくですか、そうですか。

_ [OSS]オープンソースソフトウェアもソフトウェア

気のせいかな、オープンソースソフトウェアという単語には幻想が伴うようだ。

いわく、

• オープンソースソフトウェアは信頼性が高い
• いや、信頼性の低いものもある
• オープンソース技術者が足りない
• オープンソース技術者のレベルは高くない
• サポートがない、少ない

しかし、考えてみれば「信頼性が高いものもあるが、かなりの割合で信頼性が低いものがある」ことも、 「技術者が足りない、より正確には優秀な技術者が足りない」ことも、 「十分なサポートがない、あるいは少ない」ことも、 日本のソフトウェア産業ではちっとも珍しいことじゃない。

つまり、これらはソフトウェアの性質であって、オープンソース固有の特徴じゃない。 オープンソース固有でないことをオープンソースの文脈で語ってもしょうがない。

オープンソースソフトウェアもソフトウェアには違いない、という事実が忘れられているのかな。 できればみなの理解が進んで、オープンソースに固有の点についてだけ語り合いたいものだ。

いや、オープンソースソフトウェアという単語の幻想を利用しているのは啓蒙側も同じなので、 これらの誤解もある意味副作用と呼んでも良いのかもしれないけれども。

追記

この文章は<URL:http://www.atmarkit.co.jp/news/200306/24/oss.html>の講演を批判しているように 読めるかもしれませんが、実際ちゃちゃを入れているのはこの文章を書いた記者に対してです。 比屋根さんには(事後ですが)断りを入れておきました。

_ [OSS]オープンソース政策討論会

というわけで、参加してきました。

うーん、政策担当者と直接話せる機会が持てたことと、 これだけの面子が集まったということのシンボリックな意味はあったと思うけど、 実際の討論という意味では発散し過ぎて十分な情報が集まったかどうかは自信がない。

やはり事前の意識合わせが必要であったか。

• 人材の育成はオープンソースに限らない
• オープンソースを政府が支援すべきでない(手法に過ぎないから)
• オープンソースを政府が支援すべき(alternativeとして確立させたい)
• 経済省はライセンスについて有識者による検討を行っている。結果は近日公表
• ソフトウェアの輸出輸入超過をなんとかしたい。マイナスをなくすだけでも
• オープンソース技術者がユナイトする機会が必要。人材の流動性
• 「プロジェクトＸ」？ (...それは勘弁してくれ)

えーと、あとなんだっけ。ストリーミングで参照してください。IRCログ発見。

インサイダー情報

なお、この討論会の前に「渡邊フォント」問題の当事者である、 タイプバンクさん、日立さん、狩野さん、古川さん、かずひこさんなどなどを交えて話し合いが行われたそうです。 前向きの結論が期待できる、かも。

うまくいけばグッディーの前田社長の貢献ということで。 いや、仮にうまくいかなくても(いくと信じてるけど)、貢献という意味はあるよな。

_ [OSS]オープンソースへの政府の支援

いや、支援してくれるって言うなら断りませんよ、決して。

とはいえ、実際に現実的なのは

• OSSをコンポーネントにした業務システムを開発する際に欠けているものの スタートアップを支援する(オープンソフトウェア活用基盤整備事業)
• とんがった人の発掘事業(未踏ソフトウェア事業)
• ライセンスについての日本法における研究報告(やっているとの報告あり)
• 公的機関(大学、研究所)がOSSをリリースする際の制限の緩和、事例の蓄積(進んでる？)

というわけですでにかなりの部分が手をつけられているのではないかと。

あとは、

• 特許制度・商標制度の改革
• 寄付控除の拡大
• GNU manifestoにあるところのソフトウェア税

などもありえるけど、これらは(仮に可能だとしても)時間がかかるだろう。

むしろ、善意のユーザが開発者に積極的に利益を還元するチャネルがないことの方が 問題ではないかと。これら政府の仕事ではない。Perl Foundation日本版みたいなのが、 もっと広い範囲で必要なのかも。

_ ホテル

前回といい今回といい、なぜか浅草のホテルに泊まっている。 東京オフィスの最寄り駅がが末広町なので銀座線が便利なのだ。

部屋の手配の関係かツインの部屋。広いのはいいが、ベッドがふたつあっても無駄に広いだけ。

_ [TV]0123

ホテルでテレビをつけていたら引っ越し業者のコマーシャルが流れていた。

番号っ
ゼロッ
イチッ
ニィッ
サンッ
なんでゼロから始まるねんっ

結局その業者の電話番号の一部が0123であるということなのだが、 なぜゼロから始まるのがおかしいのか理解するのに10秒くらいかかった私は もう一般人とは違う思考回路になってしまっているらしい。

_ [漫画][OSS]ゴルゴ１３

今週発売の週刊ビッグコミックに掲載されている『ゴルゴ１３』ではオープンソースが登場している。

TRONをイメージさせるOSを無償公開しようとする大学教授に対して、 マイクロソフトをイメージさせる会社が妨害する動きを見せ、 OSは公共財であるべきとの信念を持つ教授は命の危険を感じつつ ユビトピア(ユビキタス＋ユートピア)なる相手の本拠地に乗り込む、という筋書き。 作者はきっとプロジェクトＸのTRONの回を見たに違いない。 スーパー301条とか出てたし。

今週は前編なので背景説明に終始し、事件は起こっていないのだが、 間違いなく誰かが死ぬぞ。ゴルゴだから。 今やオープンソースにかかわると命があぶないこともあるということか(違います)。

しかし、以前の公開鍵暗号の話といい、意外と新しめのネタを扱ってくれる『ゴルゴ１３』だが、 毎回開発者が日本人というのはナショナリズム入ってるんだろうか。 そういえばコンピュータウィルスの話の天才ワクチン開発者も日本人だったな。

_ 東京出張終わり

というわけで松江に帰ってきた。なんか5月からこっち頻繁に東京出張が多くて いやになっちゃう。秋葉原は面白かったけど(でもなんか違う街になってきてる)、 2,3回行けばもう当分はいいやって感じ。

一応これで一段落したはずなので、しばらくは出張しなくていいかなあ。 今度の予定は８月のLL Saturdayのはず。

_ [OSS]Rubyを『プロジェクトＸ』に

やめてください。

でも、たぶんそういうことにはならないと思います。 もちろん、恥ずかしいからというのが私としての最大の理由ですが、 それよりなによりRubyの開発はドラマにならないのです。山もオチもない。

リリース直後にバグレポートが来た。
まつもとは焦った。

では盛り上がるものも盛り上がりません。やっぱやめよう。

_ [TV]東京スター銀行

テレビの経済ニュースを見ていたら、東京スター銀行の頭取が紹介されていた。

タッド・バッジ氏は 日本の銀行では初めて外国人の頭取ということで広く取り上げられたらしい。 日産におけるカルロス・ゴーン氏のような期待がされているのだろう。

しかし、その割には週３日は全社員を7時半で帰すとか、

いつか頭取の名刺はなくなりますが、「お父さん」の名刺は一生ですから

などと言う発言が。

仕事一本槍という感じの経営者が多い(ような気がする)中、 自分の生活や家族を大切にする考え方は非常に共感できる。 やっぱり充実した生活が大事だよね、仕事より。

と、思ったら、彼が最初に日本に来たのは「24年前に宣教師として」なのだそうだ。 当時19歳という年齢と二人組の写真を見る限り、うちの教会の宣教師だろうなあ。

そういうことか、共感できるのも当然だろう。

追記

妻曰く、「なに言ってんのよ、家庭に仕事を持ち込んでるくせに」。

いや、その通りです。すいません。

_ [生活]100円ショップ

うちの次女は100円ショップが大変好きなので、 彼女のたっての希望で実家の近くの100円ショップに連れていく。 しかし、なんでもあるものだ。以前の値段を考えると(品質は落ちているものの)想像を絶するものがある。

買ったもの

• ボタン電池 CR2032 x 2
• ポケットティッシュ
• カーシャンプー
• ぬいぐるみ

買わなかったが、私のPDAにちょうどいいケースも売っていた。100円...。

これがデフレというものだろうか。私には経済のことはよくわからないけれども、 成長がサチってしまった現在、デフレというのはあるべき状態ではないのだろうか。 もちろんものの値段が安くなることで企業には価格引き下げのプレッシャーが常にかかり、 経営の負担になるのは確かだが、常に企業努力が要求されるというのは間違った状況ではないはずだ。 労働者にとってもリストラの危険性が高まるわけだが、 これも自分の価値を高める個人の努力が要求されていると考えることもできる。

私にはこのデフレ社会は継続的な努力が要求される健全な社会と見える。 素人考えだろうか。

問題は効率改善の持続的なプレッシャーなどにより弱者への保護がおろそかになる可能性だ。 これについては社会全体で取り組む必要がある。というか、そういう政策になってもらいたいものだ。

_ [教会]松江

松江ワード(Ward)に出席。なんだか久しぶり。

ステーク(Stake)副会長が来ていて、副監督が交代した。 支持してから２ヶ月くらいかかった気がするので、やっとという思いだ。

今週も話が当たっていた。「イエス・キリストを生活の一部にする」という 自分でも十分にできているとはいえないテーマはつらい。 「がんばろう」というような方向性。

引用したお話

『エクストリーム・プログラミング入門』に出ていた 剣の達人と弟子入りした若者の話。 ケント・ベックもまさか教会の説教に引用されるとは思わなかっただろう。