（注意） この記事は怒髪体で書かれています。 通常の私の記事とはマイナス 3 時間ほどの方向のズレがありますので、 その点をご承知おきの上でお読みください。
ご承知のように、私はメエルマガヂンなるものを発行している。その最近の配信日が 10 月の 21 日であった。
ところが、配信したところ、 次のようなエラーメールが私あてに返ってきた。 プロバイダ名は伏せるが、中小の某無料プロバイダからである。 （念のため言っておくが、 これを伏せるのはそのプロバイダの名誉のためではない。 私が不当な圧力から身を守るためである。）
From: <support@xxxxxxxx.ne.jp>
To: delmonta@ht.sakura.ne.jp
Subject: 【xxxxxxxx管理メール】
メールを受け取ることが出来ませんでした。
【このメールはxxxxxxxxシステムから自動的に送信されています】
xxxxxxxxではメールボックスに容量制限があります。
あなた様がメールを送ったxxxxxxxxユーザーのメールボックスが制限値に達してお
り、お送りになったメールを受け取ることが出来ませんでした。
http://www.xxxxxxxx.ne.jp/
support@xxxxxxxx.ne.jp
---------------------------------------------------------------
From: mag2 ID 0000013484 <mag2from@tegami.com>
To: xxxxx@xxx.xxxxxxxx.ne.jp
Subject: =?iso-2022-jp?B?W0VtYWNzGyRCInYbKEIgTm8uIDI0XSAbJEI6RzZhJE4bKEIgRW0=?=
=?iso-2022-jp?B?YWNzIBskQiRIGyhCIFdubiAbJEIkchsoQg==?=
=?iso-2022-jp?B?GyRCJGEkMCRrPXQhOSROTGRCaiFaQTBKVCFbGyhC?=
============================================== 2002.10.21 発行 =========
極私的 Emacs カスタマイズ紹介マガヂン
Emacs をわたし色に染めて♪
------------------------------------------------------------------------
（以下略; 配信したメールが途中までで切られている）
が、これはおかしい。配信されたメールには、
From: mag2 ID 0000013484と書いてあるのだから、こういうエラーメールは<mag2from@tegami.com>
Reply-To:delmonta@ht.sakura.ne.jp
Errors-To:mag2from@rabbit.tegami.com
mag2from@rabbit.tegami.com に行ってもらわなければ困る。
今回はまぐまぐのメールマガジンだからよかったようなものの、Reply-to:
を投稿用アドレスに設定している世の大半のメーリングリストでは、
こんな馬鹿なことをされてはピンポンになってシステムが麻痺してしまう。
そこで私は、親切心で、 次のような内容のメールを上記のサポートアドレスあてに送った。 私なら親切心を出すが、某 ML の管理人なら即座に問題のユーザーを除名してもおかしくない事態である。
3 日が経過した。ここで、「このたびは大変失礼した。 設定を修正したので今は大丈夫なはずだ。」 という返事が返ってくれば一件落着である。 そういう返事が来るまで気長に待つつもりでした。
ところが、そのサポートはナメたマネをしてくれた。 いわく、
delmonta@ht.sakura.ne.jp
以外のアドレスを設定していただきたい
そこで、
その結果はこうである。さすがに 24 時間とせずに返事が返ってきたが、 その内容は
その程度の技術レベルのサポートなら混み合うのも当然だろう。 さらに、平日昼間に電話しろとは、 まったくもって客をナメているとしか言いようがない。 サービス業としての自覚がゼロである。
そこで脊髄反射で「早くそれを言え、週明けに電話する」 と返信してしまったのだが、平日の貴重な時間をこんな阿呆との応対に浪費されるのは癪なので、改めてこういうメールを書いた。 26 日の未明のことである。
さすがに応対だけは早く、週明けの月曜日の午前中には返信が返ってきた。そうやって、 脳味噌まで筋肉でできている体育会根性 （と称しては本物の体育会に失礼だが） だけでいままで営業してきたのだろう。いわく、
…もうアホかと、バカかと（以下、10 行くらい略）。 要点は最初のメールにすべて書いてある。 にもかかわらずこのていたらくである。これ以上、話を続けるのは、 誰がどう考えても時間の無駄でしかない。
そこで、メールマガジン配布元のまぐまぐさんに一部始終を報告した。 すると、…あっさり解決した。 以前からこのプロバイダのこの問題は把握していて、まぐまぐさんが手を変え品を変え説得しても埒があかなかったとのことである。
そもそも元のエラーメールをもういちど読み返してみると、 親切心のつもりで日本語で返事を返して、 しかもヘッダを思いっきり省略しているくせに、 Subject: の B エンコードをデコードできていない。そんな、 おつむの足りない連中をまともに相手にした私が馬鹿だった。
知人のサイトだが、
http://www.usata.org/diary/Sep2002-2.shtml#20c
に Netscsape 4.78 でアクセスすると、
http://www.sodan.ecc.u-tokyo.ac.jp/~usata/diary/Sep2002-2.shtml#20c
には飛ばされずに、Sep2002-2.shtml のトップに来てしまう。
この usata.org というドメインは ZoneEdit.com でホスティングされている。
自分も ZoneEdit.com のユーザーである
（
To:support@zoneedit.comDear Sirs/Madams:
I am an user of your WebForward feature and have configured the address
be forwarded to<http:// delmonta. dennougedougakkai- ndd. org/> .<http:// www. ht. sakura. ne. jp/ ~delmonta/> Here I found an odd behavior of WebForward. When I enter the URL
to my browsers (on Windows 98, both Netscape 4.78 and IE 5.01SP2), then the address is redirected to<http:// delmonta. dennougedougakkai- ndd. org/ tagebuecher/ otakukultur. html #020504> and the trailing<http:// www. ht. sakura. ne. jp/ ~delmonta/ tagebuecher/ otakukultur. html> '#020504'got lost.This phenomenon makes my Netscape show the very top of the page, not the expected part, although IE shows the right part in spite of the fact that IE does not show
'#020504'on its URL bar.Is this the feature of WebForward, or a bug?
Sincerely,
ところが、返ってきた答えはこうであった。いわく、手元の Netscsape 7.0 では（そらちの IE と同様に）正常に見られたので、 ブラウザ依存の問題ではなかろうか、と。
けっきょく調べてみたところ、こういう結論に落ち着いた：
To:support@zoneedit.comDear Sirs/Madams:
Thank you for your very quick response.
（引用略）
I have examined a little more, and have concluded that it should certainly be a browser issue, i.e. Netscape 4.x's fault. Though I have not yet tested with newer version of Netscape / Mozilla, Lynx (a text-only browser) also redirects me to the correct section.
Here is the detail:
When a browser (any one) received a URL above from the user, the browser sends a request to the server (
, i.e.delmonta. dennougedougedougakkai- ndd. org 216. or40. 201. 216 209. ) as81. 71. 83 'GET, without/tagebuecher/ 'otakukultur. html '#020504'.As a consequence, the server points to the browser that it see
, without'http:// www. ht. sakura. ne. jp/ ~delmonta/ otakukultur. html' '#020504'.Then, IE, Netscape 7, or Lynx remember that the original URL contains the trailing
'#020504'and show the correct section, but Netscape 4.78 completely forgets the'#020504'and shows the top of the page. This was the whole story.
また Netscape 4.x の問題か……憂鬱である。
私はふだん、東大総合図書館 1 階の「メディアプラザ I」 というところで原稿書きをしている。2 階・3 階の「メディアプラザ II」 「メディアプラザ III」に置いてあるのは ECCS の端末なので卒業生は使えないのだが、1 階は、 学外にあるデータベースの閲覧目的という名目で、 入館者（＝学生全員＋卒業生の希望者）が、 何の手続きもなく自由にインターネットを使えるので （これは本当は目的外使用なのだが、実際は私を含め、 私用で使っている人が圧倒的に多い）、重宝しているのである。
ここのデスク環境は自宅と比べものにならないほど快適である。 （そもそも、自宅にデスクなる高級品は存在しない[記事 1、記事 2]。自宅のスペースの狭さを考えて、 机は置かずに卓袱台ひとつで全てをこなしているのであるが、 さすがに最近、それでは限界を感じてきた …… お金と精神的余裕があったら広いところに引っ越したい。） それで原稿書きなどに重宝していたのだが、 一昨日からネットワークの利用は当分停止とのことで、閑散としている。
その場所の掲示によると、この端末を使った掲示板荒らしが出たらしい。 「以前にも発生していて、これが 2 度目だから」とか。 まったく困ったものである。
(後日注) 9/17 からメディアプラザ I の利用は再開された が、 USB 接続のハードウェアキーが必要になっている。 キーの貸し出しは平日昼間に限るとのこと…これではメディアプラザ I 本来の目的の「学内ユーザー限定の学術データベースへのアクセス」 も土休日にはできない。困ったものである。というわけで今後は、 新しくできた駒場図書館を使うことになりそうである（こちらはキーなしでいつでも使えるが、 特定のホスト以外にはアクセスできない）。
何度かネットニュースでも話題になる、GIF ファイルがらみの特許問題。 GIF ファイルで使われているデータ圧縮技術（LZW 法）は Unisys 社が特許を持っているので、GIF ファイルを扱おうとすると、 扱い方によっては Unisys への特許料支払いが必要になるのである。
99 年頃から Unisys がこの問題で強硬姿勢を明確にしたため、 その時期には、GIF ファイルを扱うフリーソフトが相次いで公開を中止するという事態になった （その後、「シロ」であることが分かって公開を再開したものもあるが、 面倒な問題と関わり合うことを嫌ってそのまま公開をやめたものもある）。
しかし、そもそもこの特許の問題に関して、 いろいろな情報や法解釈が錯綜しているのでここでまとめておく。
（注）この文書は可能な限り正確であることを期していますが、 筆者はその正確性を一切担保しません。不審な点がある場合は、 ここに書いてある情報を鵜呑みにせずに、 信頼できる弁護士・弁理士等に相談してください。
読者の中には、自分はグラフィックエディタで GIF ファイルを作って web page に置いているが、自分が Unisys から訴えられることはないか、 と心配されている方もいらっしゃるであろう。
しかし、結論からいえば、その心配はない。使っているグラフィックエディタの作者が特許料をきちんと払っているか、 あるいは特許に抵触しない「抜け道」を使っていれば、何も問題ない。もちろん、そのグラフィックエディタが特許に抵触する方法で GIF ファイルを作っており、しかも特許料を支払っていないという場合は、 かわりに利用者が支払わされる危険性はある（本来、 特許料はグラフィックエディタの製品代金に上乗せされるべきものだから）。
なお、そのグラフィックエディタがフリーソフトであっても特許料の支払いは免除されないらしい（情報源: 「GIF Info」…ここには GIF の仕様書の和訳もあるので、 プログラマ必携）ので、フリーソフトのグラフィックエディタは、 きちんと特許料を支払わずに特許に抵触している可能性がある。 従って、GIF ファイルを書き出せるグラフィックエディタを選ぶ際は、 フリーソフトのものは避けるほうが無難かもしれない。
なお、既存のグラフィックエディタを使うのではなく、自分の CGI が GIF ファイルを動的に生成するという場合は、 注意が必要である。その場合は以下の文章をよく読んでほしい。
ちなみに、著名なフリーソフト The GIMP の Windows 版 では、GIF 関係のモジュールは本体とは分離して、 フィンランドのサーバー（フィンランドでは LZW 法に特許が成立していないということであろう）で配布している。 特許が成立している国（日本を含む）で使う分にはユーザーが自ら Unisys と契約せよ、という態度である。しかし、それ以外のフリーのグラフィックエディタで、 そういう配慮を見せているものは見たことがないので、 もしあったら 教えていただきたい。
日本の特許法では、個人的な目的での使用には特許権が及ばない。 特許法の条文には「業として」という文言が頻出するが、これは、 個人や家庭内などの限られた範囲での使用を除外する意図であるとの解釈が通例である。
ただし、他人のために反復・継続して実施すれば、 たとえ非営利目的といえども特許の侵害になりうるので注意が必要である。 また、ソフトウェアを使用ではなく配布する行為も特許権の保護対象なので、 特許を使用しているソフトウェアを「フリーソフトウェア集」や、 「OS のディストリビューションの一部」などの形で配布する場合 （特に有償配布の場合）は「業として」に明らかに該当し、特許侵害である。
なお、日本の特許法にはこのような規定があるが、 諸外国では必ずしもそうとは限らない （実際、米国の特許法にはそういう規定はないそうである）ので、 この点にも注意が必要である。
さて、この LZW 特許問題について最初に知っておく必要があるのは、 特許の範囲は GIF ファイルのデータ形式ではなく、 画像データの圧縮アルゴリズム、LZW 法であるということである。
この点からすぐに分かることは、 GIF ファイルを扱う場合であっても、 圧縮されている部分に触らなければ特許には抵触しないということである。たとえば、
特許の対象が GIF ファイルフォーマットではなく
LZW アルゴリズムであるということは、当然、GIF
以外のファイルでも LZW を使っていれば同様の問題が生ずるということである。具体的には、PostScript ファイル
（.ps）、PDF ファイル（.pdf）、
TIFF 画像ファイル（.tif）、商用 Unix の
compress コマンドで圧縮されたファイル（.Z）
などが同様の問題を抱えている。
逆に、当然のことながら、画像データの圧縮作業を行う場合、つまり、 画像本体のデータを GIF ファイルに書き出す場合は、基本的に 「クロ」と考えた方がよい。ただしもちろん、上述のように、 GIF ファイルを作る場合であっても、圧縮されていない部分 （ヘッダ）を改竄するだけの作業なら「シロ」である。
(02.07.04) 圧縮を行う場合でも特許に触れない方法があるという主張をするサイトを発見した。ただし、この主張の妥当性を筆者は担保しないので、 信用するかどうかは自己責任でお願いしたい。
ただし、GIF ファイルを書き出す場合であっても、抜け道はある。 画像本体の圧縮できる部分をあえて無圧縮にするのである。 そうすれば、LZW 圧縮を使っていないので特許には抵触せずに済み、 しかも、GIF ファイルを扱えるグラフィックソフトやブラウザなどで、 LZW 圧縮のかかった GIF ファイルと全く同じように扱うことができる。 GNU の「なぜ GIF はだめなのか」では、こういった無圧縮の GIF ファイルを 「擬似 GIF」と呼んでいる。
このような無圧縮 GIF ファイルを自分のプログラムで生成するためのライブラリとして、libungif というものがある。また、以前は gd というライブラリも無圧縮の （正確にいうと、特許に抵触しない圧縮法を使った） GIF ファイルの生成をサポートしていたが、 現在はサポートを中断してしまっている。
(02.06.09 追記) 実際にプログラムを書く際には、 GIF 以外のフォーマットでファイルを書き出し、その後に ImageMagick、UcGIF、 ppmtogif-noLZW などで無圧縮 GIF に変換するのが手っ取り早い。
さて、無圧縮ではサイズが大きくなるではないかと思われるかもしれないが、CGI で使用する場合は問題ない。無圧縮の画像データを
gzip で圧縮し、それを HTTP で送る際にレスポンスヘッダに
Content-Encoding: gzip
をつけてやれば、圧縮された状態でデータが転送され、
ブラウザが自動的に展開してくれるので、
トラフィックも大きくならずに済む。
むしろ、圧縮のかかった GIF よりもサイズは小さくなる。
もっとも、CGI で生成するような小さな GIF ファイルなら、
圧縮しなくてもサイズはたかがしれているのだが。
解釈が分かれているのは、圧縮された画像データを伸長する場合、 つまり、GIF 画像のビュワーを作る場合や、 既存の GIF 画像の画像本体部分を加工するソフトを作る場合である。 この場合、LZW 圧縮された GIF ファイルも扱う必要が出てくるので、 必然的に LZW 伸長プログラムを組み込むことになる。
これについて、GNU（リンク先は上記参照）は、
GIF の展開は話が別です。Unisys と IBM の特許は LZW フォーマットを展開するだけで圧縮はできないプログラムには適用されないように書かれています。そこで私たちは GIF ファイルを表示する機能を GNU ソフトウェアに組み込めますし、 今後もそうできるでしょう。と書いて、問題なしという解釈を示している。実際、GNU の手による
gzip には、商用 Unix の compress コマンドで
LZW 圧縮されたデータを解凍する機能がついているし、
これは GNU の手によるものではないが、PostScript や PDF を表示するための
Ghostscript でも、LZW 圧縮が使われた文書を閲覧することができる。
以前、ネットニュース（fj.comp.image）で話題になったが、
この件に関して、米国特許ではそれは当てはまるが、日本特許
（2610084）は名称が
「データ伸長方法および装置ならびにデータ圧縮伸長方法および装置」
となっていることから、
伸長だけでも特許に抵触するのではないかという懸念が示されたが、
どうやら米国特許も同様の名称・内容なので、
米国で大丈夫ならば日本でも大丈夫であると思われる。
なお、この件を詳しく知りたい場合は、Google Groups あたりでこの特許の名称で検索すると一発で出てくる。
しかし、どうやら Unisys はこの見解をとっていないようで、 実際のところはどこかで問題が起こって裁判になってみないと分からないというのが大方の見方のようである。 Unisys 本社のページには各国で取得した特許の番号が書いてあり、 その番号をキーに米国特許庁や日本の特許庁のページで検索すれば特許の本文が参照できるので、 正確なところはここで確認されたし。 （ちなみに、Unisys 米国本社の日本語によるページや、日本法人のページもあるが、 このへんは役に立たない。）
なお、私自身の見解は次のとおりである:
gzip や Ghostscript
などに LZW 伸長機能があることを長年放置してきた
（たぶん、知らなかったという言い訳は通らない）ので、
これが特許権の放棄と見なしうるからである。
出典: 『東京新聞』本日付朝刊社会面Y2K、その後の要注意日付として次の日付があげられている。
1. は当然、「1900 年は平年だが、2000 年は閏年」という規則によって起こるものである。ちなみに、「99（＝1999）年の次は 100 年である。100 年という表記は 2 桁表示ではないと思われる。 したがって、西暦 100 年である」と判断された場合、やはりこの年も （当時にグレゴリオ暦があったとみなせば）平年である。ちなみに、 ある機械が「99 年の次」の年をどう扱っているかは、曜日を見ればわかる。
2.、3. はおいといて、4. へ。2025/01/01 というのは、 いまだに年データを「昭和」で記録している（つまり今年は昭和 75 年というわけだ）ソフトがあって、 それが昭和 100 年でオーバーフローするという問題。 2038/01/19 は、UNIX などでの時間の内部表現に使われている 「1970/01/01 00:00 GMT からの通算秒数（ただし閏秒は考慮しない）」が、 この日の 03:14:08 GMT に 231 を超えるため。
5. はいっていることがよくわからないのだが、たとえば「99/1/1」 「99/12/31」という形式の文字列でデータを記録しているソフトの場合、 「100/10/10」で想定字数をオーバーするのでは、ということらしい。 2000/10/09 まではたまたま 8 文字以内におさまっていた、ということで。
☆
さて、ここからが本題。ここに書かれていない要注意日付を挙げる。 ずばり、
これらは、「2 桁表記の年号が 50（または 70、80）未満なら 2000 年代、 それ以上なら 1900 年代とみなす」という安直な解法をとったツケが回ってくる時期である。
50 を境界にする方法は、たとえば Lotus 1-2-3 が採用している （米国でこの方法が特許になっているとの未確認情報あり）。
30 はたとえば手元の Windows 98 のデフォルト値（変更可能）である。 20 にしているソフトもあると思われる。
70 は、UNIX 流の通算秒数表現を使っているマシンで、 「1969 年以前は表現不能なので、1970〜2069 としてしまえ」 という安直解が出回っている可能性がある。
80 は MS-DOS、Windows の FAT の問題。 FAT ファイルシステムのディレクトリエントリでは年号から 1980 をひいた値を記録しているので、 私が以前に FAT ファイルシステムをいじるツールを作ったときには、 この値を境界にして「1980〜2079」というコードを書いたことがある。 なお、DOS では年の部分は 7 ビットで記録されるので、2107 年までが限界。
（後日補足）このほかに、「2001 年 9 月 9 日」があるとの指摘があった。
☆
以下おまけ。今までに問題になった日付。
前者は、GPS が送ってくる日付データが「1980/01/06 (Sun) から始まる週を 0 番として、何週目か」という形をしているので、 これが 1024 に達してオーバーフローする問題。 私はこれこそ恐怖の大王の正体か （つまり、GPS に頼っている航空機が墜ちるとか、 某民主主義人民共和国の自称人工衛星がソウルに落ちるとか） と考えていたのだが、その予想は無事、外れてくれた。
後者は、語呂がいいという理由で 「日付欄に 99/09/09 が書いてあったらそこでデータ打ち切り」 という意味になっている場合。それなら、ありえない日付（09/31 とか） を使っておけば少しはマシ…とはいかないか。 どっちみち 10 月以降の日付を含んだデータをソートすると変になる。 13/01 を使おうにもマークシート（当時はパンチカード？） の欄が 12 月までしか用意されていないということも多いだろうし。