「オープンソースの定義」の意義
はじめに
筆者が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で取ってあるのだが、これは元々商標ゴロの脅威にさらされてやむなく防衛目的で取得したものであって、それを振り回すというのはばかげているしやりたくない。このような文章によって少 しずつ理解を深めて頂き、ご自分で理解した上で「オープンソース」という語を使うようにしていただければと思う。逆に、そのロジックを理解した上で論拠を示してオープンソースを批判するのであれば、それは素晴らしいことだと思う。あるいは、一連の議論を理解した上で、それでも「オープンソースの定義」に則さない用法で「オープンソース」という用語を使うことに積極的な意味があれば(「分かりやすい」というのは理由にならない)、ご教示頂きたい。
最後に、大熊氏を含め、オープンソースの開発者に「お礼」がしたいという人は多いのだが、ことさらお礼をしなくても良いから、少なくとも人のやっていることくらいきちんと的確に表現してほしいというのは贅沢な望みなのだろうか?
