path: root/talermerchantdemos/blog/articles/ja/thegnuproject.html

<!--#set var="ENGLISH_PAGE" value="/gnu/thegnuproject.en.html" -->

<!--#include virtual="/server/header.ja.html" -->
<!-- Parent-Version: 1.86 -->

<!-- This file is automatically generated by GNUnited Nations! -->
<title>GNUプロジェクトについて - GNUプロジェクト - フリーソフトウェアファウンデーション</title>
<meta http-equiv="Keywords" content="GNU, GNUプロジェクト, FSF, 自由ソフトウェア, フリーソフトウェアファウンデーション, 歴史" />

<!--#include virtual="/gnu/po/thegnuproject.translist" -->
<!--#include virtual="/server/banner.ja.html" -->
<h2>GNUプロジェクト</h2>

<p>
<a href="http://www.stallman.org/"><strong>リチャード・ストールマン</strong></a>著</p>

<blockquote>
<p>
このオリジナルは、書籍<em>オープンソースソフトウェア</em>(邦題)に掲載されました。リチャード・ストールマンは<a
href="/philosophy/open-source-misses-the-point.html">&ldquo;オープンソース&rdquo;の支持者では決してありません</a>が、自由ソフトウェア運動の考えがその書籍からまったくなくなることがないように、この小論を寄稿しました。
</p>
<p>
なぜ、それがかつてないほどに重要なのか、<a
href="/philosophy/free-software-even-more-important.html">わたしたちが使うソフトウェアは自由でなければならないと主張しましょう</a>。
</p>
</blockquote>

<h3>最初のソフトウェア共有コミュニティ</h3>
<p>
1971年に<abbr title="Massachusetts Institute of
Technology">MIT</abbr>人工知能研究所(AIラボ)で働き始めたとき、わたしは何年も前からあったソフトウェア共有コミュニティの一員になりました。ソフトウェアの共有は、わたしたちのそのコミュニティに限られたことではありませんでした。ちょうどレシピの共有が料理と同じくらい古くからあるのと同じように、コンピュータと同じくらい古くからあったことでした。しかし、わたしたちは、それをほとんどのところよりも、もっと、行ったのです。</p>
<p>
AIラボは<abbr title="Incompatible Timesharing System">ITS</abbr> (Incompatible
Timesharing
System)と呼ばれるタイムシェアリング・オペレーティング・システムを使っていました。これは、研究所のスタッフのハッカーたち(1)により、当時の大きなコンピュータのひとつ、DEC製<abbr
title="Programmed Data
Processor">PDP</abbr>-10用に設計され、アセンブリ言語で書かれていました。このコミュニティの一員として、またAIラボのスタッフのシステム・ハッカーとして、このシステムを改善していくことがわたしの仕事でした。</p>
<p>
わたしたちは自分たちのソフトウェアを「自由ソフトウェア」とは呼んでいませんでした。なぜなら、その用語はまだ存在していなかったからです。しかし、それはそういうものでした。他の大学や会社からやって来た人がプログラムを移植して使いたいときはいつでも、わたしたちは喜んでそうさせました。もし誰かがめずらしくて面白そうなプログラムを使っているのを見たら、いつだってソースコードを見せてくださいと頼めました。そして、それを読み、書き換え、もしくは、その一部を取り出して新しいプログラムにすることができたのです。</p>
<p>
(1)「ハッカー」という用語を「セキュリティ破り」の意味で使うのは一部のマスメディアの混同です。わたしたちハッカーはこのような意味を決して認めません。そして、プログラムをすることが大好きな人、おちゃめな機巧を楽しむ人、もしくはその二つの組み合わせ、という意味でこの言葉を使い続けます。わたしの論説、<a
href="http://stallman.org/articles/on-hacking.html">ハッキングについて</a>をご覧ください。</p>

<h3>コミュニティの崩壊</h3>
<p>
DEC社がPDP-10シリーズを製造中止した1980年代の初め、状況は大きく変わってしまいました。60年代にはエレガントでパワフルだったそのアーキテクチャは、80年代に実用可能になった、より大きなアドレス空間に、自然に拡張することが出来なかったのです。これはITSを形成していたプログラムの大半がもう時代遅れになってしまったということでした。</p>
<p>
AIラボ・ハッカー・コミュニティは、既に、その前に崩壊していました。1981年にスピン・オフの会社SymbolicsがAIラボのほぼ全てのハッカーを引き抜いてしまい、人数の減ったコミュニティは立ち行かなくなっていたのです。(スティーブ・レビィ著、ハッカーズ、にはこれらの出来事や全盛期の頃のこのコミュニティの姿が活き活きと描かれています。)
AIラボが1982年に新しいPDP-10を購入したとき、管理者はITSではなくDEC社の不自由なタイムシェアリング・システムを使うことを決定しました。</p>
<p>
VAXや68020のような当時の先進的なコンピュータは専用のオペレーティング・システムを備えていましたが、どれも自由ソフトウェアではありませんでした。つまり、実行可能なコピーを入手するためだけでも非開示契約を結ぶ必要があったのです。</p>
<p>
ということは、コンピュータを使う最初の段階で、周りの人を手助けしない、と約束するということでした。協力し合うコミュニティは禁じられてしまったのです。プロプライエタリなソフトウェアの所有者によって作られたルールとは「もしお前が隣人と分かち合うなら、お前は海賊だ。変更を加えたいのなら、われわれに頼み込んで作ってもらうことだ」というものなのです。</p>
<p>
プロプライエタリなソフトウェアの社会システムという考え&mdash;ソフトウェアを共有したり変更したりするのは許されないとするシステム&mdash;は反社会的であり、倫理に反し、ただ単純に間違っているのだという考え方に、読者の方々は驚かれるかもしれません。しかし社会を分断し利用者が手も足も出ないようにされてしまうことの上に築かれたシステムについて、他に何と言い様があるでしょう。この考え方に驚く方は、プロプライエタリなソフトウェアの社会システムを与えられたものとして受け止め、プロプライエタリなソフトウェアのビジネスが提唱する用語で判断しているのではないでしょうか。ソフトウェア会社はこの問題の見方は一つしかないと人々に信じさせるために長いこと非常な作業を重ねてきたのです。</p>
<p>
ソフトウェア会社が「権利を」「行使する」あるいは「<a
href="/philosophy/words-to-avoid.html#Piracy">海賊版</a>を止める」と語るとき、彼らが<em>語っている</em>ことは実際には二の次なのです。この言明の真のメッセージは、彼らが当然であるとみなし、あえて口にしていない前提条件の方にあります。つまり、社会は彼らのことを無批判に受け入れるべきだというわけです。ではその点について吟味してみましょう。</p>
<p>
一つ目の前提は、ソフトウェア会社は自分たちのソフトウェアについてソフトウェアを所有するという議論の余地がない自然権を有しており、したがってその全ての利用者を支配する権力を持つということです。(もしこれが自然権であれば、それが公衆にどんな害を与えようと、わたしたちは反対できません。)
面白いことに、合衆国憲法と法の伝統ではこの見方は否定されています。著作権は自然権ではなく、利用者のコピーする自然権を制限する、人工的な政府が強いる独占なのです。</p>
<p>
もうひとつの語られざる前提条件とは、ソフトウェアに関して唯一重要なことはそれがどんな作業をさせてくれるかであって、どんな社会に暮らすことができるかについてわれわれコンピュータの利用者は気にかけるべきではないというものです。</p>
<p>
三番目の前提条件は、会社にプログラムの利用者を支配する力をさしださなければ、わたしたちには使えるソフトウェアは手に入らない(あるいはプログラムにあれやこれやの特定の作業をさせることがまるっきり不可能だ)ということです。この仮定はまことしやかに聞こえました、自由ソフトウェア運動が鎖を負わせることなく、豊富な便利なソフトウェアを作りだせることを実際にやってみせる前は。</p>
<p>
これらの前提条件を拒否して、それぞれの問題を利用者を第一に考えて普通の常識的な道徳に照らし合わせて判断するならば、全く別の結論が導き出されます。コンピュータの利用者は自分のニーズに合わせてプログラムを変更し、ソフトウェアを共有する自由がなければなりません。なぜなら、他人の手助けをすることは社会の基本なのですから。</p>
<p>
この結論を裏付ける論旨について十分に述べる余地はここにはありません。詳しくは、こちらのウェブページ<a
href="/philosophy/why-free.html">http://www.gnu.org/philosophy/why-free.html</a>と<a
href="/philosophy/free-software-even-more-important.html">
http://www.gnu.org/philosophy/free-software-even-more-important.html</a>を参照してください。
</p>

<h3>冷厳なる道徳の選択</h3>
<p>
コミュニティがなくなってしまい、以前と同じように活動を続けていくのは不可能になってしまいました。その代わりに、わたしは厳しい道徳的な選択に直面することになったのです。</p>
<p>
容易な選択は、プロプライエタリなソフトウェアの世界に参加して、非開示契約を結んで仲間のハッカーたちを手助けしないと約束することでした。その場合、おそらく、わたしは非開示契約のソフトウェアも開発し、したがって、他の人たちにも自分たちの仲間を裏切るよう圧力をかけるようになっていたでしょう。</p>
<p>
このやり方でお金を儲けることも出来たでしょう。そしておそらくコードを書くことを楽しんだかもしれません。しかしキャリアの終わりには、人々を隔てる壁を築いてきた何年もの日々を思い返し、自分の人生を世界をより悪いものにするために費やしてきたと感じるようになるのは分かっていました。</p>
<p>
わたしには既に非開示契約を受け取る当事者になった経験がありました。ある人がわたしとMITのAIラボにわたしたちのプリンタを制御するプログラムのソースコードを渡すことを拒否したときのことです。(このプログラムにはある特定の機能がなかったので、プリンタを使うのにはひどくいらいらさせられていました。)
ですから、非開示契約には罪はない、と自分自身に言うことはできませんでした。向こうがわたしたちと共有し合うことを拒否したときには本当に怒りました。わたしは振り返って、みんなを同じ目にあわせることなどできません。</p>
<p>
もうひとつの選択肢は、まっすぐではあるけれどもうれしくないもので、コンピュータの世界から去ることです。そのやり方ではわたしのスキルは間違った使われ方はしませんが、無駄になってしまうことには変わりありません。わたし自身がコンピュータの利用者を分断したり制限したりする過ちを犯すことはありませんが、それでもそういうことは起こるでしょう。</p>
<p>
そこでわたしはプログラマが正しいことをできるようになるための方法を探しました。自分に書けるプログラムはあるだろうか、それでもう一度コミュニティを作ることができるようになるだろうか、と自分に聞いてみました。</p>
<p>
答えは明らかでした。最初に必要だったのはオペレーティング・システムです。コンピュータを使うには重要なソフトウェアです。オペレーティング・システムがあれば、たくさんのことが出来るようになります。なければ、コンピュータを走らせることがまったく出来ません。自由なオペレーティング・システムがあれば、わたしたちはもう一度ハッカーたちが協力し合える&mdash;そして誰でも勧誘できるようなコミュニティを持つことが出来るのです。そうすれば自分の友人たちを拒むたくらみから始めることなく、誰もがコンピュータを使うことが出来るようになるでしょう。</p>
<p>
オペレーティング・システムの開発者として、わたしにはこの仕事に相応しいスキルがありました。だから、成功の見込みがあるわけではなかったのですが、わたしは自分がこの仕事をするよう選ばれたのだと気付いたのです。移植性が高くなるだろうという理由から、システムはUnixと互換性のあるものにすることを選びました。それに、そうすれば
Unixの利用者も容易に乗り換えることができるでしょう。GNUという名前はハッカーの伝統に従って、&ldquo;GNU's Not
Unix&rdquo;(GNUはUnixではない)の再帰頭字語として選ばれました。これは<a
href="/gnu/pronunciation.html">硬い g の一音節</a>で発音されます。</p>
<p>
オペレーティング・システムというのはせいぜい他のプログラムを実行するのに足るだけのカーネルだけを意味するわけではありません。1970年代には、オペレーティング・システムの名に相応しいものであれば、どれにもコマンド・プロセッサやアセンブラ、コンパイラ、インタプリタ、テキストエディタ、メイラ、そしてもっとたくさんのものが含まれていました。ITSでも、Multicsでも、VMSでも、Unixでもです。GNUのオペレーティング・システムにもそれらは含まれるようにするつもりでした。</p>
<p>
後になってヒレル(1)のものとされる次のような言葉を知りました。</p>

<blockquote><p>
     わたしが自分のために存在するのでなければ、いったい誰がわたしのために存在する?<br />
     わたしが自分のためだけに存在するとすれば、わたしはいったい何ものだ?<br />
     今でなければ、いったいいつ?
</p></blockquote>
<p>
GNUプロジェクトを始めようという決意も同じような精神に基づいてのことでした。</p>
<p>
(1) 無神論者として、わたしはどの宗教指導者も信心していませんが、ときおり彼らの誰かの言葉に何かしら敬服するものがあることに気付きます。</p>

<h3>自由としてのフリー</h3>
<p>
自由ソフトウェアの英語&ldquo;free
software&rdquo;は、ときに誤解を生みます。値段とは関係ないのです。自由についてなのです。ですから、ここで自由ソフトウェアの定義を述べます。</p>

<p>ある特定の利用者であるあなたにとって、あるプログラムが自由ソフトウェアであるとは、</p>

<ul>
  <li>そのプログラムをあなたの欲するままにどんな目的のためにでも実行する自由があること。</li>

  <li>あなたの必要に応じて、そのプログラムを変更する自由があること。(この自由を実際に実効的にするために、ソースコードへのアクセスがあることが必須です。ソースコードなしにあるプログラムに変更を加えることは、大変な困難を伴うからです。)</li>

  <li>無償あるいは有償のどちらでも、コピーを再配布する自由があること。</li>

  <li>そのプログラムの変更した版を配布する自由があり、コミュニティがあなたの改善による利益を享受できること。</li>
</ul>
<p>
「フリー」は自由のことをいうのであって、値段のことではありません。ですから、コピーを販売することと自由ソフトウェアであることに矛盾は全くありません。事実、コピーを販売する自由は重要です。というのも自由ソフトウェアのコレクションのCD-ROMを販売するのはコミュニティに大切なことであり、また、それを販売することは自由ソフトウェア開発のための資金調達をする重要な手段だからです。それゆえに、この中に収録することができないプログラムは自由ソフトウェアではありません。</p>
<p>
「フリー」という語の曖昧さのせいで、人々はそれに代わる別のものを探してきました。しかし、誰もぴったりくるような別の代わりを見つけられなかったのです。英語には他のどの言語よりもたくさんの言葉やニュアンスがありますが、しかし「フリー」を自由の意で表すシンプルで明白な単語がありません&mdash;&ldquo;unfettered&rdquo;(足枷のない、自由な)という語が意味の上で最も近いところにありますが。&ldquo;liberated&rdquo;、&ldquo;freedom&rdquo;、&ldquo;open&rdquo;のような候補にも間違った意味やその他の不都合がありました。</p>

<h3>GNUソフトウェアとGNUシステム</h3>
<p>
システム全体を開発するというのは巨大なプロジェクトです。それを実現可能なところにもっていくため、わたしは既存の自由ソフトウェアを可能であればなんでも採用し、使用することにしました。たとえば、開始当初にTeXを主要なテキスト・フォーマット・ツールとして採用するに決めました。その数年後には、GNU向けに別のウィンドウ・システムを作るよりもXウィンドウ・システムを使うことに決めました。</p>
<p>
この決定と同じようなそのほかの決定により、GNUシステムは全GNUソフトウェアのコレクションと同じものではなくなりました。GNUシステムにはGNUソフトウェア以外のプログラムも含まれます。それらのプログラムは他の人たちによってそれぞれの目的に応じて開発されますが、自由ソフトウェアなのでわたしたちも使うことが出来ます。</p>

<h3>プロジェクトの開始</h3>
<p>
1984年の一月にわたしはMITを辞めてGNUソフトウェアを書き始めました。MITがGNUを自由ソフトウェアとして配布するのを妨げることができないようにするためにMITを去る必要があったのです。もしわたしがスタッフとして残っていたなら、MITはその仕事の所有を主張し、自分たちの配布条件を押し付けたり、プロプライエタリなソフトウェアとしてしまうことさえ可能だったでしょう。わたしには自分のやってきた大量の仕事をむざむざ無駄になるに任せるつもりはありませんでした。新しいソフトウェア共有のコミュニティを作るのが目的なのですから。</p>
<p>
しかしながら、当時MITのAIラボを率いていたウィンストン教授のご好意により、研究所の施設を使い続けさせていただくことができました。</p>

<h3>最初の一歩</h3>
<p>
GNUプロジェクトを始めるちょっと前、VUCKという名でも知られる自由大学コンパイラ・キット(オランダ語で「自由」は<em>V</em>で始まります)のことを聞きました。これはCやPascalを含む複数の言語を扱えるよう作られたコンパイラで、複数のターゲトマシンをサポートするとのことでした。わたしは作者にGNUでこれを使えないかどうかと質問を送りました。</p>
<p>
大学は自由だがコンパイラそうではない、と述べたあざけるような返事を彼は送ってきました。そこで、わたしはGNUプロジェクトの最初のプログラムは複数言語に対応した、複数のプラットフォーム向けのコンパイラに決めたのです。</p>
<p>
自分で一からコンパイラを書き上げる手間を省くため、Pastelというコンパイラのソースコードを手に入れました。これはローレンス・リバモア研究所で開発された複数プラットフォーム対応のコンパイラです。拡張されたPascalをサポートし、またその言語で書かれたもので、システム・プログラミングのために設計されたものでした。わたしはC言語のフロントエンドを追加し、モトローラ68000コンピュータのための移植を始めました。しかしコンパイラがスタック空間に何メガバイトも必要とするのに、利用できる68000
Unixシステムでは64kしかないかもしれないことが分かって諦めることになりました。</p>
<p>
Pastelコンパイラは入力ファイル全体を構文木に解析し、構文木全体を一連の「命令」に変換し、それから出力ファイル全体を生成することが分かりました。メモリを一切解放せずにです。ここで、わたしは新しいコンパイラを一から作らなければならないという結論に達したのです。そのコンパイラは今は<abbr
title="GNU Compiler
Collection">GCC</abbr>として知られています。Pastelからのものは何も使用されておらず、自分で書いたCのフロントエンドをどうにか適応して使いました。しかしそれは数年後のことです。まず最初に、わたしはGNU
Emacsの作業に取りかかりました。</p>

<h3>GNU Emacs</h3>
<p>
GNU
Emacsには1984年の9月に取りかかり、1985年の早くには使えるようになりました。これでUnixシステムを編集作業に使うことが出来ます。viやedの修得には興味がなかったので、それまで編集には別の種類のマシンを使っていたのです。</p>
<p>
この時点から、みんなが
GNUEmacsをほしがるようになりました。そのため、どうやってこれを配布するかの問題が発生したのです。もちろん、わたしはこれを自分が使っていたMITの匿名ftpサーバに置きました。(このコンピュータ、prep.ai.mit.eduは、こうして主要なGNU
ftp配布サイトになったのです。数年後にその役目を終えると、わたしたちは新しいftpサーバに名前を移転させました。)
しかし、当時興味を持ってくれた多くの人たちがインターネット環境にはおらず、ftp経由でコピーを手にすることが出来ませんでした。そこで問題は、この人たちには何と言えばいいか、でした。</p>
<p>
「ネットに繋がっていてコピーしてくれる友達を見つけてください」と伝えることも出来たでしょう。あるいはオリジナルのPDP-10
Emacsでやったことを自分ですることも可能でした。彼らに「テープと<abbr title="Self-addressed Stamped
Envelope">SASE(返信用住所記入済み切手付封筒)</abbr>を送ってくれれば、Emacsを入れて送り返します」と言うのです。しかし、わたしには仕事がなく、自由ソフトウェアからお金を得る方法を探していました。そこで、150ドルでテープを発送しますと発表しました。このやり方でわたしは自由ソフトウェア配布ビジネスを始めました。GNU/Linuxシステム・ディストリビューション全体を配布している今日の会社の先駆者となったわけです。</p>

<h3>プログラムはすべての利用者に自由なのか?</h3>
<p>
あるプログラムが作者の手を離れたとき自由ソフトウェアであったとしても、そのコピーを持っている全ての人にとって自由ソフトウェアであるとは限りません。たとえば、<a
href="/philosophy/categories.html#PublicDomainSoftware">パブリック・ドメイン・ソフトウェア</a>(著作権が主張されないソフトウェア)は自由ソフトウェアですが、誰でもそのプロプライエタリな版を作ることが出来ます。同じく、多くの自由ソフトウェアには著作権が主張されますが、単純な容認のライセンスのもとで配布されています。これは、プロプライエタリな変更版を許します。</p>
<p>
この問題の典型的な例がXウィンドウ・システムです。MITで開発され、容認のライセンスで自由ソフトウェアとしてリリースされましたが、すぐに多くのコンピュータ関連会社によって採用されました。彼らはXを自分たちのプロプライエタリなUnixシステムにバイナリ形式のみで組み込み、同じ非開示契約によって覆ってしまったのです。これらのXのコピーはUnixと同様にもはや自由ソフトウェアではなくなりました。</p>
<p>
Xウィンドウ・システムの開発者たちはこれを問題とは考えていませでんした。彼らはこうなることを期待し、それを意図していたのです。彼らの目標は自由ではなく、「多くの利用者を獲得する」という意味でただ「成功する」ことでした。彼らは利用者が自由を得ることなどどうでもよくて、大勢になりさえすればそれでよかったのです。</p>
<p>
これによって、「このプログラムは自由なのか。」という問いに対して、自由の量を計る二つの異なるやり方がそれぞれ別の答えを出してしまうような逆説的な状況が生まれました。MITのリリースの配布条件が与える自由に従って判断すれば、Xは自由ソフトウェアと言えたでしょう。しかしXの平均的な利用者の自由を調べれば、これはプロプライエタリなソフトウェアと言わざるを得ませんでした。ほとんどのXの利用者は自由な版ではなく、Unixシステムと一緒になったプロプライエタリな版を走らせていたからです。</p>

<h3>コピーレフトとGNU GPL</h3>
<p>
GNUの目標は利用者に自由を与えることで、単に人気を得ることではありません。ですから、わたしたちはGNUのソフトウェアがプロプライエタリなソフトウェアに変わることを防ぐ配布条件を使用する必要がありました。わたしたちが使っているこの方法は「コピーレフト」(1)と呼ばれています。</p>
<p>
コピーレフトは著作権法を利用してはいますが、それをひっくり返して通常とは反対の目的のために使っています。つまり、プログラムを制限するための手段としてではなく、プログラムを自由のままにしておく手段となるように。</p>
<p>
コピーレフトの中心的な考え方は、全ての人にそのプログラムを実行し、コピーし、変更し、変更した版を再配布する許可を与え、制限事項を加えることには許可を与えるないというものです。したがって、それが「自由ソフトウェア」であると決定するような大切な自由というものは、そのコピーを持っている人たち全てに保証される、不可侵の権利になるのです。</p>
<p>
コピーレフトを効果的なものにするために、変更された版も自由でなければなりません。これにより、わたしたちのものをもとにした作品が公開された場合、それがわたしたちのコミュニティに入手可能であるよう保証されます。プログラマとしての仕事を持っている人がボランティアでGNUソフトウェアを改善したとき、それはコピーレフトなので雇用主に「我々のプロプライエタリな版を作るのに使用するから変更した部分を共有してはいけない」とは言わせないようになっています。</p>
<p>
そのプログラムの利用者すべての自由を保証したいのであれば、変更に対して、自由でなければならないとの要求が不可欠になります。Xウィンドウ・システムを私物化する会社はたいてい自分たちのシステムやハードウェアに移植する際に何らかの変更を加えています。これらの変更はXの大部分と比べれば小さなものではあるでしょうが、だからといって取るに足らないものではありません。もし変更を加えることが利用者の自由を否定するための言い訳になってしまうなら、その言い訳につけこむのは誰にとっても簡単なことでしょう。</p>
<p>
これと関連して、自由のプログラムを不自由なのコードと結合させることの問題があります。そのような組み合わせは不可避的に不自由となってしまいます。不自由な部分にたとえどんなものであっても自由が欠けているなら、全体もまた同じなのです。そのような組み合わせを認めてしまえば、船を沈めるには十分な穴を開けてしまうことになりかねません。ゆえに、コピーレフトに必ず要求されるのはこのような穴に栓をすることです。コピーレフトのプログラムに付加される、あるいは組み合わされるのが何であれ、結合された版もまた自由でコピーレフトでなければならないのです。</p>
<p>
コピーレフトの特定の実装でわたしたちがほとんどのGNUソフトウェアに用いているのがGNU一般公衆ライセンス、略してGNU
GPLです。また特定の状況で使用する別種のコピーレフトもあります。GNUマニュアルもコピーレフトされてますが、マニュアルに複雑なGNU
GPLは必要ないので、もっと簡潔なコピーレフトを使っています。(2)</p>
<p>
(1)
1984年か1985年に、ドン・ホプキンス(かなりの想像力の持ち主です)がわたしに手紙を送ってくれました。封筒にいくつか愉快なことが書かれてあり、その内のひとつが&ldquo;Copyleft&mdash;all
rights
reversed.&rdquo;だったのです。当時、配布のコンセプトについて考えていたわたしは、この「コピーレフト」という言葉をその名前にすることにしたのです。</p>

<p>
(2) わたしたちは今は<a href="/licenses/fdl.html">GNU自由文書ライセンス</a>を文書に使っています。</p>

<h3>フリーソフトウェアファウンデーション</h3>

<p>Emacsを使うことに関心が集まってくるにしたがって、GNUプロジェクトに参加する人が増えてきました。そこでわたしたちはそろそろ資金調達の方法を再考してみようと決めました。そして1985年に自由ソフトウェア開発のための税控除の対象となる福祉団体、<a
href="http://www.fsf.org/">フリーソフトウェアファウンデーション</a>(FSF)を創設したのです。<abbr
title="Free Software
Foundation">FSF</abbr>はEmacsのテープ配布ビジネスも引き継ぎ、後にはこれに(GNUと非GNUの両方の)他の自由ソフトウェアをテープに加え、さらには自由のマニュアルも販売するなど拡大していきます。</p>

<p>かつて、FSFの収入の大半は、自由ソフトウェアのコピーやその他の関連サービスの販売(ソースコードのCD-ROMやバイナリのCD-ROM、かっこうよく印刷したマニュアル、全て再配布、変更は自由です)、そして豪華版ディストリビューション(顧客の選択したプラットフォーム向けのソフトウェアのコレクション全体をビルドしたもの)から得たものでした。今日も、FSFは<a
href="http://shop.fsf.org/">マニュアルやその他のグッズの販売</a>をしていますが、多くの資金を会員の会費から得ています。あなたも、こちら<a
href="http://fsf.org/join">fsf.org</a>からFSFに参加できます。</p>

<p>フリーソフトウェアファウンデーションの職員は多くのGNUソフトウェア・パッケージを書き、またその保守をしてきました。特記すべきはCライブラリとシェルでしょう。GNU
CライブラリはGNU/Linux上で走るどのプログラムもLinuxとのやり取りに使用しています。これはフリーソフトウェアファウンデーションのスタッフ、ローランド・マクグラスによって開発されました。大半のGNU/Linuxシステムで使われているシェルが<abbr
title="Bourne Again Shell">BASH</abbr>、Bourne Again
Shell(1)で、FSFの職員であるブライアン・フォックスによって開発されました。</p>

<p>GNUプロジェクトはツールや開発環境に留まるものではないので、わたしたちはこれらのプログラムの開発に資金援助しました。わたしたちの目標は完全なオペレーティング・システムであり、これらのプログラムは目標達成のために必要なものだったからです。</p>

<p>(1) &ldquo;Bourne again Shell&rdquo;はUnixで標準的に使われる&ldquo;Bourne
Shell&rdquo;の名前にひっかけた言葉遊びです。</p>

<h3>自由ソフトウェアのサポート</h3>

<p>自由ソフトウェアの理念は世間に広がる特定のビジネス慣行を否定してはいますが、ビジネスそのものに反対しているわけではありません。ビジネスが利用者の自由を尊重するなら、わたしたちはその成功を願っています。</p>

<p>Emacsのコピーを販売することは、自由ソフトウェアのビジネスの一例を実際に示しています。FSFがこのビジネスを引き継いだとき、わたしは生活のために別の収入の道を必要としました。わたしが見つけたのは、自分が開発した自由ソフトウェアに関連したサービスを売ることです。これにはGNU
EmacsのプログラミングやGCCのカスタマイズの方法といった題目で教えることや、たいていの場合はGCCを他のプラットフォームに移植するものでしたが、ソフトウェア開発がありました。</p>

<p>今日ではこれらの自由ソフトウェア・ビジネスはどれも多くの会社によって実践されています。CD-ROMで自由ソフトウェアのコレクションを配布するところもあれば、利用者の疑問に答えたり、バグを修正したり、新しく主要な機能を付け加えたりするなどさまざまなレベルに渡るサポートを提供するところもあります。また、新たな自由ソフトウェア製品を市場に送りだすことに基礎を置く自由ソフトウェア会社が現れるのを目にするようになってさえいるのです。</p>

<p>しかし、気をつけてください。多くの会社が「オープンソース」という用語で、実際には自由ソフトウェアと一緒に動く不自由なソフトウェアに基礎を置くビジネスを展開しています。これらは自由ソフトウェア会社ではありません。自分たちの製品で利用者を自由から引き離そうとするプロプライエタリなソフトウェア会社なのです。それを「付加価値」と呼んではいますが、それは彼らがわたしたちに選んでほしいと望んでいる価値を反映しているに過ぎません。つまり、便利さは自由に勝るという価値です。もし自由がもっと大事なものだとするなら、わたしたちはそれらを「自由を減らす」製品と呼ぶべきでしょう。</p>

<h3>技術的な目標</h3>

<p>GNUの第一の目標は自由ソフトウェアであることです。たとえGNUには技術的にUnixを凌ぐところが全くなかったとしても、利用者が協力し合うのを認めるという社会的な優位性があり、利用者の自由を尊重するという倫理的な優位性があります。</p>

<p>しかし、よく知られた優れた慣行の標準を作品に適用するのは自然なことでしょう。たとえば、恣意的に固定されたサイズ制限を避けてデータ構造を動的に割り当てること、意味があるならばどこでも、可能なすべての8ビット・コードを扱うこと、です。</p>

<p>それに加え、わたしたちは16ビットのマシンをサポートしないことに決め(GNUのシステムの完成までに32ビットのマシンが普通になっているだろうというのは明らかでした)、Unixの小さいメモリサイズへの注意を無視しました。また、1メガバイトを越えない限りはメモリの使用量を減らそうと努めるのもやめました。大きなファイルを扱うことがそれほど重要でもないプログラムでは、プログラマには入力されたファイル全部をコアに読み出して、それからI/Oを気にする必要なしに中身をスキャンするように勧めました。</p>

<p>これらの決定により、多くのGNUのプログラムが信頼性やスピードの面でUnixの相当品を越えることが可能になりました。</p>

<h3>寄贈されたコンピュータ</h3>

<p>GNUプロジェクトの評判が高まるにつれ、プロジェクトにUnixが走るマシンを寄付したいと申し込んでくれる人たちが現れるようになりました。これらは大変役立ちました。というのも、GNUのコンポーネントを開発するもっとも簡単な方法はそれをUnix上で開発し、そのシステムのコンポーネントをひとつひとつ入れ替えていくことだからです。</p>

<p>Unixはかつて(今もそうですが)プロプライエタリなソフトウェアであり、GNUプロジェクトの理念ではプロプライエタリなソフトウェアは使ってはならないことになっています。しかし、自己防衛のための暴力が正当とされる同じ論法で、他の人たちがプロプライエタリなパッケージを使うことを止めるのを手助けする自由な代替物を開発するためにそれが重要な役割を果たす場合は、プロプライエタリなパッケージを使うのは正当な行為だという結論に、わたしは達したのです。</p>

<p>しかしこれは必要悪であるにしても、悪であることには違いありません。今日わたしたちはもうUnixのコピーは持っていません。なぜなら、自由なオペレーティング・システムに取り替えてしまったからです。もしマシンのオペレーティング・システムを交換することができないのならば、わたしたちはむしろマシンの方を取り替えるでしょう。</p>

<h3>GNUタスクリスト</h3>

<p>GNUプロジェクトが進行し、他で見つかったり、開発されたりしたシステム・コンポーネントの数が増えるにしたがって、残された間隙のリストを作った方が便利だということになっていきました。わたしたちは欠けている部分を作ってくれる開発者を雇うのにこれを使っていました。このリストは
GNUタスクリストという名で知られるようになり、わたしたちは欠けているUnixのコンポーネントだけでなく、真に完成されたシステムに備わっているべきだと考えられるその他のさまざまなソフトウェアやドキュメンテーションのプロジェクトを加えてリストにしていきました。</p>

<p>最近では(1)、少数のそれほど重要でないものを除けばGNUタスクリストにはUnixのコンポーネントはほとんど残っていません。ですが、いわゆる「アプリケーション」のプロジェクトは目白押しです。それなりの数の利用者にとって魅力のあるものなら、どんなプログラムもオペレーティング・システムに付け加えると便利なものであるわけです。</p>

<p>ゲームもまたタスクリストに含まれており、しかも最初の頃からずっとそうでした。Unixにはゲームが入っていましたから、GNUにも当然そうでなければなりません。しかしゲームに互換性はそれほど問題にならないので、Unixにあるゲームのリストに従うことはしませんでした。そのかわり、利用者に喜ばれそうな様々な種類のゲームをリストしたのです。</p>

<p>(1)
これは1998年に書かれました。2009年、わたしたちは、もはや長いタスクリストを保守していません。コミュニティは自由ソフトウェアを迅速に開発し、わたしたちはすべてを追跡することはもはやできません。その代わりに、わたしたちは、優先度の高いプロジェクトのリストを持つようになりました。人々に本当に開発してもらいたいプロジェクトの短いリストです。</p>

<h3>GNUライブラリGPL</h3>

<p>GNU
CライブラリはGNUライブラリ一般公衆ライセンスという特別なコピーレフトを使っています(1)。これはプロプライエタリなソフトウェアにライブラリへのリンクを許可するものです。なぜ例外を認めたのでしょうか?</p>

<p>原則の問題ではありません。プロプライエタリなソフトウェアの製品に、わたしたちのコードを含む資格があるとする原則はありません。(どうしてわたしたちと共有することを拒否した上に成り立っているプロジェクトに手を貸すのでしょう?)
LGPLをCライブラリあるいはその他のライブラリに適用するのは、戦略上の問題なのです。</p>

<p>Cライブラリはこれといって限定されずにいろいろな仕事をこなすもので、どのプロプライエタリなシステムやコンパイラにもCライブラリは付属しています。したがって、わたしたちのCライブラリを自由ソフトウェアでしか使用出来ないようにしても、自由ソフトウェアの有利になることがありません。おそらく、そんなことをしてもわたしたちのライブラリの方を使うのに二の足を踏まれるようになるだけでしょう。</p>

<p>一つのシステムだけは例外です。GNUシステム(GNU/Linuxを含む)上では、GNU Cライブラリが唯一のC ライブラリです。GNU
Cライブラリの配布に関する条件は、GNUシステム向けにプロプライエタリなプログラムをコンパイルすることを可能にするかどうか決めることです。GNUシステム上にプロプライエタリなアプリケーションを認める倫理的な理由は何もありませんが、戦略という面から見ると、これを認めなければ自由なアプリケーションの開発を押し進めるよりもGNUシステムを使うのを躊躇させてしまうことの方が多いと思われるのです。これがライブラリGPLをCライブラリに使うのが戦略上よいという理由です。</p>

<p>他のライブラリにはその都度に状況を踏まえて戦略的な決定をする必要があります。あるライブラリがある特定の種類のプログラムを書くのに便利な特別な役割を果たす場合、GPLの下でリリースして自由なプログラムに用途を限定してプロプライエタリなソフトウェアに対する優位性を与えるのも、他の自由ソフトウェア開発者を手助けするひとつの方法です。</p>

<p>BASH向けのコマンドライン編集のために開発されたライブラリ、GNU
Readlineを例に考えてみましょう。ReadlineはライブラリGPLではなく通常のGPLの元、リリースされています。このためReadlineが使われる数は減ったかもしれませんが、それはわたしたちにとって損害でもなんでもありません。そうしている間に、Readlineを使えるようにと、少なくともひとつの便利なアプリケーションが自由ソフトウェアになりました。それこそがコミュニティにとって真の利益です。</p>

<p>プロプライエタリなソフトウェアの開発者は資金面で優位にあり、自由ソフトウェアの開発者は互いに優位性を与え合う必要があります。いつの日か、プロプライエタリなソフトウェアには同等品がないような、大きなGPLのライブラリのコレクションを手にして、新しい自由ソフトウェアのビルディング・ブロックとして使える便利なモジュールを提供し、さらなる自由ソフトウェアの開発に大きな優位性を与えてくれる、そうなればいいなと願っています。</p>

<p>(1)
このライセンスは今はGNU劣等一般公衆ライセンスと呼ばれます。すべてのライブラリがこれを使うべきという考えをさけるためにこの名前となりました。<a
href="/philosophy/why-not-lgpl.html">次のライブラリに劣等GPLを使うべきでない理由</a>により詳しく述べられています。</p>

<h3>痒いところを掻く?</h3>
<p>
エリック・レイモンドは「ソフトウェアのいい仕事はいつも開発者が自分の個人的な痒みを掻くことから始まるものだ」と言っています。確かにそういうこともあるでしょう。しかし、GNUソフトウェアの中核をなすような大部分は、完全に自由なオペレーティング・システムを作るために開発されたのです。ヴィジョンと計画によって生まれたのであって、衝動からではありません。</p>
<p>
たとえば、わたしたちはGNU
Cライブラリを開発しましたが、それはUnixライクなシステムにはCライブラリが必要だったからです。BASHはUnixライクなシステムにはシェルが必要だから、GNU
tarは、それがUnixライクなシステムに必要だからです。わたし自身のプログラムにも同じことがいえます。GNU Cコンパイラ、GNU Emacs、GDB
そしてGNU Makeがそうです。</p>
<p>
GNUプログラムにはわたしたちの自由に対する特定の脅威に対処するために開発されたものもあります。すなわち、わたしたちは、gzipをCompressプログラムを置き換えるために開発しました。それはCompressが<abbr
title="Lempel-Ziv-Welch">LZW</abbr>特許のせいでもうコミュニティのものではなくなってしまったからです。また、わたしたちはLessTifを開発してくれる人たちを見つけ、さらに最近ではある特定のプロプライエタリなライブラリによって起こった問題(下記を参照)に対応して<abbr
title="GNU Network Object Model
Environment">GNOME</abbr>とHarmonyを開始しました。また、評判がよい不自由な暗号化ソフトウェアの代替としてGNU
Privacy Guardを開発しています。なぜなら、利用者はプライバシと自由との間で選択を迫られるべきではないからです。</p>
<p>
もちろん、これらのプログラムを書いている人たちはその仕事に興味を持つようになりましたし、多くの機能が様々な人たちによってそれぞれのニーズや関心によって付け加えられました。しかし、そのプログラムが存在する理由はそれだけではないのです。</p>

<h3>予想を超えた発展</h3>
<p>
GNUプロジェクトの当初は、GNUシステム全部を作り上げ、それら全体をリリースすると考えていました。しかし実際にはそうはなりませんでした。</p>
<p>
GNUシステムの各コンポーネントはUnixシステム上で実装されたので、完全なGNUシステムが出来上がるずっと前に、各コンポーネントはUnixシステム上で実行できました。これらのプログラムの内のいくつかは評判になって、利用者はそれを拡張したり移植したりするようになりました。Unixの様々な非互換の版や、時には他のシステムにもです。</p>
<p>
こういった過程でプログラムはさらにパワフルになり、GNUプロジェクトに資金と貢献者の両方を引き付けることになりました。しかし、それが実際に稼働する最小限のシステムを完成させるのを何年か遅らせたのかもしれません。GNUの開発者は、必要なコンポーネントを次々と書くよりも、これらの移植を保守したり、既存のコンポーネントにさらに機能を加えたりすることに時間を取られるようになったからです。</p>

<h3>GNU Hurd</h3>
<p>
1990年までにGNUシステムはほぼ完成していました。残された唯一の主要なコンポーネントはカーネルです。わたしたちはカーネルをMach上で走るサーバ・プロセスの集合として実装することに決めました。Machとは当初はカーネギー・メロン大学で、その後ユタ大学で開発されるようになったマイクロカーネルです。そして、GNU
HurdはMach上で走りUnixカーネルのさまざまなジョブをこなすサーバの集合(つまり&ldquo;a herd of
GNUs&rdquo;)です。開発の開始はMachが約束されたように自由ソフトウェアとしてリリースされるのを待っていたため遅れました。</p>
<p>
このデザインを選んだ一つの理由は、カーネルのプログラムをそれ用のソース・レベルのデバッガなしにデバッグするという、一番困難であろう作業を避けるべきだったからです。Machではこのパートの作業は既に終わっており、Hurdサーバをユーザ・プログラムとしてGDBを用いてデバッグできればいいと考えていました。しかしそれが出来るようになるまでには長い時間がかかり、互いにメッセージを送りあうマルチ・スレッドのサーバはデバッグするのが非常に困難なものだということも判明しました。Hurdを安定して稼働させるのは何年も先にまで引き延ばされてしまったのです。</p>

<h3>Alix</h3>
<p>
GNUのカーネルはもともとHurdという名前になる予定ではありませんでした。オリジナルの名前はAlixで、わたしの当時の恋人の女性にちなんで名付けられたものです。Unixのシステム・アドミニストレータだった彼女が、自分の名前はUnixシステムの版に共通の命名パターンにぴったりかなと指摘しました。彼女が友人に「誰かカーネルにわたしの名前をつけないかしらね」と冗談で話していたのです。わたしは何も言いませんでしたが、彼女を驚かせてやろうとカーネルの名前をAlixにすることに決めました。</p>
<p>
それから事情が変わり、中心的なカーネル開発者のマイケル(現在はトーマス)・ブッシュネルがHurdという名前の方を気に入って、Alixをカーネルの中でもシステムコールをトラップしたりそれをHurdサーバにメッセージを送って対処する部分の名称に再定義しました。</p>
<p>
結局、Alixとわたしは別れてしまい、彼女は別の名前になってしまいました。それとは別にHurdのデザインも変わってしまい、Cライブラリが直接サーバにメッセージを送るようになったので、デザイン上もAlixのコンポーネントは消えてしまいました。</p>
<p>
しかし、そうなる前に、彼女の友人がHurdのソースコードの中にAlixの名前を見つけて彼女にそのことを話したので、彼女の名前にちなんだカーネルを見つける機会が、彼女には、たしかにあったのです。</p>

<h3>LinuxとGNU/Linux</h3>
<p>
GNU
Hurdはまだ本番環境での利用には適していません。いったい、そうなるかどうかもわかりません。ケーパビリティ・ベースのデザインが設計の柔軟性から直接に問題を引き起こしています。そして、解法があるかどうか明らかではありません。</p>

<p>
幸運なことに、別のカーネルが使えるようになりました。1991年にリーナス・トーバルズはUnix互換のカーネルを開発し、それをLinuxと名付けました。当初はプロプライエタリでしたが、1992年に、彼はLinuxを自由ソフトウェアとしました。Linuxとまだ未完成だったGNUとの組み合わせで完全に自由なオペレーティング・システムが誕生したのです。(この組み合わせの作業は、もちろんそれ自体、大変なものでした。)
今日、GNUシステムの一つの版を実際に走らせることが出来るのはLinuxのおかげです。</p>
<p>
わたしたちはこのシステムの版を<a
href="/gnu/linux-and-gnu.html">GNU/Linux</a>と呼び、その構成を、カーネルとしてのLinuxとGNUシステムの組み合わせとして表現します。全体のシステムを&ldquo;Linux&rdquo;と呼ぶ慣習には陥らないでください。それは、わたしたちの仕事を別の誰かに属するもの、と意味してしまいますから。どうか、わたしたちに<a
href="/gnu/gnu-linux-faq.html">同等の言及</a>をしてください。</p>

<h3>これからの挑戦</h3>
<p>
わたしたちは広範囲に渡って自由ソフトウェアを開発する能力があることを証明してきました。しかしだからといってわたしたちが無敵で誰にも止められないというわけではありません。自由ソフトウェアの将来の見通しを不透明にするような案件がいくつもあり、それに立ち向かうには、時には何年にも及ぶ不断の努力と忍耐が必要になるでしょう。それにはみなさんが自分たちの自由は大切なものであり、誰にも奪わせるつもりはないと表明するというようなある種の決心が必要になるでしょう。</p>
<p>
次の四つの章でその挑戦課題について見ていきましょう。</p>

<h3>非開示のハードウェア</h3>
<p>
ハードウェア産業はますますハードウェアの仕様を隠す傾向を強めています。このため、LinuxやXFree86で新しいハードウェアをサポートするための自由なドライバを書くのが難しくなっています。今は完成された自由のシステムがありますが、次のコンピュータをサポート出来ないのなら、明日もそれがあるというわけにはいきません。</p>
<p>
この問題の対処方法は二つあります。ハードウェアをどうサポートするのか見つけ出すために、プログラマはリバースエンジニアリングすることが出来ます。その他の人たちは自由ソフトウェアがサポートしているハードウェアを使うといいでしょう。その数が増えれば、仕様を隠すのは自滅的ポリシーだということになっていきます。</p>
<p>
リバースエンジニアリングは大変な仕事です。それを実行する十分な決意をもったプログラマがわたしたちの中にいるでしょうか。必ずいます。自由ソフトウェアとは原則の問題であり、不自由なドライバには我慢ならないという強い気持ちを持てるのであれば。では、わたしたちの数多くは、自由なドライバを手にするために、余分なお金や少々の時間さえ注ぎ込むのでしょうか。そうです、自由を手にしようという決意が広まっていけば。</p>
<p>
(2008年追記: この問題はBIOSにも同様に拡張されます。自由なBIOS、<a
href="http://www.libreboot.org/">LibreBoot</a>(corebootの一つのディストリビューション)があります。LibreBootが不自由な「ブロブ」なしでサポートできるように、マシンの仕様を入手できるかどうか、が問題です。)</p>

<h3>不自由なライブラリ</h3>
<p>
自由なオペレーティング・システム上で走る不自由なライブラリは自由ソフトウェアの開発者を罠にかけるようなことをしでかします。ライブラリの魅力的な機能は疑似餌のようなもので、そのライブラリを使えば罠に引っ掛かることになるでしょう。なぜなら、そうしたプログラムは有用なかたちで自由なオペレーティング・システムの一部となることはできないからです。(厳密にいえば、そのプログラムを取り入れることは出来ますが、ライブラリがないため、<em>動く</em>ことはないのです。)
さらに悪いことに、もしプロプライエタリなライブラリを使用するあるプログラムが人気を得ることになってしまえば、他の疑わないプログラマも罠へとおびき寄せられるかもしれません。</p>
<p>
このようなプログラムの最初の例がMotifツールキットで、話は80年代まで遡ります。当時はまだ自由なオペレーティング・システムは存在しなかったのですが、Motifが後々どんな問題を引き起こすことになるかは明らかでした。GNUプロジェクトは、二つのやり方で応じました。個々の自由ソフトウェアのプロジェクトには、自由なXツールキット・ウィジェットをMotifと同じように使ってくれるようお願いし、Motifを置き換える自由な代替物を誰か作ってくれないかとお願いしました。この作業には何年もかかり、Hungry
Programmersの手で開発されたLessTifは1997年になってようやく大半のMotifアプリケーションをサポートするくらいにパワフルなものになったのです。</p>
<p>
1996年と1998年の間にはQtという別の不自由な<abbr title="Graphical User
Interface">GUI</abbr>ツールキット・ライブラリが重要な自由ソフトウェアのコレクションであるデスクトップ環境<abbr
title="K Desktop Environment">KDE</abbr>に使われたことがありました。</p>
<p>
ライブラリが使用出来ないため、自由なGNU/LinuxのシステムではKDEを使うことができませんでした。しかしながら、自由ソフトウェアであることにあまり厳密に遵守しないGNU/Linuxの商用ディストリビュータは自分たちのシステムにKDEを加え、高い能力を持つが自由は損なわれたシステム、を作ってしまったのです。KDEグループはもっと多くのプログラマにQtを使うよう積極的に働きかけ、何百万もの新しい「Linux利用者」がその中に問題が含まれていることを明らかにされないままになってしまいました。事態は厳しくなりました。</p>
<p>
自由ソフトウェアのコミュニティはこの問題に二つのやり方でもって応えました。GNOMEとHarmonyです。</p>
<p>
GNUネットワークオブジェクトモデル環境、GNOMEはGNUのデスクトップ・プロジェクトです。1997年にミゲル・デ・イカザが始め、Red
Hatソフトウェアの支援を受けて開発されたGNOMEは、似たようなデスクトップの機能を提供するものですが、自由ソフトウェアのみを使っています。また、C++だけでなく様々なプログラミング言語をサポートするといった、技術的な優位性も備えています。しかし、その主な目的は自由であり、いかなる不自由なソフトウェアの使用をも必要としないことなのです。</p>
<p>
Harmonyは互換性のある代替ライブラリで、KDEのソフトウェアをQtを使わずに走らせることを可能にするよう設計されています。</p>
<p>
1998年の11月にQtの開発者はライセンスを変更し、それが発効されればQtは自由ソフトウェアになると発表しました。断言はできませんが、それは不自由だった時代のQtには問題があったとしてコミュニティが断固として対処してきた成果でもあると思われます。(この新しいライセンスは不便かつ不公正なもので、Qtの使用を避けるのは望ましいままです。)</p>
<p>
[追記: 2000年の9月にQtはGNU GPLの下でリリースされ、それによりこの問題は本質的に解決されました。]</p>
<p>
次なる誘惑となる不自由のライブラリにわたしたちはどう対処するでしょうか。罠にはまらないでいるようにしなければならないとコミュニティ全体が理解していられるでしょうか。あるいは利便性に負けてわたしたちは自由をあきらめ、大きな問題を引き起こすことになるのでしょうか。わたしたちの未来は、わたしたちの理念にかかっています。</p>

<h3>ソフトウェア特許</h3>
<p>
わたしたちが直面することになった最悪の脅威は、ソフトウェア特許から生じたものでした。それにより自由ソフトウェアはそのアルゴリズムと機能から20年に渡って締め出されてしまうような事態も起きかねないのです。LZW方式による圧縮のアルゴリズムの特許は1983年に適用され、わたしたちは未だに<abbr
title="Graphics Interchange
Format">GIF</abbr>ファイル形式に適切に圧縮する自由ソフトウェアをリリースできないでいます。[2009年の時点で、この特許は失効しました。]
1998年には、<abbr title="MPEG-1 Audio Layer
3">MP3</abbr>形式に圧縮されたオーディオ・ファイルを作成する自由のプログラムが特許侵害の訴訟を恐れてディストリビューションから外されました。[2017年の時点で、この特許は失効しました。みなさい、どれくらい長く待たなければならないか。]
</p>
<p>
特許に対抗する方法はさまざまです。特許が無効であるという証拠を探し出したり、同じことを別の方法で実現するやり方を見つけたりすることも可能でしょう。しかし、どちらもたまにしか功を奏さないのです。もしどちらも失敗に終われば、特許により全ての自由ソフトウェアは利用者が求める機能のなにがしかを欠いたままであることを強いられてしまうかもしれません。長い待機の後、特許は失効しますが、それまでどうしますか?</p>
<p>
わたしたちのように自由ソフトウェアを自由のために価値あるものだとする人なら、いずれにせよそのまま自由ソフトウェアを使い続けるでしょう。特許された機能なしになんとか作業をやり遂げるでしょう。しかし技術的優位性があるだろうという理由から自由ソフトウェアを価値あるものだとする人たちは、特許に妨げられれば、それは失敗だと言い出しかねません。ゆえに、確かに「バザール」という開発モデルの実践的有効性やある自由ソフトウェアの高い信頼性と能力について語るのは有用なことではありますが、そこで留まっていてはいけないのです。わたしたちは自由と原則について話すべきなのです。</p>

<h3>自由なドキュメンテーション</h3>
<p>
わたしたちの自由なオペレーティング・システムに最も不足しているものは、ソフトウェアの分野にはありません。システムに取り入れられる自由の優れたマニュアルが足りないのです。ドキュメンテーションはどのソフトウェアのパッケージでも重要なパートを担っているわけですから、重要な自由ソフトウェアのパッケージに優れたマニュアルが付属していなければ、それは大きな欠陥となってしまいます。今日、この手の欠陥がたくさんあるのです。</p>
<p>
自由なドキュメンテーションとは、自由ソフトウェアと同じく、自由に関わることであって、値段のことではありません。自由なマニュアルであることの基準は、自由ソフトウェアとほぼ同じで、全ての利用者に確かな自由を与えるかが問われることになります。マニュアルをプログラムのあらゆるコピーに同梱できるように、オンラインでも紙媒体でも再配布(商用販売も含む)が許可されていなければなりません。</p>
<p>
変更する自由があることも同じく重要です。原則として、わたしは、すべての種類の論説や本について変更が許されるのが本質的だとは思いません。たとえば、わたしたちの活動や見解を述べたこの文書について、わたしやあなたがこの文章を変更する許可を与える義務があるとは思いません。</p>
<p>
しかし、変更の自由が自由ソフトウェア用のドキュメンテーションにとって重要であるのには特定の理由があります。ソフトウェアを変更したり、機能を付加したり変えたりする自由を行使する場合、良心的な人ならマニュアルも変更しようとするでしょう。そうすれば正確で有用なドキュメンテーションを変更したプログラムと一緒に提供できるようになるからです。プログラマに良心的になって作業を完成させることを許さないような不自由なマニュアルは、わたしたちのコミュニティのニーズを満たさないのです。</p>
<p>
変更方法のある種の制限については別に問題はありません。たとえば原作者の著作権表示、配布の条項、または作者名リストを保全するといった制限は、構わないでしょう。変更された版にはそのことを明記するよう求めること、そのセクション全体が技術的な事柄でない事項を扱うものである限りは消したり変更してはならないと求めることも問題はありません。この種の制限は問題とはなりません。良心のあるプログラマに変更されたプログラムに合ったマニュアルを添付することを止めさせたりはしないからです。言い換えれば、そのような制限は自由ソフトウェアのコミュニティがマニュアルを完全に利用するのを邪魔したりはしないのです。</p>
<p>
しかし、<em>技術的な</em>部分についてはどこでも変更し、それを普通のあらゆる媒体で、あらゆる普通のチャンネルで配布することが可能でなければなりません。そうでなければ、制限がコミュニティの障害となり、マニュアルは自由ではなくなり、また別のマニュアルが必要となってしまいます。</p>
<p>
自由ソフトウェアの開発者は一連の自由のマニュアルを作る意識と決意を持つようになるでしょうか。もう一度いいます。わたしたちの未来はその理念にかかっているのです。</p>

<h3>今こそ自由について話さなければなりません</h3>
<p>
最近の推計ではDebian GNU/LinuxやRed Hat
&ldquo;Linux&rdquo;のようなGNU/Linuxシステムの利用者は一千万人に上ります。自由ソフトウェアは利用者が純粋に実用的な理由から集まってくるような実際的な利点のあるものを開発してきたのです。</p>
<p>
この良い影響は明白です。自由ソフトウェアの開発にさらに関心が集まり、自由ソフトウェアにはさらに多くの顧客が引き寄せられ、会社にはプロプライエタリなソフトウェア製品ではなく商用自由ソフトウェアを開発することを一層強く促してくれます。</p>
<p>
しかしソフトウェアへの関心はそれが基づく理念に対する意識よりも急速に高まっており、これがトラブルを引き起こしています。試練や上記したような脅威に立ち向かうわたしたちの力は、自由のために断固立ち向かう意志いかんによるのです。わたしたちのコミュニティがこの意志を持つことを確実にするには、コミュニティに来た新しい利用者にこの考えを広める必要があるのです。</p>
<p>
わたしたちはそうすることに失敗しています。新しい利用者をコミュニティに引き付ける努力の方が、コミュニティの一員としてのあり方を広めることをはるかに超えて広まっています。わたしたちはその両方をやらなければならず、双方のバランスをとっていく必要があるのです。</p>

<h3>「オープンソース」</h3>
<p>
1998年には新しい利用者に自由について教えることがより難しくなりました。コミュニティの一部が「自由ソフトウェア」という用語を使うのをやめて、その代わりに「オープンソース・ソフトウェア」と言い出したのです。</p>
<p>
「自由」と「無料」の混同を避ける目的でこの用語を好んだ人もいました&mdash;この目標は正しいものです。しかし、その他の人たちは自由ソフトウェア運動とGNUプロジェクトの動機となった原則の精神を横において、代わりに会社の重役やビジネス利用者にアピールする目的でした。自由よりも、コミュニティよりも、原則よりも、利益を重視する思想を持つ人々へアピールするのです。したがって、「オープンソース」のレトリックは高品質のパワフルなソフトウェアを生むポテンシャルに注目しますが、自由、コミュニティ、そして原則という考えを意図的に避けるのです。</p>
<p>
いわゆる&ldquo;Linux&rdquo;関連の雑誌がこの明白な例です。そこはGNU/Linux上で動くプロプライエタリなソフトウェアの広告でいっぱいです。次のMotifやQtが現れたら、この手の雑誌はプログラマにそれらのものから離れるよう警告してくれるでしょうか、それともその手の製品の広告を打つのでしょうか?</p>
<p>
ビジネスによるサポートがコミュニティに貢献するやり方はたくさんあり、どれも公平で有用なものばかりです。しかし自由や原則についてなるべく話そうとせずにサポートを得ようとするのはひどい事態を招きかねません。先に述べた外部への働きかけとコミュニティの一員としてのあり方を伝えていくことの間のバランスがさらに悪くなってしまうのです。</p>
<p>
「自由ソフトウェア」と「オープンソース」は、多かれ少なかれ、同じソフトウェアの分類を表しますが、ソフトウェアと価値観については違ったことを唱えています。GNUプロジェクトは「自由ソフトウェア」という言葉を使い続けます。ただ技術的なことを表すのではなく、自由という理念を表現することが重要だからです。</p>

<h3>やってみよう!</h3>
<p>
ヨーダの格言(「『試し』などいらん」)はすばらしく聞こえますが、わたしには役立ちません。作業のほとんどは本当にこれが出来るのか心配なままやってきたもので、それにもしこれをしたとしても、それで目的の達成には十分なのか確信は持てないままでした。しかし、それでもやってみたのです。なぜなら押し寄せる敵と我が街の間にはわたししかいませんでしたから。自分でも驚いたことに、時には成功をおさめることだってありました。</p>
<p>
ときには失敗もしました。いくつかの街は陥落してしまいました。そして危機にある別の街を見つけ、また別の戦闘に備えました。長いこと、わたしは脅威を発見し、我が身をその脅威と自分の街との間に投げ出し、他のハッカーたちにこっちに来て一緒にやろうと呼び掛けてきたのです。</p>
<p>
今日では、わたしはたいてい一人きりではありません。大勢のハッカーたちが戦線を持ちこたえさせんと我武者らになっているのを見るのと安心して喜ばしい気持ちになり、そして確信するのです。この街は大丈夫だと&mdash;今のところは。しかし危険は年を追う毎に大きくなっており、今やマイクロソフトはあきらかにわたしたちのコミュニティをターゲットにしています。将来の自由は約束されているわけではないのです。当然のことだと思ってはいけないのです!自分の自由を守りたいのなら、それを守る備えをしておかなければいけません。</p>

<div class="translators-notes">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
 </div>
</div>

<!-- for id="content", starts in the include above -->
<!--#include virtual="/server/footer.ja.html" -->
<div id="footer">
<div class="unprintable">

<p>FSFおよびGNUに関する問い合わせは<a
href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>までお願いします(英語)。FSFへの連絡は<a
href="/contact/">他の方法</a>もあります。リンク切れや他の修正、提案は<a
href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>までお送りください。</p>

<p>
<!-- TRANSLATORS: Ignore the original text in this paragraph,
        replace it with the translation of these two:

        We work hard and do our best to provide accurate, good quality
        translations.  However, we are not exempt from imperfection.
        Please send your comments and general suggestions in this regard
        to <a href="mailto:web-translators@gnu.org">

        &lt;web-translators@gnu.org&gt;</a>.</p>

        <p>For information on coordinating and submitting translations of
        our web pages, see <a
        href="/server/standards/README.translations.html">Translations
        README</a>. -->
正確で良い品質の翻訳を提供するよう努力していますが、不完全な場合もあるかと思います。翻訳に関するコメントと提案は、<a
href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>におねがいします。</p><p>わたしたちのウェブページの翻訳の調整と提出については、<a
href="/server/standards/README.translations.html">翻訳 README</a>をご覧ください。</p>
</div>

<!-- Regarding copyright, in general, standalone pages (as opposed to
     files generated as part of manuals) on the GNU web server should
     be under CC BY-ND 4.0.  Please do NOT change or remove this
     without talking with the webmasters or licensing team first.
     Please make sure the copyright date is consistent with the
     document.  For web pages, it is ok to list just the latest year the
     document was modified, or published.
     
     If you wish to list earlier years, that is ok too.
     Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
     years, as long as each year in the range is in fact a copyrightable
     year, i.e., a year in which the document was published (including
     being publicly visible on the web or in a revision control system).
     
     There is more detail about copyright years in the GNU Maintainers
     Information document, www.gnu.org/prep/maintain. -->
<p>Copyright &copy; 1998, 2001, 2002, 2005, 2006, 2007, 2008, 2010, 2014, 2015,
2017, 2018, 2020 Richard Stallman</p>

<p>このページは<a rel="license"
href="http://creativecommons.org/licenses/by-nd/4.0/deed.ja">Creative
Commons Attribution-NoDerivs 4.0 International License</a>の条件で許諾されます。</p>

<!--#include virtual="/server/bottom-notes.ja.html" -->
<div class="translators-credits">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
 </div>

<p class="unprintable"><!-- timestamp start -->
最終更新:

$Date: 2020/07/25 20:00:28 $

<!-- timestamp end -->
</p>
</div>
</div>
<!-- for class="inner", starts in the banner include -->
</body>
</html>