自分の書いたソースコードについてどのライセンスを適用すればいいか、考えが整理されてきたので、オープンソースや、フリーソフトウェアについてまとめてみることにしよう。
GNU GPLはviral（伝染する）ライセンスであるから良くない、という主張は、オープンソース開発の本質を得ていない。Emacsの開発者でもあり、GPLの生みの親でもあるStallmanがこの方法を取ったのは、プログラムをproprietary（独占、転じてclosedの意）、つまり、特定の個人や企業の所有物とされたくないという考えが大本にあって、それを実現（強制）するための手段がGPLという形になっているだけだ。
他人の書いたコードに依存しないプログラムを書くことは、膨大な労力を要するものだ。開発者の知性や時間を、真に新しいプログラムを生み出す方向に向けるためには、過去に作られたプログラム、つまり知識や道具を誰もが利用できる形にし、それらをつなぎあわせることで不必要な作業を省き、創造する力を助長してあげなくてはならない。ソースコードが企業の利益のために隠されてしまって、創造が止まってしまうことを避けたいという信念がGPLの中にはある。
ここで、非公開でもうまくいく、とMicrosoftの例を挙げるのはかなり極端な話だ。確かに彼らは、Windows用のAPIを公開して内部実装を非公開にしているが、そのclosedな実装であっても、プログラマは利益を損なうどころか、APIの恩恵を享受して、プログラミングを快適にしてもらっている。でも、勘違いしてはいけない。彼らのビジネスモデルは、WindowsというOSを売ることであり、そのためには、Windowsの価値を向上させる必要がある。価値を向上するには、Windows上で動く品質の良いソフトウェアが多く誕生しなくてはならないのだ。そのために、他人任せではなく、熱心に次々とWindowsの機能を生かすためのコードを自社開発している。ただそれだけの話だ。
でも、コンピュータという創造力を無限に引き出すようなものの前では、Microsoft一社だけでその開発をすべてまかなえるほど、人間の新しいものを生み出す知性や創造力は限られてはいないということだ。確かにMicrosoftの貢献は大きい。Officeのように優秀で安定していて実用的なアプリケーションはとても便利だ。でも、品質のいい製品をマーケティングまで考えて開発するのは時間がかかるし、それもMicrosoftが超巨大企業になったからこそできることだ。でも、カレンダーのようなWebアプリケーションなど、今すぐ使いたいものを開発する小回りの良さでは、小さなグループで開発を進めるGoogleに完全に出し抜かれてしまっている。もし、Microsoftや他の企業がソースコードのすべてを独占し、オープンソースのコードやOSが存在しなかったらGoogleが台頭することなんてできなかっただろうし、我々がWebアプリケーションの便利さを知ることすらできなかったかもしれない。
この例だけでも、GPLが世に与えた影響は大きい。けれど、GPLを自分のコードに適用しようとすると頭の痛い問題を抱えることになる。著作権保持以外は商用利用もソースコード非公開でバイナリ配布など何でもありのBSDライセンスと同様に、ソースコードの利用に関して制限の緩いApache Software License (ASL) version 2.0が適用されたプログラムであっても、GPLライセンスのコードと組み合わせた場合、ともに配布することはできなくなってしまう。それはASLには、特許に関連する訴訟を起こした場合、ライセンスに書かれている権利を失効させる条項が含まれているからだ。ASLの権利を失うということは、ASLのソフトウェアを配布できないということを意味する。
GPLはソフトウェア開発を阻害するような特許訴訟を起こした人物にさえも判決が確定するまで、ソースコードを配布する自由を守ろうとしているし、ASLは、プログラマや企業の心の平穏を保つため、そのような特許訴訟に対しての対抗策を講じている。けれど、
ここや、
ここの話を見る限り、両者は対決をしているわけではないし、問題点は特許に関する条項のみであるから、歩み寄りの方向に向かうのであろう。
GPLのページで、GPLと他のライセンスが適用されたコードを同時に配布できるか(compatibility)について、 こと細かに述べられているが、compatibilityの問題はさほど重要でもない。要するに、いろんな独自ライセンスのproliferation(増殖）のために、GPLの親であるFree Software Foundation(FSF)が、GPLの制約の維持に苦慮しているということだ。
でも、GPLを自分のコードに適用することを考えると、そのコードを書いたことに対する自分への金銭的な見返りが何もなくなってしまうことがとても恐ろしい。GPL製品を使う企業は、製品そのもののソースコードは公開しなくてはならないから、製品そのものを売ることはできないけれどその周辺（サポートビジネスなど）で対価を得ることはできる（バザール型）という。でも、そもそも個人プログラマがそんなビジネスを一からはじめるのは、とても大変だし、かなり長い道のりだ。かといって、ASLのように、非公開でコードがどんどん拡張されて利用されることが認められる場合には、自分のプログラムが何の断りもなしに金儲けに利用されてしまうのではないかと思ってしまう。ただ、GPLと違い、ASLの場合は、自分も非公開にしてお金を稼ぐことはできる。
たとえば、データの通信ライブラリを自分が作ったとして、それを他人が利用してWeb通販などのビジネスを始めたとする。Web通販部分は、自分の作ったものとは別個のものだから、そこにまで自分の権利が及ぶと考えるのは傲慢だと純粋に感じる。もし通販部分のソースコードを公開してしまえば、通販部分の開発費を他人のために投げ捨てる事態になってしまう。データ通信部分がGPLだと、まさにこの状況になる。差別化を計れる機能を実装しても、自分自身ですら商用に利用できなくなってしまう。まぁ、著作者ならGPL以外を適用すればいいのだが、GPL製品に囲まれてしまうと、すべての著作者やcontributorをたどってGPL以外の適用を認めるように依頼しなくてはならない。開発者の意思としては、BSDライセンスのように緩いものを適用するだけでよかったとしても、コミュニティの中で開発するためにGPLを選択した例も多いはずだが、その意思を確認することはほぼ不可能だ。
GPLはGPLのコミュニティ内で活動しているとき以外は、どうも自分の手足を縛るようなものの気がしてならない。創造性を助長するというよりは、窮屈さや将来への不安を感じてしまうものなのだ。ただ、変化するソースコードを公開したままにするcopyleftというのは決して悪いアイデアではない。
そうすると、Sun MicrosystemsがOpen Soralisに適用している
CDDL (Common Development and Distribution License)というライセンスがとても魅力的になる。mozilla.orgのFirefoxなどに適用されているMPLと同様に、ソースコードはファイル単位でライセンスが付与されるなど、ライセンスの適用対象が明確。それゆえ、違うライセンスが付与されたファイルとともに配布することができる(配布物全体に影響が及ぶGPLコードとともに配布することは無理だが）。ファイルを更改して配布した人には、ソースコードの公開義務（copyleft)を課すことができる。バイナリ形式で配布するときには、違うライセンスを付けてもいい、など。
Sun関連の人のblog(
これとか、
これとか
これ)を読むと、CDDLができた経緯や意図がわかって、さらに面白いかもしれない。
CDDLは、MPLがmozilla.org専用のものであるのに対し、commonと銘打たれていることからわかるように、MPLを汎用化したライセンスとなっている。GPLが他のライセンスとのcompatibilityで苦労した轍を再び踏まないようにしたいのであろう。プログラマが開発中に法律的な条項の解釈で悩むのは、やはり好ましくない。
CDDLを使いつつも、GPLコミュニティの中で自分のプログラムが生きていけるようにするには、mozilla.orgと同様に、GPLとCDDLのデュアルライセンスを検討するといい。GPL単独での利用で困難なのは、開発メンバーが多岐に亘った場合に、条件の緩いライセンスへの変更の意思を確認することである。最初から、開発者にGPLとCDDLの双方の条項に同意してもらえれば、Firefoxの成功例のように、企業、個人、非営利団体の垣根を越えて、オープンソースソフトウェアとして安心して開発を続けられるものになるはずだ。
ただし、デュアルライセンスという形態では、GPLプログラムとの共存が完全ではない。一度GPLプログラムを取り込むと、デュアルライセンスという形式はとれずGPLライセンスのプログラムとなる道しか選べないからだ。 LinuxのようなGPLで固められたOS用に移植することは可能だが、そうするとGPL専用、CDDL/GPL兼用の2つのbranchができてしまうことは想像に難くない。開発者は、GPL製品を利用することはできるが、それを利用してできたコードを、CDDL/GPLのデュアルライセンスの形に戻すことはできない。
面倒な問題は山積みだが、ライセンスを考える上でのポイントは、プログラマの心の平穏と、創造性を助けるもの、開発コミュニティの形成を促すライセンスであるかどうか、だ。CDDLはOpenSoralisで多数のプロジェクトが生まれているように、企業や個人を含めた開発コミュニティを作りやすくすることを目的としている。
GPLとのcompatibilityの問題のように、ライセンスにこの不具合があるからだめだとかという議論は、概して不毛であるし、いいものを作るというソフトウェアライセンスにこめられた本当の目的からは外れてしまう。LinuxのようにGPLによって得られた産物のインパクトの大きさから、GPLに反するライセンスを安易に卑下する意見が巷でよく見られるのだが、GPLの威力は、GPLのcopyleftの性質によるものなのか、それとも、GPLの適用範囲がそれを利用するものすべてに拡大していくことによるものなのか、を区別して判断しなくてはいけない。けれど、そのどちらについても、FirefoxやEclipse、Apache Software Foundation、PostgreSQLなどの成功例によって、copyleftが必ずしも必須ではないこと、ライセンスの適用範囲を広げなくても、いいものは出来上がることが示唆されている。もしかしたら、それらはGPLによってオープンソース開発の土台ができたことによって成功した例なのかもしれない。けれど、はっきりと言えることは、もはやGPLはmustの存在ではない、ということだ。
そうすると、一個人プログラマとしての僕にとって重要な指標は、自分が自分のソースコード（とそれを利用したアプリケーション）を自由に（商用・非公開を含めて）利用でき、改良が僕の知らないところで行われないという点だ。これらを満たす選択肢としては、CDDLが今のところ最良のものとなる。GPL非依存のライブラリも増えてきたこともあり、GPL製品に頼らなくても、コードを開発する土台がある今なら、GPLへ回帰する選択肢だけは残したまま、つまりCDDL/GPLというデュアルライセンスの形態をとり、GPL非依存のライブラリやツールを構築していくというのが、今の僕の結論だ。
