オープンソース・ビジネスについて考える

オープンソース・プロジェクトの抱える矛盾

2000年代のソフトウェア開発の有力なモデルとして、オープンソースがあります。ソフトウェアは、ハードウェアと違って生産・流通コストが殆ど掛かりません。また、複製されても減価することなく、複製物とオリジナルがまったく同一の価値を持ちます。このため、開発者とエンドユーザがダイレクトに、生産物をやりとりすることが可能になります。また、既にできているものを複製または流用して新しいものを作り出すということができます。従って、ソフトウェア開発においてオープンソース方式は有力な開発モデルであることは間違いありません。

一方において、オープンソースは、ビジネス・モデルとしては大きな矛盾も抱えています。

どんなプロジェクトでも成功するには大義名分が必要です。そして、商用ソフトウェアのメーカは、私利私欲を追及していると見られがちです。この点、オープンソースのプロジェクトは、利己的な利益と離れて、公益を追求すると言う大義名分を付けやすいように思います。

しかし、実際は、大義名分だけでは持ちこたえることができないのは、社会人であれば誰にでも分かると思います。つまり、プロジェクトを運営するのは資金が必要で、特にソフトウェア開発の主役であるプログラム開発者の人件費を稼ぐ方法が必要です。

オープンソースのプロジェクトで、恐らく一番大きな問題は、開発者に資金が還流しないことです。

商用ソフトウェアの場合は、ソースコードの権利と、その生成物であるオブジェクトの権利を占有し、顧客に使用権を提供すると同時に見返りに対価を得るというビジネスモデルが成り立ちます。

しかし、オープンソースでは、ソースコードを誰でも入手できます。結果的にオブジェクトを誰でも入手できることになります。誰でも入手して使えることになれば、当然使用権を提供して対価を得ることは難しくなります。ありていに言えば、誰も使用料を払わなくなるということです。従ってプログラムの使用料を得るのは難しいことになります。

繰り返しますが、どのようなものであれ、開発には必ずお金が掛かります。しかし、開発に使った資金がより大きな価値となって回収できる見込みがなければ、新しいプロジェクトに投資する人はいないでしょう。大きなプロジェクトを起こすには、ベンチャキャピタルという仕組みもありますが、ベンチャキャピタルは投資が回収できる見込みがなければ決して投資しないでしょう。

この点、米英でオープンソース方式で開発するソフトウェア会社にベンチャキャピタルが出資するケースが増えているのは注目されます。

政府のような公的機関の場合は、資金の回収ということはあまり考えないかもしれませんが、国民の汗と涙の結晶である税金を使う以上は、ベンチャキャピタルなどよりは遥かに厳しい投資判断基準が必要なはずです。

最近のオープンソース・プロジェクトは、コンピュータ・メーカやシステム・インテグレータに在籍する開発者がフルタイムで働くものが多いですが、その場合、プログラマが在籍する企業にとってオープンソース・プロジェクトが価値があるものでなければなりません。

草の根オープンソース・プロジェクトでは開発者が手弁当で働くことになります。この場合、苦労した開発者が報われないような仕組みでは、プロジェクトを長期にわたって活発に継続することはできないでしょう。

このようなことを考えると、オープンソース・プロジェクトを起こすにあたって、ビジネスモデルを十分に検討することが最も大事といえるでしょう。このためのひとつの手段は、成功したプロジェクトを研究することです。

著作権法

著作権法については、日本国内では日本の著作権法が適用されます。
海外では、当該の国の著作権法で保護されることになると思います。

国際的には、万国著作権条約加盟国では、各国内の著作権法を万国著作権条約の規定に合わせて変更しています。
日本の場合：万国著作権条約の実施に伴う著作権法の特例に関する法律

プログラムは著作権法の対象になると具体的に例示されています。
・第十条　（著作物の例示）　九項　プログラムの著作物

職務著作物としてのプログラムの著作者は、原則としてその人が属する法人になります。
・第十五条の2　職務上作成する著作物の著作者

著作者は幾つかの権利を持ちます。プログラムに関してその主なものは、
・第十八条　公表権
・第十九条　氏名表示権
・第二十条　同一性保持権　　但し、動作しないプログラムを動作するように改変することは、同一性保持権の適用対象外
・第二十一条　複製権　これは著作者の専有です。
・第二十六条の二　譲渡権　著作者は複製による譲渡権を専有します。
・第二十八条　二次的著作物の利用に関する原著作者の権利　原著作者は二次的著作物にも権利を持ちます。

一方、著作権には制限があります。
・第四十七条の二　プログラムの著作物の複製物の所有者は、利用する必要と認められる限度で複製・翻案を行うことができます。

著作者の権利の行使
・第六十三条　著作権者は著作物の利用を許諾できます。

権利侵害
・第百十二条　著作者は差止請求権をもつ
・第百十四条　損害の額の推定

罰則
・著作権違反については、段階に応じて、罰則（懲役または罰金）規定があります。

このように、国家の法律では著作権者の権利を一部の制限を除いて守っていることをまず理解しなければなりません。これは著作権者の権利を守ることで、創作活動が活発になり、文化の発展につながるということが大義名分です。

ライセンス契約と使用許諾契約

オープンソースに限らず、ソフトウェアの使用許諾契約（ライセンス契約）は、著作権法で著作者に与えられた権利に基づき、著作権者が利用者に対して、一定の条件でソフトウェア著作物の使用を許諾するものです。

プログラムの使用許諾を受ける側は、著作権者から提示された条件を承認して契約を結ぶわけです。従って、約束としてそれを守らねばならないということになります。

著作権者の権利の主なものに、複製権（第二十一条）と利用許諾権（第六十三条）と２種類の権利があります。これをどのように扱うかで、異なるビジネス・モデルができそうです。

複製権と利用許諾権の行使方法はふた通り考えられます。まず、複製権と利用許諾権を同一の主体が行使するもの。

プログラム利用の一番典型的な例は、エンドユーザ（企業・個人）が、ソフトウェアの著作権者から複製物を入手して、自己のコンピュータの上でそのプログラムを動作して利用するものです（図１）。

この場合、プログラムの複製権・使用許諾権を行使しているのは著作権者（またはその許可を得た者）のみとなります。

図1　自己のコンピュータでプログラムを動かして利用

次いで、複製権と利用許諾権を異なる主体が行使するものです。

ところが、次の図２のように、プログラムは公衆または公共のコンピュータ上で動作させ、エンドユーザはその機能のみを利用する場合があります。例えば、いわゆるASP（Application Service Provider）の利用形態がこれに該当します。この場合、複製する行為と、利用許諾する行為の主体が別になっています。

図２　公衆用コンピュータでプログラムを動かして利用

すなわち、ASP形態の場合は、エンドユーザとプログラムの使用契約を交わすのは、ASP(事業者)となります。しかし、ASP事業者は（著作権者でない限り）、使用許諾を交わす権利はもっていません。いま、こうして改めて見ますと、ASP事業者は、著作権者と契約を交わして、第三者に使用を許諾することができる権利を得る必要があるように思います。

著作権者についての留意事項

著作権法の概略を簡単に説明しましたように、国が定める著作権法が著作権者にいろいろな権利を認めています。

これに関連して、特にオープンソースで少し気になりますのは、著作権者が誰になるかということです。個人でやっている場合は別として、団体、特にネット経由でお互いに協力しながら開発を行う場合、できあがったプログラムの著作権者が誰になるかは自明とは言えないように思います。

もし、特定の組織に著作権を帰属させるのであれば、参加者と組織の間で著作権の帰属についての契約を結んでおかないといけないでしょう。例えば、ApacheのFOPのプロジェクトを見ていますと、SI会社に帰属するプログラマや個人と思われるプログラマが参加しています。しかし、開発者が会社の許可を得て、オープンソースの開発に従事した場合、職務著作物にはあたらないでしょう。ですので著作権の帰属についてきちんと契約を結んでおかないと問題が発生しそうです。

オープンソース

先に進む前に、ここでオープンソースという言葉と、それに相反する商用ライセンス、占有ライセンスについて簡単に検討してみます。

まず、オープンソースという言葉ですが、プログラムのソースコードを公開、共有利用するというのは30年以上前からありました。

私がコンピュータをはじめて使いましたのは1973年ですが、当時、Fortranという言語で多変量解析などのプログラムを書いて、大型コンピュータ（メモリは128KB位から256KB位だったと記憶していますが）で計算しました。

そのプログラムは数式を元にゼロからプログラムを書いたわけではなく、専門書に掲載されていたプログラムや専門の研究所から入手したプログラムリスト（プログラムのプリントアウト）で、他の人の書いたプログラムを読んで、それを元に自分なりに多少修正してプログラムを作ったことの方が多かったと記憶しています。

実際、大きなプログラムをゼロから書くことはあまりなく、90%位は既存のものを使い、仕事に合わせて10%位書き直してということをやっていたと思います。ですからプログラムは（社外だけでなく社外とも）共有するものなんだな、とずっと思っていた位です。

そもそも自分の開発したプログラムのソースコードを占有し、使いたい人に使用権をライセンスするというビジネスの方が比較的新しいビジネスモデルである、といえるかもしれません。

さて、以上の話は個人的な余談として、本題に入ります。

オープンソースという言葉については、いろいろな人が語っていますので、ここではもう語るのはやめて、オープンソース・イニシアティブの言葉を定義しているWebページを示しておきます。

原文(英語)
・Open Source Initiative (OSI)

・The Open Source Definition

日本語訳
・オープンソースの定義（The Open Source Definitionの翻訳）
・オープンソースグループ・ジャパン(日本独自の団体）

占有ライセンス

OSIが定義しているところのオープンソースライセンスをざっくり言いますと、ソースプログラムを公開し、かつ、そのソースプログラムを入手した人に、著作権者と同等の権利を、一定の条件付きで、権利使用料を取らずに許諾するというものです。

そうしますとオープンソースでないライセンスとは、次のようになると思います。
ソースプログラムを公開しないか、あるいは、著作権者のもつ権利の一部を権利使用料をとって許諾する。

以下、この文章では、後者を占有（Proprietary）ライセンスと言いうことにします。

商用ライセンス

次に商用ライセンスという言葉を少し考えて見ます。このブログ（「PDF千夜一夜」）で商用ライセンスという言葉を既に何回か使いましたが、これは英語のWebサイトに頻繁に出てくるCommercial Licenseの訳として使いました。

商用ライセンスは、プログラム著作者のもつ権利を使って何らかのビジネス行為を行うことを意味していると思います。しかし、厳密に言いますと、商用ライセンスはオープンソースと対比するべき言葉ではないように思います。

GPL：GNU General Public License

GNU ProjectのGPLはオープンソースライセンスとして最も有名なものです。GNU Project以外に、さまざまな、オープンソース・プロジェクトが、そのプロジェクトで作成したプログラムを公開する時に、GPLライセンスを採用しています。現在使われているのはGPL Version 2（1991年6月版）です。

・原文
・日本語訳

なお、GPLのV3のドラフトが2006年1月に公開されて大きな論議を呼んでいるようです。
Welcome to GPLv3

GPLの特長はCopyleftというメカニズムです。これは、「誰でもソースコードを修正することができるようにするため、GPLを利用・改変したプログラムを頒布する場合はGPLライセンスで公開しなければならない」ということです。

このため、自分で開発したプログラムにGPLライセンスのオープンソースを結合すると、自分で開発したプログラムを頒布する場合、自分で作成した部分を含めて全てのソースプログラムをGPLライセンスで公開しなければなりません。

GNU ProjectをはじめたのはFree Software Foundation (FSF) のRichard Stallmanです。彼はエッセイCopyleft: Pragmatic Idealismで次の例を挙げています。

GNUのC++コンパイラはMCCが、GNUのCコンパイラを元にして開発したもの。MCCは普通は製品を占有ライセンスで提供している。MCCのC++コンパイラのフロントエンドには新しいファイルが沢山あったが、GNUのCコンパイラとリンクするために、新しいファイルにもGPLが適用された。こうしてMCCはC++コンパイラのフロントエンドを無償で出すことになった。

このようにGPLは感染するライセンスと言われます。GPLで公開されているオープンソースを使って、頒布用のプログラムを開発する時は、GPLは占有ライセンスとは一緒に使えないライセンスであることに注意しなければなりません。

GNU C/C++ コンパイラには例外があります。これらはGPLで公開されています。そして、自分で開発したソースプログラムをGNU C/C++でコンパイルすると、バイナリ・プログラムにコンパイラの標準ライブラリー（すなわちGPLの一部）が結合されてしまいます。そうなると、自分で開発したプログラムをGNU C/C++でコンパイルして頒布すると、自分のソースまで全部公開しなければならないということになりそうです。しかし、これはしなくても問題ありません。標準ライブラリーのソースプログラムのファイルに、標準ライブラリーをリンクしても、実行形式のバイナリはGPL感染から除外されるという例外規定が書かれています（runtime exceptionと言います）。

なお、GPLライセンスが対象とするのは、GPLライセンスで配布されているプログラムを入手して、それを組み込んだり・改変して、それを第三者に頒布する行為です。自分だけで使う分には無論、いくら改変しようが公開する必要はありません。次のGNUのQ&Aをご参照ください。
GPLは、改変されたバージョンのソースコードを公に発表することを要求しますか?

では、GPLライセンスのプログラムを、開発会社が入手して、受託開発で作成するシステムに組み込んで、客先に納品した時はどうなるのでしょうか？

GNUのQ&Aに次のような質問項目があります。
GPLは、私が機密保持契約の下で改変されたバージョンを開発することを許可していますか?

この質問への回答を読むと、客先のために機密保持契約を結んで、GPLライセンスのプログラムを組み込んだシステムを開発して納品しても、それを公開する必要はないように感じます。

但し、このあたりは、私の解釈にすぎませんので、もし、GPLを受託開発のシステムに使うならご自分で判断するか、専門の弁護士と相談してもらいたいと思います。

GPLは、Stallmanの、いわばプログラマ共産主義とでもいうべき思想を反映したもの。これを嫌う人も多いようです。しかし、著作権法に基づく私的契約としては、大変良く考えられた方式です。

GPLがこのように有名になったひとつの理由は、LinuxがGPLライセンスで頒布されていることにあります。では、Linuxの成功はGPLライセンスを採用したことが理由でしょうか？

Linuxの開発過程を研究して、「伽藍とバザール」（The Cathedral and the Bazaar）というオープンソース開発モデルについての有名な論文を発表したEric Raimondは、2005年6月の6th International Free Software Forum で、「もうGPLは必要としない」という基調講演を行ったとのことです。彼はインタビュー（ESR: "We Don't Need the GPL Anymore"）に応えて次のように述べています。

GPLがLinux成功の主要な理由とは思わない。むしろ、それは1991年Linusがソフトウェアの分散開発の正しい仕組みを最初に見つけた人だったからだろう。それ以前は安価なインターネットがなかったのでできなかった。それ以後は、新しいOSのプロジェクトを起こそうという人の多くは、Linuxを改善するのが最小コストの方法だということを発見したのだ。

LGPL：GNU Lesser General Public License

次にLGPLライセンスについて検討してみたいと思います。
LGPLはGNU Lesser General Public Licenseの略語です。
・原文
・日本語訳

これは、主にソフトウェア・ライブラリー（ソフトウェア関数やデータを集めた部品）用に使われるライセンスの種類です。

ライブラリーはソフトウェアの部品ですから、機械を組み立てるのと同じように、様々な部品を集め、さらにそれを有機的に統合して、アプリケーションを作るのに使います。

そうしますと、ひとつのアプリケーションには、様々なライセンス条件で提供されているライブラリーが混ざることになります。例えば、LGPLで頒布されているライブラリーを、他のプログラムと結合してアプリケーションを作成するとします。

そうするとできあがったアプリケーションを頒布するときのライセンスはどうなるのでしょうか？

(1)他のプログラムの中に、GPLライセンスで頒布されているものが一つでもあれば、当然、それらを結合したアプリケーションはすべてGPLライセンスを適用してオープンソースとして頒布しなければなりません。

(2)では、LGPLで頒布されているライブラリーを、占有ライセンスのプログラムと結合してひとつのアプリケーションを作成したとします。できあがったアプリケーションを占有ライセンスで頒布することができるのでしょうか？

もしこれができるのであれば、LGPLライセンスで頒布されているオープンソース・プログラムを、占有ライセンスで提供する製品のための部品として採用できます。

できないとすると、LGPLライセンスのライブラリーは、占有ライセンスのソフトウェアを開発するために採用できないことになります。

占有ライセンスで販売する市販パッケージ・ソフトウェアの開発者にとっては、上の質問(2)の答えによってLGPLライセンスのオープンソース・ライブラリーを採用できるかどうか、が決まります。大変に重要な問題です。

LGPLで提供されているオープンソース・ライブラリーを自分で作ったアプリケーションから利用したとき、そのアプリケーションを占有ライセンスで、つまり、ソースプログラムを公開することなく頒布できるでしょうか？

LGPLの契約書はとても難しいのですが。第5節を見ますと次のようなことが書いてあります。

LGPLライブラリーをまったく含まないが、それと一緒にコンパイル、リンクして動作するプログラムはLGPLライブラリーを利用するプログラムといいます。ここで、コンパイルというのはプログラムをオブジェクト（バイナリ）にすること。リンクはプログラム同士を結合することです。

契約書第5節
(1)LGPLライブラリーのいかなる部分も含まないで、LGPLライブラリーと結合して一緒に動作するだけのプログラム単体は、LGPLライセンス契約の対象外です。

(2)LGPLライブラリーを利用するプログラムに、LGPLライブラリーをリンクして実行形式を作ると、その実行形式はLGPLライセンスの対象となります。

(3)LGPLライブラリーを利用するプログラムをコンパイルするとき、LGPLライブラリーのヘッダから取られたプログラムが組み込まれると、オブジェクトコードはLGPLライセンスの適用対象となる可能性があります。但し、組み込まれたプログラムが極少ない分量であれば、LGPLライセンスの対象としなくても良いとされています。

要するに、自分で作成したプログラムにLGPLライブラリーのプログラムをある程度含んでいるか、LGPLライブラリーを静的にリンクすると、自分で作成したプログラムにもLGPLライセンスが適用されます。

そうしますと、頒布するとき、次の条件（第6節）に従わねばなりません。この第6節がまた、難解で、何度読んでも良くわかりません。

契約書第6節
どうやら、この第6節では、次のようなことを言っていると思います。
(1)　LGPLライセンスに感染したアプリケーションを占有ライセンスで頒布するときは、アプリケーションのリバースエンジニアリングを許可しなければならない。

(2)　さらに、LGPLライブラリーをユーザが改変してから自分のアプリケーションと再リンクして実行形式を作成できるか、あるいはコンピュータのシステム上でLGPLライブラリーを、他のアプリケーションと共有して使えるようにするなどの配慮をする必要があります。

(3)　第6節の条件が、自分の占有ライセンスの条件と矛盾する場合は、元のLGPLライセンスのライブラリーを自分で作成したアプリケーションの実行形式で使うことができません。

LGPLライセンスの第6節で要求しているリバースエンジニアリングは、通常の占有ライセンスでは許していないことが多いと思います。従って、多くの場合、第6節の条件で自分のアプリケーションを頒布することはできないのではないでしょうか。

結局、第5節の(3)の「但し」以降に該当する場合のみ、自分のアプリケーションを占有ライセンスとして、LGPLライセンスのライブラリーと一緒に頒布できる、と解釈します。

BSD：The BSD License

原文
日本語訳

このライセンスでは、修正の有無に関わらず、ソースプログラムまたはバイナリを頒布するときは次の条件を満たすこととされています。

BSDは非常に制限条件の緩いライセンスで、BSDで頒布されるオープンソースのプログラムは、修正したり、あるいは、修正なしで、占有ライセンス、あるいは、GPL/LGPLライセンスのものと一緒に組み合わせて頒布できます。

(1) ソースプログラムを頒布するときは、ソースプログラムに、著作権、BSDの条件、免責事項を含める。
(2) バイナリを頒布するときは添付のドキュメントに著作権、BSDの条件、免責事項を含める。
(3) 許可なく、オリジナルの開発者の名前を自分のプログラムの宣伝に使わないこと。

MIT：The MIT License

原文
日本語訳

MITライセンスで頒布されるプログラムを入手した人は、著作権表示とライセンス契約を添付するという条件を守れば、どのような使用でもできます。実質的に、BSDライセンスと同じです。

BSDライセンス、MITライセンスともおおらかなライセンスで、ビジネスモデルという表題の下で、取り上げるのが恥ずかしくなるくらいです。

MPL：Mozilla Public License

原文(MPL1.1)
日本語訳

MPLはネットスケープ（Netscape Communications Corp.）が作成したものでネットスケープが改訂権を持っています。Mozillaプロジェクトで使われており、最近、脚光を浴びている新しいブラウザFireFoxはMPL1.1で公開されています。

歴史を簡単にまとめますと；

(1) Netscape Publicライセンス　NPL 1.0
マイクロソフトのインターネット・エクスプローラとのブラウザ戦争で、劣勢になったネットスケープが、1998年にNetscape CommunicatorのソースプログラムをオープンソースしてMozｉｌｌａプロジェクトを起こしました。

その時、作られて適用されたのがNetscape Publicライセンス（NPL1.0）です。NPL 1.0はGPLに似ていて、Mozillaのソースコードを入手したプログラマが、それを改良したアプリケーションを作成して頒布するときは、改良したソースコードを公開・寄贈することを要求していました。

NPL1.0はNetscape Communicator用の修正条項（Amendments）があります。ここで、ネットスケープは、公開・寄贈されたソースコードをネットスケープ自身の他の占有ライセンス製品にも自由に使うことができるとした上、それらの占有ライセンス製品はNPL１．0で公開しなくても良い、というネットスケープに都合の良い条件をつけたことです。これはオープンソース関係者からの批判を招いたようです。

ちなみに、Netscape Communicatorのソースプログラムは複雑すぎて改良できないことが判明し、Mozillaブラウザはゼロから書き直す、ということになりました。Mozillaプロジェクトは失敗したオープンソース・プロジェクトと言えるでしょう。

(2)　Mozilla Public License （MPL) 1.0
Mozilla Public License1.0は、ＮＰＬ1.0にあるネットスケープ専用の修正条項を削除したものです。Mozillaのソースコードを修正した寄贈者が使うためのライセンスです。

(3)　Mozilla Public License （MPL) 1.１
MPL1.0の表現を改訂したもので、実質的な変更はないように思います。

(4)　MPLの特長
MPLの特長は、次の通りです。

・オリジナルのソースプログラムを修正してアプリケーションに使用した場合、その修正したプログラムをMPLで公開する必要があります。
・GPLと違って伝染性はありません。自分でゼロから書き起こしたプログラムは、修正プログラムには該当しません。仮にそれをMPLのプログラムと結合したアプリケーションを作成して頒布しても、自分のソースプログラムを公開することは要求されていません。

MPLは、Copyleftという点では、GPLとBSD/MITライセンスの中間のライセンスということができます。

Apache：　Apache Software License,　Apache License, 2.0

(1)Apacheとは？
Apache Software Foundation （ASF）は、現在、もっとも広い範囲にわたるオープンソース・プロジェクトを運営している非営利団体です。

プロジェクト領域だけでも、HTTP Server, Ant, APR, Beehive, Cocoon, DB, Directory, Excalibur, Forrest, Geronimo, Gump, iBATIS, Incubator, Jackrabbit, Jakarta, James, Lenya, Logging, Lucene, Maven, MyFaces, Perl, Portals, SpamAssassin, Struts, TCL, Tomcat, Web Services, XML, XMLBeans, XML Graphicsの31があります。

例えば、XML Graphicsには、FOP（XMLからPDFなど）、Batik（SVG関係）のふたつの活動中のプロジェクトがあります。さらに新しいプロジェクトとして、Graphics Commonを計画しており、FOPのPDFライブラリーをGraphics Commonに移すことも検討しているようです。

このように各領域には一つ以上のプロジェクトがありますので、プロジェクト総数は100を超えると思います。ASFは、単にオープンソースのプロジェクトを集めているだけではなく、プロジェクトの活動についてASFの理事会で討議して一定の水準を保つ努力をしているようです。

毎年米国と欧州でApache Conという会議を継続して行っています。

米国歳入庁（IRS)への報告が公開されていますが、これを見ますと、収入は、1999年約45,000ドル、2000年約86,000ドル、2001年約1万ドルとなっています。2003年から2005年は2万5千ドル以下です。ASFには、コンピュータ・メーカからハードウェアやソフトウェアの寄贈があるようですが、これだけの大きな非営利団体の活動を、たった数百万円のキャッシュ・フローで支えることができるのでしょうか？これはなぞです。

(2)　Apache License, Version 2.0
・原文
・日本語訳

このライセンスは、ASFの成果物を頒布するために用いられているものです。Apache Licenseで頒布されているプログラム及びその派生物を、そのソースプログラムであれ実行形式であれ、Apache Licenseを添付し、必要な通知文をつければ自由に頒布することができます。

BSD/MITライセンスに似ています。ASFに寄贈されたプログラムも対象とすること、寄贈者が保有する特許の許諾も含めること、など追加されています。

Apache Licenseはこのように寛容なライセンスであることから、ASFの成果物を改良し、自己の製品として販売しているソフトウェア会社も世界には沢山あるようです。

W3C License

原文

World Wide Web Consortium (W3C) は、Web関係の標準化を進めている産学共同のコンソーシアムです。米国のMITのCSAIL（Computer Science and Artificial Intelligence Laboratory）、日本の慶応大学、フランスのERCIM（European Research Consortium for Informatics and Mathematics）の3組織がホストになって、世界の企業・団体を組織化しています。

W3Cは、プログラムの実装よりは、むしろ、標準の仕様を策定する方に重点を置いているようです。策定した仕様は公開されていますし、誰でも自由にその仕様を利用してプログラムを実装することができます。そういう意味ではオープンソース・プロジェクトに似ています。

多くのオープンソース・プロジェクトと異なるのは、参加企業・団体にかなり高額の年会費を賦課していることで、それにより、フルタイム専属スタッフを多数擁していることでしょうか。

オープンソース・プロジェクトも、W3Cのように参加会員を募って、プログラムの共同開発を行い、できあがったプログラムは最終的にオープンソースで公開するという仕組みを取ることを考えても良いのではないかと思います。

W3Cの仕様は開発の過程では、会員企業と特定の専門家の内部だけで議論をして進めていきます。W3Cの会員になるメリットは、(1)仕様策定に参加できること、(2)仕様に関する情報を早期に入手できること、(3)各種のPR支援を得られることがあります。

ちなみに、アンテナハウスも会員になっています。当社ではW3Cの仕様の中では、XSL-FO、SVG、MathMLという3種類の仕様を実装しています。W3Cは、そういった仕様に関する情報源として、また同時に、W3CのWebサイトで当社製品をPRしてもらえることは大きなメリットになっています。

話が横道にそれましたが、W3C License はW3Cが開発したソフトウェアを、改造の有無に関わらず、再頒布する際のライセンスです。著作権の表示を明記し、このW3C License 文書を添付すれば、自由に使用を許可するという、プログラム使用者に対して寛容なライセンスになっています。

オープンソースと特許

なお、オープンソースで提供したプログラムが普及してから、特許権が成立して大きな問題になった例もあります。オープンソースはあくまで著作権に関する契約であって、一般には、特許とは別と看做されます。

一番、有名な例は、UnysisのLZW特許です。

これは、もともとそういう趣旨でプログラムをオープンソースで頒布したのかどうか分かりません。しかし、普及して多くの企業が採用した後で、特許使用料を請求されたものです。

LZW特許は、既に米国でも日本でも失効して過去の話になりました。しかし、最近では、JPEGの特許が猛威を振るって問題になっています。

JPEG特許問題

JPEGのプログラムは、BSD/MIT類似のオープンソース・ライセンスで頒布されていますので、著作権上は誰でも自由に使えます。そこで、多くの製品・ソフトウェアで採用しています。しかし、特許は著作権とは別の問題になりますので、オープンソースだからといって採用すると危険という見本です。

PDFLibのライセンス

PDFLibは大変有名なPDF作成ライブラリーです。PDFのオープンソース・プロジェクトの中で、現在の時点で一番うまくいったのは、PDFLibでしょう。PDFLibはオープンソースから初めましたが、既にオープンソースを卒業してしまったようです。成功した例が既にオープンソース・プロジェクトでない、というのは皮肉です。

改めてPDFLibのWebページを見ましたが、現在では、PDFLib Liteのみが、オープンソース開発者、私的利用者、研究者向けに限りオープンソース・ライセンスで提供されています。他の製品はすべて商用ライセンスを有償で購入する必要があります。

PDFLib Liteのライセンスページ
http://www.pdflib.com/purchase/license-lite.html

この例をもって、オープンソース・プロジェクトは成功するとオープンソースでなくなる、といったら言い過ぎかもしれません。しかし、多少なりとも大きなプロジェクトにして、品質の高い製品を継続的に出していこうとすれば、どうしても対価を得る必要があります。そのためには対価と交換に製品を提供するという仕組みをとるのが一番単純明快のように思います。

元に戻りますが、PDFLibのWebページを見ますと、現在では、ＰＤＦLibは同名の会社名となり、PDFLibはバージョン6、製品の種類も増えて世界の60カ国以上に製品を販売していると言っています。いくらインターネットを通じてオンライン・ダウンロード販売できると言っても、世界60カ国はなかなかすごいと思います。

PDFLibの成功の要因は次のようなことでしょう。
(1) サーバサイドPDFへの取り組みが早かった。
(2) 書籍などでPRして有名になった。
(3) 開発者のPDFに関する知識のレベルが優れていた。
(4) プログラムの品質が高い。

しかし、この成功の条件はオープンソースとあまり関係ありませんね。PDFLibの成功にはオープンソースで始めたことはあまり関係ないのではないでしょうか。

他には、ReportLabも結構長期間に渡って頑張っています。ReportLabは、商用ライセンスとオープンソース・ライセンス（OSL）の両方を用意して、ユーザがどちらかを選択するデュアルライセンス方式を取っています。

このデュアルライセンス方式は、オープンソースのビジネスモデルの一つです。
ReportLabは、商用ライセンスの製品では、OSLの製品と比べて、製品の種類を増やしています。また、利益源になる製品は商用ライセンスしか提供していません。このあたり、PDFLibと似ています。

結局、オープンソースから商用ライセンスに向かうというところに成功への道が一つあるように思います。

GhostScriptのライセンス

PDFのオープンソースのビジネスモデルのもう一つのタイプはGhostScriptやXpdfのように、同じものを商用ライセンスとオープンソースライセンスのデュアルライセンスで提供するタイプです。

例えば、GhostScriptのライセンスはここに説明されています。
http://www.artifex.com/licensing/index.htm

これによりますと、GhostScriptは３種類のライセンスで提供されています。

なお、以下でいうライセンスの違いは、主にGhostScriptを使ったアプリケーションを再配布する時の条件の違いになります。従って、製品提供者側向けの話です。エンドユーザの使用権について言っているわけではありません。

(1) Artifex Ghostscript　商用ライセンス
Artifex 社と契約を結びGhostScriptのソースコードを入手、GhostScriptを自分で開発したアプリケーションと一緒に配布する権利を得ることができます。このとき、自分で開発したアプリケーションのソースコードをオープンソースにしなくても構いません。

(2) AFPL Ghostscript：Aladdinフリー公開ライセンス（Free Public License）
(3) GPL Ghostscript： GPLライセンス

GPLまたはAFPLのGhostScriptを使うなら、自分が開発するアプリケーションが、次のいずれかにあてはまる場合、自分が開発するアプリケーションすべてをGPLまたはAFPLで公開しなければなりません。

・自分で開発するアプリケーションが、GPLまたはAFPLのGhostScriptのコピーを含む。
・自分で開発するアプリケーションが、GPLまたはAFPLのGhostScriptから派生している。
・自分で開発するアプリケーションが、GPLまたはAFPLのGhostScriptのひとつ以上の機能を使っている。

自分が開発するアプリケーションをGPLまたはAFPLで公開しないなら、(1)の商用ライセンスを選択しなければならないのです。つまり、お金を払って再頒布の許可を得なければなりません。

AFPL GhostScriptはこちらから入手できます。
AFPL Ghostscript

GPL GhostScriptはこちらから入手できます。
GPL Ghostscript

ややこしいですね。それにしても、なぜ、商用ライセンスの他に、GPLとAFPLの2種類のライセンスがあるのでしょうか？

Aladdin Free Public Licenseの文章をざっとみますと、まず、これは、(いわゆる）オープンソースではないと書いてあります。GPLとの違いとして、AFPLでは「商用団体が、直接的にせよ、間接的にせよ、対価をとってAFPL GhostScriptを配布することを禁止している」ということで、「AFPLはGPLより厳しいライセンス」であると書かれています。
GPLは対価を取ることを禁止していません。

RedHatの成功方程式

ちなみに、いま盛んに宣伝されているLinuxのディストリビュータで、もっとも成功したのはRedHatだろうと思います。

2006年3月28日に2006年2月度のRedHatの決算が発表されています。
Red Hat Reports Fiscal Fourth Quarter and Fiscal Year 2006 Results
売上高　　　2億78百万ドル　前年比53%増
営業利益　　　 58百万ドル 前年比165%増

というすばらしい業績です。但し、まだ多額の累積損失が残っていて、自己資本比率は30%台なので優良企業というにはあと数年掛かるように思います。

RedHat Linux の主要部分は、GPLで公開されています。

でも、RedHat LinuxをCDまたはDVDで入手し、それをそのままインタネットに公開すると訴訟されるそうです。また、コンピュータ雑誌がおまけにRedHatのCDをつけるにはRedHatの許可が必要です。しかし、雑誌社がRedHatに申し込んでも絶対に許可しないそうです。

要するにRedHat Enterprise Linux (RHEL)を入手するには、RedHatに代金を支払って、Subscribe（購読)するしかないということになります。

どうやら、RedHatはRHELを複製再頒布をさせないように商標権で守っているようです。しかし、RHELはGPLで公開されているのでGPL違反ではない、ということになります。

GPLプログラムを複製されないように商標権で守るというのはオープンソースの新しいビジネスモデルです。

RedHat のLinuxビジネスは、サービスを売っていると言われます。確かに表面上はそう見えます。

占有ライセンスでは、顧客がプログラムをインストールした台数に応じて、使用料が多く課金されるというビジネスモデルになります。しかし、RedHat Enterprise Linux （RHEL）はGPLライセンスで提供されますから、顧客は、RHELを自由に複製してインストールできます。

顧客が自分でRHELを複製してインストールすれば、インストールしたRHELの台数が増えてもサービス収入の増加には繋がらないでしょう。要するに工夫無しにサービスを売っても儲からないだろうと思います。

収入を増やすには、RHELのインストール台数が増えれば、自然にサービス契約が増えて、サービス料金を多く課金できる仕組が必要です。

このあたり、RedHatは、一体どうやって実現しているのでしょうか？

そこで、同社のサービス購読契約（Subscription Agreement）を見てみました。

ざっとみた結果ですが、さすがに、なかなかのものです。多分、優秀な弁護士をそろえて知恵をひねったんでしょう。GPLライセンスのプログラムを頒布して収益を上げるための契約の枠組みを見事に作りあげています。

大雑把に紹介しますと、
１．付録1-1　
RHELは、GPLライセンスで提供していますので、契約書では顧客がプログラムの部品を改変したり、コピーしたり、再配布する権利を制約していません。（制約したらGPL違反になりますから。）

２．付録1-2　
知的所有権という項目で、顧客がRedHatという商標を使ったソフトウェアを頒布することを禁止します。RHELを第三者に頒布するには、RedHatの各種の商標やマークを削除しなければなりません。但し、単に削除するとソフトウェアが壊れるかもしれないと脅す。（商標権で規制してRHELの頒布をさせません。）

３．本文I-A　定義
最初のインストール・システムとは、最初に顧客がお金を払って購入したRHELの枚数。（RHELは公開の場で無償入手できないように規制していますので、1枚目は購入しない限り入手できません。購入した段階で契約が成立して、顧客に契約を守る義務が発生。）

４．本文I-１　契約期間
サービス契約は１年契約で、自動更新。（これは曲者）。

５．本文I-２　価格、請求
RedHatは、契約時、契約更新時に定価の請求書を発行します。顧客は30日以内に支払わねばなりません。（自動更新なので知らないうちに請求が来ます。）

５．本文I-４　報告と監査
インストール・システムを増やすには、RedHatに1台毎に報告して、サービス契約を増やさねばなりません。
RedHatは、契約期間中、顧客企業のインストール・システム数がサービス契約の数と一致しているかどうか1年1回未満で監査する権利があります。
監査結果で不正が見つかったら、顧客企業は20%分のペナルティを払わねばなりません。

大まかなところは以上ですが、これを見ますと、サービス契約を一旦締結すると、インストールした台数が増えたらそれを申告しなければならず、しかも自動更新なので定期的にRedHatに定価で支払いをしなければなりません。これはもしかするとRHELの方がWindowsよりも運用コストが高くつくかもしれません。

この仕組みだと確かにRHELは儲かるでしょう。こんな殆ど悪知恵のような仕組みを良くも考えたものです。

この契約書は、Webページに公開されているものです。オープンソース・プロジェクトを考えている人は、ぜひご自分で研究することをお勧めします。

MySQLはデュアル・ライセンス方式

もうひとつの例として、今、脚光を浴びているオープンソースDB　MySQLはGPLと商用ライセンスのデュアルライセンス方式です。MySQLのライセンスの説明には、(1)MySQLを自己のアプリケーションと組み合わせて顧客に販売したり、(2)お客さんがMySQLをインストールして使うことを要求するアプリケーションを販売したり、(3)MySQLを組み込んだハードウェアを販売するのは、再頒布と看做し、MySQLの商用ライセンスを買わねばならないと書いてあります。

このMySQLのライセンス説明のページには少し問題がありそうに思います。

本来、GPLと占有ライセンスは、矛盾するライセンスです。GPLは占有ライセンスと同時に頒布することを認めていません。ですので、GPLで頒布されるMySQLと、占有ライセンスのプログラムを一緒に頒布するとGPL違反になります。従って、MySQLの商用ライセンスが必要となります。これは分かります。

しかし、本来GPLは、頒布に関する条件ですので、ユーザが自社内で使う分にはどんな使い方をしようがGPL違反ではないはずです。そうなりますと、ユーザが、自己の判断で、例えば、アンテナハウスのXSL FormatterをMySQLと組み合わせてシステムを作っても問題はないと思います。

XSL Formatterは占有ライセンスですので、両社を組み合わせて販売したらGPL違反で、ユーザが自己の判断で組み合わせてシステムを作成したらGPL違反にならないということになるはずです。しかし、MySQLのライセンスの説明では、このあたりが曖昧に書かれているような印象を受けます。

いずれにしても、占有ライセンスのソフトウェア供給者は、GPLのMySQLをサポートすると表明すると、まずいことになりそうです。MySQL ABと商用ライセンス契約を交わせばもちろん問題ありません。

このように、デュアルライセンス方式には一種の胡散臭さが残ります。ひとつのソースプログラムを2種類、あるいはそれ以上のライセンスで頒布するというのは、潔くないと思うのですが（日本語では二枚舌と言いますね）。

それにしても、今回初めて、ビジネスモデルという観点からMySQLのWebページをチェックしてみましたが、MySQL ABには随分多くのベンチャ・キャピタルが投資しています。

MySQL AB投資者
Benchmark Capital：　http://www.benchmark.com/
Institutional Venture Partners：　http://www.ivp.com/
Index Ventures：　http://www.indexventures.com/
Holtron Ventures：　http://www.holtron.fi/　(フィンランド)
Intel Capital：　http://www.intel.com/capital/
等々

MySQLの経営者は、ベンチャ・キャピタルから投資を引き出すのが上手なようですね。こうして投資資金が集まれば、ソフトウェアの開発を加速することができますから、開発競争という面では非常に有利です。

ベンチャ・キャピタルは通常の企業と違い、経営目標の第一優先順位は、投資先の企業の株式市場への公開と、それによるキャピタルゲインの取得にあります。この点、MySQLは、まだ公開していないと思いますが、果たして公開できるかどうか、また、その後、オープンソース・ビジネスモデルでRedHatに次ぐ（企業としての）成功例になるか興味深深ですね。