Loading article…
ソフトウェア ライセンスは、ソフトウェアの使用または再配布を管理する法的手段です。
1970 年代以降、米国ではソフトウェアの著作権が認められています。著作権が認められているにもかかわらず、ほとんどの企業はソフトウェアのコピーではなくライセンスを販売することを好みます。ライセンスの方が再配布に対してより厳しい条件を適用できるためです。当初はシュリンクラップ契約でしたが、現在ではクリックラップやブラウズラップとして最も一般的に見られるライセンスの一部を読む購入者はほとんどいません。この種のライセンスの強制力は議論の余地があり、一部の法域では制限されています。サービス レベル契約は別の種類のソフトウェア ライセンスで、ベンダーが購入者に一定レベルのサービスを提供することに同意するもので、多くの場合、金銭的な罰則が伴います。
コピーレフトは、派生作品にライセンスを付与することを義務付けるフリー ライセンスの一種です。他の種類のフリー ライセンスにはこの要件がありません。許容ライセンスの場合、通常は帰属表示のみが要件であり、パブリック ドメインに相当するライセンスには制限がありません。オープン ソース ライセンスの急増により、ライセンスの互換性の問題が複雑化していますが、すべてに共通する特徴があります。同じライセンスで再配布と派生作品を許可し、ソース コードに無制限にアクセスでき、さまざまな用途を区別せず、特に商用利用を許可します。
ソフトウェア著作権
コンピュータプログラムのソースコード（またはオブジェクトコードの形でコンパイルされたバイナリ）[9]は著作権法によって保護されており、所有者にはコードを複製する排他的権利が与えられています。基礎となるアイデアやアルゴリズムは著作権法で保護されていませんが、多くの場合、企業秘密として扱われ、秘密保持契約などの方法で隠蔽されています。[10]ソフトウェアの著作権は1970年代半ばから認識されており、ソフトウェアを作成した従業員や請負業者ではなく、ソフトウェアを作成した会社に帰属します。[1]
独自のソフトウェアライセンス
.jpg/500px-Ohhh,_Shockwave_(117804940).jpg)
独占的ソフトウェアを販売するのではなくライセンス供与する傾向は、ソフトウェア著作権保護の範囲が明確であった時代以前に遡る。これらのライセンスは、ソフトウェア著作権が裁判所で認められた後も使用され続けており、著作権法に比べて企業に特別な保護を与えると考えられている。[12]米国連邦法によると、企業は販売先を制限することはできるが、購入者が製品を再販することを阻止することはできない。ソフトウェアライセンス契約では通常、再販が禁止されており、企業が収益を最大化できるようにしている。[13]
従来、ソフトウェアはバイナリオブジェクトコードの形式で配布されており、ユーザーは理解したり変更したりすることはできませんでしたが、[9]ダウンロードして実行することはできました。ユーザーは特定のバージョンのソフトウェアを使用するために永久ライセンスを購入しました。[14 ] 2023年現在、アプリケーションソフトウェアの市場シェアの大部分を占めるソフトウェア・アズ・サービス（SaaS）ベンダー[15]は、永久ライセンスを提供することはほとんどありません。[16] SaaSライセンスは通常一時的なもので、使用量ベースまたはサブスクリプションベースで課金されますが、[17]フリーミアムなどの他の収益モデルも使用されます。[18]顧客にとって、一時ライセンスの利点には、初期費用の削減、柔軟性の向上、永久ライセンスと比較して全体的なコストの削減などがあります。[14]場合によっては、従来のソフトウェアの販売者が要求する高額な1回限りのコストは中小企業には手が届きませんでしたが、従量課金制のSaaSモデルによりソフトウェアを手頃な価格で入手できます。[19][アップデート]
エンドユーザー使用許諾契約 (EULA)
当初、エンドユーザーライセンス契約 (EULA) は、製品を包むシュリンクラップ包装 (シュリンクラップ契約を参照) または紙に印刷されていました。ライセンスでは、指定された期間内に製品を返却しない場合は顧客が同意する、と規定されることがよくありました。[20]最近では、EULA はクリックラップまたはブラウズラップとして最も一般的に見られ、ユーザーのクリックまたはブラウジングの継続が同意のサインとみなされます。物理的な制約がなくなった結果、長さが増加しました。[21]ほとんどの EULA は、読んで理解するのは非常に難しいが、読まなくてもライセンス条件に同意するのは簡単であるように設計されています。[12] [20]アクセスがどれだけ簡単であっても、ライセンス契約の一部を読む消費者はほとんどいません。[22] [23]ほとんどの消費者は、条件に異議がないと想定するか、ソフトウェアのインストール中に同意していることにほとんど気づきません。[24]企業は、消費者の不注意を利用して EULA に条項を挿入します。[25]
プロプライエタリソフトウェアは通常、コピーや再利用を禁止し、購入者がソフトウェアを1台のコンピュータでしか使用できないように制限する制限付きライセンスの下で提供されます。 [5] [26] ソースコードが利用できることはめったにありません。派生的なソフトウェア作品やリバースエンジニアリングは通常明示的に禁止されています。[26]多くのEULAでは、ベンダーがユーザーに関する情報を収集し、それを制限なく使用することを認めています。 [27]一部のEULAでは、ビデオゲームの仮想世界における創作物など、ソフトウェアを使用して作成された派生作品に対するユーザーの著作権行使を制限しています。[28] [29]
大半のEULAは、製品によって引き起こされた損害に対する責任を否認し、 [30]購入者が救済を求めるために裁判所を利用することを禁じています。[31]さらに、多くのEULAでは、ベンダーがいつでも条件を変更できることを認めており、顧客は返金を受けることなく、同意するか製品の使用を中止するかを選択する必要があります。[32] EULAでは、ベンダーがさまざまな漠然とした理由や理由なしに一方的に解約することを認めているのが一般的です。[33]
EULA は、ほとんどの場合、ソフトウェアを使用するための交渉の余地のない条件として、受け入れるか拒否するかのどちらか一方のみを提示されます。 [34]両当事者が条件を完全に理解し、自由意志で同意する典型的な契約とはかけ離れています。[35]契約がどの程度拘束力を持つと考えられるかについては、かなりの議論がありました。1996 年以前の米国では、クリックラップ ライセンスやブラウズラップライセンスは拘束力があるとはみなされていませんでしたが、それ以降は拘束力を持つことが多くなりました。[36] [21]欧州連合で発効した新しいデジタル コンテンツ指令では、EULA は、合理的な消費者の期待に反しない範囲でのみ強制力を持ちます。期待と EULA の内容のギャップは、デジタル コンテンツの複製と所有権の譲渡に関する制限に関しては特に大きくなります。[37]多くの EULA には、管轄によっては強制力がないとみられる規定が含まれています。ソフトウェア ベンダーは、ユーザーが法的制度に訴えて異議を申し立てることはめったにないためか、これらの強制力のない条項を契約に残しています。[38]
サービスレベル契約 (SLA)
サービスレベル契約は、エンタープライズソフトウェアでよく使用され、ソフトウェアのパフォーマンスや顧客が提起した問題への対応時間などのサービスレベルを保証します。多くの場合、サービスが合意された基準を満たさない場合の金銭的な罰則が規定されています。[39] SLAは、定量化可能な指標を使用して、可用性、信頼性、価格、セキュリティなどの側面をカバーすることがよくあります。[40]クラウドコンピューティングでは、異なる企業が管理する可能性のあるさまざまなコンピューティングサービスが使用されるため、多層SLAが一般的です。 [41]クラウドコンピューティングのSLAは、2024年現在、活発に研究されている分野です[アップデート]。[42]
フリーおよびオープンソースのソフトウェアライセンス
1980年代のオープンソース運動以前は、ほぼすべてのソフトウェアがプロプライエタリであり、ソースコードは公開されていませんでした。[43]オープンソースライセンスは、オープン性を最大限に高め、ソフトウェアの使用、普及、および後続のイノベーションに対する障壁を最小限に抑えることを目的としています。[4]
オープンソースライセンスにはいくつかの共通する重要な特徴がある。[44]
- 無料の配布：著作権者の許可や著作権者への支払いなしに、誰でも無料で、あるいは有償でソフトウェアを再配布することができます。[44]
- ソースコードへの無制限の公開アクセス[44] —オープンソースという言葉が指すもの[45]
- ユーザーは、フリーソフトウェアと同じ条件、または場合によっては異なるライセンスの下で、ソフトウェアを改変し、派生的な著作物をリリースすることができます。 [44]
- 異なる用途間での差別禁止[44] 、商業的利用を含む[8] [4] 。
オープンソース・イニシアティブは、オープンソース定義に準拠した新しいオープンソース・ライセンスを審査し、承認します。[44]
オープンソースライセンスの種類
- ソフトウェアがパブリックドメインにある場合、所有者の著作権は消滅しており、誰でも著作権の制限なしにその作品を使用することができます。[1]
- 非制限的ライセンスは、派生作品のライセンスに制限を設けずに、作品を自由に再利用することを許可します。[3]その多くは、オリジナルの作成者の表示を要求します。[46]最初のオープンソースライセンスは、科学的コラボレーションを促進することを目的とした非制限的ライセンスで、1978年にカリフォルニア大学バークレー校にちなんで名付けられたバークレーソフトウェアディストリビューション（BSD）でした。[47]
- コピーレフトライセンス (別名「共有」) [46]では、ソース コードをソフトウェアと共に配布し、同様のライセンスの下でソース コードを公開する必要があります。[ 48] [49]コピーレフトは、フリー ソフトウェアと見なされながら、再利用を制限できる範囲が最も広いライセンスです。[50] GNU 一般公衆利用許諾書(GPL)などの強力なコピーレフト ライセンスでは、プロプライエタリ ソフトウェアでの再利用は許可されませんが、関連するGNU 劣等一般公衆利用許諾書(LGPL)などの弱いコピーレフトでは、状況によっては再利用が許可されます。[3]開発者は、コピーレフト ライセンスを、自分の貢献が他者に不当な利益をもたらさないことを保証する方法と認識しています。[3] [51]コピーレフトを選択するもう 1 つの動機は、派生作品の要件を通じてオープン ソースを促進することです。[46]ストールマンは、「コピーレフトの中心的な考え方は、著作権法を使用することですが、それを通常の目的とは逆に反転させることです。つまり、ソフトウェアを私有化する手段ではなく、[著作権] をソフトウェアをフリーに保つ手段にするのです」と述べています。[52]
ソフトウェア以外では、非営利のみのクリエイティブ・コモンズ・ライセンスが、他人が自分の作品から過剰な利益を得るのを防ぎたい一部のアーティストの間で人気となっている。[51]しかし、非営利目的でのみ利用できるソフトウェアはオープンソースとはみなされない。[8] サン・マイクロシステムズの非営利のみのJava Research Licenseはオープンソースコミュニティによって拒否され、同社は2006年にJavaの大部分をGPLの下でリリースした。[8]
互換性
1989年以来、[43]オープンソースソフトウェアのさまざまなライセンスが作成されてきました。[53]オープンソースソフトウェアのライセンスを選択することは、ライセンスの急増によりますます困難になっています。 [54] [55]ライセンスの多くは、わずかな違いしかありません。[56]多くのライセンスは互いに互換性がなく、フリーソフトウェア運動の目標を妨げています。[57]翻訳の問題、ライセンス条件の曖昧さ、一部のライセンスと特定の管轄区域の法律との非互換性が、問題をさらに複雑にしています。[58]
オープンソース モジュールのダウンロードは迅速かつ簡単ですが、ライセンス条件の遵守はより困難になる可能性があります。[59]ソフトウェアの依存関係が多いため、複雑なプロジェクトに取り組んでいるエンジニアは、オープンソース コンポーネントのライセンス条件に準拠するために、ソフトウェア ライセンス管理ソフトウェアに頼らなければならないことがよくあります。[60]多くのオープンソース ソフトウェア ファイルではライセンスが明確に示されていないため、準拠が困難になっています。[59]コード ベースを組み合わせる場合、元のライセンスを個別のコンポーネントに維持し、互換性のあるライセンスの下でより大きな作品をリリースすることができます。[61]この互換性は、多くの場合、一方通行です。パブリック ドメインのコンテンツは、著作権の主張がないためどこでも使用できますが、ほぼすべての条件の下で取得されたコードをパブリック ドメインにすることはできません。許容ライセンスはコピーレフトの作品内で使用できますが、コピーレフトの素材を許容ライセンスの下でリリースすることはできません。一部の弱いコピーレフト ライセンスは GPL の下で使用でき、GPL 互換であると言われています。GPL ソフトウェアは、GPL または AGPL の下でのみ使用できます。[62]
執行可能性
フリーソフトウェアやオープンソースソフトウェアのライセンスは、2000年代半ばから民事裁判所で効果的に執行されてきました。 [63]裁判所は、ソフトウェアを配布することはライセンスの条件に同意したことを意味すると判断しました。[64]しかし、開発者は通常、訴訟を起こさずにコンプライアンスを達成します。コミュニティの反発の可能性などの社会的圧力で十分な場合が多いです。[65] 停止命令書は、特にドイツでは、企業をコンプライアンスに戻すための一般的な方法です。[66]
FOSSコミュニティ内で長く議論されているテーマは、オープンソースライセンスが「ベアライセンス」なのか、それとも契約なのかということである。[67]ベアライセンスとは、知的財産法によって制限されている行為が許可される条件のセットである。 [63]フリーソフトウェア財団（FSF）が提唱するベアライセンスの解釈では、著作権者は著作権侵害として訴訟を起こす。[63]契約の解釈では、当事者は契約違反として訴訟を起こすことができる。[68]米国とフランスの裁判所は、両方の解釈に基づいて訴訟を審理した。[69]
価値
企業の90％以上が、オープンソースソフトウェアを自社のプロプライエタリソフトウェアのコンポーネントとして使用しています。[70]オープンソースソフトウェアを使用するか、既存のオープンソースソフトウェアを改善するためにオープンソースプロジェクトに参加するかという決定は、通常、実用的なビジネス上の決定です。[71] [72]プロプライエタリソフトウェアがオープンソースの代替品と直接競合する場合、競争がプロプライエタリ製品の価格と品質に与える影響について、研究により矛盾する結果が明らかになっています。[73]
数十年にわたり、企業ユーザー向けのオープンソースソフトウェア製品のサービスをビジネスモデルとしてきた企業もあります。これらの企業はオープンソースソフトウェア製品を管理し、ライセンスや使用料を請求するのではなく、改善、統合、その他のサービスに対して料金を請求します。[74] オープンソースコンポーネントに基づくSaaS（サービスとしてのソフトウェア）製品はますます一般的になっています。 [75]
オープンソースソフトウェアは透明性を高め、科学的結果の検証と受け入れを助けるため、科学的なアプリケーションには好まれます。[56]
参照
- フリーソフトウェアとオープンソースソフトウェアのライセンスの比較
- デジタル著作権管理
- コピー防止
- デュアルライセンス
- ライセンスフリーソフトウェア
- ライセンスマネージャー
- 製品のアクティベーション
- プロダクトキー
- 権利表現言語
- ソフトウェアメータリング
- 利用規約
- 永久アクセス
- 著作権ライセンス（カテゴリ）
- ライセンス別ソフトウェア（カテゴリ）
参考文献
- ^ abc O'Regan 2022、403頁。
- ^ ab 「ライセンス」。オープンソース・イニシアティブ。2022年9月16日。 2024年5月12日閲覧。
- ^ abcde Sen、Subramaniam、Nelson 2008、p.212。
- ^ abc Morin et al. 2012、「フリーおよびオープンソースソフトウェア (FOSS) ライセンス」。
- ^ ab O'Regan 2022、p.394より。
- ^ オレガン2022、396頁。
- ^ Fagundes & Perzanowski 2020、p. 524.
- ^ abcd Davila 2015、6ページ。
- ^ ボイル2003、45ページより。
- ^ オレガン2022年、394-396頁。
- ^ Larry Troan (2005). 「Open Source from a Proprietary Perspective」(PDF) . RedHat Summit 2006 Nashville . redhat.com. p. 10. 2014年1月22日時点のオリジナル(PDF)からアーカイブ。 2015年12月29日閲覧。
- ^ 寺崎2013、469頁。
- ^ 寺崎 2013, pp. 469–470.
- ^ ab Clohessyら。 2020、40–41ページ。
- ^ ワット2023、4ページ。
- ^ デンプシー＆ケリーハー2018、48頁。
- ^ デンプシーとケリハー、2018 年、48、57 ページ。
- ^ デンプシー & ケリハー 2018、61–63 ページ。
- ^ デンプシー＆ケリーハー 2018、2ページ。
- ^ コルベット2019、455頁より。
- ^ キム2016、12、21頁。
- ^ Bakos et al. 2014、p.1。
- ^ ベン・シャハール＆シュナイダー 2014、68ページ。
- ^ 寺崎 2013, pp. 485–486.
- ^ コーベット2019、456-457頁。
- ^ ab Morin et al. 2012、「独自のライセンス」。
- ^ カーペンター2023、485-486頁。
- ^ アフージャ2016年、381頁。
- ^ コーベット2019、456頁。
- ^ カーペンター2023、480-481頁。
- ^ カーペンター2023、481-482頁。
- ^ カーペンター2023、485頁。
- ^ カーペンター2023、482-483頁。
- ^ カーペンター2023、478頁。
- ^ コーベット2019、460頁。
- ^ 寺崎2013、471頁。
- ^ Oprysk & Sein 2020、620–621 ページ。
- ^ コーベット2019、461頁。
- ^ オレガン2022、151、219、224、405頁。
- ^ Qazi et al. 2024、「パフォーマンス評価パラメータ」。
- ^ ラナ＆ジーグラー 2010、188ページ。
- ^ カジら。 2024年、結論。
- ^ ベルネリン2020、96頁。
- ^ abcdef セン、スブラマニアム、ネルソン 2008、p.209。
- ^ Morin et al. 2012、「オープンソースとクローズドソース」
- ^ abc Morin et al. 2012、「Permissive 対 Copyleft」。
- ^ スミス2022、§3.2.1.1。
- ^ セン、スブラマニアム、ネルソン 2008年、211-212頁。
- ^ セントローラン 2004年、38～39頁。
- ^ ダビラ 2015、5ページ。
- ^ ab Davila 2015、pp.5-6を参照。
- ^ ジョイ2022、990-992頁。
- ^ セン、スブラマニアム、ネルソン 2008、208ページ。
- ^ アラモウディら。 2020、p. 537.
- ^ ベルネリン2020、94頁。
- ^ ab Morin et al. 2012、「互換性、増殖、断片化、方向性」。
- ^ ベルネリン2020、98頁。
- ^ ベルネリン 2020、100、102頁。
- ^ オンブレダン 2020、105ページ。
- ^ オンブレダンヌ 2020、106頁。
- ^ セントローラン2004年、159-163頁。
- ^ スミス2022、§3.3。
- ^ abc スミス2022、§3.4.1。
- ^ スミス2022、106頁。
- ^ セントローラン2004年、158-159頁。
- ^ ボールハウゼン2022、127頁。
- ^ ウォルデン 2022、§ 1.1。
- ^ スミス2022、§3.4.2。
- ^ スミス2022、§3.4。
- ^ バトラー他2022年、1頁。
- ^ バトラーら。 2022、p. 11152.
- ^ ダビラ2015、7ページ。
- ^ 周＆チョードリー2022、731頁。
- ^ オーガストら。 2021 年、1 ～ 2 ページ。
- ^ August et al. 2021、p.1。
出典
- Ahuja, Neha (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): 87–102。doi :10.4000/asp.4205。ISSN 1246-8185 。
- August, Terrence; Chen, Wei; Zhu , Kevin ( 2021). 「プロプライエタリソフトウェア企業とオープンソースソフトウェア企業間の競争：戦略的貢献におけるライセンスの役割」。マネジメントサイエンス。67 (5): 3041–3066。doi :10.1287/mnsc.2020.3674。
- バコス、ヤニス、マロッタ・ワーグラー、フロレンシア、トロッセン、デイビッド・R. (2014)。「細かい文字を読む人はいるか? 標準契約書に対する消費者の関心」法学ジャーナル。43 ( 1): 1–35。doi :10.1086/674424。
- Ballhausen, Miriam (2022)。「著作権の執行」。オープンソースの法律、ポリシー、実践。オックスフォード大学出版局。pp. 126–140。ISBN 978-0-19-886234-5。
- ベン・シャハール、オムリ、シュナイダー、カール・E. (2014)。「知りたい以上のこと：義務的開示の失敗」プリンストン大学出版局。ISBN 978-0-691-16170-9。
- Bernelin, Margo ( 2020 ). 「オープン/フリーライセンスの互換性：法的な混乱」。国際法情報技術ジャーナル。28 (2): 93–111。doi :10.1093/ijlit/eaaa010。
- ボイル、ジェームズ（2003年）。「第二次囲い込み運動とパブリックドメインの構築」。法律と現代問題。66（1）：33-74。ISSN 0023-9186 。
- バトラー、サイモン。ガマリエルソン、ジョナス。ランデル、ビョルン。ブラックス、クリストファー。マットソン、アンダース。グスタフソン、トーマス。ファイスト、ジョナス。クヴァルンストロム、ベングト。レンロート、エリック (2022)。 「ソフトウェア集約型ビジネスにおけるオープンソース コンポーネントの導入に関する考慮事項と課題」。システムとソフトウェアのジャーナル。186 . Elsevier BV: 111152. doi :10.1016/j.jss.2021.111152. ISSN 0164-1212。
- カーペンター、オーウェン（2023）。「EULA、それとも賛辞？エンドユーザーライセンス契約と近未来のサイボーグの計算」。ヘルスマトリックス：法医学ジャーナル。33 ：467-498。
- Clohessy, Trevor、Acton, Thomas、Morgan, Lorraine (2020)。「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 。
- Davila, Jacinto (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。
- Morin, Andrew; Urban, Jennifer; Sliz, Piotr (2012). 「科学者プログラマーのためのソフトウェアライセンスのクイックガイド」. PLOS Computational Biology . 8 (7): e1002598. Bibcode :2012PLSCB...8E2598M. doi : 10.1371/journal.pcbi.1002598 . ISSN 1553-7358. PMID 22844236. この記事には、CC BY 4.0 ライセンスに基づいて利用可能なテキストが組み込まれています。
- Ombredanne, Philippe (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 。
- O'Regan, Gerard (2022).ソフトウェアエンジニアリングの簡潔ガイド: 基礎から応用方法まで. Springer Nature. ISBN 978-3-031-07816-3。
- Qazi, Faiza; Kwak, Daehan; Khan, Fiaz Gul; Ali, Farman; Khan, Sami Ullah (2024). 「クラウドコンピューティングにおけるサービスレベル契約: 分類、展望、課題」。モノのインターネット。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 日)。「オープンソースにおける著作権、契約、ライセンス」。オープンソースの法律、ポリシー、実践。オックスフォード大学出版局。71～112 ページ。doi :10.1093/oso/ 9780198862345.003.0003。ISBN 978-0-19-886234-5。
- St. Laurent, Andrew M. (2004)。オープンソースとフリーソフトウェアライセンスの理解。O'Reilly Media。ISBN 978-0596005818。
- テラサキ、マイケル (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 ). 「オープンソースソフトウェアとの競争がプロプライエタリソフトウェアに与える影響」。生産および運用管理。31 (2): 731–742。doi :10.1111/poms.13575。
さらに読む
- Classen, H. Ward (2022)。ソフトウェアライセンスとクラウドコンピューティングの実践ガイド。アメリカ法曹協会。ISBN 978-1-64105-750-9。
外部リンク
WikibooksにはFOSSライセンスに関する本があります。