フリーソフトウェアライセンス

ソフトウェアの黎明期には、ソフトウェアやソースコードの共有は、例えば学術機関などの特定のコミュニティで一般的でした。米国著作権作品新技術利用委員会（CONTU）が1974年に「コンピュータプログラムは、著者の独創的な創作物を具現化している限り、著作権の適切な対象である」と決定するまでは^{[ 4 ] [ 5 ]}、ソフトウェアは著作権の対象とはみなされていませんでした。そのため、ソフトウェアにはライセンスが付いておらず、パブリックドメインのソフトウェアとして共有されていました。CONTUの決定と、オブジェクトコードに関する1983年のApple v. Franklinなどの裁判所の判決により、著作権法がコンピュータプログラムに文学作品と同等の著作権の地位を与え、ソフトウェアのライセンス供与が始まりました。

1980年代後半以前のフリーソフトウェアのライセンスは、一般的に開発者自身が作成した非公式な通知であった。これらの初期のライセンスは、「寛容な」タイプのものであった。

1980年代半ば、GNUプロジェクトは、そのソフトウェアパッケージごとにコピーレフトのフリーソフトウェアライセンスを作成しました。初期のライセンス（「GNU Emacsコピー許可通知」）は1985年にGNU Emacsに使用され、^{[ 6 ]} 1985年後半に「GNU Emacs一般公開ライセンス」に改訂され、1987年3月と1988年2月に明確化されました。^{[ 7 ] [ 8 ] [ 9 ]} 同様に、同様のGCC一般公開ライセンスは、1987年に最初に公開されたGNUコンパイラコレクションに適用されました。 ^{[ 10 ] [ 11 ]}オリジナルのBSDライセンスも、1988年に遡る最初のフリーソフトウェアライセンスの1つです。1989年には、 GNU一般公開ライセンス（GPL）のバージョン 1が公開されました。 1991年にリリースされたGPLのバージョン2は、最も広く使用されているフリーソフトウェアライセンスとなった。^{[ 12 ] [ 13 ] [ 14 ]} 

1990年代半ばから2000年代半ばにかけて、オープンソース運動は、フリーソフトウェアの理念を一般社会や企業の認識の中で推進し、焦点を絞った。^{[ 15 ]}ドットコムバブルの時代に、Netscape Communicationsが1998年にウェブブラウザをFOSSライセンスでリリースしたこと^{[ 16 ] [ 17 ]}は、他の多くの企業がFOSSエコシステムに適応するきっかけとなった。^{[ 18 ]}この流れの中で、企業や新しいプロジェクト（Mozilla、Apache Foundation、Sunなど、このリストも参照）は独自のFOSSライセンスを作成したり、既存のライセンスを適応させたりした。このライセンスの増殖は、ライセンスの互換性に関する考慮事項の複雑さが増したため、後にフリーおよびオープンソースのエコシステムにとって問題であると認識された。 ^{[ 19 ]}新しいライセンスの作成は後に減速したが、ライセンスの増殖とその影響は、フリーおよびオープンソースのエコシステムにとって継続的な深刻な課題であると考えられている。

フリーソフトウェアライセンスのうち、GNU GPL バージョン 2 は、2004 年にドイツで、その後米国で初めて法廷で検証されました。ドイツの訴訟では、裁判官は GPL の条項の有効性について明示的に議論しませんでしたが、GPL を遵守しなければならないことを認めました。「当事者間で GPL に合意していなければ、被告は、ソフトウェア 'netfilter/iptables' を複製、配布、公開するために必要な権利を欠くことになる。」被告は GPL を遵守しなかったため、ソフトウェアの使用を中止しなければなりませんでした。^{[ 20 ]}米国の訴訟 ( MySQL vs Progress) は判決が出る前に和解しましたが、最初の審理で、サリス判事は GPL が執行できない「理由はない」と述べました。^{[ 21 ]}

2004 年頃、弁護士のローレンス・ローゼンはエッセイ「なぜパブリック ドメインはライセンスではないのか」の中で、ソフトウェアは真にパブリック ドメインに放棄することはできず、非常に寛容な FOSS ライセンスとして解釈することはできないと主張した^{[ 22 ]} 。この立場は、ダニエル・J・バーンスタインらから反対を受けた^{[ 23 ]}。2012年、ローゼンはCC0をオープンソース ライセンスとして受け入れ、第 9 巡回区控訴裁判所の判決を根拠に著作権を放棄できることを認めた^{[ 24 ]}。

2007年、長年の草案議論を経て、GPLv2のメジャーアップデートとしてGPLv3がリリースされました。このリリースは、ライセンスの範囲が大幅に拡大されたためGPLv2と互換性がなくなり、物議を醸しました^{[ 25 ] [ 26 ]} 。いくつかの主要なFOSSプロジェクト（Linuxカーネル[ ^{27 ] [ 28 ] 、} MySQL ^{[ 29 ]} 、BusyBox [ ^{30 ] [ 31 ]}、Blender ^{[ 32 ]} 、 VLCメディアプレーヤー^{[ 33 ] ）は、} GPLv3の採用を見送りました。一方、GPLv3のリリースから2年後の2009年、GoogleのオープンソースプログラムオフィスマネージャーであるChris DiBonaは、 Google Codeでホストされているプロジェクトを含め、GPLv2からGPLv3に移行したライセンスソフトウェアのオープンソースプロジェクトの数は50%であると報告しました^{[ 34 ]}。

2011年、GPLv3のリリースから4年後、Black Duck Softwareのデータによると、オープンソースのライセンスプロジェクト全体の6.5%がGPLv3であり、42.5%が依然としてGPLv2であった。^{[ 28 ] [ 35 ]} 2011年に続いて、451 GroupのアナリストであるMatthew Aslettは、Black Duck Softwareの統計に基づいて、コピーレフトライセンスは衰退し、寛容なライセンスが増加したとブログ記事で主張した。^{[ 36 ] [ 37 ]}

^{2015年、Black Duck Software [ 38 ]}とGitHubの統計^{[ 39 ]}によると、寛容なMITライセンスが最も人気のあるフリーソフトウェアライセンスとしてGPLv2を2位に押し下げ、寛容なApacheライセンスが3位に続いた。2016年6月、 Fedoraプロジェクトのパッケージの分析により、最も使用されているライセンスはGPL、MIT、BSD、LGPLであることが明らかになった。^{[ 40 ]}

オープンソース・イニシアティブ（OSI）は、承認されたオープンソース・ライセンスのリストを定義・維持しています。OSIは、広く使用されているすべてのフリーソフトウェア・ライセンスに関してFSFと合意していますが、FSFのリストとは異なり、フリーソフトウェア定義ではなくオープンソース定義に基づいて承認を行っています。OSIは、フリーソフトウェア・パーミッシブ・ライセンス・グループをフリーソフトウェア・ライセンスのリファレンス実装とみなしています。そのため、ライセンス承認の要件が異なります。

フリーソフトウェア定義を維持しているフリーソフトウェア財団は、フリーソフトウェアライセンスの網羅的ではないリストを維持している。^{[ 41 ]}

フリーソフトウェア財団（FSF）は、ほとんどの場合、寛容なフリーソフトウェアライセンスよりも、コピーレフト（継承）フリーソフトウェアライセンスを推奨しています。FSFのリストでは、FSFのコピーレフトGNU一般公衆利用許諾契約書（GPL）と互換性のあるフリーソフトウェアライセンスと互換性のないライセンスを区別しています。

1980年代半ばにリチャード・ストールマンによって書かれたフリーソフトウェアの共有ライセンスは、 「コピーレフト」と呼ばれる概念の先駆けとなりました。その後に続くコピーレフトの条項では、フリーソフトウェアの改変版を配布する場合、元のソフトウェアと同じ条件で配布しなければならないと規定されました。そのため、これらは「共有と共有」または「等価交換」と呼ばれています。これにより、新しいソフトウェアもオープンソースとなります。コピーレフトは、ソフトウェアの後の世代がコードを自由に改変できることを保証するため、これは「フリーソフトウェア」と言えます。コピーレフト以外のライセンスでは、ソフトウェアの後の世代がフリーであり続けることは保証されません。

製品にGPLコードを使用する開発者は、オブジェクトコードを共有または販売する際に、ソースコードを誰でも利用できるようにする必要があります。この場合、ソースコードには開発者が行った変更もすべて含まれていなければなりません。GPLコードを使用しても共有または販売しない場合は、コードを公開する必要はなく、変更内容は非公開のままにすることができます。これにより、開発者や組織は、コードやプロジェクトを販売したり共有したりしない場合など、個人的な目的でGPLコードを使用および変更する際に、変更内容を一般に公開する必要がなくなります。

GPLの支持者は、派生作品がGPLの適用下に置かれることを義務付けることで、フリーソフトウェアの成長を促進し、すべてのユーザーによる平等な参加を要求していると主張している。GPLの反対者は^{[ 42 ]}、「いかなるライセンスも将来のソフトウェアの可用性を保証することはできない」とし、GPLの欠点は利点を上回ると主張している^{[ 43 ]}。また、配布を制限するとライセンスの自由度が低下すると主張する者もいる。一方、支持者は、配布中に自由度を維持しないことが自由度の低下につながると主張するだろう。例えば、非コピーレフトライセンスでは、著作者は自分の作品が公に公開された場合に、その改変版を見る自由を与えられていないが、コピーレフトライセンスではその自由が与えられている。

1990年代には、フリーソフトウェアのライセンスに、以前は存在しなかったソフトウェア特許訴訟から保護するために、特許報復などの条項が含まれるようになりました。この新たな脅威は、 2006年にGNU GPLのバージョン3が作成された理由の1つです。 ^{[ 44 ]}近年、TiVoデバイスが例であるハードウェア制限を使用して、ユーザーがそのハードウェア上でソフトウェアの変更バージョンを実行できないようにするプロセスを指す「ティボ化」という用語が作られました。FSFはこれを、フリーソフトウェアを実質的に非フリーにする方法と見ており、GPLv3でこれを禁止することを選択した理由です。^{[ 45 ]} 1990年代後半以降に新たに作成されたフリーソフトウェアのライセンスのほとんどには、何らかの形の特許報復条項が含まれています。これらの措置は、特定の状況下で、ライセンスされたソフトウェアに関連する特許を行使しようとした場合、ライセンスに基づく権利（再配布など）が終了する可能性があることを規定しています。例えば、Appleのパブリックソースライセンスでは、ユーザーが特許訴訟を理由にAppleに対して訴訟を起こした場合、ユーザーの権利を終了させることができます。特許報復は、ソフトウェア特許の乱用と濫用への対応として出現しました。 

ほとんどのフリーソフトウェアライセンスでは、改変されたソフトウェアが改変されていないと主張することを禁じています。また、一部のライセンスでは、著作権者のクレジット表示も義務付けています。例えば、 GNU GPLバージョン2では、保証情報やライセンス情報を表示する対話型プログラムについて、配布を目的とした改変版からこれらの通知を削除してはならないと規定しています。

矛盾する要件を含むソフトウェア パッケージのライセンスでは、そのようなパッケージのソース コードを組み合わせて新しいソフトウェア パッケージを作成することは不可能です。^{[ 47 ]}コピーレフト ライセンスと他のライセンス間のライセンス互換性は、多くの場合、一方向の互換性のみです。^{[ 48 ]}この「一方向の互換性」という特性は、たとえば、この特性を持たないより寛容なApache ライセンスを提供するApache Foundationによって批判されています。 ^{[ 49 ]} FOSS の寛容なライセンスなどの非コピーレフト ライセンスは、ライセンス間の相互作用が単純で、通常はライセンス互換性が優れています。^{[ 50 ] [ 51 ]}たとえば、あるライセンスが「変更されたバージョンは、広告資料で開発者に言及しなければならない」と規定し、別のライセンスが「変更されたバージョンには追加の帰属要件を含めてはならない」と規定している場合、あるライセンスを使用するソフトウェア パッケージと別のライセンスを使用するソフトウェア パッケージを組み合わせた場合、これらの矛盾する要件を同時に満たすことができないため、組み合わせを配布することは不可能です。したがって、これら 2 つのパッケージはライセンス互換性がありません。コピーレフトソフトウェアライセンスに関しては、他のコピーレフトライセンスと本質的に互換性があるわけではなく、GPLv2 自体も GPLv3 と互換性がない。^{[ 26 ] [ 52 ]}

ソフトウェアの使用制限（「使用制限」）は、FSF、OSI、Debian、またはBSDベースのディストリビューションによれば、一般的に受け入れられません。例としては、ソフトウェアを非私的アプリケーション、軍事目的、比較またはベンチマーク、善用、倫理的に疑わしい手段^{[ 53 ] 、または商業組織[ 54 ]}で使用することを禁止することなどが挙げられます。 核戦争に関するものなど、ユーザーの自由に対するいくつかの制限は、ほとんどのフリーソフトウェア開発者の間で道徳的な支持を得ているようですが^{[ 55 ]} 、そのようなアジェンダはソフトウェアライセンスを通じて提供されるべきではないと一般的に考えられています。その理由には、結果として生じる法的不確実性や、曖昧で広範かつ/または主観的な基準の執行可能性の問題などの実際的な側面、またはツールメーカーは一般的に他人のツールの使用に対して責任を負わないことなどがあります。それにもかかわらず、 SQLiteなどの一部のプロジェクトは、法的拘束力のないユーザーへの要請を含んでいます。^{[ 56 ]}ライセンスを通じてユーザーの行動を規制しようとする開発者による度重なる試み^{[ 57 ] [ 58 ] [ 59 ]}で、より広範な議論を巻き起こしたものとしては、2012 年にDebianディストリビューションのリリース プロセスに影響を与え^{[ 60 ]}、JSMin-PHP プロジェクトがGoogle Codeから追放されたこと^{[ 61 ]}、2005 年に分散コンピューティング ソフトウェアGPUの GPL にアシモフのロボット工学の第一法則に基づく平和主義的な条件が追加されたこと^{[ 62 ] 、大手クラウド プロバイダーによる使用を排除しようとするいくつかのソフトウェア プロジェクト[ 63 ] [ 64 ]}などがある。

BSDベースのオペレーティングシステムの多くのユーザーと開発者は、ライセンスに関して異なる立場をとっています。主な違いは、コピーレフトライセンス、特にGNU一般公衆ライセンス（GPL）が望ましくないほど複雑で制限的であるという考え方です。^{[ 65 ]} GPLは派生作品もGPLに従ってリリースすることを要求しますが、BSDライセンスはそうではありません。基本的に、BSDライセンスの唯一の要件は元の著者を認めることであり、ソースコードの使用方法に制限はありません。

その結果、BSD コードは、作者のみを認める独自のソフトウェアで使用できます。たとえば、Microsoft Windows NT 3.1とmacOS には、BSD ライセンスのソフトウェアから派生した独自のIP スタックがあります。 ^{[ 66 ]}極端な場合、BSD またはその他の寛容なライセンスによるサブライセンスまたは再ライセンスの可能性により、オープンソース エコシステムでのさらなる使用が妨げられる可能性があります。たとえば、MathWorksの FileExchange リポジトリは、ユーザー貢献に対して BSD ライセンスを提供していますが、追加の使用条件により、独自のMATLABソフトウェア以外での使用、たとえば FOSS のGNU Octaveソフトウェアでの使用を禁止しています。^{[ 67 ] [ 68 ] [ 69 ]}

BSD ライセンスの支持者は、帰属表示が保持されている限り、ソースコードで何でもする権利を付与するため、GPL よりも自由であると主張している。このアプローチにより、BSD コードは広く使用されているプロプライエタリ ソフトウェアで使用されるようになった。GPL の支持者は、コードがプロプライエタリになると、ユーザーはフリー ソフトウェアを定義する自由を否定されると指摘している。^{[ 70 ]} その結果、彼らは BSD ライセンスは GPL よりも自由度が低いと考えており、自由とは制限がない以上のものだと考えている。BSD ライセンスは開発者が変更をコミュニティに再貢献する権利を制限しているため、BSD ライセンスも GPL も「制限がない」という意味では「自由」ではない。

Debianプロジェクトは、Debianフリーソフトウェアガイドライン（DFSG）に定められた基準を採用しています。Debianとフリーソフトウェア財団（FSF）の間で意見の相違が顕著なのは、Artistic LicenseとGNU Free Documentation License（GFDL）に関する点のみです。DebianはオリジナルのArtistic Licenseをフリーソフトウェアライセンスとして認めていますが、FSFはこれに同意していません。しかし、Artistic LicenseはGNU General Public Licenseと併用されるデュアルライセンス構成でほぼ常に使用されているため、この相違による影響はほとんどありません。

フリーソフトウェアの大部分は、異論のないフリーソフトウェアライセンスを使用していますが、他の特定のライセンスがその定義に該当するかどうかについては、多くの議論がなされてきました。

議論を巻き起こしたライセンスの例としては、Open Source Initiative には受け入れられたものの、Free Software Foundation や Debian には受け入れられなかったApple Public Source Licenseの 1.x シリーズや、Open Source Initiative と Free Software Foundation には受け入れられたものの、 Debianには受け入れられなかった RealNetworks Public Source License などがある。

また、FSF はGNU フリー文書ライセンスを推奨しましたが、これは GPL と互換性がなく、^2006年頃にDebianプロジェクトによって「非フリー」とみなされました。^{[ 73 ] Nathanael} Nerode、^{[ 74 ]} Bruce Perens。^{[ 75 ]} FSF は、文書はソフトウェアとは質的に異なり、異なる要件に従う必要があると主張しています。Debian は後の決議で、議論の的となっている「不変セクション」を削除すれば GNU FDL は Debian フリーソフトウェアガイドラインに準拠すると認めました^が、「まだ^問題がないわけではない」と考えています。^{[ 76 ]}それにもかかわらず、ほとんどの GNU 文書には「不変セクション」が含まれています。同様に、フリーソフトウェアのマニュアル作成に専念する組織であるFLOSS Manuals Foundationは、2007年に、GFDLとGPLの非互換性、GFDLの実装の難しさ、そしてGFDLが特にデジタルドキュメントにおいて「容易な複製と変更を許可しない」という事実を理由に、テキストにGFDLではなくGPLを採用することを決定した。^{[ 77 ]}

SLUCは、軍事利用を除くあらゆる利用を許可するソフトウェアライセンスで、2006年12月にスペインで公開されました。ライセンスの作成者はフリーソフトウェアであると主張していますが、フリーソフトウェア財団は、GPLのいわゆる「ゼロ自由」、つまりソフトウェアをあらゆる目的に使用できる自由を侵害しているため、フリーではないと述べています。^{[ 78 ]}