The GNU Operating System and the Free Software Movement

GNUシステムとフリーソフトウェア運動


Richard Stallman
リチャード・ストールマン
Translation by Akira Kurahone



ソフトウェアを共有した最初のコミュニティ
 一九七一年、私は、マサチューセッツ工科大学(MIT)人工知能研究所(AI Lab)の一員として働きはじめ、それとともに、長い歴史を持つソフトウェア共有コミュニティのメンバーとなった。とはいえ、ソフトウェアを共有するという行為は、最近になって我われが始めたことではない。それは、コンピュータの誕生以来、プログラマの世界では、自慢料理のレシピを教えあう感覚で、普通に行なわれてきた行為である。もちろん、我われが、他の人たちより熱心にソフトウェアの共有に取り組んできたのは事実である。
 人工知能研究所では、ITS(Incompatible Timesharing System)というタイムシェアリングシステムをOSとしていた。このオペレーティングシステムは、研究所の真のプログラマたちがDEC社製のPDP−10用に設計し、アセンブラで書いたものだった(PDP−10は、その時代の最大級のコンピュータの一つだった)。ソフトウェア共有コミュニティの一員であり、また、人工知能研究所のシステム管理者であった私の仕事は、このシステムを改良することだった。(原注−「ハッカー」という言葉の本来の意味は「プログラムを愛し、その改良を楽しむ人」のことで、「セキュリティ侵害者」としての「ハッカー」は、マスメディアの誤用であり、我われハッカーはそれを認めない。)
 当時、「フリーソフトウエア」という表現はまだ存在していなかったので、我われは、自分たちのソフトウェアを「フリーソフトウエア」とは呼んでいなかった。しかし、我われ他大学の人たちや会社の人たちがプログラムを移植して使いたいと言ってきたときは、喜んでそうさせていた。目新しくて面白そうなプログラムを使っている人がいれば、我われはその人からソースコードを自由に見せてもらうことができた。そういったソースコードの一部を自分たちで書き換えて使うこともできた。そういうプログラムを好きなように解体して、別のプログラムの中で使うこともできた。我われがソフトウェアをフリーソフトウェアとみなしていたことは事実である。


コミュニティの崩壊
 状況が一変したのは、一九八〇年代の初めだった。DEC社がPDP−10シリーズの生産を中止したのである。一九六〇年代には、よくできていて処理能力も高いマシンとして定評のあったPDP−10シリーズのアーキテクチャも時代遅れになり、大容量のメモリが使えないことで、我われのハードウェアとしては適さなくなってしまった。そして、PDP−10シリーズが継続されなくなってしまったことで、我われのOSであったITSを構成するプログラムの大部分は使い物にならなくなってしまった。
 実際のところ、PDP−10シリーズの生産中止が発表される少し前から、人工知能研究所のコミュニティはすでに崩壊していた。一九八一年、シンボリックス社がそれまで研究所のメンバーであった人たちを中心に創設され、研究所の腕利きプログラマのほぼ全員が引き抜かれてしまったとき、人工知能研究所は人手不足に陥り、自律したコミュニティとして機能できなくなってしまったのである(そのあたりの出来事は、全盛期のコミュニティの様子とともに、スティーブン・レヴィの著書『ハッカーズ』(工学社刊)に詳しく紹介されている)。一九八二年に人工知能研究所がPDP−10を新たに購入すると、システム管理者たちは、(MIT独自のOSである)ITSに代えてDEC社製のタイムシェアリングシステムを有料で使用することにしている。
 当時のマシンは、VAX系や68020系も含めて、独自のオペレーティングシステムを使っていた。しかし、オペレーティングシステムはフリーソフトウェアとして提供されていなかった。そのため、バイナリ形式の実行プログラム一つを手に入れるにも、我われは機密保持契約書にサインしなければならなかった。
 その時代、コンピュータを使うためには、まず隣人に手を貸さぬことを誓わなければならなかった。要するに、助け合いのコミュニティを作ることは許されなかったのである。「ソフトウェアを隣人と共有するのは著作権の侵害である。ソフトウェアに何らかの変更が必要な場合は、我われメーカーに変更を願い出なければならない」。それが、従来のビジネス慣行に沿った独占的な製品の所有者たちの定めたルールだった。
 ところで、一部の読者には意外に聞こえるかもしれないが、排他的な所有権に基づいてソフトウェアの使用をとらえる考え方は、反社会的であり、非倫理的でもある。ソフトウェアの共有を許さないことや、自由な変更を許さないことは正しくない。私には、人びとを分裂させ、ユーザを無力化させることで成り立っている制度について、他に語るべき言葉がない。この考え方を意外に思う読者は、ソフトウェアには排他的な所有権がつきものと思っているのではあるまいか。あるいは、(従来のビジネス慣行に沿ったクローズドな製品を売る)業界の都合のいいように思い込まされているのかもしれない。ソフトウェアと知的所有権の関係について、ソフトウェアメーカーは、昔から躍起になって、ひとつの見方しかないと人びとに思い込ませようとしてきている。
 ソフトウェアメーカーが、自分たちの「権利」の「行使」や「著作権侵害の防止」について語るとき、重要なのは彼らが言葉で何と言っているかではない。彼らが何を前提としてそのようなことを言っているかが重要なのである。ユーザは、我われの主張を黙っておとなしく受け入れるべきだ。彼らの発言の前提条件、つまりユーザに対する真のメッセージはまさにこれである。では、彼らの前提条件とは具体的に何なのだろうか?
 彼らの暗黙の前提条件のひとつは、ソフトウェアメーカーにはソフトウェアを所有する当然の権利があり、したがって、彼らのソフトウェアを利用する人たちを支配できる、というものである(彼らの権利が所与なものであれば、それが社会にとっていかに有害なものであろうと、我われは異議を唱えることができない)。しかし興味深いことに、合衆国憲法や法律の慣例では、メーカー側の言い分は認められていない。つまり、著作権は当然な権利などでなく、政府によって国民が従うべく人工的に制定された独占権なのである。コピーを作ろうとするユーザの天賦の権利を制限するものなのである。
 ソフトウェアメーカー側の暗黙の前提条件のふたつ目は、彼らが次のように考えていることである。一番重要なことは、「ソフトウェアを使って何ができるか」であるから、ソフトウェアを使う人たちがどんな社会に暮らすかについてはまったく気にする必要がない。
 第三の前提条件は、使いものになる(あるいは、いろいろ仕事をするための)ソフトウェアを使いたい人は、ソフトウェアメーカー側に自分たちを支配する権限を与えなければならない、とメーカー側が考えていることである。しかし、この前提は、フリーソフトウェア運動の人たちが、そんな足かせをはめなくてもソフトウェアをたくさん作れることを証明した以上、もはやもっともらしく聞こえない。
 前記のような前提条件を鵜呑みにせず、ユーザ第一主義で、ごくあたりまえの倫理観に基づいて考えれば、まったく別の見方をすることができる。我われの社会は他人を助けることで成り立っている。したがって、コンピュータのユーザは、何の制約も受けずにソフトウェアを他人と共有できるべきなのである。必要に応じて自由にプログラムを書き換えることができるべきなのである。
 どうしてこのような結論になるのか? それについては、紙面の都合上、これ以上述べることができない。詳しくは“Why Software Should Not Have Owners, by Richard Stallman(http://www.gnu.org/philosophy/
why-free.html)”を参照していただきたい。


純然たる選択
 私は、所属していた(MIT人工知能研究所という)コミュニティが消滅してしまい、以前と同じように活動することができなくなったとき、むずかしい選択に直面した。
 機密保持契約書にサインし、クローズドな製品を作る世界の一員となって、仲間のプログラマたちを助けないと約束する。そうすることにしていたなら、私も、機密保持契約書への合意をユーザに強制するソフトウェアを開発し、隣人を助けないことを他人に強いることに協力していただろう。
 クローズドな製品を作る側を選ぶのは容易だったから、そうしていれば、お金を稼ぎながら、プログラムを書いていたかもしれない。しかし、私にはわかっていた。そんな選択をすれば、将来後悔することが。そんなことをすれば、長年かかって人びとの間に壁を作る側に手を貸すことになり、この世の中をもっと住みにくくすることに一生を捧げることになる。将来、自分の人生を振りかえって、そんなことをしている自分を見るのは私の望むところではなかった。
 私にはすでに、機密保持契約がらみで嫌な思いをさせられていた。人工知能研究所で使っていたプリンタ制御用プログラムのできが悪く、それを改良しようと、我われがソースコードの提供を頼んだところ、機密保持契約を盾にして断わられたときの経験がそれである(このプログラムには特定の機能が欠けていたため、プリンタの使い心地が最悪だった)。ソースコードの共有を拒まれたとき、私は無性に腹が立った。そんな経験があったので、道義的選択に直面したとき、善悪や好き嫌い抜きに機密保持契約書を考えることができなかった。そんなわけで、私はいまさら、クローズドな製品を作る側について、自分がされて嫌だと思ったことを他人にする気にはならなかった。
 第二の選択は、簡単だが気のすすまない、コンピュータの世界から足を洗うという選択だった。このオプションを選択すれば、自分のスキルが悪用されることはない。だが、自分のスキルが無駄になってしまうことも確かだった。自分一人がコンピュータのユーザを分断したり束縛したりする罪から免れたところで、そのような事が世の中からなくならないことも確かだった。
 そこで、私は、一人のプログラマとして、世のため人のためにできることはないか、コミュニティを再生するために、私に書けるプログラムはないだろうか、と考えた。
 必要なのはオペレーティングシステムである。それが私の答であることははっきりしていた。オペレーティングシステムは、コンピュータを起動するための重要なソフトウェアである。それがあればコンピュータを使っていろいろなことができる。それがなければコンピュータはまったく動かない。フリーソフトウェアのオペレーティングシステムがあれば、誰でも参加できる、協力的な真のプログラマのコミュニティを再生できる。そして、他人を助けないことを前提としなくても、コンピュータを使えるようになる。私はそのように考えたのである。
 人工知能研究所のITSというオペレーティングシステムの開発者の一人であった私は、フリーソフトウェアのオペレーティングシステムの開発にうってつけのスキルを持ちあわせていた。必ず成功するという確証はなかったが、この仕事をするために選ばれたのだという実感があった私は、UNIXと互換性のあるオペレーティングシステムを開発することにした。移植性のあるOSにすれば、UNIXユーザも気軽に乗り換えられる。私は、再帰的な略称を好む我われの流儀にならって、このシステムをGNUと名づけた−(GNUは、「GNU's Not UNIX(GNUはUNIXでない)」という文字列中の三つの要素のそれぞれの頭文字をとった略称であるが、それ自体が最初の単語と同じであり、しかも、アフリカ東・南産の牛を意味する「GNU(ヌー)」という英単語でもある。ただし、GNUシステムのではGも発音してグニューと言う)。
 オペレーティングシステムとは、カーネルだけを示す用語ではない。カーネルだけでは、他のプログラムをかろうじて動かせる程度である。一九七〇年代、オペレーティングシステムと名のつくものにはみな、コマンドプロセッサ、アセンブラ、コンパイラ、インタープリタ、デバッガ、テキストエディタ、メーラ、その他もろもろのものが含まれていた。ITSにも、そういうユーティリティやツール類が含まれていた。Multicsもしかり、VMSにしてもUNIXにしてもそうだった。そして、GNUシステムもそうなることになった。
 これは誰かから後で聞いたことだが、あるときヒレル(Hillel−聖書解釈学における明確な基準を確立したユダヤ教のレビ)は次のように言ったそうである(原注−無神論者である私は、特定の宗教家の教えに従うことはないが、時として彼らの文言に感心させられることはある)。

「自分がしなければ、誰がするのか」
「自分だけのためにしか存在しなければ、私はいったい何なのか」
「今しなければ、いつ実行するのか」

 これと同じ精神に基づいてGNUプロジェクトの開始は決定された。


「足かせをはめられていない」という意味での自由
「フリーソフトウェア」という表現は、フリーという単語に「自由な」という意味と「無料の」という意味があるので、時として誤って解釈されてしまうことがある。しかし、「フリーソフトウェア」中の「フリー」は、「足かせをはめられていない」「(使用・コピー・変更・配布が)自由にできる」という意味であって、金銭的に有料/無料ということとはまったく関係ない。したがって、「フリーソフトウェア」は次のように定義するのが正しい。
 ユーザであるあなたが、あるプログラムを以下の条件で使用できるとき、そのプログラムはあなたにとってフリーソフトウェアである。



 右記の定義に従う限り、「フリーソフトウェア」の「フリー」は「自由にできる」という意味なので、フリーソフトウェアであるプログラムのコピーを作って、それを第三者に対して売ったところで、なんら「フリーソフトウェア」の定義に反することではない。それどころか、コピーを作って売れる自由は、「フリーソフトウェア」であることの必須条件ですらある。たとえば、フリーソフトウェアコレクションをCD−ROM版で販売する方法は、フリーソフトウェアのコミュニティにとって、開発費調達の重要な手段である。したがって、この手のコレクションに自由に収録できないプログラムは、フリーソフトウェアであるとは言えない。
 英語の「フリー(free)」という単語にはいくつもの意味がある。そのため、私がここで言うところの「フリーソフトウェア」にぴったりの意味を表わすのに、「フリー(free)」に代わって使える言葉はないかと、いろいろな人たちが随分長い間思案してきているが、これだという言葉はいまのところまだ見つかっていない。英語には、どの言語にも劣らず多くの単語やニュアンスがあるのに、「自由にできる」という意味を単純明快に指す単語がないのである。「liberated」、「freedom」、「open」といった単語も提案されているが、ぴったりした意味を表わすものではない−しいて探せば、「unfettered」という単語の「足かせをはめられていない」という意味に最も近い。


GNUシステムには、GNUソフトウェア以外のフリーソフトウェアも含まれている
 オペレーティングシステム全体を開発する。私は、この大変な仕事を実現可能とするために、既存のフリーソフトウェアで済ませられる部分については、できるだけそうすることにした。たとえば、私は、開発プロジェクトに着手したときから、テキストの(印刷のための)レイアウト用のツールには、TeXを使うことに決めていた(Texは、スタンフォード大学のドナルド・E・クヌース教授によって、数式を美しく表現するための組版システムとして開発されたフリーソフトウェアである。テキスト中に書式やフォントについての属性を記述して文書を清書できる)。また、開発プロジェクトの開始から数年たったところで、GNU用のウインドウシステムも、新しいものをゼロから作る代わりに、(ライセンス的にオープンでソースコードが自由に配布されていた)Xウィンドウシステムを使うことに決めた。
 既存のフリーソフトウェアをできるだけ利用することにしたので、GNUシステムには、GNUプロジェクトで開発したもの以外のソフトウェアも含まれている。それらを開発した人たちやプロジェクトは、我われのGNUプロジェクトとは直接関わりはないが、それらのプログラムをフリーソフトウェアとしてくれているので、我われもそれらを使うことができるのである。


プロジェクトの開始
 一九八四年一月、私はMITを辞め、GNUソフトウェアの作成に取りかかった。大学を辞職した理由は、GNUをフリーソフトウェアとして配布することについて大学側に口出しさせたくなかったからである。MITのスタッフのままGNUプロジェクトを推進すれば、できあがった成果物に対して、大学当局が所有権を主張できる。GNUシステムの配布に際して、大学独自の配布条件をかしたりすることもできる。成果物をもとに、クローズドな製品パッケージを作成することもできる。多大な努力のはて、当初の目的が達成できなくなるのは嫌だった私は、ソフトウェアを共有するコミュニティを作れないのに、汗水たらすつもりはなかった。
 ところが、親切にも、大学を辞職した私に、当時MIT人工知能研究所の所長だったウィンストン教授が、いままでどおり研究所の設備を使うようすすめてくれた。


GNUプロジェクトの第一段階
 GNUプロジェクトを実際に始める直前、私は、Free University Compiler Kit−別名VUCK−のことを耳にした(「free」を意味するオランダ語の頭文字はVである)。これは、C言語Pascalを含む複数の言語をサポートし、異なるCPUに対応した実行可能なコードを生成できるコンパイラだった。さっそく私は、プログラムの開発者に手紙を書いてGNUプロジェクトで使わせてもらえるかどうかを尋ねた。
 ところが、相手はさもばかにしたかのように、大学を使うのはフリーだがコンパイラはそうではないと返事をしてきた。そこで、私は、GNUプロジェクトでは、複数のプログラミング言語をサポートし、異なる機種の上で動作し、異なる機種に対応した実行コードを生成できるような構造を持ったコンパイラを最初に開発することに
した。
 コンパイラをすべて自分で書かなくて済むように、私は、ローレンス・リバモア研究所で開発されたマルチプラットフォームなコンパイラであるPastelのソースコードを入手した。それは、システム記述言語として使えるように拡張されたPascalで実装されていた(Pastel自体もその拡張版Pascalで書かれていた)。私はそれに自作のC言語のフロントエンドプロセッサを追加したものを、モトローラ社の68000というCPUの搭載されているマシン上で使えるようにする移植作業に取りかかった。しかし、その68000CPUのマシン上で動いているUNIXシステムは、スタック領域がキロバイトまでしか使えなかったので、数メガバイトものスタック領域を使用するように作られていたPastelコンパイラの移植を私はあきらめざるを得なかった(スタック領域とは、コンパイラが動作するときに使う動的な記憶領域である)。
 Pastelは、ソースコードの読込みから構文解析、実行コードの生成までの全処理をメモリ上で行なっていた。しかも、一度確保したメモリはまったく解放しない作りになっていた。それが、数メガバイトものスタック領域を使用しなければならない原因であることがわかった時点で、私は、新しいコンパイラを書かなければならないと思った。現在、GCCと呼ばれているそのコンパイラは、私がPastelのコードを一切使わずに開発したものであるが、(以前にPastel用に書いた)C言語用のフロントエンドは改良したうえで使用している。とはいえ、私がGCCの開発を実際に始めたのは、それから数年たってからのことである。私がそのときすぐに着手したのはGNU Emacsエディタの開発であった。


GNU Emacsの開発
 私がGNU Emacsの開発に取りかかったのは一九八四年九月である。そして、一九八五年の初頭には、それまでUNIX以外のOSで行なっていたプログラミングを、UNIX上でGNU Emacsエディタを使ってできるようになった。それまでソースコードの編集をUNIX上でしていなかったのは、(UNIXの標準的なエディタである)viやedの使い方をわざわざ覚える気がしなかったからである。
 GNU Emacsが使えるようになると、そのニュースを耳にした人たちから、このエディタを使いたいのだが入手は可能か、という問い合わせが届きはじめた。どう配布するかがちょっと問題だったが、私はMITのコンピュータ上にftpサーバを開設し、そこからユーザが匿名ftpで自由にダウンロードできるようにした(その後、このサーバのアドレスprep.ai.mit.eduは、GNUの主たる匿名ftpマシンのアドレスとなった。そして、このサーバが開設されていたマシンが数年後に撤去されると、我われは新しいマシン上で同じアドレスを使用して匿名ftpサーバを開設した)。匿名ftpサーバはできたが、配布方法の問題は解決しなかった。というのも、一九八五年当時、GNU Emacsの入手を希望していた人たちの多くはインターネットに接続しておらず、ftpでコピーを入手することができなかったからである。そういう人たちに対して、どんな助言をしたらよいか。私はそれを考える必要があった。
 私は、「インターネットに接続していて、GNU Emacsをダウンロードしてくれそうな友人がいたらその人に頼んでみたら」と助言することもできたが、それはしなかった。また、PDP−10版Emacsの入手を希望していた人たちに告げていたように、「磁気テープと返信用封筒と切手を同封のうえ、それを郵送してくれれば、GNU Emacsを入れて返送します」と伝えることもできたが、結局それもしなかった。そのときちょうど失業中だった私は、フリーソフトウェアで稼ぐ方法を模索していた最中だったので、一五○ドルを郵送してくれる人にはGNU Emacs入りの配布テープを送り返すことにした。こうして、私はフリーソフトウェアのビジネスに乗り出し、現在LinuxベースのGNUシステムの配布をビジネスとしている企業の先駆けとなった。


本当のフリーでないプログラムも多い
 ユーザがプログラムをフリーソフトウェアとして使えるためには、そのプログラムの開発者がそれをフリーソフトウェアとするだけでは十分ではない。そのことだけでは、ユーザがそのプログラムをフリーソフトウェアとして使えることに必ずしもならないからである。たとえば、パブリックドメインに公開されているソフトウェアは、(著作権が放棄されているので)フリーであるが、それをもとに別バージョンを作成し、それに著作権を設定することは可能だ。同様に、フリーなプログラムの中にも、著作権は設定されているが、非常に緩やかな契約内容のもとに配布されていて、それからクローズドな別バージョンを作成できるものも多い。
 典型な例が、MITで開発されたXウィンドウシステムである。このウインドウシステムは、緩やかな契約形態のもとにリリースされたため、すぐに多くのコンピュータメーカーが採用するところとなった。しかし彼らは、自分たちが独占的な製品として売っていたUNIXシステムに(ソースコードなしの)バイナリ形式でXを追加し、機密保持契約書によって自分たちの知的所有権を保護したので、当時のUNIXがそうであったように、コンピュータメーカーが提供していたXウィンドウシステムは、もはやフリーソフトウェアではなかった。
 ところが、Xウィンドウシステムの開発者たちにとって、それがもはやフリーソフトウェアでないことは問題ではなかった。彼らは、そうなることを予想し、意図していたからである。「多くのユーザを獲得する」という意味での単なる「成功」を目指していた彼らにとって、ユーザがXを自由にできるかどうかはどうでもいいことだった。彼らは、Xが数多くのユーザによって使われるようになることだけにしか関心がなかった。
「フリー」の趣旨が二通りに解釈されてしまうことで、ひとつの矛盾した状況が生み出されてしまった。「このプログラムはフリーであるか」という問に対し、相反する答が同時に可能になってしまった。MITの配布条件で定義される自由に基づけばフリーソフトウェアとなるXも、平均的ユーザにとって自由であるかを判断すれば、独占的な商用ソフトウェアということになってしまう。そして当時、Xウィンドウシステムのユーザのほとんどが、フリーソフトウェアのバージョンではなく、商用版UNIXシステム付属の独占的なバージョンを使っていた。


コピーレフトとGNU GPLについて
 私にとってGNUプロジェクトを推進する目的は、多くのユーザを獲得するだけではなく、ユーザの自由にできるソフトウェアを提供することにあった。したがって、我われは、GNUソフトウェアの配布条件に、それがクローズドな製品に転用されることを防止する文言を盛り込む必要があった。この目的を達成するために我われが採用した使用許諾形態がコピーレフトである(原注−私は、一九八四年か一九八五年頃、ドン・ホプキンス氏から一通の手紙をもらった。非常に創造力に豊んだホプキンス氏は、いろいろ面白いフレーズを封筒に書きつけて送ってくれていた。そして、その中のひとつが、“copyleft−all rights reserved”であった。私は、ちょうどその頃、GNUソフトウェアの配布形態をどうするかを考えていたので、このコピーレフトという表現を配布形態の名称として使用することにした)。
 コピーレフトは、著作権法(コピーライト)に基づいて著作権を告知するひとつの方法である。しかし、(ライトがレフトと逆になっているように)著作権法を裏返しに適用させることで、通常の目的とは逆の目的にかなうようにしている。つまり、コピーレフトは、著作物を私物化するための権利ではなく、自由なものにしておく権利の法的保護を目的としている。
 コピーレフトは、すべてのユーザに対して、コピーレフト適用の趣旨が明記されているプログラムの使用を許可するものである。そのプログラムをコピーすることを許可し、そのプログラムを修正し、そうしたものを改訂バージョンとして配布することを許可するものである。ただし、コピーレフト適用のプログラムとして使用許諾を得たオリジナルのコピーレフトの文面に、ユーザ自身が制限条項を盛り込むことは認められていない。このように、GNUのコピーレフトに基づく使用許諾形態は、オリジナルのコピーレフトの内容の変更を許さないことで、ユーザが(コピーレフトの)フリーソフトウェアを自由に使用する権利を、何人も奪うことのできない権利として保証している。
 コピーレフトが有効に適用されるためには、コピーレフトのソフトウェアの修正版のユーザもまた、それを自由に使用できなければならない。これが保証されれば、我われの成果物に基づいて作成されるものも、我われのコミュニティに還元され、コミュニティの人たちの共有するところとなる。たとえば、ふだんプログラマとして働いている人が、自発的にGNUソフトウェアを改良したとしよう。そういう場合でも、成果物に対してコピーレフトの適用を明記しておけば、たとえ雇用主であっても次のような主張を展開することはできない。「この成果物を使ってクローズドな製品を作るので、それを第三者と共有してはならない」
 コピーレフトは、ソフトウェアに加えられた変更部分も自由に使用できると規定している。この規定は、絶対なくてはならないものである。というのも、この規定が適用できないと、修正版のユーザの自由が保証されないからである。たとえば、たいていのメーカーは、Xウィンドウシステムを自社製のOSやマシンに移植するために、それを変更し自社製バージョンのXウィンドウシステムを作成した。彼らが施した変更は、全体のほんの一部にすぎなかったが、決して些細なものではなかった。変更が加わっていることを盾に、第三者の自由を奪うことができれば、それを悪用することは誰にでもできる。
 前記の規定と関連するが、フリープログラムのコードと、フリーでないプログラムのコードを組み合わせる場合の話がある。そのようなプログラムは、必然的にフリーではない。使用したフリーでないプログラムが、どのような意味でフリーでなかったにせよ、新しく作成されたプログラムも、まったく同じ意味でフリーでないと言えるからだ。このような組み合わせが抜け道として利用されれば、GNUプロジェクトのせっかくの試みも有効なものとはならない。したがって、認めることはできない。コピーレフトでは、そのような抜け道を残さないために、コピーレフトされているプログラムとの組み合わせで作成されたプログラムは、使われたコピーレフトプログラムと同様にフリーであり、コピーレフトによって保護されることになっている。
 GNU プロジェクトでは、我われのコピーレフトの考え方をGNU一般公有使用許諾(GNU General Public License又はGNU GPL)で表わしているが、状況によっては、GNU GPL以外の形でコピーレフトを表現することもある。たとえば、GNUのマニュアルもコピーレフトされているが、GNU GPLのような複雑な条項を適用する必要はないので、マニュアル用のコピーレフトはずっと簡略に表記されている。



FSFの設立
 GNU Emacsについての関心が高まるにつれ、GNUプロジェクトに参加する人たちも増えてきた。そこで、我われは、プロジェクト運営の資金調達に乗り出すときがきたと判断し、一九八五年、FSF(Free Software Foundation)を設立した。その時点で、GNU Emacsのテープを配布する事業は、フリーソフトウェアの開発を目的とする非営利組織であるFSFによって引き継がれた。それ以降、FSFは、GNU Emacs以外に(GNUソフトウェアでないものを含む)フリーソフトウェアが追加された配布テープや、関連マニュアルを販売して事業を拡大している。
 FSFは寄付を受け付けているが、収入の大部分を占めているのは昔から、フリーソフトウェアの販売や、様々な関連サービスからの売上である。現在、FSFは、いろいろなプログラムのソースコードが収録されているCD−ROM、バイナリ形式のプログラムの収録されているCD−ROMを販売している。ちゃんと印刷された紙製のマニュアルも取り扱っている(すべてに再配布と修正の自由が認められている)。Deluxe Distributionという名前のソフトウェアコレクションも販売している(このコレクションは、プラットフォームごとに、いくつものバージョンが用意されている)。
 FSFのスタッフは、GNUソフトウェアの開発やメンテナンスに従事している。たとえば、CライブラリとbashシェルはGNUソフトウェアとしてよく知られている。このライブラリは、GNU/Linuxシステム上で動作するプログラムがLinuxとのやりとりで使用するインターフェイスである。この開発者は、FSFスタッフのローランド・マクグラスである。bash(Bourne Again Shell)は、ほとんどのGNU/Linuxシステム上で使われているシェルプログラムであるが、これを開発したのは、FSFスタッフのブライアン・フォックスである(原注−Bourne Again Shellは、UNIXの一般的なシェルプログラムであるBourne Shell(sh)をもじって命名されている。Bourneがbornと同音異義語なので、Bourne Again Shell(ボーン・アゲイン・シェル)で「生まれ変わったシェル」となる)。
 GNUプロジェクトがこのようなプログラムの開発に資金を投入したのは、我われのプロジェクトの目的が、完全なオペレーティングシステムを作ることにあったからである。我われには、その目的を達成するために、ツールや開発環境だけでなく、Cライブラリやbashなどが必要だったのである。


フリーソフトウェアのサポート
 フリーソフトウェアの理念は、ある種のビジネス慣行とは相容れないものである。しかし、ビジネスそれ自体を否定するものではない。我われは、ユーザ側の自由を尊重するビジネスには成功してほしいと思っている。
 GNU Emacs入りの配布テープを販売したやり方は、フリーソフトウェアビジネスのひとつのありようを示しているが、FSFがこの事業を引き継いだとき、私は別の方法で生計を立てざるを得なくなった。そこで思いついたのが、自分で開発したフリーソフトウェアに関連するサービスを提供するビジネスである。GNU Emacsでプログラミングする方法やGCCをカスタマイズする方法を教えることも、そんなサービスのひとつだった。ソフトウェアの開発などもあったが、それらは主にGCCを新しいプラットフォーム上に移植する作業だった。
 現在、フリーソフトウェア関連のサービスを提供するビジネスは、多くの会社によって実践されている。フリーソフトウェアのコレクションを収録したCD−ROMの配布を商売にしているところもあれば、ユーザからの質問に答えるビジネスで成り立っているところもある。バグ取りをしているところもあれば、新機能の追加を商売にしているところもある。新しいフリーソフトウェアをビジネスの中核とする会社まで登場するようになっている。
 しかし、それらの企業の中には、「オープンソース」という言葉に便乗しているだけのところも多い。そういうところは、実際には、フリーソフトウェアと一緒に動作するフリーではないソフトウェアを主に売っているので、我われは十分注意してかかるべきである。こういったところは、フリーソフトウェアでビジネスをしている会社ではない。彼らは、独占的な製品を売っている会社であり、そのような製品を餌にユーザを本当の自由から遠ざけているのである。彼らは自分たちで売っているものを「付加価値製品」と呼んでいるが、彼らが言うところの価値とは、自由ではなく便利さのことである。彼らの付加したものに我われが価値を見出す。彼らは、そうなることを望んでいるのである。つまり、自由に重きを置く我われにとって、そのような会社の提供する製品は「付加価値製品」ではなくて「自由を減ずる製品」と呼ぶべきものなのである。


GNUシステムの目指す技術的な目標
 私がこのプロジェクトを開始したのは、第一に、GNUシステムを開発し、それをフリーソフトウェアとして世に出したかったからである。技術的観点からすれば、GNUシステムはUNIX以上のものではない。しかし社会的観点からすれば、(フリーソフトウェアの)GNUシステムにはユーザ間の協力を助長するという、UNIXにはない利点がある。ユーザの自由を尊重することを目指すという倫理的な利点がある。
 私は、GNUシステムを開発するにあたり、技術的な標望として、その当時すでに優れているとされていたソフトウェア標準を適用することにした。たとえば、データ構造については、すべて動的に割り当てることにし、データ構造の長さや個数などについての制限を一切設けないことにした。コーディングでは可能な限り、8ビットコードを扱えるようにした。
 さらに、GNUシステムが完成するころにはビットCPUのマシンが標準になっていることは明らかだったので、ビットCPUのマシンをサポートしないことに決めた。そのため我われは、メモリを極力使わないように設計する旧式のUNIX流のコーディングはしないことにし、1メガバイトのメモリを使うことを前提にコーディングして構わないことにした。つまり、使用メモリが1メガバイトに達しない限り、メモリの消費を控えようとしてはならないことにした。非常に大きいファイルを扱う場合でも、入力ファイル全体をメインメモリ上に展開して、入出力処理にわずらわされず、そのメインメモリ上をスキャンできるやり方を推奨することにした。
 GNUプロジェクトでは、技術的観点からこのようなコーディング規則を採用したため、従来のUNIX関連のプログラムよりも信頼性が高く、処理速度に優れたプログラムをたくさん開発することができた。


マシンの寄付
 我われがGNUプロジェクトで頑張っているという噂が広まるにつれ、UNIX搭載のマシンを寄付しようという人たちが現われるようになった。そして、マシンでの援助はとても有効だった。というのも、GNUシステムを開発するもっとも簡単な方法は、UNIXシステム上でUNIXの標準部分(コンポーネント)の代用品として使えるものを次々作成していき、それらができしだい、開発システムに反映させるという方法だからである。しかし、我われには、その方法を採用することに倫理的なジレンマがあった。我われには、オリジナルのUNIX版と同じものを作ることが、本当に正しい選択であるかを問う必要があった。
 UNIXは(今もそうだが)独占的なソフトウェアである。そして、GNUプロジェクトの理念では、独占的なプログラムは利用してはならないことになっていた。この矛盾が我われの倫理的ジレンマの原因だったのである。しかし私は、正当な自己防衛のための暴力は認められる、という論法を用いて、次のように結論づけ、自分の必要性を正当化した。第三者がクローズドなソフトウェアを使わなくて済むように、その代替品を開発するのに必要な場合は、所有権のあるプログラムを参照してもよい。
 とはいえ、今あるGNUシステムにはUNIXのソースコードはまったく使われていない。いくら正当化されたとはいえ、UNIXのソースコードを利用することが悪であることに変わりはなかったので、UNIXマシンのOSをフリーな代替OSで置き換えたからである。ちなみに、マシンのOSを交換できなかった場合は、マシンそのものを交換した。


GNU関係の作業リスト
 GNUプロジェクトが進行し、ますます多くのプログラム部品(コンポーネント)が調達され、また開発されるに従い、我われはリストを作成して、完成までに行なわなければならない残りの作業をわかるようにした。そして我われは、このリストをもとに、足りない部分をプログラミングしてくれる人たちの参加を募った。後に、GNU作業援助希望リスト(GNU task list)と呼ばれるようになるこのリストには、UNIXの標準部分(コンポーネント)の代用品でまだ揃っていないものが記載されていた。そのほかにも、あったら便利なソフトウェアがたくさん記載されていた。真に完成されたシステムには備わっていて当然と思われるドキュメント類を作成するプロジェクトも記載されていた。
 UNIXの標準部分(コンポーネント)の代用品については、ほとんど対応済みなので、現在、GNU作業援助希望リストに記載されているのは、いくつかの細かな部分についての記述だけである。今このリストを埋めているのは、これから開発したほうがよいであろう「アプリケーション」のプロジェクトである。広範なユーザにアピールするプログラムがオペレーティングシステムに追加されれば、便利であろうと思われるからである。
 GNU作業援助希望リストにはゲームも含まれているが、それはプロジェクト開始以来のことである。UNIXソフトウェアにもゲームが含まれていたことから、GNUも自然とそうなったのであるが、ゲームプログラムについては互換性を気にする必要がない。そこで、我われは、UNIXと同じゲームはリストせず、GNUユーザが気に入りそうなゲーム類を幅広くリストアップしている。


GNUライブラリ一般公有使用許諾
 GNUのC言語ライブラリに対するコピーレフトの適用方法は、GNUライブラリ一般公有使用許諾(GNU Library General Public License、LGPLと略す)で表現されている。LGPLは、GNU Cライブラリと独占的なソフトウェアのリンクを許すものである。我われは、なぜこのような例外を認めているのだろうか。
 我われは、原則を変えて、そのようなことを認めているわけではない。実際の話、我われのソースコードを包含する権利を独占的なソフトウェアが持つというような原則は存在しないし、我われとの共有を拒否することで成り立っている側に我われが手を貸す必要もない。我われは戦略的選択によって、GNUライブラリ一般公有使用許諾をGNU Cライブラリに(あるいは、いかなるライブラリにも)適用するのである。
 独占的なソフトウェアやコンパイラにはC言語ライブラリが必ず含まれている。したがって、我われのGNU Cライブラリは非常に一般的な仕事をするにすぎず、それとのリンクをフリーソフトウェアのプログラムだけに限定することは、その使用をユーザに断念させるだけで、少しもフリーソフトウェアのためにならない。
 であるから我われは、GNUシステム(GNU/Linuxを含む)の唯一のCライブラリであるGNU Cライブラリでは例外を認め、独占的なプログラムとライブラリをリンクしてプログラムをコンパイルできるようにしている。もちろん、我われが、GNUシステム上で独占的なプログラムを使えることを認めなければならない道義的な理由はまったくない。しかし、戦略的に考えると、それを認めない効果は、フリーアプリケーションの開発を促進するというより、GNUソフトウェアの使用を疎外する傾向がある。
 そういうわけで、戦略的に判断すれば、GNU CライブラリにLGPLを適用することは理にかなっている。しかし、このライブラリ以外の他のライブラリに対して、どんな形でコピーレフトを適用するかについては、臨機応変に決定しなければならない。たとえば、コピーレフトしようとするライブラリが、特定のプログラムの開発だけを支援するようなものである場合には、GPLを適用するのが望ましい。GPLでリリースすれば、そのライブラリでリンクできるのはフリーソフトウェアだけに限定され、独占的なソフトウェアの開発には使用できず、その意味で、フリーソフトウェアの開発者側を加勢することになるからである。
 GNU Readlineは、そのようなライブラリの一例である。bashの使用に際して、コマンド行の編集をサポートするために開発されたこのライブラリは、LGPLではなく通常のGNU GPLでリリースされている。そのため、GNU Readlineの利用率はかえって低くなっているかもしれない。しかし、それによって我われは損をしているわけではない。というのも、GNU Readlineを使えることで、少なくともひとつの有益なアプリケーションがフリーソフトウェアとして開発され、それがコミュニティにとっての真の利益となっているからである。
 独占的なソフトウェアを開発する側には、お金という味方がある。我われフリーソフトウェアの開発者は、お互いを味方にしなければならない。私の願いは、独占的なソフトウェア側には作成できないような膨大なライブラリのコレクションをGPLでリリースすることである。それによって、新しいフリーソフトウェアの開発に使用できる部品をたくさん提供し、フリーソフトウェア運動のさらなる発展の大きな足がかりを築くことである。


個人の欲求を満たすためのソフトウェア?
 エリック・レイモンドが、「よくできたソフトウェアはみな、何かを開発したいという個人の欲求を満たすことから生まれてくる」と言っているように、よくできたソフトウェアの原点に個人の欲求があることもある。しかし、GNUソフトウェアを構成する部品の多くは、完全にフリーなオペレーティングシステムを作る目的を実現するために開発されている。これらのプログラムは、何かを作りたいという個人の衝動から生まれたのではない。それらは、未来への展望をもとに計画され、開発されたのである。
 たとえば、我われは、GNUオペレーティングシステムにCライブラリが必要だったので、GNU Cライブラリやbashシェル、そして(アーカイブプログラムの)GNU tarを開発した。私がGNU Cコンパイラ、GNU Emacs、GDB(GNU デバッガ)、GNU Makeといったプログラムを書いたのもまったく同じ理由からである(GNU Makeは、必要に応じてソースファイルのコンパイルやリンクを自動的に行ない、バイナリファイルやオブジェクトファイの生成を制御するツールである)。
 GNUプログラムの中には、我われの自由に対する脅威に対抗するために開発されたものもある。たとえば、UNIXのcompressファイル圧縮プログラムが「LZWデータ圧縮法」に関わる特許問題のために使用料を要求されるようになったので、我われはそれに代わるものとしてgzip(ファイル圧縮プログラム)を開発している。UNIXの独占的なGUIであるMotif互換のフリーウェアであるLessTifの開発をスタートさせたのも我われである。最近では、独占的なライブラリが引き起こす様々な問題(次節参照)に対処するため、(完全にフリーウェアで、ユーザフレンドリーな統合デスクトップ環境を作ろうという)GNOMEプロジェクトの開発や、(完全にフリーソフトウェアで、開発言語にC++を使用するGUIツールキットであるQtライブラリ互換のライブラリを作ろうという)ハーモニー・プロジェクトに着手している。我われは今、ユーザがプライバシーか自由かの選択を迫られるべきではないとの思いから、広く普及している独占的な暗号化ソフトウェアに代わるものとして、GPG(GNU Privacy Guard)の開発を推進している。
 確かに、開発者たちはプログラミングを愛するがゆえに仕事をし、様々な機能が我われのソフトウェアに追加されているのも事実である。しかし、それだけの理由でGNUプログラムが開発されてきたわけではない。


予想外の展開
 私は、GNUプロジェクトを開始するにあたり、全システムを完成し、それを完全版として配布しようと考えていた。しかし、そういうふうにことは運ばなかった。
 GNUシステムの各部分は、UNIX上で実装されたため、GNUシステムが完全にできあがるずっと以前から、UNIX上で使うことが可能だった。そのため、GNUシステムの部品として開発されたプログラムのいくつかが幅広く利用されるようになった。中には、ユーザによって機能が拡張されたり、様々なバージョンのUNIXに移植されたりするものも登場した。
 その結果、それらのプログラムはさらに性能がアップしていった。また、GNUプロジェクトに協力する人たちや、寄付を申し出る人たちも増えていった。しかし、それはまた、最低限必要なGNUシステムの完成を何年か遅らせることにもなった。本来GNUシステムに必要な部品をどんどん開発していなければならないプログラマの時間が、移植されたプログラムのサポートや機能拡張にとられてしまったからである。


GNU HURDの開発
 一九九〇年までに、カーネル部分を除いてGNUシステムはほぼ完成した。そこで我われは、カーネルを、MACH上で動作するサーバプロセス群として実装することにした。MACHは、カーネギー・メロン大学で開発され、のにちユタ大学が開発を引き継いだマイクロカーネルである。GNUオペレーティングシステムのカーネルを形成するHURD(herd of gnus−すなわち「GNUの群」)は、MACH上で動作し、サーバプロセス群として本来UNIXカーネルの行なう様々なジョブを実行する。HURDの開発開始が遅れたのは、MACHが約束どおりにフリーソフトウェアとして配布されるのを我われが待っていたためである。
 GNUオペレーティングシステムのカーネルをサーバプロセス群として実装することにしたのは、カーネル部分のデバッグ作業をソースレベルのデバッガなしに行なうという困難な作業を避けたかったからである。我われは、このもっとも困難と思われる作業がMACHの開発者たちによってすでに行なわれていたので、HURDサーバ群をユーザプログラムとしてGNUデバッガ(GDB)でデバッグするつもりでいた。ところが、それが可能になるまでに我われは長い時間待たなければならなかった。さらに、HURDのデバッグ作業は、このカーネルが適切なサーバへメッセージを送り合うマルチスレッドなプロセス群であるところから、当初考えていたより非常に複雑なものだった。結局、HURDを安定したカーネルとして動作させるまでには数年の歳月がついやされている。


アリックス
 GNUのカーネルは、もともと、HURDではなくAlix(アリックス)と名づけられるはずだった。当時の私の恋人でUNIXシステムの管理者だったアリックスが、自分の名前は平凡なネーミングばかりのUNIXシステムバージョンにぴったりだ、と言っていた。その彼女が友達に、「誰か、カーネルに私の名前をつけてくれないかしら」と冗談のつもりで言ったとき、私は何も言わなかったが、Alixという名前のカーネルを作って彼女を驚かせてやることにしたのである。
 しかし、この一件は私の思いどおりにはいかなかった。カーネル開発の中心人物だったマイケル・ブッシュネル(現トマス)が、AlixよりHURDという名前を好んだからである。そして彼は、カーネルをAlixと呼ぶことはやめにして、システムコールをトラップしてサーバにメッセージを送るカーネル部分にAlixという名前をつけたのである。
 やがて、アリックスと私は別れ、彼女は名前を変えてしまった。それとは関係なく、HURDの仕様も、GNU Cライブラリが適切なサーバへメッセージを送るように書き換えられた。こうしてAlixはGNUカーネルからも姿を消したのである。
 しかし、一連の出来事の間に、アリックスの友達の一人が、HURDのソースコードに中にAlixという名前があるのを見つけて、そのことを彼女に話した。つまり、Alixという名前もそれなりの役割を果たしたわけである。


「Linux」 と 「Linuxを基にしたGNUシステム」
 GNU HURDはほぼ完成状態であるがまだ実践的に使えるようにはなっていない。しかし我われにとって好都合なことに、ここにLinuxと呼ばれる、リーナス・トーバルズ(Linus Torvalds)が一九九一年に開発を始めたUNIX互換のカーネルがある。一九九二年頃、Linuxカーネルと、ほぼ完成状態のGNUシステムとを統合し、完全なUNIX風フリーオペレーティングシステムとして実際に使うことが可能になった(この二つを統合すること自体が重要な仕事だったことは言うまでもない)。つまり、我われは、Linuxカーネルのおかげで、GNU/Linuxを、Linuxを基にしたGNUシステムとして使えるようになった。なお、我われが、このシステムをGNU/Linuxと名づけたのは、基本的にGNUシステムにLinuxがカーネルとして組み合わせられていることを明確にするためである。


我われの行く手を阻むもの
 我われは、様々なフリーソフトウェアの開発能力を立証してきた。しかし向かうところ敵なしというわけではない。我われは、フリーソフトウェアの将来をゆるがしかねない障害を克服し続けなければならない。それには、大切な自由を誰にも奪われまいとする確固たる意志のもとに、地道な努力を何年も忍耐強く継続していく必要がある。以下の四節で、その際、克服すべき事柄を考察してみよう。


仕様がクローズドなハードウェアの増加
 ハードウェアのメーカーは、ハードウェアの仕様を秘密にする傾向を強めている。そのために、LinuxやXFree86を新しいハードウェア上でサポートするのがだんだん難しくなっている。ハードウェアの仕様が非公開のためフリーソフトウェアのドライバの作成が難しくなっているからだ。我われは、今でこそフリーなオペレーティングシステムを持っているが、新しいコンピュータをサポートできなければ、それらもいずれは無用の長物と化してしまう。
 右記の問題についてはふたつの対処法が考えられる。リバースエンジニアリング手法でドライバを作成する方法がそのひとつ、フリーソフトウェアのドライバが使えるハードウェアを選択する方法がもうひとつの対処法である。このような対処法で実際に対抗しようと考えるユーザが増えるにつれて、ハードウェアの仕様を公開しないことはメーカーの自滅行為となるだろう。
 とはいえ、リバースエンジニアリングは大がかりな仕事である。はたして、それだけの仕事をする覚悟を持ったプログラマは現われるだろうか? この問に対する我われの答えはイエスである。フリーソフトウェアは原理・原則上の譲れぬ選択であり、商用のドライバの使用は耐えられないという強い意識が我われの間に根づくからである。また、自由でありたいという決意が一般に広まれば、多くの人たちが、少々余分に払ってでもフリードライバを買い求め、設定などに少々余計な時間をさいても、それを使おうとするだろう。多くの人たちが、フリーソフトウェアのドライバが使えるハードウェアを選択するかの問に対する答もイエスである。


独占的なライブラリ
 フリーソフトウェアを開発する際、フリーなオペレーティングシステムと一緒に独占的ライブラリを使用することは、一種の罠にはまるようなものである。このようなライブラリにはいろいろな機能が提供されているが、それは獲物をおびきよせるための餌であり、その魅力に引かれてそのようなものを使う人間は、罠にはまったことになる。独占的なライブラリを使って開発されたプログラムは、フリーオペレーティングシステムに貢献できないからだ(厳密に言えば、そのようなプログラムもフリーオペレーティングシステムに組み入れられるが、独占的なライブラリ抜きには「作動」しない)。それどころか、そのようなライブラリを使ったプログラムが普及すれば、他のプログラマたちを同じ罠に陥れる危険性がある。
 この問題の最初の事例は、一九八〇年代の(UNIXの独占的GUIである)Motifツールキットである。当時、フリーオペレーティングシステムはまだ存在しなかった。しかし、これから登場するであろうフリーオペレーティングシステムに対して、Motifが問題をつきつけるであろうことは容易に想像された。そのため、GNUプロジェクトでは、フリーソフトウェアを開発していた人たちに対して、MotifとXツールキットの両方をサポートするよう求めるとともに、Motifの代替版をフリーソフトウェアとして開発してくれる人を探しはじめた。やがて、数年がかりで、Motif互換ライブラリのLessTifが「Hungry Programmers」グループによって開発され、一九九七年にになると、Motifアプリケーションのほとんどをサポートできるようになった。
 ちょうどその頃、トロール(Troll Tech)社のQtGUIツールキットが人気になりだしたが、(制限された配布条項がついている)Qtはとてもフリーソフトウェアと呼べるものではなかった。しかし、ほとんどフリーソフトウェアの組み合わせで作られたデスクトップ環境構築ツールのKDEもこの独占的ライブラリを使っていた。
 独占的ライブラリのQtをそのまま含んでいるKDEは、完全なフリーソフトウェアではなく、そのため我われは、KDEをGNU/Linuxシステムで使うことができなかった。ところが、GNU/Linuxシステムを配布していた人たちの中にはGNUプロジェクトの理想を厳密に守ろうとしない人たちがいて、本当の意味でフリーでないKDEを彼らのソフトウェアパッケージに含めてGNU/Linuxシステムを配布するようになってしまった。その結果、パッケージのユーザは、デスクトップ環境を構築する機能を手に入れたものの、ユーザとしての自由は拘束されてしまった。しかし、KDEグループや、KDEを自分のプログラムに用いていた人たちは、他のプログラマたちにも、アプリケーションの開発にQtライブラリを使うように積極的に働きかけた。しかも、何百万人というLinuxの新規ユーザは、QtライブラリとKDEにまつわる詳しい事情を知らされないまま、そのような働きかけを受けていたので、KDEを使用することに問題があるとさえ思っていなかった。
 この状況に対してGNUプロジェクトは、ふたつの方法で対応することにした。つまり、(完全にフリーな統合デスクトップ環境を作ろうという)GNOMEプロジェクトと、(完全にフリーなQtライブラリ互換のライブラリを作ろうという)ハーモニー・プロジェクトの開始を決めたのである。
 GNOMEは、GNU Network Object Model Environmentの略称であり、ユーザフレンドリーな統合デスクトップ環境をGNUソフトウェアとして開発しようという計画である。この開発は、一九九七年にミゲル・デ・イカザ(Miguel de Icaza)が着手し、レッドハット・ソフトウェア社の協力を得て推進されてきた。GNOMEは、KDEと同様の機能を備えているが、(WQtのような)独占的ソフトは一切使われていない。つまり、完全なフリーソフトウェアである。(開発言語にC++を使用するQtライブラリと違って)GNOMEは、C++以外にも様々な開発言語をサポートしている。しかし、我われがGNOMEプロジェクトを推進している主たる目的は、独占的ソフトウェアを使わなくても、やりたいことのできる自由を獲得するためである。
 ハーモニー・プロジェクトの目的は、Qtライブラリ互換のライブラリを代替版フリーソフトウェアとして開発し、独占的ライブラリのQtを使わなくても、GNU/Linuxシステム上でKDEを利用できるようにすることにある。
 ちなみに、Qtの開発元であるトロール(Troll Tech)社は、一九九八年十一月に、それまでの制限的なライセンス条項を変更すると発表した。この約束がちゃんと実行されれば、Qtはフリーソフトウェアになるはずである。独占的ソフトのQtが巻き起こした問題にコミュニティが毅然と立ち向かったことが、同社にそのような方向転換させた原因のひとつと私は考えているが、これを確かめるすべはない(なお、新しいライセンス形態は不自由かつ不公正なものなので、Qtを使わないで済ませられるならば、依然としてそれに越したことはない)。
 思うに、次なる魅力的な独占的ライブラリが登場したとき、フリーソフトウェアのコミュニティはどう反応するのだろうか? 餌につられて罠にはまらないようにすることの重要性が理解されればいいが、大勢の人たちが利便性とひきかえに自由を捨ててしまい、新たなる深刻な事態を引き起こすことも考えられる。フリーソフトウェアのコミュニティがどう反応するかは、我われがどのような理念を掲げ続けるかによって決まるのである。


フリーソフトウェアと特許について
 様々なアルゴリズムと機能をフリーソフトウェアに応用することを二十年にわたって禁止できる特許権は、まさに我われの前に立ちはだかる最大の脅威である。たとえば、LZW(Lempel, Ziv, and Welch)データ圧縮アルゴリズムが一九八三年に特許申請されてしまったために、我われはいまだにGIF圧縮が可能なフリーソフトウェアをリリースすることができないでいる。また、一九九八年には、MP3形式でオーディオデータを圧縮できるフリープログラムが、特許権訴訟の脅威によって非公開にされてしまった。
 特許権に対抗する手段がないわけではない。我われは、特許権が無効である証拠を探し出すこともできるし、別の開発方法を模索することもできるからだ。しかし、これらの方法が常に功を奏するわけではない。そして、どちらもうまくいかなければ、我われは、ソフトウェアの特許権者の主張に従い、ユーザが求めるであろう機能をフリーソフトウェアから取り除かなければならない。そうなったとき、我われには何ができるだろうか?
 だが、もしそうなったとしても、自由という目的のためにフリーソフトウェアを尊重する我われは、あくまでもフリーソフトウェアを使い続ける人たちの側に立ち続け、特許権で保護された機能を使わずに事を成就する方法を見つけだすだろう。しかし、フリーソフトウェアの評価を技術的な優位を基準に考える人たちは、特許権に行く手を阻まれたフリーソフトウェアを失敗作と呼ぶ可能性がある。つまり、「伽藍(cathedral)形式」の開発モデルの実効性について語るのも、フリーソフトウェアの信頼性と性能について語るのもよいが、それだけでは不十分なのである。我われが真に語るべきは、我われの自由と原則なのである。


フリーソフトウェアのマニュアルについて
 我われのフリーオペレーティングシステムの最大の欠陥は、ソフトウェアにあるのではなく、良質なフリーマニュアルが不足していることにある。マニュアルは、ソフトウェアに欠かせない。重要なフリーソフトウェアと一緒に良質でわかりやすいマニュアルを配布できなければ、ソフトウェアとマニュアルの質が不均一になってしまう。現在のところ、このような問題はいたるところに見られる。
 フリーマニュアルの“free”の意味は、フリーソフトウェアの場合と同じである。それは、「足かせをはめられることなく自由にできる」という意味であって、金銭的な意味ではない。フリーマニュアルの基準も、フリーソフトウェアのそれと同じである。フリーマニュアルは、ユーザが(商用目的も含めて)自由に再配布できるものである。再配布は、マニュアルがプログラムのコピーにもれなく添付されるようにすることを考えると、印刷物としてだけでなくオンラインマニュアルとしても許されなければならない。
 フリーマニュアルはユーザが修正・変更できるものでなければならない。とはいえ、私が、原則として、あらゆる種類の論文や書籍の修正許可を人びとに与えべきだと思っているわけではない。たとえば、本章には我われの活動や考え方が述べられているが、このような論文の修正許可を、あなたや私が与える必要はないと思う。
 しかし、フリーソフトウェア用のマニュアルに修正の自由は欠かせない。それには特別な理由がある。マニュアルに修正の自由があれば、フリーソフトウェアを拡張したり機能追加するプログラマが、修正後の仕様に合うように、マニュアルの記述を良心的に書き換えることができる。そうすることで、修正後のプログラムと一緒に正確で便利なマニュアルを提供することができる。プログラマが良心的になって仕事をやりとげる自由がないマニュアルは、我われが属するコミュニティのニーズを満たすものではない。
 マニュアルの活用を妨害するものでない限り、修正方法に何らかの制限を設けることも問題でない。たとえば、原作者の著作権情報や配布条件、作者リストを保存しなければならないという制限を配布条項に盛り込むことは当然のことである。また、修正版に修正済みの断わり書きを入れるとする制限や、技術的でない部分の記述に限って削除または変更できないとする制限を盛り込むことにも不都合はない。このような制限は、プログラムを変更した人が自分の良心に従ってマニュアルを書き換えることを阻止するものではないからである。つまり、フリーソフトウェアのコミュニティによるマニュアルの活用を妨害するものではない制限を問題にする必要はない。
 ただし、マニュアルの中で、プログラムの技術的内容について書かれている部分は修正できるようになっていなければならない。修正後のマニュアルは、あらゆるルートを通じてあらゆる媒体で配布できるようになっていなければならない。これらを制限する配布条件は、フリーソフトウェアのコミュニティの活動を阻害する。そのような条項つきのマニュアルはフリーではない。そのようなマニュアルが登場したら、我われは新しいマニュアルを再度作成しなければならない。
 フリーソフトウェアの開発者たちは、自覚と決意を持って多岐にわたるフリーマニュアルを作るようになるだろうか。この答も、どのような理念を我われが掲げ続けるかによって決まるのである。


より広くのユーザに向かって自由について語る必要がある
 現在、GNU/Linuxシステムは、Debian GNU/LinuxやRed Hat Linuxなども含めて、推計一千万人にのぼるユーザによって利用されている。フリーソフトウェアが実践面で非常に強力になってきたので、実用的な動機でフリーソフトウェアを利用する人たちが増えてきている。
 これによって好ましい結果がもたらされていることは誰の目にも明らかである。フリーソフトウェアの開発に対する関心は高まりつつある。フリーソフトウェアビジネスの顧客も増加している。ソフトウェアの開発メーカーに向かって、所有権によって保護されたクローズドな製品を開発するのでなく、フリーソフトウェアの製品を開発するように求めることも、以前よりしやすくなった。
 しかし、フリーソフトウェアへの関心の急速な高まりは、それを支える理念を知ることが後回しになっている。そして、それを放置しておくことは問題である。というのも、前述のような障害や脅威に対抗できるかどうかは、自由のために断固として戦おうとする我われの意志にかかっているからである。我われのコミュニティにこの意志を持たせるためには、コミュニティに参加してくる新しいユーザたちにこの理念を広めなければならない。
 しかし、現在のところ、この仕事は成功していない。我われは、新しいユーザをコミュニティに引き入れようとしているが、その努力に比較して、彼らにコミュニティの倫理を教えようとする努力はあまりしていない。我われは、バランスを保ちながら、両方を実行しなければならない。


「オープンソース」という用語について
 一九九八年は、新しいユーザに対して、「ユーザの自由」について説くことが以前にもまして難しくなった年である。この年、コミュニティの一部が、それまで使われていた「フリーソフトウェア」という用語の使用をやめ、代わりに「オープンソースソフトウェア」という言葉を使うことを決定したからである。
「フリー」と「無料」の混同を避けるためにこの表現の使用を支持する者もいた。しかし、中には、そういう正当な目的のためではなく、フリーソフトウェア運動の発展やGNUプロジェクトを牽引してきた原理原則を退け、ユーザコミュニティよりも利益重視の人が多い経営者層やビジネスユーザ層の関心を引くことをねらって、新しい表現を支持した者もいる。その結果、「オープンソース」という言い方は、高性能なソフトウェア作りの潜在的な可能性に焦点を合わせたものとなる一方、自由、コミュニティ、原理原則といった我われの基本とするものを意図的に遠ざけることとなった。
タイトルに“Linux”を冠している雑誌は、こうした状況を如実に物語っている。このような雑誌は、GNU/Linux上で動作する商用ソフトウェアの広告で埋めつくされているが、MotifやQtのような問題をはらんだソフトウェアが再び登場したとき、それらの雑誌は、そんなものに手を出すなと言ってプログラマに警告を発するのだろうか? それとも、それらの製品の広告を掲載するのだろうか。
 業界の力を借りれば、ユーザコミュニティは様々な恩恵に浴することができるので、そのことだけで判断すれば、業界の力を借りることはいいことである。しかし、彼らの支援を得るために、自由や正義についてひかえめに語ることは、悲惨な結果につながりかねない。そんなことをすれば、ユーザの獲得とコミュニティ倫理の普及のギャップがさらに拡張されてしまう。
「フリーソフトウェア」と「オープンソース」は、同じ範疇のソフトウェアを表わす言葉であるが、ソフトウェアとは何かということや倫理的価値観については同じことを語っていない。それゆれ、GNUプロジェクトでは、引き続き「フリーソフトウェア」という用語を使い、重要なのは技術ではなく自由であるという思想を表現していく。


ひたすらトライあるのみ
ヨーダの、「トライしようと思うな」という教えは言い得て妙だが、私には通用しない。私は、自分にできるのだろうかと不安になったり、目標を達成できるのだろうかと迷いながら、どうにか仕事をこなしてきた。しかし、自陣と敵陣の間に立つ人間は自分をおいて他にいなかったから、とにもかくにもトライしてきたのは事実である。そして、これは自分でも意外なのだが、時には勝利することもあった。
 もちろん時には敗北し、いくつかの陣地を失ったこともある。しかし私は、脅威にさらされている陣地を新たに見つけ、また戦いの準備をととのえていった。私はやがて、脅威となる相手を探すようになり、彼らと自陣の間に身を置いて、私と一緒に戦うことを真のプログラマたちに呼びかけるようになった。
 そして近頃では、孤軍奮闘しないですむことも多くなっている。今では、多くの仲間たちが塹壕を掘って陣形を維持してくれている。私は、それを見ると、我われの陣営がさしあたって無事であることを実感し、ほっとすると同時にうれしい気持ちになる。しかし、危険は年ごとに増大している。今では、マイクロソフトがあからさまに我われのコミュニティを標的にしている。自由がこれからも手元にあると思ってはならない。当然の権利だと思って軽視してはならない。自由を手放したくなければ、あなたはそれを守る覚悟を固めなければならない。