寛容なソフトウェアライセンス( BSDライクまたはBSDスタイルライセンスとも呼ばれる) [ 1 ]は、コピーレフト保護の代わりに、ソフトウェアの使用、変更、再配布方法に対する制限を最小限に抑え、通常は保証の免責条項を含むフリーソフトウェアライセンスです。例としては、GNU All-permissive License、MIT License、BSDライセンス、Apple Public Source License、Apache Licenseなどがあります。2016年現在、最も人気のあるフリーソフトウェアライセンスは、寛容なMITライセンスです。[ 2 ] [ 3 ]
以下は、シンプルなGNU All-permissive Licenseの全文です。
著作権<年>、<著者>このファイルの複製および配布は、著作権表示およびこの通知が保持されている限り、いかなる媒体においても、変更の有無にかかわらず、ロイヤリティなしで許可されます。このファイルは現状のまま提供され、いかなる保証もありません。
オープンソース・イニシアティブは、寛容なソフトウェア・ライセンスを「使用、変更、再配布の自由を保証する非コピーレフト・ライセンス」と定義しています。 [ 6 ] GitHubのchoosealicenseウェブサイトでは、寛容なMITライセンスを「帰属表示を行い、責任を問わない限り、人々があなたのコードで何でも好きなようにすることを許可する」と説明しています。[ 7 ]カリフォルニア・ウェスタン・ロースクールのnewmediarights.comでは、次のように定義しています。「BSD、MIT、Apacheライセンスなどの『BSDライク』ライセンスは非常に寛容で、ライセンスされたコードの元の部分を自分のコードやドキュメントで元の開発者に帰属表示すること以外にはほとんど何も要求しません。」[ 1 ]
コピーレフトライセンスは一般的に、改変版のソースコードを元の作品のコピーレフトライセンスの下で相互に公開することを要求します。[ 8 ] [ 9 ]一方、寛容ライセンスは、ソフトウェアの改変版が引き続き無料で公開されることを保証しようとはせず、一般的には元の著作権表示を保持することのみを要求します。[ 1 ]その結果、寛容ライセンスのソフトウェアの派生作品、つまり将来のバージョンは、プロプライエタリソフトウェアとしてリリースできます。[ 10 ]
しかし、ライセンスの自由度を定義することは、簡単に定量化できるものではなく、多くの場合、最終ユーザーの目的に依存します。最終ユーザーが開発者である場合、一部の開発者にとっては、他人が書いたソースコードを修正および利用し、それを独自のコードに組み込んで収益を得る権利を持つことが価値があるかもしれません(そのため、これらの開発者は寛容なライセンスが自分たちに「権利」を与えてくれると考えています)[ 11 ]。一方、他の開発者にとっては、ほとんどが自分の仕事であるものを誰も収益化できないことを知る方が価値があるかもしれません(そのため、これらの開発者はコピーレフトライセンスが自分たちに「権利」を与えてくれると考えています)。さらに、最終ユーザーが開発者ではない場合もあり、この場合、コピーレフトライセンスは、ソフトウェアをフリーソフトウェアとして永久に利用する権利を提供し、ソフトウェアがクローズドソースにならないことを保証します。一方、寛容なライセンスは、開発者ではない最終ユーザーには何の権利も与えず、寛容なライセンスでリリースされたソフトウェアは、理論的には、ユーザーが知らないうちに、ある日突然クローズドソースのマルウェアになる可能性があります。
寛容なライセンスは、一般的に相互主義の要件が互いに矛盾するため自由に組み合わせたり混ぜたりできないコピーレフトライセンスよりも、ライセンスの互換性がはるかに広い。 [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ]
Computer Associates Int'l v. Altai 事件では、「パブリックドメイン」という用語は、意図的にパブリックドメインに置かれた作品ではなく、許可を得て広く共有・配布されるようになった作品を指すために用いられました。しかし、寛容なライセンスは、作品をパブリックドメインに公開することと実際には同義ではありません。
寛容なライセンスには、多くの場合、元の著作者のクレジット表示(帰属表示)など、いくつかの限定的な要件が規定されています。作品が真にパブリックドメインにある場合、これは通常、法的に要求されるものではありませんが、米国の著作権登録では、以前に公開された資料を開示する必要があり、[ 17 ]帰属表示は学術界では依然として倫理的要件とみなされる可能性があります。
寛容なライセンスの支持者は、ソフトウェアをパブリックドメインにリリースしようとすると、一部の法域では法的に問題が生じる可能性があるため、そうしないように勧めることが多い。[ 18 ] [ 19 ]パブリックドメイン相当のライセンスは、この問題を解決しようとする試みであり、著作権の放棄が法的に不可能な場合の代替となる寛容なライセンスを提供し、また、ほとんどの寛容なライセンスと同様に保証の免責条項も含まれることがある。

一般的に、寛容なライセンスは、ほとんどの場合、他のほとんどのソフトウェアライセンスと良好なライセンス互換性を持っています。 [ 12 ] [ 13 ]
制限が少ないため、ほとんどの寛容なソフトウェアライセンスは、他のほとんどのライセンスとは互換性がないコピーレフトライセンスとも互換性があります。4条項BSDライセンス、PHPライセンス、OpenSSLライセンスなどの一部の古い寛容なライセンスには、広告資料に著作権者のクレジットを記載することを義務付ける条項が含まれているため、コピーレフトライセンスとは互換性がありませんでした。しかし、MITライセンス、3条項BSDライセンス、zlibライセンスなどの人気のある現代の寛容なライセンスには広告条項が含まれておらず、一般的にコピーレフトライセンスと互換性があります。
派生著作物が再配布者による制限の追加を禁止するライセンスもあります。CDDLやMsPLなどがその例です。しかし、このような制限があると、寛容なフリーソフトウェアライセンスとの互換性が失われてしまいます。
1980年代半ばから使用されてきたが、[ 21 ]いくつかの著者は、2010年代に寛容なライセンスの人気が高まったことを指摘している。[ 22 ] [ 23 ] [ 24 ] [ 25 ]
2015年現在、MITライセンスは寛容なライセンスであり、最も人気のあるフリーソフトウェアライセンスで、GPLv2がそれに続きます。[ 2 ] [ 3 ]
「寛容な」ライセンスとは、単にコピーレフトではないオープンソースライセンスのことである。
「寛容」という言葉は曖昧すぎると考えられることがあります。なぜなら、すべてのフリーソフトウェアライセンスは、ソースコードの変更と再配布を許可するという意味で「寛容」だからです。ほとんどの場合、本当の対立はコピーレフトライセンスと非コピーレフトライセンスの間にあるため、一部の著者は「寛容」の代わりに「非コピーレフト」という用語を使用することを好みます。[ 27 ] [ 28 ] [ 26 ]
バークレーには「コピーセンター」と呼ばれるものがあり、「コピーセンターに持っていけば、好きなだけコピーできる」というものでした。
コピーセンターは、もともとは寛容なフリーソフトウェアライセンスである修正BSDライセンスを説明するために使われた用語です。この用語は、コンピュータ科学者であり、Berkeley Software Distribution (BSD) の貢献者であるマーシャル・カーク・マキュージックが1999年のBSD会議で発表しました。これは、著作権、コピーレフト、コピーセンターを掛け合わせた言葉遊びです。[ 29 ] [ 30 ]
私たちはそれらを「押し付けがましいライセンス」と呼んでいます。なぜなら、あるユーザーが他のユーザーの自由を奪おうとしても、彼らは「ノー」と言えないからです。
—リチャード・ストールマン、GNUオペレーティングシステムの創設者[ 31 ]
フリーソフトウェア財団のライセンス互換性と再ライセンスに関するガイドの中で、リチャード・ストールマンは、寛容なライセンスを「押し付けライセンス」と定義し、それを「ノーと言えない」人々に例えています。なぜなら、それは「他人に自由を否定する」権利を与えるものと見なされているからです。[ 31 ]財団は、コード行数が300行未満の小規模なプログラムにのみ押し付けライセンスを推奨しています。なぜなら、「コピーレフトによって得られるメリットは通常、ライセンスのコピーが常にソフトウェアに付属していることを確認する不便さを正当化するには小さすぎる」からです。[ 32 ]
. MIT ライセンス 24%、2. GNU General Public License (GPL) 2.0 23%、3. Apache License 16%、4. GNU General Public License (GPL) 3.0 9%、5. BSD License 2.0 (3 条項、新規または改訂) License 6%、6. GNU Lesser General Public License (LGPL) 2.1 5%、7. Artistic License (Perl) 4%、8. GNU Lesser General Public License (LGPL) 3.0 2%、9. Microsoft Public License 2%、10. Eclipse Public License (EPL) 2%
1 MIT 44.69%、2 その他 15.68%、3 GPLv2 12.96%、4 Apache 11.19%、5 GPLv3 8.88%、6 BSD 3条項 4.53%、7 無許可 1.87%、8 BSD 2条項 1.70%、9 LGPLv3 1.30%、10 AGPLv3 1.05%
9. GPL の利点と欠点 [..] 12. 結論
オープンソース コードの独占的な商用化を防ぐように設計された GPL とは対照的に、BSD ライセンスは将来の行動に最小限の制限しか課しません。これにより、BSD コードはオープンソースのままにしておくことも、プロジェクトや企業のニーズの変化に応じて商用ソリューションに統合することもできます。言い換えれば、BSD ライセンスは開発プロセスのどの時点でも法的時限爆弾にはなりません。
さらに、BSDライセンスはGPLやLGPLライセンスのような複雑な法的制約がないため、開発者や企業は、コードがライセンスに違反していないかどうかを心配するのではなく、良質なコードの作成と普及に時間を費やすことができます。
フリーまたはオープンソースソフトウェア(FOSS)を配布するためのライセンスは、許容的ライセンスとコピーレフトライセンスの2つのファミリーに分けられます。許容的ライセンス(BSD、MIT、X11、Apache、Zope)は、一般的に他のほとんどのライセンスと互換性があり、相互運用可能で、対象コードのマージ、結合、または改善、および多くのライセンス(非フリーまたは「プロプライエタリ」を含む)の下での再配布を許容します。
寛容なライセンスは物事を簡素化する ビジネス界やますます多くの開発者が寛容なライセンスを好む理由の 1 つは、再利用の容易さです。 ライセンスは通常、ライセンスされたソース コードにのみ適用され、他のコンポーネントに条件を推測しようとはしません。そのため、派生作品を構成するものを定義する必要がありません。 また、寛容なライセンスのライセンス互換性チャートを見たことがありません。すべて互換性があるようです。
インストール情報の提供義務など、GPLv3の要件の一部はGPLv2には存在しません。そのため、これらのライセンスは互換性がありません。両方のライセンスでリリースされたコードを組み合わせようとすると、GPLv2のセクション6に違反することになります。ただし、GPL「バージョン2以降」でリリースされたコードは、GPLv3が許容されるオプションの1つであるため、GPLv3と互換性があります。
GPLv3 は、コードを共有できない互換性のないフォークに「the」GPL を分割しました。
一部の法域では、自分の作品を自発的にパブリック ドメインに置くことが法的に可能かどうか疑わしい。そのため、相当量のコードを自由に利用できるようにするには、パブリック ドメインにリリースしようとするのではなく、著作権を明記し、ISC ライセンスまたは BSD ライセンスの下に置く方が望ましい。
また、当時私は、生涯を米国で過ごしてきたので、ご存知のように、パブリックドメインが認められている英国コモンローの下で生活していたため、世界には、自分の作品をパブリックドメインに置くことが困難または不可能な法域がたくさんあることに気づいていませんでした。私は知りませんでした。それが問題なのです。
当時 X コンソーシアム ライセンスまたは X11 ライセンスとも呼ばれていた MIT ライセンスは、1987 年に X11 と共に結晶化したという十分な主張があり、それが使用するのに最適な日付です。1985 年に作成され、その後数年間で調整された可能性があると主張することもできます。
は依然として世界で最も人気のあるオープンソースライセンスですが、その使用は減少傾向にあり、寛容なライセンスの支持者が増え、一部の開発者はライセンスなしでコードをリリースすることを選択しています。
「寛容な」ライセンスとは、単にコピーレフトではないオープンソースライセンスのことです。
一般的に、緩やかな許可ライセンス (
修正 BSD
、
X11
、
Expat
、
Apache
、
Python
など) は互いに互換性があります。これは、プログラムに追加される他のコードに関する要件がないためです。プログラム全体 (変更を加える可能性あり) を独自のソフトウェア製品に含めることさえ許可しています。そのため、あるユーザーが他のユーザーの自由を否定しようとしても「ノー」と言えないため、私たちはそれらを「押し付けライセンス」と呼びます。