ハッカーの系譜⑨オープンソースの巨人たち (11) 「伽藍とバザール」とネットスケープの決断

January 13, 2017 12:00
by 牧野武文

「伽藍とバザール」に心打たれたネットスケープ

オープンソース戦略をするきっかけになったのが、エリック・レイモンドのエッセイ「伽藍とバザール」だった。レイモンドは、フリーウェアやLinuxに関わってきたプログラマー。それまでOSのような重要なソフトウェアは、厳密な設計のもと、閉鎖され組織だった集団でなければ開発できないと考えられていた。レイモンドは、これを大聖堂のような伽藍（カセドラル）方式の開発と呼ぶ（誰かが雑な仕事をすると、伽藍は崩れてしまう）。一方で、Linuxの開発手法は、種種雑多な人が関わり、さまざまな仕事が同時並行で流れている。それはまるでバザールのようだ。バザール方式でなぜ精密なLinuxのようなOSが開発できたのか。それを論考したものが「伽藍とバザール」だ。

レイモンドは、リーナスの功績を「Linuxのカーネル構築ではなく、開発モデルを発明したことにある」という。最初の核になる部分を開発したのはもちろんリーナスだが、そこから先はネット上の共同開発者たちにどんどんまかせてしまった。「僕は基本的に怠け者なので、他人がしてくれた作業を自分の仕事だと言うのが好きなんだ」とリーナスは謙遜する。

オープンソース開発でもっとも基本になる原理は、「充分な数の目玉があれば、どんなバグも深刻ではない」というものだ。多くの共同開発者が関わり、ユーザーの数が充分に大きれば、バグは必ず見つかるし、それだけでなく、どうすればフィックスできるかも誰かが提案し、場合によっては修正したソースコードを管理者に送ってくれる。

ただし、最初からバザール方式ではうまくプロジェクトが進んでいかない。核になる人物が、将来なにか素晴らしいものになりそうだという見込みを示す必要がある。リーナスは、ここが優れていた。リーナスが最初に作ったLinuxの原型は、インタフェースはUNIXを真似たものであり、カーネルのコードはパソコン用UNIXであるMinixを大いに参考にしていた。しかし、オープンソースに近い形態での公開であったため、人の手が複数加われば、パソコンでもUNIXのような自由な世界が拓けるのではないかと、多くの人が期待した。

オープンソースこそ逆転の一手だ！

ネットスケープ内での議論は、急速にオープンソース化に傾いていった。エンジニアだけでなく、マーケティング、経営の人間まで「伽藍とバザール」を読み、感銘を受けていたからだ。

ネットスケープは、ナビゲーターを「タダ同然」で公開をした。それは、それまでのソフトウェア業界の常識ではありえない無謀な試みだった。しかし、それがバザール方式に近い開発体制をとることができるようになり、ネットスケープは急成長をした。これ以来、インターネット関連のソフトウェアは、ネットスケープを模倣し、「タダ同然」で公開し、マネタイズはそれから考えるというのが常識になっていった。だったら、前回と同じことをソースコードで試してみてはどうなのか。マイクロソフトに押されっぱなしの現状を打開して、もう一度ネットスケープは成長できるのではないか。

最終決定の会議では、「公開すべきか否か」という議論はほとんどされなくなった。みな「いつ公開すべきか」を議論していたという。

簡単ではないオープンソースへの準備

この「いつ公開すべきか」を決定するのはきわめて重要だった。もちろん、早ければ早いほどいい。しかし、それまでに、やらなければいけないことが山のようにあった。その作業スケジュールを考えなければならない。

いちばんの問題は、コミュニケーターの中には他社製のモジュールが75ヵ所も組みこまれていたことだ。ネットスケープは自社で開発したコードに関しては、オープンにすることはできるが、他社の知的財産まで勝手に公開することはできない。そこで、この75の他社製モジュールすべてについて、権利者のところに出向き、オープンソースという考え方に同意をしてもらうように説得を行った。

しかし、すべてがオープンソース化に同意するわけではない。各社、さまざまな事情があるので、その他に2つの選択肢を用意した。ひとつはバイナリ形式でのみコミュニケーターに組みこみ、ソースコードは公開しないというもの。もうひとつは、コードを引き上げてしまうという選択肢だ。この場合、ネットスケープ内で、それを代替するコードを書かなければならない。

その中でももっとも難航したのが、暗号化モジュールだった。米政府はもちろんオープンソース化に同意などしないし、バイナリ形式でのみの組みこみも拒否をした。それだけでなく、暗号化モジュールを呼び出しているコミュニケーターのソース部分も書き直すべきだと主張をした。そこから、暗号化モジュールの内容が類推できてしまう可能性がゼロとはいえないからだった。この書き直しを担当するチームは、緊密にNSAと連絡をとって、NSAの方式に準拠しているかどうかの確認をとらなければならなかった。

ライセンス方式が最大の障壁

もうひとつはライセンスの問題だった。コミュニケーターは、オープンソースにするといっても、知的所有権を放棄してしまうわけではない。所有権はあくまでもネットスケープ社がもちながら、自由に改変を許すというものだった。では、外部のボランティアエンジニアがなんらかの改変をした場合、その改変部分も自動的にネットスケープ社の知的財産になってしまうのだろうか。それは筋が通らない。

そこでネットスケープ社に、リーナス・トーバルズ、エリック・レイモンド、ティム・オライリーなどが集まって、コミュニケーターのライセンスをどのような形態にすべきかが話し合われた。

このようなオープンソースのライセンスには、BSDライセンスとGNUライセンスなどがある。BSDライセンスは、無保証であることと著作権表示を明記してあれば自由に再配布、改変できるというものだ。しかし、このライセンスだと、コードを改変した人の権利がまったく守られない。たとえば、コミュニケーターのバグを発見した人が、その部分のソースコードを修正してくれたとしても、再配布をするときは、ネットスケープ社に著作権がある旨を明記しなければならない。バグフィックスに貢献してくれた人の功績は、形式的には、すべて原著作者であるネットスケープ社のものになってしまう。二次配布をするときは、あくまでもネットスケープの著作物としておこなう。

では、GNUライセンス（GPL＝GNU一般公衆利用許諾）ではどうか。GPLでは、原著作者という考え方がなくなり、パブリックドメインに近くなる。ただし、GPLが違うのは、再配布をするときも自動的にGPLにライセンスされるということだ。つまり、著作権をGPLという架空の存在に帰属させ、なおかつGPLから外れることを禁止することで、心ない人が勝手に権利主張することができないようにしている。

しかしこの場合、問題になるのは、コミュニケーターに使われている75社のサードパーティー製コードだ。コミュニケーターをGPLにライセンスしてしまうと、この75社のコードも自動的にGPLにライセンスされてしまう。それで納得するソフトハウスもあるかもしれないが、商用コードをGPLライセンスされてしまうことを問題視するソフトハウスもあるだろう。特に同じコードを他の市販する製品にも使っている場合、権利関係がおかしなことになってくる。事実、ネットスケープ自身も、コミュケーターのコードの一部を、サーバー製品などに使っている。すると、商用サーバー製品も自動的にGPLライセンスになりかねないのだ。

ライセンス方式もオープン議論で決定

ネットスケープは、独自のライセンス方式を考える必要があったが、これすらオープンソース方式で構築しようとした。コミュニケーターについては、ほぼGPLと同じ方式のライセンスを適用するが、ネットスケープ社がコミュニケーターのコードの一部を、他の商用製品に流用している場合は、その製品にオープンなライセンスを適用するかどうかは、ネットスケープ社が決められるという特権を設定した。この草案をネットで公開したところ、炎上に近い批判を受けることになった。このような特権を与えてしまうと、ネットスケープ社に悪意があった場合、ネットコミュニティーの貢献によりコミュニケーターが優れた製品になったときに、ネットスケープ社はその成果を使って、ビジネスができてしまうことになる。

1ヵ月に渡る公開議論で、最終的にMPL（モジラ公衆利用許諾）ができあがっていった。これは画期的なものだった。サードパーティーなどが提供しているコード部分は、そのサードパーティ独自のライセンスが適用され、その他のコード部分にはMPLが適用されるというものだった。

また、コミュニケーターが改変された場合、修正バージョンに取り込まれた改変は修正と見なされ、MPLで保護される。しかし、修正バージョンに取りこまれない大きな改変については、その改変をおこなった者が自分の好きなライセンスを設定できる。つまり、コミュニケーターをベースに、まったく違ったソフトウェアを生みだして、それを販売することもできるのだ。簡単に言えば、バグの修正に対してはMPLライセンスに統合されてしまい、修正者は権利主張をすることはできないが、新たな機能を作成、追加した場合は、自分の権利を主張できる。

つまり、パブリックドメインを可能にしようとしたGPLと一般的な著作権の考え方をモザイクのように組み合わせることを可能にしたライセンス方式だった。これで、オープンソースと商用ソフトウェアを組み合わせることが可能になった。
　
（その12に続く）