オープンソース研究会 活動報告書 平成 15 年 7 月 社団法人 日本パーソナルコンピュータソフトウェア協会 目次 オープンソース研究会について....................................................................3 ■オープンソース研究会メンバー ................................................................5 活動報告 ･････････････････････････････････････ 6 ■設立主旨 ........................................................................................6 ■活動内容 ........................................................................................6 ■オープンソース一般 ......................................................................8 1. 誰にとってのオープンソースか？.......................................................8 2. オープンソースと Linux .....................................................................9 ■技術 .............................................................................................10 3. オープンソースとセキュリティ ........................................................10 4. 開発モデルとしてのオープンソース .................................................10 5. ソースコードのメリット ...................................................................12 ■知的所有権 ..................................................................................13 6. GPL は難しい....................................................................................13 7. オープンソースソフトウェアと特許 .................................................14 ■ビジネス ......................................................................................14 8. オープンソースビジネスの現状 ........................................................14 9. GPL はビジネスにならないか？ .......................................................15 10. オープンソースと価格.......................................................................17 11. オープンソースとサポート ...............................................................17 12. オープンソースビジネスとコミュニティ ..........................................18 13. オープンソースの理解.......................................................................19 ■教育 .............................................................................................19 14. オープンソースと教育.......................................................................19 参考資料 ････････････････････････････････････ 21 ■キーワード ..................................................................................21 オープンソース...........................................................................................21 1 オープンソースイニシアティブ..................................................................23 伽藍とバザール...........................................................................................23 Linux ..........................................................................................................24 GNU ...........................................................................................................25 GPL ............................................................................................................25 フリーソフトウェア....................................................................................25 Free Software Foundation ........................................................................25 シェアードソース .......................................................................................26 コミュニティ ..............................................................................................26 再配布 .........................................................................................................27 ソースコード ..............................................................................................27 ■歴史 .............................................................................................28 「Linux」誕生以前（〜1991 年） ...............................................................28 「オープンソース」以前（1991 年〜1997 年） ..........................................29 「オープンソース」以降（1997 年〜） .......................................................30 ■References ..................................................................................31 「オープンソースの定義」 （Ver.1.9）..........................................................31 「オープンソースの定義」日本語訳（Ver.1.7）..........................................31 OSI 認定ライセンス ...................................................................................31 GNU General Public License Ver.2...........................................................31 GNU General Public License Ver.2 日本語訳 ...........................................31 GNU General Public License Ver.2 日本語訳 ...........................................31 2 オープンソース研究会について 2002 年後半あたりから e‑Japan 構想の進捗に伴って、中央官庁や地方自治体 を中心にオープンソースソフトウェアの採用に関する議論が出始めてきました。 また、ハードベンダでも Linux サーバーを中心としたオープンソースソフトウ ェアのサポートを開始しています。 オープンソースは、インターネット環境において Linux や Java、XML など標 準化技術をバックボーンとして開発されたソフトウェアのソースコードや使わ れているテクノロジーを公開することで、ソフトウェアの受託開発ビジネスや 組み込みソフトウェアが成長し、ソフトウェア技術者の増加など好結果を生ん できています。 もともとオープンソースの本質は、「ソースコードを見せる」ことにあるの ではなく、公開されたそのソフトウェアの共同開発に参加できるようにし、多 くの開発者がアイデアや知恵を盛り込み、より安定したソフトウェアに育てて いくことにあります。 ところが、オープンソースの定義が正しく伝わらず、ソースコードの公開方 法もライセンス契約の解釈も一様でなかったことで、ソフトウェアベンダもユ ーザもメリットを感じながらも、今ひとつ不安があり利用できないとの声があ りました。「オープン」という言葉が一人歩きし、オープンにされたソフトウ ェアは「フリー」であり、無料で入手することができる。さらにソフトウェア はすべてオープンソースであるべきで、ソフトウェアに著作権はないなど、ソ フトウェアビジネスそのものに支障が出てくるような短絡的な定義づけが一部 で言われ始めました。 そのような状況でオープンソースの現状に関する調査・研究が必要ではない か、と（社）日本パーソナルコンピュータソフトウェア協会（以下「JPSA」） の幹部会にて提案があり、JPSA では異例の勉強会的な研究会で、しかも 3 ヶ月 間という期間を区切って「オープンソース研究会」を発足させることとなりま した。2003 年 1 月よりメンバーを募り、2 月 4 日の準備会を経て、2 月 18 日の 第 1 回の研究会から 7 月 17 日までに計 8 回（準備会を含めて計 9 回）行われま した。 オープンソース研究会のメンバーには、JPSA 会員企業を中心に、アプリケー ションソフトや OS のメーカー、受託開発や SI ベンダ、サポート会社に加え、 コミュニティとのつながりの深いイベント企業や技術動向に明るいライターな ど多方面から参加していただきました。実際にはプロダクトやビジネスの企画 やマーケティング部門の責任者の方、そして実際に SE や法人営業を経験された マネージャーなど現場の実情をよくご存じの方々で構成されました。法的問題 や契約内容について検討する委員会や技術者の考えるオープンソースを論議す るグループが他にもあります。しかし、オープンソース研究会は実際に多くの ユーザに提案をし、ソフトウェアを導入し、サポートを行っている方々によっ て、現実的でしかも前向きな議論を行うことを第一義とすることで、ソフトウ ェアビジネスの新しい可能性について検証していくことができると思われまし 3 た。 研究会の進め方としては、各委員の実経験や実際のユーザの状況をもとに議 論を行う場合もあるので、毎回の議事録は非公開とし、活動終了後に報告書と してまとめることにしました。各委員とも会議では積極的に発言され、よくあ る単なる報告の読み上げ的な研究会とはまったく異なった白熱した議論が毎回 行われました。 各委員のオープンソースに対するとらえ方や現状、オープンソースソフトウ ェアの開発事例の紹介、オープンソースソフトウェア製品の開発や営業、サポ ートの体制、ユーザからの反応、商談成立のポイントと様々な角度からの意見 を出し合い、議論を深めました。 加えて、経済産業省より政府調達にみるオープンソースや各国の採用状況、 スタンス、今後の展開とその可能性などの説明もいただきました。 ソフトウェアビジネスは今までいくつかの変革期があり、それはまた大きな チャンスでもありました。オープンソースの流れがこれに当たるかは、今後の 進捗によりますが、アンテナを伸ばし、積極的に研究しておくことは必要だと 思います。研究を進めていく中で、多くのビジネスの可能性を見いだし、ソフ トウェア市場の拡大につながっていければと思います。そしてその結果、ユー ザが個々の様々な条件や環境において複数の選択肢の中から優れたソフトウェ アを選択できることが望ましい姿だと思います。 オープンソース研究会の議論を踏まえ、活動の記録として報告書を発行しま す。JPSA 会員企業やソフトウェアビジネスに携わる方々、そしてユーザにとっ て何らかの参考になれば幸いです。 最後に本研究会の発足から活動そして報告書作成に至るまで、委員各位そし て JPSA 事務局にはご多忙中にもかかわらず、積極的に参加・活動を行っていた だきました。ここに深く感謝申し上げます。 平成 15 年 7 月 社団法人日本パーソナルコンピュータソフトウェア協会（JPSA） オープンソース研究会 座長 澤崎 章二 4 ■オープンソース研究会メンバー （社名五十音順、敬称略） • 株式会社ジャストシステム／澤崎 章二（座長） • • • • • • • • • • 株式会社アステック／矢野聡 株式会社インテリジェントウェイブ／白杉政晴 ウッドランド株式会社／村松邦浩 キースリーメディア・イベント株式会社／原洋一 コーポレイトソフトウェア株式会社／乙黒淳 コーポレイトソフトウェア株式会社／荒木美和子 株式会社タイムインターメディア／藤原博文 ニスコム株式会社／真田朋昭 マイクロソフト株式会社／反町浩一郎 株式会社リード・レックス／中道泰隆 • 株式会社テックスタイル／風穴江（ジャーナリスト） • • • 社団法人日本パーソナルコンピュータソフトウェア協会／山内敏嗣 社団法人日本パーソナルコンピュータソフトウェア協会／高部美紀子 社団法人日本パーソナルコンピュータソフトウェア協会／西村高志 5 活動報告 ■設立主旨 「オープンソース」という言葉を耳にするようになって久しいが、そこに込め られた極端な期待感や、すべてがフリーであるかのようなイメージ先行の風潮 には疑問を抱かざるを得ない。 そこで、様々な切り口からオープンソース全体を再度検証し、業界の適切な 発展のためにオープンソースをどのように捉えるべきかを議論する場として 「オープンソース研究会」を設立した。 ■活動内容 オープンソース研究会準備会議 ･･････････ 平成 15 年 2 月 4 日（火） • • 参加者：8 名 オープンソース研究会の設立趣旨、活動の方向性について議論 第 1 回オープンソース研究会 ･･･････････ 平成 15 年 2 月 18 日（火） • • • • • 参加者：13 名 座長の選出 活動スケジュールの決定 用語定義について議論 議論するべきテーマを決定 第 2 回オープンソース研究会 ････････････ 平成 15 年 3 月 3 日（月） • • 参加者：15 名 ゲスト：経済産業省 情報処理振興課 久米課長補佐、河野課長補佐 • • 経済産業省の講演「オープンソフトウェアについて」 講演で触れられた内容について議論 第 3 回オープンソース研究会 ･･･････････ 平成 15 年 3 月 17 日（月） • • 参加者：16 名 第 1 回研究会で宿題とした「オープンソースのメリット、デメリット に関する各人の見解（アンケート）」を元に議論 第 4 回オープンソース研究会 ････････････ 平成 15 年 4 月 7 日（月） • • • • • 参加者：14 名 ゲスト：経済産業省 情報処理振興課 木島係長 株式会社タイムインターメディア藤原氏の講演「オープンソース事例」 ジャーナリスト風穴氏の講演「オープンソースの基礎知識」 藤原氏、風穴氏の講演を踏まえ、オープンソースの現状について議論 第 5 回オープンソース研究会 ･･･････････ 平成 15 年 4 月 21 日（月） • • • 参加者：15 名 オープンソースのメリットについて議論 オープンソースと教育について議論 第 6 回オープンソース研究会 ･･･････････ 平成 15 年 5 月 13 日（火） • • 参加者：12 名 オープンソース研究会活動報告書の内容について議論 第 7 回オープンソース研究会 ････････････ 平成 15 年 6 月 2 日（月） • • 参加者：11 名 オープンソース研究会活動報告書（ドラフト）について議論 第 8 回オープンソース研究会 ･･･････････ 平成 15 年 7 月 17 日（木） • • • 参加者：8 名 記者発表に関する報告 参考資料編を加えた報告書案について ディスカッション オープンソースの議論は、置かれている立場や状況によって様々な視点があ り、必ずしも 1 つの結論に収束させることができるとは限らないテーマも多い。 そこで今回は、オープンソース研究会として無理に意見を一本化することはせ ず、議論の中で出された主な意見を、テーマごとに整理してまとめるに留めた。 様々な視点からの意見を参照することで、オープンソースに対する考えをま とめる一助になれば幸いである。 7 以下、ゴシック体で箇条書きになっている部分が、オープンソース研究会の 一連の議論の中で、参加者から出された意見（をまとめたもの）である。 なお、もともとオープンソース研究会の方針として、議論において個人的見 解を発言して頂く場合を考慮し議事録等において個々の意見の発言者を特定し ないことに加え、以下にまとめる際に同種の意見を集約して、各意見の発言者 を示すことはしていない。 また、文中、やや不正確な印象を与えかねない用語や表現があるが、それに ついては、そうした意見を議論の文脈から切り離したことによる影響であるこ とにもご留意頂きたい。 ■オープンソース一般 1. 誰にとってのオープンソースか？ オープンソースについて議論する場合に、考慮しておくべきこと、認識を合 わせておくべきことなど、配慮すべきことについて意見が出された。 ソフトウェアに関しては、一口に「利用」といっても、エンドユーザに よる「実行」から、開発者による「（ソースコードの）流用」まで、いろ いろな意味がある。これと同じようにオープンソースについても、エン ドユーザにとってのオープンソースと、開発者にとってのオープンソー スとでは、それがもたらす意味が異なる。オープンソースについて議論 する際に、「誰にとっての」という部分を曖昧にしていては、議論がかみ 合わない可能性がある。 エンドユーザにとっては、提供される機能が問題なのであって、それが オープンソースソフトウェアかどうかは、あまり関係ないのではないか。 特に GPL に関しては、どこまでが「利用」 （使用許諾条件の適用範囲） になるのか、難しい問題がある。 パッケージソフトウェアベンダの話と、システムインテグレータの話は、 同じオープンソースといっても視点がまったく異なる。それぞれをきち んと分けて議論するべきではないか。 オープンソースソフトウェアは誰も独占することができないので、ユー ザにとっては、特定ベンダに依存してしまったり、ベンダの方針に縛ら れたりすることがない、というメリットがある。 8 日本国内のソフトウェアベンダは、企業規模が小さいところが多いため、 オープンソースによって開発コストを削減できるのであれば、ビジネス としてのメリットも出やすいのではないか。 世界各国の政府がオープンソースに取り組んでいる動きが伝えられてお り、オープンソースソフトウェアの採用の動きも広がっている。しかし、 採用する場合の思惑や目的は、各国の事情によって異なることには注意 が必要だ。 政府や地方自治体、民間企業、コミュニティ、ユーザやベンダなど国内、 海外を問わず、標準化技術を策定していくことも必要だと思う。 2. オープンソースと Linux Linux が代表的なオープンソースソフトウェアであることは言うまでもない が、オープンソースソフトウェアと言えば Linux が暗に仮定されてしまうこと について懸念する意見が出された。 特に政府関連の話では、 「オープンソースソフトウェア」というと、Linux に偏りすぎているように思う。どうして Linux が中心的に扱われてしま うのか？ 「オープンソース」という言葉が生み出されることになったきっかけが Linux の成功にあったことや、最も広く利用され、活発に開発されてい るオープンソースソフトウェアが Linux であるという事実が背景にあ る。オープンソース開発モデルを採用していても、開発者の参加が少な かったりして、うまく進んでいないプロジェクトも多くある。その中で は、オープンソース開発モデルとして最も成功しているものの１つが Linux であると言ってよい。 オープンソースと言っても Linux だけではない。オープンソースのビジ ネスモデルとして Linux だけを考えていては、議論の視野が狭くなって しまうのではないか。 9 ■技術 3. オープンソースとセキュリティ ソースコードがすべて公開されているというオープンソースソフトウェアの 特徴が、ソフトウェアのセキュリティにどのように影響するのかについて、意 見が出された。 ソースコードが公開されてしまっているので、重要な機密に対する「セ キュリティ」が証明できないのではないか。 ソースコードが公開されていないソフトウェアは、そこでどんなことが 行われているのか分からないという不安がある。 「セキュリティ」の基本は、それが「安全」であることが客観的に証明 されることが重要である。「やり方（ソフトウェアの場合はソースコー ド）を隠す」という方法は、一見セキュアな感じがするかもしれないが、 そうではない。むしろ、「やり方」をすべて公開した上で、客観的な検証 によって安全であることを確認することのほうが重要。暗号技術などで も、暗号化アルゴリズムを隠すのではなく、公開した上で、その安全性 を客観的に検証することが常識となっている。 4. 開発モデルとしてのオープンソース 「オープンソース」は、ソフトウェアを共有し、共同で開発を進めていくと いう、開発モデルの 1 つの手法である。しかし、その自由さによって、かえっ て開発がバラバラになるのではないかと懸念する意見が出された。 コミュニティ主導で開発が行われると、バージョンが枝分かれしてしま い、互換性や効率に問題が出てくるのではないか。 オープンソースの歴史を振り返ってみても、最初に「一緒にやろう」と いうことを決めてから始まるプロジェクトは、あまり成功していないよ うな印象がある。逆に、オープンソースの手法で成功したソフトウェア は、最初にモノがあって、それについて多くの人が興味を持って自然に 集まってきた、という流れで始まることが多いと思う。 オープンソースにしろ、非オープンソースにしろ、ソフトウェアの開発 には動機が必要であることには変わりがない。また、出来上がったもの の品質は、その開発動機が経済的メリットによるものなのか、技術的興 味によるものなのかは、あまり関係がないのではないか。動機が何であ 10 るにせよ、よくできたソフトウェアもあれば、出来の悪いソフトウェア もある。 オープンソースの共同開発モデルというのは、やはり「アンコントロー ラブル」なものになってしまうのではないか。 「アンコントローラブル」というのは、「誰も独占できない」ということ の裏返しでもある。そして、この「誰も独占できない」ということは、 ユーザにとってはメリットの 1 つとなり得る。 オープンソースの場合は、共同で開発する自由と同時に、別個に開発す る自由もある。なので、あるオープンソースソフトウェアの開発が、1 つにまとまって続けられる場合もあるし、途中で分岐して別々のソフト ウェアになることもある。しかし、オープンソースであることによって、 分岐したとしてもお互いのソースコードは公開されており、お互いに相 手のコードの一部を取り込んだりすることができる。オープンソースで あれば、開発プロジェクトが分岐したとしても、開発の成果はお互いに 有効に利用することができる。 「共同開発」という点では、オープンソースも、非オープンソースも、 あまり変わらない。ただオープンソースの場合は、誰も独占できない、 誰でも開発に参加できる、という点が特徴となる。非オープンソースの 場合は、アライアンスを組んだ企業同士だけが開発に参加できる。 オープンソースによって共同開発が可能になるといっても、結局は開発 者がそれほど集まらないこともあるのではないか。特に日本では。やは り法人としてきちんとした組織にして、きちんと開発するべきなのでは ないか。 オープンソースという手法を用いることで、開発コストを大幅に削減で きる可能性がある。ソフトウェアをゼロから開発して、自分でサポート し、さらに技術革新に追随するための研究も行うとすれば、相当の開発 コストがかかる。しかし、それをオープンソースソフトウェアとして行 えば、そうした開発コストを自分一人だけで抱え込む必要はなくなるの で、全体のコストを大幅に圧縮できる可能性がある。これが開発モデル としてのオープンソースのメリットである。 オープンソース方式のメリットは、それなりに認知されていると言って もいいのではないか。Microsoft 社も、大学などと契約を結んで、 Windows の ソ ー ス コ ー ド を 提 供 し 、 研 究 開 発 し て も ら う 動 き （「SharedSource 戦略」）を加速させている。このことは、オープンソー ス的な共同開発のメリットを部分的にでも認識しているからではないか と思う。 11 ただ、オープンソース方式による「共同開発」モデルの実効性を定量的 に測ることは難しい。 プリプロダクションの用途では、オープンソースソフトウェアが利用し やすいのは確か。自由に利用できるし、ソースコードが公開されている ことから、自由にカスタマイズすることができるから。特にハードウェ アが関係する場合は、ソースコードを自由にできるというメリットが大 きいと感じる。 ライブラリのような、多くの人にとって「基盤」となるようなソフトウ ェアは、オープンソース方式で共同開発するというモデルを採用しやす いのではないか。 オープンソースという開発モデルが良いのか悪いのかは、最終的には市 場が判断することだと思う。 5. ソースコードのメリット オープンソースソフトウェアの特徴の 1 つであるソースコード公開につい て、その手法に期待する意見と、懸念する意見とが出された。 オペレーティングシステムのソースコードが公開された場合、より高機 能で安定したアプリケーションを開発できる「可能性がある」。 ソースコードがすべて公開されていなくても、ソフトウェアの外部仕様 （API など）が公開されていれば、それを活用するのに問題がない場合も 多い。 ソースコードが公開されているということは、実際問題、それだけで、 いろいろと開発の参考になることは多いと感じている。 「ソースコード公開」がメリットとなるかどうかは、ソフトウェアの種 類などによっても違ってくるのではないか。すべてのソフトウェアが、 オープンソースに適しているわけではないと思う。 12 ■知的所有権 6. GPL は難しい オープンソースライセンスとして広く利用されているライセンス「The GNU General Public License（GPL）」（厳密に言えば、GPL を採用するソフトウェ アは「自由ソフトウェア」と呼ばれる）は、著作権者としての権利を利用して 自由であることを保証するという、いささか「トリッキー」なライセンスであ る。そのため、その正確な理解は難しいという声がある。 オープンソースに関する議論をする場合、自分も含めて、GPL を理解す るのが難しいと感じる。GPL 以外のオープンソースライセンスについて も、理解が不足していると思う。 GPL の法的な側面を正確に理解するのは難しいが、何のために GPL の ようなライセンスが採用されるのかという方向から考えれば、GPL の役 割を理解する早道になる。 ライセンスに GPL を採用するのは、「共同開発モデル」を採用したいか らである。基本的な考え方は、自分が作ったものに対して自分が権利を 主張するのと同様、みんなで開発するものはみんなで共有しよう、とい うこと。両者はロジックとしては同じだ。 「GPL だから知的所有権が認められない」、 「GPL は知的所有権を放棄 している」という理解は正しくない。 GPL（や、それと同様のオープンソースライセンス）を採用し、多くの 人と共有しながら共同開発することで、開発スピードをアップさせるこ とができる。Linux の開発を Linus Torvalds 氏が 1 人で進めていたとし たら、10 年経った今でも OS として完成していたかどうか分からない （お そらく完成していないだろう）。まさにそこに、オープンソース開発手法 のメリットを見ることができる。 GPL（や、それと同様のオープンソースライセンス）には、それなりの メリットはあるものの、決してそれが万能だというわけではないと思う。 コミュニティによる共同開発という手法を利用しないのであれば、自分 だけで（自社で）開発すれば良いし、権利も独占すれば良い。単独で開 発する場合は、その権利や利益を独占できるが、その一方で、開発に必 要なリソースを全部自分で（自社で）負担しなければならない。Microsoft 社が OS 開発に投じている研究費、開発費、サポート費などを考えれば、 ソフトウェアの種類によっては、単独で開発し続けることが非常に困難 なものがあることが分かると思う。そこまでの開発リソースを自分（自 13 社）だけで負担できない場合は、オープンソース開発モデルを用いて共 同開発するという選択肢がある。 7. オープンソースソフトウェアと特許 オープンソースソフトウェアは、ソースコードが公開され、その開発には誰 でも参加できるという特徴がある。このことから、「素性の分からないコード」 が紛れ込む危険性を指摘する意見が出された。 オープンソースソフトウェアは、ソースコードの出所がはっきりしない ので、サブマリン特許のような問題に関する懸念もある。 「サブマリン特許」 （発明を秘匿しておき、それを利用した技術が世の中 に広まった頃を見計らってから申請される特許。莫大な特許利用料を徴 収する目的で使われる。）は、アメリカのように、「先発主義」（特許申請 が後になっても、先に発明していることを証明できれば、特許権が与え られる方式）を採用している場合にだけ起こりえるものである。日本の ように「先願主義」（発明の時期には関係なく、特許申請を先に行った方 に特許権が与えられる方式）の国では、その危険性はない。 そもそも「サブマリン特許」の問題は、「オープンソースだからその危険 性が高い」というものではなく、オープンソースではないソフトウェア についても、同様の確率で危険性は存在する。特許は、 「表現されたもの」 を保護する著作権と異なり、アイデアについて保護する制度なので、ソ ースコード（表現されたもの）が開示されている、いないということは、 基本的に関係がない。従って、 「オープンソースだから特許侵害の危険が ……」という指摘は当たらないと思う。 ■ビジネス 8. オープンソースビジネスの現状 オープンソースのビジネスについては、その可能性には期待する声はあるも のの、実際に「継続的な大成功」を収めた企業がほとんどないことから、不安 を感じるという率直な意見が出された。 オープンソースソフトウェアのビジネスに関しては、成功、失敗の結論 を出すには時期尚早で、まだもう少し様子を見なければいけないのでは ないかと思う。 14 典型的な「オープンソースビジネス」と見られている Linux ディストリ ビューションベンダでも、 「ものすごく儲かっている」ところはないのが 現実ではないか。 Linux のサポートサービスや、システムインテグレーションなどでは、 IBM などが利益を上げているという報道がある。しかし、IBM がオー プンソースに積極的に取り組んでいるといっても、そこに「オープンソ ースの心」があるわけではない。結局はビジネス上の判断でそうしてい るだけではないのか。 IBM 以外にも、オープンソースビジネスで利益を上げている企業はあ る。例えば Zope Corporation は、「Zope」という、オープンソースのア プリケーションサーバを開発している。「Zope」は完全にオープンソー スソフトウェアとして公開されているが、Zope Corporation は、Zope のサポートや、Zope を利用したシステムインテグレーションで収益を上 げている。 オープンソースの性質によるのかもしれないが、現状ではオープンソー スビジネスは、パッケージ製品よりも、個別にカスタマイズされるシス テムインテグレーションのようなところで成り立っているのではない か。 「すべてを独占していなければ儲けられない」という考え方は、ビジネ スモデルの一側面にすぎない。独占していなくても儲けている（＝ビジ ネスになっている）ビジネスは、世の中にたくさんある。同様に、オー プンソースはソフトウェアを独占できないので儲けられないと考えるの は早計に過ぎる。 9. GPL はビジネスにならないか？ オープンソースの分野で「継続的な大成功」を収めた企業がまだほとんど輩 出されていないということもあって、オープンソースビジネスは難しいと感じ る人が多い。その原因として GPL というライセンスの特殊性を挙げる考え方 について、疑問を投げかける意見が出された。 オープンソースのビジネスがうまくいかない原因について、よく「それ が GPL だからビジネスにならない」という言われ方をするが、単純に そうとは言い切れないのではないか。必要なアプリケーションが揃って いないとか、ビジネスのやり方が拙かったなど、ビジネスがうまくいか ない原因は他にもあるのではないか。オープンソースビジネスの難しさ を、すべて GPL のせいにするのはどうかと思う。 15 「GPL をライセンスにしたソフトウェアは、パッケージソフトウェアに は使えない」と言われることがあるが、必ずしもそうではない。ケース バイケースだ。GPL をライセンスにしたソフトウェアでも、パッケージ ソフトウェアに利用できないということはない。 GPL ではないが、オープンソースソフトウェアの「OpenOffice.org」を ベースに使って、「StarSuite」というオフィスアプリケーションスイー トのパッケージソフトウェア製品を販売している例（Sun Microsystems 社）もある。 確かに「GPL」には、「販売してはならない」とは書かれていないので、 GPL を採用するソフトウェアを「販売」することには、何ら問題がない。 GPL をライセンスにしたソフトウェアは、使用者に対して複製や再配布 の自由を認めなければいけないので、現実問題として「独占的に販売す ることで利益を上げる」ということはできない。 Linux ディストリビューションメーカーの中には、商標権や編集著作権 を利用して、自らの Linux ディストリビューションの再配布等を制限し ている例がある。Linux ディストリビューションを構成している個々の ソフトウェアがオープンソースライセンスだったとしても、それらを寄 せ集めて編集した「編集著作物」 （この場合は Linux ディストリビュー ション）には、編集者が編集著作権を主張できることを利用している。 また、商標権を利用して名称の使用を制限することで、事実上、再配布 を制限するという方法もある。雑誌等の付録 CD-ROM への収録を制限 する場合などに、商標権を利用した方法が使われることがある。 GPL を作成した Free Software Foundation の Richard Stallman 氏の 考え方は、ビジネスを否定するものではないのか？ Stallman 氏が「ビジネス」を否定しているということはない。彼は単に 「ソフトウェアの独占」に対して異議を唱えているだけ。また、自由ソフ トウェアやオープンソースソフトウェアという観点でも、彼のような考 え方は、1 つの例にすぎない。 問題なのは、オープンソースになった際に、ソフトウェア産業が成り立 つのかどうかということ。 「何が何でも GPL にしなければいけない」と決められるのは困る。 16 10. オープンソースと価格 オープンソースには、開発モデルとしての側面のほかに、ユーザが自由に利 用できるソフトウェアという側面もある。本来の目的からすればそれは副次的 な産物なのだが、現実には、「無償で利用できる」ということにメリットを感じ ているユーザも少なくない。そういう現状について意見が出された。 「オープンソース」＝「無料」ということでは決してない。 オープンソースソフトウェアは、複製や再配布が自由に行えるので、価 格の下落につながったり、経済活動が成り立たなくなったりしてしまう のではないか。 ユーザ側では、オープンソースソフトウェアを利用することでコストを 低く抑えられる可能性がある、ということをメリットとして感じている ことは確かだろう。 オープンソースというだけで値切られるなど、現実には、オープンソー スソフトウェアを利用した場合の価格は、低く抑えられてしまう傾向が ある（安くなることが当然のように期待されている）。 11. オープンソースとサポート オープンソースソフトウェアの本質「誰にも独占されない」ということにつ いて、それでは「誰も保証しない」ということにつながってしまうのではない かと懸念する意見が出された。 「誰も独占できない」ということは、「誰もサポートしない」ということ ではないか？ 「誰も独占できない＝誰もサポートしない」ということではない。そう いう言い方をするならば「誰も独占できない＝誰でも保証できる」とい う言い方が正しい。オープンソースソフトウェアの場合、開発コミュニ ティは「無保証」としている場合が多いが、それを開発コミュニティ以 外の人や会社が「保証」（サポート）を提供することもできる。非オープ ンソースソフトウェアの場合は、最終的な保証ができるのは開発元だけ である（ソースコードがないから）。従って、サポートはその企業に頼る しかない（開発企業のサポート方針やサポート能力に縛られてしまう） 。 しかしオープンソースソフトウェアの場合は、例えば、Red Hat Linux のサポートを、Red Hat 社以外の会社（や人）が行い、そこで Red Hat 社以上のサポートサービスを提供することが現実に可能だ。これはつま り、ユーザにとっては、サポートサービスについて「選択肢がある」と いうことになる。 17 オープンソースソフトウェアについては、開発元（開発コミュニティ） と、サポートを提供するところが分離していることもある。Linux カー ネルの開発は Linus Torvalds を中心とした開発コミュニティで行われ ているが、実際に顧客に対するサポートは Red Hat 社などの Linux ディ ストリビューションメーカーらによって提供されているのが好例。 オープンソースソフトウェアのサポートは技術さえあれば誰でもできる というのは、原理的には正しいかもしれない。しかし、だからといって 「必ず提供される」とは限らない。理論的に正しいということと、現実に サービスが成り立っているかということとは別。 場合によっては、 （多くの非オープンソースソフトウェアのように）開発 元とサポート元が同一であることによるメリット、1 つの中で完結して いることのメリットもあるのではないかと思う。 オープンソースソフトウェアをきちんとサポートしているというビジネ スが、現状ではなかなか実感できない。そういう企業はまだそれほど多 くはないのではないか。 12. オープンソースビジネスとコミュニティ オープンソースソフトウェアの開発には誰でも参加することができ、その開 発活動（およびそれに関わる人々）は「コミュニティ」と呼ばれる。コミュニ ティによるソフトウェア開発が、オープンソースソフトウェアの特徴の 1 つで もあるが、それについて、ビジネスとの結びつきを考える意見が出された。 オープンソースソフトウェアは、開発もサポートもコミュニティが主導 しているが、オープンソースビジネスでは、そうしたコミュニティの仕 組みをうまくビジネスに結びつけていかないと、長続きしないのではな いか。コミュニティとビジネスをうまく結びつけていくような具体的な 案や例はあるのだろうか？ コミュニティというより、プロジェクトベースで考える必要があるので はないか。 インターネットと同じように、どこまでを皆（コミュニティ）と共有し、 どこまでをビジネスとして競合するかをきちんと見極める必要がある。 18 13. オープンソースの理解 オープンソースとはどういうことなのか、どういうメリットがあるのかとい うことは、まだ広く認知されているわけではない。そのことが、オープンソー スビジネスの足かせになっている可能性があるのではないかという意見が出さ れた。 議論を重ねてきたことで、オープンソースのメリットが理解できてきた が、やはり一般にはまだ広く認知されているとは言い難い。特に、営業 担当者 1 人 1 人が、ここで議論されているような話を客先で説明して歩 くのは、実際問題として辛いものがある。オープンソースのビジネスを 考える場合、このことをまず何とかしなければならないと思う。 オープンソースに関連して、ビジネスの対極になるような極端な意見を 述べる人たちがいる。そういう風評が広まると、オープンソースビジネ スを進めていく上ではマイナスだと思う。 正直なところ、オープンソースのメリット、デメリットに関して混乱し ている。オープンソースだとソフトウェア産業そのものが経済的に成り 立たない可能性があるという指摘もあれば、オープンソースによって共 同開発することにより、開発コストを下げたりすることができるという 考え方もある。どちらがどのようにメリットとなり得るのか、混乱して いる。 ■教育 14. オープンソースと教育 オープンソースソフトウェアの「ソースコードが公開されている」「誰でも開 発に参加できる」という特徴は、コンピュータ教育においてもメリットをもた らす可能性があるのではないかという意見が出された。 大学や研究機関にとっては、人材育成面などでオープンソースのメリッ トが受けやすいのではないか。 オープンソースソフトウェアは世の中にたくさんあるが、実際にソース コードが参考になるレベルのものは、非常に少ないと感じている。だか ら、オープンソースソフトウェアのすべてについて、ソースコードが参 考になる、というわけではないと思う。 ソースコードが参考になるレベルに達しているソフトウェアは、全体の 数％しかないかもしれないが、それは何も、オープンソースソフトウェ 19 アに限ったことではないのではないか。非オープンソースソフトウェア でも、「ひどいコード」のソフトウェアはたくさんあるはず。ただ、オー プンソースソフトウェアの場合はすべてが白日の下にさらされるので、 良いコードも悪いコードもすべてが見えてしまう。しかし、非オープン ソースソフトウェアの場合は、悪いコードがあっても目に入ることがな いので（相対的に）気にならないだけでは。 オープンソースソフトウェアだからといって、それだけでソースコード の再利用が自動的に進む、ということでもない。 日本でも、オープンソースソフトウェアの開発者がもっと育つように、 お金を出すべきではないのか。 20 参考資料 ■キーワード オープンソース 「オープンソース」（Open Source）とは、不特定多数の開発者が開発に参加 できるようにソフトウェアのソースコードを公開すること、またはそのような ソフトウェア開発手法のことをいう。 また、そのような開発手法によって開発されているソフトウェアを「オープ ンソースソフトウェア」 （Open Source Software）、そのような開発手法を維持 するために考えられたソフトウェアライセンスを「オープンソースライセンス」 （Open Source License）という。 代表的なオープンソースソフトウェアとしては、UNIX ライクなオペレーテ ィングシステム「Linux」、インターネットで最も利用されている Web サーバ 「Apache」、SQL データベースサーバ「PostgreSQL」、アプリケーションサー バ「Zope」、スクリプト言語「Perl」などがある。 代表的なオープンソースライセンスとしては、Free Software Foundation が GNU プロジェクトのために作成した「GNU General Public License」（GPL）、 Apache プロジェクトで採用されている「Apache Software License」、BSD UNIX のために作られた「BSD Copyright」、Perl で用いられている「Artistic License」などがある。 オープンソースという言葉の誕生は、記録によれば、1998 年 2 月 3 日となっ ている。そのときの会合に参加した人々によって、のちに「Open Source Initiative」（OSI）という団体が結成され、「オープンソースの定義」（The Open Source Definition）という文書が発表された。 この文書は Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria: 21 （オープンソースは、ソースコードにアクセスするというだけの意味で はありません。オープンソースソフトウェアの配布条件は、以下に示 すような基準を満たしている必要があります：） という書き出しで始まる。そして、これに続いて、オープンソースソフトウェ アの配布条件（＝ライセンス）が満たすべき 10 個の条件が列挙されている。 その主な項目は以下の通り。 ① 再配布が自由に行える ② ソースコードが提供される ③ 派生ソフトウェアの作成および配布を自由に行える ④ 特定の個人やグループを差別しない ⑤ 利用する分野で差別しない ⑥ ソフトウェアを入手したすべての人に同じ権利を認める OSI では、この「オープンソースの定義」に準拠しているソフトウェアライ センスとして、表１に示すような 45 のライセンスをオープンソースライセン スとして認定している。 従って「オープンソースソフトウェア」とは、狭義には、表１のオープンソ ースライセンスが適用されているソフトウェア、ということになる。 表１ OSI 認定オープンソースライセンス ライセンス名 Academic Free License Apache Software License Apple Public Source License Artistic license Attribution Assurance Licenses BSD license Common Public License Eiffel Forum License Eiffel Forum License V2.0 Entessa Public License GNU General Public License (GPL) GNU Library or "Lesser" General Public License (LGPL) Lucent Public License (Plan9) IBM Public License Intel Open Source License Historical Permission Notice and Disclaimer Jabber Open Source License MIT license MITRE Collaborative Virtual Workspace License (CVW License) Motosoto License Mozilla Public License 1.0 (MPL) Mozilla Public License 1.1 (MPL) 22 Naumen Public License Nethack General Public License Nokia Open Source License OCLC Research Public License 2.0 Open Group Test Suite License Open Software License Python license (CNRI Python License) Python Software Foundation License Qt Public License (QPL) RealNetworks Public Source License V1.0 Reciprocal Public License Ricoh Source Code Public License Sleepycat License Sun Industry Standards Source License (SISSL) Sun Public License Sybase Open Watcom Public License 1.0 University of Illinois/NCSA Open Source License Vovida Software License v. 1.0 W3C License wxWindows Library License X.Net License Zope Public License zlib/libpng license オープンソースイニシアティブ 「OSI」（Open Source Initiative）とも略される。「伽藍とバザール」を執筆 した Eric S. Raymond 氏らが中心となって設立した、オープンソースをプロモ ーションするための団体。 前述の「オープンソースの定義」を策定、管理しているほか、オープンソー スの定義に合致するソフトウェアライセンスを「OSI 認定ライセンス」（OSI Approved License）として公表している。また、OSI 認定ライセンスを適用し ているソフトウェアに対して、それがオープンソースソフトウェアであること を明示するための「OSI Certified」マークの提供も行っている。 伽藍とバザール Linux の開発は、Linus 氏を中心に、数百人とも言われる世界中の開発者が 協力する形で行われている。しかし、その「開発者コミュニティ」は、明確に 組織化されているわけではなく、個人個人が思い思いに開発に参加しているに すぎない。 それまで大規模なソフトウェアは、きちんと管理され組織化された開発チー ムによってのみ開発され得るものだと信じられてきた。しかし Linux は、まっ 23 たく組織化されていない個人らの集まりであったにもかかわらず、5、6 年とい う短期間で、十分実用になる品質のオペレーティングシステムとして開発され てしまった。 この、開発方法論としての「Linux 成功の秘密」を解き明かそうと試みたの が、Eric S. Raymond による論文「伽藍とバザール」（The Cathedral and the Bazaar）である。 「伽藍とバザール」では、Linux のようなやり方、すなわち、 躊躇せず頻繁にリリースする 開発プロセスそのものをオープンにする 多くの人が開発に参加できるようにする といったようなやり方でも、品質の高いソフトウェアを、短期間で開発するこ とができるということを検証している。 「伽藍とバザール」は、その後の「オープンソース」という言葉を生み出す ことになる動きに、大きな影響を与えることとなった。 Linux 「Linux」の開発は、1991 年春頃、当時ヘルシンキ大学の学生だった Linus Torvalds 氏によって始められた。開発のごく初期の段階からソースコードがイ ンターネット上に公開され、開発のための議論もインターネットのニュースシ ステムを利用するオープンな形で行われたため、OS 開発に興味を持つ世界中 のプログラマが開発に参加することになった。 結局、企業活動でもなく、専門家でもない個人の集まりによって、10 年も経 たないうちに、世界的に広く利用され得る品質のオペレーティングシステムが 開発されてしまったことになる。このことによって Linux は、単なるソフトウ ェアとしてではなく、「オープンソース」という開発手法を代表するソフトウェ アとして、大きな注目を集めることになる。 なお、Linux として開発されているのは、オペレーティングシステムの核と なる部分（「カーネル」と呼ばれる）だけで、実際にオペレーティングシステム として利用するためには、各種ライブラリやユーザーコマンドなどを組み合わ せる必要がある。 Linux がどうにか日常的な利用に耐えられるようになりかけた 1993 年ごろ から、Linux カーネルに必要なソフトウェアを組み合わせて、すぐに使えるパ ッケージとして提供する動きが始まった。こうした「オペレーティングシステ ムとして、そのまま使えるようにまとめたもの」は、前述の Linux カーネルと 区別して、「Linux ディストリビューション」と呼ばれるようになった。 代表的な Linux ディストリビューションとしては、「Red Hat Linux」、 「UnitedLinux」、「Debian GNU/Linux」などがある。 Linux のユーザーが増えるにつれ、手軽に使える配布セットとしての Linux ディストリビューションの需要が高まり、これをパッケージ製品として販売す る企業がいくつも現れた。米 Red Hat 社、米 Caldera Systems（現 SCO Group） などは、その草分けとなった。 24 GNU Richard M. Stallman 氏が始めた、「『自由ソフトウェア』だけで、UNIX 互 換のオペレーティングシステム環境を作る」ことを目指したプロジェクトの名 前。あるいは、そのプロジェクトによって開発されるソフトウェア群総体の名 称でもある。前者は「GNU プロジェクト」、後者は「GNU ソフトウェア」と 呼ばれることもある。 GNU プロジェクトの成果としては、C/C++コンパイラとして使われる 「GCC」、Linux で一般的に利用されているシステムライブラリ「glibc」、多く の Linux ディストリビューションで採用されている各種コマンド群などがあ る。 なお「GNU」は、「New」や「gnu」（ウシ科ヌー属の動物）との混同を避け るため、最初の「G」の文字も含めて「グニュー」または「グヌー」と発音す る、とされている。 GPL 正式名は「GNU General Public License」。単に「GPL」と略されることも 多い。現在の最新は、1991 年に改訂された「Ver.2」。特にバージョンを意識し ていう場合は「GPL2」などと呼ばれる。 GNU GPL は、GNU プロジェクトのために作成されたソフトウェアライセ ンスである。もともとは、Stallman 氏が提唱する「copyleft 思想」を実践する ためのライセンスとして作られた。しかしその後、ライセンスとしてきちんと まとまっていることや、多くの人にその内容が知られているという利点に注目 して、必ずしも copyleft 思想に共鳴していなくても、オープンソースソフトウ ェアのライセンスとして採用されることが多くなってきている。 フリーソフトウェア copyleft 思想に合致したソフトウェアのことを、Stallman 氏は「Free Software」と命名した。日本のメディアでは「フリーソフト」と略されること も多い。 ただ Stallman 氏自身は、「フリーウェア」（無料で入手、利用できるソフト ウェア）などと混同されることを避け、その当初の意図を明確にしたいという 観点から、日本語では「自由ソフトウェア」と呼ぶべきだと主張している。 Free Software Foundation Stallman 氏が GNU プロジェクトを推進するために設立した非営利の団体。 「FSF」と略されることもある。 GNU プロジェクトの成果物である GNU ソフトウェアを開発、管理している ほか、 自由ソフトウェアの啓蒙、普及、GNU プロジェクトのための寄付の受 け付けなどを行っている。 25 シェアードソース 米 Microsoft 社が行っている、ソースコードライセンスプログラム「シェア ードソースイニシアティブ」（Shared Source Initiative）の通称。 同社によれば、その目的は、 ソースコードへのを提供することにより、開発者やパートナーのビジネス を支援する ユーザーが自分のコンピューティング環境の信頼性、安全性を確保できる ようにする Microsoft 社が、開発者の技術的フィードバックを受けやすくする 学術研究の発展に寄与する などとしている。 現在、このシェアードソースイニシアティブに基づいて、ソースコードへの アクセスが提供されている製品は、 Windows 2000 Windows XP Windows Server 2003 Windows CE 3.0 Windows CE .NET .NET C#/CLI Implementation .Net Passport Manager となっている。 また、シェアードソースイニシアティブに基づいた具体的なライセンスプロ グラムとしては、 エンタープライズソースライセンシングプログラム システムインテグレーターソースライセンシングプログラム OEM ソースライセンシングプログラム マイクロソフトリサーチソースライセンシングプログラム ガバメントソースライセンシングプログラム Windows CE シェアードソースライセンシングプログラム などがあり、具体的にどのような形でソースコードにアクセスできるのかは、 個々のライセンスプログラムによって様々である。 コミュニティ オープンソースソフトウェアに直接または間接に関わっている人々の総称。 オープンソースソフトウェアの開発作業に直接加わっている人だけでなく、そ うした活動にシンパシーを抱いているユーザーなども対象にして使われること も多い。 オープンソースソフトウェアの開発には、基本的には誰でも自由に参加する ことができ、それに関わる人々の全体像を明確に把握することが難しい場合が 多いために、 「コミュニティ」という総称的な呼び方が使われるようになった。 26 再配布 ソフトウェアのコピーを受け取った人が、別の第三者にさらにコピーして渡 すこと。日本の著作権法の用語では「頒布」という表現が使われる。 プログラムを「再配布」するためには、著作権者から、 「複製」および「公衆 送信」などに関する許諾を受ける必要がある。オープンソースライセンスでは、 「再配布」が自由に行えることを保証する（そのための権利を許諾する）ものと なっている。 ソースコード CPU が理解できるコード（「マシン語」、「機械語」などと呼ばれる）とは一 対一には対応しない「特別な言語」 （C 言語、C++言語など）によって記述され たテキスト。これを「特別な言語」の処理系によってマシン語に翻訳（コンパ イル）することで、実行可能なプログラムを作ることができる。こうして作成 された実行可能プログラムは、ソースコードに対して「バイナリプログラム」 などと呼ばれる。 一般に、ソースコードからバイナリプログラムを作成することはできても、 その逆、つまりバイナリプログラムから、その元になったソースコードを再現 することはできない。 独占的に提供されるソフトウェアでは、人間が読んで理解できる形式で記述 されているソースコードによって技術的ノウハウが流出することをおそれて、 バイナリプログラムのみを提供するのが一般的である。 逆にオープンソースソフトウェアでは、共同開発という目的のために、必ず ソースコードが提供されるようになっている。 27 ■歴史 「Linux」誕生以前（〜1991 年） 時期 1969 年ごろ 1974 年 1 月 1977 年 1978 年中ごろ 1979 年 1981 年 1983 年ごろ 1984 年 1985 年 1986 年 1989 年 1991 年 出来事 AT&T ベル研究所で UNIX の開発が始まる。その後 UNIX のソースコードは、研究用として、大学や他 の研究機関などに配布された。 カリ フォルニア 大学バーク レー校（ UCB）が、 PDP-11/45 用の UNIX Ver.4 を入手。BSD UNIX の 歴史が始まる。 1BSD リリース 2BSD リリース 3BSD、4.0BSD リリース 4.1 BSD を公開 Richard M. Stallman が、「ソフトウェアの自由」を スローガンに、「GNU プロジェクト」をスタートさ せる。 4.2 BSD を公開。TCP/IP がサポートされるなど、 現在の「UNIX」の原型となる機能が多数実装され た。 Stallman が、GNU プロジェクトの活動をサポート す る た め の 非 営 利 団 体 「 Free Software Foundation」を設立。 4.3 BSD リリース AT&T ライセンスフリーな部分を「4.3 BSD Net/1 Release」として公開。 AT&T ライセンスフリーな部分を「4.3 BSD Net/2 Release」として公開。 William Jolitz が、Dr. Dobbes Journal 誌の連載で、 Net/2 リリースをベースに、PC 互換機に移植した 「386BSD」を発表。 28 「オープンソース」以前（1991 年〜1997 年） 時期 1991 年春 出来事 フィンランド、ヘルシンキ大学の学生だった Linus B. Torvalds が、PC 互換機で動作するオペレーテ ィングシステムの開発を始める。 1991 年 8 月 25 日 Linus が、インターネットのニュースグループ 「comp.os.minix」にて「PC 互換機で動作する OS を開発している」ことを明らかにする。 1991 年 9 月 17 日 Linux カーネル 0.01 がインターネットに公開され る。「Linux」という名前はこのときにつけられた。 1992 年 1 月 Linux カーネル 0.12 を公開。ライセンスとして GPL を採用した最初のリリース。 1992 年 8 月 最初の Linux ディストリビューションの 1 つ 「SLS」がリリース。 1993 年 5 月 1 日 豊橋技術科学大学の真鍋氏を中心に開発された、 Linux の日本語構築環境パッケージ集「JE」が公 開される。 1993 年 11 月 25 日 株式会社五橋研究所が、国内初の Linux ディスト リビューション製品「Linux＋JE」（監修：生越昌 己）を発売。 1994 年 3 月 14 日 Linux カーネル 1.0 リリース 1994 年 10 月 Marc Erwing が自作の Linux ディストリビューシ ョン「Red Hat Linux」（Halloween Release）を リリース。 1995 年 3 月 6 日 Linux カーネル 1.2 リリース 1996 年 6 月 9 日 Linux カーネル 2.0 リリース。初めて PC 互換機以 外のプラットフォームがサポートされる。 1996 年 11 月 25 日 日本初の Linux 専門誌「Linux Japan」創刊 29 「オープンソース」以降（1997 年〜） 時期 1997 年 5 月 21 日 1998 年 1 月 16 日 1998 年２月３日 1998 年 3 月 6 日 1998 年 3 月 31 日 1998 年 9 月 29 日 1999 年 1 月 25 日 1999 年 4 月 1 日 1999 年 8 月 12 日 1999 年 12 月 2000 年 8 月 30 日 2001 年 1 月 4 日 2001 年 6 月 2002 年 5 月 31 日 2002 年 8 月 20 日 2003 年 7 月 1 日 出来事 Eric S. Raymond が、Linux Kongress にて「伽藍 とバザール」を発表。 米 Netscape Communications 社が、Web ブラウ ザ「Netscape Navigator」のソースコードを公開 すると発表。 Netscape 社の発表を受け、Eric Raymond らの呼 びかけに呼応したキーパーソンが初会合。「オー プンソース」という言葉が生み出された。 第 1 回 LinuxWorld Expo が、San Jose で開催さ れる。出展社数は約 70 社、来場者は約 1 万 1000 人ほど。 Netscape Navigator のソースコードが公開され る。 Linux ディストリビューションメーカー、米 Red Hat 社が、Intel 社、Netscape Communications 社などからの出資を受ける。第一次 Linux フィー バーの始まり。 Linux カーネル 2.2 リリース 日本 Linux 協会が発足。 米 Red Hat 社が Nasdaq に上場。 米 VA Linux 社が Nasdaq に上場。初日終値の倍率 が 733％という新記録を樹立。 業界主要企業が出資して、非営利のオープンソー ス ソ フ ト ウ ェ ア 開 発 支 援 組 織 「 Open Source Development Lab」（OSDL）を設立。 Linux カーネル 2.4 リリース 米 VA Linux 社、Linux 搭載サーバビジネスから撤 退 独 SuSE 社、米 Caldera International 社、ブラジ ル Conectiva 社、米 Turbolinux 社の 4 社が、共同 で共通の Linux ディストリビューションベース 「UnitedLinux」を開発すると発表。 株式会社 SRA が、ターボリナックス株式会社を救 済買収。 Linus が Open Source Development Lab フェロー となり、Linux カーネル開発に専念。 30 ■References 「オープンソースの定義」（Ver.1.9） http://opensource.org/docs/def_print.php 「オープンソースの定義」日本語訳（Ver.1.7） http://www.geocities.co.jp/SiliconValley-PaloAlto/9803/osd-ja/osd-ja.html 八田真行氏による翻訳 OSI 認定ライセンス http://www.opensource.org/licenses/ GNU General Public License Ver.2 http://www.gnu.org/copyleft/gpl.html GNU General Public License Ver.2 日本語訳 ftp://ftp.sra.co.jp/pub/gnu/local-fix/GPL2-j/gpl.text.gz 引地氏による GPL Ver.2 の翻訳。 GNU General Public License Ver.2 日本語訳 http://www.opensource.jp/gpl/gpl.ja.html 八田氏による GPL Ver.2 の翻訳。「引地版」にあった、法律用語の間違いなど を修正している。 31 禁無断複製、禁無断転載 オープンソース研究会活動報告書 (c) 2003 社団法人日本パーソナルコンピュータソフトウェア協会 発行 平成 15 年 7 月 発行者： 社団法人日本パーソナルコンピュータソフトウェア協会 〒 100‑0014 東 京 都 千 代 田 区 永 田 町 2‑4‑2 秀 和 溜 池 ビ ル 4 階 TEL:03‑5157‑0780 FAX： 03‑5157‑0781 http://www.jpsa.or.jp/
© Copyright 2026 Paperzz
