んだけど、これって効果があるから流行っているのかなー。

ちなみに逆援助系SPAMってのは、「欲求不満の女性会員（年収1000万円以上と書かれている例が非常に多い）が、あなたを求めています。30万円（って例が非常に多い）出します。連絡ください」みたいなやつね。この系統は文面のパターンも多いし、「どういう狙いでどういう表現を使っている」とかを考えるのが楽しいんで、結構チェックしている。

最近来た中で比較的新しめなのが「株式会社ウーマンフリー」と名乗るやつ。「このメールでURLを記載してしまうと、未承諾広告等の法律に違反してしまいますので、貴方の承諾を頂きたくメール致しました次第でございます。」という文言の効果が知りたいな。こういう表現を使うことによって、従来の形式よりも返信レートが高くなったりするんだろうか？

20日締めの翌月末実効らしいんで、来月末までは使える。解約するサーバーは、一番古いサーバーなぶん、一番機能が詰め込まれていたやつなんで、移行漏れがないようにしないと。ひとまずDNS周りの危険が危ない。主要な機能はだいたい移行しているんで、大して作業は残っていないはずだけど。

ソフトウェアの画面表示も著作物という話。を読んでいて思ったのだが、「画面」と「設計」と「デザイン」という言葉を、恣意的にその適用範囲を変えながら使うのは勘弁して欲しいなー。

• 「画面表示には著作物性がある」
• →「画面表示のデザインには著作物性がある」
• →「画面表示の設計には著作物性がある」

って、なんで「画面表示」が「画面表示の設計」にすり替わっているんだろう？　多分「画面表示」＝「画面の設計」だと思っているんだろうけど、それは「絵画」＝「絵画の構図」とか「小説」＝「小説のあらすじ」みたいなもんで、本来一緒くたにしてはいけないものだよ。

相変わらず、highbiscusさんの「プログラムの著作権」に関する解釈には同意しないんだけど、その件についてはこれ以上すりあわせることはできないだろう。ひとまず対論は十分提示したと思うし、「プログラムの著作権」でググれば関連する情報は見つかるし、まあそれぞれ自分の解釈を堅持するということで。

で、基本的な「プログラムの著作権」の解釈に関しては、全然同意しないんだけど、ソフトウェアの画面表示も著作物という話。で書かれた、「テンプレート互換は著作権法に触れる」という主張には、それなりに理があるとは思う。Webアプリケーション、特にHTMLやらCSSやらを使ったデータおよびそれによって生じる表現に関しては、今のところ判例がほとんどなくグレーゾーンが大きいんで、その辺をつつくと判断が非常に難しくなるからだ。

テンプレート互換というのは、基本的にはデータフォーマットの領域なんで、著作権をたてにデータ互換のツールを排除しようしても、現状のプログラムの著作権に関する主流の解釈からすれば、勝ち目はない。たとえばMicrosoftのOffice文書を読み書きできるツールを作っても著作権法に抵触することはない。もちろんWordで作ったデータファイルは、Word互換のツールで読み込んでも、同じような表示結果が得られる。テンプレート互換で表示結果が似ているから、画面表示の著作権に抵触しているというのならば、上記の例に対して有効な反論をする必要がある。

ただ、HTMLやCSSに関しては、その実用的な表現方法のバリエーションがものすごく少ない。特に洗練された表現をしようとしたときには、その表現は似通ったものになりがちだ。sbとJUGEMの件に目を向けてみると、テンプレート互換にすることによって、HTMLやCSSの表現が類似している部分や、部分的に同一の表現が出てくるだろう。HTMLやCSSの表現の類似は、どこまで著作権法に抵触すると考えるべきだろうか。というのは、おそらく今のところ具体的な判断が行われた事例はないと思う。

HTMLやCSSも、実際に表現として記述されたものには、著作権が発生する。しかし、基本的にHTMLやCSSによる表現というものは、オリジナルに書き下すものというよりは、仕様に準拠した表現や、既存のTIPSを組み合わせた表現となりがちで、そうなってくるとそこに生ずる著作物性というものも、非常に限定されたものになってくるはずだ。

もちろん、デッドコピーおよびそれに類するもの（要は、まるまるコピーしたり、あるいコピーしたものをちょっとだけ書き換えたり）は、サイボウズ−ネオジャパンの判例から考えても、著作権法に抵触すると考えるべきだろう。しかしそのソースを参考に、一般的なTIPSレベルの要素を部分的に借用しながら、新しくHTMLやCSSを作成した場合、それは著作権法に抵触すると考えるべきだろうか？

それが、「著作物の流用」なのか「著作物性を持たない一般的な表現を利用」なのかは、非常に判断が微妙な問題となる。sbとJUGEMに関して言えば、それぞれが出力するHTMLやCSSのレベルでの類似性を取り上げ、それがデッドコピーなのか、それとも仕様に準拠した結果同じような表現になっただけのかを争う、といった形になるだろう。

プログラムの著作権における判例として、「誰が作成してもほぼ同一になるものは、著作権法上の保護の対象から外す」という判断があることや、データ形式という著作権法に抵触しない部分での互換性を求め、その仕様に対応することによって似通ったHTMLおよびCSSが使われることとなった、という状況から、仕様を遵守した結果の（いわゆる創作性のない）表現と見なすことができ、著作権法に触れないという判断が下される可能性が高い*1とは思うが。

というわけで、「テンプレート互換は著作権法に触れる可能性」の問題は、使われているHTMLやCSSに同一の部分が多いような場合においては、判断が難しくなってくる。そのうちそれが問題となる事例も出てくるかもしれない。

そういえば

デフォルトのテンプレートファイル自体に、JUGEMと同一のものを使っていた場合、そのファイル自体はJUGEMの著作物なんで、著作権で保護される対象となるな。その利用については、その著作権者に利用許諾をもらう必要があるだろう。

sb開発者の方がJUGEM開発者の方に利用許諾をもらったってのは、その点についてかもしれない。

でもそれはあくまでも、sbのプログラム全体ではなく、該当のテンプレートファイルのみに関する問題ね。厳密に言えば、テンプレートファイルが著作物性を認められるような内容である必要があるけど、よほど非創作的な内容でない限りは、ふつう認められる。

一つは「{$EntryUrl}は、エントリーのパーマリンクURLを差す」みたいなテンプレートのデータ形式の仕様。

もう一つは、「<span class="EntryUrl">で定義されたHTML要素はspan.EntryUrl {font-size: 90%; color: gray;}というCSSで修飾されて表示される」みたいな、表示に使われるHTMLやCSS定義に関する仕様。

前者は、純粋にデータ形式の問題であって、その利用が著作権法に触れるということはない。一方後者に関しては「HTMLやCSSの表現自体」という要素が絡んでくるので、その部分に関しては著作権法に触れる可能性がある。

判断の分かれ目は、<span class="EntryUrl">やspan.EntryUrl {font-size: 90%; color: gray;}などの定義は、「仕様」の領域にあるのか「表現」の領域にあるのか、なんだろう。

これがデスクトップアプリケーションで、「x:0, y:0, color:blackというデータを受信したら、座標0, 0に黒い色で（文字を）出力する」なんて話ならば、純粋にデータ形式とそれを解釈して実行するプログラムの問題なんだけどな。

通常のデスクトップアプリケーションならば、データの解釈から出力処理までをいろんな書き方ができるけど、WebアプリケーションがHTMLやCSSを使って出力する場合は、HTMLやCSSにする段階で表現方法が限定されてしまうところがあるから、それがプログラム設計・仕様の問題なのか表現の問題なのかが不明確になる。

これは実際に裁判にでもならない限り、きちんとした結論は出しようがない問題だろうな。

ちなみに

ここでいう「HTMLやCSSの表現」というのは、「あるHTMLやCSSをブラウザが解釈した結果表示される画面」ではなくて、「あるHTMLやCSSを記述したコード自体」のことね。プログラムの著作権で守られるのは基本的には*1その記述したソースコード自体であり、結果として出力された内容ではないので。ただWebアプリケーションは、HTMLやCSSという中間コード的なデータを出力しなければならないし、そのHTMLやCSS自体も表現として著作権による保護の対象となりうるところが、ややこしい。あと画面の表現としての著作権に関しても、（サイボウズ−ネオジャパン判例に基づいて）限定的には認められることになるだろうし。

DB_DataObjectでprimary keyを使って行を取得するときに、

$obj->get([primary key value]);

なんて感じでいけるはずなんだけど、MySQL 3.23.58で動いているコードを、MySQL 4.1.7環境に持ってきたら、なぜか動かない（正しいprimary key valueを与えても行がgetできない）。

またMySQL 4.1以降の文字コードの問題にはまっているのかなーと、文字コード絡みの設定をいろいろ変えて試してみたんだけど、ふと、

$obj->get([primary key name], [primary key value]);

に変えてみたら動くようになった。DB_DataObjectがprimary key情報の取得に失敗している？　DB_DataObjectってまだMySQL 4.1系には対応していないんだろうか？

あの、sbていうブログ構築ツールとJUGEMが似ててアーダコーダという、いしなお!ていう人とhighbiscus -北国tvていう人のやり取りを見てて思った。スゲー見づらいっつか、見づらいまで行かないにしても、もっとなんか見易くすれば、こういう論議っつーの？そういうのもわかりやすくなって、いろんな人がハッピーになれるんじゃねーの

トラックバックに完全対応したblogツール同士のやりとりならば、 trackback trace: いしなお! - 一時しのぎの対策 (15:15) , sbライセンス問題 - いかんともしがたいの人編 : highbiscus -北国tv (16:57) - blogmapを使えば、やりとりをツリー構造に展開することができるんですが、あいにくhighbiscusさんが使っているチャンネル北国tv（blosxom）がトラックバックの送受信にしか対応していない（__mode=rssに非対応）ので、こういうツールが使えません。

ちなみにトラックバックにフル対応したツール同士の場合ならば、 trackback trace: [ビジネス] ［R30］環境が無敵のポジショニング軸になる日 - blogmapみたいな感じになります（※[+]マークをクリックすると、トラックバックのやりとりをツリーに展開していきます）。

というわけで、そういうツールはすでに作っているのですが、現状ではインフラが整っていないので、いまいち実用性が低いという状況です。

とコメントに書こうと思ったら、MTでエラーが出たんで、トラックバックにして送ってみる。

あれ、コメントが表示されてる

コメントを投稿したら、sprintfがどうとかいうエラーメッセージが出ていたんだけど。

昔、第三者によるトラックバックというネタを考えたことがあった（今は亡きintersite MLとかに流した気がする）。あるエントリーに関連する、他サイトのエントリーのURL情報を、第三者からでもトラックバックで送れるようにしたらどうだろう、という話だ。

通常第三者が（トラックバックが送られていない）関連エントリーを見つけた場合、コメント欄あたりを使って筆者（や他の読者）に伝えることになる。

その情報を人間が理解するだけならば、コメントだろうがトラックバックだろうがどちらでもかまわないのだが、トラックバックという規格を使うことによって、関連エントリーの情報をメタ情報的に扱いやすくなる（__mode=rssとかを使って機械的に取得できたり）というメリットがある。

ただし、第三者が（他人の記事に関する）トラックバックを送信することには、心理的な抵抗が大きいらしいんで、それが第三者によるトラックバック送信だということが明示できるような仕組みや、第三者がトラックバックを送りやすくする仕掛け（投稿フォームとか）があった方がいい。

というネタをこの記事に関連して今更ながらに思い出した。やっぱりこういう仕組みはあると便利だと思う。トラックバックという規格を関連エントリーを機械的に取り扱う枠組みと考えた上で、トラックバックの__mode=rssによるRSS取得機能をもっと活用していってもいいんじゃないだろうか。

簡単な実装方法としては、

• トラックバックの手動送信フォームをエントリーごとに用意し、トラックバックの標準項目以外に「トラックバックを送信するエントリーはあなたが書いたものですか？」というチェックボックスを用意する
• トラックバックデータを保存する際に「第三者による送信」というフラグを追加し、上記チェックボックスがオンの場合は、そのフラグを立てる
• トラックバック情報を出力する場合、それが第三者による送信であることを明示する（HTMLの場合はそのまま注釈をつければいいけど、RSSの場合はどう表現するのが妥当だろう？）

なんて感じだろうか。

IMAPを使ってGTDを管理できないかと、ちょっと試してみたんだけど、Becky!のインターフェースだといまいち操作に自由度が高くなくて難しいな。でも、IMAPでGTDを管理するというアプローチ自体は悪くなさそう。

そのうち、IMAPベースのグループウェアとか作ろうかと思っていたんだけど、その前段階として、IMAPベースのGTDクライアントでも作ってみればいいのかな。IMAPベースにしておけば、外出先でもmobileimapで各種情報が閲覧できるところが便利だよね。

ちなみにGTDについては、ここを斜め読みした知識しかないし、ひとまずあまりGTDそのものを追求する気はない。単にIMAPをGTD（というか仕事管理）に使う実験。

ひとまず専用のIMAPアカウントを作る。IMAPフォルダとして、

• 今日やる
  • 家で
  • 会社で
  • 外出時
• 暇なときにやる
• いつかやる
• やった
• ごみ
• 資料
• 050721
• 050722
• 050723
• 050724
• ……
• 0508
• 0509
• 0510
• ……

なんて作ってみる。IMAPフォルダの並べ替えは（Becky!では）できないんで、基本的に後から作ったものが後ろに足されていく。必要になったら新しい日付とか月のフォルダも作っていく。GTDの基本に準じるならば、日付は一ヶ月分、月は1年分用意しておくのが妥当か。並べ替えが効かない点をフォローするために、年月日あるいは年月でフォルダを作っている。不要になったら今日以前の日付のフォルダは消していく。FIFO。

続いてアイディアの登録。思いついたアイディアは草稿として作るか（これだと再編集が効く）、もしくは上記アカウント宛のメールとして適当に送っておく。タイトルは、大括弧で大まかなカテゴリーを表現し、それ以降に内容の概略を書く。「[blog]IMAPでGTDの概要を書く」とか。詳しい情報があれば本文に書く。必要な資料があれば添付ファイルとしておく。

通常のメールアカウントのメールをチェックして、何らかのアクションを伴いそうなメールがあったら、適当にタイトルだけ差し替えて、上記アカウントに転送しておく。その段階で具体的なアクションに分割できそうならば、アクション単位でメールを書き、資料として元メールを添付する。

続いてアクションの分類。受信箱や草稿箱、今日の日付に溜まったメールを、内容に応じて、

• 今日やる - 今日やれそうなもの。場所依存のものは場所ごとのサブディレクトリに入れる
• 日付のフォルダ - 特定の日付にやるもの。
• 月のフォルダ - 日付が明確ではないが、だいたいの時期が見えているもの。
• いつかやる - 緊急性がないが、いつかはやった方が良さそうなもの。
• 暇なときやる - 「いつかやる」と似ているけど、気分転換に良さそうなスキマ作業ネタ。
• 資料 - やることじゃないけど、今後やることに関係しそうな資料。
• ごみ - いらない。あるいはいらなくなった資料。そのうち捨てる。

に分類していく。

続いてアクションの消化。まず「今日やる」の中の（現在の）場所依存のものをチェック。すぐにやれるものはやる。すぐにやれないものは、適切なフォルダに移動するか、あるいは次の消化タイミング用に残しておく。すぐやれないもののうち、アクションがおおざっぱすぎるものは、細かいアクションに分解してみる。

続いて場所依存ではないものをチェック。すぐにやれるものを片付け、すぐにやれないものはフォルダ移動もしくは残す。すぐにやれないもののうち、アクションがおおざっぱすぎるものは、細かいアクションに分解してみる。

仕事に飽きてきたら、「暇なときやる」とか「いつかやる」とかを眺めて気分転換をする。また、（今いる場所以外の）場所依存のアクションをやるべきかどうかを考える。必要ならば、その場所に出かける。

一通りのチェックが終わったら、再びメールチェックしたり、新しい仕事を考えたりして、必要ならばアクションを追加するってところに戻り、適当にループする。

外出中なんかはmobileimapを使って、「今日やる」とか「暇なときにやる」をチェックする。やれることがあればやる。また、何かアクションが思いついたら、適当にメールで送っておく。

というやりかたをさっきからやり始めているんだけど、ひとまず数時間やり始めて思ったことは、

• 通常のメールアカウントとは別に、仕事管理用のメールアカウントを用意しておくと、やらなければならないことはそちらに（アクション単位で添付ファイルなどを使って）吐き出してしまえるんで、通常のメールアカウントに中途半端なメールが溜まることがない
• メールは表現力があるし、扱いが手軽だし、データ置き場にも使えるし、なかなか便利。重要度とかメール標準で用意されている機能も、もっと活用できそうだ。
• ただし、メールはというかBecky!は、再編集とかに制限があるんで、ちょっと編集したいときとかも、新しいメールとして書き直したりする必要がある。特に、ある程度大きなアクションをプロジェクトとして扱い、複数のアクションに分割して云々、みたいなことがやりにくい。専用クライアントを作る以外でいい方法はないかな。
• mobileimapで外出先から手軽に閲覧できたり、携帯メール等で手軽にアクションを登録できるのは便利。
• というか、GTDってこんなんでどのくらい再現されているんだろう？　GTD自体をもうちょっと追求してみるべきなのか、それともGTDからネタを借りた独自の仕組みとして洗練させていった方がいいのか、どっちだろう。

なんて感じですよ。

qmail、ezmlm-idx、vpopmail、qmailadmin、clamav、spamassassin、tcpserver、qmail-scanner-queueあたりを全部入れる手順がきれいにならない。どこかのバージョンに固定してしまえばいいんだろうけど、一通り新しいバージョンに追随しようと思うと、たいていどこかで前のやり方のままではうまく動かない部分があったりして、手順が錯綜してはまる。疲れる。