許容型ソフトウェアライセンスは、BSDライクライセンスやBSDスタイルライセンスとも呼ばれ、 [1]コピーレフト保護の代わりにソフトウェアの使用方法、変更方法、再配布方法に最小限の制限のみを課すフリーソフトウェア ライセンスであり、通常は保証の免責事項が含まれます。例としては、GNU All-permissive License、MIT License、BSDライセンス、Apple Public Source License、Apacheライセンスなどがあります。2016年現在、最も人気のあるフリーソフトウェアライセンスは、許容型MITライセンスです。[2] [3][アップデート]
比較表
例
以下は、シンプルなGNU All-permissive Licenseの全文です。
Copyright <YEAR>、<AUTHORS>
このファイルの複製および配布は、著作権表示とこの表示が保持される限り、変更の有無にかかわらず、あらゆる媒体でロイヤリティなしで許可されます。 このファイルは現状のまま提供され、いかなる保証もありません。— GNU全許容ライセンス[4] [5]
定義
オープンソース・イニシアティブは、寛容なソフトウェア・ライセンスを「使用、変更、再配布の自由を保証する非コピーレフト・ライセンス」と定義しています。 [6] GitHubのchoosealicenseウェブサイトでは、寛容なMIT ライセンスを「コードの使用者があなたに帰属を明示し、あなたに責任を負わせない限り、コードの使用を自由に行える」と説明しています。[7] California Western School of Lawの 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]
その他の用語
非コピーレフト
「許容」ライセンスは、単にコピーレフトではないオープンソース ライセンスです。
— オープンソースイニシアティブ、[26]
「許容的」という言葉は、あまりにも曖昧だと考えられることがあります。なぜなら、すべてのフリーソフトウェアライセンスは、ソースコードの変更と再配布を許可するという意味で「許容的」だからです。ほとんどの場合、実際の対立はコピーレフトライセンスと非コピーレフトライセンスの間にあるため、著者の中には「許容的」ではなく「非コピーレフト」という用語を好む人もいます。[27] [28] [26]
コピーセンター
バークレーには「コピーセンター」と呼ばれるものがありました。これは「コピーセンターに持っていけば、好きなだけコピーが作れる」というものです。
— マーシャル・カーク・マクキュージック、[29]
コピーセンターは、もともとは修正BSDライセンス、つまり寛容なフリーソフトウェアライセンスを説明するために使われた用語である。この用語は、コンピュータ科学者でBerkeley Software Distribution (BSD)の貢献者であるマーシャル・カーク・マックシックが1999年のBSDカンファレンスで発表した。これは、著作権、コピーレフト、コピーセンターを掛け合わせた言葉遊びである。[29] [30]
押しつけライセンス
あるユーザーが他のユーザーの自由を否定しようとしても「ノー」と言えないため、私たちはこれを「押しつけライセンス」と呼んでいます。」
— リチャード・ストールマン、GNUオペレーティングシステムの創始者[31]
フリーソフトウェア財団のライセンス互換性と再ライセンスに関するガイドで、リチャード・ストールマンは、許容ライセンスを「プッシュオーバーライセンス」と定義し、それを「ノーと言えない」人々と比較しています。なぜなら、それらは「他人の自由を否定する」権利を与えるものと見なされているからです。[31]財団は、プッシュオーバーライセンスを、コードが300行未満の小さなプログラムにのみ推奨しています。そのようなプログラムでは、「コピーレフトによって得られる利益は通常、ライセンスのコピーが常にソフトウェアに付属していることを確かめる不便さを正当化するには小さすぎる」からです。[32]
参照
- 許可ソフトウェアライセンスのリスト
- ライセンスフリーソフトウェア
- パブリックドメイン相当ライセンス
- フリーソフトウェアライセンス
- フリーソフトウェアとオープンソースソフトウェアのライセンスの比較
- フリーソフトウェア財団
参考文献
- ^ abc New Media Rights (2008-09-12). 「オープンソースライセンスガイド」. California Western School of Law .
- ^ ab 「トップ 20 ライセンス」。Black Duck Software。2015 年 11 月 19 日。2016 年 7 月 19 日時点のオリジナルよりアーカイブ。2015年11 月 19 日閲覧。1
. MIT ライセンス 24%、2. GNU 一般公衆利用許諾書 (GPL) 2.0 23%、3. Apache ライセンス 16%、4. GNU 一般公衆利用許諾書 (GPL) 3.0 9%、5. BSD ライセンス 2.0 (3 条項、新規または改訂) ライセンス 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%
- ^ ab Balter, Ben (2015-03-09). 「GitHub.com でのオープンソースライセンスの使用」. github.com . 2015-11-21閲覧。
「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 Unlicense 1.87%、8 BSD 2条項 1.70%、9 LGPLv3 1.30%、10 AGPLv3 1.05%
- ^ フリーソフトウェア財団、各種ライセンスとそれらに関するコメント、GNU 完全許容ライセンス
- ^ GNU ソフトウェアの保守者向け情報、その他のファイルのライセンス通知
- ^ opensource.org の permissive 「「permissive」ライセンスは、単にコピーレフトではないオープンソース ライセンスです。つまり、使用、変更、再配布の自由を保証する一方で、独自の派生物を許可するライセンスです。」
- ^ choosealicense.com では、オープンソース ライセンスの選択は怖いものではありません。「次のどれがあなたの状況に最も当てはまりますか? – シンプルで許容度の高いライセンスを希望します。」
- ^ 「コピーレフトとは何か」GNU . 2011年4月21日閲覧。
- ^ 「フリーソフトウェアと非フリーソフトウェアのカテゴリ」gnu.org。
- ^ Amadeo, Ron (2018年7月21日). 「Androidに対するGoogleの強硬姿勢:あらゆる手段を使ってオープンソースをコントロール」Ars Technica。
- ^ これを念頭に置き、FreeBSDプロジェクトは企業や商用利用のケースに対して許容ライセンスを提唱しています。彼らは、これらのライセンスは「将来の行動に対する制限は最小限」であり、コピーレフト ライセンスは「法的時限爆弾」であると主張しています。Montague, Bruce (2013-11-13) を参照してください。「オープンソース プロジェクトに BSD スタイルのライセンスを使用する理由」。FreeBSD。2015-11-28に取得。9 . GPL
の利点と欠点 [..] 12. 結論
オープンソース コードの独占的商用化を防ぐように設計された GPL とは対照的に、BSD ライセンスは将来の行動に対する制限を最小限にしています。これにより、プロジェクトや企業のニーズが変わったときに、BSD コードをオープンソースのままにしたり、商用ソリューションに統合したりすることができます。言い換えると、BSD ライセンスは開発プロセスのどの時点でも法的時限爆弾になることはありません。
さらに、BSD ライセンスには GPL ライセンスや LGPL ライセンスのような法的な複雑さが伴わないため、開発者や企業は、コードがライセンスに違反しているかどうかを心配するのではなく、優れたコードの作成と宣伝に時間を費やすことができます。
- ^ ab "ライセンスの互換性".欧州連合公衆利用許諾書. joinup.ec.europa.eu. 2015-06-17 にオリジナルからアーカイブ。 2015-05-30に取得。
フリーまたはオープンソースソフトウェア (FOSS) を配布するためのライセンスは、許容型とコピーレフトの 2 つのファミリーに分かれています。許容型ライセンス (BSD、MIT、X11、Apache、Zope) は、一般に他のほとんどのライセンスと互換性と相互運用性があり、対象となるコードをマージ、結合、または改良し、多くのライセンス (非フリーまたは「プロプライエタリ」を含む) で再配布することを許容しています。
- ^ ab Hanwell, Marcus D. (2014-01-28). 「パーミッシブ ライセンスを使うべきか? コピーレフトか、それともその中間か?」 opensource.com . 2015-05-30取得。
パーミッシブ ライセンスは物事をシンプルにする ビジネスの世界、そしてますます多くの開発者が [...] パーミッシブ ライセンスを好む理由の 1 つは、再利用のシンプルさです。ライセンスは通常、ライセンスが付与されたソース コードにのみ適用され、他のコンポーネントに条件を課すことはありません。そのため、派生作品を構成するものを定義する必要がありません。また、パーミッシブ ライセンスのライセンス互換性チャートも見たことがありません。すべて互換性があるようです。
- ^ 「GNU ライセンスに関するよくある質問 - GPLv3 は GPLv2 と互換性がありますか?」。gnu.org。2014年 6 月 3 日閲覧。
いいえ。インストール情報を提供するという要件など、GPLv3 の一部の要件は GPLv2 には存在しません。結果として、ライセンスは互換性がありません。両方のライセンスでリリースされたコードを結合しようとすると、GPLv2 の第 6 条に違反することになります。ただし、コードが GPL「バージョン 2 以降」でリリースされた場合、GPLv3 は許可されているオプションの 1 つであるため、GPLv3 と互換性があります。
- ^ Landley, Rob. 「CELF 2013 Toybox talk」. landley.net . 2013-08-21取得。
GPLv3 は GPL を、コードを共有できない互換性のないフォークに分割しました。
- ^ 「LinuxとZFSの組み合わせに適用されるGNU GPLの解釈、施行、変更」fsf.org 。 2020年6月8日閲覧。
- ^ 米国著作権局フォーム CO; Ashton-Tate v. Foxも参照
- ^ 「OpenBSD 著作権ポリシー」。OpenBSD プロジェクト。2020年 6 月 9 日閲覧。
一部の法域では、自分の著作物を自発的にパブリック ドメインに置くことが法的に可能かどうかは疑わしい。そのため、コードの実質的な部分を無料にするには、著作権を明記し、パブリック ドメインにリリースするのではなく、ISC または BSD ライセンスの下に置くことが望ましい。
- ^ Hipp, D. Richard. 「SQLite がデータベースとして成功した理由」。The Changelog。
また、私は、ご存知のとおり、イギリスの慣習法のもとにある米国で生まれ育ち、そこではパブリック ドメインが認められているということを、当時は理解していませんでした。自分の作品をパブリック ドメインに置くことが困難または不可能な管轄区域が世界中にたくさんあることには、気付いていませんでした。知りませんでした。それが複雑な点です。
- ^ デビッド・A・ウィーラーによるフリー・リブレ/オープンソースソフトウェア(FLOSS)ライセンススライド、2021年10月4日
- ^ Haff, Gordon. 「MITライセンスの謎の歴史」。opensource.com 。 2020年6月8日閲覧。
当時はXコンソーシアムまたはX11ライセンスとも呼ばれていたMITライセンスは、1987年にX11とともに結晶化し、それが最も適した日付であるという説得力のある議論があります。1985年に作成され、その後数年間で調整される可能性があると主張することもできます。
- ^ Vaughan-Nichols, Steven J. 「GPL の衰退と許容型オープンソース ライセンスの台頭」。ZDNet。2015年11 月 28 日閲覧。GPL
は今でも世界で最も人気のあるオープンソース ライセンスですが、使用は減少傾向にあります。一方、許容型ライセンスの支持者は増えており、開発者の中にはライセンスなしでコードをリリースすることを選択する人もいます。
- ^ Ronacher, Armin (2013-07-23). 「著作権後の世界におけるライセンス」 lucumr.pocoo.org . 2015-11-18閲覧。
- ^ Aslett, Matthew (2011-06-06). 「The trend toward permissive licenses」. the451group.com. 2015-10-13 にオリジナルからアーカイブ。2015-11-28 に閲覧。
- ^ コードにライセンスは必要ですか? 2013 年 5 月 2 日、Jason Hibbets が投稿 「Q: ソフトウェア開発会社の中には、特定のオープンソース ライセンスを他のライセンスよりも好む会社はありますか? コミュニティの傾向はどのようなものですか? A: コピーレフト ライセンスから、主に許容ライセンスへと向かう傾向が確かに見られます。」
- ^ ab 「よくある質問 | オープンソース・イニシアティブ」。オープンソース・イニシアティブ。 2022年8月9日閲覧。
「許容」ライセンスとは、単にコピーレフトではないオープンソースライセンスのことである。
- ^ 「フリー/オープンソースソフトウェアにおけるコピーレフトライセンスと非コピーレフトライセンス」Qoppa Software 2014-11-21 2022-08-09閲覧。
- ^ Sen, Ravi; Subramaniam, Chandrasekar; Nelson, Matthew L. (2011). 「オープンソースソフトウェアライセンス:強力なコピーレフト、非コピーレフト、それともその中間か?」。意思決定支援システム。52 (1 ) : 199–206。doi :10.1016/j.dss.2011.07.004。ISSN 0167-9236 。2022年8月9日閲覧。
- ^ ab 「「copycenter」に関するKirkのコメントを追加してください。見逃すにはもったいないです」。FreeBSDの歴史的fortune(6)データベース。 2020年6月8日閲覧。
- ^ Raymond, Eric S. 「コピーセンター」。The Jargon File。
- ^ ab Stallman, Richard (2016-02-08). 「ライセンスの互換性と再ライセンス」.フリーソフトウェア財団. 2019-09-29取得。
一般的に、緩い許容ライセンス (
修正 BSD
、
X11
、
Expat
、
Apache
、
Python
など) は互いに互換性があります。これは、プログラムに追加される他のコードに関する要件がないためです。プログラム全体を (おそらく変更を加えて) プロプライエタリなソフトウェア製品にすることさえ許可します。したがって、1 人のユーザーが他のユーザーの自由を否定しようとしたときに「ノー」と言うことができないため、私たちはこれを「押しつけライセンス」と呼んでいます。
- ^ 自分の作品のライセンスを選択する方法 – フリーソフトウェア財団
