Loading article…
ライセンスの増殖とは、 FOSSエコシステムにおけるソフトウェアおよびソフトウェアパッケージに対して、既に存在するライセンスが大量に存在し、かつ新しいライセンスが継続的に作成される現象のことです。ライセンスの増殖は、ライセンスの選択、ライセンス間の相互作用、およびライセンスの互換性に関する考慮事項がますます複雑化する負担によって、FOSSエコシステム全体に悪影響を及ぼします。[ 1 ]
ソフトウェア開発者が異なるソフトウェアプログラムの一部を統合したい場合、ライセンスが互換性がないため統合できないことがよくあります。2つの異なるライセンスのソフトウェアをより大きなソフトウェア作品に統合できる場合、ライセンスは互換性があると言われます。ライセンスの数が増えるにつれて、フリーでオープンソースのソフトウェア(FOSS) 開発者が互換性のないライセンスで利用可能なソフトウェアを統合したいと考える可能性が高くなります。また、使用するソフトウェア パッケージのすべての FOSS ライセンスを評価したい企業にとっては、コストも大きくなります。[ 1 ]厳密に言えば、ライセンスの増加を支持する人はいません。むしろ、問題は、組織がソフトウェア リリースの実際のニーズまたは認識されたニーズに対応するために新しいライセンスを作成する傾向があることに起因します。
ライセンスの乱立は、ライセンス同士の互換性関係が限定的または複雑な場合に特に問題となります。そのため、広く使用されているGNU General Public License (GPL) との互換性を重要な特性と考える人もいます。例えば、David A. Wheeler [ 2 ] [ 3 ]や、GPL と互換性のあるライセンスのリストを維持しているFree Software Foundation (FSF) などが挙げられます。 [ 4 ]一方、コピーレフト ライセンスではなく、パーミッシブ ライセンスを推奨する人もいます。 [ 5 ]パーミッシブ ライセンスは、より多くのライセンスとの互換性が高いためです。[ 6 ] [ 7 ]例えば、 Apache Foundation は、Apache License はコピーレフト GPLv3 と互換性がある一方で、GPLv3 はパーミッシブ Apache License と互換性がないことを批判しています。つまり、 Apache ソフトウェアは GPLv3 ソフトウェアに含めることができますが、その逆はできません。 [ 8 ]また、関連する別の例として、GPLv2自体がGPLv3と互換性がないことも挙げられます。[ 9 ] 2007年にリリースされたGPLv3は、FOSSエコシステムに互換性のないライセンスを追加したとして、複数の著者から批判された。[ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ]
虚栄ライセンスとは、企業や個人が独自のライセンスを作成するためだけに作成したライセンスのことです（「NIH症候群」）。[ 17 ]より一般的なFOSSライセンスと比べて明らかな改善点や違いがない新しいライセンスが作成された場合、それは虚栄ライセンスとして批判されることがよくあります。2008年現在、多くの人がFOSSライセンスの要件を知らず、非標準ライセンスを使用するとそのプログラムが他の人にとってほとんど役に立たなくなる可能性があることに気づかずに、新しくリリースしたプログラム用に独自の新しいライセンスを作成しています。[ 18 ]
2013 年 7 月、GitHub はchoosealicenseと呼ばれるライセンス選択ウィザードを開始しました。[ 19 ] GitHub のchoosealicenseのトップページでは、 MIT ライセンス、Apache ライセンス、GNU General Public License の3 つのライセンスのみがクイック選択として提供されています。その他のライセンスは、サブページやリンクから提供されています。[ 20 ] 2015 年までに、GitHub 上のライセンスされたプロジェクトの約 77% が、これら 3 つのライセンスのうち少なくとも 1 つでライセンスされていました。[ 21 ]
2006年から、Google Code は以下の 7 つのライセンスでライセンスされたプロジェクトのみを受け入れています。[ 22 ]
1年後の2008年頃、GNU General Public License 3.0が追加され、寛容なApacheライセンスとともに強く推奨された[ 23 ]。ライセンスの乱立を減らすため、AGPLv3は除外された[ 24 ] 。
2010年、Googleはこれらの制限を撤廃し、OSIが承認したライセンスであればどのライセンスでもプロジェクトで使用できると発表した（OSIの立場については下記参照）[ 25 ]が、パブリックドメインのプロジェクトは個別のケースとしてのみ許可されるという制限があった。
オープンソース・イニシアティブ（OSI）は、承認されたライセンスのリストを管理しています。[ 26 ] OSIは設立当初、無個性なライセンスや再利用不可能なライセンスを承認することで、ライセンスの普及に貢献しました。2004年にOSIライセンス普及プロジェクトが開始されました。[ 27 ] 2007年にはライセンス普及レポートが作成されました。[ 28 ]このレポートでは、ライセンスのクラスが定義されています。
「人気のある」ライセンスのグループには、Apache License 2.0、New BSD license、GPLv2、LGPLv2、MIT license、Mozilla Public License 1.1、Common Development and Distribution License、Common Public License、Eclipse Public Licenseの 9 つのライセンスが含まれます。
フリーソフトウェア財団の元会長であるリチャード・ストールマンと、元事務局長であるブラッドリー・M・クーンは、2000年にFSFライセンスリストを制定して以来、ライセンスの乱立に反対してきた。FSFライセンスリストは、開発者にGPL互換のフリーソフトウェアライセンスでソフトウェアをライセンスするよう促しているが、GPL非互換のフリーソフトウェアライセンスも複数掲載されており、既に当該ライセンスでライセンスされているソフトウェアを使用したり、作業したりすることに問題はないとのコメントが添えられている。また、リストの読者には、自分で作成するソフトウェアにこれらのライセンスを使用しないよう促している。[ 29 ]
FSF EuropeのCiarán O'Riordanは、 「GPLv3がライセンスの増殖にどう対処するか」と題した論説の中で、FSFがライセンスの増殖を防ぐためにできる主なことは、そもそも新しいライセンスを作成する理由を減らすことだと主張している。[ 30 ]一般的にFSF Europeは、可能な限りGNU GPLを使用することを一貫して推奨しており、それが不可能な場合はGPL互換ライセンスを使用することを推奨している。
2005年、インテルは自主的にインテル・オープンソース・ライセンスをOSIのオープンソース・ライセンス一覧から削除し、ライセンスの乱立を減らすためにこのライセンスの使用や推奨も中止した。[ 31 ]
2009年6月、451グループは「オープンソースライセンスの拡散の神話」という拡散レポートを作成した。[ 32 ]
2009年にワシントン大学ロースクールが発表した「オープンソースライセンスの増殖：有益な多様性か、それとも絶望的な混乱か？」と題された論文では、解決策として「より賢いウィザード」（ライセンス選択用）、「ベストプラクティスとレガシーライセンス」、「ハッカーのためのより多くの法的サービス」の3つが求められた。[ 33 ]
オープンソースソフトウェアコラボレーションカウンセリング（OSSCC）は、当初推奨された 9 つの OSI ライセンスに基づいて、コラボレーションをサポートし、特許の使用を許可し、特許保護を提供する 5 つのライセンス、すなわち Apache License 2.0、New BSD License、CDDL、MIT ライセンス、およびある程度 MPL を推奨しています。注目すべきは、GPL が「このライセンスは、別のライセンスの下で他の作品内で使用することはできません」という理由で除外されていることです。 [ 34 ]
コピーレフトは互換性問題の主な原因である。
寛容なライセンスは物事を簡素化する ビジネス界やますます多くの開発者が寛容なライセンスを好む理由の 1 つは、再利用の容易さにある。ライセンスは通常、ライセンスされるソース コードのみに関係し、他のコンポーネントに条件を推測しようとはしないため、派生作品を構成するものを定義する必要がない。また、寛容なライセンスのライセンス互換性チャートを見たこともない。すべて互換性があるように思われる。
フリーまたはオープンソースソフトウェア (FOSS) を配布するためのライセンスは、許容的ライセンスとコピーレフトライセンスの 2 つのファミリーに分けられます。許容的ライセンス (BSD、MIT、X11、Apache、Zope) は、一般的に他のほとんどのライセンスと互換性があり、相互運用可能で、対象コードのマージ、結合、改良、および多くのライセンス (非フリーまたは「プロプライエタリ」を含む) の下での再配布を許容します。
したがって、Apache 2 ソフトウェアは GPLv3 プロジェクトに含めることができます。GPLv3 ライセンスは、当社のソフトウェアを GPLv3 作品に含めることを認めているからです。ただし、GPLv3 ソフトウェアは Apache プロジェクトに含めることはできません。ライセンスは一方通行でのみ互換性がなく、これは ASF のライセンス哲学と GPLv3 の著者による著作権法の解釈の結果です。
いいえ。インストール情報の提供義務など、GPLv3の要件の一部はGPLv2には存在しません。そのため、これらのライセンスは互換性がありません。両方のライセンスでリリースされたコードを組み合わせようとすると、GPLv2のセクション6に違反することになります。ただし、GPL「バージョン2以降」でリリースされたコードは、GPLv3が許容されるオプションの1つであるため、GPLv3と互換性があります。
GPLv3 は、コードを共有できない互換性のないフォークに「the」GPL を分割しました。
結局、GPLv3はライセンスの増殖を意味する。
ウイルス性はライセンスの増殖を促し、「GPL 強制悪夢」に寄与します。これは、他の多くのライセンスが論理的に GPL と互換性がなく、Linux 環境で作業する開発者にとって不必要に困難な状況になるというものです (KDE が良い例で、Python はあまり知られていない例です)。GPL を「聖典」として解釈しようとするこの些細な努力は、どこにも行き着かない非生産的な議論だと思います。そして、これらはさまざまな「フリー ソフトウェア」ライセンスの増殖に直接寄与しました。
賢明に思えた。しかし現在、Black Duck Softwareによると、フリーソフトウェアの42.5%でGPLv2が使用され、GPLv3は6.5%未満となっている。
[...] FSF はすべてのプロジェクトを GPLv3 に移行し、他のすべての GPL ライセンスのプロジェクトにも移行するよう圧力をかけることを提案しているため、GPLv3 のリリースは、私たちが依存しているオープンソースの世界全体の
バルカン化
の前兆であると予想されます。
ライセンスの互換性の混乱 - GPL が関係する場合、ライセンスの複雑さは、面白くないバージョンの謎解きになります。考慮すべきことが非常に多く、考慮すべき相互作用も非常に多くあります。そして、GPL の非互換性が依然として人々に影響を与える問題であるという事実を、多くの人が忘れているようです。たとえば、すべてが GPLv3 にアップグレードされるようになった今、GPLv2 と Apache Software License 2.0 の非互換性は過去のものになっているはずだと考える人もいるでしょうが、実際には、GPLv2 しか使えない人や GPLv3 に同意しない人が十分にいるため、Apache Software License のプロジェクトの一部は移行する必要があることが判明しています。例えば、TwitterのBootstrapは現在、ASL2.0からMITに移行中ですが、これはGPLv2との互換性を必要とするユーザーがまだいるためです。影響を受けたプロジェクトには、Drupal、WordPress、Joomla、MoinMoin Wikiなどがあります。この事例からもわかるように、Joomla 3は互換性のないライセンス（GPLv2とASL 2.0）であるにもかかわらずBootstrapをバンドルしており、ライセンスに対する人々の関心はもはやそれほど高くありません。GPLと互換性がないもう一つの伝統的な例は、GPLと相性の悪いライセンスを持つOpenSSLプロジェクトです。このライセンスはGPLv3とも互換性がありません。この一連の出来事は、一部の悪質な団体がGPLライセンスを利用してライセンストローリングを始めたことで、特に興味深いものとなっています。