ised議事録

02-1212. 設計研第2回: 質疑応答

質疑応答

東浩紀(以下、東):

 まずは崎山さんですね。皆勤賞ですが、どうぞ(笑)。

崎山伸夫(JCA-NET 以下、崎山):

 八田さんの講演に関するコメントなんですが、ストールマンがなぜコピーレフト的なものに向かったのかについての説明がなかったのが気になったので、補足を。ストールマンはそもそもEmacsというエディタをTECOというエディタのマクロとして開発しました*1。さらにストールマンTECO EmacsのユーザはEmacs用のマクロを開発し、これが当時のコミュニティで自由に流通していました。いまのユーザーの数に比べればとても小さい規模ではありましたが、ともあれEmacs は、初期の段階ではバザール的な性格を持っていました。Emacs もひとつではなく複数の実装があり、そのなかのひとつに、後にJavaの開発者として著名となるジェームス・ゴスリング(James Gosling)による GoslingEmacs というのがありました*2。これも一時期非常によく使われていました。ただ、Gosling Emacs はすでに次第にソフトウェア業界が商業化の波に巻き込まれていく時期に作られました。

 その後、再びストールマンFSFをはじめたとき、EmacsGNU Emacsとして再設計することになりました。このときストールマンは様々に散らばっていたマクロや改良コードなどをかき集めて再実装することになるのですが、そこにすでにGoslingが権利を売却してしまっていたGosling Emacsのコードも含まれていました。これがソフトウェアの商業化も進み、プログラムの著作権にも敏感となっていたときだったために法的に問題となり、ストールマンはGoslingEmacs由来のコードを全て削除して一から書き直す措置をとらざるを得なかったということでちょっとした騒ぎになった、ということがありました。

 この事件を期に、FSFはそれまでの緩やかなバザール型の開発方針をやめ、伽藍的な管理を厳密に行うようになりました。こうして閉じていってしまったフリーソフトウェアの文化を、オープンソースが再び開いていったというわけです。この歴史的事情はご存じの方も多いと思うのですが、FSFもかつてはバザール型だったという点は重要なポイントだと思います。つまりオープンソースもどこで閉じる方向へ向かうかわからないということですから。

八田真行

 はい、そのことについてなんですが、私のやっているjapan.linux.comの記事で、「GNU GPL登場前夜」というところでそのあたりの歴史については詳細に触れています。興味のある方はぜひ読んでください。

崎山:

 さらにもう一件コメント。フリーソフトウェアがビジネスに適合せず、オープンソースがビジネスを取り込んでいったという部分で、BSD系があまり流行らずLinuxのほうが普及したという事実関係についても補足させてください。というのも、フリーソフトウェアのほうがまったくビジネスをやっていなかったというわけではありません。Cygnusという、いまはRedHatに買収されてしまった会社がありまして、ここはGNUのコンパイラやデバッガの開発を支援していました。たとえばあるベンダーが新しいマイクロプロセッサーを出すとき、コンパイラやデバッガを提供する必要があるのですが、ソフトウェア開発者を相手とした市場の支持を得るにはGNUのバージョンも整備する必要があり、Cygnusにお金を払えばGNUのバージョンについては必要な部分を作ってくれるというビジネスモデルでやっていました。こういうかたちでのビジネス展開はまわっていたわけです。ただし、非常に限定的な市場です。

 これに対してオープンソースLinuxのビジネスはどこが違ったのかがポイントです。たとえばBSDというのは、カーネルのレベルに限らず、非常にシステム全体としてモノリシック(一枚岩的)*3な構造です。カーネルがひとつあって、ユーザーランドが揃っていて、オプションのパッケージがあったとしてもそれほど細かいレベルでは違いがない。ということで、これではパッケージングの部分で差異化のしようがない。これに対して、Linuxの実体はカーネルしか存在せず、あちこちからソフトウェアを寄せ集めて、ひとつのパッケージとしてまとめることに付加価値が生まれるわけです(BSDの系列には実際には複数のOSがありますが、これはLinuxディストリビューションとは異なり、全く別のものが複数あり、それぞれがモノリシックなパッケージとなっています)。これに保証などをつけることで商品になる。この部分にディストリビューターたちが競争しあうという状況を生む余地があって、これがオープンソースのビジネスモデルとして成立した背景として重要だと思うんです。

 こうしたシステムのアーキテクチャとビジネスとの関係についての議論はなかったと思うので補足させていただいたということです。

東:

 ありがとうございました。

 ではつぎのかた。

坪田知己(慶應義塾大学大学院):

 それでは私もよろしいでしょうか(笑)。村上さんの議論を受けてコメントしたいのですが、ここで議論されていることにはある種の特殊性があって、後世にこうした議論を通用させるためにちょっと視点を上げて考えてみたいということなんです。というのは、世の中全体が規律訓練型から環境管理型権力に移行しているというのがこの研究会の大前提だと思うんですが、これまでなぜ規律訓練型が採用されていたかといえば、これは国家権力というだけでなく、資本主義がこの規律訓練型権力を要請したのではないか。たとえば機械化を経て大規模生産のモデルになると、生産手段や生産設備の規模も巨大化する。そこで労働者をどう統制するかといえば、規律訓練型でなければできなかったわけです。しかしこうした世界と、今日の議論の対象となっていたソフトウェア生産者とプログラマーたちの世界というのは、大きく隔たっていると思うんですね。というのも、資本主義がモノ経済から知識経済に移行しつつあり、その最先端がLinuxオープンソースの世界だからというわけです。

 ここで問題になるのが、参加のアサインの問題ではないか。これは村上さんもおっしゃっていたことと通じると思うんですが、これまでは巨大なシステムを握っていた独占権力が、お前は参加してもよい、お前は知恵を出してもいい、お前は設計してもいいとアサインする権力を持っていた。しかし知識経済においては、生産のモチベーションは「面白さ」に向かうわけです。そこでいくらお金を出してもアサインしても働かないという人間が出てくる。そこで、社会全体を考えたとき、生産の原動力をどこに規定し、経済的なエンジンをどこに置くのかを考えないといけないわけです。こうしたアサインをめぐる問題が出てくると、おそらく規律訓練型権力と環境管理型権力のバランスが最も重要なポイントになると思うんですね。

 またオープンソースがビジネスになったといっても、結局のところ資本主義経済においては、資本家がリスクをとっているわけです。お金をとって回収しないといけないという部分は変わらず、ここにボトルネックが存在するという意味では変わっていない。こうした資本主義のメカニズムに睨みをきかせつつ、今日の議論になったような新しいオープンソース的な組織運営や合意形成を議論するという両輪を意識してほしいなと思います。

東:

 ありがとうございます。

 時間がたいへん超過しているのですが、最後におひとりだけお願いします。

江島健太郎(インフォテリア):

 重要な論点として、「特定の価値に偏ることなくルールを記述するためのルールは設計可能か」というお話に何度か言及されていたかと思うんですが、私はこの点について大いに疑問なのですね。というのも、設計を行うのが人間である以上、暗黙的ないし明示的に設計者の価値が入り込むことは避けられないし、そもそもメタ価値は恣意的に作り出せるものではなくて、成熟とともに発見されるものだと思うからです。

 ソフトウェア業界でたびたび繰り返されてきた過ちのひとつに、上流工程でメタモデルが記述できれば下層のコードは自動生成できるから、いつかプログラマーが不要になるとする考え方があるんです。現在なら MDA(= Model-Driven Architecture) と呼ばれているのがそれにあたるんですけど、この手のアプローチがうまくいった試しがない。当たり前なんですけど、地図は土地そのものではないし、楽譜が音楽そのものでないのと同じで、捨象から具象は生まれないんです。

 アメリカ合衆国オープンソースも様々な宗教や思想が混交するメタルールのショウケースなわけですが、今回の議論にもあったように結果論であって再現性がない。アドホックな価値の衝突と調停の繰り返しから生まれた最大公約数が、暗黙のうちにあるいは記号として共有されればそれがメタルールなのであって、その逆は机上の空論だと思います。

 問題は、情報技術がコミュニケーションにおける時間空間の足かせから我々を解放したがために、これまで隔離されてきたことで隠蔽されていた、擦り合わない価値という根っこの部分が改めて浮き彫りになってきたというだけのことではないでしょうか。こうした状況を考えると、まずはあるべき理念や価値そのものを議論することを避けて通れないと思いますがいかがでしょうか。

東:

 ありがとうございます。

 お三方とも、質問というよりコメントでした。時間がありませんので個別にお答えすることができず残念ですが、それぞれ、今後の議論にとって重要な示唆をいただけたと思います。

 それでは、今日の討議を終了したいと思います。ありがとうございました。

*1:註:以下の記事を参照のこと。→井田昌之「Emacs 解剖学 第一回:TECO -- Emacsのみなもと

*2:註:以下の記事を参照のこと。→井田昌之「 Emacs解剖学 第三回Gosling 登場

*3:註:以下の解説を参照のこと。→IT用語辞典 e-Words : モノリシックカーネルとは 【monolithic kernel】 ─ 意味・解説

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