1971年に MIT 人工知能研究所(AIラボ)で働き始めたとき、私は長年にわたって存在してきたソフトウェア共有コミュニティの一員になった。ソフトウェアの共有は、別に私たちのコミュニティのみに限定されていたわけではない。レシピの共有が料理と同じだけの歴史を持つのと同じように、コンピュータと同じだけの歴史を持っていた。しかし、私たちの共有の進め方は、他のコミュニティ以上だったと言ってよいだろう。
AIラボは、スタッフのハッカーたちが設計し、Digital PDP-10 (当時のメジャーなコンピュータの1つ)のアセンブリ言語で書いた、ITS (Incompatible TimesharingSystem: 互換性のないTSS)と呼ばれるタイムシェアリングオペレーティングシステムを使っていた。このコミュニティの一員として、またAIラボスタッフのシステムハッカーとしての私の仕事は、このシステムを改良することだった。
私たちは自分たちのソフトウェアを「フリーソフトウェア」とは呼んでいなかったが、それはまだその用語が存在していなかったからで、このソフトウェアはまさにフリーソフトウェアだった。ほかの大学や企業の人たちがプログラムを移植、利用することを望めば、私たちは喜んでそれを認めた。誰かが見慣れない面白そうなプログラムを使っていたら、いつでもソースコードを見せてくれと頼むことができた。そうすれば、それを読み、書き換えることができるし、一部を引っこ抜いて新しいプログラムを書くことができる。
「ハッカー」という用語を「セキュリティ破壊者」の意味で使うのは、マスメディアの誤解である。私たちハッカーは、そのような意味付けを拒否し、「プログラムを書くことを愛し、そのための工夫を楽しむ人々」という意味でハッカーという単語を使い続ける。*1
1980年代初めにAIラボハッカーコミュニティが崩壊し、PDP-10コンピュータが製造中止になると、状況は一変した。
1981年に、Symbolics という AI ラボ出身者によって設立された企業がAIラボのほぼすべてのハッカーを雇い入れ、メンバーを失ったコミュニティは、自らを維持することができなくなった (Steven Levy, "Hackers", Dell, 1985:邦訳「ハッカーズ」工学社、1987年)は、AIラボコミュニティの最盛時の姿をくっきりと描くとともに、この間の経緯を明らかにしている)。AIラボが1982年に新しいPDP-10を購入したとき、管理者は、ITSではなく、Digital のフリーではないタイムシェアリングシステムを新マシンに導入することを決めた。
それからまもなく、Digitalは、PDP-10 シリーズの製造を中止した。PDP-10のアーキテクチャは、60年代にはエレガントで強力だったが、80年代に実用化されたより広いアドレス空間に合わせて自然に拡張することは不可能だった。つまり、ITSを構成するほぼすべてのプログラムが時代遅れになったということである。ITSにとっては、これが命取りになった。15年の仕事が水の泡となったのである。
VAX や 68020などの当時の最新コンピュータは、それぞれのオペレーティングシステムを持っていたが、それらはどれ1つとしてフリーソフトウェアではなかった。実行可能コードを入手するだけのためにも、NDA (nondisclosure agreement:非開示契約)を結ばなければならなかった。
つまり、コンピュータを使うときの第一歩が、隣人を助けないということを約束することだったのである。協力し合うコミュニティは禁止された。私有ソフトウェアの所有者が作った規則は、「隣人と共有したら、あなたは著作権侵害者である。変更を希望するなら、私たちにそうしてくれるよう懇願せよ」というものだった。
私有*2ソフトウェア制度(ユーザーにソフトウェアの共有や変更を認めない制度)が反社会的で、非倫理的で、単純に間違っているという思想は、一部の読者には驚きかもしれない。しかし、一般の人々を分断し、ユーザーを無援の状態に放置することを基礎とする制度に対して、ほかに何と言うことができるだろうか。私の考え方に驚いた読者は、この私有ソフトウェア制度を当然のものと考えているか、私有ソフトウェア企業が提示している約款を判断基準にしていのだろう。ソフトウェア企業は、この問題に対する考え方は1つしかないと人々が思い込むように、古くから精力的に活動してきている。
ソフトウェア企業がそれぞれの「権利」を「強制する」とか「海賊版の流通を防止する」と言うとき、彼らが実際に「言っている」ことは副次的なことである。これらの言明の本当のメッセージは、彼らが当然と考えている実際には書かれていない仮定にある。一般の人々は、それを無批判的に受け入れるものと考えられているのである。では、それらの仮定について考えてみよう。
1つ目の仮定は、ソフトウェア企業がソフトウェアを所有する疑問の余地のない自然権を持っており、すべてのユーザーにその権力を行使できるということである(もしこれが自然権なら、公共のためにいかに有害であっても、私たちはそれに反対することはできないところである)。興味深いことに、合衆国憲法と法律への伝統は、この考え方を付けている。つまり、著作権は自然権ではなく、政策的に設けられた人為的な独占権であって、コピーをするというユーザーの自然権に制約を課するものなのだ。
もう1つの書かれていない仮定は、ソフトウェアで重要なことは、それによってどのような仕事ができるようになるかだけだということである。コンピュータユーザーは、どのような社会を持つことを認められているかということについて考えてはならないものとされている。
第3の仮定は、企業にユーザーへの支配権を差し出さなければ、使えるソフトウェア(あるいは、あれこれの特定の仕事をするプログラム)は作られないというものである。この仮定は、フリーソフトウェア運動が、ユーザーを縛らずに大量の役に立つソフトウェアを提供できることを実証するまで、もっともらしく見えていたかもしれない。
私たちがこれらの仮定を鵜呑みにすることなく、ユーザーを第一に考えながら、通常の常識的な倫理に基づいてこれらの問題を判断するなら、まったく異なる結論に達する。コンピュータユーザーは、それぞれのニーズに合わせてプログラムを書き換える自由やソフトウェアを共有する自由を持たなければならない。なぜなら、他人を助けることは、社会の基礎だからである。
コミュニティが消えてから、以前と同じように生きることは不可能になった。私は倫理的に厳しい選択を迫られた。
簡単な選択肢は、NDAに署名し、仲間のハッカーを助けないことを約束して、私有ソフトウェアの世界に入ることだった。その場合、おそらくNDAのもとでリリースされるソフトウェアを開発し、他人にも仲間に対する裏切りを迫ることになるだろう。
こういうやり方でも、稼ぐことはできただろうし、コードを書くことを楽しむこともおそらくできただろう。しかし、生涯を終えようとするときに、人々を分断する壁を築くために過ごしてきた年月を振り返り、世界を悪くするために人生を費やしてきたのかと感じるだろうことはわかっていた。
私はすでにNDA を押し付けられる側になることは経験していた。それは、私とAIラボがある人物にプリンタ制御プログラムのソースコードの提供を拒否されたときのことである(このプログラムがある機能を持っていないがために、このプリンタを使うのはとてもイライラすることだった)。そのため、私はNDAを罪のないものだとはとても思えなかったのである。私は、彼がソースコードの共有を拒否したときに非常に怒った。逆の立場になって、他のすべての人たちに対して同じことをすることは不可能だった。
簡単だが面白くない選択肢として、コンピュータの世界から離れるというものもあった。そうすれば、私の技能が悪用されることはないが、無駄になることに変わりはなかった。私自身はコンピュータユーザーを分断し、制約を押し付ける罪を免れることができるが、同じ問題は間違いなく発生する。
そこで、私は、プログラマが善に貢献するための道を探した。コミュニティを復活させるために書けるプログラムはないか、自問自答した。
答えははっきりしていた。まず最初に必要なものは、オペレーティングシステムだった。オペレーティングシステムがあればさまざまなことができるが、なければコンピュータを動かすことさえままならない。フリーオペレーティングシステムがあれば、協力し合うハッカーたちのコミュニティを再び築くことができるだろう。コミュニティに加わるように誘うこともできるだろう。そして、まず友達をなくすことを強いられずに、誰もがコンピュータを自由に使えるようになるはずだ。
私は、オペレーティングシステム開発者として、この仕事をするための適切な技能を持っていた。成功を当然のこととして見込むことはできないものの、私は自分がこの仕事をするために選ばれた者だと確信した。私は、Unix 互換システムを作ることにした。そうすれば、移植性を確保できるし、Unix ユーザーが簡単に移って来れる。GNUという名前は、ハッカーの伝統に従い、“GNU's Not Unix"という再帰的な(入れ子状の) 頭字語として選ばれたものである。
オペレーティングシステムとは、単なるカーネルのことではない。他のプログラムを動かせれば充分というわけではないのだ。1970年代、オペレーティングシステムの名に値するシステムは、コマンドプロセッサ、アセンブラ、コンパイラ、インタープリタ、デバッガ、テキストエディタ、メーラなどのプログラムを含んでいた。ITS然り、Multics然り、VMS然り、Unix然り。GNU オペレーティングシステムも、それらを持つものにしよう。
その後、私はヒレル*3のものだとされる次の言葉を聞いた。
「私が自分のために動かなければ、誰が私のために動いてくれるというのだ。私が私だけのために動くのだとすれば、私は一体何者なのだ。今やらなければ、いつやる?」
GNU プロジェクトを立ち上げることにしたのも、同じような考え方からだった。私は無神論者なので、宗教界の指導者には従わないが、彼らの中の誰かが言ったことを尊敬することはある。
「フリーソフトウェア」という用語は、誤解されることがある。価格とは無関係だ。フリーとは自由のことである。そこで、フリーソフトウェアの定義を下しておくことにしよう。以下の条件を満たすプログラムは、そのユーザーにとって、フリーソフトウェアである。
「フリー」が価格のことではなく、自由であることを意味しているので、コピーを売ることとフリーソフトウェアであることの間には何らの矛盾もない。実際、コピーを販売する自由は、非常に重要である。CD-ROM化されたフリーソフトウェアのコレクションはコミュニティにとって重要であり、それを販売することは、フリーソフトウェアの開発資金を稼ぐための重要な手段である。そのため、このようなコレクションに自由に組み込めないプログラムは、フリーソフトウェアではない。
「フリー」という用語は曖昧なので、人々はずっと代わりになる言葉を探してきたが、適切なものを見つけた人はまだいない。英語は他の言語よりも多くの単語とニュアンスを持っているが、自由としての「フリー」を意味する単純で曖昧さのない単語を持っていない。もっとも近い意味を持つ単語は、「unfettered」である。「liberated」、「freedom」、「open」などの言葉は、誤った意味を兼ね備えていたり、他の欠点を持っていたりする。
システム全体を開発するのは、非常に大規模なプロジェクトである。目標を手が届くところに置くために、私は可能な限り既存のフリーソフトウェアを利用、修正することにした。たとえば、私はごく初期の段階で、テキストフォーマッタとして主に TEX を使うことにした。数年後、GNUのために新しいウィンドウシステムを書く代わりに、X Window System を使うことにした。
このような決定のために、GNU システムとすべてのGNU ソフトウェアのコレクションは同じではない。GNU システムには、GNUソフトウェアではないプログラム、他の人々や他のプロジェクトがそれぞれの目的のために開発したプログラムが含まれている。しかし、それらはフリーソフトウェアなので、私たちはそれを使うことができるのだ。
私は、1984年1月にMITの仕事を辞め、GNU ソフトウェアの開発を開始した。MIT がフリーソフトウェアとしてのGNUの頒布に干渉できないようにするために、MITを辞めることは必要だった。私がスタッフとして残っていたら、MIT は私の仕事の所有権を主張したり、独自の頒布条件を課したり、私の仕事を私有ソフトウェアパッケージに化けさせたりすることさえできていただろう。新しいソフトウェアコミュニティの創出という当初の目的にまったく添わない結果を招くために、大仕事をするつもりはなかった。
もっとも、ウィンストン教授(当時のMIT AIラボ所長)は、ラボの設備をそのまま使えるようにはからってくれた。
GNU プロジェクトを立ち上げる直前に、私は Free University Compiler Kit別名 VUCK(オランダ語の「フリー」は、Vから始まる)というものの話を聞いた。これは、CやPascalなど、複数の言語を処理し、複数のターゲットマシンをサポートするコンパイラだった。私はGNUでそれを使えるかどうかを尋ねるために、作者に手紙を書いた。
返事は嘲笑的なものだった。大学はフリー(自由)だが、コンパイラは違う(フリーコンパイラではない)というのである。そこで、GNU プロジェクトの最初のプログラムは、マルチ言語マルチプラットフォームコンパイラにすることにした。
コンパイラ全体を自分で書かなくても済むとよいと思い、私はローレンスリバーモア研究所で開発されたマルチプラットフォームコンパイラ、Pastel のソースコードを入手した。Pastelは、システムプログラミング言語になるように Pascal を拡張した言語で書かれており、その拡張 Pascal をサポートしていた。私は、C7ロントエンドを追加し、Motorola 68000 コンピュータへの移植作業を開始した。しかし、このコンパイラが何Mバイトものスタック領域を必要とするのに対し、68000の Unix システムが64K バイトのスタック領域しか認めていないことを知り、移植を諦めなければならなかった。
その後、Pastel コンパイラは、入力ファイル全体を走査して構文木を構築し、構文木全体を「命令」のチェインに変換し、出力ファイル全体を生成しており、その間、メモリを一切解放していないことがわかった。これがわかった時点で、私は0から新しいコンパイラを書かなければならないという結論に達した。その新コンパイラは、今、GCCと呼ばれているものである。Pastel コンパイラのコードは一切使われていないが、自分で書いたCフロントエンドは何とか修正して活用した。しかし、その仕事に取り掛かったのは、数年後のことである。まず、私はGNU Emacs を書いた。
私は1984年9月にGNU Emacs の仕事を始めた。そして、1985年始めには、使えるものになり始めていた。これで、私は Unix システムを使って編集の仕事をできるようになった。私は、viやedの使い方を学ぶ気にはなれなかったので、そのときまでは Unix 以外のマシンで編集をしていたのである。
この頃から、人々は GNU Emacs を使いたがるようになったが、そのことは、ソフトウェアをどのように流通させるかという問題を引き起こした。もちろん、自分が使っていたMITのコンピュータの anonymous FTP サーバから入手できるようにはした(そのため、このコンピュータ、prep.ai.mit.edu GNUのメインftpサイトになった。数年後、このマシンが廃棄処分になったときには、新しい ftpサーバに同じ名前を移した)。しかし、その当時、GNUに関心を持つ人々の多くは Internet に接続しておらず、ftpではコピーを入手できなかった。そこで、そのような人々にどう言ったらよいかが問題になった。
「Internet に接続できてコピーを作れる友達を探してください」と言ってもよかったし、オリジナルのPDP-10 Emacs のときと同じように「私にテープと SASE(切手を貼った返信用封筒)を郵送していただければ、Emacs をコピーして送り返します」と言ってもよかった。しかし、私は無職だったし、フリーソフトウェアで稼ぐ方法を探していた。そこで、私は、150ドルで希望者全員にテープを郵送すると発表した。このようにして私はフリーソフトウェア流通ビジネスを始め、現在、Linux ベースの GNU システムを販売している企業の先駆者になったのである。
作者の手を離れたときにフリーソフトウェアであったとしても、そのプログラムは、コピーを持っているすべての人々にとってフリーソフトウェアであるとは限らない。たとえば、PDS(パブリックドメインソフトウェア、すなわち著作権が放棄されているソフトウェア)はフリーソフトウェアだが、誰もがそれに変更を加えた私有バージョンを作ることができる。同様に、多くのフリープログラムは、著作権を放棄してはいないものの、変更が加えられた私有バージョンを認めるような単純で寛大なライセンスのもとで流通されている。
この問題を非常によく示している例がX Window System である。MIT で開発され、寛大なライセンスのもとでフリーソフトウェアとしてリリースされた XWindow は、すぐにさまざまなコンピュータメーカーに採用された。これらの企業は、私有している Unix システムにバイナリ形式のみでXを追加し、同じNDAを適用した。これらのXは、Unixと同様にフリーソフトウェアではなくなってしまったのである。
X Window System の開発者たちは、これを問題だとは考えなかった。むしろ、こうなることを予想し、意図していたのである。彼らの目標は自由ではなく、「多くのユーザーの獲得」と定義される「成功」だった。彼らは、ユーザーが自由を持つかどうかに注意を払わなかった。ユーザーを増やすことしか考えていなかったのである。
これは、ずいぶん逆説的な話である。自由の量を計る方法が2通りあり、「このプログラムはフリーか」という問いに対してそれらが異なる答えを出しているのである。MIT リリースの頒布条件が与える自由に基づいて判断するなら、Xはフリーソフトウェアだったと言える。しかし、Xの平均的なユーザーの自由度を計るなら、Xは私有ソフトウェアだと言わなければならない。ほとんどのXユーザーは、フリーバージョンではなく、Unix システムに付属している私有バージョンを実行していたのである。
GNU の目標は、単にポピュラーになることではなく、ユーザーに自由を与えることだった。そこで、私たちは、GNUソフトウェアが私有ソフトウェアに化けるのを防ぐ頒布条件を必要としていた。そして、私たちが今使っている方法は、コピーレフト(copyleft) というものである。
コピーレフトは著作権 (copyright) 法を利用しているが、通常とは逆の目的に奉仕するように、逆立ちさせた使い方をしている。著作権法は、ソフトウェアを私有化するための手段ではなく、ソフトウェアの自由を守る手段になったのである。
コピーレフトという考え方の中心は、プログラムを実行し、プログラムをコピーし、プログラムを書き換え、書き換えられたバージョンを流通させることをすべての人に認める一方で、独自の制限事項の追加を禁止することにある。つまり、「フリーソフトウェア」がよって立つ由縁であるところの自由が、コピーを持つすべての人に対して保証される。自由は、絶対に奪うことのできない権利になったのである。
コピーレフトの効力を保つためには、書き換えられたバージョンもフリーでなければならない。こうすれば、私たちのコミュニティは、私たちの仕事を基礎とする仕事が公表されたときに、必ずその仕事を利用できる。プログラマとしての仕事を持つプログラマがボランティアでGNU ソフトウェアを改良したときに、その雇い主が「君が加えた変更は、プログラムの私有バージョンを作るためにうちの会社で使うつもりだから、共有に付するわけにはいかない」などと言えないようにするのがコピーレフトである。
プログラムのすべてのユーザーに対して自由を保証したければ、変更点もフリーにするよう要求することは非常に重要である。X Window System を私有化した企業は、通常、それぞれのシステムやハードウェアに X Window System を移植するために、何らかの変更を加えている。これらの変更点は、Xの規模の大きさから比べればごく少量だが、ごくわずかというわけでもない。変更を加えたことが、ユーザーの自由を否定する言い訳になるのであれば、誰もがその言い訳を利用するようになるだろう。
フリープログラムとフリーではないコードを結合するときにも、同様の問題が発生する。そのような結合は、確実にフリーではないコードを作るだろう。フリーではない部分で欠けている自由は、全体として欠けている自由でもある。そのような結合を認めれば、船を沈めるに足る穴を開けることになるだろう。コピーレフトは、絶対にこの穴を塞ぐ必要がある。コピーレフトの対象プログラムに何かを追加、結合した場合、結合後の大きなバージョンもまた、フリーでコピーレフトの対象になっていなければならない。
私たちがほとんどのGNU ソフトウェアのために使っているコピーレフトの具体的な条文は、GNU一般公開使用許諾書(GNU GPL)である。私たちは、特定の状況で使われる別の種類のコピーレフトも持っている。たとえば、GNU マニュアルもコピーレフトの対象だが、マニュアルにはGNU GPL の複雑さは不要なので、ずっと単純な種類のコピーレフトを使っている。
1984年か85年のことだが、ドン・ホプキンス(非常に想像力豊かな人物)が私に手紙を送ってきた。その封筒には、いくつかの面白いことが書かれていたが、「Copyleft--all rights reversed.」(コピーレフト――すべての権利が逆になっている)というのもその1つだった。私は、このコピーレフトという言葉を当時構想していた流通概念の名前として使うことにした。
Emacs を使うことに対する関心が高まるにつれて、GNU プロジェクトには、私以外の人々が関わるようになってきた。そこで、私たちは再び資金集めを追求すべきだと考え、1985年にフリーソフトウェア開発のための非課税慈善団体として、フリーソフトウェア財団 (FSF)を設立した。FSFは、Emacs のテーブ頒布ビジネスも引き継ぎ、その後、テープに他のフリーソフトウェア(GNU および非GNU)を追加し、フリーマニュアルの販売も開始して、事業を拡大した。
FSF は寄付も受け付けているが、その収入の大半は、フリーソフトウェアのコピーや他の関連サービスの販売から得ている。現在、FSFはソースコードのCD-ROM、バイナリを収めたCD-ROM、美しく印刷されたマニュアル(どれも、再頒布、変更の自由を伴う)、およびデラックスディストリビューション(顧客が選んだプラットフォームのためにソフトウェアの全コレクションを構築する)を販売している。
FSFのスタッフは、たくさんのGNUソフトウェアパッケージを開発し、保守してきた。特筆すべきは、Cライブラリとシェルである。GNUCライブラリは、GNU/Linux システムで動作するすべてのプログラムがLinux とやり取りするために使っているものである。このライブラリは、FSFのスタッフ、ローランド・マクグラスによって開発された。ほとんどの GNU/Linux システムで使われているシェルは BASH (Bourne Again Shell)だが、これはFSFのスタッフであるプライアン・フォックスによって開発された。
私たちがこれらのプログラムの開発に資金提供したのは、GNU プロジェクトが単なるツールや開発環境ではないからである。私たちの目標は、完全なオペレーティングシステムを作ることであり、これらのプログラムはその日標のために必要だったのだ。
Bourne Again Shell は、Unixで通常に使われている Bourne Shell というシェルの名前を借りたジョークである。
フリーソフトウェアの哲学は、広く普及しているビジネスのある特定の形態に反対するが、ビジネスそのものに反対するわけではない。ビジネスがユーザーの自由を尊重するとき、私たちはそのビジネスの成功を望む。
Emacs のコピーの販売は、フリーソフトウェアビジネスの1つの形態を実証するものである。FSFがその事業を引き継いだとき、私は生計を立てるための別の手段を見つけなければならなくなった。そして、私が開発したフリーソフトウェアに関連したサービスの販売を思いついた。たとえば、GNU Emacs のプログラム方法やGCCのカスタマイズ方法といったテーマについて教えることやソフトウェア開発である。ちなみに、ソフトウェア開発のほとんどはGCCの新ブラットフォームへの移植だった。
今日、これらのフリーソフトウェアビジネスは、数社によって展開されている。CD-ROMでフリーソフトウェアコレクションを販売する企業、ユーザーの質問への回答から、バグフィックス、大きな新機能の開発に至るまでのサポートサービスを販売する企業がある。新しいフリーソフトウェア製品の開発を事業の軸に据えるフリーソフトウェア企業さえ生まれ始めている。
しかし、注意していただきたい。「オープンソース」という言葉を掲げているいくつかの企業は、実際には、フリーソフトウェアと併用される非フリーソフトウェアに事業の基礎を置いている。これらは、フリーソフトウェア会社ではなく、ユーザーを自由から引き離そうとする製品を作っている私有ソフトウェア会社である。彼らはそれを「付加価値」と称するが、それは彼らが私たちに受け入れさせようとする価値にほかならない。つまり、自由よりも便宜性を高く評価する価値観である。自由により高い価値を認めるなら、そのようなものは「自由を抜き取った」製品と呼ぶべきだろう。
GNUの第1の目標は、フリーソフトウェアになることだった。GNUがLinuxと比べて技術的に優れていなかったとしても、ユーザーの協力を認めるという社会的なメリット、ユーザーの自由を尊重するという倫理的なメリットはある。
しかし、標準として認められている優れた作業習慣に従うのは当然のことである。たとえば、適当にサイズの上限を決めるのではなく、動的にデータ構造を確保するとか、意味がある場合には、すべての8ビットコードを処理するといったことである。
さらに、私たちは16ビットマシンをサポートしないことにして(GNU システムが完成する頃には、32ビットマシンが標準になることは明らかだったので)、Unix の小さなメモリサイズに対するこだわりを捨てた。また、1Mバイトを超えない限り、メモリの利用を抑制しようとはしなかった。非常に大きなファイルを処理することがそれほど重視されないプログラムでは、入力ファイル全体をメモリに読み込み、入出力の心配をせずにその内容を走査することをプログラマたちに勧めた。
これらの決定により、多くのGNU プログラムは、信頼性とスピードの面で Unixの同等のプログラムよりも優れたものになった。
GNU プロジェクトの評価が上がってくるにつれて、プロジェクトには Unix マシンが寄付されるようになってきた。GNU コンポーネントのもっとも簡単な開発方法は、Unix 上で Unix のコンポーネントを1つずつ取り替えていくことだったので、これは非常に役に立った。しかし、このことはある倫理的な問題を引き起こした。それは、私たちが Unix のコピーを持つことは正しいかどうかということである。
Unix は私有ソフトウェアだった(今もそうである)が、GNUプロジェクトの哲学は、私有ソフトウェアを使わないとしていた。しかし、自己防衛のための暴力が正当化されるのと同じ理由から、他人が私有パッケージを使うのをやめるのを助けるフリーバージョンを開発するために必要不可欠なのであれば、私有パッケージを使うことは正当化されるという結論を下した。
しかし、必要悪であろうが、悪は悪である。現在はフリーオペレーティングシステムで置き換えたので、私たちは Unix のコピーを持っていない。あるマシンのオペレーティングシステムをフリーオペレーティングシステムに置き換えられない場合、私たちはマシンのほうを取り替える。
GNU プロジェクトが前進し、見つかった、あるいは開発が終わったシステムコンポーネントの数が増えてくると、残された穴のリストを作ると役に立つだろうということになった。私たちは、そのリストを使って、足りない部分を開発してくれるプログラマを募った。このリストは、GNU タスクリストと呼ばれるようになった。私たちは、足りない Unix コンポーネントのほか、本当に完全なシステムが備えるべき役に立つソフトウェアとドキュメントをリストに加えた。
現在、GNU タスクリストに残っている Unix コンポーネントはほとんどない。あまり重要ではない一部を除き、それらの仕事は終わった。しかし、リストには、人によっては「アプリケーション」と呼ぶようなプロジェクトが満載されている。ごく狭い範囲のユーザー以外にも魅力的なプログラムは、オペレーティングシステムに追加すべき有益なプログラムである。
タスクリストには、ゲームさえ含まれている。それはリストを作った当初からのことである。Unixにはゲームが含まれているので、当然ながらGNUもそれらを含まなければならない。しかし、ゲームの場合、互換性が問題になることはないので、Unix ゲームのリストに忠実に従っているわけではない。私たちのリストには、ユーザーが好みそうな別のゲームセットが含まれている。
GNU C ライブラリは、フリーライブラリに対する私有ソフトウェアのリンクを許可する GNUライブラリ一般公開使用許諾書 (LGPL)という特別な種類のコピーレフトを使っている。このような例外を設けたのはなぜなのだろうか。
これは、原則の問題ではない。私有ソフトウェア製品が私たちのコードを組み込む権利を認める原則など存在しない(私たちとの共有を拒否することがわかっているプロジェクトに貢献する理由があろうか)。Cライブラリやその他のライブラリでLGPL を使っているのは、戦略の問題である。
Cライブラリは、一般的な仕事をする。すべての私有システムやコンパイラには、Cライブラリが付属している。そのため、フリーソフトウェアでなければ私たちのCライブラリを使えないようにしても、フリーソフトウェアには何の利益もない。単に、私たちのライブラリを使う気になれないものにするだけである。
これには例外となるシステムが1つある。GNU システム(これにはGNU/Linuxも含まれる)では、GNUCライブラリが唯一のCライブラリである。そのため、GNU システムで私有プログラムをコンパイルできるかどうかは、GNUCライブラリの頒布条件によって決まる。GNUシステムで私有アプリケーションの実行を認める倫理的な理由はないが、戦略的に考えて、それを禁止すると、フリーアプリケーションの開発を奨励するよりも、GNU システムを使いたくない気分を助長することになる。
CライブラリではLGPL を使うことが戦略的に優れているというのは、うことである。他のライブラリについての戦略は、ケースバイケースで検討しなければならない。ある種のプログラムを書きやすくするような特別の仕事をこなすライブラリは、GPLのもとでリリースし、使用をフリープログラムのみに制限すれば、他のフリーソフトウェア開発者を助け、私有ソフトウェアに対する優位性を与えることになる。
たとえば、BASHのコマンドライン編集機能のために開発された GNU Readlineライブラリ *4について考えてみよう。Readline は、LGPL ではなく、通常の GNUGPLのもとでリリースされている。おそらく、このことによって Readline の使用数は減るだろうが、私たちにとって、それはまったく損失ではない。その一方で、Readline を使うために、少なくとも1つの役に立つアプリケーションがフリーソフトウェアとして作られた。これこそ、コミュニティにとって本物の利益である。
私有ソフトウェアの開発者は金銭的な面で優位に立つが、フリーソフトウェアの開発者は相互のために優位性を生まなければならない。いずれ、私有ソフトウェアに対応するもののないGPL によって保護されるライブラリの大規模なコレクションを作りたいものだ。これらのライブラリは、新しいフリーソフトウェアの部品として使える役に立つモジュールを提供し、フリーソフトウェアの更なる開発を促進する大きな力になるだろう。
エリック・レイモンドは、「ソフトウェアの優れた仕事は、どれもプログラマが自分で痒いと思ったところを掻くところから始まる」と言っている。そういうこともあるかもしれないが、GNU ソフトウェアの多くの主要要素は、完全なフリーオペレーティングシステムを作るために開発されている。これらは、衝動ではなく、ビジョンとプランによって作られている。
たとえば、私たちがGNUCライブラリを開発したのは、Unix風のシステムではCライブラリが必要だからであり、BASHを開発したのは、Unix風のシステムではシェルが必要だからである。GNU tarを開発したのは、Unix風システムがtarプログラムを必要とするからである。同じことが私自身のプログラム、GNUCコンパイラ、GNU Emacs、GDB、GNU Make にも当てはまる。
一部の GNU プログラムは、私たちの自由に対する個別の脅威に対処するために開発された。私たちがcompress プログラムの代わりに gzip を開発したのは、LZW の特許*5のために compress がコミュニティから失われたためである。私たちは LessTif の開発者を見つけ、さらに最近ではGNOME と Harmony をスタートさせたが、それも特定の私有ライブラリに起因する問題に対処するためである(後述の「非フリーライブラリ」を参照)。また、ユーザーがプライバシーと自由のどちらかを選択しなければならないようなことのないよう、ポピュラーな非フリーの暗号ソフトウェアに代わる GNU Privacy Guard を開発している。
もちろん、これらのプログラムを書いている人々は、仕事に興味を持つようになったし、多くの人々がそれぞれのニーズや関心に基づいてプログラムにさまざまな機能を追加している。しかし、興味はプログラムが存在する理由ではないのである。
GNU プロジェクトを立ち上げた頃、私はGNU システム全体を開発し、全体としての形でリリースすることを想像していたが、実際にはそのようにはならなかった。
GNU システムの個々のコンポーネントはUnix システムで実装されたので、完全な GNU システムが完成するはるか以前から、それらのコンポーネントは Unixシステムでも実行できた。これらのプログラムの一部はポピュラーになり、ユーザーはそれらの拡張や移植を始めた。移植先は、Unixのさまざまな互換性のないバージョンだったり、まったく別のシステムだったりした。
その過程でこれらのプログラムははるかに強力になり、GNUプロジェクトに資金や貢献者を集めることになった。しかし、GNU 開発者の時間は、足りないコンポーネントを次々に書いていくことにではなく、これらの移植版の維持や既存コンポーネントへの機能の追加に割かれていったので、おそらくこの動きは最小限の稼動するシステムの完成を数年遅らせる効果も持っていたはずである。
1990年までに、GNU システムはほとんど完成していた。主要コンポーネントで欠けていたものは、カーネルだけだった。私たちは、Mach の上で動作するサーバプロセスのコレクションという形でカーネルを実装することにしていた。Machは、カーネギーメロン大学、ついでユタ大学で開発されたマイクロカーネルである。GNU Hurdは、Machの上で動作するサーバコレクション(「GNUの群れ」)であり、Unix カーネルのさまざまな仕事を行う。開発の開始は遅れたが、それは約束通りに Mach がフリーソフトウェアとしてリリースされるのを待っていたからである。
このような設計を選んだ理由の1つは、仕事の中でもっとも難しいと思われた部分を避けるためだった。それは、ソースレベルデバッガなしでカーネルプログラムをデバッグすることである。この部分の仕事は Mach の中ですでに終わっているはずなので、Hurd サーバはユーザープログラムとして GDBでデバッグできると思っていた。しかし、それが可能になるまでには非常に長い時間がかかった。また、互いにメッセージを送り合うマルチスレッドサーバは、デバッグが非常に難しいことがわかった。Hurdを安定動作させる仕事は、何年も遅れている。
GNU カーネルは、もともとHurd という名前になるはずではなかった。最初の名前は、当時の私の恋人だった女性の名前を取った Alix だった。彼女はUnix のシステム管理者で、自分の名前が Unix システムの命名パターンに当てはまっていると言っていた。彼女は、「誰かがきっと私と同じ名前のカーネルを作るはずよ」と友人に冗談を言った。私は何も言わなかったが、Alixという名前のカーネルを作って彼女を驚かせることに心を決めていた。
しかし、事態はそのようには展開しなかった。カーネルのメインプログラマのマイケル・ブッシュネル(現在はトーマス)は、Hurd という名前を好み、Alix はカーネルの特定の部分(システムコールをトラップし、Hurd サーバにメッセージを送ってそれを処理する)を指すものとして再定義された。
最終的に、Alixと私は別れ、彼女は名前を変えた。それとは無関係に、Hurd設計は、Cライブラリがサーバに直接メッセージを送るように変更された。そのため、Alix コンポーネントは設計から消えてしまった。
しかし、これらのことが起きる前に、彼女の友達の1人がHurd のソースコードにAlix という名前があることに気づき、彼女にそのことを教えた。だから、Alixという名前は機能を果たしたのである。
GNU Hurd は、まだ稼動できる状態にはなっていないが、幸いにも別のカーネルが現れた。リーナス・トーバルズは、1991年に Unix 互換カーネルを開発し、Linux と名付けた。そして、1992年頃、Linuxとまだ完全には完成していないGNU システムを結合することによって、完全なフリーオペレーティングシステムが完成した(もちろん、両者の結合は、それ自体大きな仕事だった)。現在、実際にGNU システムの1バージョンを実行できるのは、Linux のおかげである。
私たちは、GNU システムとカーネルとしてのLinux の結合という構成を表現するために、このバージョンのシステムをGNU/Linux と呼んでいる。
私たちは、広い範囲のフリーソフトウェアを開発できるという自らの能力を証明した。だからといって、私たちが無敵で安泰だというわけではない。フリーソフトウェアの将来を不確実なものにするいくつかの試練が待ち構えている。それらの試練に遭ったときには、不屈の努力と忍耐が必要だろう。場合によっては、それが数年続くこともある。人々が自由を尊重し、自由を奪われることを拒否するときに示す決意が必要とされる。
以下の4つの節では、これらの試練について論じる。
ハードウェアメーカーは、次第にハードウェアの仕様を非開示にする傾向にある。これは、フリーのドライバを書いて Linux や XFree86*6が新ハードウェアをサポートできるようにすることを困難にする。今日は、完全なフリーシステムがあるが、明日のコンピュータをサポートできなければ、明日にはフリーシステムがなくなるかもしれない。
この問題への対処方法は2つある。プログラマは、リバースエンジニアリング、ハードウェアのサポート方法を突き止めることができる。プログラマ以外の人々は、フリーソフトウェアがサポートしているハードウェアを選ぶことができる。フリーシステムが増えれば、仕様の非開示主義は自分の首を絞める結果になるだろう。
リバースエンジニアリングは大仕事である。そのような仕事に着手するだけの意志を持ったプログラマを集めることができるだろうか? イエス。フリーソフトウェアは主義主張の問題で、非フリードライバは許容できないという強い意志を築き上げることができれば可能である。そして、フリードライバを使えるようにするために、プログラマ以外の人々は余分なお金や余分な時間を使ってくれるだろうか? 自由を確保するという意志が浸透すれば、それに対する答えもイエスである。
フリーオペレーティングシステム上で動作する非フリーライブラリは、フリーソフトウェア開発者を陥れる罠である。エサは魅力的な機能だが、そのライブラリを使ってしまうと、プログラムはフリーオペレーティングシステムの一部ではあり得なくなってしまうので、プログラマは罠に落ちたということになる(厳密に言えば、そのプログラムをフリーオペレーティングシステムの一部にすることはできるが、問題のライブラリがなければそのプログラムは動作しないだろう)。さらに悪いことに、私有ライブラリを使っているプログラムがポピュラーになったら、疑いを知らない他のプログラマたちも罠に陥れることになる場合がある。
この問題の最初の事例は、80年代のMotif*7ツールキットだった。当時はまだ、フリーオペレーティングシステムはなかったが、Motif がその後どのような問題を起こすかは明らかだった。GNU プロジェクトは、Motif に2通りの反応を返した。個々のフリーソフトウェアプロジェクトに Motif だけではなく、フリーXツールキットもサポートするように呼びかけることと、Motif に代わるフリーシステムを書く人を募ることである。この仕事には長い時間がかかった。HungryProgrammers によって開発された LessTif がほとんどの Motif アプリケーションをサポートできるだけの力を付けたのは、1997年のことである。
1996年から1998年にかけて、Qt という別の非フリーGUI(グラフィカルユーザーインターフェイス) ツールキットが、大規模なフリーソフトウェアコレクションのKDEデスクトップ環境で使われていた。
フリーGNU/Linux システムは、そのライブラリを使うわけにはいかなかったので、KDEを使うことができなかった。しかし、フリーソフトウェアに対する厳密なこだわりのない一部の市販 GNU/Linux ディストリビューションがそれぞれのシステムにKDE を追加した。機能は強化されたが自由が弱体化されたシステムを作ったのである。KDEグループは、多くのプログラマに対してQt を使うように積極的に働きかけており、数百万の新しい「Linux ユーザー」は、そこに問題が潜んでいるということを教えられていなかった。この問題は深刻に感じられた。
フリーソフトウェアコミュニティは、GNOMEと Harmony という2通りの方法でこの問題に対処した。
GNOME (GNU Network Object Model Environment)は、GNUのデスクトップ環境プロジェクトである。1997年にミゲル・デ・イカーザが開発に着手し、RedHat Software の支援のもとで開発されたGNOME は、KDEと同様のデスクトップ機能を提供するが、フリーソフトウェアだけを使っているところが異なっていた。C++だけではなく、さまざまな言語をサポートするなど、技術的な長所も持っていた。しかし、GNOMEの最大の目的は、自由――すなわち非フリーのソフトウェアを使うことを要求しないことである。
Harmony は、Qt を使わなくてもKDEソフトウェアを実行できるようにするために設計された、互換性のある代替ライブラリである。
1998年11月、Qtの開発者たちは、実際に遂行されればQt をフリーソフトウェアにするはずのライセンス契約の変更を発表した。確かなことはわからないが、このような方針変更がなされた理由の一部は、Qtがフリーではなかった時代に起こした問題に対するコミュニティの断固とした反応にあったと思う(ただし、新ライセンスは不便で不公平なものなので、まだQtの使用は避けることが望ましい)*8。
次の魅力的な非フリーライブラリに対しては、どのように対応すべきだろうか。コミュニティ全体が罠から身を遠ざけることの必要性を理解してくれるだろうか。それとも、多くのメンバーが利便性のために自由を放棄し、大きな問題を引き起こしてしまうのだろうか。私たちの将来は、私たちの哲学にかかっている。
私たちが直面している最悪の脅威は、ソフトウェア特許である。ソフトウェア特許は、20年もの間、フリーソフトウェアがアルゴリズムや機能を利用できないようにすることができる。LZW 圧縮アルゴリズム特許は1983年に発効となり、私たちはまだ正しく圧縮されたGIFを作るフリーソフトウェアをリリースすることができないでいる。1998年には、特許がらみの訴訟が現実的な脅威となったので、ディストリビューションから MP3 圧縮オーディオを作成するフリープログラムが取り除かれた。
特許には対処方法がある。特許が無効である証拠を探すこともできるし、同じ仕事をする別の方法を探すこともできる。しかし、これらの方法が機能するのは限られたときだけであり、両方とも失敗したときには、特許のためにすべてのフリーソフトウェアがユーザーの望む機能を失うことを余儀なくされる場合がある。このようなときにはどうしたらよいのだろうか。
自由のためにフリーソフトウェアを評価する私たちは、いずれにしてもフリーソフトウェアの側に立つだろう。私たちは、特許の対象となっている機能なしで仕事ができるように工夫する。しかし、フリーソフトウェアに技術的な優位性を期待するユーザーは、特許によって優位性が失われたらそれを欠陥と呼ぶだろう。開発の「伽藍」 *9モデルの実践的な有効性や、一部のフリーソフトウェアの信頼性や能力について語ることは意味のあることだが、私たちはそこに留まっているわけにはいかない。私たちは、自由と原則について語らなければならないのである。
私たちのフリーオペレーティングシステムの最大の弱点は、ソフトウェアの中にはない。それは、システムに組み込める優れたフリーマニュアルがないことである。ドキュメントは、あらゆるソフトウェアパッケージに必要不可欠な部分である。重要なフリーソフトウェアパッケージに優れたフリーマニュアルが含まれていなければ、それは大きな欠陥と言わなければならない。現在の私たちはそのような穴を無数に抱え込んでいる。
フリードキュメントは、フリーソフトウェアと同様に、価格の問題ではなく、自由の問題である。フリーマニュアルの基準は、フリーソフトウェアとほぼ同じところにある。重要なのは、すべてのユーザーに自由を与えるかどうかだ。プログラムのすべてのコピーにマニュアルを同梱できるようにするために、オンラインと紙の両方の形態で再頒布(商業目的の販売を含む)が認められていなければならない。
変更に対する許可も重要である。一般原則として、私はあらゆる種類の論文や本を変更する権利が認められることが重要だとは考えていない。たとえば、このような論文に変更を加えることを許可する必要があるとは思わない。この論文には、私たちの活動と思想が書かれているのである。
しかし、フリーソフトウェアのドキュメントについては、書き換えの自由が重要な意味を持つ理由がある。人々がソフトウェアを書き換える権利を行使し、機能を追加、変更したとき、彼らが仕事に忠実なら、マニュアルも書き換えるだろう。それにより、変更後のプログラムに合った正確で使えるドキュメントを提供できるようになるわけである。プログラマが職務を忠実に遂行し、仕事を完成させることを認めないマニュアルは、私たちのコミュニティのニーズを満たさない。
ここで変更方法に何らかの歯止めをかけても、問題は起きないだろう。たとえば、オリジナルの著者の著作権情報、颁布条件、著者リストを書き換えないことを要求することはかまわない。変更版に書き換えられているということの記載を求めることもかまわないし、技術以外のトピックを扱っている節については、節全体の削除や変更を禁止することまで認められるはずだ。これらの制限が問題とならないのは、職務に忠実なプログラマが変更後のプログラムに合わせてマニュアルを書き換えることを禁止していないからである。言い換えれば、それらの制限は、フリーソフトウェアコミュニティがマニュアルをフル活用することを妨げない。
しかし、マニュアルの「技術的な」内容はすべて書き換え可能でなければならないし、通常のすべてのメディア、すべてのチャネルを通じて結果を頒布できなければならない。そうでなければ、制限はコミュニティにとって有害であり、そのマニュアルはフリーではないということになる。私たちは、別のマニュアルを用意しなければならない。
フリーソフトウェアの開発者たちは、あらゆるタイプのフリーマニュアルを書くという意識と決意を持つようになるだろうか。繰り返すが、私たちの将来は、私たちの哲学にかかっている。
Debian GNU/Linuxや Red Hat Linux などの GNU/Linux システムのユーザーは数千・万人いると推計されている。フリーソフトウェアは、純粋に実践的な理由からそれだけのユーザーが追随するだけの現実的なメリットを生むところまで成長してきたのだ。
このことがもたらす良い結果は明らかである。フリーソフトウェアの開発に対する関心が高まり、フリーソフトウェアビジネスの顧客が増え、私有ソフトウェア製品ではなく市販フリーソフトウェアを開発する企業の士気が高まる。
しかし、フリーソフトウェアに対する関心は、それが基礎としている哲学の認知度よりも速いペースで高まっている。今まで示してきた試練や脅威に私たちが対抗できるかどうかは、自由を求める固い意志にかかっている。コミュニティにその意志を確実に持たせるためには、コミュニティに入ってくる新しいユーザーにこの思想を普及させなければならない。
しかし、私たちはそれに失敗している。人々は、コミュニティの倫理を教えようとすることよりも、コミュニティに新しいユーザーを引き付けようとすることにはるかに熱心になっている。私たちは両方を必要としており、両方のバランスをとらなければならない。
コミュニティの一部が「フリーソフトウェア」という用語の使用を廃して「オープンソースソフトウェア」という言葉を使い出した1998年には、新しいユーザーに自由について教えることがさらに困難になった。
この用語を推した人々の一部は、「フリー」が「無料」と間違えられるのを防ごうと思っていた。これは正しい目標である。しかし、フリーソフトウェア運動とGNU プロジェクトの動因であった精神と原則を脇に置いて、経営者やビジネスユーザーにアピールすることを目指した人々もいた。経営者やビジネスユーザーの多くは、自由、コミュニティ、原則よりも利益を重視するイデオロギーを持っている。「オープンソース」というレトリックは、高品質で強力なソフトウェアを創造する可能性にスポットライトを当てるが、自由、コミュニティ、原則の思想を霞ませてしまう効果を持っている。
「Linux」関連の雑誌は、このことをはっきり示す例である。これらの雑誌には、GNU/Linux と併用できる私有ソフトウェアの広告が満載されている。次のMotif や Qt が現れたとき、これらの雑誌は、プログラマたちに離れよと警告を発するのだろうか、それともそれらの広告を掲載するのだろうか。
ビジネス界からの支援は、さまざまな面でコミュニティに貢献できる。そのことに関してはみな平等であり、意味がある。しかし、自由と正義についての言及を減らすことによってビジネス界からの支援を勝ち取っても、惨めな結果を招く可能性がある。それは、ソフトウェアの普及と思想の浸透のアンバランスをさらに悪化させるだろう。
「フリーソフトウェア」と「オープンソース」は、多かれ少なかれ同じタイプのソフトウェアを指すが、ソフトウェアとその価値観についての思想は異なる。GNU プロジェクトは、単なるテクノロジーではなく、自由が重要なのだという思想を表現するために、「フリーソフトウェア」という用語を使い続ける。
「『トライ』というものはない」というヨーダの哲学はかっこよく聞こえるかもしれないが、私には無関係である。私は、自分にその仕事ができるのかどうか不安に思いながら、そしてできたとしても充分に目標を達したのか確信を持てないまま、ほとんどの仕事をしてきた。しかし、敵と私の町の間には私しかいなかったので、何はともあれトライしてきた。自分自身驚いているが、私はときどき成功を収めた。
逆に、ときどきは失敗し、私の町は敵に奪われた。そして、さらに脅威を受けている別の町を見つけ、新しい戦いに備えた。私は脅威を探し、敵と町の間に身を置き、他のハッカーを私の陣営に迎えてきた。
今は、多くの場合、私は、たった一人ではない。味方のハッカーたちが防衛線を築いているのを眺め、今のところは町が生き残れそうに感じられるのは、喜びであり、気持ちが休まることである。しかし、危険は年々増大している。そして、今や Microsoftが、私たちのコミュニティを明確にターゲットに据えた。自由に未来があることを当たり前だと思うことはできない。思ってはならないのだ。白由を保ちたければ、自由を守る備えを持たなければならない。
初出:"Open Sources: Voices from the Open Source Revolution", O'Reilly,1999。このバージョンは、"Free Software, Free Society: Selected Essays ofRichard M. Stallman", 2002, GNU Press (http://www.gnupress.org/); ISBN1-882114-98-1の一部である。
本文に一切の変更を加えず、この著作権表示を残す限り、この文章全体のいかなる媒体における複製および頒布も許可する。