thegnuproject.html (80441B)
1 <!--#set var="ENGLISH_PAGE" value="/gnu/thegnuproject.en.html" --> 2 3 <!--#include virtual="/server/header.ja.html" --> 4 <!-- Parent-Version: 1.96 --> 5 <!-- This page is derived from /server/standards/boilerplate.html --> 6 <!--#set var="TAGS" value="gnu-history" --> 7 <!--#set var="DISABLE_TOP_ADDENDUM" value="yes" --> 8 9 <!-- This file is automatically generated by GNUnited Nations! --> 10 <title>GNUプロジェクトについて - GNUプロジェクト - フリーソフトウェアファウンデーション</title> 11 <style type="text/css" media="print,screen"><!-- 12 a[href*='#ft'] { font-size: .94em; } 13 --> 14 </style> 15 <meta http-equiv="Keywords" content="GNU, GNUプロジェクト, FSF, 自由ソフトウェア, フリーソフトウェアファウンデーション, 歴史" /> 16 17 <!--#include virtual="/gnu/po/thegnuproject.translist" --> 18 <!--#include virtual="/server/banner.ja.html" --> 19 <!--#include virtual="/gnu/gnu-breadcrumb.ja.html" --> 20 <!--GNUN: OUT-OF-DATE NOTICE--> 21 <!--#include virtual="/server/top-addendum.ja.html" --> 22 <div class="article reduced-width"> 23 <h2>GNUプロジェクト</h2> 24 25 <address class="byline"><a href="https://www.stallman.org/">リチャード・ストールマン</a>著</address> 26 27 <h3>最初のソフトウェア共有コミュニティ</h3> 28 <p> 29 1971年に<abbr title="Massachusetts Institute of 30 Technology">MIT</abbr>人工知能研究所(AIラボ)で働き始めたとき、わたしは何年も前からあったソフトウェア共有コミュニティの一員になりました。ソフトウェアの共有は、わたしたちのそのコミュニティに限られたことではありませんでした。ちょうどレシピの共有が料理と同じくらい古くからあるのと同じように、コンピュータと同じくらい古くからあったことでした。しかし、わたしたちは、それをほとんどのところよりも、もっと、行ったのです。</p> 31 <p> 32 AIラボは<abbr title="Incompatible Timesharing System">ITS</abbr> (Incompatible 33 Timesharing 34 System)と呼ばれるタイムシェアリング・オペレーティング・システムを使っていました。これは、研究所のスタッフのハッカーたち <a 35 href="#ft1">[1]</a>により、当時の大きなコンピュータのひとつ、DEC製<abbr title="Programmed Data 36 Processor">PDP</abbr>-10用に設計され、アセンブリ言語で書かれていました。このコミュニティの一員として、またAIラボのスタッフのシステム・ハッカーとして、このシステムを改善していくことがわたしの仕事でした。</p> 37 <p> 38 わたしたちは自分たちのソフトウェアを「自由ソフトウェア」とは呼んでいませんでした。なぜなら、その用語はまだ存在していなかったからです。しかし、それはそういうものでした。他の大学や会社からやって来た人がプログラムを移植して使いたいときはいつでも、わたしたちは喜んでそうさせました。もし誰かがめずらしくて面白そうなプログラムを使っているのを見たら、いつだってソースコードを見せてくださいと頼めました。そして、それを読み、書き換え、もしくは、その一部を取り出して新しいプログラムにすることができたのです。</p> 39 40 <div class="announcement comment" role="complementary"> 41 <hr class="no-display" /> 42 <p> 43 なぜ、それがかつてないほどに重要なのか、<a 44 href="/philosophy/free-software-even-more-important.html">わたしたちが使うソフトウェアは自由でなければならないと主張しましょう</a>。 45 </p> 46 <hr class="no-display" /> 47 </div> 48 49 <h3>コミュニティの崩壊</h3> 50 <p> 51 DEC社がPDP-10シリーズを製造中止した1980年代の初め、状況は大きく変わってしまいました。60年代にはエレガントでパワフルだったそのアーキテクチャは、80年代に実用可能になった、より大きなアドレス空間に、自然に拡張することが出来なかったのです。これはITSを形成していたプログラムの大半がもう時代遅れになってしまったということでした。</p> 52 <p> 53 AIラボ・ハッカー・コミュニティは、既に、その前に崩壊していました。1981年にスピン・オフの会社SymbolicsがAIラボのほぼ全てのハッカーを引き抜いてしまい、人数の減ったコミュニティは立ち行かなくなっていたのです。(スティーブ・レビィ著、<cite>ハッカーズ</cite>、にはこれらの出来事や全盛期の頃のこのコミュニティの姿が活き活きと描かれています。) 54 AIラボが1982年に新しいPDP-10を購入したとき、管理者はITSではなくDEC社の不自由なタイムシェアリング・システムを使うことを決定しました。</p> 55 <p> 56 VAXや68020のような当時の先進的なコンピュータは専用のオペレーティング・システムを備えていましたが、どれも自由ソフトウェアではありませんでした。つまり、実行可能なコピーを入手するためだけでも非開示契約を結ぶ必要があったのです。</p> 57 <p> 58 ということは、コンピュータを使う最初の段階で、周りの人を手助けしない、と約束するということでした。協力し合うコミュニティは禁じられてしまったのです。プロプライエタリなソフトウェアの所有者によって作られたルールとは「もしお前が隣人と分かち合うなら、お前は海賊だ。変更を加えたいのなら、われわれに頼み込んで作ってもらうことだ」というものなのです。</p> 59 <p> 60 プロプライエタリなソフトウェアの社会システムという考え—ソフトウェアを共有したり変更したりするのは許されないとするシステム—は反社会的であり、倫理に反し、ただ単純に間違っているのだという考え方に、読者の方々は驚かれるかもしれません。しかし社会を分断し利用者が手も足も出ないようにされてしまうことの上に築かれたシステムについて、他に何と言い様があるでしょう。この考え方に驚く方は、プロプライエタリなソフトウェアの社会システムを与えられたものとして受け止め、プロプライエタリなソフトウェアのビジネスが提唱する用語で判断しているのではないでしょうか。ソフトウェア会社はこの問題の見方は一つしかないと人々に信じさせるために長いこと非常な作業を重ねてきたのです。</p> 61 <p> 62 ソフトウェア会社が「権利を」「行使する」あるいは「<a 63 href="/philosophy/words-to-avoid.html#Piracy">海賊版</a>を止める」と語るとき、彼らが<em>語っている</em>ことは実際には二の次なのです。この言明の真のメッセージは、彼らが当然であるとみなし、あえて口にしていない前提条件の方にあります。つまり、社会は彼らのことを無批判に受け入れるべきだというわけです。ではその点について吟味してみましょう。</p> 64 <p> 65 一つ目の前提は、ソフトウェア会社は自分たちのソフトウェアについてソフトウェアを所有するという議論の余地がない自然権を有しており、したがってその全ての利用者を支配する権力を持つということです。(もしこれが自然権であれば、それが公衆にどんな害を与えようと、わたしたちは反対できません。) 66 面白いことに、合衆国憲法と法の伝統ではこの見方は否定されています。著作権は自然権ではなく、利用者のコピーする自然権を制限する、人工的な政府が強いる独占なのです。</p> 67 <p> 68 もうひとつの語られざる前提条件とは、ソフトウェアに関して唯一重要なことはそれがどんな作業をさせてくれるかであって、どんな社会に暮らすことができるかについてわれわれコンピュータの利用者は気にかけるべきではないというものです。</p> 69 <p> 70 三番目の前提条件は、会社にプログラムの利用者を支配する力をさしださなければ、わたしたちには使えるソフトウェアは手に入らない(あるいはプログラムにあれやこれやの特定の作業をさせることがまるっきり不可能だ)ということです。この仮定はまことしやかに聞こえました、自由ソフトウェア運動が鎖を負わせることなく、豊富な便利なソフトウェアを作りだせることを実際にやってみせる前は。</p> 71 <p> 72 これらの前提条件を拒否して、それぞれの問題を利用者を第一に考えて普通の常識的な道徳に照らし合わせて判断するならば、全く別の結論が導き出されます。コンピュータの利用者は自分のニーズに合わせてプログラムを変更し、ソフトウェアを共有する自由がなければなりません。なぜなら、他人の手助けをすることは社会の基本なのですから。</p> 73 <p> 74 この結論を裏付ける論旨について十分に述べる余地はここにはありません。詳しくは、こちらのウェブページ「<a 75 href="/philosophy/why-free.html">ソフトウェアに所有者がいてはならない理由</a>」と「<a 76 href="/philosophy/free-software-even-more-important.html">自由ソフトウェアはいまやさらに重要だ</a>」を参照してください。 77 </p> 78 79 <h3>冷厳なる道徳の選択</h3> 80 <p> 81 コミュニティがなくなってしまい、以前と同じように活動を続けていくのは不可能になってしまいました。その代わりに、わたしは厳しい道徳的な選択に直面することになったのです。</p> 82 <p> 83 容易な選択は、プロプライエタリなソフトウェアの世界に参加して、非開示契約を結んで仲間のハッカーたちを手助けしないと約束することでした。その場合、おそらく、わたしは非開示契約のソフトウェアも開発し、したがって、他の人たちにも自分たちの仲間を裏切るよう圧力をかけるようになっていたでしょう。</p> 84 <p> 85 このやり方でお金を儲けることも出来たでしょう。そしておそらくコードを書くことを楽しんだかもしれません。しかしキャリアの終わりには、人々を隔てる壁を築いてきた何年もの日々を思い返し、自分の人生を世界をより悪いものにするために費やしてきたと感じるようになるのは分かっていました。</p> 86 <p> 87 わたしには既に非開示契約を受け取る当事者になった経験がありました。ある人がわたしとMITのAIラボにわたしたちのプリンタを制御するプログラムのソースコードを渡すことを拒否したときのことです。(このプログラムにはある特定の機能がなかったので、プリンタを使うのにはひどくいらいらさせられていました。) 88 ですから、非開示契約には罪はない、と自分自身に言うことはできませんでした。向こうがわたしたちと共有し合うことを拒否したときには本当に怒りました。わたしは振り返って、みんなを同じ目にあわせることなどできません。</p> 89 <p> 90 もうひとつの選択肢は、まっすぐではあるけれどもうれしくないもので、コンピュータの世界から去ることです。そのやり方ではわたしのスキルは間違った使われ方はしませんが、無駄になってしまうことには変わりありません。わたし自身がコンピュータの利用者を分断したり制限したりする過ちを犯すことはありませんが、それでもそういうことは起こるでしょう。</p> 91 <p> 92 そこでわたしはプログラマが正しいことをできるようになるための方法を探しました。自分に書けるプログラムはあるだろうか、それでもう一度コミュニティを作ることができるようになるだろうか、と自分に聞いてみました。</p> 93 <p> 94 答えは明らかでした。最初に必要だったのはオペレーティング・システムです。コンピュータを使うには重要なソフトウェアです。オペレーティング・システムがあれば、たくさんのことが出来るようになります。なければ、コンピュータを走らせることがまったく出来ません。自由なオペレーティング・システムがあれば、わたしたちはもう一度ハッカーたちが協力し合える—そして誰でも勧誘できるようなコミュニティを持つことが出来るのです。そうすれば自分の友人たちを拒むたくらみから始めることなく、誰もがコンピュータを使うことが出来るようになるでしょう。</p> 95 <p> 96 オペレーティング・システムの開発者として、わたしにはこの仕事に相応しいスキルがありました。だから、成功の見込みがあるわけではなかったのですが、わたしは自分がこの仕事をするよう選ばれたのだと気付いたのです。移植性が高くなるだろうという理由から、システムはUnixと互換性のあるものにすることを選びました。それに、そうすれば 97 Unixの利用者も容易に乗り換えることができるでしょう。GNUという名前はハッカーの伝統に従って、“GNU's Not 98 Unix”(GNUはUnixではない)の再帰頭字語として選ばれました。これは<a 99 href="/gnu/pronunciation.html">硬い <i>g</i> の一音節</a>で発音されます。</p> 100 <p> 101 オペレーティング・システムというのはせいぜい他のプログラムを実行するのに足るだけのカーネルだけを意味するわけではありません。1970年代には、オペレーティング・システムの名に相応しいものであれば、どれにもコマンド・プロセッサやアセンブラ、コンパイラ、インタプリタ、テキストエディタ、メイラ、そしてもっとたくさんのものが含まれていました。ITSでも、Multicsでも、VMSでも、Unixでもです。GNUのオペレーティング・システムにもそれらは含まれるようにするつもりでした。</p> 102 <p> 103 後になってヒレル <a href="#ft2">[2]</a>のものとされる次のような言葉を知りました。</p> 104 105 <blockquote><p> 106 わたしが自分のために存在するのでなければ、いったい誰がわたしのために存在する?<br /> 107 わたしが自分のためだけに存在するとすれば、わたしはいったい何ものだ?<br /> 108 今でなければ、いったいいつ? 109 </p></blockquote> 110 <p> 111 GNUプロジェクトを始めようという決意も同じような精神に基づいてのことでした。</p> 112 113 <h3>自由としてのフリー</h3> 114 <p> 115 自由ソフトウェアの英語“free 116 software”は、ときに誤解を生みます。値段とは関係ないのです。自由についてなのです。ですから、ここで自由ソフトウェアの定義を述べます。</p> 117 118 <p>ある特定の利用者であるあなたにとって、あるプログラムが自由ソフトウェアであるとは、</p> 119 120 <ul> 121 <li>そのプログラムをあなたの欲するままにどんな目的のためにでも実行する自由があること。</li> 122 123 <li>あなたの必要に応じて、そのプログラムを変更する自由があること。(この自由を実際に実効的にするために、ソースコードへのアクセスがあることが必須です。ソースコードなしにあるプログラムに変更を加えることは、大変な困難を伴うからです。)</li> 124 125 <li>無償あるいは有償のどちらでも、コピーを再配布する自由があること。</li> 126 127 <li>そのプログラムの変更した版を配布する自由があり、コミュニティがあなたの改善による利益を享受できること。</li> 128 </ul> 129 <p> 130 「フリー」は自由のことをいうのであって、値段のことではありません。ですから、コピーを販売することと自由ソフトウェアであることに矛盾は全くありません。事実、コピーを販売する自由は重要です。というのも自由ソフトウェアのコレクションのCD-ROMを販売するのはコミュニティに大切なことであり、また、それを販売することは自由ソフトウェア開発のための資金調達をする重要な手段だからです。それゆえに、この中に収録することができないプログラムは自由ソフトウェアではありません。</p> 131 <p> 132 「フリー」という語の曖昧さのせいで、人々はそれに代わる別のものを探してきました。しかし、誰もぴったりくるような別の代わりを見つけられなかったのです。英語には他のどの言語よりもたくさんの言葉やニュアンスがありますが、しかし「フリー」を自由の意で表すシンプルで明白な単語がありません—“unfettered”(足枷のない、自由な)という語が意味の上で最も近いところにありますが。“liberated”、“freedom”、“open”のような候補にも間違った意味やその他の不都合がありました。</p> 133 134 <h3>GNUソフトウェアとGNUシステム</h3> 135 <p> 136 システム全体を開発するというのは巨大なプロジェクトです。それを実現可能なところにもっていくため、わたしは既存の自由ソフトウェアを可能であればなんでも採用し、使用することにしました。たとえば、開始当初にTeXを主要なテキスト・フォーマット・ツールとして採用するに決めました。その数年後には、GNU向けに別のウィンドウ・システムを作るよりもXウィンドウ・システムを使うことに決めました。</p> 137 <p> 138 この決定と同じようなそのほかの決定により、GNUシステムは全GNUソフトウェアのコレクションと同じものではなくなりました。GNUシステムにはGNUソフトウェア以外のプログラムも含まれます。それらのプログラムは他の人たちによってそれぞれの目的に応じて開発されますが、自由ソフトウェアなのでわたしたちも使うことが出来ます。</p> 139 140 <h3>プロジェクトの開始</h3> 141 <p> 142 1984年の一月にわたしはMITを辞めてGNUソフトウェアを書き始めました。MITがGNUを自由ソフトウェアとして配布するのを妨げることができないようにするためにMITを去る必要があったのです。もしわたしがスタッフとして残っていたなら、MITはその仕事の所有を主張し、自分たちの配布条件を押し付けたり、プロプライエタリなソフトウェアとしてしまうことさえ可能だったでしょう。わたしには自分のやってきた大量の仕事をむざむざ無駄になるに任せるつもりはありませんでした。新しいソフトウェア共有のコミュニティを作るのが目的なのですから。</p> 143 <p> 144 しかしながら、当時MITのAIラボを率いていたウィンストン教授のご好意により、研究所の施設を使い続けさせていただくことができました。</p> 145 146 <h3>最初の一歩</h3> 147 <p> 148 GNUプロジェクトを始めるちょっと前、VUCKという名でも知られる自由大学コンパイラ・キット(オランダ語で「自由」は<i>V</i>で始まります)のことを聞きました。これはCやPascalを含む複数の言語を扱えるよう作られたコンパイラで、複数のターゲトマシンをサポートするとのことでした。わたしは作者にGNUでこれを使えないかどうかと質問を送りました。</p> 149 <p> 150 大学は自由だがコンパイラそうではない、と述べたあざけるような返事を彼は送ってきました。そこで、わたしはGNUプロジェクトの最初のプログラムは複数言語に対応した、複数のプラットフォーム向けのコンパイラに決めたのです。</p> 151 <p> 152 自分で一からコンパイラを書き上げる手間を省くため、Pastelというコンパイラのソースコードを手に入れました。これはローレンス・リバモア研究所で開発された複数プラットフォーム対応のコンパイラです。拡張されたPascalをサポートし、またその言語で書かれたもので、システム・プログラミングのために設計されたものでした。わたしはC言語のフロントエンドを追加し、モトローラ68000コンピュータのための移植を始めました。しかしコンパイラがスタック空間に何メガバイトも必要とするのに、利用できる68000 153 Unixシステムでは64kしかないかもしれないことが分かって諦めることになりました。</p> 154 <p> 155 Pastelコンパイラは入力ファイル全体を構文木に解析し、構文木全体を一連の「命令」に変換し、それから出力ファイル全体を生成することが分かりました。メモリを一切解放せずにです。ここで、わたしは新しいコンパイラを一から作らなければならないだろうという結論に達したのです。そのコンパイラは今は<abbr 156 title="GNU Compiler 157 Collection">GCC</abbr>として知られています。Pastelからのものは何も使用されておらず、自分で書いたCのフロントエンドをどうにか適応して使いました。しかしそれは数年後のことです。まず最初に、わたしはGNU 158 Emacsの作業に取りかかりました。</p> 159 160 <h3>GNU Emacs</h3> 161 <p> 162 GNU 163 Emacsには1984年の9月に取りかかり、1985年の早くには使えるようになりました。これでUnixシステムを編集作業に使うことが出来ます。viやedの修得には興味がなかったので、それまで編集には別の種類のマシンを使っていたのです。</p> 164 <p> 165 この時点から、みんなが 166 GNUEmacsをほしがるようになりました。そのため、どうやってこれを配布するかの問題が発生したのです。もちろん、わたしはこれを自分が使っていたMITの匿名ftpサーバに置きました。(このコンピュータ、prep.ai.mit.eduは、こうして主要なGNU 167 ftp配布サイトになったのです。数年後にその役目を終えると、わたしたちは新しいftpサーバに名前を移転させました。) 168 しかし、当時興味を持ってくれた多くの人たちがインターネット環境にはおらず、ftp経由でコピーを手にすることが出来ませんでした。そこで問題は、この人たちには何と言えばいいか、でした。</p> 169 <p> 170 「ネットに繋がっていてコピーしてくれる友達を見つけてください」と伝えることも出来たでしょう。あるいはオリジナルのPDP-10 171 Emacsでやったことを自分ですることも可能でした。彼らに「テープと<abbr title="Self-addressed Stamped 172 Envelope">SASE(返信用住所記入済み切手付封筒)</abbr>を送ってくれれば、Emacsを入れて送り返します」と言うのです。しかし、わたしには仕事がなく、自由ソフトウェアからお金を得る方法を探していました。そこで、150ドルでテープを発送しますと発表しました。このやり方でわたしは自由ソフトウェア配布ビジネスを始めました。GNU/Linuxシステム・ディストリビューション全体を配布している今日の会社の先駆者となったわけです。</p> 173 174 <h3>プログラムはすべての利用者に自由なのか?</h3> 175 <p> 176 あるプログラムが作者の手を離れたとき自由ソフトウェアであったとしても、そのコピーを持っている全ての人にとって自由ソフトウェアであるとは限りません。たとえば、<a 177 href="/philosophy/categories.html#PublicDomainSoftware">パブリック・ドメイン・ソフトウェア</a>(著作権が主張されないソフトウェア)は自由ソフトウェアですが、誰でもそのプロプライエタリな版を作ることが出来ます。同じく、多くの自由ソフトウェアには著作権が主張されますが、単純な容認のライセンスのもとで配布されています。これは、プロプライエタリな変更版を許します。</p> 178 <p> 179 この問題の典型的な例がXウィンドウ・システムです。MITで開発され、容認のライセンスで自由ソフトウェアとしてリリースされましたが、すぐに多くのコンピュータ関連会社によって採用されました。彼らはXを自分たちのプロプライエタリなUnixシステムにバイナリ形式のみで組み込み、同じ非開示契約によって覆ってしまったのです。これらのXのコピーはUnixと同様にもはや自由ソフトウェアではなくなりました。</p> 180 <p> 181 Xウィンドウ・システムの開発者たちはこれを問題とは考えていませでんした。彼らはこうなることを期待し、それを意図していたのです。彼らの目標は自由ではなく、「多くの利用者を獲得する」という意味でただ「成功する」ことでした。彼らは利用者が自由を得ることなどどうでもよくて、大勢になりさえすればそれでよかったのです。</p> 182 <p> 183 これによって、「このプログラムは自由なのか。」という問いに対して、自由の量を計る二つの異なるやり方がそれぞれ別の答えを出してしまうような逆説的な状況が生まれました。MITのリリースの配布条件が与える自由に従って判断すれば、Xは自由ソフトウェアと言えたでしょう。しかしXの平均的な利用者の自由を調べれば、これはプロプライエタリなソフトウェアと言わざるを得ませんでした。ほとんどのXの利用者は自由な版ではなく、Unixシステムと一緒になったプロプライエタリな版を走らせていたからです。</p> 184 185 <h3>コピーレフトとGNU GPL</h3> 186 <p> 187 GNUの目標は利用者に自由を与えることで、単に人気を得ることではありません。ですから、わたしたちはGNUのソフトウェアがプロプライエタリなソフトウェアに変わることを防ぐ配布条件を使用する必要がありました。わたしたちが使っているこの方法は「コピーレフト」 <a 188 href="#ft3">[3]</a>と呼ばれています。</p> 189 <p> 190 コピーレフトは著作権法を利用してはいますが、それをひっくり返して通常とは反対の目的のために使っています。つまり、プログラムを制限するための手段としてではなく、プログラムを自由のままにしておく手段となるように。</p> 191 <p> 192 コピーレフトの中心的な考え方は、全ての人にそのプログラムを実行し、コピーし、変更し、変更した版を再配布する許可を与え、制限事項を加えることには許可を与えるないというものです。したがって、それが「自由ソフトウェア」であると決定するような大切な自由というものは、そのコピーを持っている人たち全てに保証される、不可侵の権利になるのです。</p> 193 <p> 194 コピーレフトを効果的なものにするために、変更された版も自由でなければなりません。これにより、わたしたちのものをもとにした作品が公開された場合、それがわたしたちのコミュニティに入手可能であるよう保証されます。プログラマとしての仕事を持っている人がボランティアでGNUソフトウェアを改善したとき、それはコピーレフトなので雇用主に「我々のプロプライエタリな版を作るのに使用するから変更した部分を共有してはいけない」とは言わせないようになっています。</p> 195 <p> 196 そのプログラムの利用者すべての自由を保証したいのであれば、変更に対して、自由でなければならないとの要求が不可欠になります。Xウィンドウ・システムを私物化する会社はたいてい自分たちのシステムやハードウェアに移植する際に何らかの変更を加えています。これらの変更はXの大部分と比べれば小さなものではあるでしょうが、だからといって取るに足らないものではありません。もし変更を加えることが利用者の自由を否定するための言い訳になってしまうなら、その言い訳につけこむのは誰にとっても簡単なことでしょう。</p> 197 <p> 198 これと関連して、自由のプログラムを不自由なのコードと結合させることの問題があります。そのような組み合わせは不可避的に不自由となってしまいます。不自由な部分にたとえどんなものであっても自由が欠けているなら、全体もまた同じなのです。そのような組み合わせを認めてしまえば、船を沈めるには十分な穴を開けてしまうことになりかねません。ゆえに、コピーレフトに必ず要求されるのはこのような穴に栓をすることです。コピーレフトのプログラムに付加される、あるいは組み合わされるのが何であれ、結合された版もまた自由でコピーレフトでなければならないのです。</p> 199 <p> 200 コピーレフトの特定の実装でわたしたちがほとんどのGNUソフトウェアに用いているのがGNU一般公衆ライセンス、略してGNU 201 GPLです。また特定の状況で使用する別種のコピーレフトもあります。GNUマニュアルもコピーレフトされてますが、マニュアルに複雑なGNU 202 GPLは必要ないので、もっと簡潔なコピーレフトを使っています。 <a href="#ft4">[4]</a></p> 203 204 <h3>フリーソフトウェアファウンデーション</h3> 205 206 <p>Emacsを使うことに関心が集まってくるにしたがって、GNUプロジェクトに参加する人が増えてきました。そこでわたしたちはそろそろ資金調達の方法を再考してみようと決めました。そして1985年に自由ソフトウェア開発のための税控除の対象となる福祉団体、<a 207 href="https://www.fsf.org/">フリーソフトウェアファウンデーション</a>(FSF)を創設したのです。<abbr 208 title="Free Software 209 Foundation">FSF</abbr>はEmacsのテープ配布ビジネスも引き継ぎ、後にはこれに(GNUと非GNUの両方の)他の自由ソフトウェアをテープに加え、さらには自由のマニュアルも販売するなど拡大していきます。</p> 210 211 <p>かつて、FSFの収入の大半は、自由ソフトウェアのコピーやその他の関連サービスの販売(ソースコードのCD-ROMやバイナリのCD-ROM、かっこうよく印刷したマニュアル、全て再配布、変更は自由です)、そして豪華版ディストリビューション(顧客の選択したプラットフォーム向けのソフトウェアのコレクション全体をビルドしたもの)から得たものでした。今日も、FSFは<a 212 href="https://shop.fsf.org/">マニュアルやその他のグッズの販売</a>をしていますが、多くの資金を会員の会費から得ています。あなたも、こちら<a 213 href="https://fsf.org/join">fsf.org</a>からFSFに参加できます。</p> 214 215 <p>フリーソフトウェアファウンデーションの職員は多くのGNUソフトウェア・パッケージを書き、またその保守をしてきました。特記すべきはCライブラリとシェルでしょう。GNU 216 CライブラリはGNU/Linux上で走るどのプログラムもLinuxとのやり取りに使用しています。これはフリーソフトウェアファウンデーションのスタッフ、ローランド・マクグラスによって開発されました。大半のGNU/Linuxシステムで使われているシェルが<abbr 217 title="Bourne Again Shell">BASH</abbr>、Bourne Again Shell <a 218 href="#ft5">[5]</a>で、FSFの職員であるブライアン・フォックスによって開発されました。</p> 219 220 <p>GNUプロジェクトはツールや開発環境に留まるものではないので、わたしたちはこれらのプログラムの開発に資金援助しました。わたしたちの目標は完全なオペレーティング・システムであり、これらのプログラムは目標達成のために必要なものだったからです。</p> 221 222 <h3>自由ソフトウェアのサポート</h3> 223 224 <p>自由ソフトウェアの理念は世間に広がる特定のビジネス慣行を否定してはいますが、ビジネスそのものに反対しているわけではありません。ビジネスが利用者の自由を尊重するなら、わたしたちはその成功を願っています。</p> 225 226 <p>Emacsのコピーを販売することは、自由ソフトウェアのビジネスの一例を実際に示しています。FSFがこのビジネスを引き継いだとき、わたしは生活のために別の収入の道を必要としました。わたしが見つけたのは、自分が開発した自由ソフトウェアに関連したサービスを売ることです。これにはGNU 227 EmacsのプログラミングやGCCのカスタマイズの方法といった題目で教えることや、たいていの場合はGCCを他のプラットフォームに移植するものでしたが、ソフトウェア開発がありました。</p> 228 229 <p>今日ではこれらの自由ソフトウェア・ビジネスはどれも多くの会社によって実践されています。CD-ROMで自由ソフトウェアのコレクションを配布するところもあれば、利用者の疑問に答えたり、バグを修正したり、新しく主要な機能を付け加えたりするなどさまざまなレベルに渡るサポートを提供するところもあります。また、新たな自由ソフトウェア製品を市場に送りだすことに基礎を置く自由ソフトウェア会社が現れるのを目にするようになってさえいるのです。</p> 230 231 <p>しかし、気をつけてください。多くの会社が「オープンソース」という用語で、実際には自由ソフトウェアと一緒に動く不自由なソフトウェアに基礎を置くビジネスを展開しています。これらは自由ソフトウェア会社ではありません。自分たちの製品で利用者を自由から引き離そうとするプロプライエタリなソフトウェア会社なのです。それを「付加価値」と呼んではいますが、それは彼らがわたしたちに選んでほしいと望んでいる価値を反映しているに過ぎません。つまり、便利さは自由に勝るという価値です。もし自由がもっと大事なものだとするなら、わたしたちはそれらを「自由を減らす」製品と呼ぶべきでしょう。</p> 232 233 <h3>技術的な目標</h3> 234 235 <p>GNUの第一の目標は自由ソフトウェアであることです。たとえGNUには技術的にUnixを凌ぐところが全くなかったとしても、利用者が協力し合うのを認めるという社会的な優位性があり、利用者の自由を尊重するという倫理的な優位性があります。</p> 236 237 <p>しかし、よく知られた優れた慣行の標準を作品に適用するのは自然なことでしょう。たとえば、恣意的に固定されたサイズ制限を避けてデータ構造を動的に割り当てること、意味があるならばどこでも、可能なすべての8ビット・コードを扱うこと、です。</p> 238 239 <p>それに加え、わたしたちは16ビットのマシンをサポートしないことに決め(GNUのシステムの完成までに32ビットのマシンが普通になっているだろうというのは明らかでした)、Unixの小さいメモリサイズへの注意を無視しました。また、1メガバイトを越えない限りはメモリの使用量を減らそうと努めるのもやめました。大きなファイルを扱うことがそれほど重要でもないプログラムでは、プログラマには入力されたファイル全部をコアに読み出して、それからI/Oを気にする必要なしに中身をスキャンするように勧めました。</p> 240 241 <p>これらの決定により、多くのGNUのプログラムが信頼性やスピードの面でUnixの相当品を越えることが可能になりました。</p> 242 243 <h3>寄贈されたコンピュータ</h3> 244 245 <p>GNUプロジェクトの評判が高まるにつれ、プロジェクトにUnixが走るマシンを寄付したいと申し込んでくれる人たちが現れるようになりました。これらは大変役立ちました。というのも、GNUのコンポーネントを開発するもっとも簡単な方法はそれをUnix上で開発し、そのシステムのコンポーネントをひとつひとつ入れ替えていくことだからです。</p> 246 247 <p>Unixはかつて(今もそうですが)プロプライエタリなソフトウェアであり、GNUプロジェクトの理念ではプロプライエタリなソフトウェアは使ってはならないことになっています。しかし、自己防衛のための暴力が正当とされる同じ論法で、他の人たちがプロプライエタリなパッケージを使うことを止めるのを手助けする自由な代替物を開発するためにそれが重要な役割を果たす場合は、プロプライエタリなパッケージを使うのは正当な行為だという結論に、わたしは達したのです。</p> 248 249 <p>しかしこれは必要悪であるにしても、悪であることには違いありません。今日わたしたちはもうUnixのコピーは持っていません。なぜなら、自由なオペレーティング・システムに取り替えてしまったからです。もしマシンのオペレーティング・システムを交換することができないのならば、わたしたちはむしろマシンの方を取り替えるでしょう。</p> 250 251 <h3>GNUタスクリスト</h3> 252 253 <p>GNUプロジェクトが進行し、他で見つかったり、開発されたりしたシステム・コンポーネントの数が増えるにしたがって、残された間隙のリストを作った方が便利だということになっていきました。わたしたちは欠けている部分を作ってくれる開発者を雇うのにこれを使っていました。このリストは 254 GNUタスクリストという名で知られるようになり、わたしたちは欠けているUnixのコンポーネントだけでなく、真に完成されたシステムに備わっているべきだと考えられるその他のさまざまなソフトウェアやドキュメンテーションのプロジェクトを加えてリストにしていきました。</p> 255 256 <p>最近では <a 257 href="#ft6">[6]</a>、少数のそれほど重要でないものを除けばGNUタスクリストにはUnixのコンポーネントはほとんど残っていません。ですが、いわゆる「アプリケーション」のプロジェクトは目白押しです。それなりの数の利用者にとって魅力のあるものなら、どんなプログラムもオペレーティング・システムに付け加えると便利なものであるわけです。</p> 258 259 <p>ゲームもまたタスクリストに含まれており、しかも最初の頃からずっとそうでした。Unixにはゲームが入っていましたから、GNUにも当然そうでなければなりません。しかしゲームに互換性はそれほど問題にならないので、Unixにあるゲームのリストに従うことはしませんでした。そのかわり、利用者に喜ばれそうな様々な種類のゲームをリストしたのです。</p> 260 261 <h3>GNU劣等GPL</h3> 262 263 <p>GNU CライブラリはGNU劣等一般公衆ライセンスという特別なコピーレフトを使っています <a 264 href="#ft7">[7]</a>。これはプロプライエタリなソフトウェアにライブラリへのリンクを許可するものです。なぜ例外を認めたのでしょうか?</p> 265 266 <p>原則の問題ではありません。プロプライエタリなソフトウェアの製品に、わたしたちのコードを含む資格があるとする原則はありません。(どうしてわたしたちと共有することを拒否した上に成り立っているプロジェクトに手を貸すのでしょう?) 267 LGPLをCライブラリあるいはその他のライブラリに適用するのは、戦略上の問題なのです。</p> 268 269 <p>Cライブラリはこれといって限定されずにいろいろな仕事をこなすもので、どのプロプライエタリなシステムやコンパイラにもCライブラリは付属しています。したがって、わたしたちのCライブラリを自由ソフトウェアでしか使用出来ないようにしても、自由ソフトウェアの有利になることがありません。おそらく、そんなことをしてもわたしたちのライブラリの方を使うのに二の足を踏まれるようになるだけでしょう。</p> 270 271 <p>一つのシステムだけは例外です。GNUシステム(GNU/Linuxを含む)上では、GNU Cライブラリが唯一のC ライブラリです。GNU 272 Cライブラリの配布に関する条件は、GNUシステム向けにプロプライエタリなプログラムをコンパイルすることを可能にするかどうか決めることです。GNUシステム上にプロプライエタリなアプリケーションを認める倫理的な理由は何もありませんが、戦略という面から見ると、これを認めなければ自由なアプリケーションの開発を押し進めるよりもGNUシステムを使うのを躊躇させてしまうことの方が多いと思われるのです。これが劣等GPLをCライブラリに使うのが戦略上よいという理由です。</p> 273 274 <p>他のライブラリにはその都度に状況を踏まえて戦略的な決定をする必要があります。あるライブラリがある特定の種類のプログラムを書くのに便利な特別な役割を果たす場合、GPLの下でリリースして自由なプログラムに用途を限定してプロプライエタリなソフトウェアに対する優位性を与えるのも、他の自由ソフトウェア開発者を手助けするひとつの方法です。</p> 275 276 <p>BASH向けのコマンドライン編集のために開発されたライブラリ、GNU 277 Readlineを例に考えてみましょう。Readlineは劣等GPLではなく通常のGPLの元、リリースされています。このためReadlineが使われる数は減ったかもしれませんが、それはわたしたちにとって損害でもなんでもありません。そうしている間に、Readlineを使えるようにと、少なくともひとつの便利なアプリケーションが自由ソフトウェアになりました。それこそがコミュニティにとって真の利益です。</p> 278 279 <p>プロプライエタリなソフトウェアの開発者は資金面で優位にあり、自由ソフトウェアの開発者は互いに優位性を与え合う必要があります。いつの日か、プロプライエタリなソフトウェアには同等品がないような、大きなGPLのライブラリのコレクションを手にして、新しい自由ソフトウェアのビルディング・ブロックとして使える便利なモジュールを提供し、さらなる自由ソフトウェアの開発に大きな優位性を与えてくれる、そうなればいいなと願っています。</p> 280 281 <h3>痒いところを掻く?</h3> 282 <p> 283 エリック・レイモンドは「ソフトウェアのいい仕事はいつも開発者が自分の個人的な痒みを掻くことから始まるものだ」と言っています。確かにそういうこともあるでしょう。しかし、GNUソフトウェアの中核をなすような大部分は、完全に自由なオペレーティング・システムを作るために開発されたのです。ヴィジョンと計画によって生まれたのであって、衝動からではありません。</p> 284 <p> 285 たとえば、わたしたちはGNU 286 Cライブラリを開発しましたが、それはUnixライクなシステムにはCライブラリが必要だったからです。BASHはUnixライクなシステムにはシェルが必要だから、GNU 287 tarは、それがUnixライクなシステムに必要だからです。わたし自身のプログラムにも同じことがいえます。GNU Cコンパイラ、GNU Emacs、GDB 288 そしてGNU Makeがそうです。</p> 289 <p> 290 GNUプログラムにはわたしたちの自由に対する特定の脅威に対処するために開発されたものもあります。すなわち、わたしたちは、gzipをCompressプログラムを置き換えるために開発しました。それはCompressが<abbr 291 title="Lempel-Ziv-Welch">LZW</abbr>特許のせいでもうコミュニティのものではなくなってしまったからです。また、わたしたちはLessTifを開発してくれる人たちを見つけ、さらに最近ではある特定のプロプライエタリなライブラリによって起こった問題(下記を参照)に対応して<abbr 292 title="GNU Network Object Model 293 Environment">GNOME</abbr>とHarmonyを開始しました。また、評判がよい不自由な暗号化ソフトウェアの代替としてGNU 294 Privacy Guardを開発しています。なぜなら、利用者はプライバシと自由との間で選択を迫られるべきではないからです。</p> 295 <p> 296 もちろん、これらのプログラムを書いている人たちはその仕事に興味を持つようになりましたし、多くの機能が様々な人たちによってそれぞれのニーズや関心によって付け加えられました。しかし、そのプログラムが存在する理由はそれだけではないのです。</p> 297 298 <h3>予想を超えた発展</h3> 299 <p> 300 GNUプロジェクトの当初は、GNUシステム全部を作り上げ、それら全体をリリースすると考えていました。しかし実際にはそうはなりませんでした。</p> 301 <p> 302 GNUシステムの各コンポーネントはUnixシステム上で実装されたので、完全なGNUシステムが出来上がるずっと前に、各コンポーネントはUnixシステム上で実行できました。これらのプログラムの内のいくつかは評判になって、利用者はそれを拡張したり移植したりするようになりました。Unixの様々な非互換の版や、時には他のシステムにもです。</p> 303 <p> 304 こういった過程でプログラムはさらにパワフルになり、GNUプロジェクトに資金と貢献者の両方を引き付けることになりました。しかし、それが実際に稼働する最小限のシステムを完成させるのを何年か遅らせたのかもしれません。GNUの開発者は、必要なコンポーネントを次々と書くよりも、これらの移植を保守したり、既存のコンポーネントにさらに機能を加えたりすることに時間を取られるようになったからです。</p> 305 306 <h3>GNU Hurd</h3> 307 <p> 308 1990年までにGNUシステムはほぼ完成していました。残された唯一の主要なコンポーネントはカーネルです。わたしたちはカーネルをMach上で走るサーバ・プロセスの集合として実装することに決めました。Machとは当初はカーネギー・メロン大学で、その後ユタ大学で開発されるようになったマイクロカーネルです。そして、GNU 309 HurdはMach上で走りUnixカーネルのさまざまなジョブをこなすサーバの集合(つまり“a herd of 310 GNUs”)です。開発の開始はMachが約束されたように自由ソフトウェアとしてリリースされるのを待っていたため遅れました。</p> 311 <p> 312 このデザインを選んだ一つの理由は、カーネルのプログラムをそれ用のソース・レベルのデバッガなしにデバッグするという、一番困難であろう作業を避けるべきだったからです。Machではこのパートの作業は既に終わっており、Hurdサーバをユーザ・プログラムとしてGDBを用いてデバッグできればいいと考えていました。しかしそれが出来るようになるまでには長い時間がかかり、互いにメッセージを送りあうマルチ・スレッドのサーバはデバッグするのが非常に困難なものだということも判明しました。Hurdを安定して稼働させるのは何年も先にまで引き延ばされてしまったのです。</p> 313 314 <h3>Alix</h3> 315 <p> 316 GNUのカーネルはもともとHurdという名前になる予定ではありませんでした。オリジナルの名前はAlixで、わたしの当時の恋人の女性にちなんで名付けられたものです。Unixのシステム・アドミニストレータだった彼女が、自分の名前はUnixシステムの版に共通の命名パターンにぴったりかなと指摘しました。彼女が友人に「誰かカーネルにわたしの名前をつけないかしらね」と冗談で話していたのです。わたしは何も言いませんでしたが、彼女を驚かせてやろうとカーネルの名前をAlixにすることに決めました。</p> 317 <p> 318 それから事情が変わり、中心的なカーネル開発者のマイケル(現在はトーマス)・ブッシュネルがHurdという名前の方を気に入って、Alixをカーネルの中でもシステムコールをトラップしたりそれをHurdサーバにメッセージを送って対処する部分の名称に再定義しました。</p> 319 <p> 320 結局、Alixとわたしは別れてしまい、彼女は別の名前になってしまいました。それとは別にHurdのデザインも変わってしまい、Cライブラリが直接サーバにメッセージを送るようになったので、デザイン上もAlixのコンポーネントは消えてしまいました。</p> 321 <p> 322 しかし、そうなる前に、彼女の友人がHurdのソースコードの中にAlixの名前を見つけて彼女にそのことを話したので、彼女の名前にちなんだカーネルを見つける機会が、彼女には、たしかにあったのです。</p> 323 324 <h3>LinuxとGNU/Linux</h3> 325 <p> 326 GNU 327 Hurdはまだ本番環境での利用には適していません。いったい、そうなるかどうかもわかりません。ケーパビリティ・ベースのデザインが設計の柔軟性から直接に問題を引き起こしています。そして、解法があるかどうか明らかではありません。</p> 328 329 <p> 330 幸運なことに、別のカーネルが使えるようになりました。1991年にリーナス・トーバルズはUnix互換のカーネルを開発し、それをLinuxと名付けました。当初はプロプライエタリでしたが、1992年に、彼はLinuxを自由ソフトウェアとしました。Linuxとまだ未完成だったGNUとの組み合わせで完全に自由なオペレーティング・システムが誕生したのです。(この組み合わせの作業は、もちろんそれ自体、大変なものでした。) 331 今日、GNUシステムの一つの版を実際に走らせることが出来るのはLinuxのおかげです。</p> 332 <p> 333 わたしたちはこのシステムの版を<a 334 href="/gnu/linux-and-gnu.html">GNU/Linux</a>と呼び、その構成を、カーネルとしてのLinuxとGNUシステムの組み合わせとして表現します。全体のシステムを“Linux”と呼ぶ慣習には陥らないでください。それは、わたしたちの仕事を別の誰かに属するもの、と意味してしまいますから。どうか、わたしたちに<a 335 href="/gnu/gnu-linux-faq.html">同等の言及</a>をしてください。</p> 336 337 <h3>これからの挑戦</h3> 338 <p> 339 わたしたちは広範囲に渡って自由ソフトウェアを開発する能力があることを証明してきました。しかしだからといってわたしたちが無敵で誰にも止められないというわけではありません。自由ソフトウェアの将来の見通しを不透明にするような案件がいくつもあり、それに立ち向かうには、時には何年にも及ぶ不断の努力と忍耐が必要になるでしょう。それにはみなさんが自分たちの自由は大切なものであり、誰にも奪わせるつもりはないと表明するというようなある種の決心が必要になるでしょう。</p> 340 <p> 341 次の四つの章でその挑戦課題について見ていきましょう。</p> 342 343 <h4>非開示のハードウェア</h4> 344 <p> 345 ハードウェア産業はますますハードウェアの仕様を隠す傾向を強めています。このため、LinuxやXFree86で新しいハードウェアをサポートするための自由なドライバを書くのが難しくなっています。今は完成された自由のシステムがありますが、次のコンピュータをサポート出来ないのなら、明日もそれがあるというわけにはいきません。</p> 346 <p> 347 この問題の対処方法は二つあります。ハードウェアをどうサポートするのか見つけ出すために、プログラマはリバースエンジニアリングすることが出来ます。その他の人たちは自由ソフトウェアがサポートしているハードウェアを使うといいでしょう。その数が増えれば、仕様を隠すのは自滅的ポリシーだということになっていきます。</p> 348 <p> 349 リバースエンジニアリングは大変な仕事です。それを実行する十分な決意をもったプログラマがわたしたちの中にいるでしょうか。必ずいます。自由ソフトウェアとは原則の問題であり、不自由なドライバには我慢ならないという強い気持ちを持てるのであれば。では、わたしたちの数多くは、自由なドライバを手にするために、余分なお金や少々の時間さえ注ぎ込むのでしょうか。そうです、自由を手にしようという決意が広まっていけば。 <a 350 href="#ft8">[8]</a></p> 351 352 <h4>不自由なライブラリ</h4> 353 <p> 354 自由なオペレーティング・システム上で走る不自由なライブラリは自由ソフトウェアの開発者を罠にかけるようなことをしでかします。ライブラリの魅力的な機能は疑似餌のようなもので、そのライブラリを使えば罠に引っ掛かることになるでしょう。なぜなら、そうしたプログラムは有用なかたちで自由なオペレーティング・システムの一部となることはできないからです。(厳密にいえば、そのプログラムを取り入れることは出来ますが、ライブラリがないため、<em>動く</em>ことはないのです。) 355 さらに悪いことに、もしプロプライエタリなライブラリを使用するあるプログラムが人気を得ることになってしまえば、他の疑わないプログラマも罠へとおびき寄せられるかもしれません。</p> 356 <p> 357 このようなプログラムの最初の例がMotifツールキットで、話は80年代まで遡ります。当時はまだ自由なオペレーティング・システムは存在しなかったのですが、Motifが後々どんな問題を引き起こすことになるかは明らかでした。GNUプロジェクトは、二つのやり方で応じました。個々の自由ソフトウェアのプロジェクトには、自由なXツールキット・ウィジェットをMotifと同じように使ってくれるようお願いし、Motifを置き換える自由な代替物を誰か作ってくれないかとお願いしました。この作業には何年もかかり、Hungry 358 Programmersの手で開発されたLessTifは1997年になってようやく大半のMotifアプリケーションをサポートするくらいにパワフルなものになったのです。</p> 359 <p> 360 1996年と1998年の間にはQtという別の不自由な<abbr title="Graphical User 361 Interface">GUI</abbr>ツールキット・ライブラリが重要な自由ソフトウェアのコレクションであるデスクトップ環境<abbr 362 title="K Desktop Environment">KDE</abbr>に使われたことがありました。</p> 363 <p> 364 ライブラリが使用出来ないため、自由なGNU/LinuxのシステムではKDEを使うことができませんでした。しかしながら、自由ソフトウェアであることにあまり厳密に遵守しないGNU/Linuxの商用ディストリビュータは自分たちのシステムにKDEを加え、高い能力を持つが自由は損なわれたシステム、を作ってしまったのです。KDEグループはもっと多くのプログラマにQtを使うよう積極的に働きかけ、何百万もの新しい「Linux利用者」がその中に問題が含まれていることを明らかにされないままになってしまいました。事態は厳しくなりました。</p> 365 <p> 366 自由ソフトウェアのコミュニティはこの問題に二つのやり方でもって応えました。GNOMEとHarmonyです。</p> 367 <p> 368 GNUネットワークオブジェクトモデル環境、GNOMEはGNUのデスクトップ・プロジェクトです。1997年にミゲル・デ・イカザが始め、Red 369 Hatソフトウェアの支援を受けて開発されたGNOMEは、似たようなデスクトップの機能を提供するものですが、自由ソフトウェアのみを使っています。また、C++だけでなく様々なプログラミング言語をサポートするといった、技術的な優位性も備えています。しかし、その主な目的は自由であり、いかなる不自由なソフトウェアの使用をも必要としないことなのです。</p> 370 <p> 371 Harmonyは互換性のある代替ライブラリで、KDEのソフトウェアをQtを使わずに走らせることを可能にするよう設計されています。</p> 372 <p> 373 1998年の11月にQtの開発者はライセンスを変更し、それが発効されればQtは自由ソフトウェアになると発表しました。断言はできませんが、それは不自由だった時代のQtには問題があったとしてコミュニティが断固として対処してきた成果でもあると思われます。(この新しいライセンスは不便かつ不公正なもので、Qtの使用を避けるのは望ましいままです。 <a 374 href="#ft9">[9]</a>.)</p> 375 <p> 376 次なる誘惑となる不自由のライブラリにわたしたちはどう対処するでしょうか。罠にはまらないでいるようにしなければならないとコミュニティ全体が理解していられるでしょうか。あるいは利便性に負けてわたしたちは自由をあきらめ、大きな問題を引き起こすことになるのでしょうか。わたしたちの未来は、わたしたちの理念にかかっています。</p> 377 378 <h4>ソフトウェア特許</h4> 379 <p> 380 わたしたちが直面することになった最悪の脅威は、ソフトウェア特許から生じたものでした。それにより自由ソフトウェアはそのアルゴリズムと機能から20年に渡って締め出されてしまうような事態も起きかねないのです。LZW方式による圧縮のアルゴリズムの特許は1983年に適用され、わたしたちは未だに<abbr 381 title="Graphics Interchange 382 Format">GIF</abbr>ファイル形式に適切に圧縮する自由ソフトウェアをリリースできないでいます <a 383 href="#ft10">[10]</a>。1998年には、<abbr title="MPEG-1 Audio Layer 384 3">MP3</abbr>形式に圧縮されたオーディオ・ファイルを作成する自由のプログラムが特許侵害 <a 385 href="#ft11">[11]</a>の訴訟を恐れてディストリビューションから外されました。 386 </p> 387 <p> 388 特許に対抗する方法はさまざまです。特許が無効であるという証拠を探し出したり、同じことを別の方法で実現するやり方を見つけたりすることも可能でしょう。しかし、どちらもたまにしか功を奏さないのです。もしどちらも失敗に終われば、特許により全ての自由ソフトウェアは利用者が求める機能のなにがしかを欠いたままであることを強いられてしまうかもしれません。長い待機の後、特許は失効しますが、それまでどうしますか?</p> 389 <p> 390 わたしたちのように自由ソフトウェアを自由のために価値あるものだとする人なら、いずれにせよそのまま自由ソフトウェアを使い続けるでしょう。特許された機能なしになんとか作業をやり遂げるでしょう。しかし技術的優位性があるだろうという理由から自由ソフトウェアを価値あるものだとする人たちは、特許に妨げられれば、それは失敗だと言い出しかねません。ゆえに、確かに「バザール」という開発モデルの実践的有効性やある自由ソフトウェアの高い信頼性と能力について語るのは有用なことではありますが、そこで留まっていてはいけないのです。わたしたちは自由と原則について話すべきなのです。</p> 391 392 <h4>自由なドキュメンテーション</h4> 393 <p> 394 わたしたちの自由なオペレーティング・システムに最も不足しているものは、ソフトウェアの分野にはありません。システムに取り入れられる自由の優れたマニュアルが足りないのです。ドキュメンテーションはどのソフトウェアのパッケージでも重要なパートを担っているわけですから、重要な自由ソフトウェアのパッケージに優れたマニュアルが付属していなければ、それは大きな欠陥となってしまいます。今日、この手の欠陥がたくさんあるのです。</p> 395 <p> 396 自由なドキュメンテーションとは、自由ソフトウェアと同じく、自由に関わることであって、値段のことではありません。自由なマニュアルであることの基準は、自由ソフトウェアとほぼ同じで、全ての利用者に確かな自由を与えるかが問われることになります。マニュアルをプログラムのあらゆるコピーに同梱できるように、オンラインでも紙媒体でも再配布(商用販売も含む)が許可されていなければなりません。</p> 397 <p> 398 変更する自由があることも同じく重要です。原則として、わたしは、すべての種類の論説や本について変更が許されるのが本質的だとは思いません。たとえば、わたしたちの活動や見解を述べたこの文書について、わたしやあなたがこの文章を変更する許可を与える義務があるとは思いません。</p> 399 <p> 400 しかし、変更の自由が自由ソフトウェア用のドキュメンテーションにとって重要であるのには特定の理由があります。ソフトウェアを変更したり、機能を付加したり変えたりする自由を行使する場合、良心的な人ならマニュアルも変更しようとするでしょう。そうすれば正確で有用なドキュメンテーションを変更したプログラムと一緒に提供できるようになるからです。プログラマに良心的になって作業を完成させることを許さないような不自由なマニュアルは、わたしたちのコミュニティのニーズを満たさないのです。</p> 401 <p> 402 変更方法のある種の制限については別に問題はありません。たとえば原作者の著作権表示、配布の条項、または作者名リストを保全するといった制限は、構わないでしょう。変更された版にはそのことを明記するよう求めること、そのセクション全体が技術的な事柄でない事項を扱うものである限りは消したり変更してはならないと求めることも問題はありません。この種の制限は問題とはなりません。良心のあるプログラマに変更されたプログラムに合ったマニュアルを添付することを止めさせたりはしないからです。言い換えれば、そのような制限は自由ソフトウェアのコミュニティがマニュアルを完全に利用するのを邪魔したりはしないのです。</p> 403 <p> 404 しかし、<em>技術的な</em>部分についてはどこでも変更し、それを普通のあらゆる媒体で、あらゆる普通のチャンネルで配布することが可能でなければなりません。そうでなければ、制限がコミュニティの障害となり、マニュアルは自由ではなくなり、また別のマニュアルが必要となってしまいます。</p> 405 <p> 406 自由ソフトウェアの開発者は一連の自由のマニュアルを作る意識と決意を持つようになるでしょうか。もう一度いいます。わたしたちの未来はその理念にかかっているのです。</p> 407 408 <h3>今こそ自由について話さなければなりません</h3> 409 <p> 410 最近の推計ではDebian GNU/LinuxやRed Hat 411 “Linux”のようなGNU/Linuxシステムの利用者は一千万人に上ります。自由ソフトウェアは利用者が純粋に実用的な理由から集まってくるような実際的な利点のあるものを開発してきたのです。</p> 412 <p> 413 この良い影響は明白です。自由ソフトウェアの開発にさらに関心が集まり、自由ソフトウェアにはさらに多くの顧客が引き寄せられ、会社にはプロプライエタリなソフトウェア製品ではなく商用自由ソフトウェアを開発することを一層強く促してくれます。</p> 414 <p> 415 しかしソフトウェアへの関心はそれが基づく理念に対する意識よりも急速に高まっており、これがトラブルを引き起こしています。試練や上記したような脅威に立ち向かうわたしたちの力は、自由のために断固立ち向かう意志いかんによるのです。わたしたちのコミュニティがこの意志を持つことを確実にするには、コミュニティに来た新しい利用者にこの考えを広める必要があるのです。</p> 416 <p> 417 わたしたちはそうすることに失敗しています。新しい利用者をコミュニティに引き付ける努力の方が、コミュニティの一員としてのあり方を広めることをはるかに超えて広まっています。わたしたちはその両方をやらなければならず、双方のバランスをとっていく必要があるのです。</p> 418 419 <h3>「オープンソース」</h3> 420 <p> 421 1998年には新しい利用者に自由について教えることがより難しくなりました。コミュニティの一部が「自由ソフトウェア」という用語を使うのをやめて、その代わりに「オープンソース・ソフトウェア」と言い出したのです。</p> 422 <p> 423 「自由」と「無料」の混同を避ける目的でこの用語を好んだ人もいました—この目標は正しいものです。しかし、その他の人たちは自由ソフトウェア運動とGNUプロジェクトの動機となった原則の精神を横において、代わりに会社の重役やビジネス利用者にアピールする目的でした。自由よりも、コミュニティよりも、原則よりも、利益を重視する思想を持つ人々へアピールするのです。したがって、「オープンソース」のレトリックは高品質のパワフルなソフトウェアを生むポテンシャルに注目しますが、自由、コミュニティ、そして原則という考えを意図的に避けるのです。</p> 424 <p> 425 いわゆる“Linux”関連の雑誌がこの明白な例です。そこはGNU/Linux上で動くプロプライエタリなソフトウェアの広告でいっぱいです。次のMotifやQtが現れたら、この手の雑誌はプログラマにそれらのものから離れるよう警告してくれるでしょうか、それともその手の製品の広告を打つのでしょうか?</p> 426 <p> 427 ビジネスによるサポートがコミュニティに貢献するやり方はたくさんあり、どれも公平で有用なものばかりです。しかし自由や原則についてなるべく話そうとせずにサポートを得ようとするのはひどい事態を招きかねません。先に述べた外部への働きかけとコミュニティの一員としてのあり方を伝えていくことの間のバランスがさらに悪くなってしまうのです。</p> 428 <p> 429 「自由ソフトウェア」と「オープンソース」は、多かれ少なかれ、同じソフトウェアの分類を表しますが、ソフトウェアと価値観については違ったことを唱えています。GNUプロジェクトは「自由ソフトウェア」という言葉を使い続けます。ただ技術的なことを表すのではなく、自由という理念を表現することが重要だからです。</p> 430 431 <h3>やってみよう!</h3> 432 <p> 433 ヨーダの格言(「『試し』などいらん」)はすばらしく聞こえますが、わたしには役立ちません。作業のほとんどは本当にこれが出来るのか心配なままやってきたもので、それにもしこれをしたとしても、それで目的の達成には十分なのか確信は持てないままでした。しかし、それでもやってみたのです。なぜなら押し寄せる敵と我が街の間にはわたししかいませんでしたから。自分でも驚いたことに、時には成功をおさめることだってありました。</p> 434 <p> 435 ときには失敗もしました。いくつかの街は陥落してしまいました。そして危機にある別の街を見つけ、また別の戦闘に備えました。長いこと、わたしは脅威を発見し、我が身をその脅威と自分の街との間に投げ出し、他のハッカーたちにこっちに来て一緒にやろうと呼び掛けてきたのです。</p> 436 <p> 437 今日では、わたしはたいてい一人きりではありません。大勢のハッカーたちが戦線を持ちこたえさせんと我武者らになっているのを見るのと安心して喜ばしい気持ちになり、そして確信するのです。この街は大丈夫だと—今のところは。しかし危険は年を追う毎に大きくなっており、今やマイクロソフトはあきらかにわたしたちのコミュニティをターゲットにしています。将来の自由は約束されているわけではないのです。当然のことだと思ってはいけないのです!自分の自由を守りたいのなら、それを守る備えをしておかなければいけません。</p> 438 <div class="column-limit"></div> 439 440 <h3 class="footnote">脚注</h3> 441 <ol> 442 <li id="ft1">「ハッカー」という用語を「セキュリティ破り」の意味で使うのは一部のマスメディアの混同です。わたしたちハッカーはこのような意味を決して認めません。そして、プログラムをすることが大好きな人、おちゃめな機巧を楽しむ人、もしくはその二つの組み合わせ、という意味でこの言葉を使い続けます。わたしの論説、<a 443 href="https://stallman.org/articles/on-hacking.html">ハッキングについて</a>をご覧ください。</li> 444 445 <li id="ft2">無神論者として、わたしはどの宗教指導者も信心していませんが、ときおり彼らの誰かの言葉に何かしら敬服するものがあることに気付きます。</li> 446 447 <li id="ft3">1984年か1985年に、ドン・ホプキンス(かなりの想像力の持ち主です)がわたしに手紙を送ってくれました。封筒にいくつか愉快なことが書かれてあり、その内のひとつが“Copyleft—all 448 rights 449 reversed.”だったのです。当時、配布のコンセプトについて考えていたわたしは、この「コピーレフト」という言葉をその名前にすることにしたのです。</li> 450 451 <li id="ft4">わたしたちは今は<a href="/licenses/fdl.html">GNU自由文書ライセンス</a>を文書に使っています。</li> 452 453 <li id="ft5">“Bourne again Shell”はUnixで標準的に使われる“Bourne 454 Shell”の名前にひっかけた言葉遊びです。</li> 455 456 <li id="ft6">これは1998年に書かれました。2009年、わたしたちは、もはや長いタスクリストを保守していません。コミュニティは自由ソフトウェアを迅速に開発し、わたしたちはすべてを追跡することはもはやできません。その代わりに、わたしたちは、優先度の高いプロジェクトのリストを持つようになりました。人々に本当に開発してもらいたいプロジェクトの短いリストです。</li> 457 458 <li id="ft7">このライセンスは当初、GNUライブラリ一般公衆ライセンスと呼ばれました。すべてのライブラリがこれを使うべきという考えをさけるためにこの名前に変更しました。<a 459 href="/philosophy/why-not-lgpl.html">次のライブラリに劣等GPLを使うべきでない理由</a>により詳しく述べられています。</li> 460 461 <li id="ft8">2008年追記: この問題はBIOSにも同様に拡張されます。自由なBIOS、<a 462 href="https://www.libreboot.org/">LibreBoot</a>(corebootの一つのディストリビューション)があります。LibreBootが不自由な「ブロブ」なしでサポートできるように、マシンの仕様を入手できるかどうか、が問題です。</li> 463 464 <li id="ft9">追記: 2000年の9月にQtはGNU GPLの下でリリースされ、それによりこの問題は本質的に解決されました。</li> 465 466 <li id="ft10">2009年の時点で、GIFの特許は失効しました。</li> 467 468 <li id="ft11">2017年の時点で、MP3の特許は失効しました。みなさい、どれだけ長く待たなければならなかったことか。</li> 469 </ol> 470 471 <div class="infobox extra" role="complementary"> 472 <hr /> 473 <p> 474 このオリジナルは、書籍<cite>オープンソースソフトウェア</cite>(邦題)に掲載されました。リチャード・ストールマンは<a 475 href="/philosophy/open-source-misses-the-point.html">“オープンソース”の支持者では決してありません</a>が、自由ソフトウェア運動の考えがその書籍からまったくなくなることがないように、この小論を寄稿しました。 476 </p> 477 </div> 478 </div> 479 480 <div class="translators-notes"> 481 482 <!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.--> 483 </div> 484 </div> 485 486 <!-- for id="content", starts in the include above --> 487 <!--#include virtual="/server/footer.ja.html" --> 488 <div id="footer" role="contentinfo"> 489 <div class="unprintable"> 490 491 <p>FSFおよびGNUに関する問い合わせは<a 492 href="mailto:gnu@gnu.org"><gnu@gnu.org></a>までお願いします(英語)。FSFへの連絡は<a 493 href="/contact/">他の方法</a>もあります。リンク切れや他の修正、提案は<a 494 href="mailto:webmasters@gnu.org"><webmasters@gnu.org></a>までお送りください。</p> 495 496 <p> 497 <!-- TRANSLATORS: Ignore the original text in this paragraph, 498 replace it with the translation of these two: 499 500 We work hard and do our best to provide accurate, good quality 501 translations. However, we are not exempt from imperfection. 502 Please send your comments and general suggestions in this regard 503 to <a href="mailto:web-translators@gnu.org"> 504 505 <web-translators@gnu.org></a>.</p> 506 507 <p>For information on coordinating and contributing translations of 508 our web pages, see <a 509 href="/server/standards/README.translations.html">Translations 510 README</a>. --> 511 正確で良い品質の翻訳を提供するよう努力していますが、不完全な場合もあるかと思います。翻訳に関するコメントと提案は、<a 512 href="mailto:web-translators@gnu.org"><web-translators@gnu.org></a>におねがいします。</p><p>わたしたちのウェブページの翻訳の調整と貢献については、<a 513 href="/server/standards/README.translations.html">翻訳 README</a>をご覧ください。</p> 514 </div> 515 516 <!-- Regarding copyright, in general, standalone pages (as opposed to 517 files generated as part of manuals) on the GNU web server should 518 be under CC BY-ND 4.0. Please do NOT change or remove this 519 without talking with the webmasters or licensing team first. 520 Please make sure the copyright date is consistent with the 521 document. For web pages, it is ok to list just the latest year the 522 document was modified, or published. 523 524 If you wish to list earlier years, that is ok too. 525 Either "2001, 2002, 2003" or "2001-2003" are ok for specifying 526 years, as long as each year in the range is in fact a copyrightable 527 year, i.e., a year in which the document was published (including 528 being publicly visible on the web or in a revision control system). 529 530 There is more detail about copyright years in the GNU Maintainers 531 Information document, www.gnu.org/prep/maintain. --> 532 <p>Copyright © 1998, 2005, 2008, 2010, 2012, 2015, 2017, 2018, 2021 533 Richard Stallman</p> 534 535 <p>このページは<a rel="license" 536 href="http://creativecommons.org/licenses/by-nd/4.0/deed.ja">Creative 537 Commons Attribution-NoDerivatives 4.0 International License</a>の条件で許諾されます。</p> 538 539 <!--#include virtual="/server/bottom-notes.ja.html" --> 540 <div class="translators-credits"> 541 542 <!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.--> 543 </div> 544 545 <p class="unprintable"><!-- timestamp start --> 546 最終更新: 547 548 $Date: 2021/12/25 21:34:16 $ 549 550 <!-- timestamp end --> 551 </p> 552 </div> 553 </div> 554 <!-- for class="inner", starts in the banner include --> 555 </body> 556 </html>