---Against Software Patents---
1991 年 2 月 28 日
プログラミング自由連盟
(LPF、League for Programming Freedom)
「SEAMAIL」Vol.6, No. 6〜7
ソフトウェアの特許は、米国のコンピュータ産業を荒廃させる危険がある。過去 10 年間に承認されたいくつかの特許が、今や、Lotus Development Corporation のようなソフトウェア会社が独自に開発したプログラムの販売を妨害するために用いられている。このような状況が続けば、新しい企業はいずれソフトウェアの市場から完全に締め出されてしまうだろう。大きなプログラムのほとんどが、それを動かすために何十という特許を取らなければならなくなるが、そのようなことは実際上不可能である。この問題を解決する方法は 1 つしかない。それは、ソフトウェアの特許を止めさせることである。
アメリカ合衆国憲法を作った人々が特許という制度を制定したのは、発明者に対して自身の発明を一般大衆と共有することを促すためであった。発明の秘密を明らかにする代わりに、発明者にはその特許を 17 年間独占する権利が与えられる。特許権者は、他人にその発明を使用する許可を与えることができる。あるいは、その使用を禁止することもできる。後で、別の人間が同じ技法を独立に (再) 発明したとしても、それを使う権利は与えられない。
特許は、特定のシステムに対しては適用されない。いろいろなシステムの構築に使われる個々の技法、あるいはそれらのシステムが提供する個々の機能に対して適用される。いったん、ある技法や機能に特許が与えられると、その権利を持つ人間の許可がなくては、特定のシステムの中でそれを使うことができなくなる。たとえそれが異なる方法で具体化されていてもである。コンピュータ・プログラムは一般に、数多くの技法を利用し、数多くの機能を提供するものであるから、1 度に多くの特許を侵害する可能性がある。
最近まで、特許の概念はソフトウェアの分野には適用されなかった。ソフトウェア開発者は、個々のプログラムに著作権を主張したり、それらを業務上の秘密 (トレード・シークレット) として扱うことで、自分の権利を守ってきた。◆1 著作権はその由来からして、特定のプログラムの具体化の詳細を保護するものであり、プログラムの機能や使われている一般的な手法には適用されない。そして、業務上の秘密という概念は、その定義から、秘密を知らない人間が行なう開発作業を妨げるものではあり得ない。
こうした枠組みの上で、ソフトウェア開発は個々の開発活動に対して禁止事項を設け、極めて高い収益性を持つビジネスとなり、かなりの額の投資を享受してきた。しかし、この図式はもう成り立たない。1980 年代初期に米国政府の方針が変わり、その結果、特許申請の氾濫をもたらした。今や数多くの特許がすでに承認され、現在もその数は加速度的に増えつつある。
多くのプログラマはまだこの変化に気がつかず、その影響の大きさを正しく認識していない。今日、いくつかの訴訟事件が始まったばかりのところである。
特許庁および裁判所は、コンピュータ・ソフトウェアの扱いにはたいへん苦労してきた。特許庁は、コンピュータ・サイエンスの学位取得者を審査官として採用することを最近まで拒んできた。ソフトウェア業界と比較できるような給与を支払うこともできなかった。従って、ほとんどの特許審査官は、ソフトウェアの特許申請を評価する能力を持たない。つまり、個々の申請が周知の技法や明白な技法 (いずれも却下の理由になる) に基づくものであるかどうかを判断することができない。
一般的に使われているソフトウェア開発技法の多くが、コンピュータ・サイエンスの文献に出ていないということも、特許審査官の仕事をさらに困難なものにしている。わざわざ出版するにはあまりにも明白な技法もあれば、一般性に欠ける技法もある。また、プログラマにとって公然の秘密になっている技法もある。
コンピュータ・サイエンスを勉強した人間なら誰でも、広範な状況に一般化できるような技法が数多く存在することを知っている。しかし、特許庁は、ある技法の個々の使い方が、それぞれ新たな特許の対象になると考えているかのように見える。例えば、Apple 社は Hypercard プログラムが特許番号 4736308 に違反すると訴えられている。その特許は、文字列の一部を複数個一緒に画面上に表示する技法 (つまり、複数のサブウィンドウのスクロール) に関するものである。スクロールもサブウィンドウも共に周知の技法であるが、それらを組み合わせて使うことは、現在では違法となる。
特許庁によってある特許が承認されると、必然的にそれは法律的に有効になる。申請以前に長年にわたって使われてきた周知の技法であったとしても、いったんそれが特許として承認されると、連邦裁判所はそれを支持することになる。法律上の問題が発生した時点で、その技法が周知のものであることを証明するのは、かなり難しい。
例えば、画面上にカーソルを表示するために排他的論理和を使う技法は、周知であり、明白でもある (この利点は、同じ操作をもう 1 度行なうことにより、画面上のほかのデータを損なわずにカーソルを消去できることである)。この技法は、ほんの 2〜3 行でプログラミングすることができる。頭の良い高校生なら誰でも思いつくことである。しかし、これは特許番号 4197590 として承認されている。特許申請よりも 5 年以上も前からこの技法が広く使われていたにもかかわらず、2 回の裁判で特許権者の権利が支持された。そして、この特許を持っている Cadtrak 社は、大きなコンピュータ・メーカ数社から何百万ドルもの使用料を得ている。
イギリスでは、従来からある普通のグラフィックス技法 (エアブラッシング、ステンシリング、別の画面から 2 つの画面の合成などを含む) に対して特許権が認められた。その分野の開拓者が、それらの技法は自分達が何年も前に開発したものだと証言したにもかかわらず、最近、裁判所で特許権者の権利が支持された (それに相当する米国の特許は 4633416 号および 4602286 号である。これらはまだ裁判で試されてはいないが、近くそうなるであろう)。
スプレッドシート・プログラムの主だった開発者達は、「自然な順序の再計算」(スプレッドシートの各項目を固定した順序で計算し直すのではなく、ユーザが行なった変更によって影響を受けるものだけを再計算する技法) に関して認められた特許 4398249 号の脅威を感じている。今のところは Lotus 社だけが訴えられている。しかし、この訴訟がもし原告側の勝訴に終われば、その他のスプレッドシート・ベンダの希望はほとんど消え失せてしまうだろう。我々LPF は、裁判でこの特許を打ち負かす可能性、それより前に実現された技術を発見したが、我々が勝訴できるかどうかは、まだ確実ではない。
プログラマが特許になっている技法をたまたま使ってしまった結果訴えられる場合の防衛手段は存在しない。既存のプログラムのどれかを取り上げて、その性能を改善しようとでもすれば、承認済みまたは近く承認されるであろういくつかの特許に触れることになる。
いずれは特許庁がソフトウェアをもっとよく理解するようになるとしても、連邦議会または最高裁判所が介入して、これらのばかげた特許の無効を宣言しない限り、現在彼らが犯しつつある過ちが、次の世紀まで我々を追いかけまわすだろう。
しかし、問題はこれだけとは限らない。コンピュータ・プログラミングは、特許制度が適用されてきたほかの分野とは、根本的に異なっている。特許制度は、ソフトウェアに対して狙い通りに働いたとしてもなお、それが本来振興しようとする産業を阻害していることになる。
特許制度のもとでは、明白であると判断されたものが特許として承認されたり、裁判で支持されることはない。しかしながら、この制度は、「明白 (Obvious)」という言葉を、コンピュータ・プログラマにはとても考えられないような方法で解釈するのである。これまでほかの分野で使われてきた明白さの基準は、ソフトウェアに対しては適切でない。
特許審査官や裁判官は、ほんの小さな漸進的な変化でさえもが新しい特許に値すると考える習慣を持っている。例えば、有名な Polaroid 社対 Kodak 社の裁判では、フィルム中の乳剤の層の数と順番が問題になった。Kodak 社が使っていた技法と Polaroid 社が説明した技法との差異が特許を終了させた。裁判所はこれらの差異は明白なものではないと判定したのだ。
コンピュータ研究者達は、プログラミングという手段に手慣れており、いろいろな問題を素早く解決できる。そして、解法原理を 1 つの問題からほかの問題へと一般化する習練を積んでいる。そうした一般化の 1 つに、ある手続きを繰り返したり、分割するということがある。プログラマはこれを明白なことだと考えている。しかし、特許庁は、前述の複数の文字列のスクローリングに特許を与えたときには、そうは考えなかったのである。
このようなケースは、過ちであるとは考えられない。特許制度は、まさに当初考えられた通りに働いている。しかし、ソフトウェアに関しては、とんでもない結果を生み出す。
ときには、それがあまりにも明白すぎて誰もそれについて論文を書こうなどと考えもしなかったような、決して新しくはない技法を特許として申請することも可能である。
例えば、MIT が開発した X Window System を無料で配布しているコンピュータ会社は現在、「バッキング・ストア」(backing store) に関する特許 4555775 号を侵害するという理由で AT&T から訴えられる恐れがある。この技法は、一部が隠れているウィンドウの内容をスクリーン以外のメモリに格納しておき、隠す原因となったウィンドウがなくなったときに高速に画面を表示するためのメカニズムである。それは、複数のプログラムがそれぞれ固有のウィンドウを持ち、それらが互いにオーバラップすることが可能なウィンドウ・システムに用いられる。
初期のウィンドウ・システムは、複数のプログラムを同時に走らせることができないようなコンピュータで開発された。これらのマシンの記憶容量は小さく、ウィンドウの内容を保存することは、明らかに貴重なメモリ空間の浪費でしかなかった。後になって大型の多重処理コンピュータが登場し、バッキング・ストアの技法を利用してそれぞれのプログラムに固有のウィンドウを持たせることが一般的になってきた。従って、技法の組み合わせは当然のことであった。
バッキング・ストアの技法は、AT&T の特許申請より以前に、MIT の Lisp マシン・システム・プロジェクトで用いられた (偶然にも Lisp マシンもまた多重処理をサポートしていた)。Lisp マシンの開発者は、その時点ではバッキング・ストアについては何の論文も発表しなかった。それはあまりに明白だと考えられたからである。唯一、プログラマーズ・マニュアルの中で、そのオン・オフをどうするかの説明に関連して言及されているだけであった。
しかし、そのマニュアルが出版されたのは、AT&T が特許を申請して 1 週間後であった。従って、特許を打ち負かすための先行技術として考慮されるには遅すぎた。このように AT&T の特許が有効となった。MIT はいずれ、自分が AT&T より先に使っていた技法を使い続けることを禁じられることになるかもしれない。
そして、その結果、X Window System がフリー・ソフトウェアであるという理解のもとに、それを MIT から受け取っていた何十社かの企業と数十万人のユーザは、訴追を受ける危険にさらされる (人々はまた、Cadtrak 社の排他的論理和の特許にも脅かされる)。X Window System プロジェクトは、全ての開発者が自由に使えるウィンドウ・システムの開発を意図していた。この公共的なサービスという目標の達成が、今や特許制度によって妨害されているのである。
ソフトウェア・システムの設計は、同じ部品数から成るハードウェア・システムの場合と比較してはるかにやさしい。例えば、10 万個の部品から構成されるプログラム (サイズは 5 万行程度) は、優秀なプログラマが 2 人いれば 1 年で作れるだろう。必要な設備費用は 1 万ドル未満である。それ以外にかかる費用はプログラマの生活費だけであり、投資額の総計は 10 万ドル未満で済むだろう。もし、その開発が大きな企業の中で商業ベースに行なわれたとしても、開発費はせいぜい 2 倍以内であろう。それとは対照的に、10 万個の部品から成る一般的な自動車を設計するには、かなり大がかりなチームを必要とし、何千万ドルもの費用がかかる。
また、ソフトウェアは製造コストも極めて安い。1 万ドル以下の値段で手に入るような普通のワークステーションで簡単にコピーすればよいからである。一方、複雑なハードウェア・システムを製造するには、何千万ドルもかけて工場を建設しなければならない場合がよくある。
なぜこうなのか ? ハードウェア・システムは現実の部品を使って設計されなければならない。それらの部品はコストも異なる。性能にも制約がある。温度や振動、または湿度に敏感なこともある。雑音が出るかもしれないし、またエネルギーを消費する。一時的に、あるいは永久に故障することもある。物理的にも適切な場所に組み込まれなければならず、故障の際には交換できるようになっていなければならない。
さらに、ハードウェアの設計においては、それぞれの部品がほかの多くの部品の挙動に影響を与える場合が多い。このことが、ハードウェア設計の仕事をさらに複雑なものにしている。設計が終わるころになって、基本的な数学モデルの誤りが明らかになることもある。
コンピュータ・プログラムはそれと対照的で、想像上の数学的な構成要素から組み立てられる。個々の部品の挙動は、近似的にモデル化されるのではなく、抽象的規則によって明確に定義されている。if 文の後に while 文が続く場合、if 文が while 文のエネルギーの一部を吸収してしまい出力がおかしくなるとか、while 文に余計な圧力がかかって故障するといった余分な心配をする必要は全くない。
しかし、単純な部品から組み立てられているにもかかわらず、コンピュータ・プログラムは信じられないくらい複雑である。10 万個の部品から成るプログラムは、設計が容易であるにもかかわらず、自動車と同じ程度の複雑さを備えている。
プログラムを書いたり、製品化や販売などに要する費用は、自動車の場合に比べてかなり安いが、特許問題を処理する費用は決して小さくならない。部品の数が同じであったとしても、平均してほぼ同数の特許対象の技法が含まれているからである。
現行の特許制度のもとでは、法を守ろうとするソフトウェア開発者は、プログラムがどの特許を侵害しているか判断して、それぞれの特許所有者からその特許の使用許諾 (ライセンス) を貰うための交渉を行なわなければならない。ライセンス料がとんでもなく高額になることもあるだろうし、市場での競争相手が特許を持っている場合には、使わせてもらえないかもしれない。個々のライセンス料がたとえ「妥当」なものであっても、それらの金額を合計すると、プロジェクトが遂行不可能な額になるかもしれない。だからといって、既存の特許を全く使わずに開発を進める道を見出すことはほとんど不可能である。
特許制度における最大の危険は、開発者が製品を市場に出した後で、その製品がいくつかの特許を侵害していることがわかるという場合である。その結果、発生した裁判とそれに要する弁護士費用は、中規模の会社を破産させるに足る額になるであろう。
さらに困った問題として、ソフトウェア開発者がこの危険を回避する実際的な方法は存在しないことだ。あるシステムがどの特許を侵害しているかを発見する有効な方法が、全くないのである。特許検索という方法がないわけではないが、検索自体があまり信頼できないし、ソフトウェア・プロジェクトに適用するには費用が高すぎる。
10 万個の構成要素から成るシステムはおそらく、すでに特許化されている数百の技法を利用しているであろう。それぞれの特許検索には何千ドルかの費用がかかる。従って、特許侵害の危険を避けるための検索費用の総額は、それだけで 100 万ドルを簡単に越えてしまう。これはプログラム開発費をはるかに上回る金額である。
費用はこれだけでは済まない。特許申請のための書類は、弁護士が弁護士のために書いたものである。プログラマがそれを読んだとしても、自分のプログラムがその特許を侵害しているとはとても考えられないであろう。しかし、連邦裁判所の判断は違う。そのために、プログラム開発のあらゆる段階に、特許関係の法律的専門家が関係することが必要になっている。
しかし、仮にそのような手をうったとしても、後で訴えられる危険を少なくしただけに過ぎず、危険を完全に取り除いたわけではない。やはり、起こり得る訴訟に備えてあらかじめ資金を用意しておくことが必要である。
会社があるハードウェア・システムの設計に数百万ドルのお金を使い、さらにその製造に数千万ドルの投資を計画している場合には、特許問題の処理に必要な 1〜2 万ドルの経費は許容範囲内となる。しかし、極めて利益の低いプログラム開発プロジェクトの場合は、それだけの余分な経費はとても負担することができない。個人や小企業の場合はなおさらである。ソフトウェアの特許は、ベンチャー企業家を市場から締め出す働きをする。
開発者が特許検索の費用を負担できたとしても、それは既存特許の使用を回避する手段としてははなはだ信頼性が低い。特許検索は、現在審査中の特許申請について何も教えてくれない (それらは特許庁内で機密扱いで保持されている)。ソフトウェア特許の承認には平均して数年を要するから、これは深刻な問題である。ある特許が申請された後で、別の開発者が大きなプログラムの設計を開始し、特許が認められる前に製品を出荷することもあり得る。そして、出荷してしまってから、そのプログラムの配布が法律違反であることを知るのである。
例えば、広く使われているパブリック・ドメインのデータ圧縮プログラム compress は、「IEEE Computer」誌所収の論文に書かれたアルゴリズムに従っている (このアルゴリズムは PKZIP やその他のマイクロコンピュータ用によく使われているプログラムの中でも採用されている)。これらのプログラムの開発者やユーザは今、原論文の著者の 1 人に特許 4558302 号が発行されたことを知って当惑している。この特許の取得者である Unisys 社は、現在このアルゴリズムの使用料を要求しようとしている。compress プログラムは依然としてパブリック・ドメインにあるが、それを使うことは訴訟の危険を冒していることを意味する。
特許庁は、ソフトウェアの特許を分類するための枠組みを実際に持っているわけではない。特許はほとんどの場合、「鉄を鋼鉄に変換する」といった最終的な結果に従って分類される。しかし近年では、多くのソフトウェア特許は、プログラムの中での使い方がそのプログラムの最終目的とは全く独立しているようなアルゴリズムにまで適用されている。例えば、人間の音声を分析するプログラムが、高速フーリエ変換の高速化に関する特許を侵害する恐れがあれば、抽象代数のプログラムも (大きな数の乗算に際して) 同じ危険を持つことになる。しかし、このような可能性を検索しようと思っても、特許の現在の分類ではほとんど不可能であろう。
すでに特許として承認されたソフトウェア技法のリストを作成し、それを保守するのは容易ではないか、あるいは単にそのリストをどこかに記憶しておけばよいのではないか、と言われるかもしれない。しかし、そうしたリストの管理はほとんど不可能に近い。実際、1989 年にこの分野を専門とする弁護士グループが編集したリストには、この論文で引用したいくつかの特許がすでに漏れている。
あなたが何かの発明を考えたとすると、おそらく、短い言葉でその特徴を表現しようとするだろう。例えば、「固定の湾曲した翼を持った空を飛ぶ機械」とか、「マイクロフォンとスピーカを使った電気的な通信装置」といった具合である。しかし、ソフトウェア特許の多くは、複雑で詳細なプロセスを扱っており、簡単に言い表すことはとうていできない。また、特許の多くは、それ自体が複雑でよく知られたプロセスの高速化や変形に関するものである。
これらの特許はたいてい明白でもなく華麗でもない。それらはあいまいである。有能なソフトウェア設計者なら、1 つのプロジェクトの進行中に、そうした改良案をいくつも「再発明」するであろう。しかしながら、ソフトウェア技法を改良する道はたくさんあるので、異なるプロジェクトにおけるそれぞれの改良案が、特定の技法に一致する可能性は低い。
例えば、IBM 社は、最適化コンパイラが行なうべき周知の計算処理に関して、複雑ではあるが巧妙な高速化技法の特許をいくつか持っている (特許番号 4656583 ほか)。これには、レジスタの色分けや、すでに評価済みの式の計算なども含む。
特許はまた、すでに広く使われている技法の組み合わせに対しても認められる。一例として、IBM 社の 474240 号特許があり、「shared copy-on-write segments(共有書き込み時複写セグメント)」に関するものである。この技法は、ファイルにマッピングされているメモリのセグメントを共有する方法である。ファイル内の、あるページに任意のプログラムを書き込むと、そのセグメントを共有している全てのプログラムに対して、書き込みが発生したページを複写したもので置き換える。これによってファイルを共有しないで、そのページを互いに共有し続けることができる。
「セグメントの共有」および「書き込み時複写」の概念は、1960 年代から使われてきたものである。この特定の組み合わせは、確かに特別な機能を提供する新しいアイデアかもしれないが、決して発明ではあり得ない。にもかかわらず、特許庁はそれを特許に値するものと判定した。だから現在では、この特許を、新しいオペレーティング・システムを開発しようとする全ての人々が考慮に入れなければならないものとなってしまった。
こうしたあいまいな特許は地雷に似ている。全てのソフトウェア開発者は、そうした特許をあらかじめ発見し回避するよりも、これらの技法を再発明する可能性のほうが大きい。そして、特許法違反で訴えられるのである。これらの特許の 1 つに該当する可能性は小さくとも、特許の件数が非常に多いので地雷を 1 つも踏まずに遠くまで進むことはできない。あらゆる基本的ソフトウェア技法には数多くの変形があり、また数多くの組み合わせがあり得る。米国特許庁は、これまでに少なくとも 2000 件の特許を認めている。EDS 社がまとめたリストによれば、1989 年だけで 700 件以上ある。このペースはさらに加速するものと予想される。10 年以内には、プログラマはもはや盲滅法に行軍せざるを得ないだろう。そして、そうしなければ地雷を踏まずに生き残れる確率はほとんどない。
大きなソフトウェア会社の多くは、自社でいくつもの特許を取得して、この問題を解決しようと考えている。つまり、主要な特許の多くを保有するその他の大企業とクロスライセンスを結び、これまでと同じように自由に仕事を続けていこうというわけである。
Microsoft 社や Apple 社あるいは IBM 社といった大企業ならば、この方法でビジネスを続けられるかもしれないが、後発の新しい会社は締め出されてしまう。将来、自分自身の特許を 1 つも持たずにソフトウェア・ビジネスを始めようとする企業は、このような巨人の決めた特許使用料を (いかに高額であろうと) 支払うことを強いられる。最近起こった Borland 社および Santa Cruz Operation 社に対する Lotus 社の訴訟事件は、このメカニズムがどのように働くかを示す良い例である (この訴訟そのものは、特許というよりは拡張された著作権の概念に関係するものであるが……)。
特許の独占的な権利を獲得し、他人を訴訟で脅かすことだけを商売にしているような会社を相手にした場合には、たとえ巨大企業といえどもクロスライセンスによって身を守ることは不可能である。例えば、ニューヨークが本拠地の Refac Technology Development Corporation という会社がある。この会社は、前に述べた「自然な順序での再計算」に関する特許権所有者の代理人である。Refac 社はその社名とは裏腹に、訴訟を起こすだけで、何の技術開発も行なっていない。つまり、同社は、クロスライセンス協約に参加する理由を全く持ち合わせない。「排他的論理和」に関する特許所有者の Cadtrak 社も、同じような訴訟会社である。
Refac 社は、主なスプレッドシート・プログラムのベンダに対して、売上げの 5 パーセントを特許使用料として支払うよう要求している。もし、未来のプログラム商品が、このような特許を 20 件侵害したとすると、ライセンス料の合計は販売価格の 100% を越えてしまう。コンピュータ・プログラムの複雑さと、多くの特許の適用範囲の広さを考えれば、これは決して非現実的な仮定ではない (実際には、ほんの数件の特許侵害を犯しただけで、プログラム商品の利益は全て失われてしまう)。
合衆国憲法によれば、特許制度の目的は「科学および有用な技術の進歩を促進する」ことである。従って、ここでの基本的な疑問点は、もともとソフトウェアの進歩を奨励する方法として考えられたソフトウェアの特許が、はたして本当にそういう働きをするのか、それとも反対に進歩を遅らせてしまうのか、ということである。
これまでは、特許がいろいろな形で通常のソフトウェア開発を難しくする事情を説明してきた。それでは、特許がもともと意図していた利点とは、いったい何だったのだろうか。より多くの発明を生み出し、それらの成果をより多く一般に公開させることではなかったのか。ソフトウェアの世界で、そのことは実際にどの程度起こり得るのだろうか。
社会がソフトウェア特許制度から得られる利益は極めて少ない。というのは、ソフトウェアの世界においては、すでに特許制度が始まる以前から多くの発明がなされ、それらは、誰もが利用できるようにいろいろな雑誌に発表されていたからである。発明の習慣はあまりにも盛んすぎて、同じ発明が繰り返されることもしばしばあった。
特許は完全な独占である。全ての人間は、特許になったプロセスを使うことを禁じられる。たとえ独立に再発明したとしてもである。この姿勢は、発明が極めてまれな出来事であり、貴重なものであることを暗に仮定している。そういう状況でのみ、特許制度は有益なのである。
ソフトウェアの分野は、常に再発明が行なわれる世界である。誰かが言ったように、プログラマは、ほかの分野の研究者が 1 年間に生み出す数よりも多くの「発明」を毎週のように行ない、結果を使い捨てている。大規模なソフトウェア・システムの設計が比較的容易なことから、多くの人間がこの分野で仕事をしている。そして、プログラマは、1 本のプログラムを開発する過程で数多くの問題を解決していく。これらの解決法は、ほかのプログラマが同様の問題を対処する場合にも、何度も繰り返し再発明される。
このように、独立の再発明が一般的であることは、特許の通常の目的を否定するものである。特許は発明を促進し、その内容の一般への開示を奨励するための制度である。もし、ある種の技法が何度も再発明されるのならば、さらに多くの人々がそれを発明するように奨励する必要は全くない。そうした発明者の誰かが (何らかの意義を感じて) それを出版しようとしているのならば、その技法の自由な利用を禁止する代価を払ってまで、わざわざ特定の発明者に出版を奨励するいわれはない。
日米両国産業の比較分析を行なっている多くのアナリスト達は、日本が高品質の製品を製造することに成功した原因を、日本が世の中の目を引く発明よりも、漸進的な改良や、ユーザに便利な機能や品質を重視したからだとしている。
ソフトウェアの場合、開発が成功するかどうかは、まず、細部を正しくすることにかかっている。そして、有用なソフトウェア・システムの開発を行なう場合、作業の大部分は製品の細部に関わっており、その仕事の中では発明は比較的重要度が低い部分である。
ソフトウェア特許というアイデアは、製品よりもむしろ発明を重視するという米国人の誤った先入観の一例である。そして、実際の個々の特許はこの視点の誤りを助長し、本来ならばより良いソフトウェア製品を産み出すはずの開発作業を邪魔している。
ソフトウェア特許は、開発に携わるプログラマの人数を減少させるだけでも、実際に技術革新を妨げている。ソフトウェアにおける技術革新の多くは、開発作業の過程でさまざまな問題を解決しているプログラマによってもたらされるのであって、何かを発明して特許を取ることを目的にしたプロジェクトがもたらすわけではない。言い換えれば、技術革新はソフトウェア開発の副産物である。
特許が開発をより困難なものにし、開発プロジェクトの数を減らすことになれば、開発の副産物である新しい技法が生み出される数もまた減小する。
ソフトウェアの特許制度は、社会全体にとって一般に有害であるが、我々は決して個々のソフトウェア特許の全てが有害だと主張しているのではない。慎重に研究すれば、(大部分の場合を除外するような) 特定の狭い条件下に限れば、ソフトウェアの特許を認めることが有益である場合が発見されるだろう。
それでもなお現時点で行なうべき正しい行為は、もっと大きな損害が生じる前に、全てのソフトウェアの特許を可能な限り速やかに廃止することである。慎重な研究はその後で実施すればよい。
弁護士を除けば、ソフトウェアの特許制度を緊急に必要としている人間などいないことは明らかである。特許制度が導入される以前のソフトウェア産業には、特許でしか解決できないような問題などはなかった。発明が足りなかったわけでも、投資が不足していたわけでもなかった。
ソフトウェア特許の全廃は、理想的な解決策ではないかもしれないが、ほぼそれに近く、また大きな改善をもたらす。この単純さは、人々の詳細な議論で生じる大きな遅れを防ぐのに役立つ。
ソフトウェアの特許性の有益性が、例外的な場合において示されたそのときには、必要に応じて法律を再び変えることができる。現在の破滅的な状況をその日まで引きずっていく理由は全く存在しない。
驚くべきことではあるが、特許法を拡張してソフトウェアに適用したことには、いまだに法律的な疑問が残る。この拡張は、1981 年に最高裁判所が行なったある判決 (Diamond 対 Deihr 事件) の極端な解釈に基づいている。*1
伝統的に特許が認められるプロセスの種類は、(鉄を鋼鉄に変えるといった) 物質変換のプロセスに限られていた。我々がほかにプロセスだと考える多くの活動、例えばビジネス上の手法、データの解析、「精神的プロセス」などは、対象から全く除外されていた。これは、主題原則 ("Subject matter"doctorine) と呼ばれるものである。
Diamond 対 Deihr 事件は、特許庁がこの原則をくつがえすものだと解釈したが、裁判所はこれを明確に却下しようとはしなかった。このケースは、ゴムの矯正 (すなわち物質の変換) プロセスに関するものである。係争点は、そのプロセスの中でコンピュータ・プログラムを使うことが特許に値するか否かということであった。その結果、裁判所はそれは特許に値すると裁定し、特許庁はこの極めて狭い条件付きの判定を、ソフトウェア技法に対して無制限に特許を与えることへの青信号だと解釈した。そして、よく知られたソフトウェアの利用にまで拡大して適用できると考えたのである。
多くの弁護士達は、特許の新しい境界線は、何十年かの時間をかけて費用をかけても一連の裁判を通じて決定すべきだと言いながらも、実際にはこの変化を歓迎した。こうした一連の動きは、確かに弁護士にとっては好都合であるが、ソフトウェア開発者やユーザにとってははなはだ迷惑である。
我々は、特許の対象領域からソフトウェアを除外する 1 つの法律を提案したい。この法律は、いかなる特許であろうともそれがソフトウェアとして具体化された場合には適用されず、設計の難しいハードウェア形式での具体化にのみ適用されるということを規定するものである。この方法の利点は、特許審査の際に、その申請をハードウェアとソフトウェアに分類する必要がなくなることである。
この目的のためには、どのようにしてソフトウェアを定義して、どこで線を引けばよいのか、 が問題になる。この法律の目的からすれば、ソフトウェアの定義は、ソフトウェアの特許が極めて有害になる特性に基づいて行なわれるべきである。つまり、
ソフトウェアは、想像上の堅固な数学的構成要素から組み立てられ、各構成要素からの出力は、入力側の構成要素による影響は受けない。
想像上の数学的構成要素は、抽象的な規則によって定義される。従ってそれらが故障することは、その定義からして起こり得ない。これらの構成要素から組み立てられるシステムの挙動は、同様に、各構成要素に抽象的な規則を順次適用して行くことによって定義される。
ソフトウェアは、容易に安い費用で複写することができる。
この基準に従えば、素数を計算するプログラムは 1 つのソフトウェアであるが、同じ計算を実行するために特別に設計された機械的装置はソフトウェアではない。機械部品には摩擦があり、相互の動作に干渉し合い、故障することもあり、動作可能な機械を作るには、手間をかけて物理的に組み立てなければならないからである。
どのようなソフトウェアも、それを動かすにはプラットホームとしてのハードウェアを必要とする。ソフトウェアは、ある計画に従って、ハードウェアの機能をある組み合わせで操作する。我々の提案は、このような形で機能を組み合わせれば、特許の侵害を絶対に起こさないということである。もし、ハードウェア自体が特許を侵害していなければ、プログラムの制御下で、ある使い方に沿ってハードウェアを使えば、特許の侵害になるはずはない。事実、プログラムとはプログラマの精神の延長であって、プログラマの代理としてハードウェアを制御しているのである。
ここでいうハードウェアとは通常、汎用コンピュータを指し、特定のアプリケーションを想定して作られた機械ではない。そのようなハードウェアは、コンピュータの製造に関する特許を除けば、いかなる特許をも侵害するはずがない。我々の提案は、ユーザがあるプログラムを汎用コンピュータ上で動作させる場合に、コンピュータの製造に関する特許以外のいかなる特許をも適用されないという意味である。
伝統的なハードウェアとソフトウェアの境界線には、いくつかの複雑な特性が含まれており、それらはお互いに連携して働く可能性を持っている。ゲートアレイやシリコン・コンパイラなどの新技術の登場により、その区別はあいまいになっている。そうした新技術は、ハードウェア的な特性とソフトウェア的な特性とを組み合わせたものだからである。しかし、これらの新技術のほとんどは、特許審査の際には、上述の判定基準を用いて、少しのあいまいさも残さないで、ハードウェアあるいはソフトウェアのいずれかに分類することができる。いくらかは灰色の領域が残るかもしれないが、それらは比較的小さく、通常のソフトウェア開発に対して特許制度が引き起こす問題の解決を必ずしも妨害するとは限らない。これらの領域は最終的には、ハードウェア、ソフトウェア、あるいはその中間の何物かとして扱われることになるであろう。
ソフトウェア特許の廃止運動を助ける 1 つの道は、我々の組織 LPF(League for Programming Freedom、プログラミング自由連盟) に参加することである。◆2 LPF は、ソフトウェア特許とインタフェース著作権に反対するプログラマやユーザの草の根組織である (LPF は個々のプログラムの著作権には反対していない)。個人会員の年会費は、企業の従業員は 42 ドル、学生 10.5 ドル、その他は 21 ドルである。実際に活動することのできる方はもちろん大歓迎だが、自分の時間を割いて貢献することができない会員も歓迎する。
LPF への連絡は、次の宛先まで電話、電子メールまたは郵便でお願いしたい。
League for Programming Freedom 1 Kendall Square #143 P.O.Box 9171 Cambridge,MA 02139 U.S.A 電話番号 (617)243-4091 電子メール league@prep.ai.mit.edu
米国内におけるもう 1 つの援助手段として、連邦議会に手紙を出すという方法がある。あなた自身の州から選出された議員宛に出してもよいが、もっと効果的なのは、この問題を審議している小委員会宛に出すことである。
House Subcommittee on Intellectual Property 2137 Rayburn Bldg. Washington,DC 20515 U.S.A Senate Subcommittee on Patents,Trademarks and Copyrights United States Senate Washington,DC 20510 U.S.A
各州選出の議員へは (202)225-3121 で電話をかけられる。あるいは次の住所宛に手紙を出せばよい。
Senator So and So United States Senate Washington,DC 20510 U.S.A Representative Such and Such House of Representatives Washington,DC 20515 U.S.A
ソフトウェア特許の全廃に成功するまでの間、我々は個々のソフトウェア特許を覆すことに努力しなければならない。それにはかなりのお金がかかり、そのわりには問題のごく一部しか解決することができないが、それでもなお、何もしないよりはましである。
法廷で特許を覆すには、先行的な技術を見つけ出すことが必要である。それはやさしい仕事ではない。LPF は、ソフトウェア特許訴訟の被告側を援助するために、この種の情報交換所の役割を果たそうと考えている。それがうまくいくかどうかは、あなたの援助いかんにかかっている。もし、あなたがいずれかのソフトウェア特許に関する先行的な技術についてご存じならば、どうかその情報を前述の LPF 事務局までお送りいただきたい。
もし、あなたがソフトウェア関係の仕事をしているのならば、特許申請への協力を拒否することで、ソフトウェア特許の防止に個人的に協力することができる。その詳細は、個々の状況によって異なるであろう。
特許制度の適用範囲からソフトウェアを除外することは、恐ろしく費用のかかる特許検索や、既存の特許を回避するための無駄な労力、あるいは避けがたい訴追の危険などからソウトウェア開発者を守るものである。
もし、状況が何も変わらなかったとすれば、現在は有効で創造的な活動も、実行不可能なほど費用のかかるものとなる。例えば、歩道の敷石の 1 つ 1 つに所有者がいて、歩行者がそれを踏むたびにライセンス料を要求されると仮定しよう。その制度下では、1 ブロックの街路を歩くのにどれだけの交渉が必要かを想像してほしい。ソフトウェアの特許が存続した場合のプログラミングは、ほぼそれと同じようなものになる。これまでコンピュータ革命の原動力であった創造の閃きや個人主義は消滅してしまうのである。
用語について補足する。「シークレット」は官公庁に対して「機密」、民間企業に対しては「秘密」というふうに使い分けられる。
…"Legally Speaking", Communications of the ACM, August 1990 参照。
ここでいう「我々」とは、Free Software Foun‐dation や GNU プロジェクトとは別個の組織のメンバーとしてである。