断食安息日。ずっとカジュアルな格好を好んでいた息子は、 今週から教会にスーツを着ていくことを決心した。 馬子にも衣装とはこのことだ。みんな感心していた。
コンピュータ業界で悩んでいる人の相談に乗る。 というか、ただ単に話を聞いてあげただけだけど。 ユーザ部門と外注との間の板挟みだそうだ。 身につまされる話だ。 いろいろ話をしたが、どの程度お役に立てたどうかはわからない。
話題のOSSAJの報道。
言ってることは分かるんだけど、次のステップが聞きたいんだよねえ。 「ベンダーも含めたOSS利用者が利用情報を共有する」とは具体的になにかとか、 「利用者の高い志」とは具体的になんのことかとか、 「若干の仕掛け」とはどんなものを考えているかとか。
まだあまり具体化してなくて、メンバの脳内でイメージが熟成中なのかしら。 それならそれでそう言ってほしい。
本気ですか？
begin-end系の言語は{-}系の言語に比べて、まつもとさんの言葉を借りれば「言語のユーザビリティが低い」と思うのですよ。
- まず、生産性。明らかに括弧の方が生産性は高いですね?文字数も短いし、 end を使う方式で短いイテレータを一行にまとめようと思うと';'を補わなきゃいけないのも生産性に負のバイアスを与えてると思います。
- 次に理解のしやすさも括弧の方がわかりやすいです。とくに非英語文化圏の人間にとっては「英単語和訳」という作業がない分括弧は理解が簡単。
あと、 ruby の場合だと end に対応する単語が一意に定まらないので、パッと見ただけで対応が分かりづらいと思います。インデントしてあれば分かりますけど、それは括弧でも同じなんだから差っ引いて考えるべきですよね。
私の作った言語のユーザビリティを私の言葉を引用して論じるとはいい度胸だ。(笑)
言語のユーザビリティというのは全体のバランスから決まるわけで、 もっと広い視点に立たなくてはいけない。 近視眼的な視点から考えると 「end」という3文字よりも「}」という1文字の方が入力の手間が少ないと感じたかもしれないが、 実際には
と明確に不利であるとはいえない。むしろ逆に有利であるかもしれない。
理解しやすさについては、
であり、有意な差はほとんどないと考える。 予約語に色をつけるなどツールの支援でより便利になるのは明らかだし。
わからなかったのは、mputさんの
個人的には ruby-mode.el が end に対応する予約語をハイライトしてくれるようになったらもっと end 使うかも。
という発言だ。きちんとインデントしていれば、対応する予約語はほぼ明らかだと思うのだが。
さて、ここまでで「endは決してユーザビリティが低くない(「}」に負けない)」ことを示すことができたと思うのだが、 実はRubyのend採用にはさらに別の効果がある。
結果的に他の多くの言語が「end」を避けているので、 Rubyのプログラムを見た時にひと目で「これはRubyのプログラムである」と認識できるのだ。 この効果は意識のスイッチに役立つので、少なくとも私にとっては非常にありがたい。 私はCとRubyを交互に使うのだが、おかげで今どの言語を使っているかで混乱することはない。
これはユーザビリティが相当高いといえるのではないだろうか。
日経バイトの記事の後半。今回は後半の３分割のうちの最初のものだが、 残りも明日以降順次公開される。 前半のときも書いたけど、正確さよりもノリを重視した文章なので、 あくまでもエンターテイメントとして読んでほしい。
mputさんから。
続く議論が「シフトが入るからストローク数は互角だよね」とか「{}はホームポジションから遠い」とか、いぜんミクロな論点に終始している感じがしてちょっと拍子抜けであります。
えー、わざわざミクロな話をしているのは、 結局「}」も「end」も大差ないことを示して、 最後の「意識のスイッチ」を強調したかったからなんだけどなあ。 伝わらないってことは、失敗だったってことだな。
実は「 Ruby では変数の接頭辞 '@' やブロック変数代入構文の '|' など、他に記号が出現する場所が多いから、ブロックの終わりは '}' ではなく 'end' のほうが、記号とアルファベットの割合がよいのだ」という反論を想定していたのですが、どうやらそういうことを考えて end が採用されてるっていうわけじゃないようですね。
Rubyがendを採用している真の理由は
というものだ。もちろん、意識のスイッチもちょっと考えたけど。
あと、カーソルの移動には
ESC C-a ruby-beginning-of-defun ESC C-e ruby-end-of-defun ESC C-p ruby-beginning-of-block ESC C-n ruby-end-of-block ESC C-f ruby-forward-sexp ESC C-b ruby-backward-sexp
などが役に立つのではないだろうか。カーソルキーでだーっと移動するよりは。
あ、よく考えて見ると、Rubyのendの良さってのは
からこそ、意識のスイッチに役立つという点にあるのであって、 あまり喧伝して他の言語がどんどんendを使うようになっては優位性がなくなるような気がするな。 みなさん、昨日書いたことは忘れてください。
で、begin/rescueやcase での brace はどのへんが美しくないかというと、 randyさんのおっしゃるように、
case val {
when a
...
when b
...
when c
...
}
または
try {
...
rescue IOError
...
rescue SyntaxError
...
ensure
...
}
のようにブレースの中で区切るのも変だし、とはいえ
case val
when a {
...
}
when b {
...
}
when c {
...
}
あるいは
try {
...
}
rescue IOError {
...
}
rescue SyntaxError {
...
}
のように細かいブレースの連鎖になるのも気に入らなかったということです。 学生時代にOOSCに影響されてcomb styleに憧れていたのもありますが。
いつまでたってもRite VMの開発に取り掛かれないし、 そうこうしているうちに笹田さんがyarv(yunoだっけ？)を始めちゃったりしてるので、 今までサーベイしたことをメモしておこう。
Rubyのような型情報が一切なく、最適化が行いにくい言語のための仮想機械で有効そうなテクニックは以下の通り(全部ではない)。
基本的なアイディアは、仮想機械の実行のうち、 もっとも多く時間を消費するのは、命令のフェッチとジャンプであるので、 ここを改善しようというもの。ソフトウェアによる仮想機械ではCISCな発想が良いみたい。 yarvはこれらの多くをすでに実現している。
これらでVM部分の実行時間が半分以下くらいになるんじゃないかと期待している。
後、残りは
だが、これはなかなか良いアイディアがない。
メソッドキャッシュの高速化について考えると、 現在のメソッドキャッシュはなかなか効率的ではあるが、 グローバルなテーブルルックアップなのがスレッドには嬉しくない。 とはいえ、インラインメソッドキャッシュはなかなか難しいし。
メソッド呼び出しの方はスタックのデザインで少し変わるかも。 vmgenのサンプルにあるminiとかが参考になるかもしれない*1。 それと、演算子呼び出しなどで、条件が成立している時には、 直接計算してしまうことでメソッド呼び出しを削減できる。 lightningのようなものによる JITも考えられるけど、移植性を犠牲にする割にどれだけ嬉しいかは検討しないとな。
JITに限らずVMの高速化は面白いテーマではあるが、 所詮スクリプト言語なので報われるかどうかわからない分野である。
*1 もっともminiが速いのはチェックがないからかも
明日は経済産業省による「高度IT人材早期発掘のあり方検討会」の第二回である。
しかし、はっきり言って私には画期的なアイディアはないのだよなあ。
ような企画ってのはどんなものがあるのか。 「未踏ユース」でいいじゃんって思いも一部あったりする。
もはやガーベージコレクション(GC)は必然だ。これから登場する言語でGCのない言語は考えられない。 世の中にはさまざまな(宗教上の？)理由でGCを毛嫌いする人がいるが、 そういう人はCやC++を使ってればいい。これらにGCが導入されることはないだろう。
では、Rubyのようなスクリプト言語のGCに対する要求にはどんなものがあるか。
Rubyの10年の経験からいうと速度に対する要求はさほどない。 Rubyインタプリタそのものが遅いせいかもしれないが、 10年間の間でGCが問題になったのは、
というlive objectが異様に多かったケースだけだ。報告があったのは数度だけ。 もちろん「GCが遅いなあ」って思った人はもっとずっとたくさんいるだろうけど。
だから、スクリプト言語のGCに対する要求はむしろ
などだろう。実はGCの研究はトータルの速度や応答性などの性能が重視されていて(当たり前だけど)、 この辺はあんまり検討されていない。が、実際の処理系にはこういうのが必要なのよ。
ところが、これらの要求は実は実現するのが大変難しい。
たとえば、(1)を実現するためには、 Rubyも採用しているCスタックをスキャンするconservative GCが向いているんだけど、 これは移植性が低くなりがちだし、なによりpthreadがカレントスレッド以外のスタックアドレスが取れないので、 native threadとの相性は最悪だ。(5)についても、木山くんがやったような世代別GCで大量live objectに対応できるが、普段の性能はどうしても低くなってしまう。
こういう相反する要求にどう応えるかというのが、これからのスクリプト言語の実装に対する課題ではないだろうか。 もっとも、そんなことは考えないでBoehm GCを使っちゃうってのも、この際アリだけど。
でもって、数年間考え続けてやっと
GC手法を考えついたような気がするんだけど、実装してみないと「普段の速度」は分からないなあ。 これが遅いとなんにもならない。
その手法の詳細を記述するにはこの余白は狭すぎる*1(続く)。
*1 期待させる口ぶりですが、たいしたことじゃありません
あいかわらず発散しぎみなのだが、 それぞれの分野で発散したまま議論が深まった。 今後、今までに出たいろいろなアイディアから取捨選択する必要があるのだろうなあ。
次回は3月5日(金)の予定。
まず、スクリプト言語におけるGCの要求を復習すると以下の通り。
1. 拡張ライブラリが書きやすい(明示的なprotectが不要) 2. 移植性が(そこそこ)高い 3. native threadと相性が良い 4. さまざまな状況でも落ちない 5. 普段の性能を維持しつつ、大量のlive objectに対応できる
Rubyの採用しているconservative mark and sweep手法は、1,2,4はクリアしているが、3,5が苦手。 以前にも書いたようにpthreadはスタックアドレスを得るAPIがないので、 conservativeの特徴であるCスタックのスキャンができない。 また、生きているオブジェクトを全部スキャンするのでlive objectが多くなると極端に遅くなる可能性がある。
一方、PerlやPythonの使っているreference count手法は、2,4,5をクリアしている。 一般的にreference countは応答性がよく、 特にオブジェクトが参照されなくなった時にすぐに解放されるのでlive objectが増えても問題は発生しない。 しかし、代入が発生するたびに参照数(reference count)を増減させる必要があるため、 拡張ライブラリのメモリ管理が面倒だ。また、参照数管理を間違えると面倒なバグの原因になる。 代入のたびの参照数管理はトータルの性能低下の原因になる。 特にthread環境下ではあらゆる代入のためにmutex_lockが必要になるので、 性能上の問題が発生する可能性がある。
それと、reference countにはサイクル(間接的に自分を参照すること)が発生すると、 誰からも参照されなくなってもオブジェクトが解放されないという欠点があるので、 多くの処理系ではmark and sweepのようなスキャンを行う他のGC手法と組み合わされている。
こういうのを見ていると結局、大量オブジェクト対策とthread対応が大きな課題であることがわかる。
大量オブジェクト対策としては、generational GC(世代別GC)が有名だ。 これは、ほとんどのオブジェクトの寿命は短いが、 中には長く生き残るオブジェクトがいて、そういうオブジェクトはあまり変化しないという性質を利用している。 新しく作られたオブジェクトは「若い世代」として頻繁にスキャンされ、 長く生き残ったオブジェクトは「殿堂入り」してたまにしかスキャンしない。 これで無駄なスキャンによる性能低下を避けることができる。
thread対応は難しい。CスタックをスキャンするconservativeなGCでpthreadにうまく対応した手法はあまりないからだ。
QSchemeというScheme処理系とBoehm GCはスレッド対応として
という方法を使っている。しかし、pthreadとシグナルは鬼門で移植性に問題がある(Boehm GCはプラットフォームごとにスレッド対応のコードを持つ、QSchemeはLinuxのみ対応)。
スレッド対応で移植性のある唯一のGC手法はKSMというScheme処理系で採用されているものだ。 これは「ある関数内で生成されたオブジェクトはregistryと呼ばれるスレッドごとのテーブルに登録され、スキャンの対象になる」というルールによって実現されている。まあ、確かにこの方法ならまだ参照されている可能性のあるオブジェクトを解放してしまうことはないわな。
だが、これはあまりにも「保守的」すぎて、関数の実行が終了しない限り、 参照されなくなったオブジェクトも後生大事にとっておくので性能上の問題がある。 ある関数の中で大量のオブジェクトを作って捨てて、としているとあっという間にメモリを使い切ってしまう。 が、発想としては面白い。
で、これらを組み合わせて理想の技法を作り出そうというわけだ(まだ引っ張るらしい)。
追記
「pthread_attr_setstackaddrで事前にスレッド用のスタックを用意しとくのでは駄目なんですか」という質問がありました。
完全に駄目というわけではないのですが、
などの理由で、満足できてません。
東京行きですっかりくたびれたか、異常に眠る。午前中はずっと寝ていた。 が、おかげで風邪引きかかっていたような気がしていたのが、直ったような。
スクリプト言語におけるGCの課題は、大量live objectとスレッド対応であると述べたが、 今回はスレッド対応の難しさについて考察する。
複数のスレッドが存在する環境でGCを行う場合に面倒なのは同期と排他制御だ。
そもそも、あるオブジェクトが死んでいる(プログラム終了まで使われることはない)かどうかは、 機械的には判定できない。そこで、どこからも参照されていないことを近似として用いているわけだが、 「どこからも参照されていない」かどうかを判定することも、それほど簡単ではない。
reference countを除くGC手法では、rootと呼ばれる「生きていることが分かっているオブジェクト」から始めて、 リンクをたどることで到達可能なオブジェクトを「生きている」と判定している。 生きているオブジェクト以外のオブジェクトはすなわち「死んでいる」わけだ。 ところが、GCがスキャンしている最中にほかのスレッドがオブジェクトの中身を書き換えてしまうと、 正確にスキャンできない。死んだはずのオブジェクトを生きていると判定するのは別に実害はないが、 生きているオブジェクトを死んでいると判定するのは非常にまずい。
これを避けるにはふたつの方法が知られている。
前者は簡単だが、GCのために毎回スレッドが全部止まってしまうようでは、処理効率が下がってしまい、 せっかくのスレッドの意味がなくなりかねない。多くの実装ではスレッドに「止まれ」と命令しても 次の「停止できる場所」に到達するまでは止まってくれないので、待ち合わせが必要になるし、 GCは思ったより頻繁に起きるものだし。
後者は オブジェクトのスキャンをやりなおしている間にまたマークがつけられてしまうと いつまでたっても回収が行えないことを考えると、実装が複雑になってしまう。 マークにpage protectionのような方法を使うと移植性が下がってしまうし。
そこで、世代別GCでminor collectionではスレッド間の協調なしに オブジェクトの回収ができるアルゴリズムがあれば、 スレッド環境下でも性能が維持できるのではないかと考えたのだが(まだ続く)。
あー、でもスクリプト言語では性能はあまり問題にならないと自分で書いたのだったな。
いつまでも引っ張ってもしょうがないので、公開。
材料
作り方
multi thread環境では、minor GCがスレッド独立で行うことができるので、性能が期待できる。 single thread環境では、minor GCでは全オブジェクトをスキャンしないので、live objectが多くても性能が期待できる。
問題は、minor GCで回収できるのはヒープから参照されたことがないオブジェクトだけなので、 あまりに保守的過ぎて性能向上が十分でないかもしれないということ。いくら非再帰で軽いからと言っても、 あまり頻繁に行われては意味がない。実際に実装してみないとなあ。
なお、yarvメーリングリストで、富士通研の中村さんらの「動的に割付け戦略を最適化するJavaメモリ管理機構」(情報処理学会 トランザクション 「プログラミング」 アブストラクト Vol.44 No.SIG13 - 002)が似てるということを教えてもらいました。
別に真似したわけではありませんが、完全に独創的というものを作り出すのは難しいものです。 ってtraitの時にも似たようなことを書いたような。ヒープを別に持たない点などはちょっと独自かも。
なお、このアイディアはそのうち論文にする予定です。だが、まず実装しないとな。 いつになるやら。
岡山で会議。朝から雪がちらついていて、おまけに晴れているもんだから、 路面が光ってつらい。まぶしくて目がどうにかなってしまうかと思った。 こういうことは予想しなかったので眼鏡かけて運転していたのだが、 この際、格好の事は言っていられないので、眼鏡の上にサングラス。
向こうに付いたら、融雪剤で車がどろどろ。後で洗車しなくちゃ。
会議の内容はたぶん日記に書くのは問題ありなので省略。
一緒に乗せていった人の用事が終わるのを待っていたらすっかり遅くなっちゃった。 今日は妻の誕生日だったんだけどなあ。
この辺は歴史が古いせいか難しい読みの地名を見かける。いや、読みにくい地名なんてどこにでもあるか。
宍道(しんじ)というのは漢字だけ見ると読めないが、湖がそれなりに有名のような気がするので、 難しくはないか。温泉津(ゆのつ)も「温泉」を「ゆ」と読むシャレに気がつけば納得できる(か？)
しかし、ちょっと読めないだろうというのは以下のもの。
前者は私の出身地、米子市のもの。車という字を「くるま」と読まない地名は全国でもここだけらしい。 同名の小学校がある。
後者は松江の東側にある東出雲町の地名。 出雲とは松江をはさんで反対なのに東出雲というのも納得の行かない町名ではあるが、ここでは置いておこう。 これも同名の小学校がある。
答えはまた後日。ちゅーか、最近はgoogleすれば一発で分かるような気がする。
他のblogとtrackbackのやりとりをしたりすると、エントリを日単位ではなくパラグラフ単位で扱いたいなあ、 と思うこともある。pluginでなんとかできないだろうか。
ことでなんとかならないだろうか。いや、パラグラフごとにコメントをつけられるようにしないと無理かなあ。
落語の『駱駝』ではなく、昔からあるジョークの方。
旅人がラクダを連れて旅をしていた。夜、旅人が休んでいるとラクダが言った。
「ご主人様、外は砂嵐で大変です。せめて鼻先だけでもテントの中に」 「いいだろう」 「顔まで入れてもいいですか」 「いいだろう」 「では、もうすこし..」 「いいだろう」気がつくとテントはラクダに占領され、旅人は砂嵐の中に放り出されてしまった。
夜中、私が寝ている布団に息子がもぐりこんできた。 さみしくなって両親のところで寝たかったらしい。 しかし、次に気がついた時には私が布団から蹴り出されていた。寒かった。
おかげで一日中鼻がぐずぐずして調子悪かった。喉も痛い。 いざという時のために今夜からもうちょっと毛布を追加しよう。
先日公開したGC手法はRubyの新実装(Rite)で実現しようと思っていたのだが、 考えてみれば、スレッド構造体にregistry配列を追加すれば、 現在のGCの構成要素を組み替えるだけで(write barrierは入れないといけないけど)比較的簡単に実装できそうだ。 問題はflagsに参照bitを追加する余地がなさそうってことだが、 type bitに現在6bit使っているのを5bitにすれば(現在25タイプしか使ってないので)、すき間を空けられそうだ。 これはやってみるかなあ。
で、性能評価はその実装と木山GCと比較するってのはどうだろう。木山くんには迷惑な話だな。
パラグラフ単位でエントリを管理したいという与太に、たださんからコメントをいただいた。
今のところは、手間ばっかりかかっていいことないんじゃないかと考えてます >パラグラフ単位
そーかぁ。
いや、私の目からは「いいこと」は一杯あるんですけどね。私はtDiaryすごく気に入っているんですけど、 いくつかの不満は全部この「パラグラフ単位」から来てることに気がついてしまったのです。
この日記を見てる人はご存じのように、 私は(たぶん他の多くの人も)全然関係のない複数の内容を同じ日にぶち込むので、
という不満があるのです(なんとこの3つしか不満がない)。 とはいえ、日単位の管理も便利なので手放したくない(からBlogkitには移行できない)。
まあ、「コメントをパラグラフ単位に」という時点でtDiaryのコアを修正しないといけないのは明らかですし、 「日記システム」であるtDiaryを無理矢理Blogのようにするためにそこまでの変更を行うのは、 コストに合わない、あるいは本末転倒であるというのは十分理解できますけどね。
とはいえ、tDiaryからforkして、たとえばtBlogを作る根性は私にはないなあ。
待てよ。コメントとfootnoteは無理でもtrackbackはなんとかなるか。 昨日少し書いたようにtb.rbをいじって
すれば、曲がりなりに解決するような。時間が取れたらやってみよう。
本格的に風邪引いた。原稿の〆切が。
風邪が直り切らないので午前中は寝て過ごす。 午後は起き出してきて、Linux Magazineの原稿を。 テーマは「アスペクト指向」でAspectRの紹介。 これ、けっこうできがいい。
子供たちが教会の行事でお菓子を作るそうだ。 その間に私は松江ワードの監督と話す。 連絡事項のあと、2003年後期分の監査。
その後、パソコンを買い替えたいとか雑談を少々。
今月は29日までしかない上、月末が土日なので〆切が早い。 おまけに風邪を引いたりして原稿が遅れるのではないかと心配していた。 しかし、予想以上にスムーズに書き進んだので、〆切には問題なさそう。
「Ruby開発日記」のテーマは「ごみ集め」。この日記で書いてたような難しい話以前に、 そもそもごみ集めとは、とか、基本的なアルゴリズムとか、そういう話。
「パラグラフ単位のトラックバック」とか書いていたら、 私が手を下すまでもなく、ょゎさんが実装してくれている。ありがたいことだ。
パッチが公開されているので、さっそく試してみよう。
ただ、私の使っているバージョンのtDiaryにはbody_to_htmlというメソッドがなかったので、 そこだけ変更した。
テレビを見ていたら、ビリヤードに打ち込む14歳が紹介されていた。 全日本学生選手権最年少優勝者で、高校に進学せずにビリヤードの道を極めるのだそうだ。
彼いわく、
10年後には世界的なプレイヤーになって、みんなからあこがれられる存在になりたい
のだそうだ。
それを聞いて、「よーし、私も10年後にはみんなからあこがれられる世界的なプログラマに」とかほざいてたら、 妻に、
そんなこと言っても、これからは下る一方じゃない？
と指摘された。娘も
世界的なプログラマなんて言っても誰も知らないもんね。
とトドメ。 真実は胸に痛い。
いつの頃からか2月14日は女の子が男の子にチョコを渡す日になっている。 菓子業界もうまいことマーケティングしたものだ。
うちの娘たちも手作り*1のチョコなど用意している。 もっともあげる対象は(一部を除いて)同性だったりするみたいだが、小学生ならそんなものか。
これが大人だともうちょっとぶっとんでいる。やるなITmedia。
私はそんなに甘いものはたくさん食べれないので、娘からもらった「ハートチョコレート」(ピーナツ入り、80円)一枚でもう今日はたくさんという気分だ。
妻は、心のこもった「ゾウガメ型チョコレート」を贈ってくれた。 しかし、これを食べるのは残酷な気がする。どこからかじれというのだ。 頭からか、足からか。手足、頭を全部食べて「ほら甲羅にこもってます」とかやるのかっ。
食えない...。
そういえば何年か前にもバレンタインデーにもらったペンギンチョコを長らく食えなかったことがある。 あまりリアルなのはねえ。
それを見て妻は、「そう反応すると思った。しばらくしたら、あたしが食べてあげるわ」だと。 完全に読まれている。
*1 一度溶かしたものを固め直すのを「手作り」と呼ぶならば
自分で運転して鳥取に行くのは初めて。鳥取支部は駅近くの比較的わかりやすい場所にあるのだが、 しっかり迷いましたとも、ええ。
MapFanを参照しようとするとマシンがハングするし。 Linux 2.6.2でもまだ私の環境では不安定な様子。
結局、2時間半ほどかけて到着。十分時間に余裕を見てたので間に合った。 しかし、長距離運転に疲れた。
聖餐会、お話のテーマは「預言者に従う」だった。私自身は「福音を宣べ伝える」。 あんまり得意なテーマじゃないんだけど。教義と聖約15章、16章を引用。
「扶助協会」と「若い女性」の姉妹たちからそれぞれお菓子をもらった。 そうか、バレンタインデーか。
あとは、世間話。
「パート1」はなかったような気がするが。
おとといは13日の金曜日であった。この日は「不幸がある日」として知られているらしい。 この日には重大な事故があったり、不幸な出来事が起きたり、 湖畔のキャンプ上でホッケーマスクをかぶった人物による連続殺人事件が起きたりするらしい。
みなさんのどころではどうだったろうか。不幸があった人も、幸福があった人もいるのではないだろうか。 そんなもんだ。
私が13日の金曜日について初めて知ったのは、まだ小学生のころ、 実家の倉に眠っていた古い「少年マガジン」を読んでだったと思う。 たぶん私は小学校低学年で、少年マガジンは昭和42年か43年頃のものだったような記憶がある。 その頃のマガジンは巻頭にかなりの分量の特集記事が載っていて、 ある一冊の特集が「世界の不思議と謎」とかいうようなテーマであり、 その中でネス湖のネッシーなどに混じって「13日の金曜日に重大事故や事件が多い」話もあったはずだ。
なんでこんなこと覚えてるんだ、俺。
そういえば、その時いっしょに読んだ別の号の特集記事では「魔球」かなんかの解説で、 「黒い秘密兵器」の分身魔球は
ボールが上下に素早く振動し、上のボールの影が下のボールにうつって下のボールが黒くなる
とか、無茶苦茶な解説がされており、子供心に「ありえね〜」と思った覚えがある。
13日の金曜日の話に戻ろう。私の高校受験は私立が2月13日の金曜日、公立が3月13日の金曜日で、 「不吉な」と思ったものの、考えてみれば受験生全員が同じだけ不吉なので、 別に有利でも不利でもないということに気づくまで、勉強に手が付かなかったものだ。 が、それでも高校にはしっかり受かったので、実際には全然不吉でもなんでもなかったらしい。
なんで13日の金曜日が不吉と呼ばれるかというと、この日にキリスト受難の日だからだそうだが、 普通「日と曜日」で指定しないんじゃないだろうか、とも思う。 もっとも復活を祝う「イースター」はもっと複雑なルール*1なのだが。
さて、グーテンベルグとカルビンやルターによる宗教改革のおかげで、 今や聖書は誰にでも手に入る。アマチュア聖書研究者には興味深いテーマだ。 福音書と若干の暦の知識を使って 本当にキリスト受難の日が13日の金曜日かどうか検討してみよう。
福音書から以下のようなことがわかる。
ユダヤ人たちの安息日は日曜日ではなく土曜日。
キリスト受難の日は安息日の前日。
過ぎ越しの祭の1日目と7日目は曜日に関らず安息日と見なされたが、この安息日の次の日は「週の最初の日」、 つまり日曜日なので、上記の安息日はただ単に安息日というだけでなく土曜日であったことがわかる。
これで「金曜日」は確定したと言ってもいいだろう。次は「13日」の方だ。 まず最初にはっきりとさせないといけないのは当時ユダヤ人が使っていた暦は太陰暦で、 今の太陽暦とは全然違っている。だから太陽暦による「13日」には元々なんの意味もない。
日付についても聖書からわかる。
その日は徐酵祭の第1日目であった。
「過越の小羊をほふる日」は正月の14日である。
出エジプト記12:6も参照のこと。
なんと、「13日の金曜日」ではなく「14日の金曜日」であったか。
ということで、以後不吉なのは14日の金曜日ということで、ひとつよろしく。
*1 イースターは春分の日後の最初の満月の次の日曜日、2004年は4月11日
年度末なので今年度の活動をレポートにまとめている。
で、2003年に行った講演(プレゼンテーション)は9件であった。 全部、依頼または招待されたものであることを考えるとまあまあの数字か。
時期から考察すると、
などが分かって興味深い。
B0000W3OHY 話題の大作ではなく、1978年のアニメ版。 『王の帰還』を見る前に全体を振り返っておこうと思ったからだ。 「ひどい作品」という噂は聞いていたが、ダイジェストとしてしか期待していないので、 まあ大丈夫だろうと推測したのだ。
ロートスコープ(実写をそのままアニメ化する技法...らしい)を使ったアニメーションは、 見慣れないという意味で奇妙な印象を与える。 バルログだけは勘弁してほしい造形だったし、オークもいまいち。 実写もどきと安っぽいアメリカテレビアニメを混ぜたような映像を形容すると、やっぱり「奇妙」かなあ。 好きな人はいるかも。
でも、ストーリーについては原作(読んでません)を極端に圧縮しているだろう事を考慮に入れると、 そんなに悪くない。
が、始まってから2時間後、話の位置としては『二つの塔』の終盤でいきなり終わってしまう。 尺が尽きたか、気力が尽きたか、予算が尽きたか、いずれにしても、あんまりだ。
「ひどい作品」という噂の真の理由はそこにあったか。
魔球のことは秘球と呼ぶのですか、勉強になります。
そうすると、私が見たのはもしかすると「ゼロの秘球」ではなく、「黒い秘球」の解説だったのかもしれません。 記憶がかなりおぼろげですから。
もうひとつ、「回転するボールが水蒸気を巻き込みカクテル光線を反射して七色に輝く」魔球という解説の 記憶があるのですが、これはいったいなんなんでしょう？ いずれにしても、物理法則を無視した話ではありますが。
武藤さんが ふと思っておられるが、 実現できたら面白いかもしれない。
「オープンソースの日」とか「フリーソフトウェアの日」とか「FLOSSの日」とか「シュッシュッの日」とかを定義するとマーケティングの向上が図れるだろうかとふと思ったり。
しかし、バレンタインデーというのは人間の根源的欲求の3つのうちふたつ（食欲と性欲）を刺激するのが 良いのであって、オープンソースでは難しいかも。
あなたの好きな人にオープンソースソフトウェアの入ったCD-ROMを贈ると願いがかないます。
...だめそう。よっぽど頑張ってもサンジョルディの日の二の舞だな。
贈るならCD-ROMより（ホンモノの）Rubyが良いかも。 ちょっと値が張る*1のが難点だが。
追記:
「PerlやPythonを贈ってみる」とのことだが、 Perl(Pearl/真珠)はともかく、Pythonはワシントン条約やら銃刀法やらに違反しそうだ。 おまけに女の子にもウケそうにないし。
法律違反ではない 『6302293553』でも、女の子ウケはしないと思うよ。 喜ぶ女の子がいたら、それはそれで貴重な気がする。
*1 ルビーはダイヤモンドの次くらいに高い
社長をともなって、某大企業の関西研究所へ出張。
出雲から伊丹まで飛行機(Q-400)。 出雲・伊丹便は最後までYS11が残っていた便なので、もうちょっと早かったら乗れたんだけど、 去年で完全引退してしまっている。 中学生のときに乗ったのが最後になってしまった。
伊丹からバスで近鉄上本町、そこから学園前。タクシーで研究所に。
昼食後、プレゼンテーション。スライドはここ。オープンソースのあり方をあらためて紹介。内容にそれほど新規性はないけど。それなりに役に立ったとの感想を聞いた。
その後、先方の研究成果を見せていただく。非常に興味深い。
で、懇親会。最初から最後まで丁重に扱ってもらって恐縮だ。
午前中は意見交換会。われわれのような零細企業と超大企業では オープンソースに関する戦略も違ってくるのは当然だが、 再認識させられる点も多い。一応、こちらが経験者(先駆者)として情報提供というスタンスのはずだが、 勉強になることが多い。
午前中で用事は終わり、出発。研究所長さんやら部長さんやらにお見送りをしていただき、恐縮する。 こんなに良い扱いを受ける出張も珍しい。
上本町の近鉄百貨店の催事場で昼食にミニてっちり。堪能する。 良い出張であった。とくに食べ物が。満足度のためには食べ物じゅーよー。
追記:
大企業におけるオープンソース戦略については、末松教授による日本IBM会長のインタビューも参考になる。
知人もかかわっている地元の劇団のミュージカルを見に行く。
つい最近まで素人だった人の集まりとは思えない出来で、感動する。 参加したメンバがいかに頑張ったか、 音楽指導者がいかに熱意をこめて指導したかを感じることができるようだ。 暗い舞台の手前で演奏する管弦楽団の人たちにも拍手。
しかし、大変すばらしい舞台ではあったが、ストーリーには感動できなかった。
これは、私が違うものを求めているのか、ミュージカルの「文法」を知らないせいか、それとも...。
感心できなかったのは以下の点だ。
説明すべき点が説明されていない。
たとえば、小道具として薬が出てくるのだが、この薬の効能が理解できない。 なぜ先代社長が悪用を恐れて開発を中断してしまったような薬を飲むと、 悪役がみな改心してしまうのか。なら、中断することなかったじゃん。
説明するべきでない点は説明される。
たとえば、主人公は「才能はないけど優しい人」という性格づけがされているようだが、 その「優しい」ことは冒頭の歌によって直接紹介され、あとは一切でてこない。 いや、途中とってつけたように女性に対して「優しい」箇所があるんだけど、 あれはナンパしているようにしか見えない。
キャラが立ってない。
ごく一部の例外(悪役)を除いて、だれもどんな性格の人なのかよくわからない。 性格を反映したセリフ・エピソードが(上述のナンパを除いて)見当たらない。 おまけに似たような登場人物が多く、混同してしまいそう。
ここは音楽指導者には音楽に専念してもらって(音楽は大変良かった)、 次回からはシナリオは別の人に任せるというのはどうだろうか。
と、こんなところに書いてもまったく意味がないのだが、書かずにはいれなかったということで。
よそに訪問している時には割とお話の責任が割り当たるので、 松江ではそういう機会はあまりないのだが、今回は松江でも。 テーマは「悔い改め」、というか、そこから発展して「忘却」について。
忘れてしまうことは恐ろしいことだ。 感謝を忘れると恩知らずだし、罪を忘れると悔い改めることができない。
引用した聖句:
私は自分が忘れっぽい人間であることを自覚しているが、 本当に大切なものは忘れないようにしたいものだ。
先日(といってもアップロードしたのは今日だが)、 『オープンソースの光と影』という スライドを公開したら、塩崎さんから反論というか批判というかをいただいた。この意見に対して同意はしないが興味深い。
まあ、客観性などという言葉にだまされてはいけないやね。 私は、 オープンソースの客観性 というものは全く認めない。確かに、定義により 「OSD 準拠のソフトウェア = オープンソースソフトウェア」なのかもしれないが、 しかし、オープンソース運動というのが思想的プロパガンダであることを考えると、 機械的に「OSD 準拠のソフトウェア = オープンソースソフトウェア」という定式を適用することは、「OSD 準拠のソフトウェア」 を勝手にオープンソースのプロパガンダに使ってることに等しい。 これが「OSD 準拠」と言うことと、 「オープンソース(ソフトウェア)」と言うことの本質的な違いだと思う。 思想的プロパガンダに利用するようなことを、単に「定義により客観的」だから「開発者の意図とは関係ない」 と言うことが許されるべきなのだろうか。
たとえば、「日本国民 = ほげほげ党員」という定義を考えてみよう。 かなり勝手な定義だが、確かにこの定義は客観的だ。しかし、ほげほげ主義を信じているかどうかに関係なく、 あるいは、実害があるかどうかに関係なく、この勝手な定義およびその客観性という大義名分によって 勝手にほげほげ党員にされたら誰だって嫌だろうし、「日本国民はみんなほげほげ党員です。ほげほげ主義は素晴らしい!」 なんていうプロパガンダをされたら嫌だろう。 要するにそういうことだな。「ほげほげ主義は素晴らしいから許されます!」 とかアホなことを言い出す奴が出ないことを祈る。
まあ、百歩譲って 「OSD 準拠」のものを単に「オープンソース(ソフトウェア)」と呼ぶのが 「悪い」ことなのかどうかはともかく、少なくとも「失礼」なのは確かよね。 オープンソースという言葉の定義を勝手に別の定義で置き換えることを 「失礼」と言う のならば、 勝手にオープンソースという物を定義して、 その勝手な定義にしたがって勝手にオープンソースソフトウェアと呼ぶことの 「失礼」を認識していてもよさそうなものなのだが。 それが認識できていないあたり、独善と言われても仕方がない。
前にも書いた通り、そもそも「オープンソース」という言葉ができる前から 「オープンソースみたいな何か」という文化があったのだけど、「オープンソース」というのは所詮、 その旧来の「オープンソースみたいな何か」 の文化に対する乗っ取りからスタートしてるからしょうがないのかもね。
いっぱい引用したが、肝心の論についてまず述べよう。
OSD準拠のものをオープンソースと呼ぶのは失礼なのか
私は失礼だとは思わない。議論のため、ある定義を満たすものに名前をつけることはよくあることだ。
もちろん「オープンソースみたいな何か」という文化が以前から存在していたのは事実だが、
オープンソース以前には明確な定義もなく、的確な名前もなかったことは
塩崎さん本人がそれを「オープンソースみたいな何か」と呼ばざるをえなかったことから明らかではないだろうか。
明確に名前がないものに名前をつけ、範囲を確定する行為は自然な行為である。
中にはいろいろな理由から「オープンソース」という用語を好まない人はいるだろうが、 あらゆる人の意向を尊重することは事実上不可能であるため、ある程度「しょうがない」だろう。
では、失礼でないとしたら、問題はなにか。 それを考えるために塩崎さんがあげられた「たとえ」について考えてみるのは有効かもしれない。
うむ、よく出来たたとえに見える。
しかし、「勝手にほげほげ党員にされたら誰だって嫌」なのは、 最初の定義は「日本国民 = ほげほげ党員」でしかないはずなのに、 「党員」という単語の語感によって、本来の「ほげほげ党員」定義に含まれない 「ほげほげ主義に賛同する人」という「別の定義」を導入しているからではないだろうか。 これでは、最初の定義は本当の定義ではないということになる。
最後の「ほげほげ主義は素晴らしい!」についてはもっと論理が破綻している。 「日本国民 = ほげほげ党員」という定義からは 「ほげほげ党員」と「ほげほげ主義」の関連性は引き出せないので、 どう頑張っても「素晴らしい」根拠にはならないはずだからだ。 ここでも暗黙の別の定義が使われている。
語感から本来の定義にないものを導入するのは、やっぱり定義を尊重しない行為だ。 それは少なくとも私のやり方とは真っ向から反対する。 塩崎さんの批判は(定義を尊重しないことを前提にしているので)私にはあてはまらないし、 そういう私の論からそれを引き出すのは、残念であるばかりか、詭弁という印象さえある。
とはいえ、私は塩崎さんが意図して詭弁を使ったとは思っていない。 予想できるのは以下のいずれかだ。
誤解
オープンソースソフトウェアという名前がオープンソース運動に賛同した作者によるソフトウェアであると誤解している。
危惧
オープンソースソフトウェアという名前がオープンソース運動に賛同した作者によるソフトウェアであると誤解されると心配している。
いずれにしても、そういうことがないように「定義」をきちんと説明して、 さらに「客観的」という単語を入れたスライドを用意したのだが、 まさにそこがヒットしてしまうとは、なんたる皮肉。
私は、フリーソフトウェアと違ってオープンソースはプロパガンダであるとは思っていない。 むしろフリーソフトウェアという言葉のプロパガンダ臭を嫌忌した人のためのオープンソースだと思っているのだが、 思想や背景がないとまでは言わない。
しかし、オープンソース運動は「(OSD準拠の)オープンソースソフトウェアを活用する運動」であって、 「(OSD準拠の)オープンソースソフトウェアの開発」のことではない。重要なのはここだ。 OSD準拠のソフトウェアを開発しているからといって、オープンソース運動に賛同する必要も必然も存在しない。 オープンソース運動がオープンソースソフトウェアを利用しているのは事実だが、 OSD準拠のライセンスを選んだ時点でそのような利用を許容している(or そのような利用を制限することはあきらめている)とみなされるだろう。
もちろん、私だってこういう文章を書く前に少しくらいは考えるので、 「言葉なんて特定の誰かが「定義」するものではない」ことは認識しているわけだ。一般論としてそれは正しい。 言葉は誰かが中央集権的に管理しているものではないし。
しかし、
という条件がすべて揃っている場合には、「定義に従って使った方が良い」と 薦めることはできる。 「言葉なんて特定の誰かが定義するものではない」が、 特定の誰かが言葉の定義に影響を与えることはできると思うから。
ところで、私はいまだに、上記の条件が成立する場合に元々の定義を尊重しないのは「失礼」と思うのだが、 それって「自分だけが正しいという独善的」な態度に見えるんだろうか。
*1 メリットについてはtachさんのアレゲ日記が参考になる
私自身は自分自身がどのように分類されてもまったく気にしない、 その分類にウソや不都合がなければ。
ですから、私が「ほげほげ主義」に対してまったく共感もしていないのに 「ほげほげ主義者」と呼ばれればそれはウソなので、イヤだ。 また、将来日本人が迫害されるような時代になり、私が日本人であることを秘密にしているのであれば、 それがウソでなくても日本人と分類されたくないと感じるかもしれない。
では、塩崎さんの開発した(OSD準拠の)ソフトウェアがオープンソースに分類されることは、 ウソであるか、不利益であるか。
塩崎さんは私の定義に基づいた述語世界(Mワールド)では、ウソでも不利益でもないが、 現実世界では違うとおっしゃっているようだ。結局は現状認識の違いということなのだろう。
塩崎さんは「現状の実世界の人々の認識はそれ(私の世界)とは異なる」ので現実を認めよ、という意見であり、 私は「まだ間に合う、あきらめることはない」という意見だということだ。
実際の私のまわりには、
が大多数で、わずかにオープンソースについて知っている人はおおむね
である。 いわゆる「オープンソースの定義は変質してしまった」という主張の人は、 たまにツッコミやリンクでお目にかかる以外には会ったことがない。 人間は自分の住む環境から見えるもので世界観を構築するので、 私には「現状の実世界の人々の認識はそれ(私の世界)とは異なる」というのは実感できない。
さて、塩崎さんおっしゃるところの「Mワールド」においては、述語定義は
である。主義主張は前者にはなく、後者にある。
私はこのことは「定義」という言葉から自明だと考えていた。 「オープンソースソフトウェアとは以下の条件を満たす(配布条件の)ソフトウェアである」という「定義」が 与えられて、それをすべて満たすソフトウェア(OSD準拠)がオープンソースソフトウェアでなかったら、 それはどこかに他の定義がある、つまりその定義は本当の定義ではないということになる。
私は、オープンソースという単語がOSDとともに導入されたという歴史的経緯を考えれば、 OSDという「呼称」を受け入れるならば、この述語定義も事実として当然のように受け入れられるものだと考えていた。 たとえ「オープンソース」という単語からこれ以上のものを感じたとしても、 OSDについて聞かされたらそれは誤解であると理解できるだけの知性を持つ人が十分に多いと。
事実、私のまわりの多くの人々はこの述語定義を現実のものとして受け入れるのに困難はなかったようだ。
例のスライドは、 私への「オープンソースについて語ってくれ」との依頼に応えて作成したものだ。 当然聴衆は、私の世界観に基づいた『オープンソース』について聞くことを期待していたと考える。 聴衆の中には「それは違う」と思う人もいるかもしれないが、そこまでは私の責任ではない。
ある世界観を提示し、判断の材料を提供し、最終的に自己責任で判断してもらう、 それが啓蒙活動というものだろう。 そして塩崎さんは「啓蒙活動は自由」だと断言された。
塩崎さんが
そして、私やその他大勢の人々は M ワールドで生きているのではなく、 実世界で生きているのです。少なくとも私は最初からその定義に同意してないし、 明らかに世間の認識は M ワールドに一致してはいない。 そして、私には両者がそんなに近いとすら思えない。
と感じるのも、主張するのも、もちろん自由だ。
しかし、私の世界観のただ中に踏み込んできて、「明らかに世間の認識は M ワールドに一致してはいない」とまで断言されるのであれば、その十分な根拠を期待したいものだなあ。
「だってオープンソース運動あってのオープンソースなんだから思想を含むのは当然」とか、 「言葉なんて特定の誰かが「定義」するものではないから当然」とか、 「オープンソースソフトウェアというのは、 オープンソース運動という考え方に賛同しそれに参加した人が書くものであるという認識は当然」というものでないことを期待する。
私たちは意見に隔たりがあるので「当然」や「自明」は根拠にならないので。
結構あちこちから反応があるのは嬉しいといえば嬉しいのだが、いくつかのツッコミには誤解と思えるものがあった。 あるいは私の方が誤解しているのかもしれないが。目についたものに反応しておく。
ソースを公開したら「オープンソースになってないから対話拒否だ。オープンソースとしてちゃんとしたほうがいいよ」なんて言われるのはごめんです。そっとしておいてほしい。こう思うわけなんですが、誰にどうあってほしいのか書かれていなかったので、前出のように言われてるかと思い、ひどいことを言う人もいたもんだと思ってそれ以降スライドを見るのをやめました。
「オープンソースになってないから対話拒否だ。オープンソースとしてちゃんとしたほうがいいよ」というのは、 私の主張を組み替えたものですが、事実ではありません。
とは主張していますが。ソースを公開する人は当然オープンソース(OSD準拠)にしない権利を持つと思います。 あえて言えば対話を拒否する権利も。
メリット自体が当人に都合が良いだけであり、皆にとっての メリットではない上に、メリットなどいらないという人に メリットがあると言っても詮無いことだと思います。
私自身は最近再定義された（オープンソースという言葉が どの時点で再定義されどのように利用されてきたかについては 意図的に隠さずはっきりしたほうが良いです。）言葉に 勝手に含められることは断固拒否します。
私の述べたメリットなど要らない、あるいはそんなメリットなぞそもそも存在しないと考える人に とっては詮無いことだと思います。が、そうでない人もいるわけですし、 私自身は「結局は万人にとってメリットとなる」と信じていますから(根拠は示せないのですが)、 メリットを語り続ける必要はあります。
それと私は恥ずかしながらオープンソースという言葉が「最近再定義された」という出来事に思い至りません。 OSIが「Open Source」という言葉よりも「OSI Certified」という言葉を使おうとしているということかなあ。 でも、これは「再定義」ではないしなあ
というわけで「意図的に隠している」わけではなく、単に無知なだけだと思われますから、 ぜひとも、かよさんの方から「はっきり示して」くださいませんか。 それが分かると「勝手に含められることは断固拒否します」という気持ちも理解できるかもしれません。
<追記>
あ、そうか。最近OSDに10番目の項目が追加されたことかも。すっかり忘れてた。
でもそれって私には瑣末な違いに感じられるなあ。かよさんにとっては違うんですか？
</追記>
他にも、「私のほうこそ詭弁」とか「論理破綻・自己矛盾」とかいう ツッコミをもらったが、自覚できていない。私の論に矛盾や間違いがあれば是非直せるように指摘していただきたい。
追記
とか言ってる間にもさらなるツッコミが。
あなたが「オープンソース」として勝手に名前を付けて勝手に範囲を確定しているものも、あなたが「失礼な俺定義の『オープンソース』」と呼称しているものと同類の「俺様定義」でしかない、と言われているのが解りませんか?
え？ 全然分かりません。塩崎さんの主張にはそれは含まれていないと思います。 読み落としたかな。OSDはオープンソースの単語を作り出した人たちがその定義として用意したもので、 私が勝手に範囲を確定したわけじゃないし。 「OSDがなんぼのものじゃ」とか「OSDがあるからっていい気になるなよ」とかは 以前に聞いたことがありますが、それはそれ、ですよね。
「失礼」という表現がOSD以外の定義を使っている人に対して失礼で気に障ったということはあるかもしれません。 私はOSD以外の定義を尊重しない立場なので、私にとってはある意味当然なのですが、 無用の反発を招いたという意味で戦略的には失敗だったかもしれません。
「オープンソースみたいな何か」を塩崎君が「フリーソフト」と書かなかったことを「呼ばざるを得なかった」として議論しているのは違和感を感じる。この辺りの展開は不自然だと思う。
まつもとさんが気が付かなかった可能性もあるが私はそう思いたくない。
なるほど。私自身は塩崎さんがわざわざフリーソフトウェアと書かなかったことに大きな意味を見いだして、 「フリーソフトウェアという言葉では表現し切れないなにか」を意味していると読んだのですが、 それは深読みのしすぎだったということですかね。今思うとそれは否定できませんね。 となると、先の文章のこの部分は論理の飛躍があったと言えますね。
わざわざ時間をとって指摘していただきありがとうございます。
「補足」なんて言ったら八田さんに失礼だが、私の書き切れなかったことを書いてくださっている。 最初からあんな風に書けてたら面倒なことにならなかったかも。
去年の6月といい、フレームを生みやすい体質？
だとすると、改善すべき点はなにか。 ただ、「発言しない」という対策は避けたい。
世間一般で言われている「オープンソース」の意味と「OSD 定義によるオープンソース」とは同じものではなくなってしまっているので、
- 「OSD 定義によるオープンソース」だけが正しい「オープンソースの意味」だという意識は (少なくとも現段階では) 捨てる。
- 「OSD 定義によるオープンソース」と「世間で言われているオープンソース」とを常に明確に区別して議論する。
ということは強く希望したい。
意識を捨てる？ なぜわざわざそこまでの譲歩をしなければならないのでしょう？ その簒奪を許すだけの理由は？ (私にとっての)メリットは？
世間一般とおっしゃるが、実際の世間一般は「オープンソース」なんて知りませんって。 「普通」とか「世間」とか持ち込んでもあんまり意味ないんじゃないですかね。 ほとんどのケースでは「私のまわり数人」程度の意味でしょうし。
区別という意味では、私はいつも区別していますよ。 「OSD準拠以外のオープンソースなぞないっ」という形ですがね。
今野さんの
ところで
フリーソフトウェアは主観的、オープンソースは客観的などという表現がなぜ出てくるのか、私は不思議でならない。 「オープンソース」という考え方を広めたいのだろうけれど、 「フリーソフトウェア」という考え方を故意におとしめているように思えてならないのだ。
という感想は深読みのしすぎです。 「思えてならない」のかもしれませんが、事実には反します。 私は開発者としてはフリーソフトウェア擁護派ですし。
ソフトウェアの自由が大切という主張は本質的に主観的だと思います。 当然そんなの全然大切じゃない人もいるわけで。私自身は心から賛同しますけど。 主観的だからといって意味がないわけじゃない。むしろ主観的なことの方が大切なことは多いでしょう。 愛とか。
ビジネス上はソフトウェアをどのように利用することが許されるか(だけ)が重要です。 その判断のためには一定の判断基準が必要です。これは客観的な方が望ましい。 主観的な動機なんか関係ない。 OSDは(比較的)客観的に判断できるように決められています。
これらは単なる事実であって、別にどちらが良いとか悪いとかいう問題じゃありません。
もしかして、オープンソースの定義が後づけだと思っている人がいるのだろうか。 ほえさんのツッコミを読んで不安になった。
私の知識が正しければ、経緯は
である。 1997年以前にはオープンソースという用語は存在したことはなかった。 オープンソースは登場した最初の時点からOSDという定義が与えられていた。そのはずだ。
もっとも一次資料が見つかってないので、今後も探す必要はある。
追記:
オープンソースという単語が登場したのは1997年だと思いこんでましたが、 <URL:http://www.opensource.org/docs/history.php>によれば、 実は1998年2月初頭のようです。この文章を信じる限り、 オープンソースとOSDはやはり(ほぼ)同時に登場したようです。 それぐらいあらかじめ調べておけよって。その通り。恐縮です。
繰り返しになるけど、世間一般はオープンソースなんて知りませんって。
思考実験してみよう。
世論調査をするのと同じ方法でオープンソースについて意識調査をするとしよう。 公正のためrandom digit numberingのような手法を使う。人数は3000人くらいだろうか。 きちんとした調査のプロにやってもらうのがいい。
質問内容は
結果はどうなるだろうか。私の予想は
というものだ。これでもだいぶ甘めに見積もっている。
もし、私の予想が正しいとしたら、「世間一般で言われている「オープンソース」の意味と「OSD 定義によるオープンソース」とは同じものではなくなってしまっている」なんてのは幻想だ。そもそも世間一般でオープンソースなんて言われていない。たとえ「オープンソースを知っている人」の中で「誤解している人」の割合がいくら多くても、そんなの誤差の範囲だ。コップの中の嵐だ。
オープンソース運動は利用者の立場なので、これからメリットを受けられる人はソフトウェア開発者に限らずずいぶん多いはずだ。 そういう(現在98%に属する)人たちにちょいと啓蒙すればいくらでもひっくり返ると思う。
そんな状況で「正しい定義」をあきらめるのは、私には賢い選択とは思えない。
「「すでに知っている人」はITについてのオピニオンリーダーなので、重み付けが違う」という考え方もあるだろう。 だけど、本当にオピニオンリーダーになるべき人はOSDくらい理解できるんじゃないだろうか。 今回、私と議論した人たちも、自分自身ではOSDを理解しているのだと思う。 「そんなのどうでもいい」と思ってるかもしれないけど。 ただ「なにがオープンソースか」などと他人を説得したくないのではないだろうか。 憶測だけど、そうだとしたら、その気持ちは分かる。
でも、それは私があきらめる理由にはならないよね。 「Mワールド」の定義が私の属人的な後づけの定義ではなく、歴史的に正当であることは示した。 「Mワールド」の定義が多数派になるのは不可能ではない。
私にはあきらめる理由がない。
これだけオープンソースについて議論をしていても、 うちの家族は、父親が１日コンピュータに向かってなにをいっぱいタイプしているのか想像もできない。 そんなもんだ。
世間一般の「オープンソースソフトウェア」は「OSD準拠ソフトウェア」とは違うものらしい。 複数の人がそのように指摘している。だが、その世間一般の定義は人によって違う。
ほんとはどれやねん、と小一時間問い詰めたい気分だが、 あるいは重要なのは「どのように変質したか」ではなく「変質している」という事実だけなのかもしれない。 そうだと仮定して話を進めよう。
そのような主張している人を「オープンソース変質派」と呼ぶ。 「こんなのはレッテルだ」と嫌がる人もいるだろうが、 議論のためここだけで限定的に呼ぶだけなので容赦していただきたい。 オープンソース変質派の主張は以下のようなものだと理解している。
世間一般のオープンソースソフトウェアの意味はOSDから変質してしまっている。 だから、オープンソースという言葉の意味としてOSDを使うのはやめよう。
しかし、すでに述べたように、 実際には世間一般で広く認知されたオープンソースという言葉の定義なぞ存在しないのだ。私はそう思う。 「ソースがオープンなソフトウェア」という認知も、 「オープンソース運動に賛同している人が開発しているソフトウェア」という認知も ごく限られた状況でしか存在しない限定的なものだ。 「OSD準拠」と比べて圧倒的有利というのは幻想でしかない。
むしろ、OSDの歴史的正当性から世の中の趨勢はOSDに圧倒的に有利だと考えることができる。
あなたが雑誌か新聞の記者だとして、「オープンソースソフトウェア」について記事を書くとしたら、 なにを調べるだろうか。まずはGoogleだろうか。
「オープンソース 定義」での、検索結果を上から3つあげると(2004-02-25現在):
である。全部、OSDを扱っている。すべて八田さんの手によるものというのが彼の貢献の大きさを意味しているような。
「オープンソースとは」で検索しても出てくるのは種々雑多な「俺定義」よりもOSDを尊重したものが多い。 検索上位にあるもののうち、<URL:http://www.mochioumeda.com/archive/consensus/981001.html>だけは OSDよりは「ソースコードが公開に重点」という表現を使っているが、 <URL:http://www.opensource.org/>へのリンクがあるので尊重していないわけではない。
しかし、玉石混淆のインターネットからの情報を鵜呑みにするわけにはいかない。 実際に誰かにインタビューしなければ。聞くとしたら誰だろう。 私だったら、ちょっと考えると
最後のはちょっとアレだけど。
他にもいろいろいらっしゃるだろうが、これらの人を含めて思いつきそうな人はたいてい 「オープンソースとは」と聞かれたら、とりあえず「OSD」と答えるんじゃないだろうか。 人によっては「そうじゃない使い方をする人もいるけどね」と言うかもしれないけど。
そう考えると、「オープンソースソフトウェアについて考える」コンテキストでは、 すでにオープンソースの定義はOSDが主流であり、 「オープンソースソフトウェア＝OSD準拠ソフトウェア」である。 この流れは動かせないと認識するのが正しいんじゃないだろうか。 「オープンソース変質派」はもう遅いと感じてるのかもしれないが、 実はそれは逆で「(ソフトウェアの文脈で)オープンソースという言葉をOSD以外の意味で使う」行為を、 広く定着させ、正当化させるにはOSDは広まり過ぎていると思う。
「オープンソース」という言葉そのものは誰のものでもない。 商標登録したって、世間一般での使い方を規定できるはずはないし。 今後も「オープンソース政治」のような訳のわからない使い方をする人は出てくるだろう。
だが、ソフトウェアの話に限れば、個々人の現状認識がどうであるかに関らず、 実は「Mワールド(OSD=OSS)」と「現実世界」の距離は遠くないのではないか。 少なくとも現実世界と「オープンソース変質派」の世界との距離に比べたら。
藝夢日報より。 面白いので引用。
無償でソフトウェアを公開し使用させてくれた人に感謝の気持ちを表すための運動をしましょう。たとえ有償ソフトを売るためであっても、ソフトウェアの試用ができることは素晴らしいことです。感謝の気持ちを表す方法は人それぞれです。寄付をしても構いませんし、感謝のメールを送ったり、心の中で祈っても構いません。また、それによってさらに同種のソフトウェアが増えることを期待します。この活動を「シェアギフト運動」とします。シェアギフト活動は、シェアギフトソフトウェアを認定し、シェアギフトソフトウェアに対して感謝の気持ちを表すことを目的とします。シェアギフトソフトウェアは次のように定義されます。
- オンラインあるいは雑誌の附録などで取得可能なもの。
- 取得に際して、個人情報の入力や会員登録などの条件を設けていないもの。ただし、使用許諾への同意を求めることは認める。また、入手に実費（通信費・雑誌の購入費等）が必要なことは「条件」とはみなさない。
- 使用に際して期間の制限や有償のキーなど、そのソフトウェが現に有する機能に関して使用の制限がないもの。同種の有償ソフトに対して機能に制限があっても構わないが、有償のキーによって機能制限が解除されるものは除く。
この定義を満たすソフトウェアを「シェアギフトソフトウェア」と呼びます。あるソフトウェアがシェアギフトソフトウェアかどうかは、定義に沿って客観的に判断できますので、開発者・作者の意図は無関係です。この定義はシェアギフトイニシアチブによって民主的に決定されました（メンバーは私一人ですが）。シェアギフトという言葉の意味と、定義が一致していなくても、これが定義ですから客観的に判断できれば問題ありません。
どのソフトウェアをシェアギフトソフトウェアと認定するかは、シェアギフトイニシアチブによって決定されます。現在認定しているソフトウェアには、Rubyと数多くのエロゲの体験版があります。他にも多くのソフトウェアがあると思いますが、申請があればシェアギフトイニシアチブで民主的に議論の上、決定いたします。シェアギフトイニシアチブで認定されたソフトウェアは、「シェアギフト承認済み」のマークを掲げることができます。このマークを掲げたソフトウェアは、きっと多くの感謝を受けることができるでしょう。また認定していなくともこの定義を満たすソフトウェアを「シェアギフト準拠」と呼ぶことができます。
感謝の気持ちを表明することは、もっぱら使用者の善意と、代償を支払っていないことに対する贖罪を意味します。したがって、この運動はソフトウェアの使用者によるものであり、シェアギフトソフトウェアであることは、この運動の支持を意味しません。しかしながら、シェアギフトの定義を満たすソフトウェアを作成し提供したということは、この運動を許容しているとみなされても仕方ありません。それに大量の感謝のメールを受け取ることができるというメリットがありますから、きっと嬉しい悲鳴を上げてくれることでしょう。この運動は完全に善意のものですから、否定する理由などあるわけありません。
また、シェアギフトソフトウェアに感謝の気持ちを表明するために寄付をしたいが、寄付の先が分からない場合に、シェアギフトイニシアチブが寄付を受け付けます。シェアギフトイニシアチブは、シェアギフトソフトウェア普及のためにその寄付を使います。個々のシェアギフトソフトウェアが利益を得られなくても、それが全体の利益というものです。
大変面白い。前からそういう活動が必要だと思っていたのだ。 スライドにも書いたように、 現状ではオープンソースソフトウェアに対する感謝を表現する十分なチャネルが存在しない。 私自身は対象をオープンソースに限ったものを考えていたが、 そうでなくても別に構わない。 ただし、実効的であるためには「シェアギフトソフトウェアの定義」は十分検討した方が良いだろう。 ぜひ実現してもらいたい。
しかし、この後、「ちょっと皮肉がすぎますかね」とあるし、本文中に「Ruby」が登場するので、 もしかすると私はこれを読んで気分を害することが期待されているのだろうか。
とすると、私はこの「皮肉」のどの点で気分を害すべきであったか。
Rubyとエロゲの体験版を並列している点
私自身はその主のゲームになんの興味も持てないが、 Rubyがなにと同一視されようが私には関係ない。 同一の客観的な基準を満たし、私に不利益がないので、私は意に介さない。
「シェアギフトの定義を満たすソフトウェアを作成し提供したということは、この運動を許容しているとみなされても仕方ない」点
「許容する」のが「仕方がない」とか「関係ない」という意味であれば、 確かに許容しているだろう。
「この運動は完全に善意のものですから、否定する理由などない」点
善意だろうがなんだろうが、否定する理由がある場合があるので、 これは事実に反する。しかし、これは元々日記のエントリなので深い考察の結果ではないだろう。 実際にシェアギフトイニシアチブの活動が開始される時までには 趣意書からこの表現は取り除かれていることだろう、きっと。
「個々のシェアギフトソフトウェアが利益を得られなくても、それが全体の利益」という点
その通り。それがオープンソースのやり方である。あ、これは「シェアギフト」だったっけ。 ただ、もし「シェアギフトイニシアチブは、シェアギフトソフトウェア普及のためにその寄付を使います」という 宣言が事実でなかったら、それは詐欺であり、犯罪だ。犯罪には荷担されないようにお勧めする。
他には思い付かないなあ。
それに続く疑問にも答えておこう
また、「オープンソース」という言葉が 世間でもっと広い意味で使われているのは、 OSI自身が「 the term has become widely used and its meaning has lost some precision.」と書いてある通りです。だからOSI Certificatedマークを決めました、とあるわけですが、定義はOSIのものを使うのに、「オープンソース」であるものを区別するためにOSIの方針に従わないのはなぜでしょうか
私は「the term has become widely used and its meaning has lost some precision.」の続きにある、 「we still encourage use of the term "Open Source" to mean conformance to the OSD.」に従って、 「薦めている」のです。だから、OSIの方針に従っていないわけではないです。 もっとも、私はOSIの一員でもなんでもありませんから、OSDを尊重してもOSIに従属する義務はないんですけどね。
で、一連の「議論」を振り返って考えると、反省すべきだった点は、 たかはしさんの指摘にある
それはそれとして、まつもとさんのプレゼンにも、「OSD準拠なソフトウェアの開発」と「オープンソース運動への参加」とを混同させかねない傾向があるのではないか、という気もします。
だろう。
実際のプレゼンでは、あのスライドを使いながら1時間以上(質疑応答込みで90分)しゃべっているわけで、 その情報を抜きにしてスライドだけから評価されてもなあ、という気持ちも心のどこかにあるのだが、 それはそれとして、今後プレゼンを用意する場合には 「OSD準拠なソフトウェアの開発」と「オープンソース運動への参加」との混同を 招かないような書き方を心がけよう。
あと、「いち利用者」さんのコメントにある「間違った前提にたっています。(自身の無謬性を疑ってみるのが先決)」というのは気になる。自分に間違いがないなんて一度も思ったことないんだけど。 実際に今回も塩崎さんの意図を読み間違えるという失態を演じているし。 具体的にどこが間違っているのか教えてほしいなあ。
それとも、もしかして「自分だけが正しいような口ぶり」とか「態度がデカい」とかが気に入らない ということなんだろうか。 自覚はしてるんだが、こればっかりは簡単には直らないなあ。
今日、娘たちの学校は避難訓練だった。 私たちが子供のころ、避難訓練といえば火事や地震を想定しての訓練だったものだが、 最近の避難訓練は不審者が学校に侵入したというケースを想定するのだそうだ。
世の中も変わったものだ。
つまり、こういうことか？ たとえて言うと
私有財産制の否定は主張しているけど、「共産主義」とは呼ばれたくない
とかそんな感じの(注: 例の内容に深い意図はありません)。
「オープンソース」という単語にはすでにある種の色が付いているので、 たとえ自分のソフトウェアがOSD準拠であろうともその単語で呼ばれるのはイヤだ、 という感情の吐露であったと。
その「色」は誤解によるものなんだろうけど、 自分はオープンソース陣営じゃないので誤解を解消するコストは取りたくないと。
そういう感情論なら理解できないでもない。
でも、たとえどう感じたとしても、やっぱり無理筋じゃないかなあ。私のスライドがあろうがなかろうが
以上、OSD準拠のソフトウェアがオープンソースソフトウェアと呼ばれることは、 誰にも止められないんじゃないかなあ。「色を消す」ことの方がまだ可能性がある。
私のスライドの一枚にある「オープンソースは客観的」という表現(だけ)を読んで、 自分の中にある「オープンソースソフトウェアはオープンソース運動に賛同したものが書くソフトウェア」という自分定義と組み合わせて、塩崎さんを始めとする「オープンソースなんてどうでもいい」と思っているOSD準拠ライセンスを持つソフトウェアの開発者を「オープンソース運動に賛同している」と誤解するような人はかなりイタい人だし、 その誤解を解消するのに「俺はオープンソースなんて関心ない」の一言で終わらないような人物は、 私のスライドがあろうがなかろうが、イタい誤解を拡大再生産する人なので(そしてそういう人物は実在するが)、 そんな人のことを心配して行動を規制するのは、私はイヤだ。
むしろ、(まともな人を対象に)啓蒙活動を続けて「色を消す」ことを実現したい。 それは最終的には塩崎さんのような人にも利益になるだろう、きっと。
「フリーソフトウェアは主観的」、「オープンソースは客観的」と書いた時に考えていたことはこんなことだ。
ビジネス界隈で、 実利的な理由でfree software license(OSD準拠ライセンスとほぼ同義)を使っている人たちの中には、 塩崎さん以上に強い気持ちで、「俺はソフトウェアの自由には全然関心がないから 俺のソフトウェアをフリーソフトウェアと呼んでくれるな」という人がいるんじゃないかな。 そして、フリーソフトウェア陣営はそういう人たちに対する明確な解答はない(ような気がする)。 言えてせいぜい「これこれのライセンス条件であればあなたの動機はともかく結果的にソフトウェアの自由は拡大するんです」くらいではないか。根幹に「自由」という明確(で主観的)な意図を含んでいるがゆえに。
「オープンソース」にはそこに対するアンチテーゼの側面がある。 OSDには意図は含まれていない、少なくとも明示的には。 単に「オープンソース」と書いた時にはその「隠された意図」を意味する場合もあるが、 それは文脈から読み取られるべきであろう。
私のスライドの「フリーソフトウェアは主観的」の意味は、 「あるソフトウェアがフリーソフトウェアかどうかは厳密に言うとソフトウェアの自由を守り拡大する意図があるかどうかという主観的なもので決まる」ということであり、 一方、「オープンソースは客観的」の意味は「あるソフトウェアがオープンソースかどうかはOSDという客観的なもので決まる」ということだった。これは私の個人的な意見だ。
だから、「オープンソース運動は客観的」とか「OSDの背後にある意図が客観的」などというつもりは元々ない。 ていうか、客観的な運動とか客観的な意図なんてそもそも存在するはずないんだから。
個人的な意見では、きちんとした定義を見せられれば、 多くの人はオープンソースに関連した用語を正しく使えるようになると思う。 要するに辞書がないのがいけないのだ。
「言葉は誰のものではない」ので、私が決めるわけではない。提案するのだ。 出版社だって言語は彼らのものでないのに辞書を売ってるしな。 『新明解』なんかある意味日本語を私物化してるような気がする。
名詞
形容詞
なんかだんだん『オープンソース悪魔の辞典』みたいになってきたな。
この定義を読んだ人は3日以内に他の三人にこの定義を広めないと呪われる、かもしれない。
「おーぷんそーす祭」のせいかwww.rubyist.netのサーバが悲鳴を上げているので、引っ越しを計画する。これは移行途中のテスト。
一部の人が「OSIはOSDによる「オープンソース」の定義を放棄した」と豪語し、 ま2さんが翻訳してくださった 「Conformance to the OSD」だが、ま2さん版には肝心の部分の翻訳に不満がある。
OSDに準拠する
（このセクションはOSDの一部ではない）
我々は，ソフトウェアコミュニティの大多数が「オープンソース」という用語で指していた（そして今でも指している）ものは，OSD（Open Source Definition）でとらえていると考えている。しかし，この用語は広く使われるようになり，その正確な意味は失われてしまった。OSI公認マークは，そのライセンスのもとで配布されるソフトウェアがOSDに従っていることを，OSIが公認する方法である。一般的な単語としての「オープンソース」はそのような保証を与えることはできないが，我々としては今でも「オープンソース」という用語をOSD準拠の意味で使うことを推奨している。OSI公認マークに関する情報，またOSIがOSD準拠として承認したライセンスの一覧に関しては，OSDの公認マークのページを参照すること。
これだと強調した部分は「なくなっちゃった」という敗北宣言に聞こえる。実際には オリジナルでは「its meaning has lost some precision.」である。 ここはやはり八田版の訳を採用したい、
準拠について
(この節は「オープンソースの定義」の一部ではありません)
私たちはこの「オープンソースの定義」が、ソフトウェア界の人々の大多数が 「オープンソース」という語に元来込めていて、今も依然として込めている意味を捉えていると思っていますが、この語が広く使われるようになるにつれて、そ の意味するところがいくぶん正確さを失っている感は否めません。そこでOSIでは、ソフトウェアの頒布に適用されるライセンスがOSDに準拠していることをOSI認定マークで証明することにしています。私たちは 「オープンソース」という用語をOSDに準拠しているという意味で使うことを推奨していますが、 総称的な用語としての「オープンソース」には何の保障もありません。OSI認定マークについての情報、そして OSI が OSD に準拠していると認めたライセンスのリストについては認定マークのページをご覧下さい。
都合の良い訳を選んだといわれないためにも、原文は以下の通りである。
Conformance to the OSD
(This section is not part of the Open Source Definition.)
We think the Open Source Definition captures what the great majority of the software community originally meant, and still mean, by the term "Open Source". However, the term has become widely used and its meaning has lost some precision. The OSI Certified mark is OSI's way of certifying that the license under which the software is distributed conforms to the OSD; the generic term "Open Source" cannot provide that assurance, but we still encourage use of the term "Open Source" to mean conformance to the OSD. For information about the OSI Certified mark, and for a list of licenses that OSI has approved as conforming to the OSD, see the OSD Certification Mark page.
要約すると
ということだ。別に普通のことだ。OSDをあきらめたわけでもなんでもない。
OSIに限らず誰にだって 「オープンソース」という言葉が使われるあらゆる局面で「OSD準拠」を強制することなんかできない。 また、いくら歴史的に見て「オープンソース」という言葉と「OSD」がほぼ同時に登場したからと言っても、 個人個人のレベルでは当然「オープンソース」という言葉だけを最初に耳にした人が圧倒的に多いはずだ。 だから、「正確さを失う」のはある意味必然かもしれない。 実際、そこまで正確な定義を用いる必要がある場合というのは実は少ないだろう。
今野さんが「OSDの欠点」について述べておられる。 八田さんの記事にもある通り、 OSDは完璧からはほど遠い。今野さんの指摘の通り
これからも「OSI の人々が OSD 準拠にはしたくないライセンス」が登場する度に OSD は改訂し続けられるのだろう。
が、ライセンスなどという社会生活に関るものを自然言語で記述するOSDが完璧でありえるはずはない。
元々、人々の頭の中には「オープンソースのようななにか」というものがあった。 それはFSFのいう「フリーソフトウェア」に近いものだったが、かならずしも同じではなかった。 人によっては自由へのこだわりが少ない人もあったから。
しかし、それは各自の頭の中の漠然としたイメージで名づけられておらず、 したがって共通に扱うこともできないものだった。 ま2さんがおっしゃった「SF論争」のように結論の出ない議論に陥ってしまう。
そこで合意できない「みんなの頭の中だけにあるなにか」を追求するのを止めて、 「なにか」の(比較的)客観的な近似として定義されたものがOSDだ。 あらゆる状況を予想できる知能が足りなかったので(そんな知能の持ち主はヒトにはいないと思うが)、 OSDを満たしつつ「なにか」を満たさないライセンスが次々と出てくるので OSDは改訂し続けられてきたのだ。
だから、不完全であるということは、事実だ。 また、(ある版の)OSDそのものは客観的だが、その定義の理由は非常に主観的だ。
私の考えは、にもかかわらずOSDのやり方には有用性があるので採用しよう、というものだ。
あと、塩崎さんには、おそらく、UNIX等の世界で昔から連綿と流れてきた、もっとゆるやかな「ソースコード公開の文化・風潮」（もしくはおすそわけ文化？）に対しての愛着があるわけで、それを命名化できないものかなとも考えるんですね。
そういう命名ができれば、私を含め、「オープンソース」よりその名前を使いたいと思う人は多いと思います。
「オープンソース」が（無償で）「ソースをオープンにしているソフト」をあらわすジャンル、くらいのゆるやかな意味であれば、そのまま使いたいんですけどねぇ...
というのは、自然に聞こえる。ほんとはみんなそれがしたいんだよ。
しかし、やってみればその難しさは分かるだろう。 考えはじめると「無償でソースコードを開示していれば本当にそれだけで十分なのか」とか。 100人集まったらその100人にそれぞれの「おすそわけ文化」があって、 ひとつのムーブメントを作り出せるほどには一致できないと思う。 それぞれの漠然としたイメージを突き詰めるとどんどん実体がなくなって、 とらえどころのないものになってしまう。 それだけの求心力を産み出すためには
のような「基準」が必要だ。これでみんなが共通の土台に立って話し合い、 運動することができる。
BSDのゆるやかな文化は素晴らしいと思うけど、 BSDの範囲を越えて、 BSDライセンスのソフトウェアの利用を促進したり、 BSDライセンスを選ぶソフトウェアを増やしたりするような、 ムーブメントにはならない(なってない)んじゃないだろうか。 そんなもの欲しくないのかもしれないけど。
でもって、私はムーブメントを必要としている。 それは私の生活のためだったりするんだけど。
私は「自由なソフトウェア」が好きだ。 プログラムを書くすべての時間を自由なソフトウェアのために使いたい。 世の中のソフトウェアがより多く自由なソフトウェアになって、 私と世界中のプログラマの「ソフトウェアの自由」が増せばよいと心から考えている。
しかし同時に、私の生活には費用がかかるし、 養うべき妻も子供もペットもいる。霞を喰っては生きていけないのだ。
となると、私にとっての最良の選択肢は「OSDとオープンソースを利用すること」だ。 オープンソースビジネスにかかわる人たちがオープンソースソフトウェアを利用しているように、 こちらも彼らを利用しかえそうというわけだ。 こうやって私はここ数年生活をしている。
「こういう下心は嫌い」という人はそりゃいるだろう。 「「オープンソース」という単語をよく使う人は胡散臭いから一緒にされたくない」 という気持ちも理解できないでもない。
嫌いなら嫌いで結構だが(万人に好かれるとは思ってないし)、 そういう人たちが「オープンソース」と距離を置くことができるためにも、 私は「オープンソースは客観的」であり、 「オープンソースソフトウェアは開発者の意図とは無関係」と言い続けるのだ。
ところで、私が例のスライドで「オープンソース」を連呼する最大の理由は やはり「オープンソース」についての講演を依頼されたから、である。 誰かが私に「フリーソフトウェアの光と影」とかいうテーマで講演を依頼したら、 ものすごい勢いで「フリーソフトウェア」について語ると思うんだけど、 いかがだろうか？
思うにOSD流の定義をオープンソースという言葉の定義として認めてしまうと、「ソースをオープンにする」などといった文脈において「オープン」という言葉の語義をOSD流に変更・拡張することを余儀なくされるわけで、
それは違います。
「オープンソース」という言葉の定義は 「ソースをオープンにする」という表現の意味を変えません。 変えるのは「オープンソース」という言葉の存在です。 定義はどうあれ、「オープンソース」という言葉はすでに存在しているので、 「ソースをオープンにする」という表現は
のいずれかわからないので、すでに非常にあいまいになってしまっています。 OSD流の定義を認めるとあいまいさがちょっとだけ減りますね(笑)。 焼け石に水でしょうか。
まあ、辞書を見てもひとつの単語に意味がいくつもあるのは普通なので、 人間はその程度のあいまいさには耐えられるのかもしれませんが、 いずれにしてもOSDは無実です。
次女とその友人とを連れてスケートに。
ほぼ一年ぶりになるので、滑り方を忘れている。 しばらくすると少しはマシになったものの、姿勢が安定せず、 自分で「下手くそだなあ」とあきれる。
娘の友人はスケートははじめてということで、 最初は手すりを磨いていたが、しばらくすると滑れるようになっていた。 なかなかの順応能力。
帰るまぎわ、ふざけていたら思いっきり前方に転倒。はずかしい。 さらに肋骨が痛い。ひびが入ってたりして。
くっぱさんからコメントとそのフォローをいただきました。
再度要約すると、
ということだそうです。
同意できる部分もあるのですが、結論には同意できません。
まず、(1)には一部共感できる部分はあるものの、完全には同意できません。 「オープン」という単語に「オープンにされたものを自己責任のもとでどのように利用してもかまわない」というライセンス上の基本前提があるというのは、面白い考えだと思います。 確かに「オープン」という言葉の使い方のうち、いくつか(多く？)はそのような考えで説明できそうです。 しかし、逆に言うと私は指摘されるまでそういう風に認識していなかったわけで、 それが「オープンという言葉が持つ基本概念である」とまでは言えないんじゃないでしょうか。 「全米オープン」とか「オープンカー」とか「オープンサンドイッチ」とか、 かならずしもその概念で説明できそうにありませんし。 IT分野に限定しても「オープンアーキテクチャ」、「オープンシステム」、「オープンスタンダード」、「オープンオフィス(OpenOffice.org)」、「オープンウィンドウ(OpenWindow)」、「オープン・クローズの原則(Open-close principle) by B. Meyer」などがすべて上記概念を満たしていると断言するのは難しいでしょう。 一時期(10年以上前？)、この分野で「オープンなんとか」は流行語のように多用されましたし。
さらに言えば、 合成語である「オープンソース」における「オープン」という単語の使い方が、 「オープン」の意味を「根底から変更するよう迫る」ほどインパクトがあるような気はしません。 推測するに「オープンサンドイッチ」のインパクトと同程度*1ではないかと。
その次の(2)については、「OSDのオープンは上記の概念を逸脱している」という点では同意します。 OSDは「どうぞご自由に」という印象を与えるためには条件が多すぎます。 もっとも、それは「オープンの仕方」を指南していると解釈すべきなのかもしれません。
最後の(3)は、その前提となる(1)に同意できませんから、同意はしません。
私の意見は、
というものです。
くっぱさんは「オープン」という言葉の「基本前提」と、 「オープンソース」という言葉が「オープン」に与えるインパクトの両方を、 私よりずっと大きく(おそらくは過大に)評価してらっしゃるように思います。
他にもさゆちゃんとかKLさんからツッコミをいただいています。
おじさんは仕事を頑張るのは嫌いなんですが、仕事は投げ出さないようにしようと思います ＞ さゆちゃん
KLさんのツッコミは、また難解なんで(まあ真剣に考えてくださった証拠だと思いますが)、 後で時間をとって考察しようと思います。コメント入力欄のサイズについては調査してみます。
追記:
「「OpenStep」は「Open Source」を意識している可能性が大」などと書いたら、 「OpenStepの登場は、OpenSourceの定義よりも前ではありませんでした？」との ツッコミが。
ちょっと調べてみると、どうもそうらしい。 1993年かあ。そういえばそうだったか、最近記憶があいまいになってきて(いいわけ)。
*1 いや、「OpenOffice.org」や「OpenStep」は「Open Source」を意識している可能性が大なので、もうちょっと大きいかもしれないけど