コメンタリ：オープンソースは動詞にあらず
私は現在OSDLでの仕事をしているが、その職務柄、オープンソースが他動詞として用いられた文章をしばしば耳にする。それは例えば「My company open sourced our product」（日本語的意味：弊社は製品をオープンソース化しました）といった具合だ。誤解してもらうと困るが、私はガチガチの規範文法主義者ではない。英語というのは動的に変化する柔軟な言語であり、本来は名詞であった単語が動詞化したり、その逆が行われたりするものである。一例として「source」という単語を見てみよう（［名詞］元は中期英語のsoursで古期フランス語surse［男性形］が起源。また“起こる”を意味するsurdreの過去分詞の名詞用法で、その起源はラテン語のsurgereにもつながる）。現代の英語で「source」は名詞に分類されているが、この業界では忌まわしき「outsource」（アウトソース）と同様に動詞として使われることも多い。
私が気になっている点は、統語論者が動作主の前提としている考え方に起因する。実用文法の観点からすると（格文法の場合とは異なり）他動詞の主語は動作主であり、それが主体となって動詞の直接目的語ないしは非動者と呼ばれる対象に行為を及ぼすことになる。それは例えば「Dog [動作主] bites [動詞] man [非動者]」（犬が人間にかみつく）といった関係だ。犬（dog）が人間（man）にかみつく（bites）のは、犬の意志に沿った行為であり、そうした行為が可能であるから行えるのである（ソフトウェア関係向きの文例としては「Cat throws up hairball」（猫が毛玉をはき出す）の方がいいかもしれない）。それでは、「the owner of a piece of code can open source that code」（日本語的意味：プログラミングコードの権利の所有者が、それらのコードをオープンソース化する）という英文を見た場合、そうした行為が“主語にあたる主体者による恣意的判断や命令ないし認可によって行われる”ということがあり得るだろうか？
ソースコードの形態には4つのカテゴリが存在するが、私がオープンソースと見なしているのは、そのうち1つだけである。Microsoftを始めとする多くのソフトウェアサプライヤの行うコード開発は、段階的なステップをたどりながらこうした4つの形態を経るものだが、その際には“オープン”という理念を正しく反映している場合もあれば、歪めた形で不誠実に利用している場合もある。
第1のカテゴリは、ドキュメントとしてのソースコードという形態である。この段階においてバイナリ製品のサプライヤの用意（ないし販売）するソースコードは、（技術ないしライセンス的な意味で）実際にビルド可能なものである必要はなく、そのサポートはもとより、最終的に構築するバイナリとまったく無関係なものであっても可と見なされることもある。コードの提供は、ソフトウェアエスクロー（ソフトウェアライセンスに関する諸所の技術情報を専門の第三者に預託する制度）の要件を満たすために行われるが（よくあるケースは政府機関に納める場合など）、その意図は実用的なドキュメントの代用程度のものであり、ベッドに寝ころんで目を通せればいい資料レベルのものもある。
第2のカテゴリは“撒き餌”としてのソースコードという形態である。この段階においてサプライヤは自社のバイナリ製品としてビルド可能な一式としてソースコードを仕上げるが、その際には、バイナリの改編、再頒布、配備を禁止するライセンスが設けられるのが普通だ。そうしたソースコードを実際に使用したければ、商用的なバイナリの改編、再頒布、配備を許可したライセンスを改めて取得しなければならない。この第2のカテゴリにもっともよく適合するのが、Microsoft Shared Sourceに関する規約とそこに秘められた意図だ。マイクロソフトの主催する“釣り堀”鑑札制度を擁護する立場からは、潜在的なユーザを釣り上げる“撒き餌”目的な内容でも、ドキュメントとしては可なのである。
第3のカテゴリはOSIライセンスを取得したソースコードという形態である。この段階において商用ソフトウェア製品のサプライヤは、何らかの有効なオープンソースライセンス（BSD、GPL、Mozillaなど）下でソースコードを利用できるようにしているはずだが、その他にも最善の努力を謳ったサポートを提供したり、パッチの提供その他に関するフリー/オープンソースソフトウェアプロジェクトの慣例に従うといったケースもある。とは言うものの、OSIライセンスを取得する段になっても単にレガシーコードを丸投げしているだけというベンダが存在するのも事実だ。このシナリオが最も広範に使われている分野は、オープンソースを利用したデュアルライセンスのビジネスモデルや、ハードウェアベンダがデバイスドライバその他のユーティリティを将来的な保証を放棄した上で提供する場合である。
実は、ここまでに見た3つのシナリオにあるコードの形態こそが、オープンソースが動詞として用いられる文章において、その目的語として通常使われているものなのだ。意味論的な観点から見た場合、こうした動詞の使用法には問題が存在するが、その問題点は実際のシナリオ的な観点から見た場合の問題とも共通しており、それはコミュニティという概念が欠落していることなのである。なぜならば、単に名目上の措置としてソースコードをオープンソースに分類したとしても、それを支えるコミュニティが存在しなければ、それは誰にも読み解かれないカビの生えた難解な学術書と同様の存在であり、将来的な進化から取り残された死んだも同然の文字の集まりと化すだけでしかないからだ。
第4のシナリオこそはオープンソースの真の意味を具現化した模範例と呼ぶべき形態であり、それは開発者とユーザが協力してプロジェクトコードの開発と導入やメンテナンスを行うコミュニティを形成するという状態である。過去に成功を収めたプロジェクトを振り返ると、そのソースコードをOSIライセンス下でリリースしている場合が多い。実際これまでに成功したコミュニティベースのプロジェクトはそのライセンスとして、GPL、Mozilla、Apache、BSDを用いており、具体的なプロジェクトとしては、GNU、Linux、Firefox、Apacheなど多数を挙げることができる。
ところで、仮にオープンソースは主体者の意志を実行するという意味での動詞となり得ないことを認めるとしたら、オープンソース系プロジェクトはどのようにして誕生するのだろうか？ 「初めに光りありき」ではなく「初めにコードありき」なのか？ それともギリシア神話において女神アテナは父親であるゼウスの胎内から成人した姿で生まれ出たとされているように、オープンソース系プロジェクトもボサボサ頭をしたハッカーの頭脳から1つの完成形態で生まれ出るのだろうか？ あるいはオープンソースとは進化という長い過程を経て形成されるものであり、創造主の主導ないし放任に従って、わずかずつその姿を変えてゆくのだろうか？ 結局のところオープンソースの創造という神話は、様々なストーリーで進展し得るのである。
1つはっきりしているのは、既存のプロプライエタリ系コードをオープンソースとしてリリースないし再リリースし直すことで、いくつかの重要なプロジェクトが誕生しているという事実だ。例えばプロプライエタリ系アプリケーションのNetscapeからはMozillaおよびその後身であるFirefoxが誕生し（ただし何度かの大幅なコード改変が行われている）、NCSA HTTPdからはApacheサーバ（ただし無数のパッチが施されている）が生まれている。同じくBSD系OS群の母体となったのは商用ATT UNIXであり（ただしATTと我が母校との間で執拗な法廷論争が繰り広げられた末の話である）、Eclipse.orgの母体はIBMのCodeSphereというプロプライエタリ系アプリケーション開発プラットフォームであり、OpenOfficeの母体はSunのStarOfficeである。とは言うものの、ソースコードを適切なライセンス下でリリースする（上述の第3のシナリオ）というだけでは必ずしも健全な結果を生み出すとは限らず、活発なオープンソースコミュニティ活動につながることは保証されないのだ。そうした活動が固定化するには成熟までの時間を費やす必要があり、それ故に多くの場合はコミュニティの明確な姿が見いだせないモヤモヤした期間を経験することになる。
その格好な事例は、デュアルライセンスである。一般に、デュアルライセンスに従事する開発者のコミュニティは小規模なものであるが、単一ライセンスのプロジェクトと比べると比較的に閉鎖的な姿勢を取る傾向にある。これらに対して最大の関心を寄せるのは、（事前に存在しているか否かにかかわらず）その商用版に携わるアプリケーション開発者やその一般ユーザである。それと言うのも、デュアルライセンスのコードベース開発は商用コードの所有者ないしスポンサーの影響下にある開発者チームを軸に行われるが故に、パッチの提供や改訂の行われる頻度には制限が課されることになるからだ。この件については、実用性および法的な側面から見た批判意見が展開しうる。つまり商用アプリケーションとそのオープンソース版が存在する場合、前者のリリースサイクルは概して後者よりも不活発化するのが常であるため、同一のコードベースを基にした商用版とオープンライセンス版であっても、両者の間での転向（あるいは完全なフォーキングの作成）をするのが事実上困難となってしまう。
また法的な側面から見た場合、商用プロジェクトの所有者の権利としては、公開されているすべてのパッチを商用版のコードベースに取り込むことができるのか、という問題も生じてくるだろう。こうした問題は、リリースやライセンス体系が変更されたプロプライエタリ系レガシーコードにも当てはまる。こうした自らの手足を縛る自己規制的な状況に陥った事例は、（Open）Solarisにまつわる準オープンなコミュニティの間に見て取ることができるはずだ。
系統だった発展過程を経てきたことで現在も活況を呈している独立系のプロジェクトは多数存在しているが、一見気ままに海を泳いでいる魚や自由に空を飛んでいる鳥がそうであるように、こうした団体は適者生存という選択圧の下で生き残らなければならない。例えばこの原稿を執筆している現在で数え上げたところ、SourceForge.netの登録プロジェクトは132,386団体が存在しているが、どれだけのコミュニティが離合集散を繰り返す組織のあり方に不安を覚えずに活動しているだろうか？
ただしオープンソース環境で発展した製品がひとたび成功を収めた場合、その成果は巨大なものとなるはずである。それを例証するのが、膨大な数のサブシステムやユーティリティを生み出したLinuxやGNUの世界であり、体系化されたオープンソースのあり方を示すと同時に、実力主義という1つのコミュニティモデルを提示している。これらの人々は“自分が正しいと感じること”を実践することで、オープン/フリーソフトウェアのあるべきスタイルの雛型を作り出しているのだ。
以上、私がかつて学んだ規範文法主義的な言語学から見た意見だが、それでも何かを述部とした「open source」の動詞的用法に違和感を感じないだろうか、あるいは少なくとも他動詞としての用法はひかえるだろうか。オープンソースとは、プロジェクトチームやエンドユーザの活動を通じて形成されるものであり、コミュニティという舞台の上でソースコードと人間が共同して行われるプロセスなのであって、それ以外の一般的な意味においてオープンソースを“作る”ということは不可能なのである。だからあり得る表現としては「our product/project became open source」（日本語的意味：製品/プロジェクトがオープンソースになる）というのがふさわしいことになる。あるいはこの記事を読んで啓発されたのであれば、いっそ「we open source」（日本語的意味：私たちはソースをオープンに公開します）という表現を使ってみたらどうだろうか？
Bill Weinbergは、Open Source Development Labsの上級テクノロジアナリストとして活動している。
NewsForge.com 原文
