ライセンスの氾濫
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2025/05/03 04:18 UTC 版)
|
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 (2021年10月)
|
ライセンスの氾濫（ライセンスのはんらん、License proliferation）とは、ソフトウェアパッケージ毎にライセンスを改めて作成することによる弊害を指す。ライセンスの拡散、ライセンスの増殖とも訳される。この問題は自由ソフトウェアコミュニティに対し多大なる影響を与えている。
概要
ソフトウェア開発者は異なるソフトウェアプログラムを部分的に組み合わせようと考えることが多いが、しばしば不可能な場合がある。その理由はライセンスが同時に両立しないからである。2つの異なるライセンスで許諾されているソフトウェアを組み合わせ、一つのより大きな著作物とすることが可能な場合、そのライセンスは互換性がある（もしくは、ライセンスは両立する）という。ライセンスの数が増加するにつれて、FOSS開発者が組み合わせたいと考えているソフトウェアが利用可能であっても、互いに両立しないライセンス下での許諾となっている可能性が高まる。また、利用するソフトウェアパッケージの各FOSSライセンスを評価しようと考える組織にとって、これはより大きな負担となる。厳密に述べると、ライセンスの氾濫に賛同している人物や組織などない。むしろこの問題は、ソフトウェアのリリースのために新たなライセンスを作成するという現実的なニーズやそのようなニーズがあると認識したがゆえに、それらニーズに対処しようと新たなライセンスを作成する各組織の傾向に、問題の根幹があるといえる。
互換性のあるライセンス
GNU General Public License（GPL）を管理するフリーソフトウェア財団（Free Software Foundation, FSF）は、GPLと互換性のあるライセンスのリストもまとめている[1]。別の有名なFOSSライセンスとしてApache Licenseが存在する。Apacheソフトウェア財団は各団体との議論を経たのち、ウェブサイトにて次のような事実を述べている[2]。Apache LicenseはGPLv3と両立する。ただしそれは「一方的に」である。すなわちGPLv3ソフトウェアはApache Licenseのソフトウェアを含むことのみできる。しかしその逆はできない。
空虚なライセンス
空虚なライセンス（Vanity licenses）とは、ある企業や人物が特段の理由もなく作成したライセンスを揶揄する用語である。FOSSでより広く知られるライセンスと比べ明白な改善点または相違点がないライセンスを作成した場合、そのライセンスが空虚であると批判されることはしばしばある。
FOSSライセンスとしての要求を満たさず、またその要求自体も知らず、かつ標準的ではないライセンスを利用することがプログラムを第三者にとってほとんど意味のないものとすることに気付かず、新規にリリースしたプログラム向けに新しいライセンスを作成する者が、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日閲覧。 エラー: 閲覧日がウィキペディアの設立以前の日付です。
{{cite news}}:|accessdate=の日付が不正です。 (説明)⚠ - ^ 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日閲覧。
関連項目
外部リンク
ライセンスの氾濫
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2020/12/23 16:35 UTC 版)
「オープンソースライセンス」の記事における「ライセンスの氾濫」の解説
詳細は「ライセンスの氾濫」を参照 2000年代前半、オープンソースソフトウェアのライセンスは多数の独自ライセンスが策定され、よく似た条文で一部分だけ異なるという有象無象のライセンスがいたずらに作られていったことを問題視し、その事象はライセンスの氾濫と呼ばれ批判の対象となった。ライセンスの氾濫はライセンス製作者の虚栄心を満たすだけの無害なものではなく、オープンソースソフトウェアに課せられたライセンスの内容を精査しなければならない利用者を疲弊させる有害なものであった。オープンソース・イニシアティブは2006年にこの問題を解決するためライセンス氾濫問題プロジェクト（License Proliferation Project）を立ち上げ、ライセンスレビューを通して承認ライセンスを選定することでライセンスの氾濫を抑えた歴史がある。ライセンスの氾濫を再発させないため、オープンソースソフトウェアのライセンスは既存のオープンソースライセンスを採用することが推奨される。ライセンスの作成者は新規ライセンスの必要性について慎重な検討を経て策定に至り、ライセンスを承認する団体は新規のライセンスが既存のライセンスと本質的な差異がない場合は承認しない判断を下している。
※この「ライセンスの氾濫」の解説は、「オープンソースライセンス」の解説の一部です。
「ライセンスの氾濫」を含む「オープンソースライセンス」の記事については、「オープンソースライセンス」の概要を参照ください。
- ライセンスの氾濫のページへのリンク
