岡山で会議。夕べ夜更かししたせいで途中眠くて困る。
久米南の辺りで今月もまたツーリングの一団に遭遇。やはり岡山はツーリング人口が多いのか。 日差しがまぶしい。
会議では情報共有と水平展開が話題に。関係者全員がIT化されていないのが問題といえば問題だな。
あなたが自分で開発したソフトウェアをフリーソフトウェアとして公開しようとしたとしよう。 その時にどのライセンスを選ぶか迷ってしまうかもしれない。たくさんあるしね。
ここではそんなあなたにどんなライセンスがぴったりか診断してあげよう*1。 そのためにはいくつかの質問に答えてもらう必要がある。
ライセンスの選択として決してやってはいけないことは、自分用の新しいライセンスを作ることだ。 自分の経験から言って、これは避けた方が良い。俺ライセンスには危険がいっぱいだ。
既存のライセンスでは満足できないと思うことはあるかもしれないが、 既存のライセンスを選んだ方が無難だ。 既存のライセンスはそれなりに考えられているし、 広く知られているぶんだけみんなに理解してもらいやすい。
自分独自のこだわりというのは実はあんまり重要じゃないことが多い。 たとえば、私がRubyライセンスを定めた時には、 コードの一部を引用することについて明示的に許可したいと考えた。 しかし、実際にはBSDライセンスやGPLでも(少々明示的でないだけで)十分にカバーできる。
最初の質問は
である。もちろん、あなたには報酬はない。断りさえないかもしれない。
これが許せないと思うあなたはGPLを選択すべきである。
GPLならあなたのコードを組み込んだソフトウェアには同様にGPLを適用する必要がある。
ソース非公開で自由でないソフトウェアに利用される組み込まれる危険はない。
また、あなたは自分の書いたコードのライセンスを任意に設定できるので、 商用ソフトウェアに組み込みたい人が(有償で)特別のライセンスを結びたいと申し出るかもしれない。 いずれにしてもあなたに損はない。
これにYesと答えたあなたは当然GPLを選択すべきである。
その他のライセンス(の多く)は利用者がコードを自由でないソフトウェアに流用することを容認する。 これは結果として不自由なソフトウェアを容認し、間接的に支援することにつながる。 フリーソフトウェア運動に賛同するあなたにはGPLをお勧めする。
つい昨日「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:
拡充していくことができればこれに越したことはないと思います。 追加する質問や条件などは歓迎します。
*1 ネタだから、あまり本気にしないでね
旧来の電子メールの技術とMUAが採用しているメタファは破綻しつつあるという話。
電子メールは「破綻している」とハーンCEOは述べた。同氏は、米ネットスケープ社の最高技術責任者(CTO)をしていたときに、現在のような名声を獲得した。「われわれは、(電子メール・システムの)メタファー[暗喩：ここでは「システムの構造や機能を把握するための概念あるいは表現」といった意味]に変更を加える必要がある」
ハーンCEOは一例として、大部分の電子メール・ソフトウェアがメッセージの保存に利用している「フォルダー」というメタファーを挙げ、「このメタファーによる管理方法は、1日に5通のメッセージを受信することを想定していた時代に考え出されたものだ」と指摘した。現在ではこの10〜20倍のメッセージを受け取るユーザーも多く、それぞれを所定のフォルダーに整理するには時間がかかりすぎるという。
やはり、メールオーガナイザーの発想は正しいということか。
で、クラックされてRuby関連が滞っている間、 検索ベースのメール利用パターンについて考えてみた。
こういう機能があるクライアントなら、明示的に分類しなくても、 必要な時に蓄積したメールから情報を取り出すことができるような気がする。 ついでに、Webページも同じデータベースにクリップできるといいだろうなあ。
プログラミングコンテストに独創的な自作ソフトを
応募したかったけど平成17年3月31日時点で満21歳
無念・・・
それはそれは。しかし、希望はまだあるかも。今年に限っては移行措置として
という条件が加わる予定です。ごめさんがこの条件を満たせば...。
昨日は『げんしけん』にひきづられて考察できなかったが、 改めて内容について考察してみよう。
もっとも、ちゃんとした考察なら「高木浩光＠茨城県つくば市 の日記」を読んでもらった方が良いかもしれない。2chには読後感想文大会が開かれているらしいが、人大杉(人多すぎのこと？)で2chブラウザでしか読めないようだ。
ネタバレあり。あらすじ。
女子高生の恥ずかしいビデオがWinnyらしき「ファイル交換ソフト」によって流通してしまう。 流した元BFは問い詰められても、もはや回収することはできない。 女子高生の涙を見た警部補久遠あまねは...。
このことが示すようにWinnyでプライバシーを暴露された場合には、 回収することは困難である。というか、Winnyではムリ。 これは重大な問題だ。わたしだって人に知られたくないことはあるし、 それが勝手に公開されたら困る。回収不能なら大変に困る。
しかし、これってP2Pやらファイル交換に特有の問題なのだろうか。 高木さんは「それは詭弁。人の意識が介在するかどうかが肝」とおっしゃる。 Winnyが特に悪質であることを示すためには、確かにそうかもしれない。 が、人の意識が介在しようがしなかろうが、 侵害されてしまったことと回収不能であることには変わりがない。
たとえば、私の恥ずかしいビデオ*1がどこかのWebページで公開されてしまった、とする。HTTPは別に匿名を意識したプロトコルではないので、理屈では(官憲の力を使ってでも)だれがそのページを管理しているかを特定して、そのページの公開をやめさせることは可能である。しかし、そんなことは簡単にできることではないし(作中にもあったように海外でホスティングしてたら、とか)、たとえできたとしてもすでにタウンロードされてしまったファイルを消すことは(作中の「非常手段」を使いでもしない限り)不可能だ。
テクノロジーの進歩により、個人が大衆に直接アクセスできる手段ができたことそのものが、 この問題の背景にある。インターネットは便利さを提供し、人にパワーを与えたが、 そのパワーは悪意のある個人にも届けられたのだ。
現時点での私にはこの問題に対する解答はない。
ただ、問題があっても今さらインターネットの力を放棄できないこと、 確かに個人を保護しなければならないが、 下手な保護手段は(言論の封殺や弾圧に)悪用されやすいことだけは確かだ。
悩ましい。
*1 誰も見たくないや、そんなの
ソニーがウォークマン類似の特許を持つ発明家と和解し、対価として数百万ユーロを支払ったというニュース。
私は当の特許を読んでないので、
とかは、思っても言わない。実際にはもっと高度な特許かもしれないしね。
気になる点はここだ。
自身の勝訴を誇りとするPavelは、今度はウォークマンの類似製品を製造するApple Computerなどにも接触する計画だと話している。白いボディーが鮮やかなAppleのiPodは、ある意味でウォークマンのデジタル版後継機だと言える。
彼の特許が成立したのは1977年である。たとえ彼の特許がどんなにすばらしいものであっても、 特許の有効期限は20年であり、iPodが発売された年には、 少なくとも彼の最初の特許は期限切れのはずである。特許の本来の目的に則すれば、 期限がきた特許は自由に利用可能とし、人類のために広く公開するべきである。 もちろん、彼は当初の特許ではなく、関連特許によってAppleを「攻撃」するつもりだろうが、 特許の本来の精神には反していると言えよう。
最近はメールの読み書きに全文検索メーラーmorqを使っているわけだが、 返事を書かなきゃいけないメールをinboxに残しておくとすぐに数百通溜ってしまう。 まあ、処理速度が十分に速いのでそれは別に構わないんだけど、 溜った古いメールにリプライがついたことが発見し難いのが難点だ。 今日も危うく見逃すところだった。
しかし、考えてみればスレッドというものはなにも先頭のメールの日付順に並んでいる必要がある わけではない。Gmailとかはスレッド(conversation)の最後のメールの日付で並んでいる。
そうだよな。そっちがあるべき姿だろう。
というわけでmorqをハック。スレッド中最新のメールの日付でソートするようにした。 これで古いメールにリプライがあればスレッドごと浮かびあがってくるわけだ。 変更したのは、Rubyバックエンドでスレッドごとに最新の日付を保存するように追加した4行と、 ソートの基準を変更した1行だけ。 たった5行でこんなに快適。これこそがハックの醍醐味。
それから昨日の「;;」に対応できるようにruby-mode.elをハックした。 ruby-mode.elはmorqよりもだいぶ「魔術度」が高いので苦労した。 おまけにruby-mode.elに以前からあったバグを今回組み込んでしまったと勘違いして 見当違いなコード変更をしてしまってたし。
ま、楽しかったからいいけど。
出雲便が満席だったので米子便を使って東京へ。 東京の方が最終便の時刻が遅いから土曜日には有利かもしれない。 なぜかゲート前で社長と一緒になる。
で、品川で待ち合わせて、私、笹田くん、江渡さんで、 Smalltalkのデザイナーでありチューリング賞受賞者でもあるAlan Kay(と仲間たち)と 昼食会。なんか、すっごい緊張してるんですけど。
彼の考えている「子供たちのためのプログラミング環境」のために RubyなどSqueak以外の言語コミュニティからアイディアを借りたい、 ということで今回のセッティングであった。大島さん、ありがとう。
なかなか面白い話が満載であった。
WikiWygWysiWikiについて
「WisiwygなWiki」というのが語源なのは見ただけで分かるのだが、 実際はそれどころではない。プログラマブルなプレゼンテーションくらいから。 目指すのは２１世紀のHyperCardというのが近いかもしれない。 簡単なデモの範囲内ではViscuitに似てるけど、 ターゲットはもうちょっと違いそう。
Alan Kayの名刺
名刺ジャンケンで強そうなのをゲット。Bjarn Strustrupに負けない強さだろう。
AlanとRuby
Alan Kayに「Rubyは好きだ」と言わせた。それなんて罰ゲーム？
AlanとSmalltalk
えーと、「Smalltalkのことをもう愛していない」とか、 「Smalltalkは死んだ言語(dead language)だ」とか、 「Smalltalk-80よりもSmalltalk-76の方が私の理想に近い。Smalltalk-76はRubyに似てる(え？)」とか、 「コンセプトの私(Alan)、実装のDan (Ingalls)とのせめぎあいがあった。Smalltalk-80は私の手を離れ、Lisp好きの影響を強く受けてた」とか、 「おいおい、そんなこと言っていいのか」というネタ満載だった。
拡張可能文法とマクロ
「言語は拡張可能であるべきだが、Lispのマクロは正しい解ではない(強力過ぎ)」という点で意見が一致した。実際、私は20年近く遅れてSmalltalkの真似をしてきたわけだが、それでもなお、Alanとここまで意見が一致するのは意外であった。
その他、古い言語について
IMPとかLucidとかいう初耳の言語の話をいくつか聞いた。 後で調べなきゃ。歴史に埋もれていったアイディアや言語はたくさんあるんだなあ。
歴史は繰り返す・悪貨は良貨を駆逐する
すばらしいアイディアが世に広まるとは限らない。 過去の反省に基づかないで「新しい」技術が誕生するとは限らない。
特にWWWブラウザについて、そう思ってるみたい。 全然プログラマブルじゃないし(Ajax(JavaScript)はあるけど、貧弱だし、ドキュメントモデルはHTMLページレンダリング以外の目的には最悪)、 せめてHyperCardのようなものが普及していれば。
彼らはWikiWygのようなものを、できるだけダウンロードなしに実現したいのだが、 そのためには現在のクライアントサイド技術はあまりにも弱い。
ああ、他にも一杯聞いたような気がするのに。全部録音すべきであった。
追記
えーと、一部で「Alan KayはSmalltalkよりもRubyが好きだと言った」といった言われ方がしていますが、 私が聞いたのは「(もう)Smalltalkを愛していない」と「Rubyは好きだ」です。 それぞれ別のタイミングで。
両方の発言を組み合わせて上記の結論を引き出すのは不可能ではないけど やりすぎだと思う。
笹田くんのオフィスに寄ってから、東京支社へ。 原稿用の下調べをする。
テーマは「キャズム」。 先月のマーケティングネタのときにはみだしてしまって削った部分を 膨らませて2ページ。まあ、テーマが決まっているから書きやすい、のだが、 どうにも時間がない。
イベントと原稿〆切が重なると辛いなあ。
先日の「好きを貫くためには」というエントリに対する 弾さんの反応。
「仕事を好きにしてしまえ」という発想はとても健全だと思う。 少なくとも「好きを仕事にする」ことを目標とするよりは。
「好きを仕事にする」ことを目標として選ぶのは大変危険で、 「今ここにいる自分以外の『本当の自分』を求める」ことにつながる。
「本当の自分探し」ほど不毛なものはない。 そんな自分は存在しないからだ。
ある意味、新規蒔き直したい症候群にもつながる。 そんなのうまく行くわけはない。
なすべきは「継続的な変化」である。 自分の今ある位置から、より快適な方向へ少しでも変化するように 継続的に環境に働きかけ、より快適な環境、より好きなことがたくさんできる環境を 勝ち取ることができるようにすることこそが進むべき道であろう。
「青い鳥」はどこにもいない。 「本当の自分」もどこにもいない。
「好きを仕事にする」のは目標であってはならない。 それはあくまでも「結果」である。
究極シンプル言語HQ9+の後継言語HQNSFPL9+。
HQ9+の持つ以下の機能に加えて、
さらに以下の機能が増えている。
だからなに？ と言われそうだが。
Railsの仕事や求人は増えているが、 Railsから離れたRuby単体の仕事はどうだろうか。まだまだのように思える、という話。
まあ、私がそれを望んでいるかどうかは別として、 それは事実としてあると思う。RubyKaigiのキーノートで使わせてもらおうかな。
DHHが
Multiple cores are laughably easy to utilize for web applications because our problems are rarely in the speed of serving 1 request.
といったがそれは事実か、という話。
まあ、DHHが話題にするRailsがカバーする領域では これは事実だと思う。が、それを必要以上に一般化して反論するのはどうかと思う。
が、反論の内容は以下の通り。
で、ここで「しかし、Erlangなら」と続くわけだが、 まあ、いいや。
CPU intensive requestsならAP4RやdRubyを活用する手もあるし、 メモリについてもいろいろと手は打てると思う。
ささだくんのオフィスで開発合宿。
出席者は
1.9の文法からm17nまで幅広い領域で議論が行われた。 特にlambdaとbreak/nextについては、ちゃんと明確化ができたと思う。
御茶ノ水で。
いろんな人と話をして楽しかった。 私が着ていった「Python Cookbook T-shirt」は あちこちでウケていた。 私、Pythonファンですから。
Dave Thomas, Tim Brayとも話をした。 元気そう。あまり時差ぼけとか感じてないように見えたけど。
合宿中の会話にモチベートされたので、 長らく使い続けてきたbashからzshに移行してみた。
思ったよりもはるかに簡単に移行できたので拍子抜けしてしまった。 愛用のbashrcもほぼそのままzshrcに移動できたし。
ただ、bashでは可能であったワードの途中でのコンプリーションが できないようなのがちょっと面倒。zshのことだからカスタマイズ次第で できそうな気もするのだが、設定項目が見つけられない。