Loading article…
オープンソースライセンスとは、コンテンツの使用、変更、共有を可能にするソフトウェアライセンスです。これらは、フリーソフトウェアおよびオープンソースソフトウェア（FOSS）の開発を促進します。知的財産（IP）法は、創作物の改変と共有を制限します。フリーソフトウェアおよびオープンソースライセンスは、これらの既存の法的構造を逆の目的で利用します。ライセンスの受領者には、ソフトウェアの使用、ソースコードの検証、改変、および改変後の配布の権利が付与されます。これらの基準は、オープンソース定義（OSD）に概説されています。
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 ]デビアンでは、ペレンズがデビアン・フリーソフトウェア・ガイドライン（DFSG）を提案しました。[ 18 ] DFSGは、デビアンがリポジトリでホストするFOSSに対して、より具体的で客観的な標準を提供するために作成されました。[ 19 ] OSIはDSFGを採用し、それをオープンソース定義の基礎として使用しました。[ 20 ]フリーソフトウェア財団は、フリーソフトウェア定義という競合する基準セットを維持しています。[ 21 ]歴史的に、これら3つの組織とその基準セットは、ライセンスがフリーソフトウェアとオープンソースソフトウェアをカバーしているかどうかを判断する著名な権威となっています。[ 22 ]個々のライセンスには大きな違いがあるが、競合する定義の間にはほとんど違いがない。[ 16 ] 3 つの定義はいずれも、対象となるソフトウェアを受け取る人が、対象となる作品を使用、変更、再配布できることを要求している。[ 23 ]
エリック・S・レイモンドは、「フリーソフトウェア」よりも「オープンソース」という用語を提唱した。彼はオープンソースの方が企業にとって魅力的であり、FOSS開発の具体的な利点をより反映していると考えていた。レイモンドの目標の一つは、既存のハッカーコミュニティを拡大し、大規模な商業開発者を含めることだった。[ 24 ]『大聖堂とバザール』の中で、レイモンドはオープンソース開発を、屋外の公共市場であるバザールに例えた。 [ 25 ]彼は、倫理とは別に、オープンモデルはプロプライエタリソフトウェアでは再現できない利点を提供すると主張した。[ 26 ] [ 27 ]レイモンドはフィードバック、テスト、バグ報告に重点を置いた。[ 28 ]彼は、少数の秘密主義的な労働者がこの作業を行うプロプライエタリモデルと、潜在的に全世界がテスターのプールに含まれるLinuxの開発を対比させた。[ 29 ]彼はこの強みを「十分な数の目があれば、すべてのバグは浅いものになる」と要約した。[ 30 ] OSIは、Sun Microsystems、IBM、Netscape、Mozilla、Apache、Apple Inc.、Microsoft、Nokiaなどの企業開発者にオープンソース開発をもたらすことに成功した。これらの企業は既存のライセンスの下でコードをリリースし、OSIの承認を得るために独自のライセンスを作成した。[ 31 ] [ 32 ]
オープンソースライセンスは、コピーレフトまたはパーミッシブに分類されます。[ 33 ]コピーレフトライセンスでは、派生作品に同様のライセンスのソースコードを含める必要があります。パーミッシブライセンスでは必要なく、そのためコードはプロプライエタリソフトウェア内で使用できます。コピーレフトは、派生作品を広く定義するか狭く定義するかによって、さらに強いものと弱いものに分けられます。[ 34 ] [ 35 ]
ライセンスは著作権法に焦点を当てていますが、コードは他の形態の知的財産によっても保護されています。[ 36 ] 1990年代後半以降に作成された主要なオープンソースライセンスには特許付与が含まれています。これらのオープンソース特許付与は、開発者が保有する特許をカバーします。[ 37 ]ソフトウェア特許はアイデアをカバーし、特定の実装ではなく、クレームのあらゆる実装をカバーします。特許クレームは、アイデアに基づいて製品を製造、使用、販売、または輸入することを他者から排除する権利を保有者に与えます。特許は作成する権利ではなく排除する権利を与えるため、アイデアの特許を持っていても、発明が別の特許アイデアに依存している場合は、それを合法的に実装できない可能性があります。したがって、オープンソース特許付与は、カバーされている特許からの許可のみを提供できます。第三者がコードに組み込まれた概念を特許化していないことを保証することはできません。[ 36 ]古い寛容なライセンスは特許について直接言及せず、カバーされている素材の使用または販売のオファーで暗黙の特許付与のみを提供します。[ 38 ]新しいコピーレフトライセンスと 2004 年の Apache License は、明示的な特許付与と特許訴訟からの限定的な保護を提供します。[ 39 ]これらの特許報復条項は、対象ソフトウェアに関する特許訴訟を開始した当事者への付与を終了することにより、開発者を保護します。[ 39 ]
商標は、フリーソフトウェアやオープンソースソフトウェアで共有されない唯一の知的財産形態です。FOSS上の商標は、他の商標と同様に機能します。[ 40 ]商標は、製品の明確な出所を識別するデザインです。製品を区別するため、類似の出所を混同するリスクがないさまざまな分野で同じデザインを使用できます。[ 41 ]商標の管理を放棄すると、その商標を失うことになります。したがって、どのオープンソースライセンスも商標の使用を自由に提供しません。[ 42 ]
商標の制限は著作権と重複し、本来自由に利用できる素材に影響を与える可能性があります。[ 43 ]米国最高裁判所は、パブリックドメインのコンテンツを制限するために商標法を使用することを「変異著作権」と表現しました。[ 44 ] Dastar Corp. v. Twentieth Century Fox Film Corp.事件では、裁判所は、これらの変異著作権について明確な判決を下すことなく、「商標法の誤用または過剰な拡張」に対して警告しました。[ 45 ] [ 46 ]商標の重複は、外部の当事者が派生作品の商標を申請した場合、オープンソースおよびフリーコンテンツプロジェクトを「敵対的買収」に対して脆弱にする可能性があります。[ 47 ]特に、Andrey Duskin は、SCP ストーリーに基づく派生作品を作成する際に、共同執筆プロジェクトであるSCP Foundationの商標を申請しました。 [ 48 ]
学術ライセンスとも呼ばれる寛容ライセンス[ 49 ]は、受領者がソースコードを提供する義務なしにソフトウェアを使用、変更、配布することを許可する。機関は、自らの著作物を一般に配布するためにこれらのライセンスを作成した。[ 49 ]寛容ライセンスは通常短く、多くの場合1ページ未満のテキストである。それらはほとんど条件を課さない。ほとんどのライセンスには、保証の免責と著作者のクレジット義務が含まれている。特許、商標、その他の知的財産の明示的な規定を含むものもある。[ 50 ]
カリフォルニア大学バークレー校は、 Berkeley Software Distribution (BSD) オペレーティングシステムの配布を開始した際に、最初のオープンソースライセンスを作成しました。BSDライセンスとその後のバリエーションは、対象ソフトウェアの変更と配布を許可しています。これらのライセンスは、学問の自由という概念をコンピューティングにもたらしました。初期の学術ソフトウェア開発者は、暗黙の約束に基づいてコードを共有していました。バークレー校は、責任と保証に関する明確な免責事項と、再配布の条件、つまり条項によって、これらの概念を明示しました。元のライセンスには 4 つの条項がありましたが、その後のバージョンでは制限がさらに緩和されています。そのため、対象ソフトウェアが 2 条項バージョンまたは 3 条項バージョンを使用しているかどうかを指定するのが一般的です。[ 51 ] [ 52 ]
マサチューセッツ工科大学（MIT）は、 BSD のオリジナルに基づいて学術ライセンスを作成しました。MITライセンスは、条件をより明確にすることで、条件を明確化しました。[ 53 ]例えば、MIT ライセンスはサブライセンスの権利について説明しています。[ 54 ]オープンソース開発の強みの 1 つは、開発者が互いの派生作品に基づいて構築し、プロジェクトを組み合わせて集合作品にすることができる継続的なプロセスです。カバーされたコードを明示的にサブライセンス可能にすることで、著作権の連鎖を追跡する際に法的利点が得られます。[ 53 ] BSD と MIT は、あらゆるプロジェクトに適用できるテンプレート ライセンスです。これらは、多くの FOSS プロジェクトで広く採用され、使用されています。[ 51 ]
Apache License は、より包括的で明示的です。Apache Software Foundation がApache HTTP Server用に作成しました。2004 年に公開されたバージョン 2 は、単純なライセンスよりも法的利点があり、同様のライセンス付与を提供します。[ 55 ] BSD ライセンスと MIT ライセンスは暗黙の特許付与を提供しますが、[ 56 ] Apache License には、貢献者からの明示的な付与を含む特許に関するセクションが含まれています。[ 57 ]さらに、特許報復条項を持つ数少ない寛容なライセンスの 1 つです。[ 58 ]特許報復、または特許停止条項は、ライセンシーが対象コードに対して特許侵害訴訟を開始した場合に有効になります。その場合、特許付与は取り消されます。これらの条項は、特許トローリングから保護します。[ 59 ]
コピーレフトライセンスでは、ソースコードをソフトウェアとともに配布し、ソースコードを同様のライセンスの下で利用可能にすることを要求します。[ 34 ] [ 60 ]寛容なライセンスと同様に、ほとんどのコピーレフトライセンスでは帰属表示を要求します。[ 61 ] GPLを含むほとんどのライセンスは、暗黙の保証を否認します。[ 62 ]
コピーレフトは、知的財産法の制限を、その通常の目的とは逆に、コードがオープンなままであることを義務付けるために利用します。[ 63 ]この用語と関連するスローガン「All rights reversed」は、以前はプリンキピア・ディスコーディアやタイニーBASICで遊び心のある方法で使用されていましたが、現代の使用はリチャード・ストールマンがフリーのオペレーティングシステムを作成しようとした取り組みから始まります。1984年、プログラマーのドン・ホプキンスは「Copyleft Ⓛ」ステッカーを貼ったマニュアルをストールマンに郵送しました。GNUオペレーティングシステムに取り組んでいたストールマンはこの用語を採用しました。[ 64 ]コピーレフトライセンスの初期バージョンは、1985年のGNU Emacsのリリースで使用されました。[ 14 ] [ 65 ]この用語は、後にFSFの相互ライセンス、特にGNU General Public License（GPL）と関連付けられるようになりました。[ 66 ]
従来のプロプライエタリなソフトウェアライセンスは利益を増やすことを目的として書かれていますが、Stallman は利用可能なフリー ソフトウェアの規模を拡大するために GPL を作成しました。彼の相互ライセンスは、人々が同じ自由を提供するライセンスの下で派生作品をリリースしなければならないという条件で、作品を使用、変更、配布する権利を提供します。コピーレフトに基づいて構築されたソフトウェアにはソース コードが付属する必要があり、ソース コードは同じまたは類似のライセンスの下で利用可能でなければなりません。これにより、プロプライエタリ ソフトウェアがコードを消費するだけで何も返さないことに対する保護が提供されます。[ 67 ] [ 68 ] Richard Stallman は、「コピーレフトの中心的なアイデアは、著作権法を使用するが、それを通常の目的とは反対の目的に転用することである。つまり、ソフトウェアを私有化する手段ではなく、[著作権] はソフトウェアをフリーに保つ手段となる」と述べています。[ 69 ]フリー ソフトウェア ライセンスは、オープンソース ソフトウェア ライセンスでもあります。[ 70 ]フリー ソフトウェアとオープンソース ソフトウェアという別々の用語は、法的な違いではなく、異なる価値観を反映しています。[ 71 ]どちらの運動も、その正式な定義も、対象となる作品がソースコード付きで、変更と再配布の許可付きで公開されることを要求している。[ 16 ] FSF または OSI のいずれか一方のみがライセンスを受け入れるという例外的なケースが時折あるが、一般的なフリーソフトウェアライセンスは、 GPLを含めオープンソースである。[ 72 ]
コピーレフト ライセンスの実用的利点は、商用開発者を引き付けてきました。企業は、GPL よりも範囲の狭い相互ライセンスを使用したり、作成したりしてきました。[ 74 ]例えば、Netscape は Mozilla プロジェクトに寛容なライセンスを拒否した後、独自のコピーレフト条項を作成しました。[ 32 ] 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 ]これらは、企業がよく使用する弱いコピーレフトライセンスとは対照的に、強いコピーレフトと呼ばれています。弱いコピーレフトは、派生作品のより狭く明示的な定義を使用します。 [ 75 ] [ 35 ] MPL はファイルベースの定義を使用し、CPL と EPL はモジュールベースの定義を使用し、FSF 独自の LGPL はソフトウェア ライブラリを参照します。[ 76 ]
ライセンスの互換性は、異なるライセンスを持つコードをどのように一緒に配布できるかを決定します。オープンソースライセンスの目標は、作品を自由に利用できるようにすることですが、異なる要件を課す複数の用語を扱う場合、これは複雑になります。[ 77 ]あまり一般的ではないライセンスが多数あり、一部のプロジェクトは独自の契約書を作成します。その結果、これは他の法的側面よりも混乱を招きます。アプリケーションのコレクションをリリースする場合、各ライセンスは個別に検討できます。ただし、ソフトウェアを組み合わせようとする場合、別のプロジェクトのコードは、そのプロジェクトが互換性のある条件を使用している場合にのみライセンスを取り込むことができます。[ 78 ]
コードベースを組み合わせる場合、元のライセンスは個別のコンポーネントに対して維持され、より大きな作品は互換性のあるライセンスの下でリリースされます。[ 79 ]この互換性は多くの場合、一方通行です。パブリック ドメインのコンテンツは著作権の主張がないためどこでも使用できますが、ほぼすべての条件の下で取得したコードはパブリック ドメインに放棄することはできません。許容ライセンスはコピーレフト作品内で使用できますが、コピーレフト素材は許容ライセンスの下でリリースすることはできません。一部の弱いコピーレフト ライセンスは GPL の下で使用でき、GPL 互換であると言われています。GPL ソフトウェアは GPL または AGPL の下でのみ使用できます。[ 77 ]許容ライセンスはプロジェクトの個別の部分をカバーできるため、広く互換性があります。GPL や Apache License を含む複数のライセンスが互換性を高めるために改訂されています。[ 80 ]
翻訳の問題、ライセンス条項の曖昧さ、および一部のライセンスが特定の法域の法律と互換性がないことが、ライセンスの互換性の問題をさらに複雑にしています。[ 81 ]オープンソースモジュールのダウンロードは簡単ですが、ライセンス条項を遵守することはより困難になる場合があります。[ 82 ]ソフトウェアの依存関係が多いため、複雑なプロジェクトに取り組むエンジニアは、オープンソースコンポーネントのライセンス条項を遵守するためにライセンス管理ソフトウェアに頼ることがよくあります。[ 83 ]多くのオープンソースソフトウェアファイルではライセンスが明確に示されていないため、遵守の難しさが増します。[ 82 ]
フリーソフトウェアおよびオープンソースソフトウェアのライセンスは、2000年代半ば以降、民事裁判所で有効に執行されてきた。 [ 85 ]初期の訴訟2件、米国でのJacobsen v. KatzerとドイツでのWelte v. Sitecomでは、被告側はオープンソースライセンスが無効であると主張した。[ 86 ] [ 87 ] SitecomとKatzerはそれぞれ、ライセンスは執行不能であると主張した。米国とドイツの裁判所はどちらもこれらの主張を却下した。両裁判所は、ライセンスが執行不能であれば、被告側はソフトウェアを合法的に配布できなかったと判決を下した。[ 85 ] [ 84 ]
裁判所は、ソフトウェアを配布することはライセンス条項の承諾を示すものであると判断しています。[ 88 ]物理的なソフトウェアリリースでは、シュリンクラップに記載された通知によって消費者の同意を得ることができます。オンライン配布では、クリックラップを使用できます。これは、ユーザーがクリックして承諾する必要があるデジタル版です。[ 89 ]オープンソースソフトウェアには、追加の承諾メカニズムがあります。著作権者の許可なしに再配布することは法律で禁止されています。[ 90 ]したがって、裁判所は再配布をライセンス条項の承諾とみなします。これには、コピーレフトライセンスの帰属条項やソースコード条項が含まれる場合があります。[ 91 ] [ 92 ]
開発者は通常、訴訟を起こさずにコンプライアンスを達成します。コミュニティの反発の可能性などの社会的圧力は、多くの場合十分です。[ 93 ]特にドイツでは、停止命令書は企業をコンプライアンスに戻す一般的な方法です。[ 94 ]ドイツの法制度では、標準的なプロセスが確立されています。FOSS開発者は企業に停止命令書を提示します。これらの書簡には、違反からコンプライアンスに戻る方法が記載されています。ドイツの裁判官は、応答しない企業に対して裁判所命令による停止命令を発行できます。これらの最初のステップが失敗した場合は、民事訴訟が進められます。ドイツの訴訟法は明確で、原告に有利です。[ 95 ]
ライセンスの特定の側面を裁判所がどのように扱うかについては、依然として不確実性が残っています。[ 96 ]ソフトウェア全般については、何が特許の対象となり、何が著作権の対象となるかについて議論があります。アプリケーション プログラミング インターフェイス (API) に関して、欧州司法裁判所は 2012 年のSAS Institute事件で、「[コンピュータ プログラム] インターフェイスの根底にあるアイデアや原則は著作権で保護されない」と指摘しました。[ 97 ]同様の 2021 年の事件では、米国最高裁判所は、公正使用の下で、変形製品における API の再作成を許可しました。[ 98 ]
FOSSコミュニティ内で長年議論されてきたテーマは、オープンソースライセンスが「ベアライセンス」なのか契約なのかという点である。[ 96 ]ベアライセンスとは、知的財産法によって制限される行為が許可される条件のセットである。[ 85 ] FSFが提唱するベアライセンスの解釈では、著作権者が著作権侵害として訴訟を起こす。[ 85 ]契約の解釈では、関係者が契約違反として訴訟を起こすことができる。[ 99 ]米国とフランスの裁判所は、両方の解釈に基づいて訴訟を審理したことがある。[ 100 ] FSFやSoftware Freedom Conservancyのような非営利団体は、開発者のプロジェクトに対する権利を保持してコンプライアンスを強制することを申し出ている。[ 95 ]
著作権が切れると、作品はパブリックドメインとなり、誰でも自由に利用できるようになります。[ 102 ]著作権で保護されない創作物もあり、それらは直接パブリックドメインになります。コンピュータの初期の歴史では、これはソフトウェアに当てはまりました。[ 11 ]初期のコンピュータソフトウェアは、ハードウェアと一緒に無料で提供されることがよくありました。[ 103 ] MITで最初に開発された先駆的なビデオゲーム「Spacewar!」は、 PDP-1コンピュータのマーケティングとテストに使用されました。[ 104 ]
弁護士のローレンス・ローゼンによれば、著作権法は、創作者が作品をパブリックドメインに置くことを想定して書かれたものではない。そのため、知的財産法には著作権を放棄するための明確な道筋がない。「パブリックドメイン」と呼ばれる非常に寛容なライセンスは、何らかの権利を提供するが条件を課さない一方的な契約として法的に機能する可能性がある。 [ 105 ] [ 106 ]
パブリックドメインと同等のライセンス、例えばCreative Commons CC0 は、著作権の権利放棄をパブリック ドメインに提供するとともに、代替手段として寛容なソフトウェア ライセンスを提供します。パブリック ドメインの権利放棄を受け入れない法域では、寛容なライセンスが有効になります。[ 107 ]パブリック ドメインの権利放棄は、単純な学術ライセンスと同様の制限があります。これにより、外部の当事者が特許法または商標法を通じてパブリック ドメインの作品を管理しようとする可能性があります。[ 108 ]パブリック ドメインの権利放棄は、保証を他のどのタイプのライセンスとも異なる方法で扱います。MIT ライセンスのような非常に寛容なものでさえ、保証と責任を放棄します。フリー ソフトウェアを使用する人は誰でも、この免責事項を条件として受け入れなければなりません。パブリック ドメインのコンテンツは誰でも利用できるため、著作権の権利放棄は免責事項を課すことはできません。[ 102 ]
オープンソース ライセンスは、他の企業が対象ソフトウェアを商用化することを可能にします。[ 109 ]寛容なライセンスの下でリリースされた作品は、プロプライエタリ ソフトウェアに組み込むことができます。[ 110 ]寛容なライセンスは、プロプライエタリ ライセンスを含む新しい条項の追加を許可します。[ 111 ] [ 112 ]プロプライエタリ ソフトウェアは、Apache、BSD、および MIT ライセンスの下でリリースされたオープンソース コードを大幅に統合しています。[ 113 ]オープン コアは、開発者がコア ソフトウェアをオープンソースとしてリリースし、それを含む製品をプロプライエタリ ソフトウェアとして収益化するビジネス モデルです。[ 114 ]強力なコピーレフト GPL は、プロプライエタリ ソフトウェア内での配布を防止するために書かれています。[ 115 ] [ 116 ]弱いコピーレフト ライセンスは、派生作品に特定の要件を課し、特定の状況下で対象コードをプロプライエタリ ソフトウェア内で配布することを許可する場合があります。[ 77 ]
クラウドコンピューティングは、フリーソフトウェアやオープンソースソフトウェアに依存しており、ほとんどのライセンスが適用される配布を回避しています。クラウドソフトウェアは配布されるのではなく、ホストされます。[ 117 ]ベンダーがソフトウェアをオンラインでホストし、エンドユーザーは使用されているコードをダウンロードしたり、アクセスしたり、知る必要さえありません。[ 118 ]コピーレフトのGNU Affero General Public License (AGPL) は、対象となるコードがホストまたは配布されると適用されます。[ 119 ]一部の開発者はAGPLを採用しており、他の開発者はオープンソースライセンスの特徴を備えた独自のライセンスに切り替えています。[ 120 ]例えば、オープンコア開発者のElasticは、Apacheライセンスから「ソースが利用可能な」Server Side Public Licenseに切り替えました。[ 121 ]ソースが利用可能なソフトウェアには、参照用のソースコードが付属しています。[ 122 ]
2010 年以降、クラウド モデルの重要性が高まっています。[ 117 ]開発者は、オープンソース ソフトウェアをホスティングすることで利益を得ながら、上流に資金やコードを提供しないクラウド 企業を批判し、その行為をストリップ マイニングに例えています。[ 123 ]クラウド コンピューティングのリーダーであるAmazon Web Services は、ライセンスを遵守し、顧客の最善の利益のために行動していると述べています。[ 123 ] [ 124 ]