ライセンスの氾濫
 |
ライセンスの氾濫（ライセンスのはんらん、License proliferation）とは、ソフトウェアパッケージ毎にライセンスを改めて作成することによる弊害を指す。ライセンスの拡散、ライセンスの増殖とも訳される。この問題はフリーソフトウェアコミュニティに対し多大なる影響を与えている。
概要
[編集]ソフトウェア開発者は異なるソフトウェアプログラムを部分的に組み合わせようと考えることが多いが、しばしば不可能な場合がある。その理由はライセンスが同時に両立しないからである。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]。
Googleの姿勢
[編集]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]。
OSIの姿勢
[編集]Open Source Initiative（OSI）はあらゆるオープンソースライセンスを管理する立場であると自身を見なしている。彼らはOSI認証済みライセンスの一覧[8]を管理している。初期の頃は、空虚なライセンスの作成や承認を助長するような動きがあった。事実、マーク・シャトルワース[9]をはじめとする幾人[誰?]かは、OSIが新しいライセンスを受諾し続けることによりライセンスの氾濫が問題となっていることについて、OSIはその問題に対し重大な責任を負っていると主張する。このことに対応するためOSIは「ライセンス氾濫問題プロジェクト」（License Proliferation Project）[10]を立ち上げ、「ライセンスの氾濫についての報告書」[11]を準備した。
FSFの姿勢
[編集]FSF代表リチャード・ストールマンと元執行役員（Executive Director）ブラッドリー・M・クーンは2000年頃からライセンスの氾濫に対する主張を行ってきた。彼らはFSF license listを策定し、ソフトウェア開発者が作成したソフトウェアのライセンスとしてGPLと両立するフリーソフトウェアライセンスを採用するよう開発者に勧めている[12][13]。しかしながら、GPLと両立しない（互換性のない）複数のフリーソフトウェアライセンスもこのリストにコメント付きで掲載されており、そこでのコメントで彼らは次のように述べている。当該ライセンスの下、既に許諾しているソフトウェアの利用もしくは動作、またはその双方に関しては全く問題はない。しかし一方、このリスト読者が作成するソフトウェアにはそれら件のライセンスを利用しないよう勧める[12][13][1]。
FSFEの姿勢
[編集]キーラン・オリオーダン（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]。
脚注
[編集]- ^ a b 現在のリスト。 “Various Licenses and Comments about Them”. Free Software Foundation (2011年5月2日). 2011年5月10日閲覧。
- ^ “Apache License v2.0 and GPL Compatibility”. Apache Software Foundation. 2011年5月10日閲覧。
- ^ David A. Wheeler (2008年8月20日). “FLOSS License Proliferation: Still a problem”. 2021年4月24日閲覧。
- ^ Ed Burnette (2006年11月2日). “Google says no to license proliferation”. 2011年5月10日閲覧。
- ^ Greg Stein (2009年5月28日). “Standing Against License Proliferation”. 2010年9月11日閲覧。
- ^ Chris DiBona (2010年9月10日). “License Evolution and Hosting Projects on Code.Google.Com”. 2010年9月11日閲覧。
- ^ “Google Codeのライセンス要件が緩和、全OSI承認ライセンスを受け入れへ”. OSDN Magazine (2010年9月15日). 2011年5月10日閲覧。
- ^ “Licenses by Name”. Open Source Initiative. 2011年5月10日閲覧。
- ^ “#11: Simplified, rationalised licensing”. www.markshuttleworth.com (2006年11月8日). 2011年5月10日閲覧。
- ^ “The Licence Proliferation Project”. Open Source Initiative. 2011年5月10日閲覧。
- ^ “Report of License Proliferation Committee and draft FAQ”. Open Source Initiative. 2011年5月10日閲覧。
- ^ a b このライセンスリストの最初期の版では、この立場を明確に反映したものになっていた。 Bradley M. Kuhn (2000年8月15日). “Various Licenses and Comments about Them”. Free Software Foundation. pp. 37–39. オリジナルの2000年8月15日時点におけるアーカイブ。 2000年8月15日閲覧。
- ^ a b “さまざまなライセンスとそれらについての解説”. Free Software Foundation. 2011年5月10日閲覧。
- ^ “How GPLv3 tackles license proliferation”. www.linuxfordevices.com. 2007年1月15日時点のオリジナルよりアーカイブ。2011年5月10日閲覧。
- ^ “How to choose a license for your own work”. Free Software Foundation (2011年5月26日). 2011年5月27日閲覧。
- ^ クリエイティブ・コモンズ・ジャパン (19 February 2010). 賢く著作物を共有する方法 - クリエイティブ・コモンズ・ライセンスの付け方(1/2)（第32回日本分子生物学会年会） (flv) (日本語). クリエイティブ・コモンズ・ジャパン. 該当時間: 4:51-6:12. 2012年1月5日閲覧。
