ライセンスの氾濫

ソフトウェア開発者は異なるソフトウェアプログラムを部分的に組み合わせようと考えることが多いが、しばしば不可能な場合がある。その理由はライセンスが同時に両立しないからである。2つの異なるライセンスで許諾されているソフトウェアを組み合わせ、一つのより大きな著作物とすることが可能な場合、そのライセンスは互換性がある（もしくは、ライセンスは両立する）という。ライセンスの数が増加するにつれて、FLOSS開発者が組み合わせたいと考えているソフトウェアが利用可能であっても、互いに両立しないライセンス下での許諾となっている可能性が高まる。また、利用するソフトウェアパッケージの各FLOSSライセンスを評価しようと考える組織にとって、これはより大きな負担となる。厳密に述べると、ライセンスの氾濫に賛同している人物や組織などない。むしろこの問題は、ソフトウェアのリリースのために新たなライセンスを作成するという現実的なニーズやそのようなニーズがあると認識したがゆえに、それらニーズに対処しようと新たなライセンスを作成する各組織の傾向に、問題の根幹があるといえる。

GNU General Public License（GPL）を管理するフリーソフトウェア財団（Free Software Foundation, FSF）は、GPLと互換性のあるライセンスのリストもまとめている[1]。別の有名なFLOSSライセンスとしてApache Licenseが存在する。Apacheソフトウェア財団は各団体との議論を経たのち、ウェブサイトにて次のような事実を述べている[2]。Apache LicenseはGPLv3と両立する。ただしそれは「一方的に」である。すなわちGPLv3ソフトウェアはApache Licenseのソフトウェアを含むことのみできる。しかしその逆はできない。

空虚なライセンス（Vanity licenses）とは、ある企業や人物が特段の理由もなく作成したライセンスを揶揄する用語である。FLOSSでより広く知られるライセンスと比べ明白な改善点または相違点がないライセンスを作成した場合、そのライセンスが空虚であると批判されることはしばしばある。

FLOSSライセンスとしての要求を満たさず、またその要求自体も知らず、かつ標準的ではないライセンスを利用することがプログラムを第三者にとってほとんど意味のないものとすることに気付かず、新規にリリースしたプログラム向けに新しいライセンスを作成する者が、2008年時点でも多くいた[3]。

2006年から2010年にかけて、Googleはライセンスの氾濫に対して独自の立場に位置した。とりわけ2006年には、Googleは自身のコード・ホスティングサイト、Google Codeにて次のライセンスで許諾されるソフトウェアプロジェクトのみ受け入れる方針を発表した[4]。

• Apache License 2.0
• Artistic LicenseとGPLのデュアルライセンス（Perlコミュニティはしばしばこのような方法を採用する）
• GNU General Public License 3.0
• GNU General Public License 2.0
• GNU Lesser General Public License
• MIT License
• 新BSD License
• Mozilla Public License 1.1
• Eclipse Public License

2008年、GoogleはホスティングするプロジェクトにApache LicenseまたはGPLv3を強く推奨するとの追加の発表を行った[5]。しかし、2010年、これらの厳格な運用に逆行するかのごとく、結果として今後はOSIの立場と単に同じになり、OSI承認済みのライセンスによるプロジェクトが全てGoogle Codeでホストできるようになった[6]。このことによりAGPL等のライセンスによるプロジェクトもホストできるようになった[7]。

Open Source Initiative（OSI）はあらゆるオープンソースライセンスを管理する立場であると自身を見なしている。彼らはOSI認証済みライセンスの一覧[8]を管理している。初期の頃は、空虚なライセンスの作成や承認を助長するような動きがあった。事実、マーク・シャトルワース[9]をはじめとする幾人かは、OSIが新しいライセンスを受諾し続けることによりライセンスの氾濫が問題となっていることについて、OSIはその問題に対し重大な責任を負っていると主張する。このことに対応するためOSIは「ライセンス氾濫問題プロジェクト」（License Proliferation Project）[10]を立ち上げ、「ライセンスの氾濫についての報告書」[11]を準備した。

FSF代表リチャード・ストールマンと元執行役員（Executive Director）ブラッドリー・M・クーンは2000年頃からライセンスの氾濫に対する主張を行ってきた。彼らはFSF license listを策定し、ソフトウェア開発者が作成したソフトウェアのライセンスとしてGPLと両立するフリーソフトウェアライセンスを採用するよう開発者に勧めている[12][13]。しかしながら、GPLと両立しない（互換性のない）複数のフリーソフトウェアライセンスもこのリストにコメント付きで掲載されており、そこでのコメントで彼らは次のように述べている。当該ライセンスの下、既に許諾しているソフトウェアの利用もしくは動作、またはその双方に関しては全く問題はない。しかし一方、このリスト読者が作成するソフトウェアにはそれら件のライセンスを利用しないよう勧める[12][13][1]。

キーラン・オリオーダン（Ciarán O'Riordan）は、 "How GPLv3 tackles license proliferation"と名付けられた論説[14]において、FSFがライセンスの氾濫を阻止する主な動機は、まずは新しいライセンスを作成する理由を減らすことであると主張している。概してFSFEは、可能ならばGNU GPLのみを利用するよう一貫して推奨している。もしそれが不可能ならば、GPLと互換性のあるライセンスを採用するべきだと述べている。

不要なライセンスを作り、コードの再利用性を低下させないようにするためには、既存のライセンスと互換性のあるライセンスを作成するか、既存のライセンスから、そのソフトウェア、ドキュメントの性質、規模や利用形態により適切なものを選択する必要がある。FSFは相互に両立しないライセンスを誤って選択しないための一つの指針を提示している[15]。例えば、既にプロプライエタリな実装が存在するソフトウェアでは（とりわけそのようなものはライブラリに多い）二次的著作物を同一のライセンス下に置くのは制限が強過ぎて組み合わせて頒布できなくなるので、弱いコピーレフトを持つライセンスである、LGPLが適切だと述べている。またウェブアプリケーションでは"Remote Network Interaction"条項という、頒布されなくともコピーレフトを発揮するGNU AGPL（バージョン3）が適切であり、プロプライエタリなフォーマットの置き換えを目標とするもの（例: MP3に対するOgg+Vorbis）や小規模なソフトウェアでコピーレフトが必要ないと考えられる場合はApache Licenseバージョン2が適切であるとも述べている。その他のプログラムやライブラリはGPLが適切であると述べている。Apache Licenseバージョン2はBSDライセンスと同じくパーミッシブ・ライセンスであり、二次的著作物を同一の許諾条件に置く必要はない。よってプロプライエタリソフトウェアと組み合わせることができるが、BSDライセンスとは異なり特許に対するある程度の防御策が施されているため、単なるBSDライセンスを採用するよりも不当な特許権主張の訴訟攻撃を緩和できると期待される。

オープンコンテント、フリーコンテントといった、ライセンスで自由利用を可能としている創作物に関しても、ソフトウェアと同じくライセンスの互換性を考慮する必要があるが、クリエイティブ・コモンズ・ジャパンが行った講演によると、自由利用可能なコンテンツに関しても広範に利用されている標準化されたライセンスを使うべきであり、（先述した「空虚なライセンス」のように）独自ライセンスを策定することで自由利用可能なコンテンツの組み合わせを狭めてしまう場合があり、コンテンツを自由利用可能とした利点が失われると述べている[16]。

• ライセンスの互換性

• Open source license proliferation, a broader view - レイモンド・ニマー（Raymond Nimmer）による。
• 異なるライセンスがもたらす効果について。ローレンス・ローゼンによる。
• Licensing howto。エリック・レイモンドによる。
• Sharing medical software: FOSS licensing in medicine - フレッド・トロッター（Fred Trotter）による、医療用ソフトウェアのライセンス氾濫について。この記事では、医療用ソフトウェアにおいてはGoogleが受け入れを表明した7つのライセンス（2007年当時）のみを採用すべきであると主張している。