トップ «前の日記(2005-08-24) 最新 次の日記(2005-08-26)» 編集

2002|01|02|03|04|05|06|07|08|11|12|
2003|01|02|03|04|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|02|03|04|07|

2005-08-25 [長年日記]

_ 今日はスポクラお休み (13:28)

つばを飲んでも喉が痛い状態になり、さらにちょっと寝違えて(あるいは昨日のシャドーピッチングのせいで?)持病の背筋痛が出かかっているんで、今日はスポクラはパス。台風が近づいていて雨の中スポクラに行くのもだるかったし。

Tags: 日常

_ 今日は (13:32)

JR東日本:列車運行情報 関東エリアをながめながら、やばそうだったら早めに帰らないとな。

Tags: 台風 日常

_ 状況でToDoリストを整理する (13:33)

時間軸での分類とは別に、状況によってもリストを整理することができる。ToDoリストにまとめられた各項目には、特定の状況でしか実行できないものが存在するはずだ。たとえば、「寝室の収納の掃除をする」のような項目は、家にいるときにしか実行できないだろう。また、「営業のAさんと打ち合わせ」のような項目は、会社にいるときにしか実行できない。

そのような項目は、その実行可能な「状況」という軸で整理してしまう。たとえば、現在「家にいる」という状況で何らかの仕事をこなそうと考えた場合には、「家にいる」という状況のリストを見れば、今実行可能な項目が見つかるだろう。逆にその状況では「会社にいる」という状況のリストを見る必要はない。

というのが「状況」という軸での整理なのだが、本家GTD本ではこの「状況」ベースの整理の具体的な方法は、いまひとつ明快に書かれていなかった気がする。その理由としてはおそらく以下の2点が挙げられるだろう。

まず、この「状況」という分類方法は人によって大きく分け方が異なる。会社勤めしている人しか「会社にいる」という状況はないだろうし、また複数のオフィスを持っている人ならば、単純に「会社にいる」とひとくくりで表現することはできない。そのため、「状況」という軸における分類では、誰にとっても明快なサンプルが出せないというのが一点。

もう一点は、本家GTDでは基本的に通常の紙+ファイリングベースでの分類を前提と(というか、そのようなやり方でも実現できるように)している。そういう物理的な分類方法では、先に書いたような時間軸での分類という明快なやり方を先に採用してしまっている関係上、それとは異なる「状況」という軸を使った分類を、どう実現するかが難しい。物理的な紙とファイルでは、一つの紙は一つのファイルにしか挟めないのだ。

ちなみに具体的な分類例として、私は以前「家にいる」「会社にいる」「出かけている」という三つの状況の分類を試してみた。それはそれで有用な分類方法ではあったのだが、時間軸の分類のような明快さはなく、気持ちよく整理していくという気分とはほど遠かった。この「状況」を切り口に分類するというアプローチ自体は悪くないと思うのだが、整理の明快さを実現するためには、もう一工夫が必要なように思う。

すでに時間軸で分類されたものに対しての「2軸目の分類の表現が難しい」という点に関しては、コンピュータで分類する限りは、リンクによってn軸の関係性は簡単に表現できるので、GTDに向いたn軸の分類が使いやすいプログラムを用意すればそれで解決できるだろう。

自分なりにGTD的なやり方をコンピュータ上で実現するにあたっては、この「状況」という分類方法の実装は検討するべき点が多いが、逆に言うとこの部分で新しいうまいやり方を思いつけば、GTD的なやり方の生産性はさらに高くなりそうでもある。

Tags: GTD

_ 客観的な判定基準 (13:51)

自分の方の話は、(分かってはいたけど)その不毛さにちょっと疲れてきたので、GTDネタとかで脳みそがリフレッシュされるまで中断することにして、highbiscusさんとτさんの間でやりとりしている、井上雅夫さんの手による「米国著作権法102条(b)項の解説文」の読解について、取り上げてみます。

ポイントは、元の井上さんの文章の、

プログラムは何らかの機能を有しているのであり、ソースコードあるいはオブジェクトコードの表現の複製、翻案を行えば、それに伴って、その機能もコピーされる

における「ソースコードあるいはオブジェクトコードの表現」の解釈でしょう。

τさんはblog@なゆきすと : 「プログラムの表現」とは何かにおいて、

井上氏の解説内で使われている「プログラムの表現」という言葉は、「メディアの上に表現されているプログラムコードそのもの」を指すと考えるのが妥当であろう。

というように、その「ソースコードあるいはオブジェクトコードの表現」とは、ソースコードあるいはコンパイルされたバイナリコード自体を指す(その実行された画面表示などは含めない)と解釈しています。もちろん私もそう解釈します。著作権に関する文章における「表現」という言葉の意味を理解していれば、そう読むのが当たり前です。

一方highbiscusさんは、単に102条bの表現侵害規制の判例を語ってるだけでしょ : highbiscus -北国tvによれば、

プログラムとはなんらかの機能を有しているのはあたりまえであるが、ソースや表示をコピーして、これは機能(アイディア)のコピーであるからいいのだ!って論理は間違いで、それは著作権侵害です、と述べている。

のように、コンパイルされたバイナリコード自体だけではなく、それを実行した際の表示なども含めて、「ソースコードあるいはオブジェクトコードの表現」であると解釈しています。この文章は、Whelan判決における「アイディアのコピーも著作権侵害だ」を表現している文章だ、という主張らしいです。

さてどちらが正しいのでしょう。この件については、客観的な判断基準が存在するので、いつもの不毛な言い合いを続ける必要がありません。実際に元の文章を書いた人に、どちらが正しいのかを聞いてみればいいわけですから。

そこで、「プログラム関連米国判決集ホームページ」の井上雅夫さんに、米国著作権法102条(b)項の注釈文における「ソースコードあるいはオブジェクトコードの表現」の解釈についてメールで尋ねたところ、それは単に「ソースコードとそれをコンパイルしたバイナリコード自体」を意味しており、そこにおける「表現」という言葉には「オブジェクトコードを実行した際の表現(画面表示など)」という意味合いまでは持たせていない旨、ご返答をいただきました。

というわけですので、少なくともその注釈文において、井上さんが「オブジェクトコードを実行した際の表現」について語っているわけではないことになります。

※上記2段落の文章は、井上さんにその内容に間違いがないか確認していただいた上で、そのまま*1掲載しています。

こうやっていつも客観的な判断基準があるといいんですけどね。

_ mb_convert_variables (17:00)

今までその存在に気づかず、自前で再帰関数を書いて使っていたよorz...。

Tags: PHP

*1 正確には、最初の「そこで」を付け加え、敬称の「様」を「さん」に変更してある

本日のツッコミ(全12件) [ツッコミを入れる]
_ orzmaru (2005-08-25 14:40)

こんにちは、はじめまして。

オブジェクトコードを実行した際の表現というのは、ソースコード内で

print "hoge";

としたときの"hoge"というソースコード内の文字列(表現)でしょうか。
それともディスプレイ上に表示された"hoge"という文字列でしょうか。細かいことですが、少し気にかかります。

_ ishinao (2005-08-25 14:50)

その言葉はhighbiscusさんの主張するところの、単なるバイナリコード自体を指しているわけではない「オブジェクトコードの表現」という言葉を、紛らわしくないように言い換えたものなので、それが指す正確な意味はhighbiscusさんにしかわかりません。

ただ、highbiscusさんの今までの主張から読み取ると、
*プログラムを実行して得られる画面表示(orzmaruさんの言うところの、ディスプレイに表示された"hoge"という文字列など)
*プログラムを実行した結果、そこから感得できるであろう、そのプログラム独自のアイディア(設計や仕様)
あたりを指しているのではないでしょうか。

_ ishinao (2005-08-25 14:56)

少なくともhighbiscusさんは、「表示」という言葉を使っているので、ソースコードやバイナリコードを構成する文字列の一部を指しているわけではないと思います。

_ ishinao (2005-08-25 15:06)

ああ、バイナリコードの場合は文字列ではなくバイト(or ビット)列か。あるいはそれをディスアセンブルしたニーモニックコードによる文字列って場合もあるけど。

_ orzmaru (2005-08-25 15:08)

回答ありがとうございました。

私は、はいびすかすさんの解釈は文脈からして「ソースコード内の文字列」と思っていたのですが。
いずれ反論(この場合は言い訳かな?)があるでしょうから、その時に判明するでしょうね。どうも、失礼いたしました。

_ τ (2005-08-25 16:26)

おぉぉっ。私もいい加減、弁護士の方にメールを書こうかと思っていたところでした。
# 彼に言葉や論理でどうこう言うのは最早無駄という気がしています……

_ ishinao (2005-08-25 17:22)

>orzmaruさん

井上さんにはhighbiscusさんの該当のページを読んでいただいているので、私のまとめた文章表現に問題があったとしても、根本的なところは変わらないんですけどね。

>τさん

こういうのに首を突っ込んでくれるような法曹関係者の方がいればいいんですけどね。専門家の具体的な(この事例における)解釈を聞いてみたいし。

_ hal* (2005-08-26 17:07)

ぉぉ、すばらしい。井上さんも良い方ですね。

_ はいびすかす (2005-08-27 17:53)

そのその部分の文章に限って言えば、オブジェクトコード(あくまでコード)の「print "hoge"; 」って文字列って意味での表現でしょうね

ただ、コードの表現の模倣のみで、T氏の言うようなコードが違えば機能の模倣は侵害にあたらずは、
近年の裁判でも機能(表現にあたりうるようなもの)の模倣を争ってるものばかりですし、井上さんが言うわけないですから、
コードの表現(0101ってな意味での)の模倣と、機能上の表現と、「表現」という表記に両方の場合が文中にあるのではないでしょうか。

「オブジェクトコード」における表現には、厳密には2種類あります。「010101」といった意味での「コード」の記述。そして実際の機能の表現。

ちょっと俺もメールで聞いてみまーす。

_ ishinao (2005-08-27 22:13)

>highbiscusさん

オブジェクトコードに「print "hoge";」という文字列があるんですか?

というのはさておき、井上さんにあまりご迷惑にならない程度でお願いしますね。今回の議論全体には、井上さんは関係ないんですから。

_ hal* (2005-08-27 23:06)

>highbiscusさん
ぇっ(汗)。これ以上何が疑問なんですか?その前に、平成15年の吉沢ビジネスマシンズのシェイプ定義に係る記述の判例もちゃんと参考にして下さいね。タウ氏の言うようなコードが違えば機能が同一でも侵害に当たらずとしてある近年の判決なんですから。http://1st.sunnyday.jp/resources/judge/h13wa17306.html#c2s3ss1

_ 界隈 (2005-08-28 12:01)

> 「オブジェクトコード」における表現には、厳密には2種類あります。

ならば、それぞれ別のラベルをつけてください。