今日は米子の教会に訪問の責任。母の日に実家の教会に出席の割り当てがあるとは粋な計らいか。 お話のテーマは「個人的な啓示」。 先日のビデオ予約の失敗の件を導入にいくつかの聖句を引用して。
今月のLinux Magazineの原稿にも応用できそうだし、 Web日記は思ったより役に立つようだ。
教会が終わった後、実家によって母の日に感謝の気持ちを示すべく、 昨日用意しておいた花を贈る。喜ばれる。もっとも、手配をしたのは妻だ。 こうして１年に１度感謝しておくと、残りの364日良い思いができる…
なんてことは考えていないよ、決して。
子供たちはカレーを作ることによって感謝の気持ちをあらわしたつもりのようだが、 かえって親の仕事が増えてたような気がするのは内緒だ。
今回の米子への移動は、妻の軽自動車を使った。 久々のマニュアル車の運転にクラッチを踏むのが0.5秒くらい遅れたことが数度。
ずっとマニュアル車じゃないとダメだとか主張していた人間が１年やそこらでこの堕落ぶり。 恥ずかしい。しばらく慣れてくると「軽自動車はギア比が」などど考え出すが、 堕落した運転者にはそんなこと言う資格はありません(＜自分)。
昨日の話題だが、これが報道されてからずっと考えていたのだ。
Winnyを使ったことはないが、著作権侵害のファイル交換に用いられていたのは事実だろう。 が、個々のファイル交換の行為者が法律に違反しているとして、 その違法行為に使われたソフトウェアの開発者が「幇助」で逮捕されるとはどういうことか。
朝日新聞の報道によれば、
「Ｗｉｎｎｙはすばらしい技術。開発したことだけで立件したわけではない」−−。京都府警の阿波拓洋・生活安全企画課長は１０日午前に開かれた記者会見でこう強調した。府警が立件に踏み切った背景は、金子勇容疑者の著作権法に対する挑発的な態度だった。
(強調はまつもとによる)のだそうだから、ソフトウェア開発そのものが問題ではないらしい。
ではなにが問題か。
「著作権侵害を蔓延させようという意図」をもって「違法行為に使われるソフトウェアを開発」したことか。 これらが両方同時に成立すれば、立件される可能性があるのか。
たとえば、私が「現在の日本の著作権法は間違っている。 インターネット時代に適合するためこれは正すべきだ」と挑発的な態度だったとして、 著作権侵害にRubyが使われたとしたら、 Rubyも違法行為に(も)使われるソフトウェアであると見なされ、私も幇助になるのか。
もし、そうならないとしたらその違いはなにか。 あるいはビデオデッキやテープレコーダーが合法でWinnyが違法である違いはなにか。
違法行為は取り締まられるべきだ。私自身は法律に違反すべきではないと考えている。 悪法は直されるべきだとは思っているが、法は法だ。
しかし、ソフトウェアあるいはツールの開発は、 それが法律で明確に禁止されているのでなければ違法であるべきではない。 また、人の生命に直結する武器・兵器を除いて、よっぽどのことがないかぎりは非合法化されるべきではない*1。
ところで「府警が立件に踏み切った背景は、金子勇容疑者の著作権法に対する挑発的な態度だった」って、 朝日新聞の言葉、もし本当ならかなりまずいんじゃないかと。日本国憲法には
とあるのだが。法治国家としてはゆゆしき事態では。
追記:
ところで、「著作権法における罰則規定の概要」によると、今回「著作権侵害」とされたであろう
などは親告罪である。では、著作権侵害幇助は親告罪か。もしそうなら訴えたのは誰か。
*1 そういう意味から、私は前回の著作権法の改正には反対だ
先にも書いたように「集会、結社及び言論、出版その他一切の表現の自由」は憲法でも認められた基本的人権だ。
たとえば、私がこの「言論の自由」を保障するために、 完全匿名を実現するP2Pベースの(そうでなくてもよいけど)掲示板ソフトウェアを開発したらどうだろう。 私の目的は基本的人権の追求であり、なんら恥じるところはない。
しかし、そのようなソフトウェアができたら、メッセージに混じって、 現在Winnyで流通していたような著作権侵害のデータが流通する可能性はある。 いや、きっとそうなるだろう。
そんな状況で、そのような著作権データが流通している事実を知りながら、 言論の自由の方が大切だからという理由で、開発を(2年間に236回くらいリリースして)継続したら、 それは著作権侵害幇助として立件されるか。
その時、私がうっかり、「そろそろ匿名性を実現できるファイル共有ソフトが出てきて現在の著作権に関する概念を変えざるを得なくなるはず」とか発言しちゃったら立件されちゃうのか。
将来、世界第一級のクリエーターになるような優れた人材を発掘し、成長を支援しようと、文部科学省は高校生を対象に、夏休みに合宿して創作活動をする「ＩＴスクール２００５」を開く。
文部科学省もクリエータを発掘したいようだ。最近の若い者はチャンスがたくさんあるなあ。
経済産業省も負けずに今年もU20プログラミングコンテストを開催する。 我と思わん若者は今から準備していて欲しい。
江島さんがZope Essentials 1に参加された話。それはどうでもよいのだが(失礼)、
Pythonといえば、まつもとさんがMatzにっきに書かれていた調査ではRubyに次いで2番目に愛されている言語だそうです。また、あの伊藤穣一さんが愛用していることでご存じの方も多いでしょう。
というようにあの調査を本気にする人が出るような書き方はいかがなものかと。 遊びですから，遊び。
江島さんと言えば、つい先日『4798108308』を献本していただいた。 Asteriaは彼の所属するInforteriaが提供している ビジュアルプラットフォームだ。ざっと読ましていただいた限りでは、いろいろ興味深い機能を持っている。
しかし、Asteriaには二重のチャレンジが待っている。それは、
いや、ホント。もう、死屍累々。
是非ともAsteriaには，この厚い壁を乗り越えて成功していただきたいものだ。 不吉な物言いをして申し訳ない。ほんとに期待してますから。
にいるのだが、実際は内職で原稿を書いている。
やっぱ浮動小数点数なんてテーマを選ぶんじゃなかったなあ、
と公開後悔することしきり。なんか、さんざん苦労して書いたあげく
読者から「間違ってます」なんて指摘を受けるんじゃないかと。
一番苦労するのは、誤差の実例で、 教科書的な例題だとfloatを使って誤差を出しているんだけど、 RubyのFloatは内部的にはdoubleを使っているので
と悩ましい限りだ。
ま、良い例題が見つかってしまえば後は楽ってのは原稿書きの常だけど。 で、いつもうまくいっているわけではないというのが、悩ましい*1。
*1 「いつもうまくいっているわけではない」が「いつもうまくいっていない」か「いつもうまくいっている、というわけではない」のいずれであるかが大問題なのだが....聞かないで。
localeの問題で自前で実装を準備したstrtod(3)だが*1、どうも精度が悪いらしい。プラットフォームによっては有効数字が16桁出ないでmake testでエラーが出るようだ。本来は10進18桁近くあるはずなのにな。
試してみると、その辺に転がっているフリーのstrtod(3)実装は軒並み精度がその程度しかない。見るとPythonは内部でシステムのatod(3)を使っている。Perlは自前みたいだけど、あいかわらずソースが読めない(Perlの場合は、VMSなどIEEE754でないシステムにも対応していてifdefが多いせいでもある)。
で、結局、数値を下９桁とそれ以上とに分割し、それらを独立に計算した後、 最後に加算することで精度を確保した。加算で発生した誤差が拡大するから、 加算→乗算、ではなく、乗算→加算の順序で計算しなければならないのだった。
付け焼き刃だが、勉強になった。
*1 localeによっては小数点がカンマだったりするので
体調が悪いので早く休もう、と思っていたのに、寝たのは3時くらいだった。 どうしてこう一人では生活が管理できないのか。
Apache LicenseとGPLの非互換性なんてのは、別に思想の違いや対立があるわけでなく、 たんなる(法律)技術上の問題だったわけだから、これが解決するというのは非常に 望ましいことだと思う。
コミュニティの原動力は「好き」とか「楽しい」であることの再確認。
それはそうと、コミュニティごとになんとなく性格が違うのが面白い。 まあ、(日本での)Rubyのようなコミュニティのように「言語好きが集まりやすい」というのは 理解しやすいが、DebianとGentooとUbuntuの性格の違いはなにによって決定されるのだろうか。
JSR 292に関して、JVM上の各種動的言語の実装に関して。
単に一言で「動的言語」と呼んでもそれぞれ事情が違うのが興味深い。 しかし、考えるにJVMの都合なんかまったく考えてないRubyの仕様が一番凶悪だな。
「XMLは人間が読むものではない」、「DSLの台頭によって(Java界における)XMLの地位は下がりつづけている」という話。
ビルドツールとしてMavenの変わりにBuilderやSCons、 コンフィギュアファイルとしてJava Configuration, JRuby, Groovyなどが使われ始めている。
最後にSICPからの引用。
Programs must be written for people to read, and only incidentally for machines to execute.
ふたつのRuby - Erlangブリッジ。
前者(Rebar)の方がシンプルだが、実際に使う時には後者(Erlectricity)の方が可能性が高そうだ。 いずれにしてもまだproof-of-conceptレベルだけど。
こうやって、各種ツールを組み合わせて、性能や生産性を実現する試みが 次々と現れる様は、未来への可能性を感じさせる。