_ Wordむかつく (20:17)

くそむかつく。仕様書書きに、普段は絶対に（閲覧用にしか）使わないWordで文章を書いたら、もう数ヶ月安定して動いていた会社マシンがフリーズしやがった。しかも2回も。どうもWordで作っている文書の、ある特定の部分を編集しようとすると、マシンが完黙するらしい。再現性がある。普段どんなに重い処理をやらせてもフリーズしないマシンが、たかだか文書作成で落ちるんですか。ああむかつく。なんで世の中の標準文書フォーマットが、こんなクソみたいなソフトに依存しているんだろう。

_ 家サーバーが死んだ (20:17)

うわっと、久しぶりに家のブレーカーが落ちて、家サーバーが死んでしまったぜ。やっぱUPSつけなきゃだめだなー。あとディスクも二重化しておかないと。

_ だいぶできてきた (13:50)

wikilogへの移行準備を始めて一週間くらいか。実作業にかかってからはまだ3日くらいだけど。だいぶ形が出来てきた。通常のコンテンツ表示機能、コメント表示機能、コンテンツ編集機能、コメント投稿機能、RSS表示あたりまでは実装。あとはTrackBack回りを入れればだいたい完成か。

Refererの扱いについては、tDiaryあたりで議論が起こったり（http://www.tdiary.org/archive/devel/msg00801.html）しているみたいだし、しばらく様子を見ておこう。対攻撃ということを考えるんだったら、コメントもTrackBackもRefererもみんな、管理者のチェックを通ったもののみ表示するようにすればいいんだけど、そこまで管理コストを引き上げるくらいだったら、そんな機能はなくていいってことになりかねないしなー。

_ テンプレート互換が著作権法に触れる可能性 (14:36)

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

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

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

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

_ テンプレート仕様という表現に、複数の意味が混ざっているな (17:56)

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

_ 対応方法が思いつかないspam

そのページに書かれている文章から抜き取ったテキストの最後に1行（宣伝）URLを追加したツッコミspamがさっき来たんだけど、これって機械的な識別がえらく難しそうだな。日本語利用チェックとか、URL文字列割合チェックとか、その手の対応はすべて無効で、ほぼURL・ドメインベースのblacklistで対応するしか手はないんじゃなかろうか。

_ タグ入力支援機能の改善

リニューアル版1470.netのタグ入力支援機能を、使いにくいまま放置している。この辺は結局Ajaxを使わなければならず*1、Ajaxを使う場合はちゃんと設計してから作らないとぐだぐだになりがち*2なんで、隙間でちょっと機能追加するといった感じで作れない。

ひとまずタグ入力支援機能として、どういう機能があれば使いやすいのか自分の中でまとめ切れてないんで、具体的にどういう支援機能があればうれしいみたいなご意見募集中です。

_ データフォーマットはJSONでもいいでしょうか？

メモのバックアップ向けのAPIを作りかけている。インターフェースは基本RESTで行こうと思っているんだけど、データフォーマットをどうしようか悩み中。XMLが無難ではあるんだけど、やっぱりうざいなー。特にTSVとかCSVでも十分に表現できるようなデータを、わざわざXMLにするのがだるい。ただ、そういうときにTSVとかCSVとか使うってのも、扱うデータフォーマットの統一感とか、データが途中でぶち切れたとき対策とかの点でいまいちだ。で、今のところJSONにしちゃおうと思っていたりするんだけど、それだと困るって人はいますかねー。まあ最悪クライアント側のサンプル実装もこっちで作れば問題ないか。