「オープンソースの定義」の意義

前回筆者が書いた記事に対し、予想外に大きな反響を頂いたが、記事中で取り上げたオモイカネの大熊氏から反論が寄せられた。本稿では氏の反論を踏まえつつ、単なる用語の問題を越えて、そもそもオープンソースとはどのようなものなのかをバザールモデルによるソフトウェア開発プロセスにおけるオープンソースの位置付けから追ってみたい。

はじめに

筆者がopentechpress.jpに書いた記事に関して、オモイカネの大熊但由氏から早速反論が寄せられ、経済産業研究所(RIETI)のサイトに掲載された。まあ、実のところタイトルからも分かるように、あの記事の批判の主眼は大熊氏ではなく経済産業省のほうだったのだが…

まず、議論の土俵に乗って頂けたということに関しては大熊氏に率直に感謝したいと思う。批判してもなしのつぶて、あるいは居丈高に記事の削除を要求するだけという人も世には存在するので、非常に良心的な姿勢と言えよう。

さて、大熊氏の反論を拝見すると、いくつかの用語や概念の定義において、筆者と大熊氏の間に重大な相違があることが分かった。特に、そもそも「オープンソース」という用語が示す意味内容について、筆者と氏が一致していないというのは大きな衝撃であった。筆者にとって、「オープンソースである」とはOpen Source Initiative(OSI)オープンソースの定義を満たしているということと等価だったのだが、氏にとってはそうではないらしい。これは、単に立場の違いということでは片づけられない問題をはらんでいると思う。また、例えばスラッシュドットジャパンでの議論や各地のウェブ日記などでの意見交換をしばらく眺めていたのだが、大熊氏と同種の論調は意外に根強いものがあるように感じられた。結論から言ってしまえば、この種の「誤解」は、「オープンソースの定義」の成立過程への理解が不十分なところから来ているのではないかと
思うのだが、いずれにせよ大熊氏個人に問題を帰着し難詰することには、あまり意味がないのではないかと思えてきた。

そこで、以下では大熊氏の文章を適宜引用しながら反駁を加え、なぜ「オープンソースの定義」から逸脱する意味で「オープンソース」という語を使うとまずいのか、筆者の考えを明らかにしていくことにする。文脈と反するような恣意的な引用は極力避けたつもりだが、万が一そのようなものがあれば伏してお詫びし訂正させて頂くので、どしどし指摘していただきたい。また、大熊氏の文章を引用しているからといって、大熊氏個人を攻撃する意図は無い。批判するのはあくまでも内容である。

ソースがオープンなら「オープンソース」か

さて、大熊氏は「オープンソースの定義」で規定された基準を満たさないライセンスが適用されたソフトウェアをも「オープンソース」と見なし、騒動の発端となったオープンソースのリストに加えている。

(3)「オープンソースソフトウェア」 というのはここでは、ソースを入手することができ、改変が可能なソフトウェアを指します。(中略)Windowsのフリーソフトでは再配布条件が明示されていないことも多々あるため、ソースを公開している場合は広い意味でオープンソースであるとみなしました。

とのことなので、大熊氏の基準では、ソースが「転がって」いて(ライセンスが指定されていなくても良いらしいのでこう書く)、手元である程度いじれればそれでオープンソースと呼んで良いようだ。ようするに、「ソース」が「オープン」になっていれば良いという程度ではないかと思う。さらに、

あのリストは正確には「資料:日本人によるオープンソースのリスト」と題しており、一応単独で読むこともできるが、基本的には我々がオープンソースを業務的に始められる方々に向けて説明をおこなう時のプレゼン補助資料である。

とのことなので、氏はオープンソースになじみの薄いクライアントに対し、このようなものが「オープンソース」であると説明しているとおぼしい。また、実際RIETIはこのリストを「おすすめ!」していたので、これこそが「オープンソース」とお墨付きを与えていたに等しいのである(もちろんこれは大熊氏の責任ではないが)。結果的に、彼らの行動が現実的にどれだけの影響力を持っていたかというのは別として、日本においては、「オープンソース」とは単にソースが公開されていて、ある程度のカスタマイズが可能なソフトウェア、との誤解を生みやすい状況が生じていた。また、先ほども書いたように、「ソースがオープン(==公開)になっている、それをオープンソースと呼んで何が悪い」と言うような論調はそれなりの支持を集めているようである。さらには、「狭義の」オープンソースと「広義の」オープンソースを適当に設定してみたり、あるいは多少の語義の混乱は(例えば「ホームページ」や「ハッカー」のように)甘んじて容認せよという暴論もあるようだ。

さて、筆者は、このような「オープンソース」という語が指し示す概念を曖昧にし、オープンソースとそうでないものの境界をぼやけさせるような動きを非常に危惧する。極端に言えば、現在のオープンソース振興の機運を有名無実化させかねないとさえ思うのだ。それはなぜかというと、「オープンソース」を名乗りつつ「オープンソースの定義」から逸脱したソフトウェアは、それ自身オープンソースによるバザール型開発モデルの長所を最大限活かすことができず、加えて現在オープンソース運動に関わる様々な主体に悪影響を及ぼす可能性すらあるからである。ゆえに、「オープンソース」という用語を「オープンソースの定義」を満たしているという意味以外で使うべきではないと考える。以下ではそれを論証したい。

バザール型ソフトウェア開発のロジック

そもそも、人はなぜ自分の書いたソフトウェアをオープンソースにするのだろう。フリーソフトウェア運動の創始者Richard M. Stallmanはかつて筆者に、「ソフトウェアをプロプライエタリにするのは倫理的ではないからだ」と語った。これは一つの見識であり、たとえStallmanには賛同しなくても、似たような信念に導かれて自作ソフトウェアをオープンソースとして公開している人も少なからず存在する。しかし、万人がこのようなハッカー倫理を共有しているとは考えにくい。共有の美徳だの利他の精神だのと言えば耳障りは良いが、それだけで現在のオープンソース運動の隆盛が築かれたと考えるのはナイーヴに過ぎる。すなわち、自作のソフトウェアをオープンソースにするのは、作者自身にとってそこに何らかの実質的なメリットがあるからだと考えるのが自然だ。

ソフトウェアは「情報財」と呼ばれるものの一種である。いくつかの特異な性質があるが、差し当たって重要なのは、「(少なくとも現時点では)コピーにほとんどコストがかからない」「コピーしてもオリジナルが無くなるわけではない」という二点だ。

ソフトウェアにはこのような性質があるため、特にプロプライエタリなソフトウェアの違法コピーの取り締まりには膨大な監視コストがかかる。ライセンス料を高くすればするほど違法コピーを行うインセンティヴ(誘因)は増加する。また、開発者からすれば、違法コピーが横行すると開発に要する初期費用が回収できなくなってしまうので、そもそもソフトウェアを市場に送り出そうとするインセンティヴ自体が失われてしまうだろう。また、現状のようなMicrosoft一人勝ちという状況では、OSも含めMicrosoft社製品と競合するようなものを市場に出してシェアが獲得できるという目算は立ちにくい。

それならば、ソフトウェアの性質を逆手に取って、むしろ積極的にソースコードを公開し、誰でも自由に利用できるようにして(オープンソース化)、(他の企業を含む)ユーザからのフィード
バックに期待してはどうか。収入は直接ライセンス料から得るのではなく、ソフトウェアの「周辺」から取れないか。これがEric S. Raymondが当時退潮著しかったNetscape社に提案したことであり、バザール型ソフトウェア開発の基本となったロジックである。もちろん、すべてのユーザがソースに手を入れ、パッチを送ってくれるわけではない。だからこそ、ユーザ/開発者の母数を極力増やし、フィードバックを送ってくれる人が存在する可能性を高める必要がある。言い換えれば、普及させること、流通させることへの障害をできるだけ取り除くことが極めて重要になってくるのである。

普及や流通の重要性に関しては、以下のような見方もできるだろう。頒布への障害が無ければ無いほど、取引コストが下がるのでDebian Projectのようなソフトウェアの頒布者(ディストリビュータ)にはメリットがある。しかし、ソフトウェア作者にはメリットがあるのだろうか。実のところ、ソフトウェアが盛んに頒布され普及しても、直接的なメリットは無い(変なバグ報告だの苦
情だのが増えるだけでかえって効用は下がるかもしれない)。しかし、間接的なメリットは存在する。これを「ネットワークの外部性」と呼ぶ。簡単に言えば、「他人の行動が、間接的に自分の利害に影響する」ということだ。いくら大勢の他人が自作のソフトウェアを使っても、シェアウェアなどと違って直接的な金銭のやりとりはないので、作者に直接得はない。しかし、自作が人口に膾炙することで、フィードバックが返ってきたり、名声が上がることが期待される。さらに、サポートや教育などをビジネスとする契機も生じてくるわけだ。端的に言えば、「仕事が生まれる」のである。

しかし、ここで注意しなければならないのは、いくら流通を促進したいからと言って、(日本著作権法の下で実際に可能かはともかく)一切の権利を放棄しパブリックドメインにしてしまうと弊害が生じるということだ。この場合、作者の権利は一切保護されないので、白昼堂々剽窃が横行してしまうことにもなりかねない。Netscapeの例で言えば、例えばMicrosoft社がMozillaを「自社製品である」と言っても法的には基本的に何の問題もないことになってしまうのである。このような事態が頻発すれば、作者が自作をオープンソースにしようとするインセンティヴは大きく損なわれるので、ソフトウェアが世に出る機会はいよいよ減ってしまうだろう。このように、流通の促進と、作者の権利の保護、ひいてはオープンソースソフトウェアの供給・維持を行うインセンティヴの確保にはある種のトレードオフが存在する。All or Nothingではない。さじ加減が重要なのだ。

また、単にソースコードが流通するだけでバザールが「成立」するとは限らない。まず、単に改変が可能なだけではなく(ソースが公開されていればどのみち手元でいじるのは勝手だ)、改変した成果を再頒布することが明確に許可されていなければならない。また、そもそも他人がソースに手を入れやすい環境が整備されていなければならない(Mozillaはここでしばらくつまづいた)。この点、開発過程の円滑化に大きく寄与したという意味で、インターネットの普及やCVS、Subversionといった分散開発を可能とするツールの登場がバザール型開発モデルにとって極めて重要な意味を持っていたことは言うまでもないが、しかし、「手の入れやすさ」「取りかかりやすさ」はツールの存在や、ソースの規模や可読性といった技術的要因だけで規定されるわけではないのである。実際に開発や頒布に携わると痛感することが多いのだが、そのソフトウェアに適用されたライセンスの内容がかなり効いてくるのである。改変するには書面で原作者(下手をすると行方不明だったりする)から許可を取り、利用目的が世界平和に反していないか確認し、商用目的でないと強調し、さらにクリスマスカードを郵送し…などとやっていたらそれこそ日が暮れてしまう。
このような状況では例え改変点の再頒布が許可されていたとしても、手元でプライベートに変更する人こそあれ、自分の改変点を送り返してくれる人はいないか、ごく少数にとどまるだろう(ちなみに今挙げたのはすべて実在の、「ソースは公開されているがオープンソースではない」ソフトウェアのライセンスで指定されている条件である)。多くの場合、「利用は平和目的に限る」など現実的に検証が難しく無意味で煩瑣なライセンス条件は、まじめにライセンスに従おうとする利用者のみを苦しめるということは留意して欲しい。

さて、ここまでの話をまとめるとこうだ。ソフトウェアの開発手法としてオープンソースによるバザール型開発モデルが提案され、現在世界的に普及している。開発者の利他主義や倫理性に支えられなくとも、ネットワークの外部性等を経由した作者自身へのメリットが存在し、他人に強制されなくともソフトウェアのソースを公開するインセンティヴは確保される。もちろんそういう信念に突き動かされている人がいても差し支えない(むしろ好ましい)のだが、仮に誰もが自分の利益だけを追求していたとしても、より優れたソフトウェアがより多く世に出るという社会的に好ましい状態が実現する(可能性がある)というのがオープンソースによるバザール型開発モデルのキモなのだ。しかし、ソースを公開するだけでバザール型開発がうまく行くとは限らない。オープンソースによるバザール型開発のメリットを生かすには、最低でも改変点の再頒布の許可と権利処理上煩瑣なライセンス条項の排除が必要となる。しかし、いくら制約を取り払うことが重要だからと言って、パブリックドメインのように「何をしてもOK」としてしまっては、作者の立つ瀬がない。また、GNU GPLやBSDライセンスといった特定のライセンスのみが唯一の「オープンソースのライセンス」としてしまうのは、それこそ宗教戦争じみた混乱に拍車をかけるだけだろう。

そう考えていくと、結局オープンソースによるバザール型開発モデルが有効に機能するには、前出の条件に加えてさらにいくつか特定の条件を制約として置き、ソフトウェアを取り巻く状況をコントロールする必要があることが分かってくる。もちろん制約は少ないに越したことはない。そのような制約の集合のうち、ライセンスに関するものとして慎重に選び抜かれた、これらだけははずせないという9つの条件が、「オープンソースの定義」なのである。言い方を変えれば、「オープンソースの定義」は、オープンソースによるバザール型開発がうまく回るために必要だと経験上知られている、それも最低限の必要条件を列挙したものなのだ。一般のユーザからハッカー、企業や公共機関といったオープンソースやバザールに関わる主体は、必ずしも利害が一致していない。そもそも開発者の間でも意見が一致することすらまれである。しかし、それでもなお、誰もが賛同し協力できるよう、極力緩く、しかしそれでもなお開発者とユーザ双方の権利と意志が最大限尊重されるような基準を設定したのが、「オープンソースの定義」なのだ。だからといってむやみにありがたがる必要はないが、そういった経緯を経て、熟慮の末成立したものだということは押さえておきたい。

ちなみに「オープンソースの定義」が微妙なバランスの上に成り立っているのは、その成立過程に原因があると考えられる。「オープンソースの定義」が、Debian Projectの「Debian フリーソフトウェアガイドライン」を下敷きにしていることはあまり知られていないようだが、Debianは、自らが頒布して問題の無いソフトウェアと、頒布できないソフトウェアを厳密に弁別したいと考え、侃々諤々の議論の末このような基準をまとめた。当時すでにGNU GPLやBSDライセンスといった種種多様なライセンスが存在していたのだが、良く知られているライセンスをすべて列挙する代わりに、頒布に障害となる条件を課すようなライセンスを排除し(ネガリスト)、ライセンスが満たすべき要件を列挙するといういわば公理主義的な方法を採ったのである。ここで重要なのは、DFSGはソフトウェア作者とユーザの両方の性格を持つ頒布者によって編纂されたため、ソフトウェア作者と同じウェイトで、ユーザの利害も考慮しつつ書かれたということだ。第四条に典型的に見られるように、流通の容易さを損なわず、かつ作者の意志も極力損なわないようにするということは、ある種の「妥協」でもあるわけだが、そういったものが盛り込まれた理由はここにある。このようなあくまで現実主義的な性格は、「オープンソースの定義」にも基本的にそのまま引き継がれているのだ。

念のため一言付け加えておくと、もちろん「オープンソースの定義」を満たしているからといって、バザール型開発が自動的にうまくいくとは限らない。例えば、ユーザからの要望にきちんと対応できなかったり、恣意的なプロジェクト運営で人望を失ったりすれば、そのプロジェクトは遅かれ早かれ推進力を失うだろう。そうしたものが失敗した理由まで、オープンソースのせいにされてはたまらない。また、逆にオープンソースでなくても、バザール型開発がうまくいくことはある。往年のVz エディタがまさにそうだ。Vzに限らず、別にオープンソースでなくても開発がうまく進んでいる(いた)ソフトウェア開発プロジェクトはいくらでも存在するが、そういったものが「オープンソースなので成功した」と言われたら彼らが困ってしまうだろう。

「オープンソースの定義」の意義

GNU/Linuxの成功を見て、何だかよく分からないがどうも「オープンソース」とか言うものにすると良いことがあるらしい、そういったことを唱える風潮があるようだ。一連の政府の動きもその流れに乗ったものだろう。しかし、今まで述べてきたように、オープンソースによるバザール型開発の恩恵を最大限享受するには、前提となる諸条件が満たされていなければならないのである(逆に、オープンソースであることははバザール型開発成功のための必須条件ではない)。そういった条件をまとめたのが「オープンソースの定義」だが、別に天下り式にどこかから落ちてきたのではなく、現実的な要請から現場で生まれたものだということがお分かり頂けたと思う。ゆえに、もし「オープンソース」という概念に「オープンソースの定義」から逸脱した制限を加えたり、省いたりしたいのであれば、その前にそれがオープンソースによるバザール型開発においてどのような意味を持つのか、慎重に検討すべきなのだ。

実際のところ、筆者は「オープンソースの定義」の中身に関する論争は、もっと起こってしかるべきだと思う。既存の基準を単に丸暗記してありがたがっていても仕方がない。なぜそのような定義になっているのかを我々一人一人が検討し、吟味すべきなのである。そして、納得が行かなければOSIにそう言えば良い。以前の記事で紹介したように、Debian Projectはソフトウェア以外の著作物における「フリー」という概念に関して、「フリー」概念の総本山とも言うべきFree Software Foundation(FSF)と論争している。こうやって思想というものは鍛えられていくのである。この程度のことを思想とか言うと面はゆいが…また、そうやって自分の意見をどんどん発言していくことが、真の意味で「オープンソースにおける日本の国際プレゼンス」の向上につながっていくことは言うまでもない。最初に権限ありきではなく、まずは行動なのである。

さらに、「オープンソース」の定義が曖昧になると、プロプライエタリなソフトウェアに立脚した反オープンソース陣営からの攻撃に隙を見せることになる。例えば、Microsoftはオープンソースへの対抗策として「共有ソース」構想を打ち出したが、公共機関がもし「中身さえ見られれば良い」という方針であれば、これで十分ということになろう。しかし、再頒布はできず、改変も困難という条件では、開発の主導権は相変わらずMicrosoftに握られているわけで、何より我々に何のメリットもない。筆者自身は、オープンソースソフトウェアを政策的にことさら優遇するようなことは無意味だと思っている(費用便益分析に基づいて、あくまで「何がどの程度のコストでできるか」という基準で判断すべき)が、「オープンソース振興」の名のもとにこのような類のものが推奨されたらまさに本末転倒だ。

また、大熊氏は

そのような観点から「オープンソース」という言葉を使うときに
は、ネットワークに密着したソフトウェ アの開発・流通・マーケティングの
構造が重要なのであって、ライセンスのみをOSIの定義に照らして厳密に適用
して議論することには意味がない。

と述べているが、ここまでの議論を追って下さった方なら分かるように、そもそも国際的な「ネットワークに密着したソフトウェ アの開発・流通・マーケティングの構造」を支えているのは、「オープンソースの定義」とそれを満たすライセンス群が提供するある種の保証なのだ。「オープンソースの定義」が、万国共通のものとしてあるおかげで、例え外国産のソフトウェアで難解なライセンスが適用されていたとしても、そのライセンスが「オープンソースの定義」に準拠している限り、「オープンソースの定義」で規定された範囲内で自由に利用することができる。
元々ビジネスとの親和性を念頭に策定されたこともあって、「オープンソースの定義」は、オープンソースに立脚したビジネスがスムーズに運ぶ土台を築いているのである。

まとめ

長々と書いてきたが、「オープンソースの定義」に準拠しないライセンスが適用されているソフトウェアを「オープンソース」と呼ぶことは、オープンソースによるバザール型開発のサイクルを揺るがしかねず、百害あって一利無しだということがお分かり頂けただろうか。「オープンソースの定義」からはずれるものは、個々のライセンスに応じて「ソースが公開されているソフトウェア」あるいは「無料で手に入るソフトウェア」などと明記すれば良いだけの話なのだ。ちなみに、「オープンソースの商標を取って、オープンソース(R)として用語の利用を制限すれば良いではないか」という意見もあった。これは鋭い意見だと思うし、実際「オープンソース」という商標はopensource.jpで取ってあるのだが、これは元々商標ゴロの脅威にさらされてやむなく防衛目的で取得したものであって、それを振り回すというのはばかげているしやりたくない。このような文章によって少しずつ理解を深めて頂き、ご自分で理解した上で「オープンソース」という語を使うようにしていただければと思う。逆に、そのロジックを理解した上で論拠を示してオープンソースを批判するのであれば、それは素晴らしいことだと思う。あるいは、一連の議論を理解した上で、それでも「オープンソースの定義」に則さない用法で「オープンソース」という用語を使うことに積極的な意味があれば(「分かりやすい」というのは理由にならない)、ご教示頂きたい。

最後に、大熊氏を含め、オープンソースの開発者に「お礼」がしたいという人は多いのだが、ことさらお礼をしなくても良いから、少なくとも人のやっていることくらいきちんと的確に表現してほしいというのは贅沢な望みなのだろうか?

投稿者: mhatta

A rapidly-aging old-school geek in Japan.