Tokyo CabinetとKyoto Cabinetの商用ライセンスをどう定義したら俺にとってハッピーだろうか検討してみた。
背景
俺が作成した各種ソフトウェアのライセンス管理業務を妻に任せて、さしあたって妻の個人事業としてライセンス販売を行ってもらうことにした。KCの名義を「FAL Labs」にしたのはその布石である。事業が軌道に乗れば、法人化したり、人を雇ってサポートサービスを始めたりといったことも検討するが、現状で「箱」だけ作ってリスクを増大させるのもあまり得策ではないと考える。
現状のビジネスモデルを一言で言うと、「お小遣いモデル」あるいは「シェアウェアモデル」である。つまり、ライセンスすべき製品は既にあるので、それをほぼゼロのコストで収益化することを目指す。現時点では、人を雇ったり外部委託業務を発生させたりしてコストやリスクを増大させることなく、生活の足しになる程度の収入を得られればよいと考える。
したがって、営業活動はしない。サポート契約もしない。そしてライセンス契約もできるだけシンプルなものにしたい。それらの制約によって、収益もかなり限定されたものになるだろう。でも、今はそれでいい。
LGPL/GPLのリンク例外
TCはLGPL、KCはGPLで一般公衆にライセンスされているオープンソース製品であり、俺が商用ライセンスを規定したとしても、それらのライセンスが無効になることはない。LGPL/GPLで一旦ライセンスしたバージョンを既にダウンロードしてその条件のもとで製品なりサービスに組み込んで利用している人がいるとして、それを一方的に剥奪することは当然ながら不可能である。次のバージョンからプロプライエタリなライセンスでリリースする権利が俺にはあるが、たとえそうしたとしても、旧バージョンを第三者がメンテナンスしてLGPL/GPLでリリースしつづけることが可能であるので、単なる意地悪という以外に意味はない。よって、TCやKCがオープンソースでありつづけることは絶対的である。
LGPLやGPLについて確認しておこう（詳細は原典で確認してほしい）。TCやKCを組み込んだソフトウェアをLGPLやGPLの条項に基づいて自由なライセンスの下で公開したくない場合には、LGPLやGPLによる利用許諾が認められないので、その他のライセンスを俺と別個に契約することが必要となる。ただし、LGPLであるTCの場合は、TCを動的ライブラリとして第三者が利用可能な形態で配布した状態でそれにリンクする場合に限り、アプリケーションを自由なライセンスにする義務から免れることができる。
以上を踏まえて、プロプライエタリなソフトウェアの開発者がTCやKCとの別個のライセンス契約を望んだ場合に、俺は商用ライセンス契約を提案することとなる。で、まったく新たにライセンスを作ることも考えられるのだが、俺は法律家ではないので、込み入った条項を的確に定義する自信がない。英語と日本語を両方作らなきゃならないし、ちょっと考えるだけでも非常に面倒くさい。そこで、基本的にLGPLやGPLの条項を踏襲した上で、それらのリンク例外という条項をいくつか盛り込むことで商用ライセンスを構成しようと思う。
つまり、LGPL/GPLが宣言するように、あるがまま提供され、商用目的で使おうがいかなる目的で使おうが無保証であるという条件を踏まえた上で、上述した自由なライセンスの伝染性を回避する権利を金銭的対価のもとに提供するということである。
包括ライセンスとその制限
簡単のために、まずは個人または法人に対する包括的ライセンスについて考える。つまり個々の商品に組み込む権利や個々のコンピュータの上で稼働させる権利をその数量に比例させて売るのではなく、その人または会社によって開発され配布される製品に数量的には無制限に組み込むことを許諾するライセンスである。その場合、対象の個人や法人の営業規模によって予めライセンス料金を定めることになる。契約が一回だけになるので簡単であるが、その反面、継続的に収入を得ることは望めない。しかし営業コスト最小の目標の下では包括ライセンスが最も手軽でよい。
ライセンシーは、TCやKCのライセンサーである「FAL Labs」に対して規定の金額を支払うことによって、LGPLやGPLによるソース公開義務を免れて自己の製品を配布することができるようになる。ただし、いくつか制限を加えておかないと我々のビジネスが破綻してしまう。
第一に、そのライセンスによって得た権利を他者に譲渡することはできないようにしなければならない。そうしないと個人にライセンスを買わせて、それを大企業が引き取れば、個人のライセンス料金で大企業が利用できるようになってしまうからだ。これに関しては、その旨をライセンスに明記しておけばそれほど問題はないと思う。ライセンシーが合併したり買収されたりした場合にどう扱うかなどの詳細を詰める必要はあるが。
第二に、TCやKCを組み込んだ製品がTCやKCの単なるラッパーとして実質的にKCやTCの機能そのものを再配布することができないようにしなければならない。そうしないと、あるライセンシーがTCやKCのライセンスを買って、10行程度のラッパーを書いて、それを別の名前でより安価に売ることが可能になってしまい、俺の商売は上がったりになる。この条件を明確にするのはかなり難しいと思っている。「単なるラッパー」なのか歴とした製品やサービスなのかを客観的に判断する指標がない。これは下請け企業が元請け企業にサブシステムを納入するとしてそこにTCやKCを使っていた場合にもあてはまる。
価格
世の中には様々な企業があり、その営業規模（支払い能力）を簡単に測ることは難しいので、包括ライセンスの値付け方式を適正に定めるのは難しい。しかし、いわゆるマーケティングのスキルを全く持たない俺としては、とりあえず会社の規模で定めるのが妥当であろう。以下のような感じだろうか。TCとKCは別個のライセンスとするが、両方契約してくれたら後から契約した方は5割引にしてもいいとかにしようか。
| 個人 | 10万円 |
| 法人 | 従業員数一人あたり10万円 |
これが高いか安いかは正直言ってわからない。従業員数10人の企業だと100万円、100人の企業だと1000万円、1000人の企業だと1億円である。でも、数量無制限って考えると100人企業で1000万円は安いよねぇ。1000人企業で1億円ってのは何か高い気もするけど、いずれにせよ高額案件は応相談って感じになるだろうから、もっと高めに設定しておいてもいいくらいだ。だって、Berkeley DBなんて、「1プロセッサあたり」で5800ドル（50万円ちょい）だよ。
まとめ
GPLリンク例外のライセンスモデルであれば比較的簡単に商売を始められそうだ。価格に関しては高めに設定しておいて、売れなかったら下げればいい。しかし、ライセンスの制限条項に関しては後から厳しくすることは難しいので、売り出す時点でかっちりと決めておかねばならない。が、俺が適当に書くのは後々係争を招きそうで不安だ。
なので、その辺に詳しい方に相談に乗っていただきたいと常々思っているのだが、どなたか私めと飯でも食ってくれる人いませんか。あるいはプロの方で、そのライセンス文書（英文）の策定までコンサルしてくれる方いませんか。
追記：Kyoto Cabinetの宣伝のために、期間限定IRC相談窓口を設けた。freenode（chat.freenode.netとか）で #kyotocabinet にjoinしていただきたい。OSS開発者/プロプライエタリ開発者問わず、何でも聞いてね。