改変の連鎖とニコニコパブリックライセンス

オープンソースの歴史を考える上で、GPLというライセンス文書の存在は極めて重要だと思います。そのGPLオープンソースに果たした役割と、「初音ミク」現象においてGPLに相当するものは何か(仮称「ニコニコパブリックライセンス」)ということを考えてみました。

オープンソースの歴史を解説した良エントリがあったので、ついでにその紹介もしながら、ちょっとそのあたりの解説も試みてみました(その分長文になってしまいました)。

初音ミク」と「初音ミクのようなもの」

1つ文脈整理として考えたいのは、
 
 初音ミク なのか 初音ミクのようなもの” なのか
 
という点です。(「バールのようなもの」みたいなお話ですみませんが。)
 
たとえば、
 
初音ミクすごい! 歌手の仕事がどんどん減っていくかも!
 
というお話と、
 
初音ミクで作った曲はレベルが低い! あんなのオタ受けだけ!
 
というお話は、前者は ”初音ミクのようなもの” の話をしており、
後者は ”初音ミク” そのもののお話をしています。いわずもがな、
 
1、”初音ミク
 今出荷されているクリプトンのソフト「初音ミク
 
2、”初音ミクのようなもの”
 今後登場するであろうVOCALOID製品およびそのエンジンとなる
 音声合成技術の進化の行く先
 
のことです。

これは、重要なポイントで、確かに私は「初音ミクのようなもの」のことを指して「初音ミク」と言っているので、そこが議論のすれ違う所だと思います。

しかし、なぜそういう言い方をするかと言えば、オープンソース的なものを語る上では、この考え方が本質的に欠かせないからです。

Linuxとは「Linuxのようなもの」の総称であって、固定して解剖され得るLinuxというものは存在していません。そういうふうにLinuxを見たら、Linuxという言葉で表現されるものの一番重要な性質が抜け落ちてしまいます。

随分前に書いた文章ですが、こんなことを書いたことがあります。

このユニックスが改良されていく過程で、 プログラムの開発の方法の常識も変化していった。 文書作成にたとえると、添削を重視する考え方が主流になった。 従来は、1000行の文書を作るなら少なくとも990行の文書を作ってから添削を行なった。 テニオハを直したり、句読点の抜けを直すような作業を行ない1000行の文書が完成する。 つまり、添削は補助的な作業だった。

しかし、ユニックスは改良されながら進化した。 1000行の文書を大勢の人が少しづつ添削して10000行の文書ができたようなものだ。 人数をかけてこういうやり方をすると、 非常に高性能なプログラムができることがわかってきた。

この発想は企業の中には無いし、なかなか企業には受けいれられない。 添削するためには、ソースプログラムというプログラムの中身を外部に公開しなくてはならないからだ。 実際、ユニックスは、ある所まで進化してからソースプログラムの公開を取りやめてしまった。 ソースプログラムという中身を見せると商品にできないからだ。 それによって外部の者には添削できない普通のソフトになってしまった。

しかし、大勢で添削しながら開発するというユニックスの開発スタイルは多くのプログラマに支持された。 この方法がいろいろな形で試みられ、 最終的に、誰でも添削して使える新しいユニックスができあがった。 それがリナックスである。

初音ミクオープンソースと比較して分析した次の文章も、連鎖的な改善の過程に注目しています。

初音ミク現象」の一連の創作活動は、個々人が単独で行っているものではない。人の創作をベースに、次の創作がうまれる。「オマージュ」「リスペクト」といったものではない。ある意味では「改善」であり、あるいみでは「盗用」であろう。しかし誰も「盗用」だとして問題にはしない。ここでは「共有」という考えをベースにした「創作の場」「創作の市場」がうまれている。(「ウィキノミクス」の言葉通りだろう)

元ネタを作ったヤツも偉いけど、それを組み合わせて、ちょっとだけ自分なりの創作を加えるだけで、すごいものができる。みんな結果を見て評価する。その創作が「ちょっとだけ」であることをあげつらって非難するひとなんて見たこと無い。「結果がすべて」で評価される土壌がある。

Linuxのようなもの」における「改変の連鎖」

次のエントリも、ほぼ同じ趣旨ですが、オープンソースの歴史が丁寧に解説されていますので、そのあたりに詳しくない方には特に参考になるかと思います。


こちらでは、多くのオープンソースプロジェクトの中で、Linux(カーネルというOSの本体部分)に見られる際だった特色として、「改変を歓迎する姿勢」を強調しています。

中でもLinuxは、ちょっと特別でした。

リーナス・トーバルズ氏が書いたLinuxは、やはり大学生が一人で書いたものだけあって、実を言うとそれほどいいものでもなく、上級者でなくてもあちこちほつれが見える、ずさんなものだったのです。

しかしそれがかえってLinuxを特別なものにしました。

ひどいできのLinuxをインターネットで見た世界中の凄腕プログラマーたちは、Linuxに対して「そこはそうじゃない」「ここはこうやるんだ」「あれが足りないじゃないか、いいよ俺が書く」といった感じで、いっせいに修正や改造を施しはじめたのです。

そうした変更をトーバルズ氏は、ありがたく頂戴し、どんどん次のバージョンのLinuxに取りこんでリリースしていきました。

それまでのソフトウェア開発というのは、少人数で開発するというのがセオリーで、僧侶が伽藍にこもるようにして書くのが普通でした。

ところがLinuxは、まるでバザールのように、インターネットを通して大人数でわいわいがやがやと開発を進めている。インターネットの発達により、Linuxの開発者総数は従来では考えられない程の人数になっていました。

そんなスタイルでソフトウェア開発ができるわけがない、みんなそう思ってました。

ところが、Linuxはどんどん洗練されていきます。世界中の凄腕プログラマーたちがいっせいに修正や改造を加え、みるみるうちに一級品のソフトウェアになっていったのです。

「いっせいに修正や改造」の具体的な例として、非常に技術的なものですがちょうどよい文書がありました。

これは、ある学生さんが「冬休み自由研究」として、Linuxの改善に取り組んだレポートです。スケジューラというOSの中でも特に重要な部分について、Linuxには、ひとつの欠陥があることを指摘し、それを実証した上で、Linuxの中身を改善して「もっとよい自分バージョンのLinux」を作った過程がまとめられています。

この研究の内容そのものが本家に提案されたという記述はありませんが、世界中でこれと同じようなことがたくさん行なわれています。そして、その改良の結果が中心人物のリナス・トーバルズ氏に届けられていて、その集積がLinuxなのです。

だから、あるプロジェクトの為に使用するOSとして、Linuxを使用するか他のものを使用するかという判断は、常に難しいものになります。

たとえば、上記の文書で欠陥があると指摘されているスケジューラという要素の機能が重要だったとしましょう*1。もし、ある時点のLinuxと別のOSを比較して、上記のような分析をしたら、Linuxの方が劣っているという結論になります。

しかし、たいていのプロジェクトにおいてOSというのは数年単位で使用されて、同一OS内でのバージョンアップは可能でも、途中で変更することは困難です。ですから、こういう判断は長期的に行なう必要があります。現状のLinuxはスケジューラの機能が劣っていても、そのプロジェクトの開発が終わり実運用に入る頃には、その問題は直ってしまっているかもしれません。

実際、典型的な使用法で発生する問題については、現在も多くの改良が行なわれています。これもかなり専門的なものですが、Linuxの中核部分に関して具体的に検討されている改良について解説した文章がありました。

これは、高い負荷の場合に発生する問題に対して提案されている、いくつかの解決策を比較しているものです。こういう点で議論があるということは、従来より本格的な用途でLinuxが使用されるケースが増えていることを示していると思いますが、おそらく、各機能ごとに多数のこういう提案が同時進行で進んでいるのだと思います。

また、自分たちが分析の過程で何らかの問題を発見したら、それを開発者にフィードバックすれば、誰かがその点について改良してくれるかもしれません。「おまえが作っているソフトは欠陥品だ」などと言うと嫌われるのではないかと思うでしょうが、オープンソースの開発者は、一般的にはその指摘の内容が技術的に正しければ、欠陥の指摘はむしろ歓迎されます。

ソフトウエア技術者が「Linuxを採用するかどうか」の時に、検討する対象は特定の時点のLinuxではなくて、常に改良され進歩し続ける未来のLinuxとそのコミュニティの性質なのです。

冒頭のckomさんの言葉を借りれば、「今後登場するであろうLinuxの進化の行く先」と自分たちのニーズを比較対象するわけです。もちろん、今すぐに絶対必要で待てない機能もありますから、現状のあるがままのLinuxをそのまま調査、検討した上でのことですが、全体としては、そういう未来を含めた「Linuxのようなもの」のことを「Linux」という言葉で呼び、それについて検討するのです。それが無意識的な思考の癖となっているので、ついつい「初音ミクのようなもの」のことを「初音ミク」と呼んでしまうわけです。

「改変の連鎖」を保証するライセンスとコミュニティ

だから、このような見方が有効かどうか判断する上で、重要なのは「初音ミクのようなもの」に関して「改変の集積と連鎖」が起きているかどうか、継続するかどうかだと思います。

その点についてまず重要なのは、「初音ミク現象とハッカー経済学」で指摘されているインセンティブ(動機づけ)の問題ですが、私はそれと同等に「改変した作業の結果を安心して配布できる仕組み」が重要だと思います。

私も、ささやかなものですが、オープンソースソフトウエアを開発し配布したことがあります。その時に、配布をどのようにしたら安全であるかということについて、具体的な方法が既に存在しているということに、大きなありがたみを感じました。

オープンソースにおいて、ライセンス(配布条件)の問題は重要ですが、私は(こんな文章をせっせと書くくせに)これが非常に苦手です。法律のからむ話になるので、勉強してはいるのですが、どうにもよくわからない。そういう私にとっては、なんだかよくわからないけどGPLという文書を自分の公開するソフトに混ぜておけば良いということが非常にありがたかった。私にとってGPLとは「あらゆるトラブルから守ってくれる災難よけのおまじない」でした。

GPLとは、公開するソフトを第三者が使う場合に、「こういう条件を守れば使っていいよ」ということを書いた文書です。背後に、ソフトをタダで公開することに人生を賭けているリチャード・ストールマンという人とその取り巻きがいるので、GPLを付けて公開しておけば、トラブルが起きた時に、ストールマン先生が飛んできて立ちどころに解決してくれます。と言ったら言いすぎですが、そういう人たちが集まる[slashdot.jp:titleスラッシュドット]というコミュニティが日本にもありますので、何か問題が起きたら、ここらあたりで相談すれば、味方になってくれる人がきっと出てくるだろうと思っていました。

そういう意味で、GPLというライセンスの存在は、非常にありがたかったです。

これは、GPLというライセンスのとらえ方としては異端(というよりほとんど間違い)ですが、GPLというライセンスを作るに至ったコミュニティの存在を含めて言えば、そんなに的外れでもないと思います。GPLがあったことで、法律について勉強したり事例を調べたりしないで、ほとんど何も考えずに公開することができるからです。

一般に、プログラマは、自分の成果物を配布する強い動機は持っていません。「これで有名になってやる」とか「これで世界をひっくりかえしてやる」とか思ってソフトウエアをを公開するプログラマはほとんどいないと思います。「どっちでもいいけど、せっかく作ったから人に見せたいな」くらいの弱い動機でしかないのです。意欲は強くないけど、簡単に配布できるなら配布しようと思うプログラマはたくさんいます。

そういう弱い動機で配布するプログラマにとって、「配布したらいいことがある可能性」は、あまり重要ではありません。配布するかしまいこんでおくかの分かれ目は、「配布してもトラブルになることがない保証」です。自分のソフトウエアを公開して、お金が入ってくることは期待しないけど、お金を取られてしまうのは嫌だ、それは当然のことですが、これを盗作して勝手に販売した上に「俺が本家だ俺が作者だ俺が本物でおまえの方が盗作だ金よこせ」とかやる連中もいないわけじゃないし、そういう人たちは法律を駆使するので、「タダで公開するのだから無防備でよい」とは言えないのです。

「改変した作業の結果を安心して配布できる仕組み」として、ライセンスに関する議論の蓄積と、その成果としての、GPLBSDというライセンスのお手本が重要だと思います。そして、それらに実効性を持たせていたのが、それを支えるコミュニティの存在だと思います。

ニコニコパブリックライセンス

おそらく、「初音ミク」というかニコニコ動画を巡るコミュティについても、これと同じことが言えるでしょう。

「職人」に大半は、作品を公開するにあたり「弱い動機」しか持っていません。その人たちが気にするのは、何か見返りがあるかどうかではなくて、公開によってトラブルが起きないかだと思います。それは、ソフトウエアより著作権的にグレーな部分を含むMAD動画等ではより切実な問題でしょう。

現在、多くの動画が公開されている理由の一つは、「ニコニコに投稿しておけば、理不尽な横槍からは守られる」という安心感ではないでしょうか。何しろ、背後には「敵にすると恐しいが味方にすると頼りない」2ちゃんねらの大集団が控えています。法律的にグレーであっても、2ちゃんねらの暗黙の倫理基準に照らしあわせて正当性が認められれば、何かトラブルがあっても炎上するのは相手の方だ、そういう安心感があると思います。

私は、GPLの文面は理解していませんでしたが、それを取り巻くコミュニティの独特の倫理についてはある程度理解しており、それを信頼していました。同じように「職人」たちも、ニコニコ動画の倫理基準は読んだことは無い(だってまだ成文化されてない)けど、それを取り巻くコミュティが暗黙の倫理基準を持っていることを感じ、そのコミュニティを信頼しているのだと思います。

文学的に言えば、まだ明文化されてない「ニコニコパブリックライセンス」というものが生まれつつあり、同時にその回りにコミュニティが形成されているのです。

GPLは、成文化された「法」に対する信頼の深いアメリカで生まれたので、テキストの形を取りましたが、日本で生まれた「ニコニコパブリックライセンス」は、テキストでなく空気として生まれ空気のまま機能し始めているのだと思います。誰もそんなものは読んだことがないけど、それはもう存在しているのです。

ニコニコパブリックライセンスは空気のまま暴走し続けるのかクリエイティブコモンズに着地するのか

おそらく、ニコニコ動画を巡るコミュニティが暗黙の倫理基準を持っているという観点には多くの人が同意すると思いますが、その暗黙の倫理基準が明文化された現状の法律と不整合であるということにも大半の人が同意するでしょう。

ここが、中核にあるライセンスが成文化されていて、だからこそ、その法律的な解釈を巡って法律の専門家が検証した上で、社会的な運動として認知されてきたオープンソースと一番違う所でしょう。

実は、まさにここに書いたような「ニコニコパブリックライセンス」に相当するもの、ソフトウエアでなくコンテンツに対して「改変の連鎖」を安心して行なう為のライセンスとそれを広めるクリエイティブ・コモンズという活動があります。「ニコニコパブリックライセンス」が成文化されるとしたら、その文面はこれに近いものになると思います。

しかし、私は、それが必ずしもハッピーエンドになるとは思えません。日本では、法律というのは、誰に対しても平等に作用し、誰もが利害の反する人たちとの調整に安心して使えるインフラとして確立していません。テキストになった法律は不平等に作用するし、その使い道は、条文や解釈等の法的システムの外で決定されることが、残念ながら多いと思います。

むしろ、そのような事態を避ける為に、ニコニコ動画は、中心に確立されたテキストを持たない空気の状態のまま、倫理基準とコミュニティの輪を広げているのだと思います。

もし、現状で「ニコニコパブリックライセンス」が成文化されたら、「職人」さんたちは今より安心して投稿できるでしょうか。そんなものが発表されたら、それが法律に即していようが反していようが、コミュニティの「空気」がそれをどう判断するかを待つでしょう。それは法律に詳しい人もそうでない人も同じだと思います。

この想像が当たっているとしたら、日本ではテキスト(化された法律)に対する基本的信頼が薄いということを示しているのだと思いますが、それは、実際には日本の社会で生きる為の処世術として必要なことでしょう。

だから、「ニコニコパブリックライセンス」の成文化を要請する前に、テキスト(法)の支配に対する信任を取り戻すことが必要で、この順番を間違ってはいけないと思います。つまり、「空気」から「法」への禅譲を促すような手順が欠かせないということです。

もちろん、中心にテキストを持たない「空気」は常に暴走する気があって危険なものですが、だからと言って、順番を変えて「法」が「空気」から支配権を簒奪することでは、テキスト(法)の支配に対する信頼は得られません。危険性があるなら、その分だけ禅譲を急がせるべきだと思います。

まとめ

  • 初音ミクオープンソースも、可能性やコミュニティを含めた「○○のようなもの」という視点が重要
  • 「改変の連鎖、集積」を可能にするのはライセンスとコミュニティ
  • ニコニコとオープンソースの違いは、中心にあるライセンスが「空気」であるか成文化されているか
  • 「ニコニコパブリックライセンス」を成文化する前に、「テキストへの信頼」を構築すべき

(追記)

RMSは「タダ」じゃなくて「自由」に命を書けてるんですよね。このコンテキストの中でfree as beerで言っちゃうのはもったいないかと。

いや、これはまったくその通り。

ストールマンの言う free software は「無料のソフト」ではなく「(利用、改変、再配布の)自由なソフト」でした。彼の名前を出して「タダ」という言葉を使ったのは大チョンボです。

もちろん知らなかったわけじゃないんだけど、つくづく自分は粗雑な人間でツッコミの入らない所では発言しちゃいけない人間だと思いました。

*1:この指摘そのものは、非常に稀なケースでしか発生しない問題を扱っていて、実用上はほとんど問題にはならないと思いますが、Linuxのスケジューラについては他にもいろいろ問題が指摘されています