オープンソースの理想と現実

この記事は『RIETI（経済産業研究所）』サイト内に掲載された「オープンソースの理想と現実」を転載したものです。

はじめに

　オープンソースに関する議論が活発に行われているが、オープンソースの当事者であるプログラマからの発言は少なかったように思われる。そこで、ここではオープンソースの開発・公開にかかわる立場から見たオープンソース、特にその問題点を議論していきたい。

　なお、オープンソースはそもそも開発したプログラムのソースコードを公開することを意味していたが、最近はインターネット上で公開されたソースプログラムを通じて世界規模で共同開発することを指すことが多くなっており、ここではそれにならい開発手法としてオープンソースを議論する。

混沌から生まれたオープンソース

　オープンソースの生まれた背景にはUNIXワークステーションの混乱がある。PCはPC/AT互換機(いわゆるDOS/V機)やMacintoshなど少数のプラットフォームに集約されたが、UNIXが搭載されるワークステーションはハードウェアが多様化し、そのOSであるUNIX自体もSystem/V やBSDなどへの分裂やメーカによる独自拡張が頻繁に行われた。この結果、コンピュータが直接実行できるネイティブ形式（またはバイナリ形式）によるソフトウェアの配布先を制限されてしまい、ソフトウェアの開発が難しかった。

　その一方でUNIXワークステーションはソフトウェア開発に利用され、C言語などのプログラミング言語処理系が利用できることが多かった。このため、非営利的なソフトウェアの場合、ネイティブ形式による配布をあきらめて、C言語など書かれたソースプログラムのまま配布し、それを受け取ったワークステーションの利用者または管理者がそれ自身のワークステーションで動作するようにソースプログラムを改変し、それをC言語処理系などでネイティブ形式にコンパイルして使っていた。そして、こうした利用者や管理者によるソースプログラム変更を集約・発展したのが、現在のオープンソースによる開発手法である。このため、昔も今もオープンソースはUNIX 文化の影響が強く、UNIXと比較してPCやMacintoshでは必ずしも成功していない。なお、当時は磁気テープを回覧することでプログラムを配布することが多く、オープンソースをインターネットが生んだ開発手法としてとらえるのは必ずしも正しくない。

オープンソースと利己主義

　一部のオープンソースに対する評論を見ているとオープンソースはプログラマの奉仕活動としてとらえているが、むしろ利己的な活動といった方がいいだろう。

1. プログラマの事情

　それではプログラマがオープンソースのプロジェクトを始めるまたは参加する動機とは何であろうか。もちろん有名になりたい、自己顕示力が強いことも挙げられるが、もっとも典型的な動機は簡単にいうと、自分が使いたいプログラムがないので開発したい、ただ一人で全部を作るのはたいへんなので、同じような状況の他のプログラムと一緒に開発して自分の負担を小さくしたいということである。

　例えば、オープンソースによる成功事例を3つ上げるとしたら、Linux、Apache、Perl、Mozillaなどが列挙されるだろうが、これらに共通しているのはプログラマ自身が使うソフトウェアという点である。また、これ以外の事例もエディタやコンパイラなどのプログラマ自身が普段使うソフトウェアに偏っている。つまり、自分が使うときに便利になることを目的にソフトウェア開発に参加しているのであって、必ずしも第三者の利益を考えた奉仕活動ではなく、逆にいうとプログラマが使わないソフトウェアではオープンソースによる開発は成立し難い。

2. 営利企業の事情

　Eclipseというプロジェクトをご存じだろうか。Java言語の開発環境としてここ1,2年で急激にシェアを伸ばしている。このプロジェクトはIBMが自社のWebsphereというアプリケーションサーバ向けの開発用ソフトウェアの開発を目的として始まったものであるが、IBMは自社開発したソースプログラムを公開し、オープンソースによる開発に切り替えた。IBMはその理由を明らかにしていないが、その一つには自社開発よりも多くのプログラマの手助けを得た方が効率がよいと判断したからであろう。もう一つは企業としての宣伝効果を狙ったと思われる。

　現在、オープンソースが善玉で、クローズソースは悪玉として扱われることが多く、オープンソースに積極的な企業は肯定的に評価される。特にITバブルが崩壊したとはいえIT分野において優秀な学生や中途採用者を確保することは難しく、オープンソースへのコミントメントは求人活動の宣伝材料になる。また、一部の企業は有名なオープンソースのプログラマを採用し、就業時間内にオープンソースのソフトウェア開発に従事させているが、企業の知名度向上や求人対策という打算が働いていることが多い。

3. 国家の事情

　公共調達するソフトウェアにオープンソースを義務づける動きがある。ただし、この場合のオープンソースとは守秘義務を結んだ上でソースプログラムの閲覧を求めるものであり、いわゆるオープンソースとは区別して議論すべきである。なお、安全保障などの観点からはソフトウェアの開発した企業に頼らずにプログラムの保守・改良が必要であり、そのソースコードが入手できることは重要性となるが、その場合は単にソースコードを提供を受けるだけでは不十分である。ソフトウェアの開発では特定のプログラミング言語処理系やソフトウェアツールを前提にしていることがあり、これらが揃っていないとソースコードから実行可能なソフトウェアに変換(コンパイル) できるとは限らない。このためソースコードから実行可能なソフトウェアへの再構成も調達用件に加える必要がある。

　ところで、ソースコードが公開されている場合とそうではない場合を比較すると、当然ながら前者の方がセキュリティ上の不備も見つけやすい。現在は問題点を発見したものが適切な方法で不備を通報することが前提となっているが、それが守られる保証はどこにもない。従って、オープンソースの特性を理解した上で利用すべきであり、セキュリティを含む保守コストを考えると必ずしも安いとは限らない。

3. 研究者の事情

　著者はソフトウェアの研究を本業としている。このため研究成果を社会に還元することは職務となっているが、ソースコードは利用する側の都合にあわせやすく、技術移転方法として優れている。このため、ソフトウェアに対する研究助成ではソースコードの公開を義務づけるのは有用である。また、研究者にとっ てもその研究対象にブラックボックス、つまりソースプログラムが観覧できない部分が含まれると研究の障害となることが多く、オープンソース化には好意的であるものが多い。

オープンソースの陰

　オープンソースは万能な開発手法でなく、また問題も多い。ここではいくつかの問題について列挙する。

1. 技術的停滞

　オープンソースによる開発手法では多数のプログラマがインターネットを通じて世界規模で参加しているが、そのとき彼らの共通基盤となるのは公開されたソースプログラムだけである。従って、そのプログラムの軽微修正や拡張を行う限りはプログラマ同士が互いにソースプログラムをチェック・改良しながら作業が行われるが、プログラム構成全体を変更するような大きな機能変更や拡張では多くのプログラムも新規に開発することから共通基盤を失う。また、学術研究の成果に基づくソフトウェアを除くと、オープンソースのプロジェクトが大きくなるほど大幅な変更に抵抗が大きくなる、つまり、一部のプログラマが技術的に価値のあるソースプログラムを用意しても、その変更内容が広範囲に及ぶ場合は、既存ソースプログラムの修正に携わっているプログラマから拒絶されることが多い。

　一般にソフトウェアのライフサイクルでは新規開発後に運用と保守・機能拡張を何度か行った後に、再び新規開発をするという過程を繰り返すが、オープンソース手法はそのうちの保守や機能拡張において有効な手法なのであって、新規開発では足かせとなる危険性も高い。

2. 市場の破壊

　オープンソースに興味ある者であればGNUというプロジェクトを御存知だろう。GNUはGNU's Not Unix!という標語のもとにオープンソース手法によりUNIX互換OSを開発しようとした。また、LinuxもUNIXに強く影響を受けたOSといえる。つまり、どちらのプロジェクトも新規OS技術の開発ではなく、ソースコード付きのUNIX相当OSを作ることが目標であり、実際Linuxを見ると技術的に商用UNIX製品を超える点は少ない。この関係はオープンソースのApacheと商品Web サーバを比較しても同様である。

　これにはいくつかの理由があるが、その一つには既存ソフトウェアがあるとプログラマ同士が共通の目標を持ちやすく、開発がしやすいからである。この場合は開発されるソフトウェアも既存ソフトウェアに近いものになりやすく、結果として商品ソフトウェアの市場を奪っていることも多い。例えばLinuxはOSであることからWindows vs. Linuxという構図でとらえられることが多いが、商品UNIXの市場に与える影響の方が大きいと思われる。

3. クローズコミュニティ

　オープンソースの開発プロジェクトではインターネット上の開かれたコミュニティによるソフトウェア開発ということになっているが、プロジェクト自体のプログラムの改変権利はコアメンバと呼ぶ少数の特定のプログラマにしか与えられていないことが多い。これはプロジェクトに参加するプログラマの能力が必ずしも高いとはいえないため、全員の改変を許すと一貫性欠如や改悪の危険性があるためである。ただし、コアメンバの見識が低いと開発は停滞・頓挫しやすい。またコアメンバ内及びプロジェクト参加者全体の合議方法を特に決めていないことが多く、必ずしも民主的なコミュニティとはいえない。

4. 知的所有権

　オープンソースとして公開されるソフトウェアは、プロジェクトのコアメンバが中心になって改良・チェックが行われるにしても、プログラマの善意に任さている。従って、あるプログラマが他社の知的所有権を侵害するようなソフトウェアを提供した場合、他のプロジェクトメンバーがそのソフトウェアの出所を調べる手段はない。多くのオープンソースのプロジェクトでは、現在または過去に業務として類似したソフトウェアの開発に携わっているプログラマが数多く含まれている。プログラマはオープンソース向けの開発であっても、過去に似たような処理のプログラムの開発に関わっていると、それと類似したプログラムになる可能性が高く、悪意がなくても結果として知的所有権を侵害する可能性がある。

　また、オープンソースの開発では関連技術の調査が十分に行われるとは限らず、結果として特許化されている処理をオープンソースとして開発・公開する可能性や、プログラムが故意に保有している特許技術を埋め込む可能性もあり、将来的な特許紛争の原因となることがある。

おわりに

　オープンソースというとLinuxやApacheなどに話題が関心が集中しているが、その背後に数え切れないほどの多くのプロジェクトがあり、それらには共同開発を意図しながらも開発コミュニティが成立しなかったものが、当初から特定の用途・ユーザを指向して一定の成果を上げているものも多く、それらの存在も忘れないで頂きたい。なお、本稿ではオープンソースに対してネガティブな議論が多くなったが、著者は研究成果の多くをこれまでオープンソースとして配布・公開しており、オープンソースにコミットする立場におり、オープンソースを否定するつもりは一切ないことを申し添えておく。