許容ソフトウェアライセンス

パーミッシブ・ソフトウェア・ライセンス（Permissive Software License）は、 BSDライク・ライセンスやBSDスタイル・ライセンスとも呼ばれる^{[ 1 ]}フリーソフトウェア・ライセンスの一種で、コピーレフト保護の代わりに、ソフトウェアの使用、改変、再配布に関して最小限の制限しか課さない。通常は保証の放棄が含まれる。例としては、GNU All-permissive License、MIT License、BSDライセンス、Apple Public Source License、Apacheライセンスなどがある。2016年現在、最も人気のあるフリーソフトウェア・ライセンスは、パーミッシブ・MITライセンスである^{[ 2 ]}。^{[ 3 ]}

比較表

	パブリックドメイン および同等のもの	許容ライセンス	コピーレフト（保護ライセンス）	非商用ライセンス	独自のライセンス	企業秘密
説明	すべての権利を付与する	使用権を付与し、ほとんど何も禁止しない（独占化、ライセンスの互換性を許可する）	使用権を付与し、所有権の取得を禁止する	非営利目的のみに権利を付与します。コピーレフトと併用することも、併用しないこともできます。	著作権の伝統的な使用法。権利を付与する必要はない。	情報は公開されていない
ソフトウェア	PD、CC0	BSD、MIT、Apache	GPL、AGPL	JRL、AFPL	プロプライエタリソフトウェア、パブリックライセンスなし	プライベートな社内ソフトウェア
その他の創作作品	PD、CC0	CC BY	CC BY-SA、フリーアートライセンス	CC BY-NC , CC BY-NC-SA	著作権、パブリックライセンスなし	未発表

例

以下は、シンプルなGNU All-permissive Licenseの全文です。

著作権 <YEAR>, <AUTHORS>このファイルは、改変の有無にかかわらず、著作権表示とこの表示が保持されている限り、いかなる媒体においても無償で複製および配布できます。このファイルは現状有姿で提供され、いかなる保証もありません。

— GNU All-permissive License ^{[ 4 ] [ 5 ]}

定義

オープンソース・イニシアティブは、寛容なソフトウェアライセンスを「使用、改変、再配布の自由を保証する非コピーレフトライセンス」と定義しています。 ^{[ 6 ]} GitHubのchoosealicenseウェブサイトでは、寛容なMITライセンスを「コードの使用者が、あなたに帰属を明示し、責任を負わせない限り、コードに対して何をしても構わない」と説明しています。^{[ 7 ]}カリフォルニア・ウェスタン・スクール・オブ・ローのnewmediarights.comは、寛容なMITライセンスを次のように定義しています。「BSDライセンス、MITライセンス、Apacheライセンスなどの『BSDライク』ライセンスは非常に寛容であり、ライセンス対象コードのオリジナル部分を、自身のコードやドキュメントでオリジナルの開発者に帰属させるだけで十分です。」^{[ 1 ]}

コピーレフトとの比較

コピーレフトライセンスでは、一般的に、元の作品のコピーレフトライセンスの下で改変されたバージョンのソースコードを相互に公開することが求められます。^{[ 8 ] [ 9 ]}一方、許容ライセンスでは、改変されたバージョンのソフトウェアが無料で公開されることを保証せず、一般的に元の著作権表示を保持することのみを要求します。^{[ 1 ]}その結果、許容ライセンスのソフトウェアの派生作品や将来のバージョンは、プロプライエタリソフトウェアとしてリリースされる可能性があります。^{[ 10 ]}

しかし、ライセンスの自由度を定量的に定義することは容易ではなく、多くの場合、最終ユーザーの目的によって決まります。もし最終ユーザーが開発者であれば、他者が書いたソースコードを変更・活用し、場合によってはプロプライエタリコードに組み込んで収益を得る権利を持つことは、一部の開発者にとって価値のあることかもしれません（そのため、彼らは許容型ライセンスを「権利」を提供するものと見なします）。^{[ 11 ]}一方、他の開発者にとっては、ほとんどが自分たちの成果物であるものを誰も資本化しないことを知ることの方が価値のあることかもしれません（そのため、彼らはコピーレフトライセンスを「権利」を提供するものと見なします）。さらに、最終ユーザーが開発者ではない場合もあり、その場合、コピーレフトライセンスは、ソフトウェアをフリーソフトウェアとして永続的にアクセスするための権利を提供し、それがクローズドソースになることがないように保証します。一方、許容型ライセンスは開発者以外の最終ユーザーにはいかなる権利も提供しません。許容型ライセンスでリリースされたソフトウェアは、理論的には、ユーザーが気付かないうちに、ある日突然クローズドソースのマルウェアに変わる可能性があります。

許容ライセンスは、コピーレフトライセンスよりも広範なライセンス互換性を提供します。コピーレフトライセンスは、相互性の要件が互いに矛盾するため、一般的に自由に組み合わせたり混ぜたりすることができません。^{[ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ]}

パブリックドメインとの比較

Computer Associates Int'l v. Altai事件では、「パブリックドメイン」という用語が、意図的にパブリックドメインに置かれた作品ではなく、許可を得て広く共有・頒布されている作品を指すために使用されました。しかし、許容ライセンスは、実際には作品をパブリックドメインに解放することと同等ではありません。

許容ライセンスでは、原著者のクレジット表示（帰属表示）など、限定的な要件がしばしば規定されます。作品が真にパブリックドメインである場合、これは通常法的に義務付けられていませんが、米国の著作権登録では、過去に出版された資料の開示が義務付けられており^{[ 17 ]} 、学術界では依然として帰属表示が倫理的要件とみなされる場合があります。

許容ライセンスの支持者は、一部の法域では法的に問題になる可能性があるという理由で、ソフトウェアをパブリックドメインにリリースしようとしないことを推奨することが多い。^{[ 18 ] [ 19 ]}パブリックドメインと同等のライセンスは、この問題を解決するための試みであり、著作権の放棄が法的に不可能な場合に備えてフォールバックの許容ライセンスを提供し、場合によってはほとんどの許容ライセンスと同様の保証の免責事項も含める。

ライセンスの互換性

David A. Wheeler（2007）によると、一般的なフリーソフトウェアライセンスとオープンソースソフトウェア（FOSS）ライセンス間のライセンス互換性は次のとおりです。ベクトル矢印は一方向の互換性を示しており、左側（「許容ライセンス」）の方が右側（「コピーレフトライセンス」）よりも互換性が高くなります。^{[ 20 ]}

一般的に、許容ライセンスは、ほとんどの状況において他のほとんどのソフトウェアライセンスと良好なライセンス互換性を持っています。 ^{[ 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 ]}

参照

• 許可ソフトウェアライセンスのリスト
• ライセンスフリーソフトウェア
• パブリックドメイン同等ライセンス
• フリーソフトウェアライセンス
• フリーソフトウェアとオープンソースソフトウェアのライセンスの比較
• フリーソフトウェア財団

参考文献

1. New Media Rights (2008-09-12). 「オープンソースライセンスガイド」カリフォルニア・ウェスタン・スクール・オブ・ロー.
2. 「上位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劣等一般公衆利用許諾書 (LGPL) 2.1 5%、7. Artisticライセンス (Perl) 4%、8. GNU劣等一般公衆利用許諾書 (LGPL) 3.0 2%、9. Microsoftパブリックライセンス 2%、10. Eclipseパブリックライセンス (EPL) 2%
3. Balter, Ben (2015年3月9日). 「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 無ライセンス 1.87%、8 BSD 2条項 1.70%、9 LGPLv3 1.30%、10 AGPLv3 1.05%
4. フリーソフトウェア財団、各種ライセンスとそれらに関するコメント、GNU All-permissive License
5. GNUソフトウェアの保守者向け情報、その他のファイルのライセンス通知
6. opensource.org のpermissiveより 「「permissive」ライセンスとは、単にコピーレフトではないオープンソース ライセンスです。つまり、使用、変更、再配布の自由を保証する一方で、独自の派生物を許可するライセンスです。」
7. choosealicense.com では、オープンソース ライセンスの選択はそれほど難しいことではありません。「次のどれがあなたの状況を最もよく表していますか? – シンプルで許容度の高いライセンスを希望します。」
8. 「コピーレフトとは何か」 GNU 2011年4月21日閲覧。
9. 「フリーソフトウェアと非フリーソフトウェアのカテゴリー」 gnu.org。
10. Amadeo, Ron (2018年7月21日). 「GoogleのAndroidに対する鉄の支配：あらゆる手段を使ってオープンソースをコントロール」 Ars Technica .
11. これを念頭に、 FreeBSDプロジェクトは企業や商用利用において、許容ライセンスを推奨しています。彼らは、これらのライセンスは「将来の行動に対する制限は最小限」であり、コピーレフトライセンスは「法的時限爆弾」であると主張しています。Montague , Bruce (2013-11-13). 「オープンソースプロジェクトにBSDスタイルのライセンスを使うべき理由」 . FreeBSD . 2015-11-28参照。9 . GPLの長所と短所 [..] 12. 結論オープンソースコードの独占的商用化を防ぐことを目的としたGPLとは対照的に、BSDライセンスは将来の行動に対する制限を最小限に抑えています。これにより、プロジェクトや企業のニーズの変化に応じて、BSDコードをオープンソースのままにしたり、商用ソリューションに統合したりすることができます。言い換えれば、BSDライセンスは開発プロセスのどの段階でも法的時限爆弾になることはありません。さらに、BSD ライセンスには GPL ライセンスや LGPL ライセンスのような法的な複雑さが伴わないため、開発者や企業は、コードがライセンスに違反しているかどうかを心配するのではなく、優れたコードの作成と宣伝に時間を費やすことができます。
12. 「ライセンスの互換性」 .欧州連合パブリックライセンス. joinup.ec.europa.eu . 2015年6月17日アーカイブ。2015年5月30日閲覧。フリーソフトウェアまたはオープンソースソフトウェア（FOSS）を配布するためのライセンスは、パーミッシブライセンスとコピーレフトライセンスの2種類に分けられます。パーミッシブライセンス（BSD、MIT、X11、Apache、Zope）は、一般的に他のほとんどのライセンスと互換性と相互運用性を備えており、対象となるコードの統合、結合、改良、および多くのライセンス（非フリーまたは「プロプライエタリ」ライセンスを含む）の下での再配布が認められています。
13. Hanwell, Marcus D. (2014-01-28). 「パーミッシブライセンスを使うべきか？ コピーレフトライセンス？ それともその中間か？」 opensource.com . 2015-05-30閲覧。パーミッシブライセンスは物事をシンプルにする ビジネス界、そしてますます多くの開発者が [...] パーミッシブライセンスを好む理由の一つは、再利用のシンプルさにあります。ライセンスは通常、ライセンス対象となるソースコードにのみ適用され、他のコンポーネントに何らかの条件を課すことはありません。そのため、派生作品を構成するものを定義する必要がありません。また、パーミッシブライセンスのライセンス互換性チャートも見たことがありませんが、すべて互換性があるようです。
14. 「GNUライセンスに関するよくある質問 – GPLv3はGPLv2と互換性がありますか？」 gnu.org 。 2014年6月3日閲覧。いいえ。GPLv3の要件の一部、例えばインストール情報の提供要件などは、GPLv2には存在しません。そのため、これらのライセンスは互換性がありません。両方のライセンスでリリースされたコードを結合しようとすると、GPLv2の第6条に違反することになります。ただし、コードがGPL「バージョン2以降」でリリースされている場合は、GPLv3がGPLv3で許可されているオプションの1つであるため、GPLv3と互換性があります。
15. Landley, Rob. 「CELF 2013 Toybox talk」 . landley.net . 2013年8月21日閲覧。GPLv3はGPLをコードを共有できない非互換性のフォークに分割しました。
16. 「LinuxとZFSの組み合わせに適用されるGNU GPLの解釈、施行、変更」 . fsf.org . 2020年6月8日閲覧。
17. 米国著作権局様式CO 。アシュトン・テイト対フォックス事件も参照
18. 「OpenBSD著作権ポリシー」 . OpenBSDプロジェクト. 2020年6月9日閲覧。一部の法域では、自らの著作物を自発的にパブリックドメインに置くことが法的に可能かどうかは疑問です。そのため、コードの実質的な部分をフリーにするには、パブリックドメインにリリースするのではなく、著作権を明記し、ISCライセンスまたはBSDライセンスを適用することが望ましいと考えられます。
19. Hipp, D. Richard. 「SQLiteがデータベースとして成功した理由」 . The Changelog.また、私は当時、ご存知の通りイギリスのコモンローに基づくアメリカ合衆国で生まれ育ち、そこではパブリックドメインが認められていることを認識していませんでした。世界には、作品をパブリックドメインに置くことが困難、あるいは不可能な法域が数多くあることも知りませんでした。知らなかったのです。それが事態を複雑にしていたのです。
20. フリー・リブレ/オープンソースソフトウェア（FLOSS）ライセンスに関するスライド（David A. Wheeler著、2021年10月4日）
21. Haff, Gordon. 「MITライセンスの謎めいた歴史」 . opensource.com . 2020年6月8日閲覧。MITライセンス（当時はXコンソーシアムまたはX11ライセンスとも呼ばれていた）は、1987年にX11とともに誕生し、その日付を用いるのが最適であるという説は説得力があり、1985年に作成され、その後数年間にわたって調整が加えられたと主張することもできる。
22. Vaughan-Nichols, Steven J. 「GPLの衰退と許容型オープンソースライセンスの台頭」 ZDNet 2015年11月28日閲覧。GPLは依然として世界で最も人気のあるオープンソースライセンスですが、利用は減少傾向にあります。一方、許容型ライセンスは支持者を増やしており、一部の開発者はライセンスを一切付与せずにコードをリリースすることを選んでいます。
23. Ronacher, Armin (2013年7月23日). 「著作権後の世界におけるライセンス」 . lucumr.pocoo.org . 2015年11月18日閲覧。
24. Aslett, Matthew (2011-06-06). 「許容型ライセンスへの傾向」 . the451group.com. 2015年10月13日時点のオリジナルよりアーカイブ。 2015年11月28日閲覧。
25. コードにライセンスは必要ですか？ 2013年5月2日投稿 Jason Hibbets「Q: ソフトウェア開発会社の中には、特定のオープンソースライセンスを他のライセンスよりも好む企業はありますか？ コミュニティの傾向はどうですか？ A: コピーレフトライセンスから、主にパーミッシブライセンスへと移行する傾向が確かに見られます。」
26. 「よくある質問 | オープンソース・イニシアティブ」オープンソース・イニシアティブ2022年8月9日閲覧。「パーミッシブ」ライセンスとは、単にコピーレフトではないオープンソースライセンスのことである。
27. 「フリー／オープンソースソフトウェアにおけるコピーレフトライセンスと非コピーレフトライセンス」Qoppa Software . 2014年11月21日. 2022年8月9日閲覧。
28. Sen, Ravi; Subramaniam, Chandrasekar; Nelson, Matthew L. (2011). 「オープンソースソフトウェアライセンス：強力なコピーレフト、非コピーレフト、それともその中間か？」 . Decision Support Systems . 52 (1): 199– 206. doi : 10.1016/j.dss.2011.07.004 . ISSN 0167-9236 . 2022年8月9日閲覧。 
29. 「「copycenter」に関するKirkのコメントを追加。見逃せない魅力が満載です」。FreeBSDの歴史的fortune(6)データベース。2020年6月8日閲覧。
30. レイモンド、エリック・S. 「コピーセンター」。ジャーゴンファイル。
31. Stallman, Richard (2016-02-08). 「ライセンスの互換性と再ライセンス」 .フリーソフトウェア財団. 2019-09-29閲覧.一般的に、緩い許容ライセンス（修正BSD、X11、Expat、Apache、Pythonなど）は互いに互換性があります。これは、プログラムに追加される他のコードに関する要件がないためです。プログラム全体を（場合によっては変更を加えて）プロプライエタリソフトウェア製品に組み込むことさえ許可します。そのため、あるユーザーが他のユーザーの自由を否定しようとしても「ノー」と言えないため、「押しつけライセンス」と呼ばれます。
32. 自分の作品に適したライセンスの選び方 – フリーソフトウェア財団

外部リンク

「 https://en.wikipedia.org/w/index.php?title=Permissive_software_license&oldid=1330485469」より取得