ライセンスの増殖

ライセンスの増殖とは、 FOSSエコシステムにおけるソフトウェアおよびソフトウェアパッケージにおいて、既存のソフトウェアライセンスが過剰に存在し、新たなライセンスが継続的に創出される現象を指します。ライセンスの増殖は、ますます複雑化するライセンスの選択、ライセンスの相互作用、ライセンスの互換性に関する考慮といった負担によって、FOSSエコシステム全体に悪影響を及ぼします。[ 1 ]

インパクト

ソフトウェア開発者が異なるソフトウェアプログラムの一部を統合したい場合、ライセンスに互換性がないため、統合できないことがよくあります。2 つの異なるライセンスのソフトウェアを 1 つの大きなソフトウェア作品に統合できる場合、そのライセンスは互換性があると言われます。ライセンスの数が増えるほど、フリー オープンソース ソフトウェア(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ライセンスはコピーレフトのGPLv3と互換性がある一方で、GPLv3はパーミッシブなApacheライセンスとは互換性がないという事実を批判しています。ApacheソフトウェアはGPLv3ソフトウェアに含めることができますが、その逆はできません。[ 8 ]別の関連する例として、GPLv2自体はGPLv3と互換性がありません。[ 9 ] 2007年にリリースされたGPLv3は、FOSSエコシステムに互換性のないライセンスを追加したとして、複数の著者から批判されました。[ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ]

バニティライセンス

バニティライセンスとは、企業や個人が独自のライセンスを作成するためだけに作成したライセンスです（「NIH症候群」）。[ 17 ]既存のFOSSライセンスと比べて明らかな改善点や違いがない新しいライセンスが作成された場合、それはしばしばバニティライセンスとして批判されます。2008年現在、多くの人がFOSSライセンスの要件を理解せず、非標準ライセンスを使用することでそのプログラムが他者にとってほとんど役に立たなくなる可能性があることに気づかずに、新しくリリースしたプログラムのためにカスタムライセンスを作成しています。[ 18 ]

解決策のアプローチ

GitHubのスタンス

2013年7月、GitHubはchoosealicenseと呼ばれるライセンス選択ウィザードを開始しました。[ 19 ] GitHubのchoosealicenseトップページでは、 MITライセンス、Apacheライセンス、GNU一般公衆利用許諾書の3つのライセンスのみがクイック選択として提供されています。その他のライセンスはサブページやリンクを通じて提供されています。[ 20 ] 2015年には、GitHub上のライセンス対象プロジェクトの約77%が、これら3つのライセンスの少なくとも1つに基づいてライセンスされていました。[ 21 ]

Googleの立場

2006年からGoogle Codeは以下の7つのライセンスでライセンスされたプロジェクトのみを受け入れるようになりました。[ 22 ]

1年後の2008年頃には、GNU一般公衆利用許諾書3.0が追加され、許容的なApacheライセンスとともに強く推奨されました。[ 23 ]ライセンスの拡散を抑えるためにAGPLv3が除外されたことは注目に値します。[ 24 ]

2010年にGoogleはこれらの制限を取り除き、プロジェクトがOSI承認のライセンスをどれでも使用できるようにすると発表しました（OSIの立場については下記を参照）[ 25 ] 。ただし、パブリックドメインプロジェクトは単一のケースの決定としてのみ許可される という制限があります。

OSIの立場

オープンソース・イニシアティブ（OSI）は、承認済みライセンスのリストを管理しています。[ 26 ] OSIは設立当初から、虚栄心を満たすライセンスや再利用不可能なライセンスを承認することで、ライセンスの拡散を助長してきました。2004年にはOSIライセンス拡散プロジェクトが開始されました。[ 27 ]同プロジェクトは2007年にライセンス拡散レポートを作成しました。[ 28 ]このレポートでは、ライセンスのクラスが以下のように定義されています。

  • 人気があり広く使用されているライセンス、または強力なコミュニティを持つライセンス
  • 国際ライセンス
  • 特別目的ライセンス
  • その他/雑多なライセンス
  • より一般的なライセンスと重複するライセンス
  • 再利用できないライセンス
  • 置き換えられたライセンス
  • 自主的に廃止されたライセンス
  • 分類されていないライセンス

「一般的な」ライセンスのグループには、Apache License 2.0、New BSD ライセンス、GPLv2、LGPLv2、MIT ライセンス、Mozilla Public License 1.1、Common Development and Distribution License、Common Public License、Eclipse Public Licenseの 9 つのライセンスが含まれます。

FSFの立場

フリーソフトウェア財団の元会長リチャード・ストールマンと元事務局長ブラッドリー・M・クーンは、2000年にFSFライセンスリストを制定して以来、ライセンスの乱立に反対している。このリストでは、開発者にGPL互換のフリーソフトウェアライセンスの下でソフトウェアをライセンスするよう促しているが、GPLと互換性のないフリーソフトウェアライセンスも複数リストされており、すでに当該ライセンスの下でソフトウェアを使用および/または開発しても問題はないというコメントが付けられている。一方で、リストの読者には、自分が作成したソフトウェアにはこれらのライセンスを使用しないよう促している。[ 29 ]

FSFヨーロッパのキアラン・オリオーダンは、「GPLv3はライセンスの増殖にどのように対処するか」と題する論説の中で、FSFがライセンスの増殖を防ぐためにできる主なことは、そもそも新しいライセンスを作成する理由を減らすことだと主張している。[ 30 ]一般的にFSFヨーロッパは一貫して可能な限りGNU GPLの使用を推奨しており、それが不可能な場合はGPLと互換性のあるライセンスを使用するように推奨している。

その他

2005年にインテルは、オープンソースライセンスのOSIリストからインテルオープンソースライセンスを自主的に撤回し、ライセンスの拡散を抑えるためにこのライセンスの使用や推奨も中止しました。[ 31 ]

2009年6月、451グループは「オープンソースライセンスの拡散の神話」という拡散レポートを作成しました。[ 32 ]

2009年にワシントン大学ロースクールが発表した「オープンソースライセンスの普及：有益な多様性か絶望的な混乱か？」という論文では、解決策として「より賢いウィザード」（ライセンス選択用）、「ベストプラクティスとレガシーライセンス」、「ハッカー向けの法的サービスの強化」という3つの点を挙げている。[ 33 ]

オープンソース・ソフトウェア・コラボレーション・カウンセリング（OSSCC）は、当初推奨されていた9つのOSIライセンスに基づき、Apacheライセンス2.0、New BSDライセンス、CDDL、MITライセンス、そしてある程度はMPLの5つのライセンスを推奨しています。これらのライセンスは、コラボレーションをサポートし、特許使用を許可し、特許保護を提供するためです。注目すべきはGPLが欠落していることです。「このライセンスは、異なるライセンスが適用されている他の著作物内で使用することはできません。」[ 34 ]

参照

参考文献

  1. ^ a b Martin Michlmayr著、2008年8月21日、FOSSBazaar掲載「OSIとライセンスの拡散」。「ライセンスの種類が多すぎると、ライセンサーの選択が難しくなります。ライセンスの種類が多すぎるため、プロジェクトに適したライセンスを選ぶのが難しくなります。ライセンスによっては、相性の悪いものもあります。オープンソースライセンスの中には、他のオープンソースライセンスと相互運用性が低いものもあり、他のプロジェクトのコードを組み込むのが難しくなります。ライセンスが多すぎると、マルチライセンス配布において何に同意しているのか理解しにくくなります。FOSSアプリケーションには通常、異なるライセンスのコードが含まれており、ユーザーはそれぞれ1つまたは複数のライセンスを含む多くのアプリケーションを使用しているため、どのような義務があるのか​​把握しにくくなります。」
  2. ^「 The Free-Libre / Open Source Software (FLOSS) License Slide」、David A. Wheeler、2007 年 9 月 27 日。
  3. ^ Wheeler, David A. (2014年2月16日). 「オープンソースソフトウェアをGPL互換にしよう。さもなければ」 . 2023年11月13日時点のオリジナルよりアーカイブ。
  4. ^「さまざまなライセンスとそれらについてのコメント」GNU。 2000年8月15日Wayback Machineにアーカイブ。
  5. ^ Laurent, Philippe (2008年9月24日). 「GPLv3と互換性の問題」(PDF) .欧州オープンソース弁護士イベント2008.ナミュール大学（ベルギー）. p. 7.オリジナル(PDF)から2016年3月4日時点のアーカイブ。 2015年5月30日閲覧。コピーレフトは互換性問題の主な原因である。
  6. ^ Hanwell, Marcus D. (2014年1月28日). 「パーミッシブライセンスを使うべきか？ コピーレフトライセンス？ それともその中間か？」 . opensource.com . 2015年5月30日閲覧。パーミッシブライセンスは物事をシンプルにする ビジネス界、そしてますます多くの開発者が [...] パーミッシブライセンスを好む理由の一つは、再利用のシンプルさにあります。このライセンスは通常、ライセンス対象となるソースコードにのみ適用され、他のコンポーネントに何らかの条件を課すことはありません。そのため、派生作品を構成するものを定義する必要がありません。また、パーミッシブライセンスのライセンス互換性チャートも見たことがありませんが、すべて互換性があるように見えます。
  7. ^ 「ライセンスの互換性と相互運用性」。オープンソースソフトウェア - 行政機関向けオープンソースソフトウェアの開発、共有、再利用。joinup.ec.europa.eu。2015年6月17日時点のオリジナルよりアーカイブ。 2015年5月30日閲覧。フリーソフトウェアまたはオープンソースソフトウェア（FOSS）を配布するためのライセンスは、パーミッシブライセンスとコピーレフトライセンスの2種類に分けられます。パーミッシブライセンス（BSD、MIT、X11、Apache、Zope）は、一般的に他のほとんどのライセンスと互換性と相互運用性を備えており、対象となるコードの統合、結合、改良、および多くのライセンス（非フリーライセンスや「プロプライエタリ」ライセンスを含む）の下での再配布が認められています。
  8. ^ Apache Foundation (2015年5月30日). 「GPL互換性」 . 2015年5月30日閲覧。GPLv3ライセンスはApache 2ソフトウェアをGPLv3作品に含めることを認めているため、Apache 2ソフトウェアをGPLv3プロジェクトに含めることができます。しかし、GPLv3ソフトウェアをApacheプロジェクトに含めることはできません。これらのライセンスは一方向のみで互換性がなく、これはASFのライセンス理念とGPLv3の作者による著作権法の解釈によるものです。
  9. ^ 「GNUライセンスに関するよくある質問 - GPLv3はGPLv2と互換性がありますか？」 gnu.org 。 2014年6月3日閲覧。いいえ。GPLv3の一部の要件、例えばインストール情報の提供要件などは、GPLv2には存在しません。そのため、これらのライセンスは互換性がありません。両方のライセンスでリリースされたコードを結合しようとすると、GPLv2の第6条に違反することになります。ただし、コードがGPL「バージョン2以降」でリリースされている場合は、GPLv3がGPLv3で許可されているオプションの1つであるため、GPLv3と互換性があります。
  10. ^ Landley, Rob. 「CELF 2013 Toybox talk」 . landley.net . 2013年8月21日閲覧。GPLv3はGPLを、コードを共有できない互換性のないフォークに分割しました。
  11. ^ Asay, Clark D. 「Michigan Telecommunications and Technology Law Review 第14巻 - 第22008号 一般公衆利用許諾書 バージョン3.0：Foss運動の成否を分ける」 law.umich.edu.結局のところ、GPLv3はライセンスの増殖を招く。
  12. ^ Nikolai Bezroukov (2000). 「GPL、BSD、Artisticライセンスの比較メリット（GPL v.2のウイルス的性質の批判 - あるいはデュアルライセンス構想の擁護）」 。 2001年12月22日時点のオリジナルからのアーカイブ。ウイルス的財産はライセンスの増殖を促し、「GPL強制の悪夢」の一因となっています。これは、他の多くのライセンスがGPLと論理的に両立せず、Linux環境で作業する開発者の作業を不必要に困難にする状況です（KDEがその好例ですが、Pythonはあまり知られていません）。GPLを「聖典」と解釈しようとするこのつまらない試みは、何の成果ももたらさない非生産的な議論だと私は考えています。そして、こうした試みは、様々な「フリーソフトウェア」ライセンスの増殖に直接寄与したのです。
  13. ^ Byfield, Bruce (2011年11月22日). 「フリーソフトウェアが影響力を失う7つの理由：2ページ目」 . Datamation.com . 2013年8月23日閲覧。当時、行き詰まりに直面したこの決定は賢明に思えた。しかし現在、Black Duck Softwareによると、フリーソフトウェアの42.5%でGPLv2が使用され、GPLv3は6.5%未満となっている。
  14. ^ James EJ Bottomley; Mauro Carvalho Chehab; Thomas Gleixner; Christoph Hellwig; Dave Jones; Greg Kroah-Hartman; Tony Luck; Andrew Morton; Trond Myklebust; David Woodhouse (2006年9月15日). 「カーネル開発者のGPLv3に関する立場 - GPLv3の危険性と問題点」 . LWN.net . 2015年3月11日閲覧. [...] FSFはすべてのプロジェクトをGPLv3に移行し、他のすべてのGPLライセンスプロジェクトにも移行を迫る提案をしているため、GPLv3のリリースは、私たちが依存しているオープンソースの世界全体のバルカン化を予見させるものとなるでしょう。
  15. ^ Ronacher, Armin (2013年7月23日). 「著作権廃止後の世界におけるライセンス」 . lucumr.pocoo.org . 2015年11月18日閲覧.ライセンス互換性の混乱 - GPLが絡むと、ライセンスの複雑さはまるで面白くない謎かけのようになります。考慮すべき点があまりにも多く、相互作用も非常に多くなります。そして、GPLの非互換性が依然として人々に実際に影響を与える問題であるという事実を、多くの人が忘れているようです。例えば、すべてがGPLv3にアップグレードされた今、GPLv2とApacheソフトウェアライセンス2.0の非互換性は過去のものになるはずですが、実際にはGPLv2だけに固執している人やGPLv3に同意しない人が多数いるため、一部のApacheソフトウェアライセンスプロジェクトは移行を余儀なくされています。例えば、TwitterのBootstrapは現在、ASL2.0からMITに移行中です。これは、GPLv2との互換性を依然として必要とする人々がいるためです。影響を受けたプロジェクトには、Drupal、WordPress、Joomla、MoinMoin Wikiなどが含まれます。Joomla 3は、GPLv2とASL 2.0という互換性のないライセンスであるにもかかわらず、Bootstrapをバンドルしただけであり、このケースでさえ、人々がもはやライセンスをそれほど気にしていないことを示しています。GPLと互換性がないもう一つの典型的な例としては、GPLと相性の悪いライセンスを持つOpenSSLプロジェクトがあります。このライセンスは、GPLv3とも依然として互換性がありません。この一連の騒動は、一部の悪質な団体がGPLライセンスを使ってライセンス・トロールを始めていることから、特に興味深いものとなっています。
  16. ^ GPL を使用しますか? Armin Ronacher (2009)
  17. ^医療ソフトウェアの共有：医療におけるFOSSライセンス（freesoftwaremagazine.com、Fred Trotter著、2007年6月14日）
  18. ^ 「David A. Wheelerのブログ」dwheeler.com。
  19. ^ GitHubがついにオープンソースライセンスを真剣に受け止める、Simon Phipps著、2013年7月 Infoworld
  20. ^オープンソースライセンスの選択は怖くない - あなたの状況に最も当てはまるのは次のどれですか？ choosealicense.com (2015年11月29日アクセス)
  21. ^ GitHub.com におけるオープンソースライセンスの使用状況（ 2015 年 3 月 9 日、Ben Balter 著）「MIT 44.69%、[...]GPLv2 12.96%、Apache 11.19%、GPLv3 8.88%」
  22. ^ Ed Burnette (2006年11月2日). 「Googleはライセンスの拡散にノーと言っている」 . ZDNet . 2007年2月24日時点のオリジナルよりアーカイブ。 2010年9月11日閲覧。
  23. ^ Greg Stein (2009年5月28日). 「ライセンスの拡散に反対する」 . 2008年6月1日時点のオリジナルよりアーカイブ。2010年9月11日閲覧。
  24. ^ライセンスの増殖 - 少ないほど多く、1 つが最良、 2009 年 1 月 27 日、Ernest M. Park 著「Google の Chris DiBona 氏は、ライセンスの増殖を理由の 1 つとして、Google Code リポジトリの AGPLv3 ライセンスを拒否したことで、OSS コミュニティから激しい非難を浴びました。」
  25. ^ Chris DiBona (2010年9月10日). 「ライセンスの進化とCode.Google.Comでのプロジェクトのホスティング」 . 2010年9月11日閲覧。
  26. ^ opensource.org のOSI 承認ライセンス
  27. ^ opensource.com のライセンス拡散プロジェクト(2004)
  28. ^ライセンス拡散レポートアーカイブ2012-12-12 ウェイバックマシンon opensource.com (2007)
  29. ^ライセンスリストの最も古いアーカイブ版はこの立場を反映しています。Bradley M. Kuhn (2000年8月15日). 「Various Licenses and Comments about Them」 . Free Software Foundation. pp.  37– 39. 2000年8月15日時点のオリジナルよりアーカイブ。 2015年11月29日閲覧。
  30. ^ GPLv3 がlinuxdevices.com のライセンス増殖にどのように対処しているか
  31. ^ Marson, Ingrid (2005年3月31日). 「Intel、オープンソースライセンスの使用を停止」 . cnet.com . CNet . 2014年10月6日閲覧。
  32. ^ the451group.com の「オープンソースライセンスの普及に関する神話」
  33. ^オープンソースライセンスの拡散：有益な多様性か絶望的な混乱か？（law.washington.edu、Robert W. Gomulkiewicz著、2009年）
  34. ^ osscc.net のライセンス互換性
「 https://en.wikipedia.org/w/index.php?title=License_proliferation&oldid=1332732997」より取得