Loading article…
オープンソース ライセンスは、コンテンツの使用、変更、共有を許可するソフトウェア ライセンスです。これらは、フリーおよびオープンソース ソフトウェア(FOSS) の開発を促進します。知的財産(IP) 法は、創作物の変更と共有を制限します。フリーおよびオープンソース ライセンスは、これらの既存の法的構造を逆の目的で使用します。つまり、受領者にソフトウェアを使用する権利、ソース コードを検査する権利、ソース コードを変更する権利、変更内容を配布する権利を付与します。これらの基準は、オープンソースの定義に概説されています。
1980 年以降、米国はソフトウェアを著作権法の対象となる著作物として扱うようになりました。リチャード・ストールマンは、プロプライエタリソフトウェアの台頭に応えてフリーソフトウェア運動を創設しました。「オープンソース」という用語は、フリーソフトウェア開発者のブルース・ペレンズとエリック・S・レイモンドによって創設されたオープンソース・イニシアティブ(OSI) によって使用されました。「オープンソース」は、ソフトウェアの自由ではなく、オープン開発モデルの長所を強調しています。用語の背後にある目的は異なりますが、オープンソースライセンスとフリーソフトウェアライセンスは同じタイプのライセンスを表します。[1]
オープンソース ライセンスには、主にパーミッシブとコピーレフトの 2 つのカテゴリがあります。どちらもソフトウェアの変更と配布を許可します。通常、帰属表示と免責事項が必要です。パーミッシブ ライセンスは学術界から生まれたものです。コピーレフト ライセンスはフリー ソフトウェア運動から生まれました。コピーレフト ライセンスでは、派生作品はソース コードとともに同様のライセンスの下で配布する必要があります。2000 年代半ば以降、複数の国の裁判所が両方のタイプのライセンスの条件を支持しています。ソフトウェア開発者は、著作権侵害および契約違反として訴訟を起こしています。
背景
知的財産（IP）は、創造的な成果物を私有財産に匹敵する財産として扱う法的カテゴリーです。[2]法制度は、IPの所有者にさまざまな方法でアクセスを制限する権利を与えています。[3]所有者は、その財産を売却、リース、贈与、またはライセンス供与することができます。[4]複数の種類のIP法が、商標、特許、著作権を含むソフトウェアをカバーしています。[4]
米国を含むほとんどの国では、ベルヌ条約に沿って著作権法が制定されています。[5]これらの法律では、作品がどのような形式であれ、発表されるたびに著作権が割り当てられます。[6]米国の著作権法では、最初の発表がオリジナル作品とみなされます。[7]作成者またはその雇用主がこのオリジナル作品の著作権を保有し、したがって、複製、修正版の発表、複製の配布、公の場での演奏、または公の場での展示の排他的権利を有します。オリジナル作品の修正版は派生作品です。[8]作成者が既存の作品を修正した場合、その修正に対する著作権は作成者に帰属します。[9]オリジナル作品がパブリックドメインでない限り、派生作品はすべての著作権者の許可を得た場合にのみ配布できます。[10]
1980年、米国政府は法律を改正し、ソフトウェアを文学作品として扱うようにした。この時点以降にリリースされたソフトウェアは、知的財産法によって制限された。[11]当時、アメリカの活動家でプログラマーのリチャード・ストールマンは、MITコンピュータサイエンスおよび人工知能研究所で大学院生として働いていた。ストールマンは、ソフトウェア開発者の断片化を目の当たりにした。彼は、プロプライエタリソフトウェアの普及と開発の閉鎖モデルを非難した。これらの傾向に対抗するために、ストールマンはフリーソフトウェア運動を設立した。[12] 1980年代を通じて、彼はフリーオペレーティングシステムを作成するためのGNUプロジェクトを開始し、自由に関するエッセイを書き、フリーソフトウェア財団（FSF）を設立し、いくつかのフリーソフトウェアライセンスを作成した。[13] FSFは、制限という本来の目的とは反対の目的で既存の知的財産法を利用した。制限を課す代わりに、フリーソフトウェアは受信者に明示的に自由を提供した。[14]
90 年代には、フリーソフトウェアの代替ラベルとして「オープンソース」という言葉が造られ、どのライセンスがフリーおよびオープンソースソフトウェアをカバーするかを決定するための特定の基準が策定されました。[15] [16]フリーソフトウェアコミュニティの 2 人のアクティブメンバー、ブルース・ペレンズとエリック・S・レイモンドがオープンソースイニシアティブ(OSI)を設立しました。 [17] Debianでは、ペレンズがDebian フリーソフトウェアガイドライン(DFSG) を提案しました。[18] DFSG は、Debian がリポジトリでホストする FOSS に対して、より具体的で客観的な標準を提供するために起草されました。[19] OSI は DSFG を採用し、それをオープンソース定義の基礎として使用しました。[20]フリーソフトウェア財団は、フリーソフトウェア定義というライバルの基準セットを維持しています。[21]歴史的に、これら 3 つの組織とその基準セットは、ライセンスがフリーおよびオープンソースソフトウェアをカバーするかどうかを決定する際の著名な権威でした。[22]個々のライセンス間には大きな多様性がありますが、ライバルの定義間にはほとんど違いがありません。[16] 3つの定義はいずれも、対象となるソフトウェアを受け取った人が対象となる作品を使用、変更、再配布できることを要求しています。[23]
エリック・S・レイモンドは、「フリーソフトウェア」よりも「オープンソース」という用語の支持者だった。彼は、オープンソースの方が企業にとって魅力的であり、FOSS開発の具体的な利点をより反映していると考えた。レイモンドの目標の1つは、既存のハッカーコミュニティを拡大して、大規模な商業開発者を含めることだった。[24]レイモンドは『伽藍とバザール』で、オープンソース開発を野外の公共市場であるバザールに例えた。 [25]彼は、倫理は別として、オープンモデルはプロプライエタリソフトウェアでは再現できない利点を提供すると主張した。[26] [27]レイモンドは、フィードバック、テスト、バグレポートに重点を置いていた。[28]彼は、秘密主義の労働者の小さなグループがこの作業を実行するプロプライエタリモデルと、テスターのプールに潜在的に全世界が含まれるLinuxの開発を対比した。[29]彼はこの強みを「十分な数の目があれば、すべてのバグは浅い」と要約した。[30] OSIは、サン・マイクロシステムズ、IBM、ネットスケープ、モジラ、Apache、アップル社、マイクロソフト、ノキアなどの企業開発者にオープンソース開発をもたらすことに成功した。これらの企業は既存のライセンスの下でコードをリリースし、OSIの承認を得るために独自のライセンスを起草した。[31] [32]
種類
オープンソースライセンスは、コピーレフトとパーミッシブに分類されます。[33]コピーレフトライセンスでは、派生作品に同様のライセンスのソースコードを含める必要があります。パーミッシブライセンスではその必要はありません。そのため、コードはプロプライエタリソフトウェア内で使用できます。コピーレフトは、派生作品を広く定義するか狭く定義するかによって、さらに強いコピーレフトと弱いコピーレフトに分けられます。[34] [35]
ライセンスは著作権法に焦点を当てていますが、コードは他の形式の知的財産によっても保護されています。[36] 1990 年代後半以降に作成された主要なオープンソース ライセンスには、特許の付与が含まれています。これらのオープンソースの特許付与は、開発者が保有する特許を対象としています。 [37] ソフトウェア特許はアイデアを対象としており、特定の実装ではなく、クレームのあらゆる実装を対象としています。特許クレームは、そのアイデアに基づいた製品の製造、使用、販売、輸入を他者が行うことを排除する権利を保有者に与えます。特許は作成権ではなく排除権を付与するため、アイデアの特許を取得していても、その発明が別の特許取得済みのアイデアに依存している場合は、それを合法的に実装できない可能性があります。したがって、オープンソースの特許付与では、対象となる特許からの許可しか提供できません。コードに組み込まれた概念を第三者が特許取得していないことを保証することはできません。[36]古い許容ライセンスでは、特許について直接議論されておらず、対象となる素材の使用または販売のオファーにおいて暗黙の特許付与のみを提供しています。[38]新しいコピーレフトライセンスと2004年のApacheライセンスは、明示的な特許付与と特許訴訟からの限定的な保護を提供しています。[39]これらの特許報復条項は、対象となるソフトウェアに関して特許訴訟を起こした当事者への付与を打ち切ることで開発者を保護します。[39]
商標は、フリーソフトウェアやオープンソースソフトウェアで共有されない唯一の知的財産です。FOSS 上の商標は、他の商標と同じように機能します。[40]商標とは、製品の明確な出所を識別するデザインです。製品を区別するため、同じデザインを異なる分野で使用しても、類似の出所を混同するリスクはありません。 [41]商標の管理を放棄すると、その商標は失われます。したがって、オープンソースライセンスでは商標の使用を自由に提供していません。[42]
商標による制限は著作権と重複し、自由に利用できる素材に影響を及ぼす可能性がある。[43]米国最高裁判所は、商標法を使ってパブリックドメインのコンテンツを制限しようとすることを「ミュータント著作権」と表現した。[44] Dastar Corp. v. Twentieth Century Fox Film Corp.の訴訟で、裁判所は「商標法の誤用や過度な拡大に対して警告」したが、ミュータント著作権については明確な判断を下さなかった。[45] [46]商標の重複により、オープンソースやフリーコンテンツのプロジェクトは、外部の当事者が派生作品に商標を申請した場合、「敵対的買収」の危険にさらされる可能性がある。[47]注目すべきことに、Andrey Duskin は、共同執筆プロジェクトであるSCP Foundationで、SCP ストーリーに基づく派生作品を作成する際に商標を申請した。 [48]
寛容な
許容ライセンスはアカデミックライセンスとも呼ばれ、[49]受信者がソースコードを提供する義務なしにソフトウェアを使用、変更、配布することを許可します。機関はこれらのライセンスを作成し、その作品を一般に配布しました。[49]許容ライセンスは通常短く、多くの場合1ページ未満のテキストです。条件はほとんど課されません。ほとんどのライセンスには保証の放棄と著者のクレジット義務が含まれています。特許、商標、その他の知的財産に関する明示的な規定を含むライセンスもいくつかあります。[50]
カリフォルニア大学バークレー校は、 Berkeley Software Distribution (BSD) オペレーティングシステムの配布を開始した際に、最初のオープンソースライセンスを作成しました。BSDライセンスとその後の派生版では、対象となるソフトウェアの改変と配布が許可されています。BSDライセンスは、学術的な思想の自由という概念をコンピューティングに持ち込みました。初期の学術ソフトウェアの作者は、暗黙の約束に基づいてコードを共有していました。バークレーは、再配布の条件または条項とともに、責任と保証の明確な免責事項を明記して、これらの概念を明示しました。元のライセンスには 4 つの条項がありましたが、その後のバージョンでは制限がさらに削減されました。その結果、対象となるソフトウェアが 2 条項バージョンを使用するか 3 条項バージョンを使用するかを指定するのが一般的です。[51] [52]
マサチューセッツ工科大学（MIT）は、 BSDのオリジナルをベースに学術ライセンスを作成しました。MITライセンスは、条件をより明示的にすることで明確化しました。[53]たとえば、MITライセンスはサブライセンスの権利について説明しています。[ 54]オープンソース開発の強みの1つは、開発者が互いの派生作品を基にしてプロジェクトを集合作品に組み合わせることができる継続的なプロセスです。対象となるコードを明示的にサブライセンス可能にすることで、著作権の連鎖を追跡する際に法的利点が得られます。[53] BSDとMITは、あらゆるプロジェクトに適応できるテンプレートライセンスです。これらは、多くのFOSSプロジェクトで広く採用され、使用されています。[51]
Apacheライセンスはより包括的かつ明示的です。Apache Software Foundation がApache HTTP Server用に作成しました。2004 年に公開されたバージョン 2 は、単純なライセンスよりも法的に有利で、同様の付与を提供しています。[55] BSD ライセンスと MIT ライセンスは暗黙の特許付与を提供していますが、[56] Apache ライセンスには貢献者からの明示的な付与を伴う特許に関するセクションが含まれています。[57]さらに、これは特許報復条項を備えた数少ない許容ライセンスの 1 つです。[58]特許報復条項、または特許停止条項は、ライセンシーが対象コードに対して特許侵害訴訟を起こした場合に発効します。その場合、特許付与は取り消されます。これらの条項は特許トロールから保護します。[59]
コピーレフト
%22_sticker,_from_an_envelope_mailed_from_Don_Hopkins_to_Richard_Stallman_in_1984..jpg/500px-%22Copyleft_(L)%22_sticker,_from_an_envelope_mailed_from_Don_Hopkins_to_Richard_Stallman_in_1984..jpg)
コピーレフトライセンスでは、ソースコードをソフトウェアと一緒に配布し、同様のライセンスの下でソースコードを利用できるようにする必要があります。[34] [60]許容ライセンスと同様に、ほとんどのコピーレフトライセンスでは帰属表示が必要です。[61] GPLを含むほとんどのライセンスでは、暗黙の保証を放棄しています。[62]
コピーレフトは、通常の目的とは逆に、知的財産法の制限を利用して、コードをオープンのままにすることを義務付けています。[63]この用語とそれに関連するスローガン「すべての権利は逆転します」は、以前はプリンキピア・ディスコルディアとTiny BASICで冗談めかして使用されていました。現代の使用法は、リチャード・ストールマンがフリーオペレーティングシステムを作成しようとした努力に始まります。1984年、プログラマーのドン・ホプキンスは「コピーレフトⓁ」ステッカーを貼ったマニュアルをストールマンに郵送しました。GNUオペレーティングシステムに取り組んでいたストールマンは、この用語を採用しました。[64]コピーレフトライセンスの初期バージョンは、1985年のGNU Emacsのリリースで使用されました。[14] [65]この用語は、FSFの後の相互ライセンス、特にGNU一般公衆利用許諾書（GPL）に関連付けられました。[66]
従来のプロプライエタリソフトウェアライセンスは利益の増加を目的として書かれていますが、ストールマンは利用可能なフリーソフトウェアを増やすためにGPLを書きました。彼の相互ライセンスは、人々が同じ自由を提供するライセンスの下で派生作品をリリースすることを条件に、作品を使用、変更、配布する権利を提供します。コピーレフトベースで構築されたソフトウェアにはソースコードが付属している必要があり、ソースコードは同じまたは同様のライセンスの下で利用可能でなければなりません。これにより、コードを消費するだけのプロプライエタリソフトウェアから保護されます。[67] [68]リチャード・ストールマンは、「コピーレフトの中心的な考え方は、著作権法を使用することですが、それを通常の目的とは逆に反転させることです。つまり、ソフトウェアを民営化する手段ではなく、[著作権] がソフトウェアをフリーに保つ手段になります」と述べています。 [69] フリーソフトウェアライセンスはオープンソースソフトウェアライセンスでもあります。[70]フリーソフトウェアとオープンソースソフトウェアという別々の用語は、法的な違いではなく、異なる価値観を反映しています。[71]どちらの運動もその正式な定義も、対象となる作品はソースコード付きで公開され、改変や再配布が許可されていることを要求している。[16] FSFとOSIのどちらか一方だけがライセンスを受け入れるという例外的なケースも時々あるが、 GPLを含め、一般的なフリーソフトウェアライセンスはオープンソースである。[72]
.jpg/500px-Mitchell_Baker_(2).jpg)
コピーレフトライセンスの実際的な利点は、商業開発者を引き付けてきました。企業は、GPLよりも狭い範囲の相互ライセンスを使用したり作成したりしてきました。[74]たとえば、Netscapeは、Mozillaプロジェクトの許容ライセンスを拒否した後、独自のコピーレフト条件を起草しました。[75] GPLは、このタイプのライセンスで最も人気のあるままですが、他の重要な例もあります。FSFは、ライブラリ用のLesser General Public License （LGPL）を作成しました。Mozillaは、 Firefoxを含むリリースにMozilla Public License （MPL）を使用しています。IBMはCommon Public License （CPL）を起草し、後にEclipse Public License（EPL）を採用しました。GPLと他の相互ライセンスの違いは、相互条項の対象となる派生作品をどのように定義するかです。GPL、およびそれに基づくAffero License（AGPL）は、影響を受ける作品を記述するために広い範囲を使用しています。AGPLは、GPLの相互義務をネットワーク経由で利用できるソフトウェアにまで拡張しています。[74] [32]これらは、企業がよく使用する弱いコピーレフトライセンスとは対照的に、強いコピーレフトと呼ばれています。弱いコピーレフトは、派生作品のより狭く明確な定義を使用します。 [76] [35] MPLはファイルベースの定義を使用し、CPLとEPLはモジュールベースの定義を使用し、FSF独自のLGPLはソフトウェアライブラリを参照します。[77]
互換性
ライセンスの互換性は、異なるライセンスのコードを一緒に配布する方法を決定します。オープンソースライセンスの目標は、作品を自由に利用できるようにすることですが、異なる要件を課す複数の用語を扱う場合、これは複雑になります。 [78]あまり使用されていないライセンスが多くあり、一部のプロジェクトでは独自の契約書を作成しています。その結果、他の法的側面よりも混乱が生じます。アプリケーションのコレクションをリリースする場合、各ライセンスを個別に検討できます。ただし、ソフトウェアを組み合わせる場合、別のプロジェクトのコードは、プロジェクトが互換性のある利用規約を使用している場合にのみライセンスできます。[79]
コードベースを組み合わせる場合、元のライセンスを個別のコンポーネント用に維持し、互換性のあるライセンスの下でより大きな作品をリリースすることができます。[80]この互換性は多くの場合、一方通行です。パブリックドメインのコンテンツは著作権の主張がないためどこでも使用できますが、ほぼすべての条件の下で取得されたコードをパブリックドメインに持ち込むことはできません。許容ライセンスはコピーレフトの作品内で使用できますが、コピーレフトの素材を許容ライセンスの下でリリースすることはできません。一部の弱いコピーレフトライセンスはGPLの下で使用でき、GPL互換であると言われています。GPLソフトウェアはGPLまたはAGPLの下でのみ使用できます。[78]許容ライセンスはプロジェクトの個別の部分をカバーできるため、互換性が広くあります。GPLやApacheライセンスを含む複数のライセンスが互換性を強化するために改訂されています。[81]
翻訳の問題、ライセンス条件の曖昧さ、一部のライセンスと特定の法域の法律との非互換性により、ライセンスの互換性の問題が複雑化しています。 [82]オープンソースモジュールのダウンロードは簡単ですが、ライセンス条件の遵守はより困難になる可能性があります。[83]ソフトウェアの依存関係が多いため、複雑なプロジェクトに取り組んでいるエンジニアは、オープンソースコンポーネントのライセンス条件に準拠するためにライセンス管理ソフトウェアに頼ることがよくあります。[84]多くのオープンソースソフトウェアファイルではライセンスが明確に示されていないため、準拠が難しくなります。[83]
執行
フリーソフトウェアおよびオープンソースソフトウェアのライセンスは、2000年代半ば以降、民事裁判所で有効に執行されてきました。 [86]初期の2つの訴訟、米国のJacobsen v. KatzerとドイツのWelte v. Sitecomでは、被告はオープンソースライセンスが無効であると主張しました。[87] [88] SitecomとKatzerはそれぞれ、ライセンスは執行不可能であると主張しました。米国とドイツの裁判所は両方ともこれらの主張を却下しました。彼らは、ライセンスが執行不可能であれば、被告がソフトウェアを合法的に配布することはできなかったと判決を下しました。[86] [85]
裁判所は、ソフトウェアを配布することはライセンスの条件に同意したことを示すと判断しています。[89]物理的なソフトウェアリリースでは、シュリンクラップに通知を記載することで消費者の同意を得ることができます。オンライン配布では、ユーザーがクリックして同意する必要があるデジタル版であるクリックラップを使用できます。 [90]オープンソースソフトウェアには、追加の承諾メカニズムがあります。著作権者の許可なしに再配布することは法律で禁止されています。[91]そのため、裁判所は再配布をライセンス条件の承諾とみなします。これには、コピーレフトライセンスの帰属条項またはソースコード条項が含まれます。[92] [93]
開発者は通常、訴訟を起こさずにコンプライアンスを達成します。コミュニティの反発の可能性などの社会的圧力で十分な場合が多いです。[94] 差し止め命令書は、特にドイツでは、企業をコンプライアンスに戻すための一般的な方法です。[95]ドイツの法制度では、標準的なプロセスが開発されています。FOSS開発者は、企業に差し止め命令書を提出します。これらの手紙には、違反からコンプライアンスに戻す方法が概説されています。ドイツの裁判官は、応答しない企業に対して、裁判所の命令による差し止め命令を発行できます。これらの最初のステップが失敗した場合は、民事訴訟が進行します。ドイツの手続き法は明確で、原告に有利です。[96]
異なる裁判所がライセンスの特定の側面をどのように扱うかについては不確実性が残っている。[97]ソフトウェア全般については、何が特許可能で何が著作権で保護できるかについて議論がある。アプリケーションプログラミングインターフェース（API）に関して、欧州司法裁判所は2012年のSAS Instituteの訴訟で「[コンピュータプログラム]インターフェースの基礎となるアイデアや原則は著作権で保護されない」と指摘した。 [98]同様の2021年の訴訟で、米国最高裁判所はフェアユースの下で変形製品におけるAPIの再現を許可した。[99]
FOSS コミュニティ内で長く議論されているテーマは、オープンソース ライセンスが「ベア ライセンス」なのか、それとも契約なのかということです。[97]ベア ライセンスとは、知的財産法によって制限されている行為が許可される条件のセットです。[86] FSF が提唱するベア ライセンスの解釈では、著作権者は著作権侵害として訴訟を起こします。[86]契約の解釈では、当事者は契約違反として訴訟を起こすことができます。[100]米国とフランスの裁判所は、両方の解釈に基づいて訴訟を起こしました。[101] FSF やSoftware Freedom Conservancyなどの非営利団体は、開発者のプロジェクトの権利を保持してコンプライアンスを強制することを提案しています。[96]
パブリックドメインソフトウェア
著作権が切れると、その作品はパブリックドメインとなり、誰でも自由に利用できるようになります。[103]創作物の中には著作権で保護されず、直接パブリックドメインとなるものもあります。コンピュータの初期の歴史では、これはソフトウェアに当てはまりました。[11]初期のコンピュータソフトウェアは、ハードウェアと一緒に配布されることが多かったです。[104] MITで最初に開発された先駆的なビデオゲーム「Spacewar!」は、 PDP-1コンピュータのマーケティングとテストに使用されました。[105]
弁護士ローレンス・ローゼンによれば、著作権法は、著作者が作品をパブリックドメインに置くことを想定して制定されたものではない。したがって、知的財産法には著作権を放棄する明確な道筋がない。「パブリックドメイン」と呼ばれる非常に寛容なライセンスは、法的には、何かを提供するが条件を課さない一方的な契約として機能する可能性がある。 [106] [107]
クリエイティブ・コモンズCC0のようなパブリックドメイン相当のライセンスは、パブリックドメインへの著作権の放棄と、フォールバックとしての許容ソフトウェアライセンスを提供します。パブリックドメインの放棄を受け入れない法域では、許容ライセンスが有効になります。 [108]パブリックドメインの放棄には、単純な学術ライセンスと同じ制限があります。これにより、外部の当事者が特許法または商標法を介してパブリックドメインの作品を制御しようとする可能性があります。[109]パブリックドメインの放棄は、他の種類のライセンスとは異なる方法で保証を扱います。MIT ライセンスのような非常に許容度の高いライセンスでさえ、保証と責任を放棄します。フリーソフトウェアを使用する人は誰でも、この免責事項を条件として受け入れる必要があります。パブリックドメインのコンテンツは誰でも利用できるため、著作権の放棄では免責事項を課すことはできません。[103]
独自ソフトウェアでの使用
オープンソースライセンスは、他の企業が対象となるソフトウェアを商用化することを可能にします。[110]許容ライセンスの下でリリースされた作品は、プロプライエタリソフトウェアに組み込むことができます。[111]許容ライセンスは、プロプライエタリな条件を含む新しい条件の追加を許可します。[112] [113]プロプライエタリソフトウェアには、Apache、BSD、およびMITライセンスの下でリリースされたオープンソースコードが高度に統合されています。[114] オープンコアは、開発者がソフトウェアのコア部分をオープンソースとしてリリースし、それを含む製品をプロプライエタリソフトウェアとして収益化するビジネスモデルです。[115]強力なコピーレフトGPLは、プロプライエタリソフトウェア内での配布を防ぐために書かれています。[116] [117]弱いコピーレフトライセンスは、特定の状況下で対象となるコードをプロプライエタリソフトウェア内で配布することを許可する可能性のある派生作品に特定の要件を課します。[78]
クラウドコンピューティングは、フリーでオープンソースのソフトウェアに依存しており、ほとんどのライセンスのトリガーとなる配布を回避します。クラウドソフトウェアは、配布されるのではなくホストされます。[118]ベンダーはソフトウェアをオンラインでホストし、エンドユーザーは使用中のコードをダウンロードしたり、アクセスしたり、使用中のコードについて知る必要さえありません。[119]コピーレフトのGNU Affero General Public License (AGPL) は、対象となるコードがホストまたは配布されるとトリガーされます。[120]開発者の中には AGPL を採用している人もいますが、オープンソースライセンスの機能を備えた独自のライセンスに切り替えた人もいます。 [121]たとえば、オープンコア開発者のElastic は、Apache ライセンスから「ソースが利用可能な」Server Side Public Licenseに切り替えました。[122] ソースが利用可能なソフトウェアには、参照としてソースコードが付属しています。[123]
2010年以降、クラウドモデルは注目を集めるようになりました。[118]開発者は、資金やアップストリームのコード提供なしにオープンソースソフトウェアをホスティングして利益を得ているクラウド企業を、ストリップマイニングに例えて批判しています。[124]クラウドコンピューティングのリーダーであるAmazon Web Servicesは、ライセンスに準拠し、顧客の最善の利益のために行動していると述べています。[124] [125]
参照
- ビール用品
- フリーソフトウェアとオープンソースソフトウェアのライセンスの比較
- 無料コンテンツライセンスのリスト
- マルチライセンス
- ソフトウェア構成分析
- フリーおよびオープンソースソフトウェアライセンスのリスト
- コピーレフトソフトウェアライセンスのリスト
- 許可ソフトウェアライセンスのリスト
注記
- ^ バイフィールド 2008.
- ^ ローゼン2005、22ページ。
- ^ ローゼン2005、22-23頁。
- ^ Rosen 2005、15ページより。
- ^ 「ベルヌ条約」。Wex 。コーネル大学ロースクール。2021年11月。
- ^ Fagundes & Perzanowski 2020、p. 529.
- ^ ローゼン2005、17ページ。
- ^ ローゼン2005、27-28頁。
- ^ ローゼン2005、28-29頁。
- ^ ローゼン2005、28ページ。
- ^ オマーン2018年、641-642頁。
- ^ ウィリアムズ 2002、第1章。
- ^ ウィリアムズ 2002、第7章。
- ^ ab Williams 2002、第9章。
- ^ グリーンバウム 2016、§ IA
- ^ abc Maracke 2019、§2.2。
- ^ カーバー2005年、448-450頁。
- ^ ペレンズ1999、¶16。
- ^ グリーンバウム 2016、1302–1303頁。
- ^ グリーンバウム 2016、1304–1305頁。
- ^ グリーンバウム 2016、1305頁。
- ^ フォンタナ 2010、2ページ。
- ^ コールマン 2004、「政治的不可知論」。
- ^ レイモンド 1999、「ミームと神話の創造」。
- ^ ミーカー 2020、2:33–3:06。
- ^ レイモンド 2001、「大聖堂とバザール」。
- ^ ブロック2022、§16.3.4。
- ^ レイモンド 2001.
- ^ Raymond 2001、「オープンソース ソフトウェアの社会的文脈」。
- ^ レイモンド2001、19ページ。
- ^ オネッティ＆ヴァーマ 2009、69ページ。
- ^ ハマーリー、パキン、ウォルトン 1999年。
- ^ スミス2022、§3.2。
- ^ ab Sen、Subramaniam、Nelson 2008、211-212ページ。
- ^ ab Meeker 2020、16:13。
- ^ ローゼン2005、22-24頁を参照。
- ^ ベイン＆スミス 2022、§ 10.4.3。
- ^ ベイン＆スミス 2022、§ 10.4.2。
- ^ Bain & Smith 2022、§ 10.4.4を参照。
- ^ チェステック2022、30頁。
- ^ チェステック2022、184-185頁。
- ^ ローゼン2005、38ページ。
- ^ ジョイ2022、986頁。
- ^ ジョイ2022、989頁。
- ^ Dastar Corp.対Twentieth Century Fox Film Corp.、539 US 23、34（2003年）。
- ^ ジョイ2022、987-988頁。
- ^ ジョイ2022、1004-1006頁。
- ^ ジョイ2022、979、1002頁。
- ^ Rosen 2005、69ページより。
- ^ ローゼン2005、101-102ページ。
- ^ ab スミス 2022、§ 3.2.1.1。
- ^ OSI 2023。
- ^ ローゼン2005、73-90頁を参照。
- ^ OSI 2023、「MITライセンス」。
- ^ スミス2022、§3.2.1.2。
- ^ ベイン＆スミス 2022、§ 10.4.2。
- ^ OSI 2023、「Apacheライセンス、バージョン2.0」。
- ^ ベイン＆スミス 2022年、第10章。
- ^ ベイン＆スミス 2022、§ 10.4.4。
- ^ セントローラン 2004年、38～39頁。
- ^ ボールハウゼン2019、86頁。
- ^ ローゼン2005年、135ページ。
- ^ ローゼン2005年、103-106頁。
- ^ キーツ 2010、64ページ。
- ^ 「GNU Emacs コピー許可通知の全文」 1985 年。
- ^ キーツ 2010年、63-67頁。
- ^ ローゼン2005年、103-109頁。
- ^ ミーカー 2020、6:00–7:22。
- ^ ジョイ2022、990-992頁。
- ^ オネッティ＆ヴァーマ 2009、71ページ。
- ^ セントローラン 2004、81-83、114頁。
- ^ ボールハウゼン2019、82頁。
- ^ セントローラン2004、68、75ページ。
- ^ ab Tsai 2008、pp.564-570。
- ^ Hammerly、Paquin、Walton 1999、¶23。
- ^ セン、スブラマニアム、ネルソン 2008年、212-213頁。
- ^ Rosen 2005、対応する章を参照。
- ^ abc スミス2022、§3.3。
- ^ ローゼン2005、243-247頁。
- ^ セントローラン2004年、159-163頁。
- ^ 2004 年の Apache License バージョン 2.0、2007 年の GPL バージョン 3、2007 年の LGPL バージョン 3、2007 年の AGPL バージョン 3 については、Smith 2022、102 ページを参照してください。2012 年の MPL バージョン 2.0 と 2017 年の EPL バージョン 2 については、Smith 2022、95 ～ 101 ページを参照してください。
- ^ ベルネリン 2020、100、102頁。
- ^ オンブレダン 2020、105ページ。
- ^ オンブレダンヌ 2020、106頁。
- ^ Ballhausen 2022、§5.3を参照。
- ^ abcd スミス2022、§3.4.1。
- ^ ヤコブセン対カッツァー、535 F.3d 1373 ( Fed. Cir. 2008)。
- ^ Welte v. Sitecom（ミュンヘン地方裁判所 2004）、No. 21 O 6123/04。
- ^ スミス2022、106頁。
- ^ ローゼン2005、137ページ。
- ^ ローゼン2005、138ページ。
- ^ ローゼン 2005、第6章。
- ^ ミーカー 2020年17時04分。
- ^ セントローラン2004年、158-159頁。
- ^ ボールハウゼン2022、127頁。
- ^ Ballhausen 2022、§5.4を参照。
- ^ Walden 2022、§ 1.1を参照 。
- ^ スミス2022、§3.1.3。
- ^ Google LLC 対 Oracle America, Inc.、593 US、1203 (2021)。
- ^ スミス2022、§3.4.2。
- ^ スミス2022、§3.4。
- ^ Ross 2021、「Spacewar: 開発の終了」。
- ^ Rosen 2005、36ページより。
- ^ ウォルデン 2022、3ページ。
- ^ スミス2019、55-56頁。
- ^ ローゼン2005、74-77頁。
- ^ セントローラン 2004、98ページ。
- ^ Fagundes & Perzanowski 2020、p. 524。
- ^ ジョイ2022、1008-1010頁。
- ^ ブロック2022、§16.3.3。
- ^ セントローラン 2004、14ページ。
- ^ セントローラン 2004、22ページ。
- ^ オネッティ＆ヴァーマ 2009、81ページ。
- ^ セントローラン 2004、30ページ。
- ^ ブロック2022、§16.4.2.3。
- ^ 蔡 2008、550頁。
- ^ セントローラン2004、39ページ。
- ^ ab ブロック 2022、§ 16.5.2。
- ^ ブロック2022、§16.4.2.8。
- ^ ブロック2022、§16.4.2.2。
- ^ ブロック2022、§16.5.3。
- ^ ブロック2022、§16.5.3.8。
- ^ クネルト 2022.
- ^ 若林2019年。
- ^ ブロック2022、§16.5.3.2。
参考文献
- Ballhausen, Miriam (2019年6月). 「フリーソフトウェアライセンスとオープンソースソフトウェアライセンスの説明」. Computer . 52 (6): 82–86. doi : 10.1109/MC.2019.2907766 .
- Bernelin, Margo ( 2020 ). 「オープン/フリーライセンスの互換性：法的な混乱」。国際法情報技術ジャーナル。28 (2): 93–111。doi :10.1093/ijlit/eaaa010。
- ブロック、アマンダ編 (2022)。オープンソースの法律、ポリシー、実践 (第2版)。オックスフォード大学出版局。doi : 10.1093/oso/ 9780198862345.001.0001。ISBN 978-0-19-886234-5. 2023年3月26日時点のオリジナルよりアーカイブ。2023年1月29日閲覧。
- ベイン、マルコム、スミス、P・マッコイ。「特許と防御的対応」。ブロック（2022年）。
- ボールハウゼン、ミリアム。 「著作権の執行」。ブロックにて（2022年）。
- チェステック、パメラ。「商標」。Brock (2022)。
- Smith, P McCoy。「オープンソースにおける著作権、契約、ライセンス」。Brock (2022)。
- ウォルデン、イアン。「オープンソースを哲学、方法論、商取引として：法を態度で使う」。Brock (2022) より。
- Byfield, Bruce (2008 年 3 月 4 日)。「「フリー」および「オープンソース」ソフトウェア: Shibboleths のナビゲート」。Datamation。2024年6月 6 日閲覧。
- Carver, Brian W. (2005). 「共有と同等の共有: オープンソースとフリーソフトウェアのライセンスの理解と実施」Berkeley Technology Law Journal . 20 (1): 443–481. ISSN 1086-3818.
- コールマン、ガブリエラ (2004)。「フリーおよびオープンソースソフトウェアの政治的不可知論と、対比の意図しない政治」。人類学季刊誌。77 (3): 507–519。ISSN 0003-5491 。
- DiBona, Chris; Stone, Mark; Ockman, Sam, 編 (1999). 「オープンソースの定義」。オープンソース: オープンソース革命からの声。カリフォルニア州セバストポル: O'Reilly Media。2023年1月27日時点のオリジナルよりアーカイブ。 2023年1月21日閲覧。
- Hammerly, Jim; Paquin, Tom; Walton, Susan. 「Freeing the Source: The Story of Mozilla」DiBona, Stone & Ockman (1999) より。
- Perens, Bruce. 「オープン ソースの定義」。DiBona、Stone、Ockman (1999) より。
- レイモンド、エリック S.「ハッカーの復讐」。ディボナ、ストーン、オックマン (1999)。
- ファグンデス、デイブ、ペルザノフスキー、アーロン（2020年11月）。「著作権の放棄」ウィリアム・アンド・メアリー法学評論62 （ 2）：487–569。
- Fontana, Richard E. (2010 年 4 月)。「オープン ソース ライセンスの施行とコンプライアンス」。The Computer and Internet Lawyer。27 ( 4)。Aspen。
- Greenbaum, Eli (2016 年 4 月)。「オープンソースライセンスにおける非差別原則」(PDF)。Cardoza Law Review。37 ( 4) 。
- ジョイ、レーガン（2022年）。「クリエイティブ・コモンズの悲劇：重複する知的財産権が許容ライセンスの使用をいかに損なうかについての分析」。ケース・ウェスタン・リザーブ・ロー・レビュー。72 （4）：977–1013。
- キーツ、ジョナサン (2010)。「コピーレフト」。仮想語: 科学技術の先端にある言語。オックスフォード大学出版局。doi : 10.1093 /oso/ 9780195398540.003.0017。ISBN 978-0-19-539854-0. 2023年3月26日時点のオリジナルよりアーカイブ。2023年1月28日閲覧。
- Kunert, Paul (2022年9月8日). 「オープンソースビジネスがAkkaをビジネスソースライセンスに移行」。2022年10月31日時点のオリジナルよりアーカイブ。2023年1月25日閲覧。
- Maracke, Catharina (2019 年 7 月)。「フリーおよびオープンソース ソフトウェアとFRANDベースの特許ライセンス: 標準必須特許とフリーおよびオープンソース ソフトウェアを仲介する方法」。世界知的所有権ジャーナル。22 (3–4): 78–102。doi : 10.1111 /jwip.12114。
- Meeker, Heather (2020 年 1 月)。企業ユーザー向けオープンソース ソフトウェア ライセンスの基礎。オープンソース ソフトウェア ライセンス。2023年12 月 7 日に閲覧。
- オマーン、ラルフ（2018年春）。「著作権保護対象としてのコンピュータソフトウェア：Oracle対Google、立法意図、デジタル作品の権利範囲」ハーバード法とテクノロジージャーナル31 （ 2）：639-652。
- Ombredanne, Philippe (2020). 「フリーおよびオープンソースソフトウェアライセンスコンプライアンス：ソフトウェア構成分析ツール」. Computer . 53 (10): 105–109. doi :10.1109/MC.2020.3011082.
- オネッティ、アルベルト、バーマ、サミール (2009 年 5 月 1 日)。「オープン ソース ライセンスとビジネス モデル」。ICFAIナレッジマネジメント ジャーナル7 (1): 68–94。
- OSI (2023 年 2 月)。「OSI 承認ライセンス」。opensource.org。オープン ソース イニシアティブ。2023 年12 月 23 日閲覧。
- Raymond, Eric S. (2001)。『The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary (Revised ed.)』カリフォルニア州セバストポル: O'Reilly Media。ISBN 978-0-596-00108-7. 2003年4月24日時点のオリジナルよりアーカイブ。2023年1月28日閲覧。
- ローゼン、ローレンス (2005)。オープンソースライセンス: ソフトウェアの自由と知的財産法 (ペーパーバック版)。アッパーサドルリバー、ニュージャージー:プレンティスホール。ISBN 978-0-13-148787-1. 2022年12月19日時点のオリジナルよりアーカイブ。2023年1月21日閲覧。
- ロス、ヘザー（2021年1月4日）。「スペースウォー - ガイド、歴史、起源など」。History -Computer 。 2023年12月23日閲覧。
- Sen, Ravi; Subramaniam , Chandrasekar; Nelson, Matthew L. (2008 年冬)。「オープン ソース ソフトウェア ライセンスの選択の決定要因」。Journal of Management Information Systems。25 ( 3): 207–239。doi : 10.2753 /MIS0742-1222250306。
- スミス、アレクサンダー（2019）。彼らは世界を創る：ビデオゲーム業界を形作った人々と企業の物語。第1巻：1971-1982年。フロリダ州ボカラトン：CRCプレス。ISBN 978-1-138-38990-8。
- St. Laurent, Andrew M. (2004)。オープンソースとフリーソフトウェアライセンスの理解。カリフォルニア州セバストポル: O'Reilly Media。ISBN 978-0596005818。
- Tsai, John (2008). 「良くも悪くも: Gnu General Public License バージョン 3 の紹介」Berkeley Technology Law Journal 23 ( 1): 547–581.
- 若林大輔（2019年12月15日）。「プライム・レバレッジ：アマゾンはテクノロジーの世界でどのように権力を握っているか」ニューヨーク・タイムズ。2023年10月30日時点のオリジナルよりアーカイブ。 2024年5月24日閲覧。}
- ウィリアムズ、サム (2002)。『フリーダムの自由:リチャード・ストールマンのフリーソフトウェアへの闘い』(初版)。カリフォルニア州セバストポル: ファーナム:オライリーメディア。ISBN 978-0-596-00287-9. 2023年2月7日時点のオリジナルよりアーカイブ。2023年2月6日閲覧。