![[image of What's GNU]](http://www.gnu.org/graphics/whats-gnu-sm.jpg)
[ English | French | Indonesian |
Italian| Korean | Russian |Spanish
]この文書は書籍『オープンソース』に収録されています
[ English | French | Indonesian |
Italian| Korean | Russian |Spanish
]
１９７１年に MIT 人工知能（AI）研究所で働くようになると、わたしはもうそこに何年も前からあったソフトウェア共有コミュニティの一員になりました。ソフトウェアの共有はわたしたちのコミュニティに限られたことではなく、ちょうど料理のレシピが料理と同じくらい古くからあるのと同じように、コンピューターの歴史と同じくらい古くから行われてきたことではありましたが、わたしたちはそれを最大限に利用してきたのです。
AI 研は ITS (Incompatible Timesharing System) と呼ばれるタイムシェアリング・オペレーティング・システムを使っていました。したがって研究所のスタッフだったハッカーたち（１）は当時広く使われていた DEC 社の PDP-10 用にアセンブラ言語で設計し、（コードを）書いていました。このコミュニティの一員としての、また AI 研のハッカーとしてのわたしの仕事はシステムを改善していくことでした。
わたしたちは自分たちのソフトウェアを「フリーソフトウェア」とは呼んでいませんでした。なぜなら、そんな用語は存在していなかったからです。しかし、実際はそういうものでした。他の大学や企業からやって来た人がプログラムを移植したり使ったりしたいときはいつでも、わたしたちは喜んで許可していました。もし誰かが珍しくて面白そうなプログラムを使っているのを見たら、いつでもソースコードを見せてほしいと頼んでもいいので、それを読んだり、書き換えたり、新しいプログラムを作るためにその一部を取り出しても構いませんでした。
（１）「ハッカー」という用語を「セキュリティ破り」の意味で使うのはマスメディアの側の誤用です。わたしたちハッカーはこのような意味づけを拒否し、この言葉を「プログラムが大好きでそれに精通することを楽しんでいる人」という意味で使い続けます。
１９８０年代に DEC 社が PDP-10 シリーズの開発を止めたとき、状況は大きく変わってしまいました。６０年代にはエレガントでパワフルだったそのアーキテクチャーは、８０年代に実用可能になったより大きなアドレス空間用には本来拡張していくことが出来なかったのです。これは ITS を形成していたあらゆるプログラムの大半がもう時代遅れになってしまったということでもありました
AI 研のハッカーコミュニティは既に、その直前に崩壊していました。１９８１年にその中から誕生した Symbolics 社が AI 研のほぼ全てのハッカーを引き抜いてしまい、根絶やしにされたコミュニティは立ち行かなくなっていたのです（Steve Levy 著「ハッカーズ」にはこれらの出来事や全盛期の頃のコミュニティの姿が活き活きと描かれています）。AI 研が１９８２年に新しい PDP-10 を購入したとき、管理者は ITS ではなく DEC 社の非フリー版タイム・シェアリング・システムを使うことに決定してしまいました。
VAX や 68020 のような当時の先進的なコンピューターは専用のオペレーティング・システムを備えていましたが、どれもフリーソフトウェアではありませんでした。つまり、実行可能なコピーを入手するためだけでも非開示契約を結ぶ必要があったのです。
ということは、つまり最初にコンピューターを使うときには、周りの人を手助けしないと約束する必要があるということでした。協力し合うコミュニティは禁じられてしまうのです。独占的なソフトウェアの所有者によって作られたルールとは「もしお前が隣人と分かち合うなら、お前は著作権法に反していることになる。変更を加えたいのなら、われわれに頼み込んで作ってもらうことだ」というものなのです。
独占権のあるソフトウェアという社会システム -- ソフトウェアを共有したり変更したりするのは許されないとするシステム -- は反社会的であり、倫理に反し、ただ単純に間違っているのだという考え方に、読者の方々は驚かれるかもしれません。しかし社会を分断しユーザーが手も足も出ないようにされてしまうことの上に築かれたシステムについて、他に何と言い様があるでしょう。この考え方に驚くのは、独占権を与える社会システムを考えもなくただ受け止めていたり、独占ソフトウェア企業の示唆する言葉遣いにおいて判断しているのではないでしょうか。ソフトウェア会社はこの問題の見方は一つしかないと人々に信じさせるために長いこと非常な作業を重ねてきたのです。
ソフトウェア会社が自分たちの「権利を」「行使する」あるいは「著作権違反をやめさせる」と語るとき、彼らが語っていることは実際には二の次なのです。この言明の真のメッセージは、彼らが当然であると見なし、あえて口にしていない前提条件の方にあります。つまり、社会は彼らのことを無批判に受け入れるべきだというわけです。ではその点について吟味してみましょう。
一つ目の前提は、ソフトウェア会社は自分たちのソフトウェアについて議論の余地がない自然権を有しており、したがってその全てのユーザーを支配しているということです（もしこれが自然権であれば、それが社会にどんな害を与えようと、わたしたちには異議を唱えることさえできないでしょう）。面白いことに、合衆国憲法と法律上の慣習ではこの見方は否定されています。著作権は自然権ではなく、複製するというユーザーの自然権を政府が強要する独占的行為なのです。
もうひとつの語られざる前提条件とは、ソフトウェアに関して唯一重要なことはそれがどんな作業をさせてくれるかであって、われわれコンピューターのユーザーはどんな社会に暮らすことができるかについて気にかけることができないというものなのです。
三番目の前提条件は、プログラムのユーザーを支配してる企業に申し出なければ、わたしたちには便利なソフトウェアは手に入らない（あるいはある特定の作業をするためのプログラムを入手することがまるっきり不可能だ）ということです。
これらの前提条件を拒否して、それぞれの問題をユーザーを第一に考えて普通の一般常識的なモラルに照らし合わせて判断するならば、全く別の答えが導き出されます。コンピューターのユーザーは自分のニーズに合わせてプログラムを修正し、ソフトウェアを共有する自由がなければなりません。なぜなら、他人の手助けをすることは社会の基本なのですから。
http://www.gnu.org/philosophy/why-free.html
この結論を裏付ける推論については紙幅が尽きましたので、このウェブページを参照してください。
コミュニティがなくなってしまい、以前と同じように活動を続けていくのは不可能になってしまいました。その代わりに、わたしは道徳的な選択に直面することになったのです。
手っ取り早いのは独占ソフトウェアの世界に参加して、非開示契約を結んで仲間のハッカーたちを手助けしないと約束することでした。ひょっとしたら、わたしも非開示契約の下でソフトウェアを開発し、他の人たちにも自分たちの仲間を裏切るようプレッシャーをかけるようになっていたかもしれません。
このやり方でお金を儲けることも出来たでしょう。そしておそらくコードを書くことを楽しんだかもしれません。しかしキャリアの終わりには、人々を隔てる壁を築いてきた何年もの日々を思い返し、自分の人生を世界をより悪いものにするために費やしてきたと感じるようになるのは分かっていました。
わたしには既に非開示契約を受け取る当事者になった経験があります。ある人がわたしと MIT の AI研にプリンターを制御するプログラムのソースコードを渡すことを拒否したときのことです（このプログラムにはある特定の機能がなかったので、プリンターを使うのにはひどくいらいらさせられていました）。ですからわたしには非開示契約には罪はないというのは理解できません。向こうがわたしたちと共有し合うことを拒否したときには本当に頭にきました。わたしには変節してみんなを同じ目に遭わせることなどできません。
もうひとつの選択肢は、正直ではあるけれどもいやなもので、コンピューターの世界から去ることです。そのやり方ではわたしのスキルは間違った使われ方はしませんが、無駄になってしまうことには変わりありません。わたし自身がコンピューターのユーザーを分断したり制限したりする過ちを犯すことはありませんが、それでもそういうことは起こるでしょう。
そこでわたしはプログラマーが正しいことをできるようになるための方法を探しました。自分に書けるプログラムはあるだろうか、それでもう一度コミュニティを作ることができるようになるだろうか、と自分の胸に聞いてみました。
答えは明らかでした。最初に必要だったのはオペレーティング・システムです。コンピューターを使うには重要なソフトウェアです。オペレーティング・システムがあれば、たくさんのことが出来るようになります。なければ、コンピューターを実行させることも出来ません。フリーなオペレーティング・システムがあれば、わたしたちはもう一度ハッカーたちが協力し合える--そして誰でも勧誘できるようなコミュニティを持つことが出来るのです。そうすれば自分の友人たちを拒むことから始めるような真似をせずに、誰もがコンピューターを使うことが出来るようになるでしょう。
オペレーティング・システムの開発者として、わたしにはこの仕事に相応しいスキルがありました。だから、成功の見込みがあるわけではなかったのですが、わたしは自分がこの仕事をするよう選ばれたのだと気付いたのです。移植性が高くなるだろうという理由から、システムは Unix と互換性のあるものにすることを選びました。それに、そうすれば Unix のユーザーも容易に乗り換えることができるでしょう。GNU という名前は 「GNU's Not Unix」 という風に頭文字を循環させるハッカーの伝統に従って選ばれました。
オペレーティング・システムというのはせいぜい他のプログラムを実行するのに足るだけのカーネルだけを意味するわけではありません。１９７０年代には、オペレーティング・システムの名に相応しいものであれば、どれにもコマンド・プロセッサやアッセンブラ、コンパイラ、インタープリタ、テキストエディタ、メイラーなどなどが含まれていました。ITS
にも、Multics にも、VMS にも、Unix にもです。GNU のオペレーティング・システムにもそれらは含まれるようにするつもりでした。
後になってヒレル（１）のものとされる次のような言葉を知りました。
わたしが自分のためにするのでなければ、いったい誰がわたしのためにする？
わたしだけが自分のためにするとすれば、わたしはいったい誰？
今でなければ、いったい何時？
GNU プロジェクトを始めようという決意も同じような精神に基づいてのことでした。
（１）無神論者として、わたしはどの宗教指導者も信心していませんが、ときおり彼らの誰かの言葉に何かしら敬服するものがあることに気付きます。
「フリー」は自由のことをいうのであって、値段のことではないので、複製を販売することとフリーソフトウェアであることに矛盾は全くありません。事実、複製を販売する自由は重要です。というのもフリーソフトウェアを集めた CD-ROM を販売するのはコミュニティにとっても大切なことであり、またそれを販売することはフリーソフトウェア開発のためのファンドを立ち上げるための重要な手段でもあるからです。それゆえに、この中に収録することができないプログラムはフリーソフトウェアではありません。
「フリー」という語の曖昧さのせいで、みんなそれに代わる別のものを探してきました。しかし、誰もぴったりくるような別の代わりを見つけられなかったのです。英語には他のどの言語よりもたくさんの言葉やニュアンスがありますが、しかし「フリー」を自由の意で現すシンプルで明白な単語がありません--「unfettered（足枷のない、自由な）」という語が意味の上で最も近いところにありますが。「liberated」「freedom」「open」のような候補にも間違った意味やその他の不都合がありました。
システム全体を開発するというのは巨大なプロジェクトです。それを実現可能なところにもっていくため、わたしは既存のフリーソフトウェア群を可能であればなんでも付け加えたり使用することにしました。例えば、一番最初に決めたのは TeX を主要なテキスト形式として採用することでした。その数年後には、GNU 向けに別のウィンドウシステムを作るよりも X Window システムを使うことに決めました。
この決定により、GNU システムは全 GNU ソフトウェアのコレクションと同じものではなくなりました。GNU システムには GNU ソフトウェア以外のプログラムも含まれます。それらのプログラムは他の人たちによってそれぞれの目的に応じて開発されますが、フリーソフトウェアなのでわたしたちも使うことが出来ます。
１９８４年の一月にわたしは MIT を辞めて GNU ソフトウェアを書き始めました。MIT が GNU をフリーソフトウェアとして配付するのを妨げることができないようにするために MIT を去る必要があったのです。もしわたしがスタッフとして残っていたなら、MIT はその仕事の所有権を主張し、自分たちの配付条件を押し付けたり、独占的なソフトウェアとしてしまうことさえ可能だったでしょう。わたしには自分のやってきた大量の仕事をむざむざ無駄になるに任せるつもりはありませんでした。
しかしながら、当時 MIT の AI 研を率いていた Winston 教授のご好意により、研究所の施設を使い続けさせていただくことができました。
GNU プロジェクトを始めて間もなくの頃、VUCK という名で知られる Free University Compiler Kit（オランダ語で「free」は V で始まります）のことを聞きました。これは C や Pascal を含む複数の言語を扱えるよう作られたコンパイラで、複数のマシンをサポートするとのことでした。わたしは作者の方に GNU でこれを使えないかどうかと質問を送りました。
彼は「university は free だけれども compiler は free ではない」と始まる小馬鹿にしたような返事を送って寄越しました。そこでわたしは GNU プロジェクトの最初のプログラムは複数言語に対応した、複数のプラットフォーム向けのコンパイラにすることにしました。
自分で一からコンパイラを書き上げる手間を省くため、Pastel というコンパイラのソースコードを手に入れました。これは Lawrence Livemore 研究所が開発した複数プラットフォーム対応のコンパイラです。拡張された Pascal をサポートし、またその言語で書かれたもので、システム・プログラミングのために設計されたものでした。しかしスタック空間に何メガバイトも必要な上に、自分が使える 68000 Unix システムは 64k しか対応していないことが分かって諦めることになりました。
そのとき、Pastel コンパイラはインプットされたファイル全体をシンタックスツリーに解析して動作し、全シンタックスツリーを一連の「instructions」に変換してから、溜め込んだものを一切開放せずに全アウトプット・ファイルを作成することが分かりました。この点を踏まえて、わたしは新しいコンパイラを一から作らなければならないという結論に達したのです。そのコンパイラは GCC として知られていますが。Pastel からのものは何も使用されておらず、自分で書いた C のフロントエンドをどうにか実装しました。しかしそれは数年後のことです。まず最初に、わたしは GNU Emacs の作業に取りかかりました。
GNU Emacs には１９８４年の九月に取りかかり、１９８５年の頭には使えるようになりました。これで Unix システムを編集作業に使うことが出来ます。vi や ed の修得には興味がなかったので、それまで編集には別の種類のマシンを使っていたのです。
この時点から、みんなが GNU Emacs をほしがってくれるようになりました。そのため、どうやってこれを配付するかの問題が発生したのです。もちろん、わたしはこれを自分が使っていた MIT の匿名 ftp サーバに置きました（prep.ai.mit.edu のこのコンピューターは、こうして主要な GNU ftp 配付サイトになったのです。数年後にその役目を終えると、わたしたちは新しい ftp サーバにサーバ名を移転させました）。しかし、当時興味を持ってくれた多くの人たちがインターネット環境にはおらず、ftp 経由で複製を手にすることが出来ませんでした。そこで問題が起きたのです。この人たちには何と伝えればいいのでしょう？
「ネットに繋がっていてコピーしてくれる友達を見つけてください」と伝えることも出来たでしょう。あるいはオリジナルの PDP-10 Emacs でやったことを自分ですることも可能でした。彼らに「テープと SASE を送ってくれれば、Emacs を入れて送り返します」と言うのです。しかし、わたしには仕事がなく、フリーソフトウェアからお金を得る方法を探していました。そこで、１５０ドルでテープにコピーして発送しますと発表することにしました。このやり方でわたしはフリーソフトウェア・ビジネスを始めました。全 Linux ベースの GNU システムを配付している今日の企業の先駆者となったわけです。
あるプログラムがフリーソフトウェアで、それが作者の手を離れたとき、そのコピーを持っている全ての人にとってフリーソフトウェアのままであり続けるとは限りません。例えばパブリックドメインのソフトウェア（著作権のないソフトウェア）はフリーソフトウェアですが、誰でもその独占バージョンを作ることが出来ます。同じく、多くのフリーソフトウェアには著作権がありますが、独占的なものに作り替えたバージョンを作るのが許されるような単純な使用許諾条件の下で配付されています。
この問題のいい例が X Window システムです。MIT で開発され、使用許諾条件付でフリーソフトウェアとしてリリースされましたが、すぐに多くのコンピューター関連企業によって採用されました。彼らは X を自分たちの独占的な Unix システムにバイナリ形式のみで組み込み、同じく非開示契約によって覆ってしまったのです。これらの X のコピーは Unix と同様にもはやフリーソフトウェアではなくなりました。
X Window システムの開発者たちはこれを問題とは考えていませでんした。彼らはこうなることを期待し、それを意図していたのです。彼らの目標は自由ではなく、「多くのユーザーを獲得する」という意味でただ「成功する」ことでした。彼らはユーザーが自由を得ることなどどうでもよくて、大勢になりさえすればそれでよかったのです。
これによって、「このプログラムはフリーなの？」という問いに対して、自由の量を計る二つの異なるやり方がそれぞれ別の答えを出してしまうような矛盾した状況が生まれました。MIT
のリリース方針が与える自由に従って判断すれば、X はフリーソフトウェアです。しかし X の平均的なユーザーの自由を調べれば、これは独占的なソフトウェアと言わざるを得ません。ほとんどの
X のユーザーはフリーなバージョンではなく Unix システムと一緒になった独占的なバージョンを走らせているからです。
GNU の目標はユーザーに自由を与えることで、ポピュラーになることではありません。ですからわたしたちは GNU のソフトウェアが独占ソフトウェアに変わることを防ぐ配付条件を使用する必要がありました。わたしたちが使っているこの方法は「コピーレフト」（１）と呼ばれています。
コピーレフトは著作権法を利用してはいますが、それをひっくり返して通常とは反対の目的のために使っています。つまり、ソフトウェアを私物化するための手段としてではなく、ソフトウェアをフリーにしておくために。
コピーレフトの中心的な考え方は、全ての人にそのプログラムを実行し、複製し、修正し、修正したバージョンを再配布する許可を与えることですが、制限事項を加えることにも許可を与えるわけではありません。したがって、それが「フリーソフトウェア」であると決定するような大切な自由というものは、その複製を持っている人たち全てを保証するものであり、それによって誰もが不可侵の権利を手に入れることになるのです。
コピーレフトを効果的なものにするために、修正されたバージョンもフリーでなければなりません。これにより、わたしたちの作業をもとにした作品が出版された場合、それがわたしたちのコミュニティも入手可能であるよう保証されます。プログラマーとしての仕事を持っている人がボランティアで
GNU ソフトウェアを改善してくれたとき、それはコピーレフトなので雇用主に「我々の独占バージョンを作るのに使用するから変更した部分を共有してはいけない」とは言わせない
ようになっています。
そのプログラムのユーザーの自由を保証したいのであれば、そのような変更の自由を求めるのが不可欠になります。X Window システムを私物化する企業はたいてい自分たちのシステムやハードウェアに移植する際に何らかの変更を加えています。これらの変更は X の大部分と比べれば些細なものではあるでしょうが、だからといってどうでもいいことではありません。もし変更を加えることがユーザーの自由を否定するための抜け道になってしまうなら、その抜け道につけこむのも容易になってしまうのです。
これと関連して、フリーのプログラムを非フリーのコードと結合させることの問題があります。そのような組み合わせは不可避的に非フリーとなってしまいます。非フリーの部分にたとえどんなものであっても自由が欠けているなら、全体もまた同じなのです。そのような組み合わせを認めてしまえば、船を沈めるには十分な穴を開けてしまうことになりかねません。ゆえに、コピーレフトに必ず要求されるのはこのような穴に栓をすることです。コピーレフトのプログラムに付加される、あるいは組み合わされるのが何であれ、統合されたバージョンもまたフリーでコピーレフトでなければならないのです。
コピーレフトに特有の事柄を履行させるためにわたしたちがほとんどの GNU ソフトウェアに用いているのが GNU 一般公有使用許諾、略して GNU GPL でです。また特別な状況下で使用する別種のコピーレフトもあります。たとえば GNU マニュアルもコピーレフトですが、マニュアルに複雑な GNU GPL は必要ないので、もっとシンプルなコピーレフトを使っています。
（１）１９８４年か１９８５年に、Don Hopkins 氏（かなりの想像力の持ち主です）がわたしに手紙を送ってくれました。封筒にいくつか愉快なことが書かれてあり、その内のひとつが「Copyleft--all rights reserved」だったのです。当時、配付の仕方について考えていたわたしはこの「コピーレフト」という言葉をその名前にすることにしました。
Emacs を使うことに関心が集まってくるにしたがって、GNU プロジェクトに参加する人が増えてきました。そこでわたしたちはそろそろ資金調達の方法を再考してみようと決めました。そして１９８５年にフリーソフトウェア開発のための非営利団体、フリーソフトウェア財団（FSF）を設立したのです。FSF は Emacs のテープ配付事業も引き継ぎ、後にはこれに（GNU のものと非 GNU のものも含んだ）他のフリーソフトウェアをテープに加え、さらにはフリーのマニュアルも販売するなどして事業を拡大していきます。
FSF は寄付も受け付けますが、その収益の大半は常に販売利益 -- フリーソフトウェアの複製の販売やその他の関連サービス -- から得ています。今日ではソースコードの CD-ROM やバイナリの CD-ROM、印刷したマニュアル（全て再配布、修正は自由です）、豪華版ディストリビューション（選んでもらったプラットフォーム向けの全ソフトウェアのコレクションをビルドしたもの）の販売を手掛けています。
フリーソフトウェア財団の職員は多くの GNU ソフトウェアを書き、またそのメンテナンスをしていますが、特記すべきは C Library とシェルでしょう。The GNU C Library は GNU/Linux 上で走るどのプログラムも Linux とのやり取りに使用しています。これはフリーソフトウェア財団のスタッフ、Roland McGrath 氏によって開発されています。大半の GNU/Linux システムで使われているシェルが（１） BASH（Bourne Again Shell）で、FSF の職員である Brian Fox によって開発されています。
GNU プロジェクトは開発ツールや開発環境に留まるものではないので、わたしたちはこれらのプログラムの開発を資金援助しています。わたしたちの目標はオペレーティング・システム全体であり、これらのプログラムは目標達成のために必要なものだからです。
（１）「Bourne again Shell」は Unix で標準的に使われる「Bourne Shell」の名前にひっかけたジョークです。
フリーソフトウェアの哲学は世間に広がる特定のビジネス慣行を否定してはいますが、ビジネスそのものに反対しているわけではありません。ビジネスがユーザーの自由を尊重するなら、わたしたちはその成功を願っています。
Emacs のコピーを販売することがフリーソフトウェアのビジネスの一例を示すデモンストレーションになっています。FSF がこのビジネスを引き継いだとき、わたしは別の収入の道を探さなければなりませんでした。わたしが見つけたのは、自分が開発したフリーソフトウェアに関連したサービスの提供です。これには GNU Emacs のプログラミングや GCC のカスタマイズの方法、ソフトウェア開発、それにたいていの場合は GCC を他のプラットフォームに移植するやり方でしたが、それらを教えることも含まれます。
今日ではこれらのフリーソフトウェア関連ビジネスはどれも多くの企業によって実践されています。CD-ROM でフリーソフトウェアのコレクションを配付するところもあれば、ユーザーの疑問に答えたり、バグを修正したり、新しく主要な機能を付け加えたりするなどさまざまなレベルに渡るサポートを提供するところもあります。また、新たにフリーソフトウェア製品を市場に送りだすことをベースにしたフリーソフトウェア関連企業が現れるのを目にするようになってさえいるのです。
しかし、気をつけてください。多くの企業が「オープンソース」という言葉の下で、実際にはフリーソフトウェアと一緒に動く非フリーのソフトウェアをベースにしたビジネスを展開しています。これらはフリーソフトウェア企業ではありません。自分たちの製品でユーザーを自由から引き離そうとする独占企業なのです。それを「付加価値」と呼んではいますが、それは彼らがわたしたちに選んでほしいと望んでいる価値を反映しているに過ぎません。つまり、便利さは自由に勝るという価値です。もし自由がもっと大事なものだとするなら、わたしたちはそれらを「自由を減らす」製品と呼ぶべきでしょう。
GNU の第一の目標はフリーソフトウェアであることです。たとえ GNU には技術的に Unix を凌ぐところが全くなかったとしても、ユーザーが協力し合うのを認めるという社会的な優位性があり、ユーザーの自由を尊重するという倫理的な優位性があります。
しかし、よく知られた優れた慣行を作品に適用するのは自然なことでしょう。たとえば、恣意的に固定されたサイズ制限を回避して、意味をなすのであればあらゆる８ビットのコードをどこでも扱えるようデータ構造を動的に割り振ることなどがそうです。
それに加え、わたしたちは１６ビットのマシンをサポートしないことに決めて、Unix が小さいメモリサイズを想定しているのを無視することにしました（GNU のシステムが完成する頃までには３２ビットのマシンが普通になっているだろうというのは明らかだったからです）。また、１メガバイトを越えない限りはメモリの使用量を減らそうと努めるのもやめました。大きなファイルを扱うことがそれほど重要でもないプログラムでは、プログラマーには入力されたファイル全部をコアに読み出して、それから I/O を気にする必要なしに中身をスキャンするように勧めています。
これらの決定により多くの GNU のプログラムが信頼性やスピードの面で Unix における類似品の域を越えることが可能になりました。
GNU プロジェクトの評判が高まるにつれ、プロジェクトに Unix が走っているマシンを寄付したいという申し込んでくれる人たちが現れるようになりました。大変ありがたいことです。というのも、GNU のコンポーネントを開発するもっとも簡単な方法はそれを Unix 上で走らせることであり、またそのシステムのコンポーネントをひとつひとつ入れ替えていくことだからです。
Unix はかつて（今もそうですが）独占ソフトウェアであり、GNU プロジェクトの哲学では独占ソフトウェアは使ってはならないことになっています。しかし、正当防衛のための暴力が認められると結論づける同じ論法で、他の人たちが独占的なパッケージを使うことを止めるのを手助けするフリーな代替物を開発するためにそれが重要な役割を果たす場合は、独占的なパッケージを使うのは正当な行為だという結論に達しました。
しかしこれは必要悪であるにしても、悪であることには違いありません。今日わたしたちはもう Unix のコピーは持っていません。なぜなら、フリーなオペレーティング・システムに取り替えてしまったからです。もしマシンのオペレーティング・システムを交換することが出来いのならば、わたしたちはむしろマシンの方を取り替えるでしょう。
GNU プロジェクトが進行し、立ち上げられたり開発されたりしたシステム・コンポーネントの数が増えるにしたがって、残された間隙のリストを作った方が便利だということになっていきました。わたしたちは欠けている部分を作ってくれる開発者を雇うのにこれを使っていました。このリストは GNU タスクリストという名で知られるようになり、わたしたちは欠けている Unix のコンポーネントだけでなく、真に完成されたシステムに備わっているべきだと考えられるその他のさまざまなソフトウェアやドキュメンテーションのプロジェクトを加えてリストにしていきました。
最近では少数のそれほど重要でないものを除けば GNUタスクリストには Unix のコンポーネントはほとんど残っていません。ですが、人呼んで「アプリケーション」のプロジェクトは目白押しです。それなりの数のユーザーにとって魅力のあるものなら、どのプログラムもオペレーティング・システムに付け加えると便利なものであるわけです。
ゲームもまたタスクリストに含まれており、しかも最初の頃からずっとそうでした。Unix にはゲームが入っていましたから、GNU にも当然そうでなければなりません。しかしゲームに互換性はそれほど問題にならないので、Unix にあるゲームのリストに従うことはしませんでした。そのかわり、ユーザーに喜ばれそうな様々な種類の全ゲームをリストしたのです。
GNU C ライブラリには GNUライブラリ一般公有使用許諾（GNU Library General Public License）という特別なコピーレフトが適用されます。これは独占ソフトウェアにライブラリへのリンクを許可するものです。例外を作った理由ですか？
主義主張とは関係ありません。独占ソフトウェアの製品にはわたしたちのコードが含まれてはならないとする主義など存在しないのです（どうしてわたしたちと共有することを拒否した上に成り立っているプロジェクトに手を貸すのでしょう？）。GNUライブラリ一般公有使用許諾を C ライブラリあるいはその他のライブラリに適用するのには、戦略上の理由があるのです。
C ライブラリはこれといって限定されずにいろいろな仕事をこなすもので、どの独占的システムやコンパイラにも C ライブラリは付属しています。したがって、わたしたちの C ライブラリをフリーソフトウェアでしか使用出来ないようにしても、フリーソフトウェアの有利になることがありません。おそらく、そんなことをしてもわたしたちのライブラリの方を使うのに二の足を踏まれるようになるだけでしょう。
一つのシステムだけは例外です。GNU システム（GNU/Linux を含む）上では、GNU C ライブラリが唯一の C ライブラリです。GNU C ライブラリの配付に関する案件は、GNU システム向けに独占プログラムをコンパイルすることを可能にするかどうか決めることです。GNU システム上に独占的なアプリケーションを認める倫理的な理由は何もありませんが、戦略という面から見ると、これを認めなければフリーなアプリケーションの開発を押し進めるよりも GNU システムを使うのを躊躇させてしまうことの方が多いと思われるのです。
以上のような理由から、C ライブラリにとっては GNUライブラリ一般公有使用許諾を使うのは戦略上望ましいことなのです。他のライブラリにはその都度に状況を踏まえて戦略的な決定をする必要があります。あるライブラリがある特定の種類のプログラムを書くのに便利な特別な役割を果たす場合、GPL の下でリリースしてフリーなプログラムに用途を限定して独占ソフトウェアに対する優位性を与えてあげるのも、他のフリーソフトウェア開発者を手助けするひとつの方法です。
BASH 向けのコマンドライン編集のために開発されたライブラリ、GNU Readline を例に考えてみましょう。Readline は GNUライブラリ一般公有使用許諾ではなく通常の GPL でリリースされました。このため Readline が使われる数は減ったかもしれませんが、それはわたしたちにとって損害でもなんでもありません。それに対して、少なくともひとつの便利なアプリケーションが厳密なフリーソフトウェアを作ったならば、それが Readline を使えるわけで、それこそがコミュニティにとって真の利益になるのです。
独占ソフトウェアの開発者は資金面で優位にあり、フリーソフトウェアの開発者は互いに優位性を与え合っています。いつの日か、独占ソフトウェアと同時に使えるようなことなしに、新しいフリーソフトウェアにおいて建築資材のように提供される便利なモジュールを提供するような、そしてさらなるフリーソフトウェアの開発に大きな優位性を与えてくれる GPL のライブラリのコレクションを手にすることができればいいなと思っています。
エリック・レイモンドは「ソフトウェアのいい仕事はいつも開発者が自分の個人的な痒みを掻くことから始まるものだ」と言っています。確かにそういうこともあるでしょう。しかし、GNU ソフトウェアの中核をなすような大部分は、完全に自由なオペレーティング・システムを作るために開発されたのです。ヴィジョンと計画によって生まれたのであって、衝動からではありません。
例えば、わたしたちは GNU C ライブラリを開発しましたが、それは Unix のようなシステムには C のライブラリが必要だったからです。Bourne-Again Shell は Unix のようなシステムにはシェルが必要だから、GNU tar もまたそれが Unix のようなシステムに必要だからです。わたし自身のプログラムにも同じことがいえます。GNU C コンパイラ、GNU Emacs、GNU Make がそうです。
GNU のプログラムにはわたしたちの自由を脅かすものにうまく対処するために開発されたものもあります。例を挙げれば、gzip は Compress プログラムと置き換えるために開発されましたが、それは Compress が LZW 関連の特許のせいでもうコミュニティのものではなくなってしまったからです。また、わたしたちは LessTif を開発してくれる人たちを見つけ、さらに最近ではある特定の独占的なライブラリによって起こった問題（下記を参照）に対応して GNOME と Harmony を立ち上げました。それから、ポピュラーな非フリーの暗号化ソフトウェアの代替として GNU Privacy Guard を開発しています。なぜなら、ユーザーはプライバシーと自由との間で選択を迫られるべきではないからです。
もちろん、これらのプログラムを書いている人たちはその仕事に興味を持つようになりましたし、多くの機能が様々な人たちによってそれぞれのニーズや関心によって付け加えられました。しかし、そのプログラムが存在する理由はそれだけではないのです。
GNU プロジェクトを始めるにあたり、まず GNU システム全部を作り上げ、それからひとまとめにしてリリースしようと考えていました。しかし実際にはそうはなりませんでした。
完成された GNU システムが出来上がる前に、それぞれのプログラムは Unix システム上で使われ、またそれぞれのコンポーネントは Unix 上で走ることができたために、これらのプログラムの内のいくつかはポピュラーになってユーザーはそれを拡張したり移植したりするようになりました。Unix 互換の様々なバージョンや、時には他のシステムにもです。
こういった過程でプログラムはさらにパワフルになり、GNU プロジェクトに資金と貢献者の両方を引き付けることになりました。しかし、それが実際に稼働する最小限のシステムを完成させるのを何年か遅らせたのかもしれません。GNU の開発者は次第に必要なコンポーネントを書くよりも、移植されたプログラムや既存のコンポーネントにさらに付け加えられた機能をメンテナンスすることに追われるようになったからです。
１９９０年までに GNU システムはほぼ完成していました。残された唯一の主要なコンポーネントはカーネルです。わたしたちはカーネルを Mach の上位に走るサーバープロセスのコレクションとして実装することに決めました。Mach とは当初はカーネギー・メロン大学で、その後ユタ大学で開発されるようになったマイクロカーネルで、GNU HURD は Mach 上で走り Unix カーネルのさまざまなジョブをこなすサーバーのコレクション（別名「herd of gnus」）なのです。開発の開始は Mach がフリーソフトウェアとしてリリースされるまで待っていたので遅れ、それまではずっと開発すると約束されたままの状態でした。
このデザインを選んだ一つの理由は、カーネルのプログラムをそれ用のソース・レベルのデバッガなしにデバッグするという、一番困難であろう作業を避けるべきだったからです。Mach ではこのパートの作業は既に終わっており、HURD サーバーをユーザー向けプログラムとして GDB を用いてデバッグできればいいと考えていました。しかしそれが出来るようになるまでには長い時間がかかり、それぞれにメッセージを送るマルチ・スレッド式のサーバーはデバッグするのが非常に困難なものだということも判明しました。HURD を安定して稼働させるのは何年も先にまで引き延ばされてしまったのです。
GNU のカーネルはもともと HURD という名前になる予定ではありませんでした。最初の名前は Alix で、わたしの当時の恋人にちなんで名付けられたものです。Unix のオペレーターだった彼女が、自分の名前が Unix システムの各バージョンに共通の命名法にぴったりだと言い出しました。彼女が友人に「誰かカーネルにわたしの名前をつけないかしらね」と冗談で話していたのです。わたしは何も言いませんでしたが、彼女を驚かせてやろうとカーネルの名前を Alix にすることに決めました。
それから事情が変わり、中心的なカーネル開発者の Michael Bushnell（現在は Thomas）が HURD という名前の方を気に入って、Alix をカーネルの中でもシステムコールをトラップしたりそれを HURD サーバーにメッセージを送って対処する部分の名称に変更しました。
結局、Alix とわたしは別れてしまい、彼女は別の名前になってしまいました。それとは別に HURD のデザインも変わってしまい、C ライブラリが直接サーバーにメッセージを送るようになったので、デザイン上から Alix の名前は消えてしまいました。
しかし、そうなる前に、彼女の友人が HURD のソースコードの中に Alix の名前を見つけて彼女にそのことを話したので、その名前は役には立ちましたけれど。
GNU HURD はまだ製品レベルに達してはいません。幸運なことに、別のカーネルが使えるようになりました。１９９１年に Linus Torvalds は Unix 互換のカーネルを開発し、それを Linux と名付けました。１９９２年頃、Linux とまだ未完成だった GNU との組み合わせでフリーなオペレーティング・システムが誕生したのです（この組み合わせはもちろんそれ自体意義深いものではありました）。今日では Linux のおかげで GNU のシステムの一つのバージョンを実際に走らせることが出来るようになりました。
わたしたちはこのシステムのバージョンを、GNUシステムの組み合わせとカーネルである Linux の合成を表すために GNU/Linux と呼んでいます。
わたしたちは自分たちには広範囲に渡ってフリーソフトウェアを開発する能力があることを証明してきました。しかしだからといってわたしたちが無敵で誰にも止められないというわけではありません。フリーソフトウェアの将来の見通しを不透明にするような案件がいくつもあり、それに立ち向かうには、時には何年にも及ぶ不断の努力と忍耐が必要になるでしょう。それにはみなさんが自分たちの自由は大切なものであり、他人に奪わせるつもりはないと表明するというような類いの決心が必要になります。
次の四章でその挑戦課題について見ていきましょう。
ハードウェア産業はますますハードウェアの仕様を隠す傾向を強めています。このため、Linux や XFree86 で新しいハードウェアをサポートするためのフリーなドライバを書くのが難しくなっています。今は完成されたフリーのシステムがありますが、次のコンピューターをサポート出来ないのなら、明日もそれがあるというわけにはいきません。
この問題の対処方法は二つあります。ハードウェアをどうサポートするのか見つけ出すために、プログラマーはリバースエンジニアリングすることが出来ます。その他の人たちはフリーソフトウェアがサポートしているハードウェアを使うといいでしょう。その数が増えれば、仕様を隠すのは不利なやり方だということになっていきます。
リバースエンジニアリングは大変な仕事です。それなのに、プログラマーに十分な決意をもってそんなことをさせるというのでしょうか？そうです。フリーソフトウェアとは道徳の問題であり、非フリーのドライバには我慢ならないという強い気持ちをつのらせたならば。ではわたしたちは余分なお金や少々の時間さえ注ぎ込めばフリーなドライバを手にすることが出来るのでしょうか？そうです、自由を手にしようという決意が広まっていけば。
フリーなオペレーティング・システム上で走る非フリーのライブラリはフリーソフトウェアの開発者を罠にかけるようなことをしでかします。ライブラリの魅力的な機能は疑似餌のようなもので、そのライブラリを使えば罠に引っ掛かることになるでしょう。なぜなら、プログラムはフリーな有用なかたちでオペレーティング・システムの一部となることはできないからです（厳密にいえば、そのプログラムを取り入れることは出来ますが、ライブラリがなければ動くことはないのです）。さらに悪いことに、もし独占的なライブラリを使用するあるプログラムがポピュラーになってしまえば、他のスレていないプログラマーも罠に引っ掛かるようにさせてしまうかもしれません。
このようなプログラムの最初の例が Motif ツールキットで、話は８０年代まで遡ります。当時はまだフリーなオペレーティング・システムは存在しなかったのですが、Motif が後々どんな問題を引き起こすことになるかは明らかでした。GNU プロジェクトは、まず個々のフリーソフトウェアのプロジェクトにフリーの X ツールキット・ウィジェットを Motif と同じくらい使ってくれるようお願いし、また誰か Motif を置き換えるフリーな代替物を作ってくれないかと頼むという二つのやり方で応じました。この作業には何年もかかり、Hungry Programmers の手で 開発された LessTif は１９９７年になってようやく大半の Motif アプリケーションをサポートするくらいにパワフルなものになったのです。
１９９６年と１９９８年の間には Qt という別の非フリーな GUI ツールキット用ライブラリが重要なフリーソフトウェアのコレクションであるデスクトップ環境 KDE に使われたことがありました。
ライブラリが使用出来ないため、フリーな GNU/Linux のシステムでは KDE を使うことができませんでした。しかしながら、フリーソフトウェアであることにあまり厳密に遵守しない GNU/Linux の商用ディストリビューターは自分たちのシステム -- 受け入れられ易いものの自由は損なわれたシステム -- に KDE を加えてしまったのです。KDE のグループはもっと多くのプログラマーに Qt を使うよう積極的に働きかけ、何百万もの新しい「Linux ユーザー」がその中に問題が含まれていることを開示されないままになってしまいました。事態は深刻化しました。
フリーソフトウェアのコミュニティはこの問題に二つのやり方でもって応えました。GNOME と Harmony です。
GNU オブジェクトモデル環境、GNOME は GNU のデスクトップ・プロジェクトです。１９９７年に Miguel de Icaza が始め、RedHat ソフトウェアの支援を受けて開発された GNOME は、似たような機能を提供するものですが、フリーソフトウェアのみを使っています。また、C++ だけでなく様々なプログラミング言語をサポートするといった技術的な優位性も備えていますが、その主な目的は自由であり、非フリーのソフトウェアの使用を必要としないことなのです。
Harmony は互換性のある代替ライブラリで、KDE のソフトウェアを Qt を使わずに走らせることを可能にするようデザインされています。
１９９８年の十一月に Qt の開発者はライセンスを変更し、それが発効されれば Qt はフリーソフトウェアになると発表しました。断言はできませんが、それは非フリーだった時代の Qt には問題があったとしてコミュニティが断固として対処してきた成果でもあると思われます（この新しいライセンスは不便かつ不公正なもので、Qt の使用を避けるのは望ましいままです）。
（追記：２０００年の九月に Qt は GNU GPL の下でリリースされ、それによりこの問題はすっかり解決されました）
次なる誘惑となる非フリーのライブラリにわたしたちはどう対処するでしょうか？罠にはまらないでいるようにしなければならないとコミュニティ全体が理解していられるでしょうか？あるいは利便性に負けてわたしたちは自由をあきらめ、大きな問題を引き起こすことになるのでしょうか？それとも、わたしたちの未来は自分たちの哲学にかかっているのでしょうか？
わたしたちが直面することになった最悪の脅威は、ソフトウェアの特許から生じたものでした。それによりフリーソフトウェアはそのアルゴリズムと機能から２０年に渡って締め出されてしまうような事態も起きかねないのです。LZW 方式による圧縮のアルゴリズムの特許は１９８３年に適用され、わたしたちは未だに GIF ファイル形式に適切に圧縮するフリーソフトウェアをリリースできないでいます。１９９８年には、MP3 形式に圧縮されたオーディオ・ファイルを作成するフリーのプログラムが特許侵害の訴訟を恐れてディストリビューションから外されました。
特許に対抗する方法はさまざまです。特許が不適切なものであるという証拠を探し出したり、同じことを別の方法で実現するやり方を見つけたりすることも可能でしょう。しかし、どちらもごくたまにしか功を奏さないのです。もしどちらも失敗に終われば、特許により全てのフリーソフトウェアはユーザーが求める機能のなにがしかを欠いたままであることを強いられてしまうかもしれません。
わたしたちのようにフリーソフトウェアを自由のために価値あるものだとする人なら、いずれにせよそのままフリーソフトウェアを使い続けるでしょう。特許に守られた機能なしになんとか作業をやり遂げるつもりです。しかし技術的優位性があるだろうという理由からフリーソフトウェアを価値あるものだとする人たちは、特許の邪魔が入れば、それは失敗だったと言い出しかねません。ゆえに、確かに「伽藍」という開発モデルの有効性やフリーソフトウェアの高い信頼性とパワーについて語るのは有用なことではありますが、そこで留まっているわけにはいきません。わたしたちは自由と主義のことを話し合うべきなのです。
わたしたちのフリーなオペレーティング・システムに最も不足しているものは、ソフトウェアの分野にはありません。システムに取り入れられるフリーの優れたマニュアルが足りないのです。ドキュメンテーションはどのソフトウェアのパッケージでも重要なパートを担っているわけですから、大事なフリーソフトウェアのパッケージに優れたマニュアルが付属していなければ、それは大きな欠陥となってしまいます。最近ではこの手の欠陥がたくさんあるのです。
フリーなドキュメンテーションとは、フリーソフトウェアと同じく、自由に関わることであって、値段のことではありません。フリーなマニュアルであることの基準は、フリーソフトウェアとほぼ同じで、全てのユーザーに確かな自由を与えるかが問われることになります。マニュアルをプログラムのあらゆるコピーに同梱できるように、オンラインでも紙媒体でも再配布（商用利用も含む）が許可されていなければなりません。
修正する自由があることも同じく重要です。原則として、わたしは許諾を得てあらゆる種類の本や記事を修正するというのが大事なことだとは信じていません。たとえば、わたしやあなたがこの文章を修正するのに許可を与える義務があるとは思いません。そのことがわたしたちの活動や見解を物語っているわけです。
しかし修正の自由がフリーソフトウェア用のドキュメンテーションにとって重要であるのには特別な理由があります。ソフトウェアを修正したり、機能を付加したり変えたりする自由を行使する場合、良心的な人ならマニュアルも変更しようとするでしょう。そうすれば正確で有用なドキュメンテーションを修正したプログラムと一緒に提供できるようになるからです。プログラマーに良心的になって作業を完成させることを許さないようなマニュアルは、わたしたちのコミュニティのニーズを満たさないのです。
修正方法の制限については別に問題はありません。たとえば原作者の著作権表示を残すといった制限は、配付に関して、または作者名リストについては構わないでしょう。修正されたバージョンにはそのことを明記するよう求めること、そのセクション全体が技術的な事柄でない事項を扱うものである限りは消したり変更してはならないと求めることも問題はありません。この種の制限は問題とはなりません。良心のあるプログラマーに修正されたプログラムに合ったマニュアルを添付することを止めさせたりはしないからです。言い換えれば、フリーソフトウェアのコミュニティが役に立つマニュアルを作るのを邪魔したりはしないからです。
しかし、「技術的な」部分についてはどこでも修正し、それを普通に考えられるあらゆる媒体で、あらゆる手段でもって配付することが可能でなければなりません。そうでなければ、規制がコミュニティの障害となり、マニュアルはフリーではなくなるので、また別のマニュアルを作らなければならなくなってしまいます。
フリーソフトウェアの開発者は一連のフリーのマニュアルを作る意識と意志を持つようになるでしょうか？もう一度いいます。わたしたちの未来はその哲学にかかっているのです。
最近の見積もりでは Debian GNU/Linux や Red Hat Linux のような GNU/Linux システムのユーザーは一千万人に上ります。フリーソフトウェアはユーザーが純粋に実用的な理由から集まってくるような実際的な利点のあるものを開発してきたのです。
この良い影響は明白です。フリーソフトウェアの開発にさらに関心が集まり、フリーソフトウェアにはさらに多くの顧客が引き寄せられ、企業には独占ソフトウェア製品ではなく商用フリーソフトウェアを開発することを一層強く促してくれます。
しかしソフトウェアへの関心はそれが基づく理念に対する意識よりも急速に高まっており、これがトラブルを引き起こしています。試練や上記したような脅威に立ち向かうわたしたちの力は、自由のために断固立ち向かう意志いかんによるのです。
わたしたちはそれを怠ってきました。新しいユーザーをコミュニティに引き付ける努力の方が、コミュニティの一員としてのあり方を広めることをはるかに超えて広まっています。わたしたちはその両方をやらなければならず、双方のバランスをとっていく必要があるのです。
１９９８年には新しいユーザーに自由について伝えることがより重要になった出来事がありました。コミュニティの一部が「フリーソフトウェア」という用語を使うのをやめて、その代わりに「オープンソース・ソフトウェア」と言い出したのです。
「自由」と「無料」の混同を避ける目的でこの用語を好んだ人もいました -- 目的は正しいものです。しかし、その他の人たちはフリーソフトウェア運動と GNU プロジェクトを突き動かしてきた主義を拒絶し、会社の重役やビジネス・ユーザー、それに自由やコミュニティ、主義よりも利益を重視するイデオロギーを抱く大勢の人たちにアピールする目的でした。「オープンソース」のレトリックは高クオリティのパワフルなソフトウェアを強調していますが、自由という思想や主義を避けているのです。
いわゆる「Linux」関連の雑誌がこの明白な例です。そこは GNU/Linux 上で動く独占ソフトウェアの広告でいっぱいです。次の Motif や QT が現れたら、この手の雑誌はプログラマーにそれらのものから離れているよう警告してくれるでしょうか、それともその手の製品の広告を打つのでしょうか？
ビジネスによるサポートがコミュニティに貢献するやり方はたくさんあり、どれも公平で有用なものばかりです。しかし自由や主義についてなるべく話そうとせずにサポートを得ようとするのはひどい事態を招きかねません。先に述べた外部への働きかけとコミュニティの一員としてのあり方を伝えていくことの間のバランスがさらに悪くなってしまうのです。
「フリーソフトウェア」と「オープンソース」はソフトウェアのほぼカテゴリーを表す言葉ですが、ソフトウェアと価値観については違ったことを唱えています。GNU プロジェクトは「フリーソフトウェア」という言葉を使い続けます。ただ技術的なことを表すのではなく、自由という理念を表現することが重要だからです。
スターウォーズのヨーダの哲学（「試す」はナシだ）は適切なものかもしれませんが、わたしの役には立ちません。作業のほとんどは本当にこれが出来るのか心配なままやってきたもので、それにもしこれをしたとしても、それで目的の達成には十分なのか確信は持てないままでした。しかしそれでもやってみたのです。なぜなら押し寄せる敵と我が領地の間にはわたししかいませんでしたから。自分でも驚いたことに、時には成功をおさめることだってありました。
ときには失敗もしました。いくつかの領地は陥落してしまいました。そのときは危機にある別の街を見つけ、また別の戦闘に備えました。長いこと、わたしは脅威を発見し、我が身をその脅威と自分の街との間に投げ出し、他のハッカーたちにこっちに来て一緒にやろうと呼び掛けてきたのです。
今日では、わたしはたいてい一人きりではありません。大勢のハッカーたちが戦線を持ちこたえさせんと我武者らになっているのを見るのと安心して喜ばしい気持ちになり、そして確信するのです。この街は大丈夫だと -- 今のところは。しかし危険は年を追う毎に大きくなっており、今やマイクロソフト社はあからさまにわたしたちのコミュニティをターゲットにしています。自由を軽視するわけにはいきません。当然のことだと思ってはいけないのです！自分の自由を守りたいのなら、それを守る備えをしておかなければいけません。