誰?

• HN: 博多市 (hakatashi)
• GitHubで300以上のリポジトリを
  オープンソースライセンスで
  公開しています
• 法律関連について
  • 2024年に資格「法学検定
    スタンダード (法学部3年次程度)」
    を取得しました
  • とはいえ、素人同然
  • 米国法は完全に分野外
  • 内容は綿密に調査し、
    万全を期していますが
    不正確な内容もあるかもしれません

このスライドについて

• 私 (@hakatashi) がこのスライドに関して有する一切の権利は
  CC0の条件のもとで放棄します
• 原則として日本法、そして一部では米国法での話を前提として
  講義を行います
• ソフトウェアライセンスが現在の形になるまでに起こった
  ​紆余曲折ある長い長い歴史に関しては、原則として触れません
  • 「今」ソフトウェアライセンスを使う上で必要な知識を
    まとめた講義になります。
• わからない部分があったらいつでも止めて質問してください!
  • 早口になりがち。申し訳ないです

用語について

このスライドで扱う「ある程度自由に使えるソフトウェア」には、

1. オープンソースソフトウェア (OSS)
2. ソースアベイラブルソフトウェア
3. フリーソフトウェア

の3種類があります。

特に2.はOSSの定義に合致しませんが、
長いので、このスライドではこれらを総称して
「OSSなど」と呼ぶことにします。

もくじ

1. なぜライセンスを知っておく必要がある？
2. ライセンスと著作権の関係
3. 著作権などの知的財産権について
4. ソフトウェアライセンスの基本
5. オープンソースソフトウェア (OSS)
6. ソースがオープンだがオープンソースでないソフトウェア
7. フリーソフトウェアとコピーレフトなライセンス達
8. ジョークライセンス
9. ソフトウェア以外のライセンス
10. OSSなどに対するコントリビューション
11. ソフトウェアライセンスの選び方
12. まとめ

なぜライセンスを
知っておく必要がある？

スマホアプリにはほぼ必ず⋯⋯

ライセンス関連の不祥事

MicrosoftがうっかりMITライセンスプロジェクトをMicrosoft名義に書き換えて謝罪 - GIGAZINE https://gigazine.net/news/20211227-microsoft-forked-mit-licensed-copyright/

フリーソフトウェアライセンスの「GPL」に違反したとして1億円超の損害賠償を大手通信事業者のOrangeが命じられる - GIGAZINE https://gigazine.net/news/20240305-french-court-violation-gpl-orange/

OSSなどとは
無縁でいられない

• Linux / OpenBSD
• ほとんどのプログラミング言語
  • C言語 (GCC / clang)
  • Python
  • Ruby
  • PHP
  • JavaScirpt (Node.js)
• Webプログラミング
  • React
  • Vue.js
• データベース
  • MySQL
  • MongoDB

• Webブラウザ
  • Chromium
  • Firefox
  • Brave
• 機械学習
  • TensorFlow
  • Torch
  • Transformers
• マルチメディア
  • OBS Studio
  • FFmpeg
  • VLC Media Player

OSSなどを活用するために

• 使いようでトラブルはあるとはいえ、
  基本的にOSSなどは「みんなに使ってほしい」から
  公開されているソフトウェア
• トラブル防止の観点だけでなく、
  正しくOSSなどを活用するのも大事
• 「何をしてはいけないか」だけでなく
  「何をしていいか」を知ることで
  活用の幅は広がっていく

ライセンスと著作権の
関係

「ソフトウェアライセンス」とは?

2つの意味で用いられることがある

* なお[姉崎]では、「ソフトウェアライセンス」というと左側が一般にイメージされるため
右側を「ソフトウェアライセンスの一種」と呼ぶのは誤解を呼ぶ表現としてやめるよう推奨している。

ライセンスと著作権は
切っても切れない関係にある

例えば次のようなケース

• あなたはプログラマー
• 自作のOS「TSG OS」を開発するため、
  Linuxカーネルのソースコードの一部をコピーして利用した
• 「TSG OS」を搭載したゲーム機を開発し販売したが、
  ソースコードの開示などは行わなかった

LinuxカーネルはGPLでライセンスされており、
GPLは利用者の求めに応じてソースコードを開示することを
義務付けているためこれはGPLライセンス違反となる

成立していない契約に
法的拘束力はない

*黙示の同意や定型約款の合意が認められる可能性もあるため、より正確にはケースバイケースです。[2]
米国法においてもブラウズラップ契約の有効性を認めた判例が存在します。[5]

味の素株式会社 ～Eat Well, Live Well. ～AJINOMOTO
https://www.ajinomoto.co.jp/

よく見る光景だけど⋯⋯

ウェブサイト側が一方的に告知しているものは
「契約」とみなされない (可能性が高い) [1][2]
ため、規約の内容に従わせる拘束力はない*

公開にあたってこのページは削除されました

このような背景からGPLは自身を
「契約に基づくライセンス」ではなく
「著作権に基づくライセンス」と
位置づけている[1][2]*

*なお、日本においてはOSSなどのライセンスも契約として成立する可能性が高いという解釈が一般的です。
米国法においては契約として成立するかどうかは不透明です。→Appendix A

また、その他多くのソフトウェアライセンスも
著作権を軸足に考えるとわかりやすい場合が多い。

「著作権に基づくライセンス」とは何か

GPLは、一言でいうと⋯⋯
「GPLライセンスのコードを改変して利用した場合、
改変した部分もGPLライセンスで公開しないといけない」
強い制約を持つソフトウェアライセンス

著作権者
(プログラムの作者)

ユーザー

顧客

利用条件付きの
利用許諾表示 (GPL)

利用条件に則った
コードの利用

著作権者が利用を許可しているため
著作権侵害にならない

「著作権に基づくライセンス」とは何か

GPLは、一言でいうと⋯⋯
「GPLライセンスのコードを改変して利用した場合、
改変した部分もGPLライセンスで公開しないといけない」
強い制約を持つソフトウェアライセンス

著作権者
(プログラムの作者)

ユーザー

顧客

利用条件付きの
利用許諾表示 (GPL)

利用条件を無視した
コードの利用

著作権者の利用許諾条件を満たしていないため
利用許諾は無効となり、著作権侵害となる

著作権に基づいたライセンス

このような仕組みにより、
プログラムの作者はユーザーと契約を取り交わしていないにも関わらず
特定の条件を守ることをユーザーに強制することができる。

一方、プログラムの作者がユーザーと契約を取り交わした場合と比べると
守らせることができる内容の範囲には制限がある。[1]

質問1「どこからがGPL違反か」

「GPLのコードを他のプログラムで利用したら
ソースコードを公開しなければならない」と言われていますが、
for文の書き方とか、変数の命名の仕方とか、コピーしようとせずとも
コードの一部が自然と似通ってしまうことはあると思います。

このような場合にソースコードを公開する義務はないと思うのですが
であれば、どこからがGPL違反となるラインとなるのでしょうか？

コードの中の2、3行がたまたまGPLのコードと完全一致してしまったら
ソースコード全体を公開しないといけないですか？

A. 「著作権違反とみなされる利用かどうか」が
ライセンスの制約に従わなければいけないライン

• 「たまたま」で一致するような内容は
  「創作的」とはみなされないため、著作権も発生していない*
• そもそも著作権がないものはライセンスで保護できない

* 実際にはケースバイケースです

質問1「どこからがGPL違反か」

• よく誤解されるが、「GPLでライセンスされているコード」は
  「何もライセンスがないコード」よりも
  利用する際に気を付けることが少ないと考えて良い
• ​「一般に他人の著作物を扱う時に気を付けること」にさえ
  気を付けていれば、GPLの制約条件は一切意味をなさない
• 例えば、以下のようなケースは一般の著作物であっても
  問題にならないため、GPLでも問題にならないケース
  1. GPLのコードを改変し、親しい友人 (著作権法30条1項で
     認められる範囲に限る) にシェアした
  2. デスクトップ画面を生放送するライブ配信において、
     ​エディタがちらっと開いてGPLのコードが映ってしまった
     (著作権法30条の2で認められる範囲に限る)
  3. GPLでライセンスされたエディタ (Emacsなど) を用いて
     商用プログラムを書いた[宮原, No938]
     (著作権法47条の3で認められる範囲に限る)

質問2「GPL違反を見つけたらどうする?」

GPL違反を見つけたらどうしたらいいですか？

つまり、誰かのGPLのコードが無断で使われていて
私がソースコードを要求しても無視されたり頑なに公開しなかった場合、
不利益を被ったとして警察や裁判所に訴えることができますか？

A. できません。

• 著作権侵害事件という観点で見た場合*、あなたは
  被害者でも加害者でもない第三者であり、原告適格を欠く
• このような著作権侵害の訴えを起こすことができるのは
  当事者である著作権者のみ [1] なので
  最終的にGPLを行使するためには著作権者に頼む必要がある
• まずはそのコードを書いた人にGPL違反について連絡しよう
• より詳しい手続きに関しては
  https://www.gnu.org/licenses/gpl-violation.html を参照

*契約違反と見た場合も

著作権などの
知的財産権について

文化庁著作権課「令和6年度著作権テキスト」
https://www.bunka.go.jp/seisaku/chosakuken/textbook/pdf/94089201_01.pdf

プログラムは (多くの場合) 著作物

文化庁著作権課「令和6年度著作権テキスト」
https://www.bunka.go.jp/seisaku/chosakuken/textbook/pdf/94089201_01.pdf

プログラムは (多くの場合) 著作物

文化庁著作権課「令和6年度著作権テキスト」
https://www.bunka.go.jp/seisaku/chosakuken/textbook/pdf/94089201_01.pdf

著作権の発生

ベルヌ条約の加盟国 (日本やアメリカなど) では
著作権は著作物を作った時点で自動的に発生する

• ©マークを書かなくても
• ソフトウェアライセンスを用意して
  著作者を表示しなくても
• どこにもアップロードしなくても

プログラムを手元で作成した時点で著作権がある

著作権の細分化

文化庁著作権課「令和6年度著作権テキスト」
https://www.bunka.go.jp/seisaku/chosakuken/textbook/pdf/94089201_01.pdf

複製権

• コンピューターソフトウェアの文脈では
  かなり広い行為を表す用語
• インターネットからソフトウェアを
  ダウンロードしたらその時点で複製とみなされる
• つまり、例えばGitHubで見つけた良さげなリポジトリを
  手元のPCにcloneしてきたら、その時点で他人の権利を
  侵している、ということ

ただし、ソフトウェアの複製権は制限が多く、
以下のような (以下に限らない) シチュエーシェンでは利用が認められている

1. 私的使用のための複製
2. プログラムの著作物の複製物の所有者による複製等

著作物の私的利用

以下の条件を満たす場合、私的利用とみなされ
著作物を複製することができる (著作権法30条)

1. 個人的に又は家庭内など、限られた範囲内での使用を目的とすること
   • 目安では4～5人程度のごく親密な少人数まで [1]
2. 使用する本人が複製すること
3. 以下の利用に該当しないこと
   • 誰でも使える状態で設置してあるダビング機など（当分の間、コンビニ等のコピー機など「文献複写」のみに用いるものは除かれています）を用いて複製すること
   • コピーガードを解除して（又は解除されていることを知りつつ）複製すること
   • 著作権を侵害したインターネット配信と知りつつ、音楽や映像をダウンロードすること
   • 著作権を侵害したインターネット配信と知りつつ、音楽や映像以外の著作物（漫画、書籍、論文、コンピュータ・プログラム等）をダウンロードすること（軽微なもののダウンロード等、一定の利用は除かれています）

プログラムの所有者による複製等

以下の条件を満たす場合、プログラムを複製することができる (著作権法第47条の3)

1. プログラムの所有者 (著作権者ではない) が行うこと
2. 所有者がプログラムを実行するために必要な限度内であること
   （複数台のパソコンで使うための複製は対象外）
3. 海賊版と知って入手したものでないこと

公衆送信権

公衆送信=放送、有線放送、自動公衆送信など

ソフトウェアで特に重要なのは「自動公衆送信」

文化庁著作権課「令和6年度著作権テキスト」
https://www.bunka.go.jp/seisaku/chosakuken/textbook/pdf/94089201_01.pdf

訴訟に際して実際にファイルのダウンロードが行われたことを立証するのは難しい

そのため、著作権法においてはサーバーにファイルを置くだけの
「送信可能化」も「自動公衆送信」に含めている

公衆送信権

公衆送信に「私的利用」は認められていない

そのため、私的な目的でもインターネットで
他人のプログラムを再配布するのは原則として違法

一見、「やらないように気をつけよう」で済みそうだが⋯⋯

著作権はどこまでを保護するか

その他、著作権を侵害しないソフトウェアの利用は多く存在する

• 著作権が発生しないものたち
  • アイデアの類に分類されるもの
    • アルゴリズム
    • 変数の命名規則など
    • ただし、特許によって保護されている場合がある
  • ​プログラミング言語
• 著作権が発生するものたち
  • APIの宣言コード (米国)
• また、著作権が存在しても著作権法で利用が認められる場合がある
  • 引用・私的複製・キャッシュやバックアップのための複製
  • フェアユース (米国)
    • これらの利用形態で利用する場合も同様に
      ライセンスの制約が意味をなさない [1]

著作者人格権

著作権が財産権の一種であり譲渡や放棄ができる*のに対して、
譲渡や放棄といった概念の存在しない
著作者にまつろう人格権のことを著作者人格権という

なお、米国法では著作者に対する人格権を原則認めていない

* 放棄に関しては著作権法に定めはないが通説である [1]
*2 ほとんどすべてのソフトウェアライセンスは改変を許可しているのでこれに該当する
*3 同様に著作者人格権不行使契約も無効とする説もある [2]

また、日本などの国では譲渡できないことから、著作者人格権の不行使を
一方的に宣言するようなソフトウェアライセンス*2には
法的効力がないと指摘する向きもあり[1]、課題として残されている*3

著作者の人格権とは、例えば著作物への氏名表示権・公表権・
同一性保持権などが該当する。

特にインターネット上での著作物の利用において、どこからどこまでが
著作者人格権の侵害に当たるかの判例は少なく、近年の司法判断は揺れている[2]

特許権

著作権は発明を保護しない一方、発明を保護するための権利が特許権

登録主義を原則としており、認定されるには以下の要件を
すべて満たすか審査を受ける必要がある。

1. 産業上利用できる発明であること（産業上の利用可能性）
2. 新しいものであること（新規性）
3. 容易に考え出すことができないこと（進歩性）
4. 先に出願されていないこと（先願）
5. 公序良俗を害さないこと

ソフトウェアの発明が特許権で保護されうるかに関しては議論があるが、
特許庁の審査基準は、「ソフトウェアによる情報処理が、
ハードウェア資源を用いて具体的に実現されている」場合、
当該ソフトウェアは発明に該当すると述べている[1]。

特許権

一方、日本ではソフトウェアの特許の侵害訴訟で
原告側の主張が認められる割合は著しく低く、
「特許として登録できるが、それによる権利を
実際に行使することは難しい*」という
状況になっている。

とはいえ、一度特許を取得されてしまえば
訴訟リスクとして無視できないものに
なるのは間違いない。

侵害訴訟にみるソフトウェア特許 : 特許庁と裁判所の「連携プレイ」と裁判所の「単独プレイ」による保護 範囲の限定の現況
https://eprints.lib.hokudai.ac.jp/dspace/bitstream/2115/72117/1/51_05li.pdf

*もちろん一切保護されないという意味ではない。特許侵害を認めた判例としては2022年・2023年の「FC2対ドワンゴ訴訟」が記憶に新しい → Appendix C

特許権

このような背景から、多くのソフトウェアライセンスでは
(著作権に加えて) 特許に関する権利を放棄する旨の条項を盛り込んでいる。

が、著作者人格権と同様に一方的な宣言行為が
法的効力を持つかに関しては判例がなく不明である[1]。

まあ、そもそも特許権の不行使を宣言している人間が当該ソフトウェアの
特許を取得するとは思えないため、実用上は問題にならない。

オープンソースのコミュニティでは特にソフトウェアの発明に対して
特許を適用することに反発しており、例えばGPLv3のライセンス文書では
「およそ国家は、特許が汎用コンピュータにおけるソフトウェアの開発と
利用を制限することを認めるべきではありません。」*と述べられている。

*翻訳は一般社団法人オープンソース・グループ・ジャパン「オープンソースライセンスの日本語参考訳 > GNU General Public License version 3」(CC BY 4.0) より

ソフトウェアライセンスの基本

ライセンスの基本構造

右に示したのは特にシンプルな
ライセンスであるMITライセンスの全文

多くのソフトウェアライセンスには
以下の3つの要素が条項に含まれている

1. 許諾表示
2. 許諾の条件
3. 免責事項

The MIT License
Copyright (c) <year> <copyright holders>

本ソフトウェアおよび関連する文書のファイル（以下「ソフトウェア」）の複製を取得した全ての人物に対し、以下の条件に従うことを前提に、ソフトウェアを無制限に扱うことを無償で許可します。これには、ソフトウェアの複製を使用、複製、改変、結合、公開、頒布、再許諾、および/または販売する権利、およびソフトウェアを提供する人物に同様の行為を許可する権利が含まれますが、これらに限定されません。

上記の著作権表示および本許諾表示を、ソフトウェアの全ての複製または実質的な部分に記載するものとします。

ソフトウェアは「現状有姿」で提供され、商品性、特定目的への適合性、および権利の非侵害性に関する保証を含むがこれらに限定されず、明示的であるか黙示的であるかを問わず、いかなる種類の保証も行われません。著作者または著作権者は、契約、不法行為、またはその他の行為であるかを問わず、ソフトウェアまたはソフトウェアの使用もしくはその他に取り扱いに起因または関連して生じるいかなる請求、損害賠償、その他の責任について、一切の責任を負いません。

翻訳は一般社団法人オープンソース・グループ・ジャパン「オープンソースライセンスの日本語参考訳 > MIT License」より

①

②

③

許諾表示

ユーザーがこのソフトウェアを
どうすることができるかを示したもの

多くの場合、実質的に著作権を放棄した
場合と同様に「何をしてもいい」旨が
書かれている。

The MIT License
Copyright (c) <year> <copyright holders>

本ソフトウェアおよび関連する文書のファイル（以下「ソフトウェア」）の複製を取得した全ての人物に対し、以下の条件に従うことを前提に、ソフトウェアを無制限に扱うことを無償で許可します。これには、ソフトウェアの複製を使用、複製、改変、結合、公開、頒布、再許諾、および/または販売する権利、およびソフトウェアを提供する人物に同様の行為を許可する権利が含まれますが、これらに限定されません。

上記の著作権表示および本許諾表示を、ソフトウェアの全ての複製または実質的な部分に記載するものとします。

ソフトウェアは「現状有姿」で提供され、商品性、特定目的への適合性、および権利の非侵害性に関する保証を含むがこれらに限定されず、明示的であるか黙示的であるかを問わず、いかなる種類の保証も行われません。著作者または著作権者は、契約、不法行為、またはその他の行為であるかを問わず、ソフトウェアまたはソフトウェアの使用もしくはその他に取り扱いに起因または関連して生じるいかなる請求、損害賠償、その他の責任について、一切の責任を負いません。

翻訳は一般社団法人オープンソース・グループ・ジャパン「オープンソースライセンスの日本語参考訳 > MIT License」より

①

許諾条件

ユーザーがソフトウェアを利用する際
「何に従わなければいけないか」を
記載したもの。

ソフトウェアを使う上ではここが
一番重要。

The MIT License
Copyright (c) <year> <copyright holders>

本ソフトウェアおよび関連する文書のファイル（以下「ソフトウェア」）の複製を取得した全ての人物に対し、以下の条件に従うことを前提に、ソフトウェアを無制限に扱うことを無償で許可します。これには、ソフトウェアの複製を使用、複製、改変、結合、公開、頒布、再許諾、および/または販売する権利、およびソフトウェアを提供する人物に同様の行為を許可する権利が含まれますが、これらに限定されません。

上記の著作権表示および本許諾表示を、ソフトウェアの全ての複製または実質的な部分に記載するものとします。

ソフトウェアは「現状有姿」で提供され、商品性、特定目的への適合性、および権利の非侵害性に関する保証を含むがこれらに限定されず、明示的であるか黙示的であるかを問わず、いかなる種類の保証も行われません。著作者または著作権者は、契約、不法行為、またはその他の行為であるかを問わず、ソフトウェアまたはソフトウェアの使用もしくはその他に取り扱いに起因または関連して生じるいかなる請求、損害賠償、その他の責任について、一切の責任を負いません。

翻訳は一般社団法人オープンソース・グループ・ジャパン「オープンソースライセンスの日本語参考訳 > MIT License」より

②

免責事項

ソフトウェアを提供する代わりに、
それを利用したことによる責任は
一切負わないことを宣言する記述。

ソフトウェアが沢山の人に使われるのは
よいが、それによって何かしら
開発者側に不利益が返ってこないことを
保証するための文章。

The MIT License
Copyright (c) <year> <copyright holders>

本ソフトウェアおよび関連する文書のファイル（以下「ソフトウェア」）の複製を取得した全ての人物に対し、以下の条件に従うことを前提に、ソフトウェアを無制限に扱うことを無償で許可します。これには、ソフトウェアの複製を使用、複製、改変、結合、公開、頒布、再許諾、および/または販売する権利、およびソフトウェアを提供する人物に同様の行為を許可する権利が含まれますが、これらに限定されません。

上記の著作権表示および本許諾表示を、ソフトウェアの全ての複製または実質的な部分に記載するものとします。

ソフトウェアは「現状有姿」で提供され、商品性、特定目的への適合性、および権利の非侵害性に関する保証を含むがこれらに限定されず、明示的であるか黙示的であるかを問わず、いかなる種類の保証も行われません。著作者または著作権者は、契約、不法行為、またはその他の行為であるかを問わず、ソフトウェアまたはソフトウェアの使用もしくはその他に取り扱いに起因または関連して生じるいかなる請求、損害賠償、その他の責任について、一切の責任を負いません。

翻訳は一般社団法人オープンソース・グループ・ジャパン「オープンソースライセンスの日本語参考訳 > MIT License」(CC BY 4.0) より

③

オープンソースソフトウェア
(OSS)

よくある誤解

「オープンソースソフトウェア」は
単に「ソースコードが公開されているソフトウェア」という意味ではない

「オープンソース」は1998年にパロアルトで行われた会議で考案された
用語で、後述する「フリーソフトウェア」を代替するためのもの

現在では、単にソースコードが公開されているだけでなく
Open Source Initiative が策定した「オープンソースの定義」全てに
則ったソフトウェアのみを指す。

Open Source Definition (OSD)

1. 再頒布が自由であること
2. ソースコードが公開されていること
3. 派生ソフトウェアを同一のライセンスで頒布することを許可すること
4. パッチ形式の配布の際のライセンス変更の許可
5. 個人やグループに対する差別の禁止
6. 利用する分野に対する差別の禁止
7. ライセンスの分配が公平であること、および追加的ライセンスの禁止
8. 特定製品でのみ有効なライセンスの禁止
9. 他のソフトウェアを制限するライセンスの禁止
10. ライセンスは技術中立的でなければならない

Open Source Initiative は、これらの定義に則ったソフトウェアライセンスを
「オープンソースライセンス」として適宜承認している。

つまり、「ソースがオープンであること」は「オープンソース」の
必要条件であって、必要十分条件ではない。

MIT License

GitHubで公開されているリポジトリの44%が採用している[1]、
名実ともに最もポピュラーなOSSライセンス

先ほど示したとおり、法律や契約の専門家でなくても理解できる
シンプルでわかりやすい条項が特徴

ただし、特許については一切触れられておらず、
使用する際に特許関係のリスクについて考える必要がある。

許諾条件

• 著作権表示 (Copyright (c) <year> <copyright holders>) と
  MITライセンスの表示を記載すること

Apache License 2.0

MIT License はわかりやすい一方、法的文書の体裁をなしておらず
用語の細かい定義などで運用上の問題が発生する可能性がある。

Apache License 2.0 は MIT License とほぼ同じ頒布条件だが
より長く厳密な文章となっており、トラブルを防いでいる。

また、特許権の放棄に関する明文規定があるため、その点でも安心できる。

GoogleがリリースするOSSは Apache License 2.0 が標準となっている[1]。

許諾条件

• 再配布時にこのライセンスのコピーも渡すこと
• 変更を加えたファイルについては、
  変更内容がよくわかるような告知を入れること
• 「NOTICE」ファイルが含まれている場合は
  再配布時にこれを含めること
• その他細かい条件

2条項BSDライセンス

BSD License は歴史上何度も改訂を繰り返しており、
そのたびに条項の数が減っていることから、古いものから
「4条項」「3条項」「2条項」というように呼ばれる。

ライセンスの内容がシンプルなことを含め MIT License とほぼ同等。

BSD License は名前の通りBSDの配布の際に適用されたライセンスで、
FreeBSDやNetBSDは現在もこの2条項BSDライセンスで配布されている。

特許に関する明文規定はない。

許諾条件

• ソースコードを再頒布する場合、このライセンスを含めること。

• バイナリ形式で再頒布する場合、頒布物に付属の
  ドキュメント等の資料に、このライセンスを含めること。

ISC License

MIT License よりもさらに条文が短い。

機能的にも MIT License とほぼ同等。

OpenBSDは現在もこのライセンスを採用しているほか、
npmで新規プロジェクトを作成するとデフォルトでこのライセンスになる。
(個人的には正気か?と思っている)

特許に関する明文規定はない。

許諾条件

• このライセンスが全ての複製物に記載されていること

The Unlicense

ここまでに紹介したライセンスは全て著作者表示や
ライセンス表示を記載しなければならないことを条件としていた。

そのような制約を利用者に課すことに抵抗感を覚える人のために、
著作権を完全に放棄して一切の利用条件をなくしたOSSライセンス。

なお、著作権放棄の手段としては後述するCC0が利用されることもある。

特許に関する規定はない。

許諾条件

• なし

ソースがオープンだが
オープンソースでないソフトウェア

ソースアベイラブルソフトウェア

先ほど述べた通り、オープンソースであるためには、
ソースがオープンな (公開されている) だけでなく、
様々な基準に適合する必要がある。

そのため、ソースがオープンだがオープンソースでないという
ソフトウェアの分類が存在し、これらを含めた総称として
ソースアベイラブルソフトウェアなどという呼称がある[1]

近年、さまざまな社会的背景によってここに分類されるソフトウェアが
増えており、利用する際には注意が必要。

ライセンスがないソフトウェア

ソースコードが公開されているが、明示的にライセンスを与えていないもの

例えば⋯⋯

• ライセンスに関する記述のないGitHubリポジトリ
• 個人サイトで配布されている「フリーウェア」
• どこかのウェブサイトで使われていたJavaScriptコード
• Qiita・Zenn・teratailに投稿されたソースコード
• AtCoderに提出された他人のソースコード

これらのソースコードは一般の著作物と同じく
著作権の及ぶものなので、著作者に無断で使うことは出来ない。

オープンソースの定義に適合しない
独自の厳しい条項を持つライセンス

オープンソースが普及する前に生まれた、使用が推奨されないライセンスも
ここに分類されるが、近年ではあえてオープンソースでないライセンスを
採用するような例も増えてきている。

背景にはクラウドベンダとオープンソースコミュニティの対立があり、
かなり根深い問題となっている。興味がある人は
「クラウドベンダのフリーライド問題」などで検索するとよい。

これらのライセンスは傾向として商用利用を制限するものが多く、
個人で使う分にはなんら問題ないが、会社で使う場合は (社員個人として使う場合も)
使うのを避けておく、もしくは法務にあらかじめ相談しなければならない。

Server Side Public License (SSPL)

2018年にMongo社が発表したライセンス。

MongoDBおよびRedisなどが採用している。

GPLv3の一部を改変する形で作成されている。

この追加条項にある「サービスとして (as a service)」というのは
Mongo社のFAQ[1]では、例えばクラウドベンダがMongoDBをDBaaS
として提供するような場合に限る、としているが、法的根拠は乏しい[2]。

条項の解釈によっては、MongoDBを内部的にDBとして使用するだけでも
この条項が及ぶことになり、トラブルを避けたいなら使わないほうがいい[2]。

許諾条件

• GPLの許諾条件 (後述)

• 本プログラムをサービスとして提供する場合、
  サービスを提供するのに必要な環境全てのソースコードを公開すること

Business Source License (BSL/BUSL)

もとはMariaDBの一部の製品のみに採用されていたライセンス。

現在ではHashiCorpの製品 (Vagrant, Terraform, Packer...) や
CockroachDBなどで採用されている。

本番環境での利用のみを禁止したシンプルなライセンス。

HashiCorpで採用されているバージョンはSSPLと比較して意味が明確、かつ
禁止する使い方をHashiCorp製品に競合する商用利用に限定しており、
トラブルになる可能性は低いと考えられる。

許諾条件

• 本番環境での利用の禁止
  • ただしHashiCorpではこれを修正して
    • HashiCorpの製品に競合する商用利用 (本番環境での利用) の禁止
  • としている

フリーソフトウェアと
コピーレフトなライセンス達

よくある誤解2

「フリーソフトウェア」とは、無料のソフトウェアのことではない

ここでのfreeは「自由」を意味する単語のため、和訳する際は
「自由ソフトウェア」という訳語も頻繁に用いられる。

日本では「フリーソフト」や「フリーウェア」と略すと
無料のソフトウェアのことを指しがちなため、略さないことが推奨される。

GNUプロジェクトを創始したリチャード・ストールマンが提唱した概念で
次のページに示す4つの自由を有するものを指す。

おおよそ「オープンソース」の定義と同じと考えてよい[1]。

フリーソフトウェアの4つの自由

• どんな目的に対しても、プログラムを
  望むままに実行する自由 (第零の自由)
• プログラムがどのように動作しているか研究し、
  必要に応じて改造する自由 (第一の自由)
• ほかの人を助けられるよう、コピーを再配布する自由 (第二の自由)
• 改変した版を他に配布する自由 (第三の自由)

コピーレフト

フリーソフトウェア運動を展開するフリーソフトウェア財団 (FSF) は、
同時にコピーレフトという思想を広める活動を行っている。

これはGPLなどのライセンスを用いてソフトウェアをリリースすることで
そのソフトウェアが今現在のみならず将来的にも
フリーソフトウェアであることを保証するという内容の思想である。

コピーレフトでないライセンスの場合

著作権者
(プログラムの作者)

ユーザー

ユーザー2

MITライセンス下での
利用許諾

改変したソースコードを
プロプライエタリな
ライセンスで配布

ライセンス表示を行っていれば再配布は許可されるため
フリーソフトウェアではなくなる可能性がある

配布プログラムをもとに
独自に改良

コピーレフトなライセンスの場合

著作権者
(プログラムの作者)

ユーザー

ユーザー2

GPL下での
利用許諾

改変内容を含めた
全体をGPLで公開

改変内容をGPLで公開しなければ著作権違反となるため
改変プログラムもソースコードが公開されることを保証できる

→誰の手に渡ってもフリーソフトウェアであり続けることができる

配布プログラムをもとに
独自に改良

どこまでが「改変」か?

GPLv3では以下の通り定義されている。

ある作品の「改変」（modify）とは、その作品の全体ないし一部を、『コピーライト』の許可を必要とするようなやり方で複製ないし翻案することを意味する。ただし、完全に同一なコピーを作成する場合は除く。*

つまり、完全に同一な複製以外の複製行為はすべて「改変」にあたる。

*翻訳は一般社団法人オープンソース・グループ・ジャパン「オープンソースライセンスの日本語参考訳 > GNU General Public License version 3」(CC BY 4.0) より

GPLでライセンスされたライブラリの場合

ライブラリA

プログラムC

ユーザー2

GPL下での
利用許諾

全体をGPLで公開
しなければならない

ライブラリB

MITライセンス下での
利用許諾

ライブラリAと
ライブラリBを用いた
1つのプログラムCを配布

コピーレフトの継承性は
ライブラリとしての利用にも及ぶ

このようにGPLは、著作権を盾にしてGPLの利用を強制する力を持ち、
それはライブラリとして利用する際も同様である。

近年では1つのプログラムを作成するのに百や千を下らないライブラリを
使うことも多く、これらのどれか1つでもGPLでライセンスされていれば
全体をGPLで公開しなければいけない、という厳しい許諾条件を持つ。

このようなGPLというライセンスの持つ強い下位継承性を、
(GPLの支持者からすれば侮辱的な名称だが) GPL汚染と呼ぶことがある。

また、GPLで再ライセンスすることを許可しないライセンス
(先ほど挙げたSSPLやBSLなど) のライブラリと混ぜて使うことはできない。

結合したプログラムとみなされない場合

著作権者

プログラムA

ユーザー

GPL下での
利用許諾

プログラムBは、
MITなど別のライセンスで
公開できる

プログラムAと
協調動作する
別のプログラムB

全体を1つのバンドル
(集積物) として配布

どこまでが「結合」か?

GPLの原文では「結合」の定義について細かく触れておらず、
FSFも「最終的には裁判官が決めること[1]」と匙を投げている。

一応、ガイドラインとして、

メイン・プログラムがforkやexecでプラグインを呼び出し、複雑なデータ構造を共有することで密接な通信をしたり、複雑なデータ構造をやりとりする場合、単一の結合されたプログラムとなるでしょう。[2]

などの基準が設けられているが、ライセンスにはこのようなことは
一切述べられていない。

また、このガイドラインに則れば、「複雑なデータ構造をやりとりする」
データベースアプリケーションとそれを利用するソフトウェアの関係も
1つの結合されたプログラムとみなされる可能性がある。

GNU General Public License (GPL)

「コピーレフト」を推進するためにGNUが実装したライセンス。

LinuxやGNUプロジェクトのツール (GCC, ls, cp, Emacs, R言語など...) で採用される。

バージョンが複数あり、現在の最新バージョンはGPLv3。

許諾条件による制約を受けるのはあくまで頒布を行う場合であり、
サーバーのみで動かす場合や修正のみを行う場合は適用されない。

許諾条件

• 「改変」したプログラムを頒布する場合、
  • プログラム全体を同じGPLでライセンスすること
  • 改変したことを明確に記すこと
  • UIがある場合、そこに著作権表記を行うこと
• バイナリ形式などでプログラムを頒布する場合、
  それを受け取った人にソースコードも頒布すること
• その他、細かい条件

GNU Lesser General Public License (LGPL)

GPLを拡張し、ライブラリ向けに頒布条件をゆるく設定したもの。

動的リンクして使う場合にライセンス継承の制約を解除するようになっている。

もともとはglibcなどと、フリーでないソフトウェアを動的リンクすることを
許可することで広く使われることを目指したものだが、
現在はFSFとしては利用を推奨していない[1]。

glibcなど、GNUプロジェクトのライブラリの一部で採用されている。

許諾条件

• GPLの許諾条件、ただし:
  • このプログラムを動的リンクする場合は、以下の条件で頒布できる
    • ライセンス表示を行うこと
    • このプログラムのソースコードを頒布すること
    • UIを持つ場合、そこに著作権告知を表示すること
    • その他、細かい条件

GNU Affero General Public License (AGPL)

GPLを拡張し、サーバーで動作するだけのプログラムにも同様に
ソースコードを開示しライセンスを適用することを義務付ける制約を加えたもの。

先ほど述べた通り、サーバーでプログラムを実行するだけなら
プログラムの頒布には当たらず、GPLの制約は適用されない。

これが問題視される一部のサーバー向けプログラムに向けて
適用されることを目指したライセンスだが⋯⋯話はそう単純ではない → 次ページ

許諾条件

• GPLの許諾条件、ただし:
  • 「改変」したプログラムをサーバーで動かす場合、
    それとネットワーク越しにやり取りするユーザーに対して
    そのソースコードにアクセスする手段を提供しなければならない
  • (上記が適用される場合、第5項の規定からプログラム全体が
    AGPLでライセンスされることが即座に従う)

AGPLの問題点

AGPLは、GPLの第13項を以下に変更したライセンスである (一部抜粋・強調引用者)

本許諾書に含まれる他の条件に関わらず、あなたが『プログラム』を改変した場合、改変したバージョンは、そのバージョンとリモートでコンピュータネットワークを介し対話的にやりとりする (中略) すべてのユーザに対して、ネットワークサーバから、あなたのバージョンに『対応するソース』にアクセスする手段を、無償、かつソフトウェアのコピーを円滑に行う上で標準的、慣習的に用いられる方法で提供することにより、ユーザが『対応するソース』を受け取る機会を明示的に与えなければなければならない。*

*翻訳は一般社団法人オープンソース・グループ・ジャパン「オープンソースライセンスの日本語参考訳 > GNU Affero General Public License version 3」(CC BY 4.0) より

Googleは、この「すべてのユーザ」が指す範囲が不明確であることを指摘している[1]。

例えば社内のサーバーにAGPLのソフトウェアをインストールした場合、
その瞬間、サーバーにログインできる社員はすべてそのユーザーとみなされるのか、
それともより公にそのサービスを公開した際にはじめてユーザーが生まれるのか
この条項からは読み取ることができない。

AGPLの問題点

また、先ほど説明したとおり、「結合」の指す範囲が不明確であることから
どのような利用が「改変」にあたるのかも現在のところ明確ではない。

例えばMongoDBは一時期AGPLを採用していたが、MongoDBと通信する
アプリケーションは総体としてMongoDBを「改変」したことになるのか、
であればそのアプリケーションを公に提供する際にAGPLの制約は課されるのかなど
実務上でも問題になる可能性が高い点が多く指摘されている。

実際にこれらが訴訟リスクとして考慮されうるかは難しい論点だが、
例えばGoogleはこのような背景から、AGPLでライセンスされたソフトウェアを
社内で利用することを一律で禁止し、単にインストールすることを含め
積極的に禁じている[1]。

ジョークライセンス

Do What The Fuck You Want To Public License (WTFPL)

ジョークライセンスの一種で、条項は以下の一文のみ。

許諾条件

• なし

 0. You just DO WHAT THE FUCK YOU WANT TO.

わかりやすさはダントツで、採用実績も多いが、免責事項が含まれていない、
かつ法的文書として語句の明確さに欠けるなど、問題点も多い[1]。

なお、GoogleではかつてWTFPLの利用が禁止されていた[1]が、
現在では許可されている[2]。

THE BEER-WARE LICENSE

許諾条件

• いつか開発者に会ったときに、開発者にビールを奢ることができる

/*
 * ----------------------------------------------------------------------------
 * "THE BEER-WARE LICENSE" (Revision 42):
 * <phk@FreeBSD.ORG> wrote this file.  As long as you retain this notice you
 * can do whatever you want with this stuff. If we meet some day, and you think
 * this stuff is worth it, you can buy me a beer in return.   Poul-Henning Kamp
 * ----------------------------------------------------------------------------
 */

FreeBSDの開発者である Poul-Henning Kamp が
自身のプロダクトに適用しているジョークライセンス

ソフトウェア以外の
ライセンス

Creative Commons (CC)

著作権を部分的に放棄することを表示する際に使われるライセンス

ユーザーが「何をしなければならないか」「どんな制約があるか」によって
4つのマークが制定されている。

• BY: 著作権の告知などを表示しなければならない
• SA: 改変した著作物を同一のライセンスで提供しなければならない
• ND: 改変は許可されない
• NC: 営利目的の利用は許可されない

クリエイティブ・コモンズ・ライセンスとは | クリエイティブ・コモンズ・ジャパン
https://creativecommons.jp/licenses/

Creative Commons Zero (CC0)

ここまでの通りソフトウェアには「改変」や「翻案」などについて独自の
問題があるため、一般の著作物を対象とした Creative Commons よりも
OSSなどのために作られたライセンスのほうが推奨されている[1]。

例外として、一切の著作権を放棄する Creative Commons Zero は
ソフトウェアに対しても安全に適用できる[2]。

About CC Licenses - Creative Commons
https://creativecommons.org/share-your-work/cclicenses/

Creative Commons の実用例

特筆すべき点として、Stack Overflow に投稿されたコードは
自動的に CC BY-SA でライセンスされる[1]。

また、Wikipediaの記事も CC BY-SA で利用可能である[2]。

フォントのライセンス

• 無料で配布されるフォントの多くは、
  フォントに特化した独自のライセンスを付与している。
• 特によく使用されるのは
  SIL Open Font License (SIL OFL) で、
  ライセンスされたフォントの販売を禁止するなどの
  条件のほかは自由に使うことができる非常にゆるい
  ライセンスである。
• なお、SIL OFL は厳密にはGPLと非互換なため[1]、
  GNUでは「GPLフォント例外」というライセンスも用意している。

SIL Open Font License
https://openfontlicense.org/

OSSなどに対する
コントリビューション

パッチを当てた人の著作権はどうなる?

• ソフトウェアに著作権がある以上、パッチにも当然
  パッチを作成した人の著作権が存在する。
• 元ソフトウェアのライセンスがGPLならば:
  • パッチされたバージョンを配布する人の責任で、パッチも
    ​GPLでライセンスされることを保証しなければいけない
• 元ソフトウェアのライセンスが寛容なライセンス (MITなど) ならば:
  • パッチされたバージョンがどのようなライセンスで配布されるか、
    明示的に示さなければならない。
  • 通常はLICENSEファイルなどが改変されず残っていたら
    パッチされたバージョンも同じライセンスで
    配布されていると推定される

不特定多数からのパッチを受け入れる
大規模プロジェクトの場合

• 他人のパッチは他人の著作物であることから、
  第三者からのコントリビューションを受け入れるOSSプロジェクトは
  他人の著作物にライセンスを付与して頒布していることになる
• なので、厳密に言えばパッチを送った全てのコントリビューターに
  ​ライセンスを付与して頒布していいか許可を取る必要がある
  • もっとも、コントリビューターとしてパッチを送るということは
    普通はその変更をOSSに取り入れてもらいたいという意図なので、
    現実には問題になるケースは稀ではある
• そのため、大規模なオープンソースプロジェクトでは
  法的な問題を回避するために、プルリクエストなどで貢献する
  全てのコントリビューターに Contributor License Agreement (CLA) に
  同意することを義務付けている

Contributor License Agreement (CLA)

• CLAは、プロジェクトの管理者とコントリビューターの間で
  交わされる契約であり、その内容はプロジェクトによって異なるが
  おおむね以下のような内容が含まれている。
  • パッチをライセンスして頒布する著作権ライセンスの付与
  • 同様に、特許ライセンスの付与
  • パッチに関するこれらの権利を有することの確認
  • 免責事項
• また Linux Foundation では、よりシンプルな
  Developer Certificate of Origin (DCO) に同意することを示す
  「Signed-off-by: <name>」という文字列を全ての
  コミットメッセージに付加することを義務付けている
  • これは git commit --signoff で簡単に付加できる

Contributor License Agreement (CLA)

• もしあなたが大規模なオープンソースプロジェクトに
  コントリビュートした際にCLAへの同意を求められた場合は
  (よく読んだうえで) 基本的に同意してよい
  • コントリビュートの意思の最終確認であるため
• また、オープンソースプロジェクトを作成する側になった時
  法的なリスクをちゃんと考えるならばCLAの設置を
  ​考えてみても良いかもしれない
  • その際は contributoragreements.org などの
    ウェブサイトが参考になる

フォークについて

• GitHubのフォーク機能は、行為としては他のリポジトリを
  コピーして自分のアカウントのもとで再配布していることになる
• そのため本来は再配布が許可されるライセンスのリポジトリでしか
  行うことができないが、GitHubではサービス使用条件によって
  フォークを許可しなければならないことが定められている[1]。
• そのためGitHubリポジトリのフォークは自由に行うことができる
  • フォークしたあと追加のコミットを行ってよいかは
    そのリポジトリのライセンスの定めによる

ソフトウェアライセンスの
選び方

Q. いろいろなライセンスがあったけど、
これから新しく作るプロジェクトには
結局どれを選んだらいいの?

おすすめのライセンスは?

• FSFが主張するコピーレフトの考え方に共感したなら:
  • GPL系のライセンス
  • 自分事としてライセンスを採用する以上、GPLのFAQなどを
    よく読んであらかじめGPLについて深く知っておこう
• シンプルに誰でも使えるようにしたいなら:
  • MITなどのシンプルで寛容なライセンス
  • 特にMITライセンスは人気も高く、条項もシンプルで分かりやすい。
    実用上はMITライセンスを採用していればほぼ問題はない
• MITはシンプルすぎて心配なら:
  • Apache License 2.0
  • 特許ライセンスの付与などをカバーしており、訴訟リスクを
    避けるという点で優秀なので、大企業視点でも使いやすい[1]
  • Googleは特段の事由がない限り Apache License 2.0 を推奨している[2]
• 著作者表示義務もなくしたい。著作権を完全に放棄したいなら:
  • The Unlicense や Creative Commons Zero など

ライセンスの選び方

• GitHubが公開している choosealicense.com は
  このような情報がよくまとまっていて、とても便利
• どんなライセンスを採用するにせよ、
  自分が採用しているライセンスが何を許可していて、
  ​どんな条件があるかはちゃんと知っておこう
  • ライブラリやアプリケーションの利用者から
    「〇〇していいですか？」と聞かれたときに
    ちゃんと的確に答えられないとやはり問題が起こる

わたしの場合

• 以下は@hakatashiが自分のプロジェクトに適用する
  ライセンスを選ぶ際に考える個人的な意見です。
• まず、GPLなどのコピーレフト系のライセンスは避ける
  • コピーレフトという考え方は現代のインターネットにはそぐわないと思う
  • 自分が書いたコードに対する追加的な変更は、法的には派生著作物として自分の
    権利が及ぶとはいえ、やはりその人のものだし、オリジナルの著者がとやかく
    言うのは間違っていると思う
  • 加えて、GPLはとにかく考えることが多い
    • このスライドで論じた通り、何をしていいのか曖昧な部分も多い
    • GPLでライセンスされたソフトウェアを使う人全てに、数百行に及ぶ許諾書と
      その何倍もの長さがあるFAQを全て読んで理解してもらうというのは
      理想論に過ぎないと、今回のために調べて改めて感じた
  • また、@hakatashiが得意とするJavaScript系の技術と相性が悪い
  • コピーレフトという思想が歴史上果たしてきた役割については評価するが、
    オープンソースという文化が何年もかけて培われてきている現状、あらためて
    自由なソフトウェアという理想を無理に押し広げるようなライセンスは時代遅れ

わたしの場合

• 以下は@hakatashiが自分のプロジェクトに適用する
  ライセンスを選ぶ際に考える個人的な意見です。
• そのうえで、なるべくシンプルで寛容なライセンスを選びたい
  • 人気度も考えると、MITか Apache 2.0 の二択
    • ライセンスが多くのプロジェクトで採用されていることは、
      ​互換性や利用者からの理解を得るうえで重要
  • 今までは基本的にMITを選択していたが、最近では Apache 2.0 にすることも多い
    • @hakatashiのMITのライセンス表示ページ: hakatashi.mit-license.org
      • このウェブサイトはMITライセンスで義務付けられている「ライセンス表示」を
        ​行うためのショートリンクを作成できるもので、便利
  • MITはライセンスが曖昧で一部の企業では採用しづらい、という事情があることを知り
    より法的に適した Apache 2.0 を採用する気持ちに傾いてきた
  • Apache 2.0 は簡明さでは劣るものの、比較的コンパクトにまとまっており許容可能な範囲
    • もっとも、Apache 2.0 もかなりややこしいところがあるのだが
• 一部のプロジェクトでは著作権を放棄するためにCC0を採用している (このスライドなど)

複数のライセンスの適用について

• ひとつのソフトウェアに複数のライセンスを適用することがある
  • 特に2つのライセンスを適用する場合、デュアルライセンスとよぶ
  • ライセンスは利用許諾なので、当然1つのものに対して
    異なった方法で複数回利用許諾を与えることができる
  • 利用する側としては適用されたライセンスのうち1つを選択し
    ​その許諾条件に則ってソフトウェアを使えばよい
• 特にGPL系のライセンスでは、バージョンごとの互換性がない
  (GPLv2のソフトウェアはGPLv3と混ぜて使うことはできない)
  ことから、ライセンスを指定する際に「GPLのバージョン3以降の
  ライセンスでライセンスされる」のように書くことが多い
  • 詳しくはFSFのガイドラインを参照

まとめ

まとめ

• ソフトウェアライセンスは、OSSなどと関わるうえで
  絶対に避けては通れないもの
• OSSなどを利用する側としても、リリースする側としても、
  ライセンスというものがどのような仕組みで動いているのか、
  何を許諾し、どのような条件があるのかを知っておこう

ありがとうございました

参考文献

• [姉崎]: "OSSライセンスを正しく理解するための本" 姉崎章博著 シーアンドアール研究所 2021.11
• [宮原]: "オープンソースの教科書/ 宮原徹, 姉崎章博著" シーアンドアール研究所 2023.10
• [上田]: "OSSライセンスの教科書 : ソフトウェア開発の現場で求められる適切な利用方法" 上田理著 技術評論社 2018.9
• その他、本文中で示した多数のインターネット文献

Appendix

Appendix A: ソフトウェアライセンスに
契約としての訴求力はあるか

民法第522条（契約の成立と方式）
１.契約は、契約の内容を示してその締結を申し入れる意思表示（以下「申込み」という。）に対して相手方が承諾をしたときに成立する。
２.契約の成立には、法令に特別の定めがある場合を除き、書面の作成その他の方式を具備することを要しない。

単に著作権者が利用許諾の意思表示を示すだけのソフトウェアライセンスでは
「相手側が承諾」したとは言えないため、契約ではないと解する資料もある [姉崎, p74] が、同時に「利用者が著作物を利用したことで黙示の同意とする」とも解釈され、
こちらのほうがより一般的であるように見受けられる→参考資料 次ページ～

どちらにせよ、今のところ明確な判例がないので確定的なことは何も言えない

Appendix A: ソフトウェアライセンスに
契約としての訴求力はあるか

法的位置付けとしては、契約成立のための明示的な合意がないにもかかわらず、契約と解する根拠はあるのかが問題となる。利用者が契約内容を十分理解しないまま成立が問われるシュリンクラップ契約やクリックオン契約と似ているという考え方もありうるが、これらが主としてプログラムの実行についての契約であるのに対して、GPL は、実行にあたっては本ライセンスを受諾する必要がないと言っていること、GPL は公開されていて利用者は内容を検討することも可能であることから、これらの契約と同様に考えることはできない。むしろ、民法５２６条２項の「承諾の意思表示と認めるべき事実」があったときに契約が成立する（意思実現による契約の成立）との規定により、伝播行為の着手があったときに契約が成立すると解すべきであろう。

日本においては、一般には、GPL は契約であると考えられているようです。これに対して、アメリカにおいては、契約の成立に必要な OSS の利用者による「承諾」が存在するかどうかが議論されています。多くの場合、OSS の利用者は、GPL の適用を受けることについて明示的に同意しておらず、利用する OSS に GPLv2 や GPLv3 が記載されたテキストファイルが同梱されているに過ぎません。このような場合に、OSS の利用者が OSS を利用したからといって、GPL に拘束されることを承諾したといえるのか、という問題です。

Appendix A: ソフトウェアライセンスに
契約としての訴求力はあるか

CCライセンスに関しては、単独行為による利用権の許諾とする見解、及び利用許諾契約が成立しているとする見解がある。本件では、裁判所は、両者間の意思表示に関して詳細な事実認定をすることなく、CCライセンスを付与したことをもって利用許諾が成立すると判断しているといえる。なお、後者の見解については、予め所定の利用条件等を表記することにより利用許諾の意思表示とし、ユーザが対象の著作物等を利用した時点で契約が成立する解するものであるが[iv]、CCライセンス「リーガル・コード」前文[v]の定めにも整合しているといえよう[vi]。

この点に関し、本件において被告は、原告が本件写真を投稿しCCライセンスを表示した本件写真共有サイトではなく、「ビジュアルハント」という別のウェブサイトから本件写真をダウンロードしました。そのため、原告が本件写真共有サイト上で行った、利用許諾の申し込みの意思表示が被告に到達しておらず、契約が成立していないように思われます。しかし本判決では、特に意思表示が被告に到達したか否かを問題にすることなく、単にCCライセンスを付与したことをもって「使用を許諾した」と認定していることから〈前記（Ａ）〉、単独行為であっても利用許諾は成立する、という考え方を採用しているものと理解されます。一応「ビジュアルハント」上の表示を介して原告の利用許諾の意思表示が被告に到達したと解する余地もありますが、本判決では一切言及がないため、この考え方は採用されていないと考えられます。

≪クリエイティブ・コモンズ・ライセンス違反が著作権侵害に当たるかが争われた裁判例≫ | 知財弁護士.COM｜知的財産紛争・企業法務のご相談なら弁護士法人内田・鮫島法律事務所
https://www.ip-bengoshi.com/archives/7296 (強調は引用者)

生田哲郎◎弁護士・弁理士／川瀬茂裕◎弁護士 クリエイティブ・コモンズ・ライセンスが付された著作物の利用について著作権侵害が認められた事例
https://www.hanketsu.jiii.or.jp/hanketsu/jsp/hatumeisi/news/202211news.pdf

Appendix A: ソフトウェアライセンスに
契約としての訴求力はあるか

SFC vs VIZIO の訴訟では、GPLが契約であるという側面も肯定されました。GPLが契約であれば、契約書が重要になってきますので、GPLの条文本文と公開されているFAQあたりが争う際の根拠になってくるのではないでしょうか。著作権に基づかない請求も通るため、動的リンクの判例は流用されず、契約として動的リンクもGPLの適用を強制されると考えられるのではないでしょうか。

GPL再考 #ライセンス - Qiita
https://qiita.com/ground0state/items/ee0986381f79300208ef

Appendix B: JavaScriptや画像をCDNから
拝借する場合

• JavaScriptや画像をCDNから拝借した場合、ウェブサイトの作成者は
  単にHTMLにリンクを記載しただけとみなされるため、
  「公衆送信」には該当しないとみなされる 
• CDNに限らず、他で配信されている画像への直リンクimgや
  埋め込みプレイヤーなど、自分のサーバーで配信していない場合は
  公衆送信とはみなされず、判例では著作権侵害も著作者人格権侵害も
  認定されていない (ロケットニュース24事件) [1]
• ただし、自分で設置したリバースプロキシが中間にある場合は
  公衆送信とみなされる (漫画村事件) [2]
• CDN自体が違法な内容を配信している場合は、
  2020年著作権法改正によるリーチサイト違法化で
  CDNへのリンクを張った場合も違法となる可能性がある

Appendix C: FC2対ドワンゴ訴訟事件について

• ソフトウェア特許の侵害を認めた訴訟例として、2023年に知財高裁が
  FC2の運営する動画サービス「ひまわり動画」などでニコニコ風コメントを
  流す機能がドワンゴの特許を侵害していると認定した裁判[1]が身近かつ記憶に新しい。
• ドワンゴは過去に同様の訴訟をFC2に対して起こしており、当時はFC2の機能が
  特許の構成要件を満たしていないとして2018年に第一審で敗訴している[2]。
• これに対してドワンゴは徹底抗戦の構えを見せ、2019年に親出願を分割し
  余計な構成要件を省いて新たな特許を申請、これが認められ (この段階でも新規性や
  進歩性などを審査されるのでかなり険しい道である) 再度FC2を提訴し、控訴ののち
  ​2023年に勝利を勝ち取った。
  • なお、2018年に敗訴した事件も2022年に控訴審で勝訴している[3]。
• なお、くりたしげたかニコニコ代表は、同様の機能を実装するアドオンも
  「見つけ次第つぶしています」と発言している[4]。あくまで個人的な感想だが
  本特許はコメント配信サーバー・動画配信サーバー・ネットワークが一体と
  なったコメント表示システム全体に対して申請されたものであり、
  ブラウザアドオンにも同様に侵害が認められるかはかなり怪しいと思われる。
• なお本事件は (両方とも) 現在のところ最高裁へ上告受理申立て中であり[3]、
  ひまわり動画は現在もサービスを継続している。