LZW圧縮の復活
結果、轟々たる非難の声が湧き起こり、LZW圧縮はほぼすべてのフリーソフトウェアから閉め出され、サポートが打ち切られた。Unisys社の特許権は2つとも2004年7月に失効したが、その後もLZW圧縮への世間の関心は冷めたままであり、大多数のLinuxユーザにとってLZW圧縮は存在しないも同然である。だが、幸いなことに、復活は難しくない。
問題が大きくなったのは、LZWがGIFイメージの圧縮方式だったからである。BurnAllGIFキャンペーンが始まり、GIFをやめてPNGで置き換えようという運動が広がった。現在、Webブラウザと画像アプリケーションの両方でPNGフォーマットが広くサポートされていることを見れば、キャンペーンは成功だったと言えよう。もともとGIFは弱く、ぎこちないフォーマットだった。今日、その喪失を嘆く人はほとんどいない。
だが、GIFが不要ならLZWも不要ということにはならない。LZWにはほかにも重要な用途がいくつかあって、たとえばTIFFでは、これがデフォルトの圧縮アルゴリズムとして使われている。TIFFとGIFは名前こそ似ているが、中身は大きく違う。TIFFのほうが見映えがよく、頭がよいだけでなく、ロスレス（可逆）圧縮の事実上の標準にもなっている。
TIFFでは、複数のビット深度/カラー空間/エンコーディング方法を扱える。1つのファイルで複数の「ページ」を使用できる。整数データも浮動小数点データも使えるし、その他、さまざまな拡張機能を追加できる。TIFFの仕様画像フォーマットの世界的リーダー（もしくは、通常は善意の独裁者）と自他ともに認めるAdobe社によって管理されていて、TIFFフォーマットに独自機能を付け加えたいユーザは、Adobe社に電子メールを送るだけでそれができる。
こうして、LZW紛争の余波として、TIFF拡張機能の形をとってさまざまな圧縮方式が現れた。Zlib（別名Zip）もそうなら、JPEGもそうである。後者などは逆効果とも言えるほど非生産的な方式に思えるが、まあ、蓼食う虫も好き好きということだろう。
だが、そうした新しい圧縮方式のなかで、TIFFの公式仕様に取り入れられたものは1つもない。TIFF仕様の改訂が2002年以後停滞していること――さらに言えば、TIFF 7.0が1992年から「策定中」であること――が、理由の1つである。当然、TIFF拡張機能のサポートにはむらがあって、不便きわまりない。家で写真アルバムを整理する際にスペースを多少節約したいという程度のことなら、Zip圧縮で十分かもしれない。だが、その写真を印刷用にアップロードするとなれば、どうしてもフォーマットの変換が必要となる。
また、携帯用「メディアドライブ」やファイルから直接印刷するプリンタなど、小型デバイスでサポートされる代替圧縮方式も、なかなか見つからない。さらに、2つのロスレス圧縮方式のうちでは、Zipのほうが計算にともなうオーバーヘッドが大きく、それだけ時間がかかることも大きな問題である。
欠けているピース
LZWは確かに目に触れないが、まったく忘れられているわけでもない。フリーソフトウェアの主だったグラフィックアプリケーションは、GIMP（GUI）にせよImageMagick（コマンドライン）にせよ、LZWで圧縮されたファイルを読むことは常にできた。できないのは書くことだったが、それに必要なフックは内部に残存していたから、LZW圧縮の復活を望むユーザ（反逆者であれ、Unisysに使用料を支払う正式ユーザであれ、公海上のユーザであれ）は、その気になればいつでも復活させることができた。
必要なフックの残存は、もちろん、作者からユーザへの友好的な態度の現れではあったが、GIMP 2.xユーザをジレンマに陥れるものでもあった。たとえば、TIFFファイルの保存ダイアログでは、LZWがオプションではなく自動選択のデフォルトになっていて、ユーザによる設定変更ができない。このため、GIMP 2.xユーザはTIFFファイルを1つ保存するごとに、サポートされている圧縮オプションを手作業で選択しなければならず、これをうっかり忘れると、プログラムが止まり、警告ボックスが続々と現れてエラーメッセージを表示した。
GIMPとImageMagickが、LZWを愛するTIFFファンに対して相変わらずこれをやりつづけているのは、どちらもTIFFフォーマットの読み書きをオープンソースのlibtiffライブラリに依存しているからである。GIMPなどは実に脳天気で、ファイル保存のたびに呼ぶlibtiffが、LZW対応かどうかを忘れている節さえある。
Unisys社への特許料支払いが問題になりはじめたとき、libtiffの開発者は巧妙な方法でこれに対処した。まず、LZW圧縮機能を独自ファイルに移動させ、本来ならLZWルーチンがあるはずの場所に空の「スタブ」ファイルを置いて、ライブラリ3.5.5版を配布し、LZW機能がどうしても必要だというユーザには、別途、ライブラリパッチを用意した。
libtiff 3.7からは再び以前の配布形態に戻り、LZW圧縮機能が本体に含まれている。昨年は、LZWアルゴリズムに対してIBM社も特許権を持っているのでは……？という問題が起こりかけたが、こちらは無事解決した。IBM社が特許権を保有している圧縮方法は、LZWの従兄弟とでも言うべきもので、似てはいるが違う。どちらも、LZ78という先駆的アルゴリズムから派生したものである。既存の圧縮アルゴリズムからいくつもの新アルゴリズムが派生した場合、それらが特許の対象になるほど革新的かどうかを判断することが必要になるが、この問題はおそらく各国の特許局に任せるのが賢明だろう。
残念ながら、Fedora、Ubuntu、Slackware、Debian、Mandrivaといった人気のLinuxディストリビューションには、libtiff 3.7が含まれていない。Novell社のSUSEは、ハイエンド製品であるProfessionalには3.7を含むが、Desktopには含まない（と、同社Webサイトにある）。
ユーザが自分のシステムにLZWサポートを復活させるための第1歩は、インストールされているlibtiffのバージョンを確認することである。ほとんどは3.6.1だろうが、最新の「LZW圧縮キット」（libtiffではこう呼ばれている）は、libtiff 3.5.5〜3.6シリーズのためだけに作られたドロップインなので、この点の確認は重要である。3.5.4かそれ以前のバージョンを使っているときは、アップグレードが必要となる。確認には、パッケージ管理ソフトウェア（yum、Synaptic、その他）を立ち上げ、libtiffまたはtiffという名前のパッケージを探して、それのバージョン番号をメモする。パッケージ管理アプリケーションがないときは、コマンドラインからlocate libtiffを実行し、出力中から正確なバージョン番号を探せばよい。
明日のライブラリを今日
「実が熟するのを待て」と言うかもしれない。「libtiff 3.7へのアップグレードまで待ったらどうだ」と。もちろん、それでもいい。だが、パッケージ管理システムを使用するとき、libtiff 3.6に依存していると主張するアプリケーションが出てきて、依存関係問題が発生する。もちろん、それらアプリケーションの依存関係チェックの不備が原因なのだが、残念ながらよく見られる問題である。おそらく、うまくなだめればlibtiff 3.7を使わせることもできるだろうが、途中、パッケージ管理システムから多くの苦情が出ることを覚悟しておかなければならない。当該ディストリビューションが3.6ライブラリを最新と信じているなら、パッケージ更新や新規インストールのたびに--forceオプションを使うより、3.6ライブラリを「修正」したほうがよい。
LZW圧縮キット（lzw-compression-kit）は、libtiff.orgから入手できる。ダウンロードし、インストールバージョンに対応するlibtiff 3.6.xを選択する。パッケージ管理システムを使ってもよいし、libtiffのホームページを使用してもよい。
次に、キットとライブラリソースの両方を作業用ディレクトリにアンパックする。圧縮キットにはREADMEと、Changelogと、tif_lzw.cという名前のファイルが含まれている。最後のファイルを、アンパックしたtiff-3.6.x/libtiff/ディレクトリにコピーし、libtiffに含まれていたtif_lzw.cファイルをこれで上書きする。
次に、tiff-3.6.xディレクトリに移動し、構成スクリプトを実行する。通常の作業なら、shとする。libtiffソフトウェアをlocate libtiffで、libtiffライブラリの所在を確かめよう。ほとんどの場合はshとして設定スクリプトにそう伝える。最後に、make installでコンパイルする。すでにインストールされているバージョンに上書きするには、ルート権限が必要なので注意しよう。
この方法（システムライブラリのパッチ、コンパイル、上書き）では不安だという方は、--prefixフラグなしでconfigureを実行し、コンパイルして、LD_LIBRARY_PATH経由で新しいlibtiffを使うGIMPを立ち上げる（$ LD_LIBRARY_PATH=/usr/local/lib; export LD_LIBRARY_PATHを実行し、GIMPを立ち上げて、TIFFファイルを保存してみる）。ただし、LD_LIBRARY_PATHの使い方を誤ると、ひどいことになるので注意が必要だ。新しいライブラリが正しく機能すると確認できたら、それを目的の場所にインストールする。
あとは鼻歌でも歌いながら、ハードディスクを遅くするばかりだった巨大な非圧縮TIFFファイルを心行くまでスリムにしていけばよい。
libtiff 3.5 → 3.7で学ぶ教訓
私としては、次世代の各Linuxディストリビューションが最初からlibtiff 3.7を含んでいて、上記パッチ手順を不要にしてくれることを願っているが、エンタープライズ向けなど、リリースサイクルの長いLinuxディストリビューションのユーザは、この問題からしばらく逃れられないと覚悟したほうがよいだろう。
そして、修正作業をこれだけ簡単にしてくれたlibtiff開発者に感謝しよう。特許という重しのもとで、修正もままならないライブラリは数多くある。NewsForgeにあるHOWTOはイソップ物語にも似て、単純に見えても、貴重な教訓を――無料で――提供してくれる。今回の修正作業から得られる教訓は、「すっきりさわやかなコーディング標準は、予想もしなかったところで役に立つ」である。
ソフトウェア特許問題は、残念ながら、いましばらく問題でありつづけるだろう。たとえばFreetypeには、TrueTypeバイトコードヒンタ関連の問題があり、現在、特許権を盾にとったApple社からの脅迫に直面している。また、Monoファンは、仮に親会社Novellが特許権問題でいらいらしはじめても、Ximianが従来どおり優しく接してくれることを願うしかない。
原文
