ised議事録

02-121. 設計研第2回: 八田真行 講演(1)

題目:「オープンソース構造と力

D2:オープンソースの構造と力
(開催:2005年2月12日 国際大学GLOCOM / 議事録公開:2005年4月9日)

八田真行 HATTA Masayuki

http://www.mhatta.org/
東京大学大学院経済学研究科 博士課程 / Debian Project / GNU Project / 国際大学GLOCOM研究員

 1979年生まれ。2003年東京大学経済学部卒、現在東京大学大学院経済学研究科修士課程に在籍、専攻は「法と経済学」。高校時代アメリカ合衆国ニューヨーク州に留学。1998年より、 Debian JP Project開発者としてFLOSS (Free or Libre & Open Source Software) 関連活動を開始。2000年にはDebian Project公式開発者となる。また、1998年にはGNU ProjectのWebmaster、2003年からは Free Software Foundationのchief translation coordinatorを務める。同年 japan.linux.comの立ち上げに参与、主筆。 CPSR/Japan 設立メンバ。日本のオープンソース運動に関わるアクティビストの中で最若手の中心人物。

 今日の講演は「オープンソース構造と力」という題目です。このタイトルは浅田彰さんの著作*1をモジってみたのですが、内容的にはあまり関係ありません。ised@glocomでキーワードになっている東さんの「環境管理型権力」という概念を用いて、オープンソース環境管理型権力として捉え直すという作業を行っていきたいと思います。

 流れとしては、まずオープンソース運動に見られる「フォーク fork」という現象を取り上げ、バザール型開発におけるガバナンスについて考えます。そしてオープンソースを成功例として捉えていった場合、その観察から得られる知見を整理していきます。最終的には、オープンソースの事例から考える環境管理型権力のよりよいガバナンスの条件とでもいうべきものを考察していきたいと思います。

1.環境管理型権力としてのオープンソース

 では、最初にオープンソースとはなにかについて簡単に確認しておきましょう。僕にはオープンソースに対する一般的なイメージがどのようなものになっているのか、よくわからない。ただ、おそらく「プログラムの設計図(ソースコード)が公開されている」「無料で使うことができる」「仕事でもないのに、暇な人々がボランティアで集まって作っているらしい」といったイメージを一般に持たれているのではないでしょうか。

 しかし、これは不正確な理解です。実際には、通常はあまり関係のないとされている2つのものが混合しているイメージとして把握できます。すなわち、ひとつはプログラムという著作物の法的状態(ライセンス)としての<オープンソース>(ここではこの法的状態としてのオープンソースをカッコつきで表しておきます)。そしてもうひとつは、著作物の開発形態としての「バザール型開発モデル」*2オープンソースの内実は、大きく分けてこの2つになるんですね。

 今回の講演で主張するのは、前者の法的状態としての<オープンソース>という「構造」が、後者の「バザール開発型」としてのオープンソース、つまりバザール開発という集合行動における「力」を、間接的に規定しているのではないかというものです。要するに、<オープンソース>という法的状態はある種のアーキテクチャ、ある種の環境管理型権力として考えられるのではないか。

 さて、ここでいうアーキテクチャあるいは環境管理型権力*3について、僕なりの解説を加えておきます。環境管理型権力という言葉は、東さんと大澤真幸さんによる『自由を考える』(NHK出版、2003年 asin:4140019670)という本を読みまして、これはとてもわかりやすい言葉だと思ってそのまま使わせていただいているんですね。東さんはフーコーの権力論などを補助線にしながらこの言葉を定義されているのですが、ここでは漠然と、文字通り「環境を管理する権力」だと考えています。たとえば東さんがお出しになっている例というのはマクドナルドの硬い椅子というものでした。これは、マクドナルドにある椅子はワザと硬く、座り心地が良くないものを選んでいる、と。……本当に故意かどうか僕は確認していませんので、マクドナルドに訴えられると困ってしまいますが(笑)、座り心地が悪いと長居をする気がしませんね。そして長居を皆がしなければ、全体としてのお店の回転率を上げることができる、というものです。僕がこの言葉をお借りするときには、次の3点を意識しています(図:「環境管理型権力」とは)。

 1)まず、椅子に座った客は、「長居するな」と明言されたわけではありませんし、長居させたくないという店側の意図に気づくことがないという点です。なんとなく、居心地が悪いから出て行くに過ぎない。こうした対象の内面に訴えかけない身体的(動物的)な管理のあり方を、東さんは環境管理型権力であるとして描いている。ただ僕が今回この言葉を用いるときには、身体的な管理という側面は省いて、「環境」の管理という意味で用います。これが第一点です。

 2)また第二点として、ここで僕が環境管理型権力というときには、具体的な禁止や制約とその目的が、直接結びついていないかたちのガバナンスというものがありうるのではないかという含意を込めています。つまり、マクドナルドの例のように、回転率の上昇という目的を実現するために椅子の堅さという制約をかけるという「目的-手段」がはっきりしたものだけが環境管理型権力ではないだろう、ということを描き出したい。偶然の産物としてのオープンソースといいましょうか。

 3)最後に、『自由を考える』ではフーコー規律訓練型権力*4との対比が行われていました。環境管理型権力とは、内面的な価値観・規範などの形成を促すことなく、間接的に行動をコントロールするというわけです。つまり、人々の意図や動機はコントロールしないが、人々のインセンティブ構造を介した間接的な制御を行うということです。これは経済学でいうところのメカニズム・デザイン、いわゆる「制度設計」に近い概念といえる。このあたりを研究してきた一派は、どのような法律や制度、契約ルールを作れば、社会的に望ましいかたちで最適配分ができるかということを、ゲーム理論などの道具立てを用いて考えてきたんですね。つまりここでいう経済学とは、環境管理型権力の学であったといえるのではないか。これが第三点になります。

図:「環境管理型権力」とは
図:「環境管理型権力」とは

2.バザール型開発形式のガバナンスヘゲモニー

 それではなぜオープンソース環境管理型権力といえるのでしょうか。法的な状態としての<オープンソース>が、バザール型という開発プロジェクトの形態を間接的に規制しているというモチーフをさきほど提出したのですが、まずはそのバザール型開発形式のガバナンスの中身を見ていきます。

 まず、よく言われることとして、バザール型というのはフラットな組織形態ではないかと言われます。要するに参加するみなが平等で、わいわいがやがやとやっている。誰が統制を取っているというわけでもなく、カオティックなイメージです。もちろんプロジェクトリーダーはいるのですが、たしかに多くの場合、目に見えるかたちでの地位や役職はありません。そして上意下達的な強制力もほぼ存在しません。しかしその一方で、潜在的なヒエラルキーは存在しないわけではない。要は能力の差はもちろんあるし、発言力の差もある。そして持ちうる権利の差というものがあり、これが重要なんですね。

2.1.原著作者というヘゲモニー

 どういうことか。それは「原著作者」であるかどうかという点です。というのも、オープンソース・ソフトウェアは基本的にプログラムという著作物ですから、著作権で保護されています。たとえば日本の著作権法だと第十条一項九条で「プログラムは著作物である」と明記されている*5著作権法の構成上、著作権はいくつかの権利の束にとして存在しています。もちろんオープンソースは当然日本産のものではありませんから、たとえば国際的なベルヌ条約*6の範囲で考えてもいいでしょう。

 このプログラムの著作権に関して、オープンソースに限らず基本的に作者は「留保」している状態です。つまり束となっている著作権のなかには、複製権や、著作者人格権に含まれる氏名表示権といったものがありますが、場合によってはこうした権利は行使されないものの、基本的には著作権者がその権利を有したままです。だから逆にいえば明示的な許諾を受けない限り、第三者には自由に使えないものなんです。ですから、オープンソースでは著作権者の多くがライセンス文書によってその使用を明示的に「許諾」します。つまり著作権者とその他大勢との関係は、ライセンス契約関係の視点から見れば、ライセンサーとしての著作権者とライセンシーとしての一般参加者(あるいは彼らがそのプログラムのどこかを改変するならば「二次著作者」)になっている。これはどういうことかというと、どれだけそのプログラムが無料で使えて改変が許されていたとしても、最初にライセンスを提示するのはもちろんライセンサーですから、最初の時点での全権はライセンサーに存する。つまりある種の独裁者としてのライセンサーという存在があるわけです。

2.2.フォーク(分派)をめぐって

 次にオープンソース型の開発プロジェクトの特徴として、フォーク(コード・フォーキング Code Forkingとも呼ばれる)という現象を取り上げます。このフォークという言葉の意味は、文字通り食器と同様、「分岐する」ということです。あるオープンソース・プロジェクトが分派したり独立したりすることをフォークと呼んでいます。

 フォークの原因として、開発方針の相違やライセンスの変更といったものが多くあります。ライセンスの変更とは、たとえばオープンソースであったものをオープンソースでなくしてしまうといったことですね。またフォークに関しては、エリック・レイモンド(Eric Raymond)の『ノウアスフィアの開墾』(山形浩生訳)という文章でも少し取り上げられています。

 フォークの実例を4つ挙げたいと思います(図:フォーク(fork)の実例)。有名なものとして、92年にEmacs Version 19からX Emacs Version 20が分岐したという事件がありました*7。理由はコピーライト・アサインメント(著作権譲渡)の問題だったんですね。X Emacsというのは、もともとEmacs 19に対して、見栄えを良くする・画像の扱いを良くするといった部分でコードを足したものでした。もともとはLucid Emacsとも呼ばれていたのですが、Lucid社の後にNetscape Navigatorを作ったジェーミー・ザウィンスキー(Jamie Zawinski)*8 がいて、彼も開発に関わっていました。さてコピーライトのアサインメントとして、FSF(Free Software Foundation フリーソフトウェア財団)がEmacsコードベースの著作権を持っていたわけですが、そしてFSFは、Emacsコードのコントリビューター(今回でいうとX Emacs ver.20の開発者であるLucid社)に対して、「著作権の行使をFSFに一任する」という一文(著作権譲渡証明書)を提出しなければいけないという決まりを定めていました*9。しかしLucid社がそれを拒んだため問題となり、フォークに至ったんですね。

 フォークに至った理由としては、ほかにもLucid社が書いたX Emacsのコードを本家のEmacsにマージするプロジェクトが進まなかったせいもあります。この点に関してはLucidにもFSFにも言い分があるようで、また単純に技術的に難しかったというだけのことかもしれませんが。また、FSFの創設者でEmacsをもともと開発したリチャード・ストールマンRichard Stallman*10が、これを“GNU X Emacs”と呼べと主張して、話がこじれてしまったという話もある。。こうした結果として、EmacsとX Emacsは現在でもほぼ同等の存在として共存しているんですね。

 次に、セキュア・シェル・ソフトウェアであるSSHとOpen SSHが1999年に分離したケースを挙げておきましょう*11SSH Version 1.1.12が事実上オープンソースだった最後のバージョンで、ここからOpen SSHが分岐しています。理由はオリジナルのSSHのライセンスが次第に制限的になってきて、要するにSSHの原著作者がプロプライエタリなビジネス志向へとシフトしたわけです。たとえばWindowsなどのUNIX以外のプラットフォームへの移植を禁止したり、商用目的での利用を禁止し、代わりに商用ソフトのほうを企業に購入するよう促すということをやろうとした。加えて、このソフトウェアはもともとlibgmpライブラリというものをそのコードに含んでいたのですが、それには当時GPLが適用されていたにも関わらず、それを放置していたというライセンシングの問題などがありました。こうしたゴタゴタがあった結果、いまはほとんどのプラットフォーム上でOpen SSHが主流になっていると思います。

 そしてSambaSamba TNGフォークですね*12。これは開発方針の食い違いから、2000年に分裂しました。ここではSamba側のプロジェクトリーダーが、分岐して別の道を行きましょうと平和裏にフォークが成立しました。ただ、 Samba TNGのサイトを見に行くと「我々はまだ生きてます(“Samba-TNG is still alive”)」なんて書いてあるんですが、「我々はまだ生きてます」と主張するプロジェクトが生きているわけがなく(笑)、現在、一般的にはオリジナルのSambaがそのまま使われています。

 いま3つ例を紹介しましたが、これらは共存している例、新しいものが勝ってしまった例、古いほうが勝った例ということになります。そして最後に、これは一番最近のことなのですが、XFree86X.orgの分裂がありました。実はその理由はいまだによくわかっていないのですが、ともかくXFree86のリーダー格だった人々がライセンスを変更しようとした。これはいわゆる宣伝条項といって、頒布にあたって宣伝を表示することを義務付けるようなライセンスでした。しかしそこに問題がありまして*13GPLが適用されているソフトウェアでかつXと連動したソフトウェアなどがあると、GPLライセンスには「宣伝条項の禁止」の条項があるためにライセンスの内容がかち合ってしまうわけです*14

 ほかにも、XFree86に関してはコアチームやコミッターたちがパッチをレビューする体制になっていたのですが、しばしば放置されることがありました。その結果、DebianBSDFreeBSDといった主要なディストリビュータ*15の大半はX.orgのほうを支持した。また、キース・パッカードのような主要な開発者たちがX.orgのほうに移った。というわけで、この例でも新しくフォークしたほうが勝ちそうな状況ですね。

図:フォーク(fork)の実例
図:フォーク(fork)の実例

2.3.フォークの禁止の禁止 一方的な契約終了条項をめぐって

 さて、こうして見てきたフォークなのですが、オープンソースに関わっている人々にとってはフォークができるということはごく当たり前のことになっています。しかしよく考えてみると、一番最初のライセンスの書き方によっては、本当はフォークになる事態を禁じることは可能なはずだと思うんですね。たとえば、あるソフトウェアのバージョン1はオープンソースとして出す。そしてバージョン2からは非オープンソースとして出したいとする。これはSSHと同じケースですね。そこでオープンソースの世界では、それに同意しない人はバージョン1からフォークをしてきたわけです。ところが、バージョン1の段階で、著作権者がライセンス契約を一方的に打ち切ることができるという条項をライセンスに盛り込んでおけば、バージョン1についての反乱や改変・頒布といった行為はできないはずなんですね。ここでは仮にこれを「一方的な契約終了条項 one-sided revoking clause」と呼んでみましょう。

 こういう条項は商用ソフトウェアビジネスの世界では一般的です。またオープンソースの世界の実例として有名なものに、JikesというJavaコンパイラのライセンスを巡る事件がありました*16。これはIBMオープンソースのつもりで出したものですが、そのライセンスにはIBMは事実上任意に契約を終了できると書かれていました*17。「任意に」というのは微妙な表現ですが、たとえば誰かがIBMの出したオープンソースのコードに何らかの特許侵害があると指摘した場合には、IBMはそのコードを使っているユーザーに対して、オープンソースのライセンスの下で認めた権利を打ち切る、という通知を一方的に行うことができる、というような書き方をしていました。元々この条項は別段フォークを止めたいわけではなく、特許侵害対策として盛り込んだと思うんですが、フォークを止めるためにも使えます。ただこのJikesライセンスの条項は批判も多かったために、後に撤回されることになります。

 もうひとつ紹介しておきますと、アップル社のAPSL(Apple Public Source License)というのがありまして、これも同様に、つまりアップルが事実上任意に契約を終了できるという条項が盛り込まれていました。これはMac OS XDarwinと呼ばれる技術のライセンスとして採用されていたもので、たぶんJikesの真似をしたんだろうと言われています。このAPSLをめぐっては有名な論争が起きたのですが、その発端はOSI(Open Source Initiative)という「オープンソースの定義 The Open Source Definition(以下、OSDとも略記)」*18を定めている組織があって、その創設者であるエリック・S・レイモンドがこのAPSLを「オープンソースだ」と認めてしまったことにあります。これにFSFストールマンや、Debianのイアン・ジャクソン(Ian Jackson)、ブルース・ペレンス(Bruce Perens)といったオープンソースの著名人たちが反発し*19、結局FSFがアップル社と話し合ってこの条項を撤回させ*20、APSLはいまVersion2.0になっています。

 いま「オープンソースの定義」、略してOSDという言葉を出しました。これは誤解されている人が多いのですが、この「オープンソースの定義」自体はライセンスではないんですね。これはメタライセンス*21とでもいうべきものであって、これを満たしていればオープンソースと呼んでよい、という基準が10個定められているものです。これはOSIという任意団体が管理していまして、頻繁に改善され現在Version1.9です。頻繁に改定されてはいるんですが本質的な中身はあまり変わってはいません。そしてこのオープンソースの定義の第3項では、「派生ソフトウェアを認めなければいけない」というかたちでフォークについて間接的に配慮しています。つまりオープンソースでは「一方的な契約終了」を禁じているわけです。

2.4.「優しい独裁

 さて、こうしたフォークについて、プロジェクトリーダーの立場から見たときなにを意味するのかについて考えてみましょう(図:プロジェクト・リーダーのジレンマ)。まずオープンソース・プロジェクトでは、彼は自由にふるまっていいわけです。なにか制約があるわけではないですし、さらに上位にいる誰かから命令されるわけでもありません。ですから独善的なプロジェクト運営も可能である、と。しかしフォークの自由が存在するために、プロジェクトに集う参加者の側から見たとき、参加するも退出するも自由であるわけです。たしかに給料を払っているわけではないので、協力を強制することはできません。

 退出というとき、消極的な退出と積極的な退出という2パタンに分けて考えることができます。消極的な退出というのは、単にプロジェクトから追い出されるということです。先ほどの例でいえば、一方的に契約を終了させてしまうことです。そして積極的な退出というのは、たしかにプロジェクトからは抜けるんだけれど、残存するコードベースを用いてオルタナティブな開発を続行するということで、つまりフォークということです。この積極的退出の可能性を考えるとプロジェクトリーダーはあまりひどいことができませんね。フォークをされてしまい、主導権を失う可能性が常にあるからです。ライセンスは公開されているわけですから、そのことは参加者もリーダーも事前にわかっている。

 となると、すくなくとも協力してもらいたいのであれば、プロジェクトリーダーはあまり独善的な運営はできない。たとえばオープンソース開発について「優しい独裁*22という表現をすることがありますが、それはこういう意味です。著作権を持っている以上、最終的な決定権はリーダーが持っている以上独裁的ではある。しかし、プロジェクトの運営自体は比較的民主的というか、みんなの意見を汲んだ「優しい」ものにしなくてはいけない。逆に、「これがみんなの意見である」と考えれば、リーダーはここぞというときに決断を下すこともできるという、ある程度柔軟な体制になっている、と。もちろん、プロジェクトで結局開発しているのは自分だけじゃないか、と思うならば、皆を追い出して一人でやることもできます。たとえばXFree86はディヴィッド・ドーズ(David Dawes)の「ひとりオープンソース」状態になってしまいつつあるんですが、ともあれ孤立を選ぶこともできるように選択肢は開かれている。選択肢は自由ですが、皆が合理的に振る舞うだろうと想定すれば互いに協力しあうような場の力が働いていると言えるんですね。そして、もちろん主導権を握るのがめんどくさくなったのであれば、あえてフォーク「してもらう」こともできるわけです。

図:プロジェクト・リーダーのジレンマ
図:プロジェクト・リーダーのジレンマ

2.5.まとめ

2.5.1.重層的な間接制御

 このフォークの例からわかるように、法的状態としての<オープンソース>が規定する、間接的な条項・条件が重層的に組み合わさることで、オープンソース・プロジェクトという場の運営形態はかなり左右されています。そして、ライセンスの記述のしかたは色々な書き方がありえる。さきほどの例のように一方的な契約解除を入れてもいいし、一方的な契約解除はしないと書いてもいい。あるいは契約は両者の同意による破棄がない限り永続的だと書いてもよい。あるいはAPSLが採用したように、一方的な契約解除はありうるが、逆にライセンシーが文句を言ってきた場合には協議をしなければいけないという条項を追加的に挟み込むのでもいい。そしてこうしたライセンスレベルの多様性を、ライセンスのメタレベルにあるOSDの存在によって、どういう条項であればオープンソースであると言えるのか・言えないのかの縛りをかけています。

 このようにオープンソースというのは、共通性はありつつも多様性を許容するという仕組みになっています。これによっていろんな主体が共存可能となり、互いにチェックアンドバランスが働くという構造になっている。たとえばフォークの例であれば、OSIがオープンソースの定義にしくじることがあるので、そんなときには周囲の発言力の強い人々が異議を出す。そしてこの多様性の許容がフォークを許容し、それゆえにリーダーたちは協力を取り付けるために民主的で円滑な運営というものを合理的に選択する。そして、こうして生き残ったプロジェクトによってソフトウェアの普及と流通が達成されていくというわけです。こう考えると、<オープンソース>というある種の法律や規範を使った構造が、バザール的運営を間接的に制御しているとみなせるのではないか。

2.5.2.価値の多様性

 ここで興味深いのは、倫理研のほうのキーワードになっている「価値」の問題なんですね。オープンソースというのはなんらかの価値を実現するために様々なルールが設計されているとはいえ、その価値は一定には決まっていません。参加者間で必ずしも利害や目的、思想が一致しないことが多いですし、むしろそれが前提となっている。たとえばいわゆる普通のハッカーもいれば中道穏健派もいる、あるいはIBMやhpといった営利目的の企業もいれば、金儲けはあとで、ただハックだけがしたい中毒者もいるでしょう。

 またOSDの第五項では差別の禁止というのを入れています。これは要するにユーザーの属性などによって、利用を制限するような条項を盛り込んではいけないということです。たとえばいまだとBSDの関係者とFSFというのは互いにあまり仲がよくない状態なんですが、BSDの人々でもGNU Cコンパイラを使うことができる。思想的に気に食おうが気に食わまいが、コードを共有することができる。こうしたOSDによる自由を守るための制約条項は、価値の多様性を下支えするインフラになっているわけです。

2.5.3.四規制力説からみる「オープンソースの構造」

 また前回倫理研の講演で、白田先生がレッシグの議論を「四規制力」と整理されていたので、それに当てはめつつ考えてみたいと思います。というのも、それによっていままでの議論に抜け落ちている部分が浮かび上がってくるからです。

 「法律」はここではライセンスのことです。ただライセンスは法律といえるのかという問題が実はあります。通常、ライセンスというのはあくまで個人間の契約を定めるものですから、民法の契約にあたるということで法律ともいえるでしょう。ただライセンスは契約ではないという議論がありまして、最近ではこの考え方が主流になりつつあります*23レッシグもそのようなことを言っています*24)。要するに、ライセンスというのはサジェスチョン(示唆)であって、著作権侵害が起きたときの取り決めをお互いに示しておくものだ、という考え方です。ただ、ここではライセンスは明文化された法律ということで考えましょう。

 次に、「規範」は「オープンソースの定義」のことです。OSD自体はライセンスではないので、ここでは規範の位置に置いています。

 そしてオープンソースにおける「市場」ですが、たとえば先ほどの例でいうフォークの事例を浮かべてください。あるソフトウェア開発のプロジェクトに人気があれば人が寄ってくるし、人気がなければ誰も寄ってこないでしょう。リーダーが気にくわなければフォークすることができる。このように、ある種の淘汰的な市場メカニズムがオープンソースの世界には働いています。

 そして最後に「アーキテクチャ」です。先ほど抜け落ちていると言ったのは、インターネットの普及というのがやはり致命的に重要である、ということです。オープンソースというアーキテクチャを支えるアーキテクチャとして、インターネットの普及はきわめて重要でした。つまりインターネットの普及というのは要するに取引コスト、意思疎通にかんするコストを下げる機能を果たしたわけです。そして、プログラムコードの流通・頒布のコストも下がっていく。これはプログラムは電子情報化された情報財ですので、ネットワークを介したコピーが簡単だったということです。

 こうした4つの構造をあわせて、「オープンソースの構造」と呼んでおきます。そしてここでの主題を言い換えれば、このオープンソースの構造が、バザール型運営という集合行動における力を間接的に、つまり環境の側から環境管理型権力として規定しているのではないかということですね。

2.6.議論の折り返し地点

 ここまでの議論をまとめておきましょう(図:中まとめ)。

 まず、オープンソースによって、バザール型という開発プロジェクトが間接的に制御されているのではないかというお話をしてきました。たとえばオープンソースのライセンスではフォークの可能性を残しているために、著作権者が暴走することに歯止めがかけられています。というよりは、歯止めを破って著作権者が暴走しても彼の自由ですし、著作権者に対してどこか公的な機関がああしろこうしろと命じているわけではない。だけれども、OSDというライセンスの大枠がフォークを認めるために、「優しい独裁」というプロジェクト形態をとることが合理的なものとして選択されていくという話でした。

 つぎに、間接的に多様性を確保しているのではないかという話です。オープンソースの定義自体がソフトウェアの開発や頒布を促進するような性質を持っているので、作者があまり好き勝手に流通をコントロールすることはできません。いわば「属著作者性」が弱められ、作者が死のうがどうしようが、勝手にソフトウェアだけ流通するという事態が起こりやすくなっています。しかし逆にいうと、オープンソースではフォークを「当然」とはみなしますが、それを「奨励」しているわけでは必ずしもありません。既存プロジェクトに貢献するコストよりもフォークするコストのほうが上回っていればフォークは起こらないでしょう。このあたりのバランスがおそらく重要ではないかと思うわけですね。

 またOSIのやり方が間違っていれば、周囲からツッコミが入りますし、オープンソースの定義それ自体も絶えず再検討に晒されています。なにかがおかしいと思えば誰かが文句をいい、それがまた検討の対象となるというように、絶えざる再検討がなされている。

 最後に、特定の価値からの中立というお話をしましたね。ここから議論を折り返して、なぜオープンソース環境管理型と言えるのか、その特徴をオープンソース以前の世界との比較を通じて行います。

図:中まとめ
図:中まとめ


*1:註:浅田彰構造と力』(勁草書房、1983年 asin:4326151285

*2:註:isedキーワード伽藍とバザール」参照のこと。

*3:註:isedキーワードアーキテクチャ」「環境管理型権力」参照のこと。

*4:註:isedキーワード規律訓練」参照のこと。

*5:註:著作権法第十条一項九条社団法人 著作権情報センター(CRIC)

*6:註:ベルヌ条約とは、正式には“The Berne Convention for the Protection of Literary and Artistic Works(文学的及び美術的著作物の保護に関するベルヌ条約”(CRICに掲載の邦訳)のこと。コンピュータ・プログラムについては、「著作権に関する世界知的所有権機関(WIPO)条約」(CRICに掲載の邦訳)にて明記される。

*7:註:Emacsについては以下参照のこと。→Emacs - Wikipedia

*8:註:のちにザィンスキーはMozillaプロジェクトを去ることになる(インプレス:Mozillaプロジェクト1周年、Zawinski氏が語るオープンソースの難しさ)。その際の手記は邦訳されている(Resignation and Postmortem: Japanese)。

*9:註:以下参照のこと。→なぜFSFは貢献者に著作権の譲渡をお願いしているのか - GNU プロジェクト - フリーソフトウェア財団 (FSF)

*10:註:isedキーワードストールマン」参照のこと。

*11:註:OpenSSH プロジェクトの歴史と実績

*12:註:以下の記事を参照のこと。→ITmedia News:分裂の不安を助長? Sambaのコード分岐発表

*13:註:宣伝条項の問題については、かつてはBSDライセンスをめぐるものが著名。→BSD ライセンスが抱える問題 - GNU プロジェクト - フリーソフトウェア財団 (FSF)

*14:註:以下の記事でも「他のライセンスとの"摩擦"も」という観点から紹介されている。→【特集】History of GNU - GPLとはなにか (3) GPLは万能か? (MYCOM PC WEB)スラッシュドット ジャパン | XFree86のライセンスが4.4.0から宣伝条項付きに

*15:註:以下の解説を参照のこと。→X-MEDIA パソコン用語事典「ディストリビューション」

*16:註:以下の記事を参照のこと。→Slashdot | Jikes licensing problems

*17:註:IBM Jikes Compiler License Agreement

*18:註:講演者の八田真行により邦訳されている。→The Open Source Initiative: オープンソースの定義(日本語)

*19:註:OSIに対するコメントが邦訳されている。→The Apple Public Source License - Our Concerns日本語訳。それを受けたレイモンドのリプライも以下同様。→OSI clarifies the status of the APSL 日本語訳

*20:註:以下の記事を参照のこと。→Wired News - アップルが批判に応えてオープンソースの条件を修正 - : Hotwired

*21:註:isedキーワードメタライセンス」参照のこと。

*22:註:isedキーワード優しい独裁」参照のこと。

*23:註:ライセンスは「契約」か、権利の「不行使宣言」かという議論がなされている以下を参照のこと。→【Internet Week 2003レポート】OpenSource Way 2003(2) - 小倉氏講演 GPLと日本法の整合性 (MYCOM PC WEB)

*24:註:レッシグがCreativeCommonsとGPLの関係について言及している箇所を参考のこと。→ Hotwired:日本の「クリエイティブ・コモンズ」の可能性 02. ローレンス・レッシグ教授インタビュー

トラックバック - http://ised-glocom.g.hatena.ne.jp/ised/04010212