The Open Source Definition

「オープンソースの定義」について

Bruce Perens
ブルース・ペレンス
Translation by Akira Kurahone



　何年も前に買ったソフトウェアで、いまではお払箱になってしまっているもの。そういうソフトウェアをいくつかお持ちの方はまれでないと思う。どうしてそういうことになっているのか？　理由はまちまちである。マシンをアップグレードした結果、そうなったのかもしれない。別のメーカーのマシンに買い換えた結果、そのマシンで使えなくなって、そうなったのかもしれない。古くて使い物にならなくなって、お払箱になっているのかもしれない。自分のやりたいことができないので、そうなったのかもしれない。二台目、三台目のマシンに付いてきた同じソフトウェアを、封をあけずにほっておいた結果、そうなったのかもしれない。理由はどうあれ、お金を払って手に入れたソフトウェアが、使われなくなっている。それは、本当にいたしかたないことなのだろうか？
　たとえば、自分の必要なときに、ソフトウェアを無料でアップグレードしてもらえるとしたら、どうだろう？　使っているパソコンをマッキントッシュからＰＣに乗り換えたとき、ソフトウェアも無料でＰＣ版に取り替えてもらえるとしたら、どうだろう？　使っているソフトウェアが機能不足と思ったときや、パワー不足と思ったときに、自分で機能を拡張したりできたら、どうだろう？　使っているソフトウェアの開発元が倒産しても、そのソフトウェアの保守が継続されるとしたらどうだろう？　ソフトウェアのコピーが自由にできて、ソフトウェアパッケージを一本買えば、職場のワークステーション上でも、自宅のデスクトップ上でも、ノートブック上でも使えるとしたら、どうだろう？　こういうことがみんなできるとしたら、何年か前のソフトウェアがいまだに使用されている公算は高い。そして、オープンソースの環境では、こういうことがみんな合法的にできるのである。
　本章で紹介する「オープンソースの定義」は、コンピュータユーザのいわば権利章典である。様々な権利を定義し、ソフトウェアのライセンスが、オープンソースのライセンスとして認められるのに必要とされる条件を明確にしている。我われが、ユーザとして当然持つべき権利について理解を深めれば深めるほど、オープンソースでないプログラムは、オープンソースプログラムと競合しにくくなる。現に、Ｌｉｎｕｘやネットスケープは抜群の人気を博し、他のより制約的なライセンス形態のもとに販売されているソフトウェアを駆逐しつつある。オープンソースソフトウェアは、迅速な開発作業の恩恵を企業にもたらすものである。オープンソースソフトウェアは、数社が共同で開発している場合もあるが、個人が必要に迫られて自分でプログラムしたものがほとんどである。
　オープンソースの権利があればこそ、ボランティアを募ってＬｉｎｕｘなどのソフトウェアを開発することができる。企業が協力することができる。一生懸命良いプログラムを書き上げても、それを売るのは持ち主であって、自分への見返りが何もない状況を馬鹿ばかしく感じるプログラマたちも、オープンソース方式の開発には喜んで協力する。それは次のような権利が、プログラマたちも保障されているからである。



　右記の権利がソフトウェアの開発を協力する人たちにとって大事なのは、これらの権利が保証されていることによって、すべての協力者が平等になるからである。オープンソースプログラムは、売りたい人が売れるので、価格は当然安くなる。新しい市場に向けた開発も迅速に進められる。自分の時間を割いてオープンソースプログラム作りに協力した人は誰でも、自分の知識を活かしてそのプログラムの技術サポートサービスを提供する権利がある。ソースコードを入手する権利のあるオープンソースでは、ユーザが自分でプログラムをサポートすることもできる。競合企業が、サポートサービスを提供してビジネスすることもできる。プログラマなら、特定の顧客ニーズにあわせてオープンソースプログラムを改良して、新しい市場を開拓することもできる。そして、オープンソースでは、使用料やライセンス料を支払うことなしに、これらのことができるのである。
　共産主義がうまくいっていない世の中で、オープンソースがこの一見共産主義的な戦略で成功している。それはなぜだろうか？　それは、普通の（物質的な）商品と（デジタルなデータとして存在する）情報では、生産コストがまったく違うからである。ようは、経済原理が違うのである。コンピュータプログラムのように情報が材料の品物は、コピーして数量を増やすのにほとんど費用がかからない。電気代などわずかなものである。機器使用料もたいしたことはない。これに反して、食パンをひとつコピーするには、一ポンドの小麦粉が必要である。


これまでの流れ
　フリーソフトウェアの概念は、研究用器材として初期のコンピュータが大学や研究所などに初めて導入された頃からすでにあった。その当時、研究者たちはソフトウェアを自由に使いまわしていた。プログラマは、プログラミング作業に対する報酬を受け取っていたが、作成したプログラムそのものに対する報酬は受け取っていなかった。プログラマが、ソフトウェアの使用にいろいろ制限を設け、コピーごとに料金を取って収入を確保するようになったのは、コンピュータがビジネスの世界で使われるようになってからの話である。そして、フリーソフトェアの概念が政治的なアイデアとして出てきたのは、一九八四年、リチャード・ストールマンがＦＳＦ（Free Software Foundation）を設立してＧＮＵプロジェクトを始めたときである。その時、ストールマンは、人間はもっと自由であるべきだし、その自由をもっと認めるべきだと主張し、ユーザが持ってしかるべき一連の権利を、ＧＮＵ一般公的使用許諾（ＧＰＬ）としてまとめた。ストールマンはこのライセンスにコピーライト（著作権）をもじってコピーレフトと名付けた。ストールマン自身も、ＧＮＵプロジェクトの開発者としてＧＮＵ ＣコンパイラやＧＮＵ Ｅｍａｃｓ などのフリーソフトウェアを世に送り出している。とくにＧＮＵ Ｅｍａｃｓは、一部に熱狂的なファンができて、あたかも宗教的創造物のように語られるようになっている。ストールマンに触発されて、多くの人がソフトウェアを開発し、ＧＰＬライセンス適用のフリーソフトウェアを世に送り出した。本章で紹介する「オープンソースの定義」もストールマンの発想の多くを取り入れている。「オープンソースの定義」は、ＧＰＬほどの自由論的ではないにしろ、ストールマンの始めた仕事の発展形とみなすこともできる。
「オープンソースの定義」のもとになったのは、Ｄｅｂｉａｎ ＧＮＵ／Ｌｉｎｕｘの配布方法を記述したドキュメントである。Ｄｅｂｉａｎ ＧＮＵ／Ｌｉｎｕｘは、早くからあるＬｉｎｕｘベースのシステムのひとつであり、いまでも広く使われている。Ｄｅｂｉａｎ ＧＮＵ／Ｌｉｎｕｘには、フリーソフトウェアだけしか含まれていなかった。しかし、当時、フリーを主張するライセンス形態がＧＮＵのコピーレフト以外にもいくつか存在していた。しかもデビアンプロジェクト自体がフリーの定義を明確にできなかったこともあり、我われはフリーソフトウェアの規範を公表していなかった。そこで私は、デビアンプロジェクトのリーダーとして、一九九七年七月に、デビアン社会契約（Debian Social Contract）とデビアンフリーソフトウェアガイドラインを提案した。その後、これらのドキュメントは、デビアンプロジェクトの開発者たちから寄せられた意見やコメントが数多く盛り込まれたうえで、現在にいたっている。デビアン社会契約には、デビアンのシステム全体をフリーソフトウェアだけで構成する意図が記されている。デビアンフリーソフトウェアガイドラインは、デビアン構成要素のライセンスのもとで、「フリーソフトウェア」と「フリーでないソフトウェア」を明確に分類できるようにするものである。
　デビアンフリーソフトウェアガイドラインは、コミュニティから歓迎された。とくに、フリーソフトウェア革命を起こそうとして、世界初のフリーなオペレーティングシステムを開発していたＬｉｎｕｘの開発者たちは、デビアンフリーソフトウェアガイドラインを賞賛した。そしてネットスケープ社は、自社ブラウザをフリーソフトウェアにすることに決定すると、フリーソフトウェア界のマーガレット・ミード（文化人類学者）のような存在であったエリック・レイモンドにまず接触をはかった。それまでにレイモンドは、フリーソフトウェア現象についていろいろ発言していた。フリーソフトウェア文化について考察した人類学的な論文もいくつか執筆していた。彼はフリーソフトウェア現象にスポットライトを当て、それまでほとんど知られていなかった現象を世に知らしめすきっかけを作った人物である。レイモンドの論文「伽藍とバザール」は、無報酬のボランティアたちがいかにしてソフトウェアの開発を成功させたかを記したものである。彼のこの論文を読んで感銘を受けたネットスケープ社の上層部は、機密保持を条件に彼の助言を受けながら、自分たちのブラウザをフリーソフトウェア化するためのライセンス作りにはげんだ。そのときレイモンドは、ブラウザのフリーソフトウェア化を真剣に受け取ってもらいたいのなら、デビアンフリーソフトウェアガイドラインに沿ってライセンスを起草すべきであると主張している。
　この話が持ちあがる以前にも私は、レイモンドとはハッカーズ・コンファレンスで何度か顔を合わせていた（ハッカーズ・コンファレンスは、創造的で型破りなプログラマたちの集まる招待者だけの会合である）。また、いろんな話題について電子メールで意見をやりとりしていた。一九九七年二月、私はレイモンドからオープンソースのアイデアについて打ち明けられた。ストールマンのＦＳＦの考え方は、リベラルなプログラマからは歓迎されていたが、ソフトウェアビジネスの人たちからは煙たがられていた。これでは、Ｌｉｎｕｘがソフトウェアビジネスの世界で受け入れられない。そう心配したレイモンドは、それこそ誕生したてのＬｉｎｕｘビジネスの関係者たちと会合を重ね、どのようにしたら、ネクタイを締めた連中にフリーソフトウェアの概念を売り込めるかについて相談した。これらの話し合いには、ＶＡリサーチ社のラリー・オーガスティン（Larry Augustin）とサム・オックマン（Sam Ockman）（のちにＶＡ社をやめてペンギン・コンピューティング社を設立）も参加していた。彼らのほかにも参加していた人たちがいるが、私は彼らのことを直接知らない。
　ところで、「オープンソースの定義」が誕生する何か月か前に、私はオープンハードウェアのアイデアを思いついていた。内容はオープンソースソフトウェアと同じようなものだが、定義の対象はハードウェアやインターフェイスであった。いまのところ、オープンハードウェアはオープンソースソフトウェアほど成功していないが、それでも一定の役割は果たしていると思う。詳しくはhttp://www.openhardware.org/を参照してほしい。
　さて、レイモンドから相談を持ちかけられた件に話をもどすと、そのとき彼は、デビアンフリーソフトウェアガイドラインがオープンソースを定義するのにぴったりの文書と考えていた。しかし、デビアンフリーソフトウェアガイドラインという名称では、デビアンプロジェクトのことに限定しすぎるので、もっと一般的な名称が必要と思っていた。そこで私がデビアンフリーソフトウェアガイドラインを編集しなおし、「オープンソースの定義」を作成した。そして、私がデビアンプロジェクトのために設立しておいたSoftware in the Public Interest社という会社を使って、オープンソースという表現を商標登録し、「オープンソースの定義」の内容と一緒に使うようにすることを提案した。この考えにレイモンドも同意し、私は認証マークを商標登録した（認証マークとは、他人が作った製品に適用される特殊な商標のことである）。しかし、登録をすませてから一か月たったころ、私は、オープンソースの商標をSoftware in the Public Interest社に帰属させておくのは適切でないと感じ、商標の所有権をレイモンドに委譲した。その上で、私が彼といっしょに結成したのが、オープンソースのキャンペーンとオープンソースの認証マークを管理するオープンソース・イニシアティブという組織である。この文章を書いている現在、オープンソース・イニシアティブを運営しているのは、フリーソフトウェア界でその名を知られた六名から成る理事会である。この理事会のメンバーはいずれ十名程度になるはずである。
　オープンソースという表現の使用に対しては、Ｌｉｎｕｘコミュニティの人びとからも激しい批判が噴出した。彼らはすでにフリーソフトウェアの概念に賛同していた人びとであったが、そういう彼らが、「オープンソース」という言い回しは、政治的な情報産業ですでに使われていると指摘したのである。「オープン」を使い古された単語と感じた人たちもいた。すでにフリーソフトウェアという表現が定着しているのだから、それを今さら変える必要はないと思った人たちも多かった。そういう意見に対して、私は次のように反論した。「オープン」という単語がいくら使われすぎているとは言っても、英語の「free」が二重の意味−自由か価格か−を持つことに比べれば問題ではない。しかも、コンピュータやソフトウェアのビジネスでは、「価格」という単語がいちばんよく使われている。なお、「オープンソース」という言い回しを広めようとする我われの努力に対して、のちにリチャード・ストールマンがＧＮＵの自由と協調、互助精神に重きを置かれていないと不満をもらしたことがある。そのときストールマンは、オープンソースの知名度が上がるにつれて、自分の設立したＦＳＦがフリーソフトウェアの草創期に果たした役割が無視さている−「歴史から抹消されていく」ようであると言っていた。こういう不満がでてくる原因のひとつは、この業界の人たちがストールマンとレイモンドを、互いに相容れない考え方の持ち主と対立させて捉えることにも関係していた。二人は、ほんとうは同じ概念を別々のやり方で売り込んでいるにすぎない。また、そういう私もおそらく原因のひとつである。Ｌｉｎｕｘエキスポ、オープンソース・エキスポで行なわれたディベートで、二人を対立グループに割り振った責任は私にあるからだ。二人を敵対者とする見方がすっかり定着してしまい、公表しないことを前提に電子メールで行なわれた議論がオンラインジャーナルのSalon上に掲載されるにおよび、私はレイモンドに頼んで、彼がもともと加わるつもりのなかった議論であまり過激な発言をしないようにしてもらった。
「オープンソースの定義」が作成されたとき、すでにこの定義に該当するソフトウェアはたくさん出回っていた。したがって我われの次なる課題は、ユーザにとって魅力的なソフトウェアでありながら、この定義にあてはまらないもをどうするかであった。


ＫＤＥ、、そしてトロール社について
　ＫＤＥとは、デスクトップ環境構築ツールである。フリーソフトウェアの組み合わせで作られたＫＤＥは、トロール社の（制限された配布条項が付いている）商用グラフィックライブラリであるQtをそのまま含んでいた。ＫＤＥをプログラムで積極的に使おうとしたグループとトロール社は、Ｌｉｎｕｘのインフラストラクチャに商用ライブラリのQtを押し込もうとして、思ってもみない抵抗にあっている。商用ライブラリの部分をオープンソースに取り替えろという要求がコミュニティからあがり、ことの重大さを認識したトロール社は、結局、オープンソースのライセンスに切り替えている。これは「オープンソースの定義」がコミュニティにしっかり受け入れられた結果、製品を成功させるためにはトロール社もコミュニティの要求に従わざるをえなかったのである。
　ＫＤＥは、フリーソフトウェアとして登場したＬｉｎｕｘ向けのデスクトップ環境構築ツールとしては最初のものである。ＫＤＥ自体はＧＰＬに準拠していたが、グラフィカルライブラリはトロール社が著作権を持つQtに依存していた。のライセンス条件では、ソースコードの変更は許されておらず、Qtグラフックライブラリも時代遅れのＸウィンドウシステムと一緒にしか使えなかった。それ以外のウンドウシステムと一緒に使用したい人は、千五百ドルをトロール社に払って開発ライセンスを取得しなければならなかった。ウィンドウズ対応バージョンとマッキントッシュ対応バージョンのQtで稼いでいた同社が、フリーソフトウェアバージョンのQtを提供していたのは、Ｌｉｎｕｘの開発者にそれを使わせて、彼らがオープンソースとして公開する成果物を、有料で販売しているQtのウィンドウズ版やマッキントッシュ版にただで取り込もうと考えていたからである。
　このようにQtライセンスは誰の目から見ても問題だらけであったが、多くのユーザにとってＬｉｎｕｘ用としては新しいＧＵＩツールキットの魅力は抵抗しがたいものであった。そして、彼らは、オープンソースでないことを黙認してまでも、Qtを使ったのである。「ＫＤＥを使ってアプリケーションを開発している人たちは、Qtのように部分的にフリーなソフトウェアをフリーソフトウェアに含めることで、何がフリーソフトウェアであるを不明確にしている」。オープンソースの考え方を支持していた人たちは、そういって異議を唱えた。これに対してＫＤＥ側は、オープンソースのライブラリでは動作しないが、それでもＫＤＥそのものはオープンソースであると反論した。しかし私たちは、ＫＤＥはオープンソースでないプログラムを含んだオープンソースの断片に過ぎないと指摘したうえで、オープンソースを名乗りたいのであれば、Qtのオープンソース版を作るべきであると主張した。
　ＫＤＥ側は、トロール社との間で、ＫＤＥフリーQtファウンデーション協定を結ぶことで、部分的にこの問題を解決しようとした。この協定は、同社とＫＤＥプロジェクトがQtのフリーバージョンを共同で管理すること、同社が買収された場合、もしくは倒産した場合には、オープンソース準拠のライセンスでをリリースすることが定められていた。
　同じ頃、ＫＤＥに対抗して、完全にフリーソフトウェアで、ユーザフレンドリーな統合デスクトップ環境を作ろうというＧＮＯＭＥプロジェクトが始まったりもしている。完全にフリーソフトウェアで、開発言語にＣ＋＋を使用するＧＵＩツールキットであるQtライブラリ互換のライブラリを作ろうというハーモニー・プロジェクトも始まっている。そしてＧＮＯＭＥの評価が高く、ハーモニーも使いものになりそうだということがはっきりすると、トロール社もようやく、制約的なライセンスを変更しなければならないことを悟った。そうしなければ、QtがＬｉｎｕｘ市場で成功しないことがわかったのである。こうして同社は、Qtのライセンスをオープンソースなものに切り替え、問題を沈静化させた。これによってハーモニー・プロジェクトを続ける意味はなくなったが、ＧＮＯＭＥプロジェクトは続行され、いまはライセンス云々よりも、機能性、洗練度ともに最高のものを目指している。
　トロール社は、新しいオープンソースライセンスのリリースを控えて、内容を確認してほしいとコピーを一部私のところに送ってきた。公式発表までは口外しないでもらいたいという要望つきであった。しかしＫＤＥグループと仲直りしたいという気持ちが強く、また黙っているのも自分をあざむくようでいやだったので、私は正式リリースの八時間前にＫＤＥメーリングリストで発表してしまった。この電子メールはたちまちSlashdotを始め、他のオンラインニュースマガジンにも掲載され、私はとても困ってしまった。
　トロール社の新ライセンスは、パッチファイルだけは他のソフトウェアと異なる扱いをしてもよいという、「オープンソースの定義」の抜け道をうまく利用していた。この抜け道については、将来「オープンソースの定義」を改訂するときにふさぐ予定であるが、その改訂によってQtがオープンソースからはずれることはない。
　この文章を書いているいまも、オープンソースの支持層は指数関数的に急増している。つい最近も、ＩＢＭとエリクソン社がオープンソースプロジェクトへの支援を発表したことが大々的に報道されていた。イグドラシルやデビアンも、数多くのアプリケーションを含むＬｉｎｕｘシステムの配布を始めている。彼らの配布パッケージにはオープンソースのソフトウェアしか含まれていない。レッドハット・ソフトウェア社なども、それに近いことをしている。ＧＮＯＭＥシステムが完成すれば、ウィンドウズＮＴに対抗できるような、オープンソースのＧＵＩデスクトップＯＳが登場するに違いない。


「オープンソースの定義」の分析
　ここでは「オープンソースの定義」の全文を掲載して、そこにコメントと説明を（違う書体で）付け加える。「オープンソースの定義」の正式版については、http://www.opensource.org/osd.htmlを参照してほしい。
　なお、「オープンソースの定義」に少しあいまいな語句が含まれているとのご指摘をいくつか受けているが、現バージョンの使用開始からまだ一年そこそこであることを考慮し、それらの指摘はあえて反映させていない。内容的に安定していると思っていただきたいからである。今後においても、字句を少々変更することはありうるが、趣旨そのものが大幅に変わることはない。


オープンソースの定義 （ バージョン ）


ライセンスの分析と、オープンソース準拠
「オープンソースの定義」を理解するには、他の形態のライセンスを具体的に考察するのがよいだろう。

パブリックドメイン
　フリーソフトウェアは大半がパブリックドメインだと誤解されている。多くの人にとっては、フリーソフトやオープンソースの概念がややこしく、いちばん近いと思われるパブリックドメインと混同してしまうからである。しかしパブリックドメインだからといって、必ずしもプログラムに著作権が設定されていないわけではない。何らかのライセンスでカバーされていないわけではない。ただそのライセンスが、他のものと違って多くの権利を認めているだけである。
　パブリックドメインプログラムは、作者（原著作権者）が意図的に著作権を放棄したプログラムである。したがってライセンスとは両立しない。あなたは、自分の所有物を好きなように使える。パブリックドメインプログラムは、いわばあなたの所有物なので、自分の好きなようにしてよい。パブリックドメインプログラムについて、あなたがライセンスを発行することもできる。特定バージョンをパブリックドメイン以外の扱いにすることもできる。原著者の名前を削除して自分のものだと主張することもできる。
　いろいろ時間とエネルギーを投資したプログラムをパブリックドメインで公開しているのであれば、自分の著作権を適用してから、再度、そのプログラムをライセンスして公開する方法もある。たとえば第三者が勝手に修正してプライベートなものにするのを防ぎたければ、ＧＰＬなどのライセンスを適用するのも一考である。その場合でも、プログラムをパブリックドメインで公開し続けることは可能である。しかし、著作権者であるあなたの許可なしに、他人が勝手に派生物を作成することはできない。
　なお、パブリックドメインプログラムは、著作権があると宣言してライセンスを適用すれば、それを宣言した人のものになってしまう。また、「著作権所有」と記すだけでも、簡単に自分だけのものにできてしまう。（翻訳注−この節の記述は米国の著作権法に基づいた記述である。日本では、著作者人格権は放棄できないとされているので、勝手に自分が作者と主張したり、勝手に改変することはできないので注意。）

フリーソフトウェアのライセンス
　Ｌｉｎｕｘの配布ＣＤ−ＲＯＭのような、フリーソフトウェアを集めたＣＤ−ＲＯＭを持っていると、それに含まれているプログラムがすべて自分の所有物と思えるかもしれないが、それは間違いである。著作権のあるプログラムは、たとえそれがＧＰＬのようなオープンソースライセンスでも、著作権者の所有物である。プログラムの利用者は、そのライセンスによって諸権利を付与されている。また、著作権法によって、妥当な利用に関する諸権利を付与されている。
　プログラムの著者は、複数のライセンス形態を自分のプログラムに適用することもできる。たとえば、自分のプログラムをオープンソースとして公開する一方、商用バージョンを提供する人は、たいていこの方式をとっている。オープンソースライセンスが必要でない人は、商用バージョンに対して金を払い、著者はそこから収入を得ることができる。
　これから見ていくライセンスにすべて共通するのは、保障責任を拒否していることである。ソフトウェアの著作権者が、プログラム関連の法的責任に問われることのないようにというのがそのねらいである。プログラムは無料で譲渡することが多いので、これは合理的な要求であろう−著者がそれで十分な収入を得られない以上、責任保険や訴訟費用を負担できるはずがない。
　フリーソフトウェアの著者が、保障責任を拒否することができず、自作プログラムの性能について訴えられるとしたら、誰もフリーソフトウェアを世に出さなくなってしまう。著者がこの拒否権を守るのを手助けすることは、我われユーザのためになることでもある。

ＧＮＵ一般公的使用許諾（ＧＰＬ）
　ＧＰＬの全文については付録Ｂを参照していただきたい。ＧＰＬは、ソフトウェアライセンスであると同時に、政治的な声明書でもあり、ライセンスの背景にある理論的根拠の説明に大半が費やされている。その政治色にうんざりして、新しくフリーソフトウェアライセンスを作った者もいるほどであるが、ＧＰＬは法律専門家の協力で作られているので、同種のものよりよく書けている。あなたがソフトウェアをライセンスするときは、できればＧＰＬ、あるいはそのライブラリ版であるＬＧＰＬを使うことをお勧めする。どうしても別のライセンスにしたい、あるいは自分で書きたいという場合は、それだけの理由があるかどうかよく考えてからにしていただきたい。とくに、自分でライセンスを書く作業は、簡単に取りかかっていいことではない。詰めの甘いライセンスは思ってもみない事態を引き起こし、その後何十年もソフトウェアユーザに負担を強いる結果となる。
　ＧＰＬの本文自体はＧＰＬのライセンス対象ではなく、そのライセンスはごく単純である−それぞれの著作権表示とこの告知を全ての写しに載せており、しかも何ら変更を加えていない場合にのみ、あらゆる媒体への写しの配布を許可します。ここで重要なのは、一般的に、オープンソースソフトウェアのライセンスに書かれている文章は、それ自体オープンソースではないということである。ライセンスは、ライセンスの本文を改竄から保護するものではない。
　ＧＰＬの条項は「オープンソースの定義」にも合致している。ただし「オープンソースの定義」の第四条で定めている、「原作者のソースコードとの統合性」に相当する部分はＧＰＬ中にはない。
　ＧＰＬは、ＧＰＬでライセンスされたソフトウェアの派生物を非公開にすることを認めていない。派生物は、ＧＰＬで配布することが定められている。そのため、自分のプログラムに対してＧＰＬを適用した著者は、他人が加えた修正や改良を手にすることができる。修正や改良を施したのが営利企業であっても、同じである。
　ＧＰＬライセンスは、知的所有権のあるプログラムとの組み合わせを認めていない。この場合の、知的所有権のあるプログラムとは、ＧＰＬより権利の幅が狭いプログラムのことである。
　ＧＰＬには抜け道がいくつかあり、完全にオープンソースでないプログラムもＧＰＬとして認められてしまう。たとえば、ＧＰＬは、通常コンパイラやオペレーティングシステムと一緒に配布されるライブラリを、ＧＰＬライセンスのソフトウェアと一緒に使うことを許している−つまり、フリーでないプログラムの使用を部分的に許している。著作権者（普通はプログラムの著者）は、自分のプログラムにＧＰＬを冠することもできれば、自らのライセンスに違反することもできるので、こういうことができるのである。これはトロール社がQtにオープンソースライセンスを適用する前に、ＫＤＥの開発者たちが、Qt付きプログラムを配布するのに使った方法である。ただし、この方法を実際に使えるのはプログラムの著者（著作権者）だけである。したがって、プログラムを再配布する第三者は、著作権者自身が違反している条件も含めて、ライセンスに明記されているすべての条件に従わなければならない。これが、ＧＰＬでライセンスされたプログラムにQtが含まれていることにより発生する問題である。ＫＤＥ開発者は、自分たちのソフトウェアにＧＰＬではなくＧＮＵライブラリ一般公有使用許諾（ＬＧＰＬ、後述）のライセンスを適用して、この問題を回避しようとしているように見える。
　ＧＰＬの政治臭の強さに辟易する人たちの一部が、リチャード・ストールマンの思想から逃れ、彼の文言を自分のソフトウェアパッケージで繰り返したくないという理由だけで、不適切なソフトウェアライセンスを選んだ事例もある。

ＧＮＵライブラリ一般公有使用許諾（ＬＧＰＬ）
　ＬＧＰＬはＧＰＬから派生したライセンスで、ソフトウェアライブラリを対象としている。ＧＰＬと違って、ＬＧＰＬでライセンスされたプログラムは、知的所有権のあるプログラムに組み込むことができる。Ｌｉｎｕｘシステムに提供されたＣ言語ライブラリなどは、ＬＧＰＬでライセンスされたフトウェアの例である−このＣ言語ライブラリを知的所有権のあるプログラムの構築に使えなければ、Ｌｉｎｕｘはフリーソフトウェアの著者の役にしかたたない。
　ＬＧＰＬでライセンスされているソフトウェアに対しては、いつでもＧＰＬライセンスを適用することができる。ただし一度ＧＰＬに切り替えてしまったあとは、そのソフトウェアから派生したものをＬＧＰＬでライセンスすることはできない。
　前記以外の部分について、ＬＧＰＬとＧＰＬは同じである。実際の話、ＬＧＰＬには、参照項目としてＧＰＬが含まれている。

Ｘコンソーシアム、ＢＳＤ、Ａｐａｃｈｅのライセンスについて
　Ｘコンソーシアムライセンス（Ｘライセンス）とその親戚であるＢＳＤ、そしてＡｐａｃｈｅは、ＧＰＬやＬＧＰＬとは大きく性質を異にする。これらのライセンスでは、ほとんどなんでも自由にできる。というのも、ＸライセンスやＢＳＤライセンスがもともと適用されていたソフトウェアは、アメリカ政府の資金提供を受けて開発されたものだからである。すでに税金の一部でソフトウェアにお金を払っていた市民（つまりユーザ）は、好きなようにソフトウェアを活用することができたのである。
　ＧＰＬにはないがＸライセンスにはある特徴で最大のものは、Ｘライセンスでは、プログラムを修正してプライベートなバージョンを勝手に作れるという点である。言い換えれば、Ｘライセンスで提供されているプログラムのソースコードを入手し、それに手を加え、ソースコードは付けないでバイナリ形式で販売できるのである。しかも、Ｘライセンスを適用しなくてもいいのである。なお、このようにして、Ｘライセンスのソフトウェアから派生的に作成したソフトウェアでも、「オープンソースの定義」に準拠している。「オープンソースの定義」は、修正バージョンに対して原バージョンのライセンスの適用を義務づけていないからである。
　Ｘライセンスには、いくつかの変形がある。ＢＳＤライセンスやＡｐａｃｈｅウェブサーバプロジェクトなどもＸライセンスの変形である。これらのライセンスを採用している開発者は多い。なお、ＢＳＤライセンスで困ることは、ＢＳＤでライセンスされているプログラムの機能を広告でうたう場合は、カリフォルニア大学で開発された旨をかならず表示しなければならないことである（通常は脚注で）。Ｌｉｎｕｘディストリビューションのようなパッケージの中に含まれているＢＳＤライセンスのプログラムを確認し、広告でその名前を出すたびに大学名に触れなければならないというのは、ビジネス関係者にとっては頭痛の種である。現時点でも、Ｄｅｂｉａｎ ＧＮＵ／Ｌｉｎｕｘディストリビューションには二千五百種類以上のソフトウェアパッケージが入っており、仮にそのごく一部がＢＳＤライセンスだとしても、デビアンのようなＬｉｎｕｘシステムを宣伝するときは脚注だけで何ページにもなってしまう！　ただしＸライセンスには、この条件は入っていない。ＢＳＤ方式のライセンスにしようと思っているならば、Ｘライセンスをお勧めする。

Ａｒｔｉｓｔｉｃ Ｌｉｃｅｎｓｅについて
　これはもともとＰｅｒｌ言語をライセンスするために作成されたものであるが、それ以来ほかのソフトウェアにも適用されてきている。私が思うに、Artistic Licenseはずさんなライセンスである。種々の要求を提示しているが、抜け道もあるので、要求が遵守されない可能性あるからである。そういうこともあって、Artistic Licenseを適用しているソフトウェアには、ＧＰＬも適用されて、どちらかを選べるようになっているのであろう。
　Artistic Licenseは、第五条でソフトウェアの販売を禁じているが、二つ以上のプログラムを集成したソフトウェアを販売することは認めている。つまり、Artistic Licenseのプログラムに、hello-world.cをバンドルすれば、売ってもいいわけである。我われが「オープンソースの定義」の第一条に、「様々な出自のプログラムを含んだソフトウェア配布パッケージ」という表現を盛り込んだのも、Artistic Licenseにこの抜け道があったからである。しかしながら、Artistic Licenseはあまり使用されなくなってきているので、我われとしては「オープンソースの定義」の第一条から前記の表現を削除することを考えているが、実際に削除してしまうと、Artistic Licenseはオープンソースライセンスではなくなってしまう。我われとしては、軽々にそんなことはできないので、考慮と議論を重ねていきたい。実行に移るまでは一年以上はかかるであろう。
　Artistic Licenseは、派生物をフリーウェアにすることを要求しているが、第七条には抜け道があって、派生物を非公開にすることができる。パブリックドメインにすることさえできる！

ＮＰＬとＭＰＬ
　ネットスケープ・パブリック・ライセンス（ＮＰＬ）はネットスケープ・ナビゲータをオープンソースにするとき、ネットスケープ社が作成したライセンスである。実際には、ネットスケープ・ナビゲータのオープンソース版はＭｏｚｉｌｌａと呼ばれ、Navigatorという商標はネットスケープ社が保有している。エリック・レイモンドと私は、このライセンス（ＮＰＬ）作りに無報酬のコンサルタントとして参加した。最初私はＧＰＬを使うよう説得したのだが、ネットスケープ側に受け入れてもらえなかった。そのため、「オープンソースの定義」に合致した新しいライセンス作りを手伝うことにしたのである。
　ＮＰＬの大きな特徴は、ネットスケープ社にのみ適用される特別な権利を定めている点である。つまり、Ｍｏｚｉｌｌａが変更された場合、その変更部分を再ライセンスする権利はネットスケープ社に帰属するのである。その権利があるのでネットスケープ社は、変更部分を非公開にすることができる。自分たちで改良することもできる。その結果を非公開にしておくこともできる。ネットスケープ社がこの条項を盛り込んだのは、オープンソースに踏み切ると決めたとき、対象となるソースコードに他社とのクローズドなライセンスでの契約があったためである。
　この問題を解決するために、ネットスケープ社はＭｏｚｉｌｌａパブリック・ライセンス（ＭＰＬ）を作成している。ＭＰＬはＮＰＬとよく似ているが、ネットスケープ社が変更部分を再ライセンスできるという条項は盛り込まれていない。
　ただし、ＮＰＬ、ＭＰＬはどちらも、変更部分を非公開にできる。
　ちなみに、このＭＰＬのバリエーションは、ネットスケープ社以外の多数の企業で採用されている。しかしＮＰＬは、当時のネットスケープ社のビジネス状況に合わせて作成されたものであり、他社がそのまま使うことはかならずしも適当ではない。ＮＰＬとＭＰＬはナビゲータとＭｏｚｉｌｌａに限定して、ほかのプログラムではＧＰＬないしはＸライセンスを使ったほうがよいであろう。


ライセンスの選びかた
　前述したライセンスのどれかが使えるのであれば、新しくライセンスを書くべきではない。種々雑多で整合性のないライセンスが増えると、複数のプログラムが整合性のないライセンスの下に提供され、一緒に使用できなくなってしまう可能性がある。そういう状況が出現することは、オープンソースソフトウェアのコミュニティにとって好ましくない。
　もしArtistic Licenseを使用するのであれば、内容をよく吟味し、抜け道を削除しなくてはならない。それ以外のライセンスであれば、以下の諸点をよく吟味してから、実際に採用するライセンスを決めればよいであろう。



表12−１に各ライセンスの比較表を示す。

ライセンス商用ソフトウェアとの組み合わせ可能変更部分が非公開になり原著者の手元に還元されないこともある誰がライセンスしてもよい原著者には、変更部分に適用される特別な権限がある
GPL



LGPL○


BSD○○

NPL○○
○
MPL ○○

パブリック
ドメイン		○○○


今後の展望
　この文章をそろそろ印刷に回そうというころ、ＩＢＭがオープンソースの世界に加わった。ベンチャーキャピタルがオープンソースに目をつけ始めてきた。インテル社とネットスケープ社は、Ｌｉｎｕｘのディストリビュータであるレッドハット・ソフトウェア社に投資している。Ｌｉｎｕｘサーバ、ワークステーションハードウェアのインテグレータであるＶＡリサーチ社も、投資することを発表している。また電子メールソフトとして人気の高いsendmailを商品化するために設立されたセンドメール社は、六百万ドルの資金を集めたと発表している。ＩＢＭ社のＰｏｓｔｆｉｘメーラーはオープンソースとしてリリースされている。また、同じＩＢＭ製品であるＪｉｋｅｓ　Ｊａｖａコンパイラも、「オープンソースの定義」の趣旨に合ったライセンスでリリースされようとしている。この試みはいまのところうまくいっていないが、ＩＢＭ社はＪｉｋｅｓのライセンスに手を加えて完全なオープンソースにしたいらしく、コミュニティから意見を募っている。
　マイクロソフト社が作成した二つの社内文書、ハロウィーン文書がオンラインに流れているが、それによると、同社がオープンソース運動とＬｉｎｕｘに対して脅威を感じていることがよくわかる。ハロウィーン文書には、同社が市場を守るために攻撃に出ることが記されているので、これから面白い時代になりそうである。マイクロソフトは、できるだけたくさんのインターフェイスに対して著作権を設定する戦略と、できるだけたくさんの特許を確保するの戦略の二本立てで戦ってくるだろう。マイクロソフトは、フリーソフトウェアに使用を許さない独自のネットワーク機能やプロトコルを導入してくるはずである。そして他社ともども、コンピュータサイエンスの新しい方向を探り、様々な分野で特許をとりまくり、我われを技術的に取り囲んで、特許使用料を盾に我われを締め出すつもりである。ちなみに私は、ウェブマガジン「Linux World」に、特許権の領域でオープンソースの敵とどう闘うかという論文を掲載している。
　とにかく、マイクロソフト社が戦々恐々としているのは良い知らせである。第二のハロウィーン文書には、
Ｌｉｎｕｘシステムは思った通りにカスタマイズできるし、しかもマイクロソフトの人間にとってさえ、ＮＴよりよっぽど簡単だったということが興奮気味のトーンで語られている。
　我われにとって最も危険なのは、内部からの攻撃である。ＫＤＥのQtライブラリについて、トロール社が現実を認めてオープンソースライセンスをリリースした例でもわかるように、「オープンソースの定義」を水で薄めて、部分的にフリーに過ぎない製品を含めてしまおうという動きはこれからも出てくるだろう。「オープンソースの定義」ほど完全に自由でなくても、ユーザを惹きつける程度にフリーにしたソフトウェアをマイクロソフトなどが出すことも考えられる。オープンソースソフトウェアのカテゴリーが発展するのを阻止しようと、「まあまあ使える」とか「ほとんどフリーの」ソリューションが出ることもあるだろう。しかしQtライブラリが完全にオープンソースになるまでの間、ＫＤＥプロジェクトへの風当たりが強かったことを考えれば、マイクロソフトなどの戦略も同じような目にあうと思われる。
　いまのところ、我われはトロイの木馬をかわしている。しかし、我われに反感を持つ者が、Ｌｉｎｕｘシステムのセキュリティを壊すトロイの木馬入りソフトウェアを提供したらどうなるだろうか？　その張本人が、そのソフトウェアが広く配布されるのを待って、セキュリティが脆弱だと公表したら、世間はどのように反応するだろうか？　マイクロソフトのようなクローズドな開発環境より、オープンソースシステムの開発環境のほうが無防備だというイメージを世間は持つかもしれない。それによってオープンソースの信頼性に傷がつくかもしれない。しかし、クローズドな環境で開発されているマイクロソフトのシステムにも、相当のセキュリティバグがある。オープンソースにもバグはあるが、ソースコードが公開されているので、バグはすぐに発見されフィックスされる。ウィンドウズのバグは何年も見つからなかったり、フィックスされなかったりする。Ｌｉｎｕｘではどんなバグも告知された翌日にはフィックスされている。それでもトロイの木馬に対する防御は強化する必要がある。いちばん効果的な方法は、ソフトウェアの提供者やパッチの提供者の身分をきちんと把握することだろう。そうすれば、トロイの木馬を送り込む人間に刑法を適用できる。私がＤｅｂｉａｎ ＧＮＵ／Ｌｉｎｕｘディストリビューションのマネージャをしていたとき、ソフトウェアメンテナンスを行なう者は、全員身分を明らかにし、ソフトウェアがどこから来たかわかるよう公開鍵暗号鍵を利用してもらうシステムを整備した。現在では、オープンソースのプロジェクトのほとんどが、この種のシステムを採用している。
　Ｌｉｎｕｘが普通の人に使えるようになるには、まだ改良するべきところがたくさんあるが、いちばん欠けているのはグラフィカルユーザインターフェイスである。ＫＤＥプロジェクトやＧＮＯＭＥプロジェクトがそれを補うべく進められている。次の課題はシステム管理である。Ｌｉｎｕｘｃｏｎｆなどの各種設定をＧＵＩで設定できるソフトもあるが、初心者にも使える総合的なシステム管理ツールと呼べるようなものではない。カルデラ社が現在開発中のＣＯＡＳが完成すれば、システム管理がらみの問題がかなり解決できると思われるが、同社は開発部隊を十分確保できず、進捗が遅れ気味である。そして、進捗の遅れにいやけがさした参加者の中には、戦線を離脱するものも出ている。
　レッドハット・ソフトウェア社が名実ともに勝者となり、カルデラ社がそれを追いかける図式が見えてくると、過剰なＬｉｎｕｘディストリビューションも淘汰されることになるだろう。これまでレッドハット・ソフトウェア社はオープンソースの概念にしっかり関わってきた。しかし、噂にあるように、新社長のもとで株式公開（ＩＰＯ）を計画しているとしたら、それがこの関わりを力学的に弱めるかもしれない。ことに、オープンソースにそれほどこだわっていないカルデラ社が、レッドハット・ソフトウェア社の市場に打って出るような事態になれば、その可能性は十分ある。商用Ｌｉｎｕｘディストリビューションのオープンソース化が問題になるようであれば、それに代わるものとしてＤｅｂｉａｎ ＧＮＵ／Ｌｉｎｕｘのような純粋なオープンソースのバージョンが登場するであろう。そのようなバージョンは、現在のデビアンのように非営利目的のユーザを対象とするのではなく、商業市場を対象として提供されることになるだろう。
　いろいろ課題はあるものの、オープンソースは勝利すると私は見ている。コンピュータサイエンスの学生たちに知識習得の場を提供しているＬｉｎｕｘは、彼らが卒業すると同時に社会にも出ていく。各種研究機関では、科学手法に欠かせない情報の共有を実現するために、オープンソースモデルを採用している。オープンソースにすればソフトウェアが簡単に共有できるからである。ビジネスの世界がオープンソースモデルを採用したのは、反トラスト訴訟を恐れることなく、協力して問題解決にあたれるからである。また、コンピュータプログラミングに詳しい一般の人間に自由にソフトウェアを改良してもらって、その恩恵に浴することができるからである。一部の大企業も、マイクロソフト社に対抗し、今後コンピュータ業界を牛耳る第二のマイクロソフトを出さないためにオープンソースを採用している。しかし、オープンソースの未来を示すいちばん確かな指標は、これまでの道のりが示している。我われはたった数年で、ゼロからソフトウェア界の一大勢力へと成長し、数々の問題を解決しながら何百万人というユーザを獲得してきた。その動きが今後減速する理由は、どこにも見あたらないのである。