ソフトウェアライセンス

FSFとそのフリーソフトウェア定義に基づく様々なライセンスのソフトウェアの図：左側が「フリーソフトウェア」、右側が「プロプライエタリソフトウェア」。両側、つまりほぼ直交する「無料ダウンロード」（フリーウェア）です。

ソフトウェアライセンスは、ソフトウェアの使用または再配布を規制する法的手段です。

1970年代以降、米国ではソフトウェア著作権が認められています。著作権が認められているにもかかわらず、多くの企業はソフトウェアのコピーではなくライセンスを販売することを好みます。これは、再配布に関してより厳格な条件を適用できるためです。当初はシュリンクラップ契約でしたが、現在ではクリックラップやブラウズラップ契約として最も一般的に見られるライセンス契約は、購入者がライセンスの内容を少しでも読むことはほとんどありません。この種のライセンスの執行可能性は議論の的となっており、一部の法域では制限されています。サービスレベル契約は、ベンダーが購入者に対して一定レベルのサービスを提供することに同意するソフトウェアライセンスの一種で、多くの場合、金銭的なペナルティが伴います。

コピーレフトとは、派生作品にライセンス条項に基づくライセンスを義務付けるライセンスの一種です。コピーレフト・ライセンスは、フリーでオープンソースのライセンスです。サーバーサイド・パブリック・ライセンス[1]など、 4つの自由を遵守しないライセンスを「コピーレフト」と表現しようとする試みがなされてきましたが、これは用語の濫用として広く否定されています。他の種類のフリーライセンスにはこの要件がありません。許容型ライセンスでは通常、帰属表示のみが要件であり、パブリックドメインに相当するライセンスには制限はありません。オープンソース・ライセンスの急増はライセンスの互換性の問題を複雑化させていますが、すべてに共通する特徴があります。すなわち、同じライセンスの下での再配布と派生作品の許可、ソースコードへの無制限のアクセス、そして異なる用途間の差別禁止（特に商用利用の許可）です。

自由でオープン非フリー
パブリックドメイン[2]および同等のライセンス許容ライセンス[3] [4]コピーレフト[3] [4]非商用ライセンス[5]独自のライセンス[6]企業秘密[7]利用可能なソース
説明著作権保護を放棄する再ライセンス権を含む使用権を付与します（所有権の帰属、ライセンスの互換性を許可）使用権を付与し、所有権の取得を禁止する非営利目的のみの使用権を付与します。著作権の伝統的な使用法。権利を付与する必要はない。情報は公開されていない使用権を付与するが、特定の使用例に限定され、フリーソフトウェアやコピーレフトには適用されない
注目すべきソフトウェアライセンスPD、CC0 [8]MIT、Apache、MPL、BSDGPL、AGPLJRL [9]独自のソフトウェアSSPL
シリーズの一部
コンピューティングの法的側面

コンピュータプログラムのソースコード（またはオブジェクトコード形式のコンパイル済みバイナリ）[10]は著作権法によって保護されており、所有者にはコードの独占的複製権が付与されます。その根底にあるアイデアやアルゴリズムは著作権法によって保護されていませんが、多くの場合、企業秘密として扱われ、秘密保持契約などの手段によって秘匿されます。[11]ソフトウェアの著作権は1970年代半ばから認められており、ソフトウェアを作成した企業に帰属し、ソフトウェアを作成した従業員や請負業者には帰属しません。[2]

ソフトウェアのライセンスと権利は、マーク・ウェビンクによれば著作権の文脈で付与される。[12]フリーウェアとサブライセンスによって拡張される。
付与された権利パブリックドメインおよび同等のもの許容型 FOSSライセンス（例：BSDライセンス）コピーレフトFOSSライセンス（例：GPL）フリーウェア/シェアウェア/フリーミアム独自のライセンス企業秘密
著作権保持いいえはいはいはいはいはい
執行権はいはいはいはいはいいいえ
表示する権利はいはいはいはいはいいいえ
複製権はいはいはい頻繁いいえ著作権侵害に対する訴訟は、著作権者によって最も多く起こされる。
変更する権利はいはいはいいいえいいえいいえ
配布権はいはい、同じライセンスの下ではい、同じライセンスの下で頻繁いいえいいえ
再許諾権はいはいいいえいいえいいえいいえ
サンプルソフトウェアSQLite、ImageJApache ウェブサーバー、ToyBoxLinuxカーネル、GIMP、OBSIrfanview、WinampWindows、ほとんどの商用ビデオゲームとそのDRM、Spotify、xSplit、TIDALサーバー側の
クラウド コンピューティングプログラムとサービス、
フォレンジック アプリケーション、およびその他の基幹業務。

独自のソフトウェアライセンス

1995年にマクロメディアが発行した簡潔なベータテストソフトウェアライセンス

独占的ソフトウェアを販売するのではなくライセンス供与する傾向は、ソフトウェア著作権保護の範囲が明確であった以前の時代から存在していました。これらのライセンスは、ソフトウェア著作権が裁判所で認められた後も使用され続けており、著作権法よりも企業に特別な保護を与えると考えられています。[13]米国連邦法によれば、企業は販売先を制限することはできますが、購入者による製品の再販を阻止することはできません。ソフトウェアライセンス契約では通常、再販が禁止されており、企業は収益を最大化することができます。[14]

伝統的に、ソフトウェアはバイナリオブジェクトコードの形式で配布され、ユーザーは理解または変更できませんでしたが、[10]ダウンロードして実行できました。ユーザーは特定のバージョンのソフトウェアを使用するために永久ライセンスを購入しました。[15] 2023年時点でアプリケーションソフトウェアの市場シェアの大部分を占めるソフトウェア・アズ・サービス（SaaS）ベンダー[16]は、永久ライセンスを提供することはほとんどありません。[17] SaaSライセンスは通常一時的なもので、従量制またはサブスクリプションベースで課金されますが、[18]フリーミアムなどの他の収益モデルも使用されています。[19]顧客にとって、一時ライセンスの利点には、初期費用の削減、柔軟性の向上、永久ライセンスに比べて全体的なコストが低いことなどがあります。[15]場合によっては、従来のソフトウェアの販売者が要求する高額な1回限りの費用は中小企業には手の届かないものでしたが、従量制のSaaSモデルによりソフトウェアは手頃な価格になりました。[20]

エンドユーザー使用許諾契約書（EULA）

当初、エンドユーザーライセンス契約（EULA）は、製品を包むシュリンクラップ包装（シュリンクラップ契約参照）または紙に印刷されていました。このライセンスでは、顧客が一定期間内に製品を返却しない場合、契約に同意することがしばしば規定されていました。[21]近年では、EULAはクリックラップやブラウズラップとして最も一般的に見られ、ユーザーによるクリックやブラウズラップの閲覧が同意の証とみなされます。物理的な制約がなくなった結果、EULAの長さは増加しました。[22]ほとんどのEULAは、読んで理解するのは非常に困難である一方で、読まなくてもライセンス条項に同意するのは容易であるように設計されています。[13] [21]アクセスの容易さに関わらず、ライセンス契約を少しでも読む消費者はほとんどいません。[23] [24]ほとんどの消費者は、条項に異議がないと想定するか、ソフトウェアのインストール時に同意していることにほとんど気づきません。[25]企業は、消費者の不注意を利用してEULAに条項を挿入します。[26]

プロプライエタリソフトウェアは通常、コピーや再利用を禁止し、購入者がソフトウェアを1台のコンピュータでしか使用できないように制限する制限的なライセンスの下で提供されます。[6] [27] ソースコードはほとんど入手できません。派生的なソフトウェア作品やリバースエンジニアリングは通常明示的に禁止されています。[27]多くのEULAでは、ベンダーがユーザーに関する情報を収集し、それを無制限に使用することが許可されています。[28]一部のEULAでは、ビデオゲームの仮想世界における創作物など、ソフトウェアを使用して作成された派生作品に対するユーザーの著作権行使が制限されています。[29] [30]

ほとんどのEULAは、製品によって引き起こされた損害に対する一切の責任を否認しており[31]、購入者が救済を求めて裁判所を利用することを禁じています。[32]さらに、多くのEULAでは、ベンダーがいつでも条件を変更できることを認めており、顧客は返金を受けることなく、同意するか製品の使用を中止するかを選択する必要があります。[33] EULAでは、ベンダーが漠然とした理由や理由なしに一方的に解約できる場合がよくあります。[34]

EULAは、ほとんどの場合、ソフトウェアを使用するための交渉の余地のない条件として「受け入れるか、拒否するか」という形で提示されますが[35] 、両当事者が条件を完全に理解し、自由意志で合意する典型的な契約とはかけ離れています。[36]契約がどの程度拘束力を持つと考えられるかについては、かなりの議論がありました。1996年以前の米国では、クリックラップライセンスやブラウズラップライセンスは拘束力があるとはみなされていませんでしたが、それ以降は拘束力を持つことが多くなりました。[37] [22]欧州連合で施行されている新デジタルコンテンツ指令の下では、EULAは合理的な消費者の期待に反しない範囲でのみ執行可能です。デジタルコンテンツの複製および所有権の譲渡に関する制限に関しては、期待とEULAの内容のギャップが特に大きくなります。[38]多くのEULAには、管轄区域によっては執行不能となる可能性のある規定が含まれています。ソフトウェアベンダーは、ユーザーが法的手段に訴えて異議を申し立てることがほとんどないためか、これらの執行不能な条項を契約に残しています。[39]

サービスレベル契約（SLA）

サービスレベル契約は、エンタープライズソフトウェアでよく使用され、ソフトウェアのパフォーマンスや顧客から提起された問題への対応時間など、サービスレベルを保証します。多くの場合、サービスが合意された基準を満たさない場合、金銭的な罰則が規定されています。[40] SLAは、多くの場合、定量化可能な指標を用いて、可用性、信頼性、価格、セキュリティといった側面をカバーします。[41]クラウドコンピューティングでは、異なる企業が管理する可能性のある異なるコンピューティングサービスが使用されるため、多層SLAが一般的です。 [42]クラウドコンピューティングにおけるSLAは、2024年現在、活発に研究されている分野です。[43]

フリーおよびオープンソースのソフトウェアライセンス

1980年代のオープンソース運動以前は、ほとんどすべてのソフトウェアはプロプライエタリであり、ソースコードは公開されていませんでした。[44]オープンソースライセンスは、オープン性を最大限に高め、ソフトウェアの使用、普及、および後続のイノベーションに対する障壁を最小限に抑えることを目的としています。[5]

オープンソースライセンスにはいくつかの共通する重要な特徴がある。[45]

  • 自由な再配布：著作権者の許可や支払いなしに、誰でもソフトウェアを無償または有償で再配布することができます。[45]
  • ソースコードへの無制限の公開アクセス[45] —オープンソースという言葉が指すもの[46]
  • ユーザーはソフトウェアを改変し、派生的な著作物をリリースすることができる。その場合、フリーソフトウェアと同じ条件で、あるいは場合によっては異なるライセンスの下で行われる。[45]
  • 異なる用途間での差別の禁止[45]。これには商業的利用も含まれます。[9] [5]

オープンソース・イニシアティブは、オープンソース定義に準拠した新しいオープンソースライセンスを審査し、承認します。[45]

オープンソースライセンスの種類

円グラフには、最も一般的に使用されているオープンソース ライセンスが、Apache 30%、MIT 26%、GPL 18%、BSD 8%、LGPL 3%、MPL 2%、残りの 13% がそれぞれ市場シェア 1% 未満のライセンスとして表示されています。
2022 年現在、最も人気のあるオープンソース ライセンスは、 Apache ライセンス(permissive)、MIT ライセンス(permissive)、GPL (copyleft) です。
  • ソフトウェアがパブリックドメインにある場合、所有者の著作権は消滅しており、誰でも著作権の制限なしにその作品を使用することができます。[2]
  • 非制限的ライセンスは、派生作品のライセンスに制限を設けずに、作品を自由に再利用することを許可します。[4]それらの多くは、元の作者の帰属を要求します。[47]最初のオープンソースライセンスは、科学的なコラボレーションを促進することを目的とした非制限的ライセンスであるバークレーソフトウェアディストリビューション（BSD）で、1978年にカリフォルニア大学バークレー校にちなんで名付けられました。 [48]
  • コピーレフト・ライセンス（「share-alike」とも呼ばれる）[47]は、ソースコードをソフトウェアと共に配布し、同様のライセンスの下で利用可能にすることを義務付けています。[49] [50]コピーレフトは、フリーソフトウェアとみなされながらも、再利用を制限できる範囲が最も広いライセンスです。[51] GNU一般公衆利用許諾書（GPL）のような強力なコピーレフト・ライセンスは、プロプライエタリ・ソフトウェアの再利用を一切認めませんが、関連するGNU劣等一般公衆利用許諾書（LGPL）のような弱いコピーレフト・ライセンスは、状況によっては再利用を認めています。[4]開発者は、コピーレフト・ライセンスを、自らの貢献が他者に不当な利益をもたらさないことを保証する手段と捉えています。[4] [52]コピーレフトを選択するもう一つの動機は、派生作品に対する要件を通してオープンソースを促進することです。[47] ストールマンは、「コピーレフトの中心的な考え方は、著作権法を利用しつつ、それを通常の目的とは逆の目的に転用することである。つまり、ソフトウェアを私有化する手段ではなく、ソフトウェアを自由に保つ手段となるのだ」と述べています。[53]

ソフトウェア以外では、非営利のみのクリエイティブ・コモンズ・ライセンスが、作品から他人が過剰な利益を得るのを防ぎたい一部のアーティストの間で人気となっている。[52]しかし、非営利目的でのみ利用できるソフトウェアはオープンソースとはみなされない。[9] サン・マイクロシステムズの非営利のみのJava Research Licenseはオープンソースコミュニティによって拒否され、同社は2006年にJavaの大部分をGPLの下でリリースした。[9]

互換性

いくつかのオープンソースソフトウェアライセンスの互換性チャート

1989年以来、[44]様々なオープンソースソフトウェアライセンスが作成されてきました。[54]オープンソースソフトウェアライセンスの選択は、ライセンスの急増によりますます困難になっています。 [55] [56]ライセンスの多くは、わずかに異なるだけです。[57]多くのライセンスは互いに互換性がなく、フリーソフトウェア運動の目標を妨げています。[58]翻訳の問題、ライセンス条件の曖昧さ、一部のライセンスと特定の管轄区域の法律との非互換性が、問題をさらに複雑にしています。[59]

オープンソースモジュールのダウンロードは迅速かつ簡単ですが、ライセンス条項の遵守はより困難になる可能性があります。[60]ソフトウェアの依存関係の多さから、複雑なプロジェクトに取り組むエンジニアは、オープンソースコンポーネントのライセンス条項の遵守を実現するために、ソフトウェアライセンス管理ソフトウェアに頼らざるを得ないことがよくあります。[61]多くのオープンソースソフトウェアファイルはライセンスを明確に記載しておらず、遵守の困難さを増大させています。[60]コードベースを統合する場合、個々のコンポーネントについては元のライセンスを維持し、より大きな成果物は互換性のあるライセンスの下でリリースすることができます。[62]この互換性は多くの場合一方通行です。パブリックドメインのコンテンツは著作権を主張しないためどこでも使用できますが、ほぼあらゆる条件の下で取得されたコードはパブリックドメインに移行できません。パーミッシブライセンスはコピーレフト作品内で使用できますが、コピーレフト素材はパーミッシブライセンスの下でリリースすることはできません。一部の弱いコピーレフトライセンスはGPLの下で使用でき、GPL互換であると言われています。GPLソフトウェアはGPLまたはAGPLの下でのみ使用できます。[63]

執行可能性

フリーソフトウェアおよびオープンソースソフトウェアのライセンスは、2000年代半ば以降、民事裁判で効果的に執行されてきました。 [64]裁判所は、ソフトウェアの配布はライセンス条項の承諾を意味すると判断しています。[65]しかし、開発者は通常、訴訟を起こさずにライセンスの遵守を達成します。コミュニティからの反発の可能性などの社会的圧力で十分な場合が多いです。 [66] 停止命令書は、特にドイツにおいて、企業をライセンス遵守に戻すための一般的な方法です。[67]

FOSSコミュニティ内で長年議論されているテーマは、オープンソースライセンスが「ベアライセンス」なのか、それとも契約なのかという点です。[68]ベアライセンスとは、知的財産法によって制限されている行為が許可される条件の集合です。[64]フリーソフトウェア財団（FSF）が提唱するベアライセンス解釈では、著作権者は著作権侵害として訴訟を起こします。[64]契約解釈では、関係者は契約違反として訴訟を起こします。[69]米国とフランスの裁判所は、両方の解釈に基づいて訴訟を起こしてきました。[70]

価値

企業の90%以上が、オープンソースソフトウェアを自社のプロプライエタリソフトウェアのコンポーネントとして使用しています。[71]オープンソースソフトウェアを使用するか、あるいは既存のオープンソースソフトウェアを改善するためにオープンソースプロジェクトに参加するかという決定は、通常、実用的なビジネス上の決定です。[72] [73]プロプライエタリソフトウェアがオープンソースの代替ソフトウェアと直接競合する場合、その競争がプロプライエタリ製品の価格と品質に与える影響について、研究では矛盾する結果が出ています。[74]

数十年にわたり、一部の企業は、企業ユーザー向けにオープンソースソフトウェア製品のサービスを提供することをビジネスモデルとしてきました。これらの企業はオープンソースソフトウェア製品を管理し、ライセンスや使用料ではなく、改良、統合、その他のサービスに対して料金を請求しています。[75]オープンソースコンポーネントをベースとしたSaaS（ Software as a Service）製品はますます普及しています。[76]

オープンソースソフトウェアは透明性を高め、科学的結果の検証と受け入れを助けるため、科学的なアプリケーションには好まれます。[57]

参照

参考文献

  1. ^ 「Open Token Compensation License」。Open Token Compensation Licenseホームページ。 2025年3月26日閲覧。
  2. ^ abc O'Regan 2022、403ページ。
  3. ^ ab "ライセンス".オープンソース・イニシアティブ. 2022年9月16日. 2024年5月12日閲覧。
  4. ^ abcde セン、サブラマニアム & ネルソン 2008、p. 212.
  5. ^ abc Morin他 2012、「フリーおよびオープンソースソフトウェア（FOSS）ライセンス」。
  6. ^ O'Regan 2022、394ページより。
  7. ^ オレガン2022、396頁。
  8. ^ Fagundes & Perzanowski 2020、p. 524。
  9. ^ abcd Davila 2015、6ページ。
  10. ^ ボイル 2003、45ページより。
  11. ^ O'Regan 2022、394–396 ページ。
  12. ^ Larry Troan (2005). 「オープンソースとプロプライエタリな視点」(PDF) . RedHat Summit 2006 Nashville . redhat.com. p. 10. 2014年1月22日時点のオリジナル(PDF)からアーカイブ。 2015年12月29日閲覧。
  13. ^ 寺崎 2013, p. 469.
  14. ^ 寺崎 2013, pp. 469–470.
  15. ^ Clohessy et al. 2020, 40–41頁。
  16. ^ ワット 2023、4ページ。
  17. ^ デンプシーとケリハー 2018、p. 48.
  18. ^ デンプシーとケリハー、2018 年、48、57 ページ。
  19. ^ デンプシー & ケリハー 2018、61–63 ページ。
  20. ^ デンプシーとケリハー 2018、p. 2.
  21. ^ コーベット2019、455ページより。
  22. ^ ab Kim 2016、12、21頁。
  23. ^ Bakos et al. 2014, p. 1.
  24. ^ ベン・シャハール & シュナイダー 2014、p. 68.
  25. ^ 寺崎 2013, pp. 485–486.
  26. ^ コーベット2019、456–457頁。
  27. ^ ab Morin et al. 2012、「独自のライセンス」。
  28. ^ カーペンター2023、485–486頁。
  29. ^ アフージャ 2016年、381頁。
  30. ^ コーベット2019、456頁。
  31. ^ カーペンター2023、480–481頁。
  32. ^ カーペンター2023、481-482頁。
  33. ^ カーペンター2023、485頁。
  34. ^ カーペンター2023、482-483頁。
  35. ^ カーペンター2023、478頁。
  36. ^ コーベット2019、460頁。
  37. ^ 寺崎 2013, 471頁。
  38. ^ Oprysk & Sein 2020、620–621 ページ。
  39. ^ コーベット2019、461頁。
  40. ^ O'Regan 2022、151、219、224、405ページ。
  41. ^ Qazi et al. 2024、「パフォーマンス評価パラメータ」。
  42. ^ ラナとジーグラー、2010、p. 188.
  43. ^ カジら。 2024年、結論。
  44. ^ ベルネリン 2020、96頁。
  45. ^ abcdef Sen、Subramaniam、Nelson 2008、p.209。
  46. ^ Morin et al. 2012、「オープンソースとクローズドソース」。
  47. ^ abc Morin et al. 2012、「Permissive vs Copyleft」。
  48. ^ スミス 2022、§3.2.1.1。
  49. ^ セン、スブラマニアム、ネルソン 2008年、211～212頁。
  50. ^ セントローラン 2004年、38～39頁。
  51. ^ ダビラ 2015、5ページ。
  52. ^ ab Davila 2015、5～6頁。
  53. ^ ジョイ2022、990-992頁。
  54. ^ セン、スブラマニアム、ネルソン、2008、p. 208.
  55. ^ アラモウディら。 2020、p. 537.
  56. ^ ベルネリン 2020、94頁。
  57. ^ ab Morin et al. 2012、「互換性、増殖、断片化、方向性」。
  58. ^ ベルネリン 2020、98頁。
  59. ^ ベルネリン 2020、100、102頁。
  60. ^ オンブレダンヌ 2020年、105頁。
  61. ^ オンブレダンヌ 2020年、106頁。
  62. ^ セントローラン 2004年、159～163頁。
  63. ^ スミス 2022、§3.3。
  64. ^ abc Smith 2022、§3.4.1。
  65. ^ スミス2022、106頁。
  66. ^ セントローラン 2004年、158～159頁。
  67. ^ ボールハウゼン 2022、127頁。
  68. ^ ウォルデン 2022、§ 1.1。
  69. ^ スミス 2022、§3.4.2。
  70. ^ スミス 2022、§3.4。
  71. ^ バトラー他 2022年、1頁。
  72. ^ バトラーら。 2022、p. 11152。
  73. ^ ダビラ 2015、7ページ。
  74. ^ 周＆チョードリー 2022、731頁。
  75. ^ オーガストら。 2021 年、1 ～ 2 ページ。
  76. ^ August et al. 2021、p.1。

出典

  • アフージャ、ネハ（2016年）「商業的創作物：ユーザー生成コンテンツの活用を制御するエンドユーザーライセンス契約の役割」ジョン・マーシャル知的財産法レビュー16：381-410。
  • Alamoudi, Emad; Mehmood, Rashid; Aljudaibi, Wajdi; Albeshri, Aiiad; Hasan, Syed Hamid (2020). 「スマートインフラ時代のオープンソースおよびオープンデータライセンス：レビューとライセンス選択フレームワーク」.スマートインフラとアプリケーション：よりスマートな都市と社会の基盤. Springer International Publishing. pp.  537– 559. ISBN 978-3-030-13705-2。
  • アネサ・パトリツィア（2014年3月1日）「エンドユーザーライセンス契約の翻訳：問題点、戦略、そしてテクニック」ASp. La revue du GERAS . 65 (65): 87– 102. doi :10.4000/asp.4205. ISSN  1246-8185.
  • August, Terrence; Chen, Wei; Zhu, Kevin (2021). 「プロプライエタリソフトウェア企業とオープンソースソフトウェア企業の競争：戦略的貢献におけるライセンスの役割」. Management Science . 67 (5): 3041– 3066. doi :10.1287/mnsc.2020.3674.
  • バコス、ヤニス；マロッタ＝ワーグラー、フロレンシア；トロッセン、デイヴィッド・R. (2014). 「細字部分は読むのか？ 標準契約書に対する消費者の関心」法学ジャーナル43 (1): 1– 35. doi :10.1086/674424.
  • バルハウゼン、ミリアム (2022). 「著作権の執行」.オープンソース法、ポリシー、実践. オックスフォード大学出版局. pp.  126– 140. ISBN 978-0-19-886234-5。
  • ベン・シャハール、オムリ、シュナイダー、カール・E. (2014). 『あなたが知りたかった以上のこと：義務的情報開示の失敗』 プリンストン大学出版局. ISBN 978-0-691-16170-9。
  • ベルネリン、マーゴ (2020). 「オープンライセンスとフリーライセンスの互換性：法的難問」.国際法情報技術ジャーナル. 28 (2): 93– 111. doi :10.1093/ijlit/eaaa010.
  • ボイル、ジェームズ（2003）「第二次囲い込み運動とパブリックドメインの構築」『法と現代問題』66 (1): 33-74 . ISSN  0023-9186.
  • バトラー、サイモン。ガマリエルソン、ジョナス。ランデル、ビョルン。ブラックス、クリストファー。マットソン、アンダース。グスタフソン、トーマス。ファイスト、ジョナス。クヴァルンストロム、ベングト。レンロート、エリック (2022)。 「ソフトウェア集約型ビジネスにおけるオープンソース コンポーネントの導入に関する考慮事項と課題」。システムとソフトウェアのジャーナル。186 111152。エルゼビア BV。土井：10.1016/j.jss.2021.111152。ISSN  0164-1212。
  • カーペンター、オーウェン (2023). 「EULAか、それとも弔辞か？エンドユーザーライセンス契約と近未来のサイボーグの見直し」Health Matrix: Journal of Law- Medicine 33 : 467–498 .
  • Clohessy, Trevor; Acton, Thomas; Morgan, Lorraine (2020). 「SaaSのメリット：SaaS技術のプロビジョニングによるビジネス価値の測定」.クラウドコンピューティングのビジネス価値の測定. Springer International Publishing. pp.  39– 55. ISBN 978-3-030-43198-3。
  • コーベット、スーザン (2019). 「コンピュータゲームライセンス：EULAとその不満」.コンピュータ法とセキュリティレビュー. 35 (4): 453– 461. doi :10.1016/j.clsr.2019.03.007. ISSN  0267-3649.
  • ダビラ、ジャシント (2015). 「フリー、リブレ、オープンソースソフトウェアの政治的論理」.自由にアクセス可能な技術と知識資源の社会的利益. IGI Global. pp.  1– 24. ISBN 978-1-4666-8337-2。
  • デンプシー、デイビッド、ケリーハー、フェリシティ（2018年）『クラウドコンピューティングの業界動向：B2B収益モデルの代替』 Springer International Publishing. ISBN 978-3-319-87693-1。
  • ファグンデス、デイブ；ペルザノフスキー、アーロン（2020年11月）「著作権の放棄」ウィリアム・アンド・メアリー法学評論62 ( 2): 487–569。
  • ジョイ、レーガン（2022年）「クリエイティブ・コモンズの悲劇：重複する知的財産権が許容ライセンスの利用をいかに阻害するかについての分析」ケース・ウェスタン・リザーブ・ロー・レビュー72 ( 4): 977-1013。
  • キム、ナンシー・S. (2016). 「ラップ契約とオンライン環境：原因と解決策」電子商取引法研究ハンドブック. エドワード・エルガー出版. ISBN 978-1-78347-992-4。
  • ランガー、アーサー・M. (2016). 『ソフトウェア開発ガイド：ライフサイクルの設計と管理』シュプリンガー. ISBN 978-1-4471-6799-0。
  • モーリン, アンドリュー; アーバン, ジェニファー; スリス, ピオトル (2012). 「科学者プログラマーのためのソフトウェアライセンスクイックガイド」. PLOS Computational Biology . 8 (7) e1002598. Bibcode :2012PLSCB...8E2598M. doi : 10.1371/journal.pcbi.1002598 . ISSN  1553-7358. PMC 3406002.  PMID 22844236  .  この記事には、CC BY 4.0 ライセンスに基づいて利用可能なテキストが組み込まれています。
  • オムブレダンヌ、フィリップ (2020). 「フリーソフトウェアおよびオープンソースソフトウェアのライセンスコンプライアンス：ソフトウェア構成分析ツール」. Computer . 53 (10): 105–109 . doi : 10.1109/MC.2020.3011082 .
  • Oprysk, Liliia; Sein, Karin (2020年6月). 「エンドユーザーライセンス契約における制限：新デジタルコンテンツ指令における適合性の欠如は存在するか？」IIC - 国際知的財産・競争法レビュー. 51 (5): 594– 623. doi :10.1007/s40319-020-00941-y.
  • オレガン、ジェラード（2022年）『ソフトウェアエンジニアリング簡潔ガイド：基礎から応用方法まで』シュプリンガー・ネイチャー、ISBN 978-3-031-07816-3。
  • Qazi, Faiza; Kwak, Daehan; Khan, Fiaz Gul; Ali, Farman; Khan, Sami Ullah (2024). 「クラウドコンピューティングにおけるサービスレベル契約：分類、展望、そして課題」. Internet of Things . 25 101126. doi : 10.1016/j.iot.2024.101126 . ISSN  2542-6605.
  • Rana, Omer; Ziegler, Wolfgang (2010). 「サービスレベル契約の管理と活用における研究課題」.グリッド、P2P、サービスコンピューティング. Springer. ISBN 978-1-4419-6793-0。
  • Sen, Ravi; Subramaniam, Chandrasekar; Nelson, Matthew L. (2008). 「オープンソースソフトウェアライセンスの選択における決定要因」. Journal of Management Information Systems . 25 (3). Informa UK Limited: 207– 240. doi :10.2753/mis0742-1222250306. ISSN  0742-1222.
  • Smith, P McCoy (2022年10月20日). 「オープンソースにおける著作権、契約、ライセンス」.オープンソース法、ポリシー、実践. オックスフォード大学出版局. pp.  71– 112. doi :10.1093/oso/9780198862345.003.0003. ISBN 978-0-19-886234-5。
  • セント・ローラン、アンドリュー・M. (2004). 『オープンソースとフリーソフトウェアライセンスの理解』O'Reilly Media . ISBN 978-0-596-00581-8。
  • テラサキ、マイケル (2013). 「エンドユーザーライセンス契約は一般人を拘束するか？」ウェスタン州立大学ローレビュー41 : 467 .
  • イアン・ウォルデン（2022年10月20日）「オープンソースの哲学、方法論、そして商業：法を態度で用いる」『オープンソースの法、政策、そして実践』オックスフォード大学出版局。doi :10.1093/oso/9780198862345.003.0001. ISBN 978-0-19-886234-5。
  • Watt, Andy (2023). 『C#と.NETによる最新のSaaSアプリケーションの構築：プロフェッショナルなSaaSアプリケーションの構築、展開、保守』 Packt. ISBN 978-1-80461-087-9。
  • Zhou, Zach Zhizhong; Choudhary, Vidyanand (2022). 「オープンソースソフトウェアからの競争がプロプライエタリソフトウェアに与える影響」. Production and Operations Management . 31 (2): 731– 742. doi :10.1111/poms.13575.

さらに読む

  • Classen, H. Ward (2022). 『ソフトウェアライセンスとクラウドコンピューティングの実践ガイド』 . アメリカ法曹協会. ISBN 978-1-64105-750-9。
WikibooksにはFOSSライセンスに関する書籍があります。
「https://en.wikipedia.org/w/index.php?title=Software_license&oldid=1315627065」より取得