SOFTIC 29-2

IoT 時代におけるOSS の利用と法的諸問題

Q&A 集

平成３０年３月
一般財団法人ソフトウェア情報センター

序現在、OSS は、IT 業界、家電業界、自動車業界、通信業界、その他の多様な事業分
野で活用されており、また、クラウドコンピューティング、ビックデータ、AI、IoT 等の技術分野でも、極めて重要な役割を果たし、今や世界の産業・経済を支える不可欠の存在と言っても過言ではありません。
そうした状況に鑑み、当ソフトウェア情報センターは、法律専門家と企業実務担当者で構成される「IoT 時代における OSS の利用と法的リスクに関する検討委員会」を立ち上げ、OSS を利用する上での法的諸問題やビジネスを展開する上での疑問点について、検討を重ね、その検討成果を Q＆A 集として取りまとめました。
本 Q＆A 集では、基礎的な論点を整理した上で、OSS の利用者・提供者の各立場からの留意点を分析し、OSS が混入した場合や複数の OSS を結合した場合の各ライセンス間の関係、OSS 混入のチェック方法、OSS を利用したシステム開発における責任、免責条項の問題、OSS ライセンスの法的性質、GPL の伝搬性の問題、GPL のライセン
スの留意点、特許条項をもつ OSS ライセンスの留意事項、OSS と管轄及び準拠法の問
題、代表的 OSS コミュニティや関連団体の活動内容等、OSS を活用したビジネスを展開する際に、特に留意すべきと考えられる論点を取り上げています。
本 Q＆A 集が読者のビジネスの実務に少しでもお役にたつことができれば幸いです。
なお、本 Q＆A 集は、各執筆者が個人としての立場で執筆されたものであり、委員会としての総意を取りまとめたものではありません。また、本 Q＆A 集の内容が、特定の個別事案等には必ずしも適合しないこともあり得ますし、網羅的な調査に基づくものではないために、記載内容に訂正を要する箇所もあるかもしれません。その点、ご容赦い
ただきますようお願いいたします。
最後に、本 Q＆A 集作成に当たりまして、後掲する委員会の委員の方々及びご協力いただいた皆様に多大なご尽力をいただきましたことを深く感謝申し上げます。
平成３０年３月
委員長 弁護士 宮下佳之
1

IoT 時代における OSS の利用と法的リスクに関する検討委員会（敬称略、五十音順）
【委員長】
宮下 佳之
【委 員】
阿久沢 剛
足立
岩井
岩切
岩原
上沼
梅谷
大内

多寿子
久美子
美和
将文
紫野
眞人
佳子

奥津
小栗
片山
北見
柴田

宏幸
久典
史英
かおり
木保子

野末

浩志

平嶋
桝井
松島
溝口
村尾
本永
吉田

竜太
知子
淳也
則行
治亮
公章
行男

弁護士、西村あさひ法律事務所

株式会社日立製作所 システム&サービスビジネス統括本部法務部部長代理
凸版印刷株式会社 法務本部法務部
弁護士、曾我法律事務所
株式会社日立製作所 知財マネジメント本部技術情報管理 G GL 部長代理
弁護士、水谷法律特許事務所
弁護士、虎ノ門南法律事務所
富士ゼロックス株式会社 知的財産部 知財渉外グループ長
富士通株式会社 法務・コンプライアンス・知的財産本部 知的財産イノ
ベーション統括部
株式会社日立製作所 知的財産権本部 知財ビジネス本部部長代理
弁護士、弁護士法人内田・鮫島法律事務所
弁護士・弁理士、虎ノ門南法律事務所
東芝デジタルソリューションズ株式会社 技術統括部知的財産担当部長
富士通株式会社 法務・コンプライアンス・知的財産本部知的財産戦略統括部マネージャー
株式会社東芝 ソフトウェア技術センターオープンソース技術部シニア
エキスパート
筑波大学 大学院ビジネス研究科教授
弁護士、Next 法律事務所
弁護士、松島総合法律事務所
TIS 株式会社 IT 基盤技術本部 OSS 推進室室長
弁護士、東啓綜合法律事務所
NTT データ株式会社 技術開発本部知的財産室
株式会社日立ソリューションズ 業務統括本部技術革新本部研究開発部
主管技師【オブザーバー】
小林 良岳
株式会社東芝 ソフトウェア技術センターオープンソース技術部部長
【事務局】
亀井正博
平澤高美
内田礼
高橋宗利

一般財団法人ソフトウェア情報センター
一般財団法人ソフトウェア情報センター
一般財団法人ソフトウェア情報センター
一般財団法人ソフトウェア情報センター

2

専務理事
調査研究部長
調査研究部課長代理
調査研究部

【目

次】

基 礎
基礎-1 OSS とライセンスの基礎知識・・・・・・・・・・・・・・・・・・・・・ 2
基礎-2 OSS のビジネスモデルと OSS の利用形態・・・・・・・・・・・・・・・・7
基礎-3-1 OSS 活用の際に遵守すべき知財関連の法令・・・・・・・・・・・・・・13
基礎-3-2 契約による合意がない場合のベンダの責任・・・・・・・・・・・・・・･17
基礎-3-3 OSS の輸出管理に関して遵守すべき法令・・・・・・・・・・・・・・・･21

A．関係する者の立場の違いからの視点
１．OSS を自社ソフトウェアへ組み込む場合
A-1-1 自社製品に OSS を組み込んで利用する場合、どのような判断基準で、どのようなライセンスの OSS を選択すべきか・・・・・・・・・・・・・・ 27
A-1-2 自社製品に OSS を組み込んで利用する場合、ユーザに提供すべき情報・・・・・・・・・・・・・・・・・・・・・・・31
２．自社ソフトウェアを OSS 化して提供する場合
A-2 自社ソフトウェアを OSS で提供する場合の留意点・・・・・・・・・・・・・40
３．OSS ソフトウェアを利用する場合
A-3 OSS のメリットと留意事項・・・・・・・・・・・・・・・・・・・・・・・43
４．クラウドサービスの利用
A-4 クラウドサービスを提供するためのソフトウェアに
OSS を利用する場合の留意点・・・・・・・・・・・・・・・・・・・・・・51

B. 課題領域
１．OSS の両立／混入
B-1-1

OSS の両立性とは・・・・・・・・・・・・・・・・・・・・・・・・・・55

B-1-2

OSS チェック方法・・・・・・・・・・・・・・・・・・・・・・・・・・57

B-1-3

OSS の混入をチェックするチェックツールの種類・・・・・・・・・・・・60

B-1-4

OSS 混入のチェックツールの選択・・・・・・・・・・・・・・・・・・・62

２．OSS の教育
B-2 OSS 利用ポリシーと社内教育・・・・・・・・・・・・・・・・・・・・・・65
３．OSS とサポート・セキュリティ（脆弱性）
B-3-1

OSS とサポート、セキュリティ（脆弱性）－サポートと脆弱性対策・・・・69

B-3-2

OSS とサポート・セキュリティ（脆弱性）－バグを発見した場合の対処・・73

４．OSS の管理
B-4

OSS の管理について・・・・・・・・・・・・・・・・・・・・・・・・・・75
3

C. 取引上の留意点
１．OSS と免責条項
C-1-1 免責条項の文例・・・・・・・・・・・・・・・・・・・・・・・・・・・・78
C-1-2 受託開発において受託者の故意・重過失により免責条項の適用が制限される場合・・・・・・・・・・・・・・・・・・・・・・・・・・・81
C-1-3 受託開発におけるベンダのユーザに対する説明義務・・・・・・・・・・・・85
C-1-4 受託開発でユーザが OSS を選定した場合のベンダの責任・・・・・・・・・88
C-1-5 契約書等の書面による合意がない取引で、ユーザから免責の同意を得る方法・・・・・・・・・・・・・・・・・・・・・・・・・・・91
C-1-6 消費者契約法により免責条項の適用が制限される場合・・・・・・・・・・・94
C-1-7 製造物責任法上の責任を排除する免責条項について・・・・・・・・・・・・97
２．契約条項等
C-2-1 ソフトウェア開発委託契約について・・・・・・・・・・・・・・・・・・101
C-2-2 ソフトウェア使用許諾契約書について－モデル契約の有無と留意点・・・・105
３．OSS 化と会計・税務処理
C-3 ソフトウェアを OSS 化する場合の会計上、税法上の取扱い（資産計上・費用処理）について・・・・・・・・・・・・・・・・・・・・・108

D. GPL その他の OSS ライセンス上の留意点
１．ライセンス表示やソースコードの提供
D-1 JavaScript や１プログラム中に多数のライセンスが含まれる場合の表示方法・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・118
２．ライセンスの解釈
D-2-1

OSS ライセンスの解釈・・・・・・・・・・・・・・・・・・・・・・・122

D-2-2 「非営利」目的の利用のみ認められているソフトウェアについて・・・・・123
D-2-3 ライセンスの「継承」と修正・・・・・・・・・・・・・・・・・・・・・126
D-2-4 ライセンスが未添付などにより確認できない場合・・・・・・・・・・・・129
３．GPL の伝搬
D-3-1 GPL の伝搬性－Application Programing Interface・・・・・・・・・・・131
D-3-2-1 GPL が適用されたエディタやコンパイラの出力と GPL・・・・・・・・142
D-3-2-2 GCC コンパイルによる GCC ランタイムライブラリとのリンクによる GPL への適用・・・・・・・・・・・・・・・・・・・・144
D-3-3 GPL の OSS とのリンクによる GPL の伝搬－受託開発・・・・・・・・・・146
D-3-4 OSS のユーザによる取得・リンク－ベンダによる代行・・・・・・・・・・149
D-3-5 GPL のソフトウェアによる社内システムのグループ会社への提供・・・・・151

4

D-3-6 GPL ライセンスのソフトウェアをインストールした PC の貸出が配布に該当するか・・・・・・・・・・・・・・・・・・・・・・・153
D-3-7-1 R 言語の規約に従ったスクリプトと GPL・・・・・・・・・・・・・・・・154
D-3-7-2 伝搬性－ソフトウェアの開発方法・・・・・・・・・・・・・・・・・・156
D-3-8

LGPL－リバースエンジニアリングの許可・・・・・・・・・・・・・・・・159

４．GPL ライセンスの解釈上の諸問題
D-4-1

GPL の法的性質・・・・・・・・・・・・・・・・・・・・・・・・・・・166

D-4-2 GPL が定める以上の制限の追加・・・・・・・・・・・・・・・・・・・・169
D-4-3 ライセンスを遵守していない OSS の利用・・・・・・・・・・・・・・・・173

E. コミュニティや OSS 関連団体
E-1 コミュニティや OSS 関連団体・・・・・・・・・・・・・・・・・・・・・・175
E-2 Openchain の取組み・・・・・・・・・・・・・・・・・・・・・・・・・・182

F. 知的財産に関する問題
1.特許条項を有する OSS ライセンスの概観と留意事項等
F-1-1 GPLv3､Apache2.0 等の特許条項を有するﾗｲｾﾝｽの概観と留意事項（１）・・・186F-1-2 GPLv3､Apache2.0 等の特許条項を有するﾗｲｾﾝｽの概観と留意事項（２）・・・191F-2 特許調査・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・194
F-3

OSS の混入発見と守秘義務について・・・・・・・・・・・・・・・・・・・198

F-4-1 OSS と越境問題－国際裁判管轄・・・・・・・・・・・・・・・・・・・・201
F-4-2 OSS と越境問題－準拠法・・・・・・・・・・・・・・・・・・・・・・・207

G. トラブル事例
1.OSS の過去の問題事例
G-1-1

OSS の過去の問題要因・・・・・・・・・・・・・・・・・・・・・・・・216

G-1-2

OSS の裁判事例・・・・・・・・・・・・・・・・・・・・・・・・・・・218

2. OSS ライセンス違反の法的責任
G-2-1

OSS 混入によるライセンス違反・・・・・・・・・・・・・・・・・・・・225

G-2-2

GPL 違反による法的責任・・・・・・・・・・・・・・・・・・・・・・・229

G-3 ライセンス違反等のトラブルへの対応・・・・・・・・・・・・・・・・・・232

H. OSS の今後の動向
H OSS の今後の展望・・・・・・・・・・・・・・・・・・・・・・・・・・・・237

5

基

礎

1

Question 基礎-1

OSS とライセンスの基礎知識

OSS とはどのようなものですか、また、ライセンスにはどのような内容が書かれているのですか？

Answer
１．OSS について
OSS とは、ソースコードが入手可能であり、誰でも自由に複製や改変、配布1ができる条件で提供されているソフトウェアのことです。OSI（Open Source Initiative）2が OSS の定義を定めていますので、具体的な条件については、以下の WEB サイトを参照してください。
●The Open Source Definition
https://opensource.org/osd（１）フリーソフトウェアと OSS の違い
日本国内で無償公開されているソフトウェアの中には「フリーソフトウェア」や「フリーウェア」と呼ばれるものがあります。これらはソースコードが公開されているとは限りません。また、ライセンス条件で一定の制限が課されているものもあり、必ずしも自由に
複製や改変、配布ができるとは限りません。したがって、「フリーソフトウェア」や「フリーウェア」の中には、OSS の定義に合致しないものもあります。
一方、Free Software Foundation が定義している「フリーソフトウェア」は、誰でも自由にソフトウェアの実行ができ、ソースコードの改変や配布を行うことができる条件で公開されているソフトウェアです。したがって、基本的な考え方は、OSS とほぼ同じ3です。
フリーソフトウェアの定義については、以下の WEB サイトを参照してください。
●The Free Software Definition
https://www.gnu.org/philosophy/free-sw.en.html
なお、世の中には、上記のような定義を気にせず OSS やフリーソフトウェア、フリーソ
フトウェアといった言葉を使っている人も多いので、どのような意図でこれらの言葉4を使OSS を他者へ提供することを「再配布」ということもあるが、本書では「配布」と記載する。
OSI は、OSS の推進団体であり、OSS の定義に合致したライセンスを承認する活動を行なっている。
3 OSS を利用した成果物の中には、自由利用が維持されていないものもあることから、「フリーソフトウ
ェア」とは異なるとの意見もある。
4 OSS やフリーソフトウェアのように自由利用が許諾されたソフトウェアを総称して FOSS(Free andOpen Source Software)、あるいは FLOSS(Free/Libre and Open Source Software)と呼ぶ人もいる。
122

っているのかに留意する必要があります。
（２）代表的な OSS
著名な OSS の例としては、OS である Linux や Android、プログラム開発言語の java

や perl、ruby、開発フレームワークの Eclipse、JavaScript 用のライブラリである
jQuery、データベースの PostgreSQL や MySQL、WEB サーバの Apache HTTP Server、
その他、近年では、クラウド基盤である OpenStack やサーバ運用管理用の Zabbix 等があります。
２．ライセンスについて
OSS のライセンスは、各 OSS の著作権者が定めたものであり、OSS の利用者に対して許諾する行為とその条件、あるいは禁止する行為等が記載されています。
（１）代表的なライセンス
著名なライセンスとしては、以下があります。
（以下のライセンス名は略称を記載しています。正式な名称は表１をご参照ください）①GPL および LGPL（最新版は v3）
Free Software Foundation で作成されたライセンスです。
GPL が適用された OSS（GPL プログラム）を改変して、このプログラムに基づく著作物（派生著作物）を作成し、配布する場合、その全体について GPL の条件を遵守する義務があります。この条件により、GPL プログラムと他のプログラムをリンクや結合した場合、他のプログラムにも GPL の条件を適用する必要があります。
LGPL は、GPL の条件を少し弱めたライセンスです。LGPL が適用された OSS（LGPL プログラム）と他のプログラムをリンクした場合、リンクした他のプログラ
ムに LGPL を適用する必要はありませんが、リバースエンジニアリングを許諾する（禁止しない）義務があります。
最新のバージョンは GPLv3 ですが、GPLv2 の OSS も多数、存在しています。GPLv3
で追加された条件としては、OSS で実施された特許権について、当該 OSS の開発者が保有する特許権を許諾する条件や、ユーザ製品に OSS を利用する場合には修正した
OSS を再インストールできるように、「インストール用情報」を提供する義務などが追加されました。また、LGPLv3 については、GPLv3 の追加的許諾条項となりました。
なお、GPL や LGPL は、OSS を配布した際に条件が課されるため、誰にも配布しない場合は、ソースコードの提供等の義務はありません。これをカバーするためにAfferoGPLv3 が作成されました。このライセンスは、クラウドサービス等のサーバでOSS（AfferoGPLv3）を利用した場合、（OSS のバイナリを配布しない場合でも）サーバにアクセスするクライアントへソースコードを提供する条件が GPLv3 に追加された

3

ライセンスです。
②CPL v1.0
IBM で作成されたライセンスであり、CPLv1.0 が適用された OSS（CPL プログラム）を配布する場合は、ソースコードも提供する義務があります。また、CPL プログ
ラムのコントリビュータに対する特許訴訟（訴訟対象は OSS に限定されていない）を制限する条件があります。
③EPL v1.0
Eclipse Foundation で CPLv1.0 を基に作成されたライセンスであり、上記②記載の特許訴訟の制限が削除されました。
④MPL（最新版は v2.0）
Mozilla Foundation で 作 成 さ れ た ラ イ セ ン ス で す が 、 も と も と は NetscapeCommunications の弁護士により作成されたものです。MPL が適用された OSS（MPL
プログラム）のソースコードを配布する場合は、ソースコードも提供する義務があります。
最新のバージョンは MPLv2.0 ですが、MPLv1.1 の OSS も多数、存在しています。
MPL v2.0 で追加された条件としては、GPL 関連の OSS と組み合わせて配布する場合、“Secondary License”（GPLv2.0/LGPLv2.1/AfferoGPLv3.0、以降のバージョンを含む）を適用することを許諾するか否かを定めることができるようになりました。
⑤Apache License（最新版は v2.0）
Apache Software Foundation で作成されたライセンスです。
最新のバージョンは Apache License v2.0 ですが、Apache Software License v1.1
も多数、存在しています。
Apache Software License v1.1 は、ドキュメントへの謝辞の記載義務があります。
Apache License v2.0 では、謝辞の記載義務は削除され、開発者による著作権や特許権の許諾が明確になりました。
⑥BSD License
カリフォルニア大学で作成されたライセンスであり、制限は緩く、著作権表示と許諾リスト、免責条項を記載する義務があります。
以前の OLD BSD License（4-Clause）には、宣伝媒体に所定の謝辞を記載する条件がありましたが、NEW BSD License（3-Clause）では、削除されました。2-Clauseの BSD License もあり、3-Clause から開発者名等の利用許諾に関する条件を無くし、ソースコードとバイナリの配布条件を記載したライセンスです。
⑦MIT License
マサチューセッツ工科大学で作成されたライセンスであり、制限は緩く、著作権表
示と許諾表示を記載する義務があります。BSD License（2-Clause）と利用条件は類似していますが、MIT License では、サブライセンスの許諾等、著作権者が許諾する内4

容が細かく記載されています。
⑧CC ライセンス（最新版は v4.0）
クリエイティブ・コモンズで作成されたライセンスであり、条文とは別に、条件をマークで示すことで分かりやすくしたライセンスです。マークにはクレジットの表示
義務、営利目的での利用禁止、改変禁止、ライセンス継承義務の４種類があり、これらの組み合わせにより条件を示します。
なお、本ライセンスは、OSI 承認のライセンスには含まれていません。
OSI により OSS の定義に合致しているとして承認されたライセンスについては、以下のWEB サイトに掲載されています。
●Licenses by Name（Open Source Initiative）
https://opensource.org/Licenses/alphabetical●OSI 承認オープンソースライセンス 日本語参考訳
https://osdn.jp/projects/opensource/wiki/Licenses（２）よくあるライセンス条件
各 OSS の著作権者は、自らが開発した OSS について、他人が複製や改変、譲渡等、著作権法上の利用行為を行なうことについて、コントロールする権利を持っています。したがって、OSS の利用を許諾する際、自由に様々な条件を定めることができます。
よくある条件としては、例えば、以下のようなものがあります。
①OSS を配布する際には、その OSS の著作者が定めたライセンス文書を添付すること②OSS を配布する際、OSS に含まれていた知的財産関連の情報（著作権表示等）を残しておくこと③OSS を利用した製品に、その OSS が含まれている旨の記載を行なうこと④OSS を改変する際には、誰が、どのような改変を行なったのかを記載しておくこと⑤OSS を改変して提供する際には、改変者が含めた自らの特許権を改変版の利用者に許諾すること⑥OSS のバイナリを提供した相手に OSS のソースコードも提供すること⑦上記⑥に加えて、OSS と他のプログラムをリンクや結合等して作成した派生著作物を配布する場合、全体のプログラムのソースコードも提供して、同じ OSS のライセンスを適用すること
世の中の状況を見ると、OSS のライセンス条件に違反しているとして訴訟等のトラブルに発展しているケースは、上記⑥⑦のようにソースコードの提供義務があるライセンスに関連しているものが多いようです。表 1 にソースコードの提供義務のあるライセンスを示

5

します。
【表１】著名なライセンスとソースコードの提供義務*1：OSS のソースコードを提供する義務の有無*2：OSS と他のプログラムをリンク等により作成した派生著作物全体のソースコードを提供する義務の有無
略称

OSS*1

名称

派生著作物
全体*2

GPL

GNU General Public License

有

有

LGPL

GNU Lesser General Public License

有

無（注）

AGPL

GNU Affero GENERAL PUBLIC LICENSE

有

有

CPL

Common Public License

有

無

EPL

Eclipse Public License

有

無

MPL

Mozilla Public License

有

無

CDDL

Common Development and Distribution License

有無Apache License

Apache License

無無BSD License

BSD License

無無MIT License

MIT License

無無CC License

Creative Commons License

無無（注）LGPL プログラムと他のプログラムを静的リンクした場合は、他のプログラムのオ
ブジェクトコードかソースコードのどちらかを提供する義務があります。
３．近年、多いライセンス
世の中には、多数の OSS が様々な場所で公開されているため、どのライセンスの OSSが多いかを集計5することは困難です。参考情報になりますが、ソースコードの管理サービスを行っている GitHub が 2015 年 3 月 10 日に発表した情報によると、GitHub 上のプロ
ジェクトが採用しているライセンスは、MIT ライセンスが最も多く、約半数弱がこのライセンスを採用しているということです。その他、GPLv2、Apache License と続いています。
●Open source License usage on GitHub.com
https://github.com/blog/1964-open-source-License-usage-on-github-com（作成日：2017 年 11 月 14 日）

5Black Duck 社は「Top 20 Open Source Software Licenses」を公開している。
https://www.blackducksoftware.com/top-open-source-licenses

6Question 基礎-2

OSS のビジネスモデルと OSS の利用形態

OSS のビジネスモデルや、ビジネスでの OSS の利用の仕方にはどのような形態がありますか。また、それぞれの形態（ビジネスモデルや利用の仕方）の特徴や、メリット、デメリ
ットは何ですか？

Answer「OSS でビジネスができますか？」、「OSS でどのようなビジネスモデルが可能でしょうか？」といったことが議論されることが多くあります。これは、OSS そのものが多くの場
合に無料で入手や利用可能であることと、OSS がいろいろな自由度を持っているために知恵と工夫で様々なビジネスモデルが可能なことに起因していると言えます。なお、OSS のビジネスモデルについては、確立した分類の仕方があるわけではありません。ここでは、オープンソースビジネス推進協議会（OBCI）による分類6を元に一部分類を追加して説明をしますが、その他の分類の仕方をする場合もあります7。
１．ディストリビューションモデル
（１）特徴
自社またはコミュニティにて開発されたソフトウェアの配布とサポートを行うモデルです。対価をいただく部分の基本は、ソフトウェアの配布よりも、サポート提供（OSS についての技術問合せへの回答など8）が一般的です。したがって、多くの場合は年間契約で提供されます。
このモデルで対象にする OSS には、(a) 自社で開発した OSS の場合(b) 公開されている OSS を対象にする場合の両方の場合があり得ますし、(a)と(b)が組み合わされている場合もあります。メリットやデメリットは、この(a)と(b)のパターンで異なってきます。

OBCI，「オープンソース入門」（2016 年 11 月版）， http://www.obci.jp/2016event/2338/
寺田雄一，「最新オープンソースがよーくわかる本」，秀和システム，2016 (ISBN 978-4-7980-4783-6），
p.84〜（オープンソースビジネス５分類），http://www.shuwasystem.co.jp/products/7980html/4783.html
8 OSS サポートサービスの内容は、技術問合せ、障害調査、情報配信(アップデートや脆弱性情報など）が代表的であるが、ソースコード解析、パッチ（修正プログラム）提供が含まれる場合や追加サービスで用意されている場合もある。サービス内容や提供時間帯、課金の仕方などは、同じ OSS プロダクトについても提供各社ごとに異なる。
6
7

7

（２）例
① 自社で開発した OSS の場合
Zabbix（Zabbix）、NTT データ（Hinemos）など。
② 公開されている OSS を対象にする場合
野村総合研究所（各種 OSS）
、サイオステクノロジー（各種 OSS）など。
③ 組み合わさっている場合
レッドハット（Linux カーネル他）、SRA OSS（PostgreSQL の拡張機能や独自ディストリビューション）、 オープンソース・ソリューション・テクノロジ（OpenAM を元にした独自ディストリビューション）など。
（３）自社で開発した OSS の場合のメリットとデメリット【メリット】
成功した場合に大きな収益となることが期待できます。年間契約でのサポート提供や、サブスクリプション方式9であれば、売上が毎年得られます。
【デメリット】
ソフトウェアの開発投資が必要なのは当然ですが、OSS 化によって投資回収が遅くなる場合もあります。
（４）公開されている OSS を対象にする場合のメリットとデメリット【メリット】
すでに存在する OSS をサポートするので、サポート対象の OSS に精通したエンジニアを確保できれば、参入障壁がほとんどなくすぐに提供を始められます。
【デメリット】
他社も同じ OSS のサポートを提供できるので価格競争になりやすく、利益の確保が難
しくなりがちです。
２．システムインテグレーションモデル（１）特徴
OSS を活用したシステム構築およびプロフェッショナルサービス（コンサルテーションを含む）を提供するモデルです。顧客との契約や対価のいただき方は、OSS ではない場合と何ら変わりません。
（２）例
OSS を採用したシステムインテグレーションを推進している例としては、NTT データ、
ソフトウェアの販売方法の形態で、特定期間の使用権やサポートを販売する方式。1 年間の料金を支払う形態が一般的である。参考: http://www.weblio.jp/content/サブスクリプション契約
98

日立ソリューションズ、電通国際情報サービス、TIS などがあります。なお、現在ではほとんどのシステムインテグレータ（IT サービス企業）が OSS を採用したシステム構築を実施
しています。
（３）メリットとデメリット【メリット】
いわゆる商用ソフトウェアの代替としたコスト削減をメリットと考えるケースがもっとも多いようです。また、特定のソフトウェアベンダに囲い込まれないオープン性や、特殊な機能要求などに合わせてソフトウェアを変更できること（カスタマイズ性）もメリットです。昨今では、ビッグデータ関連や人工知能関連などを実現するソフトウェアが OSS として発表されるケースが多く、最新技術をいち早く採用できる点もメリットになりつつあります。
【デメリット】
オープン性やカスタマイズ性との兼ね合いでもありますが、システムインテグレータが技術課題を解決しないといけない部分が増えます。昨今では極めて多くの種類の OSS があり、中には品質面に不安があるなど未成熟な OSS が存在することも事実です。また、シス
テムインテグレーション事業ではシステム構築費用の他にソフトウェア製品の販売ビジネ
スが組み合わさっている場合も多く、営業面での商用ソフトウェアの販売額の低下が OSS
採用のマイナス要因となっている面もあります。
３．サービスモデル（１）特徴
クラウドサービスや WEB サービス、SNS 等、OSS を活用して構築したサービスをイン
ターネットなどで提供するモデルです。顧客との契約や対価のいただき方は OSS を利用していることと無関係です。顧客はサービスが提供する機能を利用するだけですから、サービスが OSS で実現されているかどうかは通常は意識しません。OSS のビジネスモデルとしてこの形態が特徴的なのは、(1) 中核のコンポーネントとして OSS を採用することで OSSが競争力の源泉となっていること、(2)サービスのために開発したソフトウェアを OSS として公開することがサービスのアピールや優位性の一助となっていることが挙げられます。
（２）例
いわゆるハイパージャイアントと呼ばれるインターネット上で世界的に大規模にサービスを展開している事業者（Google や Facebook、Twitter など）は、自社のサービス実現のために有益な OSS を積極的に採用すると共に、独自のソフトウェアを開発し、その一部をOSS として公開するケースが目立っています。日本の楽天やヤフーなども同様に OSS を積9極的に採用したり OSS を公開しています10。
（３）メリットとデメリット【メリット】
システムインテグレーションの場合と同様に、コスト削減、オープン性、カスタマイズ
可能性、最新技術採用のメリットがあります。サービスモデルの場合、その対価はサービ
ス内容で決定されますので、実現コストの削減はサービス事業者の利益にできる場合が多いでしょう。
自社で開発したソフトウェアを OSS として公開する場合、公開することで自社のサービスや技術の優位性をアピールする広告としての効果が期待できます。また、周辺ツールや周辺ビジネスの誕生、発達に寄与する効果も期待できます。また、コミュニティによる機能追加や品質改善が、自社サービスの改善につながる場合もあります（コミュニティを組織的に立ち上げる場合もあれば、非組織的な開発者によるフィードバックの場合もあります）。
【デメリット】
他のモデルと比べたときのサービスモデルでの注意点は次の 2 点が挙げられます。
・OSS のライセンスには、ASP や SaaS の様なサービス提供型で利用する場合の条項が明記されているものがあります。（例: Affero GPL（AGPL））。
・OSS の脆弱性が発見された場合に、その脆弱性を悪用される懸念が高くなります。これは OSS 固有の問題というわけではありませんが、サービスで利用しているソフトウェ
アを OSS として公開することは脆弱性を発見されやすくなる面もあります。
４．製品組み込み利用
自社パッケージソフトウェアやその他製品の一部に OSS を利用する形態です。
【特徴】
気をつけるべきポイントは、製品とともにその中に組み込まれた OSS が利用者に届けられることです。これは「OSS の配布」にあたると考えられます。したがって、利用する OSSのライセンスが課している配布する場合の条件を満たすようにする必要があります。11このことは、その製品が有償か無償かとは無関係です。
５．社内利用
自社の社内システムなどに OSS を活用する形態です。これは開発コスト低減であったり、先進技術を速やかに組み込むなどの利用の仕方なので、オープンソースビジネス（オープ2013 年 3 月 26 日 OBCI プレミアムセミナー，「主役交代、IT の未来は OSS が決める」，
http://www.obci.jp/2013event/900/ 、 http://itpro.nikkeibp.co.jp/article/NEWS/20130327/466483/
11本書「A-1」を参照。
10

10

ンソースを収益や競争力の一つにしている）ものとは異なりますが、利用の仕方や適用箇所によって特徴や気をつけるべき点などが異なります。
【特徴】
一般的な商用ソフトウェアとの明確な違いは、利用開始前（対象の社内システムの開発前）に、購入という行為が必要ない点でしょう。ただし、これは一般論なので、Red Hat
Enterprise Linux のように購入が必要になる OSS も存在します。サポートやコンサルテー
ションなどのサービスが必要であれば、それらが必要なタイミングからサービスを購入することになります。
費用、品質，利用ノウハウなど各ソフトウェアの個別事情の差異がほとんどで、OSS か
非 OSS であるかの違いはほとんどありません。OSS 固有のライセンスの制約を受けることもあまりありません（厳密には個別の OSS のライセンス条件に依存します）。
５．複数モデルのハイブリッド型
上記のビジネスモデル（ディストリビューションモデルからサービスモデルの３種類）
を単独で提供する企業ばかりではなく、異なるモデルを組み合わせて OSS をビジネスにしている形態もあり、昨今ではこの様なハイブリッド型が多くなってきています。
① ディストリビューションとシステムインテグレーション
製品サポートの提供に加えて顧客からの要望に応じてコンサルティングを含むシステ
ム構築を請け負う形態や、システムインテグレータが OSS 専門部隊を持ってサポート
サービスも提供する形態がこれに該当します。
② ディストリビューションとサービスモデル
OSS をディストリビューションモデルで提供すると共に、その OSS を使った
SaaS/ASP サービスを提供する形態です。
６．まとめ
ビジネスモデルや利用形態ごとの、OSS の特徴からくるメリット、デメリット（OSS であることによる要注意点）を整理すると下表の様になります。

11

メリット

デメリット（注意点）

収益事業化

サービスや

先進性やオ

ライセンス

サポート

のしやすさ

製品のアピ

ープン性の

遵守への注

継続や脆

ールのしや

享受

意

弱性への

すさ

注意

1. ディストリビューションモデル
自社ソフトウェア

✓大

✓大

—

—

✓大

その他

✓

△

—

✓

✓大

2. システムインテグレーション

△

✓

✓

✓

✓大

3. サービスモデル

△

✓大

✓

✓大

✓大

4. 製品組み込み

—

—

✓

✓大

✓大

5. 自社内利用

—

—

✓

✓小

？

✓: 該当する、 △: やや該当する、？: 個別ケース次第、—: 該当しない／対象外（作成日：2017 年 11 月 24 日）

12Question 基礎 3-1

OSS 活用の際に遵守すべき知財関連の法令

OSS を活用する際、知的財産法の分野ではどのような法律を遵守する必要がありますか12？

AnswerOSS を活用する場合、商用ソフトウェアの場合と同様、著作権法、特許法、商標法などの法律を遵守する必要がありますが、OSS の場合には、商用ソフトウェアとは異なる検討が必要となる点もあります。
１．著作権法（１）著作権とは
著作権は、著作物（思想又は感情を創作的に表現したものであって、文芸、学術、美術
又は音楽の範囲に属するもの）を創作した著作者に自動的に発生する権利13であり、著作権の保護期間は、原則として著作者の死後５０年間です。また、法人等が名義を有する著作物の場合は公表後５０年間、公表されなかった場合は創作後５０年間が保護期間になります。
著作権法によって著作権者が専有するものと認められた権利（複製権、公衆送信権、譲渡権、翻案権等）を、著作権者以外の第三者が行使するには、著作権者の許諾が必要であり、この許諾なしに権利行使をすれば、著作権侵害として、著作権者から損害賠償請求や差止めを受ける可能性があります。
著作物には、プログラムの著作物14も含まれます。したがって、ソフトウェアを、著作権者の許諾なく業務上15複製したり譲渡したりする行為は、当該ソフトウェアの著作権侵害となります。
（２）OSS の著作権
OSS は、ソースコードが入手可能であるとともに、「誰でも自由に複製や改変、配布ができる」との条件で提供されているソフトウェアと定義されています16。
12

本問においては、準拠法として日本法が適用されることを前提とする。準拠法の決定方法に関しては、
本書「F-4-2」を参照。
13 無方式主義。登録が権利発生要件となる特許権等（方式主義）と異なる。
14 「電子計算機を機能させて一の結果を得ることができるようにこれに対する指令を組み合わせたものとして表現したもの」
15 私的使用のための複製は、デジタル方式の録音録画機器等を用いて複製する場合などを除き、著作権侵害とはならない。
16 OSI（Open Source Initiative）が OSS の定義を定めている（The Open Source Definition）。
https://opensource.org/osd

13ソフトウェアの複製17、改変、配布は、著作権者の権利であり、本来、第三者はこれらを自由に行うことはできません。OSS において、これらの行為が自由とされているのは、法的には、OSS の著作権者が、OSS の著作権を留保しつつ18、OSS 利用者に対し、ライセンスの規定を遵守することを条件に、複製や改変などの本来著作権者の許諾なくしてはなし
えない行為を許諾するものと宣言していることによります。したがって、OSS 利用者がライセンス条件に違反する場合には、OSS の著作権侵害となり、OSS の著作権者から、損害賠償や差止めの請求を受けるリスクがあります。OSS の著作権侵害の問題を生じさせないためには、許諾条件であるライセンス条件を遵守することが必要です。
（３）OSS による第三者の著作権侵害
OSS のユーザがライセンス条件に違反して OSS の著作権を侵害するケースとは別に、
OSS 自体が第三者の著作権を侵害するケースも考えられます。たとえば、自社で OSS を開発する場合（自社ソフトウェアを OSS ライセンスによって提供する場合）において、OSSの開発過程で、開発者が従前の受託開発した商用ソフトウェアで著作権を譲渡したものを混入させるケースなどです。その結果、商用ソフトウェアを含む OSS を配布することによって当該商用ソフトウェアの著作権を侵害する事態が生じます。すなわち、商用ソフトウ
ェアのライセンスは通常、著作権を許諾する条件として、ユーザによる複製や改変等に制限を課しているため、商用ソフトウェアが混入した OSS を、複製、改変、配布を自由とするライセンスによって配布することは、当該商用ソフトウェアの著作権を自社が保有していない以上、同著作権の侵害になるのです19。
上記のケースにおいては、商用ソフトウェアの著作権者から、OSS 開発者（自社）やその OSS を利用してソフトウェアを開発した企業に対して、損害賠償請求や当該 OSS の差止請求がなされる可能性があります2021。そして、場合によっては、当該 OSS を利用したビジネス自体の中止を余儀なくされることがあり得ます。
このような事態を防ぐため、自社で OSS を開発しようとする場合には、開発者に対して、
既存プログラムを再利用して開発する場合の留意事項を説明し、著作権帰属の確認を徹底するなどの対策を検討する必要があると考えられます。

17「私的使用のための複製」等、著作権が制限される場合を除く。
OSS においては、著作権を放棄する方法でソフトウェアを公開する（パブリックドメイン化する）手法
は採用されていない。
19 ソフトウェアのソースコードは不正競争防止法上の営業秘密として保護されるとして（平成 25 年 7 月
16 日判決（大阪地裁 平成 23 年（ワ）第 8221 号）参照）、不正競争防止法違反の責任も生ずる可能性がある。
20 米国では、2003 年に、SCO グループが自社が知的財産権を保有する UNIX のソースコードが OSS である Linux に流用されたと主張して IBM などを提訴した事件がある。本件は 2010 年 6 月、SCO が UNIXの知的財産権を保有しないとの結論で決着した。
21 OSS を使用するだけのユーザについては、プログラム入手時に著作権侵害の事実を知っていた場合に限り著作権侵害行為とみなすとの規定により免責される可能性が高い。
1814

２．特許法（１）特許権とは
特許権は、一定の発明（自然法則を利用した技術的思想の創作のうち高度のもの）をした発明者に対して付与される権利であり、特許庁に出願し審査を経て登録されることにより発生します22。特許権者は、特許権の存続期間（特許出願の日から 20 年間）中、業として、特許発明を独占的に実施することができます。「実施」とは、物（プログラムを含む）の発明については、その生産、使用、譲渡等、輸出若しくは輸入又は譲渡等の申出をする行為をいいます。
（２）OSS による第三者の特許権侵害
OSS が第三者の特許権を侵害している場合、商用ソフトウェアによる特許権侵害のケー
スと同様、特許権者から差止請求や損害賠償請求を受けるリスクがあります。
OSS 開発者、OSS の供給を受けて自社ソフトウェアを開発する者、OSS 利用者のいずれもが上記リスクを負っています。そして、特許権者から責任追及された場合、別途、ライセンス許諾を得るか、OSS から当該特許権を侵害するソースコードを除去する必要があり、どちらの対応もできない場合には、OSS 開発者は当該 OSS の提供自体の中止、自社ソフト
ウェアの開発に OSS を利用した者は自社ソフトウェアの取引の中止に追いこまれる事態も考えられます。
また、OSS については、①多くの開発者が関与して開発や機能追加等が行われ、開発者の中には特許侵害の認識がない開発者もいることが予測されるため、第三者の特許権を侵害する機能が混入する可能性がおのずと高くなる可能性がある、②特許権者が第三者による特許権侵害を発見しようとする際、ソースコードが非公開の商用ソフトウェアでは、発明の利用をプログラムの機能によって確認するしかないのに対して、OSS の場合は、OSSの名称が記載され、ソースコードが公開されているため、特許侵害がソースコード上で指摘しやすく、特許侵害の発見が容易である等の指摘がなされています。
OSS を活用する場合、特許権侵害によるリスクを回避するための対応策をとることが必要となります。具体的な対策としては、①OSS について特許調査を実施すること23、②安
全性がある程度実証されているソフトウェアを利用することなどが考えられます。実務上
は、OSS の利用形態、ビジネスの規模などから、コストとリスクを考慮して、どこまでの対策をとるかを検討する必要があります。
３．商標法（１）商標権とは
商標とは、事業者が、自己（自社）の取り扱う商品・役務（サービス）を他人（他社）2223

方式主義。著作権が自動的に発生する（無方式主義）のと異なる。
特許出願から公開まで 18 カ月かかるため、特許権侵害を 100％発見することは不可能である。

15

のものと区別するために使用するマーク（識別標識）やネーミングであり、商品やサービスに付ける「マーク」や「ネーミング」を財産として保護するのが商標権です。
我が国において、商標権については登録制度が採用されており、商標権を取得するためには、特許庁へ商標を出願して商標登録を受けることが必要です。商標登録がなされると、権利者は、指定商品・指定役務について登録商標を独占的に使用することができるようになります。第三者が商標権を侵害した場合、商標権者は侵害行為の差し止め、損害賠償の請求等を行うことができます。なお、商標権の存続期間は設定登録の日から１０年間ですが、１０年の登録期間を何度でも更新することが可能です。
（２）OSS と商標
OSS の名称、マークについても、商標法を考慮し、遵守する必要があります。
自社ソフトウェアを OSS ライセンスで提供する者は、プロジェクトの途中で、名称・マークの変更を余儀なくされることを回避するためには、早期に商標登録することが推奨されます24。
また、OSS を自社ソフトウェアに組み込む者は、コミュニティが OSS の商標の使用等について条件を付している場合、それらを遵守する必要があります。
（作成日：2017 年 12 月 10 日）

24 1995 年、Linux の商標登録をした人物が、Linux の名称を利用している個人と企業に 10％のロイヤルティーを要求したため、Linux 陣営が商標登録の無効を主張して提訴した。リーナス・トーバルズら Linux陣営が Linux の商標を引き継ぐ和解によって終結したが和解条件は公表されていない。

16

Question 基礎-3-2

契約による合意がない場合のベンダの責任

ソフトウェア開発契約において、契約書に別段の合意がない場合、ベンダは納品物に含めた OSS について、民法上、どのような責任を負いますか？

AnswerOSS であるか、あるいは独自に開発したプログラムであるかに関係なく、製品物に対するベンダの責任は同じです。以下に基本的な責任について紹介します。
１．はじめに民法の契約各則においては、売買、請負、準委任等の 13 種類の契約類型（典型契約）が定められ、それぞれの契約類型に適用される条文が規定されています。ソフトウェア開発
契約を解釈する際、上記の中に、その契約があてはまる契約類型がある場合、当該契約において別段の合意25がない限り、その契約類型について民法が規定している条文が当該契約に適用されることになります。ここでは、ソフトウェア開発契約において選択されることの多い「請負契約」、「準委任契約」を中心に、契約で別段の合意がなされていない場合、ベンダが負う民法上の責任について検討します26。
２．請負契約におけるベンダの責任（１）仕事の完成義務
請負契約は、当事者の一方（請負人、ベンダ）が、ある仕事を完成することを約し、相手方（注文主、ユーザ）がその仕事の結果に対してその報酬を支払うことを約する契約です（民 632 条）27。したがって、ベンダは仕事を完成させる義務を負い、ユーザに報酬請求をするための要件として仕事が完成していることが求められます（民 633 条28）29。

25「任意規定」（公の秩序に関しない規定）は当事者の意思によって排除できる。
平成 29 年 5 月 26 日、民法の一部を改正する法律が成立し、一部の規定を除き、平成 32 年 4 月 1 日から施行される（http://www.moj.go.jp/MINJI/minji06_001070000.html）が、本問の記述は上記改正前の民法の規定を前提としている。
27 システムの内部設計やソフトウェア設計など、業務に着手する前の段階でベンダにとって成果物の内容が具体的に特定できる場合は請負契約に馴染むとされる（「情報システム・モデル取引・契約書」（経済産業省）12 頁）。
28 契約上、仕事の目的物を引渡す必要がある場合、報酬請求の要件として引渡しまでが必要とされる（民633 条）。
29 ソフトウェア開発における仕事の「完成」は、建築訴訟の実務と同様、「予定された最後の工程まで一応終了した」といえるか否かによって判断される。そして、「検収の終了」は仕事の完成を認定するための重要なメルクマールとされる（「ソフトウェア開発関係訴訟の手引」判例タイムズ 1349 号 4 頁）
。
26

17

（２）瑕疵担保責任①請負契約において、ベンダの帰責性による債務不履行がある場合、ベンダはユーザに対して債務不履行責任（民 415 条・541 条）を負いますが30、仕事の完成後は、ベンダはもはや債務不履行責任を負わず、目的物（成果物）に瑕疵が存在する場合、ベンダの瑕疵担保責任の問題となります。
②ベンダの瑕疵担保責任
目的物（成果物）に瑕疵がある場合、ベンダは瑕疵担保責任を負います。請負人の瑕疵担保責任は、債務不履行責任と異なり「無過失責任」とされます。ただし、瑕疵がユーザの指示により生じたときは、ベンダは瑕疵担保責任を負いません（民 636 条）。
ⅰ）修補請求、損害賠償請求
瑕疵担保責任に基づき、ユーザは、ベンダに対して、瑕疵の修補請求、及び／又は、損害賠償請求31をすることができます（民 634 条 1 項・2 項）。ただし、瑕疵が重要でな
く修補に過分の費用を要する場合、修補請求は認められません（民 634 条 1 項但書）。
瑕疵の修補が可能である場合でも、修補請求をせず、修補に代わる損害賠償請求をすることもできますが32、瑕疵があっても修補が容易で、これによりユーザに損害が残らなくなるような場合、信義則上、損害賠償請求をする前に修補請求をすべきと考えられます33。仕事が完成している以上、ベンダには報酬請求権がありますが、ユーザの損害賠償請求権とベンダの報酬請求権は同時履行の関係に立ち（民 634 条 2 項後段）、ユーザ
はベンダから瑕疵の修補に代わる損害賠償を受けるまでは、報酬の全額の支払いを拒むことができます34。
ⅱ）契約の解除瑕疵によりユーザが契約の目的を達成することができないときは、ユーザは当該契約を解除することができます（民 635 条）。
ⅲ）権利行使期間
上記の修補請求、損害賠償請求、解除ができる期間は、仕事の目的物を引き渡した時、引渡しを要しない場合は仕事が終了した時から１年以内とされています（民 637 条）35。
30

仕事の完成が納期より遅れた場合（履行遅滞）、仕事の完成が社会通念上不可能になった場合（履行不能）、
ベンダに帰責性（過失）があれば、ユーザはベンダに対する損害賠償請求（履行利益）、及び契約の解除をすることができる。
31 損害賠償の範囲は履行利益（瑕疵により生ずる全損害）とされる。
32 最判昭和 54 年 3 月 20 日判時 1076‐56
33 我妻榮「民法抗議Ⅴ‐2 債権各論中巻二」638 頁
34 最判平成 9 年 2 月 14 日民集 51 巻 2 号 337 頁（もっとも、瑕疵の程度などに鑑み、信義則に反するときは、ユーザによる報酬全額の支払拒否は認めらないとする）
35 平成 29 年 5 月 26 日、民法の一部を改正する法律（以下、民法改正法という）が成立した（一部の規定を除き、平成 32 年 4 月 1 日から施行される）が、同改正により担保責任の規定も変更されている。民法改正法においては「瑕疵」にかわり「契約不適合」との表現が採用され、担保責任がある種の債務不履行責
任として整理された（その結果、売買の瑕疵担保責任が不特定物にも適用されることになる）。これにより、
ソフトウェアに不具合がある場合、完成したか否かを問わず、債務不履行責任が問われることになる（仕18③ソフトウェアの「瑕疵」
ソフトウェアの「瑕疵」は「契約で合意した仕様・性能に仕上がっていない場合」に認められます36。したがって、瑕疵の有無の判断においては、契約で合意された「仕様」が何であるかが重要になります。また、瑕疵があるといえるためには、ユーザ側で、瑕疵現象の原因がベンダの提供したソフトウェアにあること（瑕疵原因）まで立証する必要があります。瑕疵現象の原因がユーザが別途調達したハードウェアの欠陥による場合など、ベンダが提供したソフトウェアにない場合、ベンダが瑕疵担保責任を負うことはありません37。
なお、瑕疵に関して、ユーザから、「システム化すれば実現できたはずのコスト削減ができていないから瑕疵がある」との主張がなされる場合がありますが、これは、瑕疵の問題
としてではなく、ベンダの説明義務38の範囲及び同義務違反の問題として検討すべきと考えられます39。
３．準委任契約におけるベンダの責任（１）準委任契約40は、受任者（ベンダ）が、委任者（ユーザ）のために一定の事務処理行為を行うことを約する契約であり41、当該事務処理行為に対して対価請求権が生じます（民656 条）42。ベンダはユーザの請求があればいつでも事務処理の状況を報告し、また終了の後は遅滞なくその経過及び結果を報告する義務を負います（報告義務。民 656 条・645 条）。
（２）善管注意義務
ベンダは受任者として善管注意義務を負います（民 644 条）。これは、受任者と同様な職
業・地位にある者に対して一般に期待される水準の注意義務とされます。ユーザがベンダ事の完成の前は債務不履行責任であり仕事の完成後は担保責任であるとの整理は維持できなくなる）。また、請負の担保責任の規定が削除され、売買の規定を準用する形となった。債務不履行責任であることから、請負人の帰責事由なく損害賠償請求はできず、この点で従来、瑕疵担保責任が無過失責任とされていることから変更される。
36 ソフトウェア開発においてプログラムにバグが生じることは不可避であるため、検収後、システムを本稼働させる中でバグが発見された場合でも、プログラム納入者が不具合発生の指摘を受けた後、遅滞なく補修を終え又はユーザとの協議の上相当と認める代替措置を講じたときは、右バグの存在をもってプログラムの欠陥（瑕疵）と評価することはできないものとされる（東京地裁平成 9 年 2 月 18 日、ダイセーロジ
スティクス事件）
37 前期「ソフトウェア開発関係訴訟の手引」
38 契約の当事者は、契約の締結に先立ち、当該契約を締結するか否かの判断に影響を及ぼす事情を相手方に説明する信義則上の義務を負うものとされる（最判平成 23 年 4 月 22 日民集 65 巻 3 号 1405 頁）
39 前記「ソフトウェア開発関係訴訟の手引」
40 法律行為を委託する場合が「委任」、法律行為ではない事務を委託する場合が「準委任」であり、委任の規定が準委任に準用される（民 656 条）。システム開発における「コンサルティング」や「技術のＱＡサポート」は、「知識や技術の提供」という事実行為の委託であるため、一般に、準委任契約に分類される。
41 システム外部設計やシステムテスト業務はユーザ側の業務要件に関わる部分が多く（ベンダにとって成果物の内容が具体的に特定できないため）、準委任に馴染むとされる（前記「情報システム・モデル取引・契約書」12 頁）。
42 民法改正案において、（準）委任には、達成された成果に対し報酬が支払われる場合（成果完成型）と事務処理のための労務に対して支払われる場合（履行割合型）の双方があるとの整理がなされている（改正案 648 条 3 項）。

19

の知識・経験に期待して事務処理を委託するソフトウェア開発契約において、善管注意義
務の内容は、「情報処理技術に関する専門的な知識及び経験に基づき、ユーザの作業が円滑かつ適切に行われるよう、調査、分析、整理、提案及び助言などを行う義務」等と規定されます43。ベンダは契約書に定めのないときも同義務を負い（民 644 条）、この義務に違反して、例えば、専門家としてするべき助言をユーザにしなかったことによりプロジェクトが頓挫したような場合、ベンダは債務不履行責任を負う可能性があります。

参考１：売買における瑕疵担保責任
ソフトウェア開発に伴い、ベンダ・ユーザ間でハードウェア等の動産の売買が行われるケースがあるが、売買の目的物に瑕疵がある場合、ベンダは売主の瑕疵担保責任を負い、ユーザは契約の解除（契約目的不達成の場合）、及び／又は、ベンダに対する損害賠償請求をすることができる（民 570 条・566 条）。売買の場合は請負の場合と異なり「隠れた瑕疵」（取引で要求される
通常の注意を払っても発見できない瑕疵）である必要があり、通説の理解では、不特定物には適用されず、損害賠償が認められるのは信頼利益44に限られる。権利行使の期間は瑕疵を知った時から１年である。商人間の売買ではユーザは検査通知義務を果たさなければ解除や損害賠償請求をすることができない（商法 526 条）。

参考２：ベンダのプロジェクト・マネジメント義務
ソフトウェア開発においては、ベンダの IT に関する専門性のみならず、ユーザの業務に関する専門性も必要であるとの特色（二重の専門性の存在45）から、ソフトウェア開発に関する当事者双方の協力は、法的義務のレベルまで高められ、具体的には、主たる義務に付随的な信義則上の義務として、ベンダには「プロジェクト・マネジメント義務」が、ユーザには「協力義務」が課されているとされる46。ベンダの「プロジェクト・マネジメント義務」は具体的な義務内容が一義的に決まっているわけではないが、「プロジェクトの進捗状況を管理し、開発作業を阻害する要因の発見に努め、これに適切に対処する義務」「ユーザの開発へのかかわりについて適切に管理する義務」などとされる（東京地裁平成 16 年 3 月 10 日／東京土建国民健康組合事件）。ベ
ンダは契約書に別段の定めのない場合でも、個別案件の事情に応じ、この「プロジェクト・マネ
ジメント義務」を負うものと考えられる。

（作成日：2017 年 12 月 10 日）

43

前記「情報システム・モデル取引・契約書」69 頁

44 「信頼利益」とは、契約が無効である場合に、その契約が有効と信じたために生じた損害をいい、契約締結のために費やした費用などがこれにあたる。
45 前期「ソフトウェア開発関係訴訟の手引」
46 「裁判例から考えるシステム開発紛争の法律実務」（桃尾・松尾・難波法律事務所）96 頁～

20

Question 基礎-3-3

OSS の輸出管理に関して遵守すべき法令

OSS の輸出管理に関して、どのような法令を検討し遵守すべきですか？

Answer
１．安全保障貿易管理
安全保障貿易管理とは、武器そのものの他、軍事的に転用されるおそれのある物・技術が、大量破壊兵器の開発者やテロリスト集団などに渡らないように輸出規制を行うことをいいます。この安全保障貿易管理は、国際的な平和及び安全を維持するための手段の一つであり、日本を含む国際社会が一体となって安全保障貿易管理に取り組んでいます（国際
輸出管理レジーム47）。
２．日本の輸出規制（外為法）（１）外為法による規制
我が国においては、外国為替及び外国貿易法（以下、「外為法」）に基づき輸出規制が行
われています。外為法には、「リスト規制」と「キャッチオール規制」という２種類の規制が定められており、いずれかの規制に該当する輸出には、事前の許可48が必要となります。
リスト規制は、軍事転用の可能性が特に高い貨物・技術について、提供先がいずれの国であっても事前の許可を必要とする規制です。キャッチオール規制は、リスト規制に該当しない貨物・技術の輸出に対して、その用途や需要者に兵器の開発に関する懸念がある場
合に事前の許可を必要とする規制（補完的輸出規制）です。輸出管理の手順としては、まずリスト規制該当性を判断し、リスト規制に該当しない場合、キャッチオール規制該当性を判断するという流れになります。
また、外為法は、貨物の輸出だけではなく、技術（プログラムを含む）の提供もその規制対象としています。技術提供の場合、例えば、「非居住者」と整理される留学生や研究者、一時帰国中の日本人などへの規制技術の提供のケースなど、国内での技術提供でも許可が必要となる場合があるため注意が必要です4950。

47

原子力供給国会合（NSG）、オーストラリアグループ（AG）、MTCR（ミサイル関連機材・技術輸出規制）、ワッセナーアレンジメント（WA）を包括した枠組み
48 外為法に基づく経済産業大臣の許可
49 https://www.mof.go.jp/about_mof/act/kokuji_tsuutatsu/tsuutatsu/TU-19801129-4672-15.pdf（財務省通達「外国為替法令の解釈及び運用について」）
50 http://www.meti.go.jp/policy/anpo/qanda25.html（経済産業省「安全保障貿易管理・技術関連 Q&A」）

21

（２）リスト規制
リスト規制の対象品目は、外為法に基づいて定められた政令以下に定められています。
すなわち、リスト規制対象貨物のリストは輸出管理貿易令（以下、「輸出令」）別表第１，
第１～１５項に、同対象技術のリストは外国為替令（以下、「外為令」）別表第１～１５項にそれぞれ定められ、これらの具体的なスペックは貨物等省令51に定められています。
リスト規制に関する確認としては、まず輸出しようとする貨物・提供しようとする 技
術のスペックが上記に該当するか否かの判断（該非判定）を行い、該当する場合、次に、「例外規定」52の適用可否を判断するという流れになります。
該非判定の結果、リスト規制に該当し、例外規定の適用がない場合、事前の許可が必要となります。
（３）キャッチオール規制
キャッチオール規制対象貨物は、輸出令別表第１，第１６項に、同規制対象技術は、外為令別表第１６項にそれぞれ定められ、これらの具体的なスペックは、貨物等省が定めています。キャッチオール規制は、「大量破壊兵器キャッチオール」と「通常兵器キャッチオール」の２種類からなり、客観要件53とインフォーム要件54の２つの要件により規制されています。客観要件、インフォーム要件のどちらかに該当する場合には、事前の許可が必要となります。なお、いずれの場合も、「ホワイト国55」向けの貨物輸出・技術提供は、キャッチオール規制の対象外です。56

法律

貨物

外為法第 48 条

政令

省令

通達

（品目を規定）（ｽﾍﾟｯｸを規定）（用語の解釈等）

輸出令別表第 1

貨物等省令

運用通達

貨物等省令

役務通達

リスト規制：1～15 項
キャッチオール規制：16 項
技術

外為法第 25 条

外為令別表
リスト規制：1～15 項
キャッチオール規制：16 項

51

輸出貿易管理令別表第一及び外国為替令別表の規定に基づき貨物又は技術を定める省令
規制の対象となる貨物・技術であっても一定の要件を満たす場合に許可を不要とするもの。貨物に関しては少額特例、無償特例等があり、技術に関しては、貿易外省令第 9 条が定める。
53 用途（用途要件）及び需要者（需要者要件）から大量破壊兵器や通常兵器の開発に使用されるおそれがあるかを判断するもの。
54 経済産業大臣から許可申請すべき旨の通知（インフォーム通知）を受けている場合に許可申請が必要となるもの。
55 輸出令別表第 3 の地域（アメリカ、イギリス、韓国など 27 ヵ国）
56 安全保障貿易管理ハンドブック（経済産業省）P12（キャッチオール規制確認フロー図）参照
http://www.meti.go.jp/policy/anpo/seminer/shiryo/handbook.pdf
52

22

（４）外為法違反に対する制裁など
外為法違反に対しては、①1000 万円以下または対象となる貨物や技術の価格の 5 倍以下の罰金、10 年以下の懲役、②3 年以内の貨物の輸出・技術の提供の禁止、③違反の事実の
経済産業省からの公表などの制裁が定められています。
また、平成２１年４月の外為法改正により、業として輸出・技術提供を行う事業者が従うべき基準として「輸出者等遵守基準」が定められました57。事業者は同基準によって外為法を遵守し、関係法令の改正等にも適切に対処していくことが必要です58。
（５）OSS の輸出管理プログラム（ソフトウェア）の輸出は、外為法上、技術の提供として規制されていますが、OSS に対する規制は、一般のプログラムに対する規制より緩やかであるといえます。
すなわち、規制の例外として、「公知の技術を提供する取引」については、経済産業大臣の許可を受けないで取引をすることができるものとされているおり、「公知の技術を提供する取引」の一つとして「ソースコードが公開されているプログラムを提供する取引」が挙げられています。OSS はこれに該当するものとして輸出の際、事前の許可が不要です（外為法 25 条、外為令 17 条 5 項・同 1 項～3 項、貿易外省令 9 条 2 項 9 号ニ）。
もっとも、①OSS を改変し、改変部分のソースコードを提供しない場合（提供が求められないライセンスによる）、②改変した OSS を社内で内部利用する範囲で非居住者へ提供
し、改変後のソースコードを公開しない場合59等は、上記「公知の技術」として扱えないので、原則通り、リスト規制、キャッチオール規制の該当性を確認することが必要です。
３．米国の輸出規制（EAA，EAR）（１） 米国輸出管理法の「再輸出規制」
安全保障に関する各国の輸出管理法規は、通常、その国から輸出される取引についてのみ適用されます。ところが、米国輸出規制の中核となる米国輸出管理法は、「再輸出規制」という形で、米国の主権または管轄権の及ばない他国での取引にも米国の国内法を適用す
る域外規制を行っています。この米国再輸出規制とは、具体的には、米国原産品等60について、当初、米国から輸出・提供される時だけではなく、その後のすべての再輸出取引に対しても、米国法による規制が適用されることをいいます。
したがって、米国製の OSS の取引に関しては、米国輸出管理法についても検討し遵守す

57

輸出者等が遵守すべき具体的な内容は「輸出者等遵守基準を定める省令」が定める。
「安全保障貿易管理
ハンドブック」P8 参照。http://www.meti.go.jp/policy/anpo/seminer/shiryo/handbook.pdf
58 http://www.meti.go.jp/policy/anpo/law09.html 経産省「安全保障貿易管理」関連法令・改正情報59 技術提供の場合、貨物と異なり、国内にいる非居住者への技術研修なども輸出規制の対象
60 EAR の対象品目は「米国内の全ての品目」（米国からの輸出規制の対象）のほか、再輸出規制の対象となる「全ての米国原産品（現所在地を問わない）」、「外国製品で特定の割合を超えて米国規制品目が含まれている製品（組込み品）、「外国製品で特定の米国規制技術が使用されている製品」（直接製品）等（EAR Part734.3 ITEMS SUBJECT TO THE EAR）

23

る必要があります。
（２）米国再輸出規制の根拠法
米国の安全保障輸出管理は規制品目によって管轄が異なりますが61、日本の企業の多くがフォローする必要があるのは、米国商務省の産業安全保障局（BIS）が管轄する米国輸出管理法（EAA：Export Administration Act）とその規則である米国輸出管理規則（EAR：Export
Administration Regulations）です。EAA は、一般の民生用途品目（軍用・民生用である
デュアルユース品を含む）の輸出及び再輸出を対象としています。なお、EAA は 2001 年に失効し、現在（2017 年 10 月）も失効中ですが、国際緊急経済権限法（IEEPA）により、
EAA の規則である EAR によって米国の輸出管理が行われています。
（３）米国製品を再輸出する際の確認の流れ
米国製品を再輸出する際の確認のおおまかな流れは次のようになります。
①

再輸出しようとする品目に ECCN（Export Control Classification Number、規制品目番号）62が振られているかどうかを調べる。

②

規制理由、規制レベルを調べる（Supplement No.1 to Part774）。

③

カントリーチャート63を調べる（Supplement No.1 to Part738）。

④

許可例外（LE：License Exception）64の適用可否を調べる。

カントリーチャート又は許可例外の適用により許可不要（NLR：No License Required）
65とされる場合以外は、許可申請をする必要があります。

（４）違反に対する制裁
米国輸出管理法に違反した場合、罰金、禁固という刑罰のほか、取引禁止顧客（Denied
Persons）としての指定、米国政府調達からの除外等の制裁が課されます。そして、ある企業が取引禁止顧客リスト（DPL：Denied Persons List）に掲載され取引禁止顧客として公表された場合、その企業が EAR 対象品目を輸出・再輸出することが禁止されるほか、米国
および米国以外の国から EAR 対象品目の輸出・再輸出を受けることもできなくなりますので、米国製品の取引を扱う企業にとって、非常に深刻な影響が生じます。
（５）米国輸出規制に対する対応、情報窓口
したがって、米国製品を取り扱う企業としては、米国輸出規制を理解するスタッフの育61

日本と異なり米国の場合は、複数の政府機関が数種類の異なった輸出管理を行っており、EAR を管轄す
る米国商務省の他に、国務省、エネルギー省、財務省が担当している。
62 EAR の規制品目リスト（CCL：Commercial Control List）に記載されている品目分類番号）
63 EAR Part738 Supplement No.1 に記載されている表。仕向地と規制理由・レベルで輸出許可の要否を規定している。×がなければ許可不要である。
64 LVS:Shipments of Limited Value（少額特例）等
65 NLR と判断した根拠資料について 5 年間の保管義務がある。

24

成、コンプライアンスプログラムの作成等を図ることが必要です。
米国輸出規制に関する情報の窓口としては次のような組織・機関があり、これらの WEB
サイトやセミナーを活用することができます。
①

米国商務省安全保障局（BIS）http://www.bis.doc.gov/②

米国大使館商務部 http://www.buyusa.gov/japan/services/③

一般財団法人安全保障貿易情報センター（CISTEC）http://www.cistec.or.jp/④

日本機械輸出組合（JMC）http://www.jmcti.org/（６）米国製 OSS の再輸出管理①暗号を含まない場合
米国再輸出規制によって、米国製 OSS を利用する企業は EAR についても検討し遵守する必要があります。もっとも、外為法と同様、EAR においても、OSS に関しては規制が緩和されています。すなわち、OSS は、「一般に入手可能な技術及びソフトウェア（ECCN 5D002 に分類されるソフトウェアを除く）」であり、且つ、「すでに公開されているか公開されようとしているもの」として、EAR の対象外とされています6667②暗号を含む場合
OSS のなかでも、「暗号ソースコード」（ECCN 5D002）に分類されるソフトウェアについては、従前、EAR の規制対象とされていましたが、2016 年 9 月の改正により、同ソフトウェアについても、EAR の規制対象外とされました68。
（作成日：2018 年 2 月 19 日）

EAR Part734.3 ITEMS SUBJECT TO THE EAR (b)(3)(1)
Supplement No.1 to Part734 Q&A には次の記載がある。”If the source code of a software program is
publicly available, then the machine readable code compiled from the source code is software that is
publicly available and therefore not subject to the EAR.”（ソフトウェアプログラムのソースコードが一般に入手可能な場合、ソースコードからコンパイルされた機械可読コードは一般に入手可能なソフト
ウェアであり、したがって EAR の対象とはなりません）
68 但し、通知要件を満たす必要があるものとされています。
66
67

25

A．関係する者の立場の違いからの視点
１．OSS を自社ソフトウェアに組み込む場合
２．自社ソフトウェアを OSS 化して提供する場合
３．OSS ソフトウェアを利用する
４．クラウドサービスの利用

26

Question A-1-1

なライセンス

自社製品に OSS を組み込んで利用する場合、どのような判断基準で、どのようなライセンスの OSS を選択すべきか。

自社製品に OSS を組み込んで利用する場合、どのようなライセンスを選択するか。ライセ
ンスを選択する判断基準や考慮すべき要素、注意点を教えてください。

Answer１．自社製品の類型
企業が自社製品に OSS を利用する場合としては、次のような類型があり、それぞれについて、OSS をそのまま利用する場合と改変する場合があります69。
(a) ソフトウェア製品の一部に OSS を利用し、ユーザに配布（distribution）する場合。
(b) ハードウェア製品に OSS を利用したソフトウェアを組み込んで、ユーザに配布する
場合（distributing software as a product）。
(c) 自社内に設置したシステムに OSS を利用して、ユーザに対してクラウド･サービスを提供する場合（Software as a service）70。
(d) 自社内に設置したシステムに OSS を利用して、社内のみで利用する場合（forinternal purpose only）。
(e) ベンダとして第三者（ユーザ）から受託したシステム開発において、OSS を利用して開発し、成果物を注文主（ユーザ）に納入する場合71。
この Q&A では、OSS を配布する行為によってライセンス条件に基づく義務を負うことに注意を要する(a)と(b)について解説します。
２．OSS 利用ポリシー（１）自社製品への OSS 組込み
OSS にはメリットとデメリットがあり72、自社製品に OSS を組み込んで利用する企業は、
そもそも自社開発プログラムではなく OSS を自社製品に組みこむことを選択するか否か、
OSS を選択する場合の判断基準や品質保証プロセスなどについて、社内規程（OSS 利用ポリシー）で定めておくことが望ましいでしょう73。
See Noam Shemtov=Ian Walden, Free and Open Source Software: Policy, Law, and Practice, Oxford
Univ Pr (2014) P.74 §8.3.3.
70 Affero-GPL では、ネットワーク経由の利用者にもソースコードを提供すル義務があることに注意を要します。http://choosealicense.com/licenses/agpl-3.0/
71 本書「C-2-1」参照。
72 本書「A-3」参照。
73 本書「B-2」社団法人情報サービス産業協会「オープンソースビジネスに取り組む SI 企業のための企業
69

27

（２）主なライセンスの種類74
主要なライセンス条件
OSS ライセンスの 著 作 権 ラ イ セ ン
種類（例）OSS（改変部 結 合 す る

特許権の

保証免責

表示

スの承継

分を含む）の 他 コ ー ド

行 使 制 限 責任制限

義務

（同一条

ソースコー への伝搬

等件で配布） ド提供義務
有有有性（注 1） （注 2）
有

GPLv3

必須特許

無保証で

許諾。差別 配布する
的ライセ
ンス禁止

GPLv2

有

有

有

有

有

LGPLv2.01

無

明文なし

同上

明文なし

同上

ソース開

同上

（注 3）

（ライブラリ用）
Mozilla Public

有

有

有

無

示で権利

License v.1.1,

不行使約

v.2.0

束
有

無

有

無

必須特許

同上

許諾。特許
Apache Ver.2.0

ライセン
ス終了条
件

修正版 BSD

有

有

無

無

明文なし

同上

MIT License
有
有
無
無
明文なし
同上
（注 1）
「伝搬性」とは、ある OSS と一体化したソフトウェア全体（OSS の派生物）に対して、
ソースコードの公開等、OSS ライセンス（許諾条件）が適用されることです75。
（注 2）「特許権の行使制限」には、①OSS の貢献者（作者）や配布者が OSS を配布する相手方（下流のユーザ）に対する「特許ライセンス義務」と、②OSS のライセンサーやコン
トリビュータに対して特許権を行使すると、自己に対する当該 OSS に実施されている特許ライセンスが自動的に消滅しまたは解除される「特許ライセンス終了条件」があります。
（注 3）LGPLv2.1 は、リンクによる自社開発プログラムへの伝搬性はありませんが、ユーザ自身の利用のための著作物の改変を許可し、その改変をデバッグするためのリバースエンジ
ニアリングを許可しなければなりません（LGPLv2.1 第 6 条）
。数字のパラメタやデータ構造のレイアウト、アクセス機構または小さなマクロや小さなインライン関数(長さが 10
行かそれ以下)のみ利用するならば、そのオブジェクトファイルの利用は制限されないとされています（LGPLv2.1 第 5 条）。
ポリシー策定ガイドライン」（平成 17 年）参照。http://www.jisa.or.jp/Portals/0/report/16-J013.pdf
74 主な OSS ライセンスの種類について、BLACKDUCK, Top 20 Open Source Software Licenses, (2016)参照。https://www.blackducksoftware.com/top-open-source-licenses
75 伝搬性について、独立行政法人情報処理推進機構『ビジネスユースにおけるオープンソースソフトウェ
アの法的リスクに関する調査』（平成 17 年 2 月）23 頁および本書「D-3-1」以下参照。

28

（３）ライセンス選択の判断基準
自社製品に OSS を組み込む場合、自社が秘匿したい技術については、ソースコード提供義務を負わない OSS ライセンスを選択し、GPL が適用される OSS の利用を差し控えるか、または GPL が伝搬しない設計手法を採用すべきでしょう（技術流出の回避）。また、自社の特許権を行使する予定がある技術領域については、OSS を利用する前に、特許権による期待収益と OSS 利用によるメリットを比較考量して、OSS の採否を判断する必要があります76。
（４）両立性
複数の異なるライセンス条件が適用される OSS を同一のソフトウェアに組み込む場合、ライセンスの両立性（License compatibility）に注意し、一方の条件を遵守すると、他方のOSS の条件を遵守できないような、ライセンス条件の矛盾によって共存できないライセンスに注意を要します77。
（５）複数ライセンスを適用するマルチライセンスの選択
複数のライセンスから利用者が選択できる OSS もあります。デュアルライセンスまたは
マルチライセンスは、
複数の異なるライセンス条件で配布されている OSS であり、
例えば、商用か非商用（学術研究）などの利用形態によって適用されるライセンス条件が異なる場
合と、利用者が複数のライセンス条件から自由に選択できる場合があります78。
３．GPL を選択した場合の注意点（１）ライセンス条件の義務の遵守
自社製品に組み込んだ OSS をリスト化し、著作権表示、ライセンス条件を記載した文書
および OSS の保証免責文言の添付、提供すべきソースコードの特定と複製物の保存など、ライセンス条件を遵守することが必要です79。
（２）ソースコードの提供80
第一に、OSS を配布するか否かを判断します。第二に、GPL が適用される OSS と組み合わせる自社開発プログラムに GPL が伝搬して、自社開発プログラムについても GPL が適用されてソースコード提供義務を負うか否かを判断し、提供義務を負うソースコードを漏れなく提供できるようにしなければなりません。
76

特許条項について、本書「F-1-1」参照。
両立するライセンスの組合せについて、FSF「さまざまなライセンスとそれらについての解説」
https://www.gnu.org/licenses/license-list.html 参照。
78 例えば、MySQL は GPL とコマーシャルライセンスのデュアルライセンス方式で提供されている。
79 OSS ライセンス条件に違反した場合の問題について、本書「G-1」以下参照。ライセンス表示チャソー
スコード提供の留意点について、本書「D-1」参照。
80 GPL の伝搬性の判断基準について、本書「D-3-1」以下参照。
77

29

（３）OSS 開発コミュニティへの積極的な貢献
OSS のバグ修正版（パッチ）については、改変したソースコードを OSS コミュニティに積極的に還元しないと、次回の OSS のバージョン･アップのときに、そのバグが修正されずにリリースされて、バグ修正が二度手間になり、かつ、そのバグ修正によって他のソフ
トウェアの機能に悪影響が及ぶ可能性があります81。したがって、各企業の技術情報開示に関する方針や社内承認手続きがあるとは思いますが、OSS のバグを修正したプログラムについては、積極的にコミュニティに提供することも検討すべきでしょう。
（４） GPLv3 におけるインストール情報の提供
GPLv3 第 6 条は、変更したソフトウェアをデバイスにインストールするために、GPLv3が適用されるプログラムを組み込んだユーザ製品（消費者用の製品）を販売する場合、ソースコードだけでなく、OSS のインストール用情報（改変バージョンのインストール及び実行に必要な手法、手順、認証キー及びその他の情報のすべて）をユーザの求めに応じて開示する義務を利用者（ディストリビューター）に課しています82。ただし、ソフトウェア
が ROM にインストールされていれば、インストール情報の開示義務はないと明示されています。また、改変された場合、メーカが当該デバイスの保証責任を負わないでよく、ネッ
トワークに障害が出る改変については、ネットワークへの接続を拒否してよいとされています。
ユーザに OSS のインストール情報を開示し、製品に組み込まれたソフトウェアをユーザが改変する行為を許可した場合、製品の性能、品質または通常有すべき安全性に影響が及ぶ可能性を否定できません83。したがって、ハードウェア組込みソフトに関して、企業によっては、予見不能な障害の発生等を懸念して、GPLv3 の利用を差し控えることもあるようです。
（作成日：2017 年 1 月 20 日）

See Supra note (1) P.290 §8.2.7.
See Brett Smith, A Quick Guide to GPLv3, Free Software Foundation, Inc (2007) P.3.
https://www.gnu.org/licenses/quick-guide-gplv3.pdf
GNU GENERAL PUBLIC LICENSE Version 3 ( 29 June 2007) https://www.gnu.org/licenses/gpl.html
83 製造物責任については、本書「C-1」参照。
81
82

30

Question
A-1-2
にの
センス

自社製品に OSS を組み込んで利用する場合、ユーザに提供すべき情報

自社製品に OSS を組み込んでユーザに配布する場合、ユーザに対してどのような情報を提供する必要がありますか？
また、請負人が、注文主からの受託開発の納品物に GPL が適用される OSS を利用する場
合、注文主に対してどのような情報を提供する必要がありますか？

Answer
１．提供する情報
自社製品に OSS を組み込んでユーザに配布する場合、OSS を特定するための情報に加えて、OSS ライセンス条件に従った情報を提供する必要があります。ほぼ全ての OSS において必要な情報は、次のとおりです。
①

利用している OSS の名称とバージョンの情報（対象の特定）②

OSS に添付されているライセンス条件と同一のライセンス文書③

無保証であること（免責条項）の表示④

配布する OSS の著作権表示（記載されていた著作権表示を削除しない）

その他、個々の OSS のライセンス条件で定められた情報を提供する必要があります。
（例）⑤

OSS を改変した場合には、改変の事実と改変者の名前

⑥

謝辞の記載

⑦

GPL の場合は、ソースコードを提供すること等

なお、GPL については、特に注意を要するので、第 3 項以下で GPL プログラムに関する注意事項について解説します。
２．著作権表示
著作権表示が必要とされる法的理由は、次のとおりです。
（１）ライセンス条件としての著作権表示
著作物である OSS の利用許諾（ライセンス）を受ける条件として、配布する OSS に著
作権表示が求められている場合、その条件に従って OSS を利用することが必要です84。OSSのライセンス条件を遵守せずに、著作権に基づく行為（例えば、複製、翻案、複製物の譲渡、公衆送信など）をするならば、著作権侵害になります。
表示方法としては、OSS のソースコードのコメント行に記載された著作権表示（ソース84Open source Initiative, Frequently Answered Questions 参照。https://opensource.org/faq

31

コードを配布すれば表示したことになるでしょう）や、README ファイル等に記載されている表示をそのまま表示して、OSS を配布すればよいのです。バイナリコードでのみの配布で、ソースコードを配布しない場合は、ドキュメント等に表示することになります。
BSD ライセンスや MIT ライセンスが適用された OSS の場合、これらのライセンスは、
いわゆる「テンプレートライセンス」であり、それらの先頭にある著作権表示に実際の著作者名などを埋めることにより、OSS の適切な著作権表示が完成します。なお、ライセン
ス文書の言語は、原文（英語ならば日本語に翻訳せずに英語）で表示します85。
（２）著作者人格権としての著作者表示
著作権表示がライセンス条件になっていない場合であっても、著作権法に基づいて、著
作者の氏名を表示することが求められる国があり、日本はその一つです。著作者には、氏名表示権（著作物の公表に際し、著作者の実名もしくは変名を著作者名として表示、または著作者名を表示しないこととする権利。著作権法 19 条）があるので、著作物である OSSに表示された著作者の氏名を勝手に削除、改変することは、著作者人格権侵害になります86。
特に契約がないときは、その著作物にて既に表示されている方法で表示すればよいことになっていますから（19 条 2 項）、OSS を配布する場合には、OSS に表示されていた著作者表示をそのまま表示します87。OSS を受領した時点で何も著作権表示がなければ、そのま
ま何も表示しません。
例外的に、著作物の利用の目的および態様に照らし、著作者が創作者であることを主張する利益を害するおそれがないときは、公正な慣行に反しない限り、著作者の表示を省略することができます（19 条 3 項）
。例えば、大きなモジュール内の個々のサブルーチンやライブラリについて数千個の表示をドキュメントに並べるというのは現実的ではありません。
入手した OSS のバイナリコード内に個々のサブルーチンの著作者の氏名が表示されていな
い場合、（OSS を利用する企業のリスク判断になりますけれども）それに倣うか、またはソースコード（著作権表示が書かれているもの）を配布することも一つの選択肢です。
（３）著作財産権としての著作権表示
万国著作権条約加盟国 3 条 1 項に基づく著作権表示として、著作物の保護要件を充たすために次の 3 つの表示が必要とされています88。
①©（丸の中に C、丸 C、マルシー）の記号（symbol ©）。

IPA 技術本部国際標準推進センターリーガル WG 委員「OSS ライセンスの良くある質問」（2011 年 11
月 16 日）7-11 頁参照。http://www.ipa.go.jp/files/000028284.pdf
86 中山信弘『著作権法』（有斐閣、第 2 版、2014 年）489～493 頁参照。
87 情報処理振興事業協会（IPA）「オープンソース・ソフトウェアの現状と今後の課題について」（2004 年）
75 頁参照。なお、日本で著作者人格権を行使する場合、著作者表示をしておくと著作者であることの推定を得られるので（著作権法 14 条）、表示する意義もあります。
88 万国著作権条約パリ改正条約参照。http://www.cric.or.jp/db/treaty/bap_index.html
また、米国著作権法第 401 条にも著作権表示の方法についての定めがある。
http://www.cric.or.jp/db/world/america/america_c4.html
8532

② 著作権者の氏名。複数の著作権者がいる場合は、全ての著作権者の名を書くことになっています。
③ 最初の発行の年。複数のバージョンがある著作物は最初のバージョンの最初の発行年と最新版の発行年を「2015 年－2017 年」のように表示することが慣行です。
一般的に、著作権表示の方式としては、この表示に従って、次のような表示がよく見られます。
〔Copyright © SOFTIC 2017-2020 All Rights Reserved〕
現在、ほとんどの国がベルヌ条約に加盟しており89、著作物を著作もしくは発表した時点
で自動的に著作権が発生し、何らの方式または手続の履行を要求しない「無方式主義」が採用されていますので、著作権表示は法的保護を受けるための要件ではありません90。
３．GPL プログラムに関する注意事項（１）GPL のライセンス条件、著作権表示およびライセンス条件の表示①GPL のライセンス条件
GPL プログラムを利用して配布する企業がユーザに提供すべき情報に関して、GPL のライセンス条件は、著作権表示、ライセンス文書の提供、GPL プログラム、その改変および伝搬するプログラムのソースコードの提供を求めています91。
②OSS の特定
先ず、OSS の名称とバージョンを正確に特定しなければなりません。企業が、過去の資産を再利用する場合、ダウンロードした時点のコードと再利用する時点における最新版のコードは、必ずしも同一のコードとは限りません。したがって、ダウンロードした Web
サイトの URL と日時とバージョンを記録して、後日、実際に配布したプログラムのバー
ションとライセンス条件を再確認できるようにしておくことが大切です。また、実際に配布したコードと同一のソースコードを保存しておき、バグ修補等できるようにしておくことが必要です。

89

文学的及び美術的著作物の保護に関するベルヌ条約。http://www.cric.or.jp/db/treaty/t1_index.html
米国著作権法第 405 条(b)項は、「著作権表示が欠落し、かつ、1988 年ベルヌ条約施行法の発効日より前に著作権者の権限により公に頒布された適法なコピーまたはレコードに依拠して、善意で著作権を侵害する者は、表示の欠落によって錯誤を生じたことを証明する場合には、第 408 条に基づく著作物のための登録が行われたことの現実の通知を受領する前に行われた侵害行為につき第 504 条に基づく現実損害賠償または法定損害賠償の責任を負わない。かかる場合の侵害訴訟においては、裁判所は、侵害により侵害者が受けた利益の賠償を認定しまたは否定することができ、また、侵害にあたる活動の継続を差し止めまたは侵害にあたる活動の継続を許可する条件として著作権者に対して裁判所が定める金額および条件の下に相当な使用料を支払うことを義務づけることができる。
」と定めている。
91 財団法人ソフトウェア情報センター「オープンソースソフトウェアライセンスの最新動向に関する調査報告書」（平成 19 年 11 月 16 日）、情報処理推進機構（旧称：情報処理振興事業協会）「オープン・ソース・
ソフトウェアの現状と今後の課題について」（2004 年 10 月）52 頁乃至 60 頁参照。
90

33

③著作権表示92
著作権表示は、ソースコードのコメント行、ライセンス条項を記載したテキスト、プ
ログラムとともに配布される README ファイル、取扱説明書などに書かれています。
この著作権表示を削除せずにそのまま残し、または変更することなく転記して、ユーザに情報を提供します。なお、企業が自ら OSS を改変して配布する場合には、自社が改変したコードについての著作権表示を追加することもできます。
④GPL の文書および保証免責
自社が配布する OSS と一緒に GPL の文書をそのまま（As Is）で転載します（言語も英語のままとし、翻訳しません）。GPL の文書を転載する方法は、OSS プログラムのREADME ファイルや LICENSE ファイル等の電子的記録でもよく、OSS とともに配布する取扱説明書等の書面であっても差し支えありません。
GPL を文書で添付する代りに、OSS を配布したライセンサーの WEB サイトの URLを記載している事例を見かけます。しかし、ライセンサーが URL やライセンス条件を変更することがありますから、OSS をダウンロードした時点で GPL の文書を複製し、電子的にアーカイブをとっておいて、自社の Web サイトにて自社製品で利用する OSS の情報と共に掲載するか、または提供する自社製品に GPL の文書を転載したファイルを添付することを推奨します。
（２）ソースコードの提供①提供方法
ソースコードの提供方法については、GPLv2 と GPLv3 でその条件が異なるので注意を要します93。GPL 違反を主張される係争事件が発生するリスクが高い行為の事例は、
このソースコード提供義務違反です。提供方法の選択肢を次頁に 3 つ示します94。
ソースコードの提供方法については、ユーザが企業か個人か、ソフトウェアが汎用パッ
ケージ･ソフトウェアか個別の受託開発ソフトウェアかといった違いによって、それぞれに適した提供方法を選択することになるものと考えられます。

92

オープン・ソース・ソフトウェアの著作権は、創作によって発生する無方式主義 （文学的及び美術的著作物の保護に関するベルヌ条約パリ改正条約第五条）で発生する。著作権者として表示した者は、権利者の推定を得られる （日本国著作権法第十四条）。
「(C)の記号、著作権者の名及び最初の発行の年」を表示することを保護の要件とする条約がある （万国著作権条約パリ改正条約第三条）ただし、現在は、ベルヌ条約批准国が多く、ほとんど関係がない。アメリカ合衆国では、1988 年（ベルヌ条約発効年）以前の著作物について、著作権表示を欠く場合、善意の侵害者に対する損害賠償責任を制限している。
93 GPL プログラムのソースコード提供に関する FAQ について、Free Software Foundation, Inc.「GNUライセンスに関してよく聞かれる質問」（2016）参照。
https://www.gnu.org/licenses/gpl-faq.ja.html#DistributeWithSourceOnInternet
94 独立行政法人情報処理推進機構「GPLv3 逐条解説」第 1 版（2009 年 4 月）66 頁には、5 種のオブジェ
クトコード配布法と対応するソースコードの配布法がまとめられている。なお、OSS 配布時にソースコー
ドを提供するのではなく、要求に応じてソースコードを提供することと連絡先、入手方法等を記載した書面のみを交付し、個別に対応する方法も考えられる。

34

提供方法
1

メリット

デメリット

CD-ROM 等の媒体にソー No.2 のようなソースコー CD-ROM 等の媒体を追加すスコードを記録し、製品に ド提供要求に対して、個別 る場合には、コストが増加す
添付して配布する。

に 対応す る体制 が要らな る。
い。

2

要求に応じてソースコー ソースコードの提供を求め 対応窓口を設置し、個別に対ドを提供する。なお、GPL た 者を特 定する ことがで 応する体制を維持する必要
v2 の場合、要求があれば き、要求が少なければ、製 がある。
媒体での提供も必要であ 品に添付する方法よりもコる95。

3

ストが安い。

WEB サイトにソースコー 配 布する ソフト ウェアが 公衆がアクセス可能な WEB
ドをダウンロード可能な WEB サイトからダウンロ サイトに掲載する場合、誰で状態で掲載する96。

ードするタイプの場合、同 も自由に閲覧およびダウン
じサイトからソースコード ロード可能になるので、係争をダウンロードさせれば足 事件の証拠収集に使われるり、手間がかからない。

リスクもある。製品に ID とパスワードをつけてユーザ
のみがダウンロード可能にする方法もある。

②GPL プログラムの改変の有無と伝搬i) GPL プログラムの OSS を改変することなく配布する場合、当該 OSS を配布する者は配布先に対し、オリジナルの OSS のソースコードを提供しなければなりません。
ii) GPL プログラムの OSS を改変して配布する場合、当該 OSS を配布する者は配布先に対し、改変したソースコードも提供しなければなりません。
iii) GPL が適用される OSS が自社開発プログラムに伝搬する場合、当該 OSS を配布する
者は配布先に対し、自社開発プログラムのソースコードも提供しなければなりません。

95

この場合、最低３年間、かつ、該当製品モデルのスペアパーツ又はカスタマーサポートを提供している
限りは、この提供が必要とされる（GPL v3 第 6 項 b）
。https://www.gnu.org/licenses/gpl-3.0.ja.html
なお、GPLv2 第 3 項 b）では最低 3 年間とされている）。https://www.gnu.org/licenses/gpl.html
このような提供期限を明記していないライセンスもあり、
また、FAQ 等に明示されていない場合もあるが、それらのライセンスも合理的に不可能であろう行為までを要求するとは考え難いので、ソフトウェア製品
を実際に配布する期間（例えば、製造終了から 3 年程度）を目処と考えておけば、紛争に発展する可能性が低いのではないだろうか。
96 GPL は、WEB サイトにソースコードをダウンロード可能な状態で掲載する方法に関しては、いつまで同 URL をアクセス可能としておかなければならないかについて、明示の規定を置いていない。しかしながら、ソースコード提供の申出の有効期間が限られていることに鑑みれば（GPLv2 第 3 条 b）
、申出の有効期間と同一の期間、アクセス可能にしていれば足りると考えることもできるが、（注 12）の要求に応じた提供期間の問題が残る。

35

４．その他の留意事項（ハードウェア組込みソフトの注意点）（１）サプライ・チェーン・マネジメント97
サプライヤーから提供されたソフトウェアについては、サプライヤーから、納入物に使用されている OSS に関する正確な情報を提供してもらう必要があります。ソフトウェア･コンポーネントの構成が分からないと、OSS ライセンス条件を遵守できません。
（２）構成管理（ソフトウェアの Bill of Materials）98
OSS コンプライアンス、品質保証（バグ修正や脆弱性対応）において、自社製品に使用されている OSS を正確かつ迅速に特定することが重要になります。
（３）義務が発生する配布の意味99
ユーザに情報提供する義務が発生するか否かは、配布に該当するか否かの判断が先決問
題になります。ハードウェア組込みソフトの場合、当該ハードウェア製品をユーザに譲渡、貸与等して OSS の複製物を頒布するのであれば、配布に該当します。
OSS を配布することなく、自社内のサーバに格納し、クラウド･コンピューティングでユーザに対して処理結果をサービスとして提供する SaaS（Software as a service）の場合、配布に該当しません。ただし、Afero GPLv3 の場合、第 13 条において、SaaS（ネットワークサービス）であっても配布と同様にライセンス条件に従うことが定められていますので、注意を要します100。
Distribution（配布）又は Convey（コンベイ）に該当する行為（GPLv2/GPLv3）

Distribution（配布）に該当しない行為（GPLv2/GPLv3）

Distributing Software as a product（機器に組み込んで販売する行為。プログラムの複製物の譲渡又は貸与に該当する。
）
Making Available to Public（公衆送信可能化。ユーザがプログラムをダウンロード可能な状態に置かれて、ユーザがプログラムの複製物を入手できる。
）
Software as a service（クラウドでソフトウェアを使用し、その処理結果をユーザに提供するサービスであり、プログラムコードの複製物がユーザに伝送されない。
）
Centralized/Internal use only
（社内使用であって、プログラムコードは他人に配布も使用もされていない。
）

Supply Chain Management について、本書「E-2」参照。
構成管理について、本書 A-3 参照。
99 フォーマット統一の活動について、本書「E-2」参照。
100 AGPL 第 13 条” Notwithstanding any other provision of this License, you have permission to link or
combine any covered work with a work licensed under version 3 of the GNU Affero General Public
License into a single combined work, and to convey the resulting work. The terms of this License willcontinue to apply to the part which is the covered work, but the special requirements of the GNU
Affero General Public License, section 13, concerning interaction through a network will apply to the
combination as such.” http://www.fsf.org/licensing/licenses/agpl-3.0.html
97
98

36

５．受託開発の場合
ソフトウェア開発委託契約における注文主（ユーザ）が、仕様を指定し、利用する OSSを指図し、またはその利用を合意仕様として承認して、請負人（ベンダ）がソフトウェアを開発した場合、OSS のライセンス条件に定められた義務を負う当事者は誰になるでしょうか。この問題は、ケース・バイ・ケースの判断にならざるを得ず、一般論として断定することは難しい問題です。
（１）ベンダの責任請負人が OSS を配布している WEB サイトから、ライセンス条件に同意して、プログラ
ムをダウンロードした場合、請負人が当該ライセンス条件を遵守する義務を負います。そして、請負人は、受託開発の納品物に当該 OSS を複製し、改変、翻案して二次的著作物を作成し、注文主に納入するのですから、請負人は、OSS を配布したことになります101。したがって、注文主からの受託開発の納入物に GPLv2 または GPLv3 が適用される OSS を利用する場合においても、原則として、請負人は注文主に対して、GPL のライセンス条件に従って情報を提供しなければならないと考えられます。
（２）ユーザの責任
上記の考え方に対する例外もあります。GPLv3 第 2 条によれば、注文主（ユーザ）が請負人（ベンダ）に対して、自分専用の仕様を決定し指図して開発を委託し（having themmake modifications exclusively for you）
、納入物を管理支配して、請負人による第三者への配布を禁止した場合には、請負人は GPL ではなく、注文主の指示に対してのみ義務を負い、注文主が当該 GPL プログラムを第三者へ配布したときに、ソースコード提供等の GPLで定められた義務を負うことになるでしょう102。これは、have-made（下請への製造委託）理論に類似しており、注文主が納入物の仕様を決定し、全量を買い取るならば、納入物プロ
グラム著作物を利用する主体は注文主であると評価して、注文主を GPL プログラムのライ
センシーと評価するものと考えられます。

人材派遣契約に基づき、注文主（ユーザ）の指揮命令下で OSS を利用する（work for hire になる）場
合には、OSS ライセンスの当事者となるライセンシーは、注文主（ユーザ）になるものと考えられる。
102 “You may make, run and propagate covered works that you do not convey, without conditions solong as your license otherwise remains in force. You may convey covered works to others for the sole
purpose of having them make modifications exclusively for you, or provide you with facilities forrunning those works, provided that you comply with the terms of this License in conveying all material
for which you do not control copyright. Those thus making or running the covered works for you must
do so exclusively on your behalf, under your direction and control, on terms that prohibit them frommaking any copies of your copyrighted material outside their relationship with you.”https://www.gnu.org/licenses/gpl-3.0.ja.html
101

37

６．GPLv3 の注意事項（１）インストール情報の提供
GPLv3 第 6 条は、ユーザが自ら GPLv3 が適用されるプログラムを改変した場合、当該
GPLv3 プログラムのオブジェクトコード形式の作品の対応ソース（Corresponding Source）
103を提供するのと同時に、ユーザ製品（User Product）については104、改変後のソフトウ

ェアを稼動できるように、インストール情報（Installation Information）を提供することを求めています105。ただし、①ROM のように誰もソフトウェアの書き換えを行えない場合
は、情報提供は不要であり、②改変によってネットワーク通信規約に反するような場合はネットワークアクセスを拒否することができ、③改変について保証責任も負わないとされています。したがって、ハードウェア製品に GPLv3 が適用されるプログラムを組み込む場合、当該製品がユーザ製品か否かについて検討する必要があります。
（２）ユーザ製品について
GPLv3 第 6 条は、個人、家族または家庭用に作られた消費者製品（consumer product）
上で動作するソフトウェアは、同条に従わなければならないと定めています。Free Software
Foundation（FSF）のコンプライアンス・エンジニア Brett Smith 氏は、この定義について、「我々に害を及ぼさないある種のビジネスモデルを妨げることなくフリーソフトウェア
に関する主要な問題を解決するための妥協案だ」と説明し、GPL v3 のドラフトでは米国のMagnuson-Moss 保証法の定義を引用していました。マグナソン・モス保証法が定める消費者製品の定義は、次のとおりです106。
「消費者製品」とは、あらゆる有形の私有財産で、商業的に流通され、通常、個人、家族、家庭用に使用されるものを意味する。それらの財産が、実際に不動産（住居）に付属し又は組み込まれたか否かににかかわらず、不動産（住居）に付属することを意図し、又は不動産
GPLv3 第 1 条の代議によれば、オブジェクトコード形式の作品に『対応するソース』(Corresponding
Source)とは、その作品を生成、インストール、（実行可能な作品に関しては）オブジェクトコードを実行、
103

または作品を改変する上で必要とされるソースコードのすべてを意味する。この場合、そうした活動をコントロールするためのスクリプトは『対応するソース』に含まれるが、その作品にとっての『システムラ
イブラリ』や、先ほど列挙した活動を行う上で改変されることなく利用されるものの作品の一部ではない、
汎用のツールや一般的に利用可能なフリープログラムは除外される。例えば『対応するソース』には、その作品のソースファイルと連携するインターフェース定義ファイルに加え、共有ライブラリや動的にリンクされた下位プログラムと作品のその他の部分との間での親密なデータのやりとりやコントロールフローなどのために、その作品が設計上明確に必要とする、そうした共有ライブラリや下位プログラムのソースコードなどが含まれる。
104 GPLv 3 第 6 条の"User Product"は、個人、家族または家庭用に作られた“consumer product”であり、コンシューマプロダクト上で動作するソフトウェアは同条に従わなければならないと定めている。
105 なお、GPLv3 第 3 条において、「あなたが『保護された作品』を伝達する場合、『保護された作品』に関して本許諾書の下で権利を行使することにより、技術的手段の回避に影響が出る範囲において、そのよ
うな手段の回避を禁じるいかなる法的権力をも放棄することになる」と定められている。
106 Magnuson-Moss Warranty Act-Federal Trade. Commission Improvement Act（15 U.S.C.§§2301 etseq.）The term “consumer product” means any tangible personal property which is distributed incommerce and which is normally used for personal, family, or household purposes (including any suchproperty intended to be attached to or installed in any real property without regard to whether it is so
attached or installed). http://www.law.cornell.edu/uscode/text/15/2301

38

（住居）に組み込まれることを意図した場合を含む（購入した消費者が実際に付属させ又は組み込んだか否かという使用内容を問わず、販売する時点で組込みを用途としていれば、消費者製品となります）。
この定義に従うならば、企業間で業務用システムを受託開発する場合、当該システムは「User Product」に該当しないものと考えられ、GPLv3 プログラムのインストール情報を提供する義務はないと解釈することができます107。他方、一般消費者向け製品の場合には、インストール情報を提供した場合の問題に注意すべきでしょう108。
（作成日：2017 年 11 月 20 日）

107
108

独立行政法人情報処理推進機構（IPA）「GPLv3 逐条解説」（第 1 版、2009 年）74 頁以下参照。
本書「A-1-1」参照。

39

Question A-2

自社ソフトウェアを OSS で提供する場合の留意点

自社で独自に開発したソフトウェア（以下、自社ソフトウェア）を OSS 化したいと考えています。どのような点に留意しなければならないでしょうか？

Answer
１．自社ソフトウェアを OSS 化する目的とは
OSS 化する利点としては、新しい技術を用いてソフトウェアを開発した場合など、多くの人に広く使ってもらうことで世の中に認知される他、OSS コミュニティの参加者がボランティアで OSS のバグや不足している機能を修正してくれるなど、技術的な貢献が期待できる点です。
OSS 化することで洗練されたソフトウェアに付加価値をつけ、OSS 版とは別に有償版としてリリースしている企業も多くみられます。
多くの人に使ってもらうことが OSS 化の利点であり、OSS 化するソフトウェアは誰もが価値を認めるソフトウェアである必要があります。
ここでは、OSS 化する際の留意点について、以下のとおりご紹介します。
２．OSS 化する自社ソフトウェアの確認事項（１）保有特許との関係確認
OSS 化する自社ソフトウェアに関連する特許を保有している場合、当該 OSS のユーザに対して権利行使ができなくなる可能性があり、慎重に検討する必要があります。
（２）自他者の秘密情報や著作権が混入していないか
顧客等、取引先の情報や、自社の秘匿すべき技術情報が混入していないか、第三者が著作権を有するコードが含まれていないかを開発関係者と確認する必要があります。
（３）他の OSS が混入していないか
OSS 化する自社ソフトウェアに他の OSS が混入していないかを確認する必要があります。
混入していた場合には、ライセンス違反とならないよう条件に従う他、適切な著作権告知を行ってください。万一、相容れないライセンスの OSS が混入していた場合には除外するなどの対処が必要です。
なお、OSS 混入の有無の確認作業を人手で完全に実施することは困難であり、BlackDuck40

HUB109や FlexNet Code Insight110、FOSSology111などの検出ツールを使ってスキャンした
結果をエビデンスとして残すことが望ましいです。
（４）特許調査
OSS ライセンスでは、使用者に特許の権利行使制限や予め実施許諾を要求していることから特許調査不要と思いがちですが、OSS ライセンスに拘束されない第三者から権利行使される可能性があります。しかも、ソースコードを公開しない場合と比べ訴えられるリス
クが高まるため特許調査は慎重に行う必要があります。
最近では、特許権者からの防衛手段として、Linux 技術に関する特許を調達して会員にライセンス許諾する Open Invention Network（OIN）が設立されるなど112、特許権利行使の脅威は OSS にも及んでいます。
３．OSS 化後の社内体制を検討（１）自社ソフトウェアを OSS 化する際のライセンスは何にすべきか検討
より多くの人に使ってもらうためには、独自のライセンス条件で公開するよりも、広く知られている OSS ライセンス113を選択した方が無難です。
OSS 促進を目的とする非営利団体 OSI114が認定した OSS ライセンスであれば比較的、自由度が高く、一般的に許容されやすいライセンス条件を選択することが望ましいです。
（２）関連資料の整備
自社ソフトウェアの OSS 化に伴い操作説明書などの資料をどの程度、整備すべきかの検討や、また日本語で作られている場合は、英語に翻訳するなどの対応が必要です。
（３）公開する場所
OSS 化した自社ソフトウェアを多くの人に使ってもらうには公開場所も重要です。自社のサイトで公開しても良いですが、開発者がコードの共有や、公開するためのソーシャル
ネットワーキングサイトである GitHub115など、コミュニティ活動が活発な場所を選ぶとよいでしょう。
（４）コミュニティとの上手な付き合い
コミュニティに参加する開発者たちは積極的に OSS への貢献（不具合報告、バグ修正、
109

https://www.blackducksoftware.com/ja/products/hub

110

https://www.flexera.com/enterprise/products/software-vulnerability-management/flexnet-code-insight/
111 https://www.fossology.org/
112 パテント 2015 Vol.68 「新たな特許防衛の仕組みと PAE 対策とその分析」（小林和人）。
113 主な OSS ライセンスの種類や特徴については、本書「基礎-1」参照。
114 OSI（Open Source Initiative）認定の定義
https://opensource.org/osd
115 GitHub
https://github.com/github

41

機能の不足等）を行なうことが期待できます。OSS 化した自社ソフトウェアへ貢献があった場合、速やかに応答し、自社からも不具合報告への対応などの貢献を行わないと、一方的に受益を得ていると非難され、開発者とうまく信頼関係を築けないまま自社ソフトウェ
ア OSS 化の目的を果たせない可能性があります。
４．自社ソフトの OSS 化に際する社内手続き
自社ソフトウェアを公開する点において、通常、製品化プロセスと大きな違いはないと思われますが、以下の点から OSS に特化した手続き等が必要となる可能性があります。
（１）商標調査
OSS 化する自社ソフトウェアを広く使ってもらうために、認識されやすいよう名称やロゴを付ける場合がありますが、事前に対象国において商標調査が必要です。
インターネットを通じて世界中どこからでもアクセス可能なため、調査対象国を限定することが難しい一方、全ての国で商標調査すると膨大な費用がかかり現実的ではなく、主要国を選定するなどの事業判断が必要となります。
（２）輸出管理
インターネットでプログラムを公開する場合においても輸出管理が必要となります。
「OSS 公開時」、「不具合修正のためのパッチ提供時」、「コミュニティからの問合せへの応答時」など、ネット上に技術情報を発信する際には、社内規程やルールに基づき、輸出管理部門より該非判定の実施や、公開されたソフトウェアかどうか、暗号が含まれていないかどうか等の確認が求められると思います。しかし、会社にとって重要な手続きである一方、迅速さが要求されるコミュニティとの付き合いにおいては支障となる場合があります。
コミュニティへのタイムリーな貢献や対応が可能となるよう、OSS の専門部門や人を限定するなど、条件を付けて輸出管理プロセスを緩和するなど工夫が必要と思われます。輸出管理に関する詳細は、本書「基礎 3-3」を参照ください。
（作成日：2017 年 11 月 14 日）

42Question A-3

OSS のメリットと留意事項

Open Source Software（OSS）を利用する場合、商用ソフトウェアと比較した場合に、OSSのメリットと留意事項は何ですか？

Answer
企業がソフトウェアを開発、販売し、または社内使用する場合において、OSS を利用するメリットと留意事項について、①性能および品質（Quality）、②開発工数や費用（Costs）、③技術情報や知的財産権（IP）および④供給安定性と納期など（Delivery）の観点で、商用ソフトウェアと比較して解説します116。
１．性能および品質について（１）OSS のメリット①オープンイノベーションによる累積的発展
OSS は、世界中の多くの優秀な開発者によってレビューされるので、高い機能と品質を持つソフトウェアが生まれ、開発とバグ修正を積み重ねているプログラムがあります。
さらに、デファクトスタンダード化している OSS を生むコミュニティもあり、自社開発
プログラムの提供をビジネスにしている企業も、汎用性やユーザの利便性を考えると、積極的に利用することを検討すべき OSS も存在します117。
②リソースの自由利用性
ソースコードを参照し、複製、改変できるため、OSS の利用者がソフトウェアのバグを修正したり、カストマイズしたりすることができます。
（２）留意事項①無保証
OSS は無保証で提供され、品質保証や技術サポートがないために、品質問題や第三者の著作権や特許権を侵害する事件が発生した場合には、OSS の開発者は責任を取らず、利用者が自ら解決し、責任を取らなければなりません。
②脆弱性
加害意図を持つプログラマが OSS のセキュリティ・ホールを発見して攻撃してくる場
合があります。脆弱性に関する不安は、商用ソフトウェアでも同様ですが、脆弱性情報
IPA（独立行政法人 情報処理推進機構）の調査参照。
http://ossipedia.ipa.go.jp/nfs/pdf_pub/1004/201/645/645.pdf
117 KDDI「OSS の動向とその活用戦略」（2018 年）http://www.soumu.go.jp/main_content/000527339.pdf
116

43

の提供や対策パッチの提供について、OSS の場合は、特定のベンダに依頼することができないという不安があります。
③サポート
操作方法説明書などのドキュメントが不足している場合があり、緊急時にサポートを迅速に受けられない場合があります。さらに、OSS はユーザが保有する特定のシステムにあわせるカスタム対応、OSS のバグを修補した更新版の定期的な提供、開発ツールキ
ット、サンプルプログラム、テストプログラムの提供なども保証されていません。そのため、利用者は、自ら対応しなければならないのですけれども、OSS を管理し、自らバグを修正することができる社内の技術者が不足している企業にとっては、リスクになります。
④バージョン管理
OSS は、誰でも改変できるので、似て非なるプログラムが乱立して、同種機能の OSSに多数のバージョンが存在してしまうこともあります。
（３）対処方法①無保証の連鎖無保証の OSS については、自分も無保証で損害賠償責任を免除される特約を付して再配布することによって、リスクをヘッジする方法があります。OSS に限らず、第三者のソフトウェアを利用する場合にも同様に発生する問題ですが、ソフトウェアの配布元が保証してくれる範囲内でのみ、再配布者も保証し、自己が有する保証請求権のみを再配
布先のユーザに与える方法です（pass-through warranty）。
例えば、ベンダ（請負人）がユーザ（注文主）からシステム開発を受託する場合、開発委託契約において、第三者のソフトウェア（OSS を含む）に関しては、品質保証責任を負わない旨の特約も、ユーザの合意を得られれば、契約条件として選択可能です118。
ただし、システム障害の発生原因が OSS の瑕疵（契約の内容に適合しないこと。ソフト
ウェアの場合、バグがあって合意した仕様に反すること）であることを特定するための原因調査義務、システムとの組み合わせで発生した障害の場合のベンダ責任、当該 OSSの使用を決定した経緯（例えば、合理的に OSS の品質を判断可能な情報に基づいて注文主が指図したか、ベンダが自己の判断で技術選択したか等）によって、品質保証責任を負うべき当事者が異なることに注意を要します。
②自ら品質保証する体制作り
企業が OSS を自社のソフトウェアやハードウェア製品に組み込んで販売する場合、製品全体として品質保証するためには、以下の対応が有効です。
第一に、自社開発プログラムと組み合わせる構成部品となる OSS を特定し、ソースコ
118

経済産業省商務情報政策局情報処理振興課「情報システムの信頼性向上のための取引慣行・契約に関する研究会」～情報システム・モデル取引・契約書～（平成 19 年）、モデル契約書 48 条・49 条参照。
http://www.meti.go.jp/policy/it_policy/softseibi/index.html#05

44

ードのバージョンを管理し、構成管理表（Bill of Materials）を作成することが重要です
119。OSS

それ自体は無保証で配布されていますが、OSS を組み込んだ自社製品全体についてユーザに対する品質保証責任が直ちに免除されるわけではありません。脆弱性問
題やバグが発見された場合には、自社でユーザに対してすみやかに修正版を提供することができるよう、ソフトウェアの構成管理表に基づいて、問題があるバーションを特定
し、サポートを提供できる態勢を維持することが望ましいでしょう120。
第二に、自社製品の品質を保証する以上は、品質検査が必要であり、OSS を含むソフ
トウェアの開発プロセスにおいて、各工程の品質基準を満たすことをサブ･システムテス
ト（単体テスト）で検証し、かつ、最終製品が詳細仕様どおりに稼動するか否かをシス
テム・テスト（結合テスト）で検証することが必要です。自社の技術者が、技術的構成に不慣れな OSS の性能品質をテストする場合には、コミュニティが提供するバグや脆弱性に関する情報をモニタリングして、適時に取得するとともに、テストに関するスキルを磨くことも必要になってきます。なお、NIST（アメリカ国立標準技術研究所）が脆弱性に関する情報を公開しているので、適時チェックすることを推奨します121。
第三に、自社のみならず、開発委託先・サプライヤーからの納品物についても、サプ
ライヤーに対して利用している OSS に関する情報の提供義務を課すとともに、必要に応じて解析ツールを用いて自らソースコードを調査し、外部からの不適切な OSS 混入を排除する仕組みを持つことが必要でしょう122。
２．開発工数や費用について（１）OSS のメリット①ライセンス料OSS は、無償でライセンスされるので、ソフトウェア・ライセンス料の支払いがあり
ません。
②開発費用
OSS を利用すれば、その機能モジュールについては、自社で開発する必要がなく、市場導入までの開発工数を削減することができます。

OSS 管理について、本書「B-4」参照。
IPA「組込みシステムセキュリへの取組みガイド（2010 年度改訂版）」（2010 年 9 月）
https://www.ipa.go.jp/files/000014117.pdf、IPA「自動車と情報家電の組込みシステムのセキュリティに関する調査報告書」http://www.ipa.go.jp/security/fy20/reports/embedded/index.html
121 National Institute of Standards and Technology, National Vulnerability Database は、NIST が管理している脆弱性情報データベースで、国土安全保障局が一般市民に対して、脆弱性情報を通知している。
https://nvd.nist.gov/
他に、JPN iPedia なども脆弱性対策情報データベースを公開している。https://jvndb.jvn.jp/index.html
122 OSS のサプイライチェーン・マネジメントについて、本書「E-2」参照。OSS の混入発見について、
本書「F-3」参照。
119
120

45

（２）留意事項①特定用途の場合
第一に、OSS は、特定ユーザの特定用途に適合するように開発されておらず、通常は広範な分野を対象とすべく汎用性を高めた設計となっています。したがって、自社に適合するソフトウェアの開発（移植作業）の工数が予想以上に増加してしまい、無償の OSSを利用することによって、結果的に別の開発工数が増えて、コストや開発期間にデメリットが生じる可能性も否定できないので、注意を要します。
②技術者の熟練度
技術者が不慣れな OSS を利用する場合、開発効率（生産性）が低下する場合もあり得ます。
③品質テストの工数
OSS プロジェクトは、ソフトウェア開発プロセスの中にテスト工程が存在しない場合が多いために、自社開発ソフトウェアの資産を再利用する場合と比較して、テスト工数
が相対的に大きくなることがあります。
④サポート費用
障害発生時に保守サポートを提供してくれるベンダが存在しない OSS が多いために、自社内のバグ修補に要する工数が増加することがあります。そのため、結果的に、無償の OSS を利用してもコストが下がらない場合もあり得ます123。
（３）対処方法
OSS を利用することが、自社開発プログラムや商用ソフトウェアと比較して、トータル・コストが高いか安いかについては、ケース・バイ・ケースであって、企業が商用ソフトウ
ェアの保守をベンダに依存するかの如く、いわば丸投げで OSS を利用する行為は、品質保証の観点でも、費用の観点でも、リスクを伴うものと考えられます。
技術者の OSS 対応スキルを上げ、自らサポートをユーザに提供していくための施策の一つとしては、OSS コミュニティへの積極的な参加と情報共有による社内技術者の能力熟練が考えられます。
３．技術情報や知的財産権について（１）OSS における知的財産権のライセンス
OSS は、著作物の利用許諾に基づいてソースコードを複製して利用することができます。
また、OSS の種類によっては、上流の OSS 配布者が保有する特許権について、黙示の実施
許諾（implied license）と解釈される可能性があったり、例えば、Apache v2.0 や GPLv3
であれば、必須特許の実施権（license）を得られたりすることによって、ソフトウェアの123

野村総合研究所「あらためてオープンソースのコスト削減を考える」（IT ソリューションフロンティア、
2008 年）https://www.nri.com/jp/opinion/it_solution/2008/pdf/IT20080803.pdf

46

自由な利用を認め合うことができます。
（２）留意事項①ソースコード提供義務
GPL プログラムと自社開発プログラムを組み合せた場合、別個の作品を自社開発プロ
グラムの編集物（compilation）でなく、リンクしたときに組み合せた全体のソフトウェ
アが OSS に基づいて開発された派生物 （二次的著作物。derivative work based on the
Program）に該当する場合、その自社開発プログラムにも GPL が適用されます（伝搬性）。
派生物はソース形式でもバイナリ形式でも配布できますが、バイナリ形式を配布する場
合には、配布先から要求があれば、配布先に対応するソースコードを提供しなければならないため、自社開発プログラムの秘匿したい技術が社外に流出してしまう場合があります。他方、OSS を利用する者がライセンス条件に違反すれば、ライセンサーの著作権を侵害することになります124。
②特許権行使の制限
Apache License v2.0 など OSS によっては、OSS に関連する特許権を行使すると、当該 OSS に関連する特許ライセンスを解除されたり（特許ライセンス終了条件）、プログ
ラム著 作権を使用す るライセ ンスを解除さ れたりす る場合があり ます（ defensive
termination）。その結果、OSS を継続利用できなくなる場合があるため、OSS を利用す
る限り、自社の特許発明を無償で実施許諾するのと同じ事実状態になることがあります。
③特許侵害事件
OSS の種類によりますが、OSS は特許発明を実施する権利の許諾については、特段の定めがないライセンス条件が多く、第三者の権利侵害についての保証もありません。そして、OSS はソースコードが公開されていますから、特許権者にとっては、プログラム
コードをリバースエンジニアリングして技術構成を解析しなくても、ソースコードに基
づいて、被疑侵害品のプログラムの表現や技術的構成を証明することができるので、特許権侵害事件で被告になった場合には、証拠の面で不利になるでしょう。
④著作権侵害事件
OSS が第三者の著作権を侵害するリスクについては、著作権は登録制度がなく（無方式主義）、創作によって権利が発生するため、調査が難しいのです。しかし、他人の作品に依拠しないで独自にプログラムを製作すれば、著作権を侵害しません（独立著作の抗弁）。
ソフトウェアの著作権侵害の証明は、原告と被告のソースコードの比較によって、実質的な同一性または類似性を判断して行われます。ソースコードが公開されている OSSの場合、OSS の著作権者が訴訟の原告になるときは、自社開発プログラムのように営業秘密保護のためにソースコードを秘匿する必要がなく、かつ、ライセンス違反による著
124

OSS ライセンス違反の事件例について、本書「G-1-2」参照。

47

作権侵害訴訟の場合には、被告が当該 OSS を利用している事実を把握できますから、侵害訴訟を提起することを躊躇しない可能性があります。反対に、OSS の利用者を被告として真の著作権者が訴訟を提起するときは、被疑侵害品のソースコードが公開されていれば、被疑侵害品の構成を証明することが容易です。
（３）対処方法①ソースコード提供義務について自社が秘匿したい技術については、ソースコード提供義務を負わないライセンスの
OSS を選択し、GPL プログラムの利用を差し控える方法、または GPL が自社開発プロ
グラムに伝搬しないような設計を用いる方法があります125。反対に、差別化し秘匿すべき分野でなければ、自社の技術力をアピールする目的で、積極的に自社開発プログラムのソースコードを公開していくという選択肢もあり得ます。
②特許権行使の制限について
OSS を利用した場合に、自社の特許権を当該 OSS の利用者に対して許諾する条件や、特許権を行使するとライセンスが消滅して自らも当該 OSS を使用できなくなる条件については、OSS を利用して配布する前に、当該 OSS に関連する自社の特許権を調査し、OSS を利用するメリットと自社特許権から得られる利益を比較考量して、OSS を利用するか否かを判断することになるでしょう。
③特許侵害リスクについて
第三者の特許権を侵害するリスクについては、OSS の機能およびソースコードに基づ
いて、OSS の機能や構成と関連性を有する他社の特許を調査し、特許侵害のリスクが高いものは、当該機能を使用しないように設計変更や代替品の検討といった対応が必要になります126。
④著作権侵害リスクについて
OSS が第三者の著作権を侵害するリスクについては、過去または現在において訴訟等の係争事件があれば現実的なリスクを把握できますが、判断が難しいと思います。確率論
としては、著名なコミュニティが長期間安定的に提供している OSS で、かつ、具体的な係争事件がない OSS の場合、被疑侵害品となる OSS のソースコードが公開されていて著作物の複製行為の証明が容易なはずの OSS が、著作権侵害を理由とする請求を受けていないという状況は、事実上、紛争発生リスクが低いと考え得るかもしれません。
法律上の抗弁としては、著作権表示をしている OSS のライセンサーが著作物の利用許
125

伝搬性の判断と設計手法については、本書「D-3-7-2」参照。
特許調査について、本書「F-2」参照。なお、プログラムを消去しなくても、機能を使用不能にすれば、特許侵害責任を負わないと主張する余地があると考えられる。特定の機能を実施することを必要とする装置クレームは、クレームされた機能を実施しなければ侵害せず、クレームの必須構成が使用不能になっていれば、ソフトウェアプログラムの販売だけでは実施しておらず、プロセスクレームの侵害を構成しないという解釈論もあり得るからである。ただし、この点については、各企業で社外弁護士の意見をとることを推奨する。
126

48

諾権限を有するものと推定して、仮に他人の著作権を侵害した場合であっても、故意または過失がないと主張する余地があります。また、日本の著作権法では、「プログラムの著作物の著作権を侵害する行為によって作成された複製物を業務上電子計算機において使用する行為は、これらの複製物を使用する権原を取得した時に情を知っていた場合に限り、当該著作権を侵害する行為とみなす」（著作権法 113 条 2 項）とされていますから、著作権侵害の OSS であることを知らずに（善意で）利用している限り、著作権侵害訴訟のリスクが低いものと考えられます。ただし、外国において当該 OSS の利用の差止めを請求された場合に備えて、他の商用ソフトウェア等の代替手段を準備しておくことも検討課題でしょう。
４．供給安定性と納期などについて（１）OSS のメリット①供給安定性
商用ソフトウェア製品のように、ソフトウェア供給元の倒産、吸収合併、収益性を理由とする事業撤退などの事情で、一方的にソフトウェアの使用権を解除されることによって、ソフトウェアの使用を継続できなくなるリスクが、OSS にはありません。次世代のプログラム開発や保守サポートが停止されても、ソースコードを持っていれば、自ら対応する手段があります。
②ロックイン
ソフトウェアの供給を特定のベンダに依存しないので、ベンダに「ロックイン」されるリスクがありません127。
（２）留意事項①計画性
OSS は、次世代の開発計画などが不明で、自社の商品またはサービスに OSS を利用する場合、自社の市場導入計画との調整が難しいことがあります。市場導入後も、OSS コ
ミュニティから発信される脆弱性情報や新たなパッチ対応が必要になりますが、OSS のパッチ提供は自社開発プログラムのバージョン・アップ計画とは必ずしも一致しません
し、そのモニタリングと迅速かつ頻繁な市場対応が難しい場合があります。
②継続性
OSS コミュニティが解散したり活動が停滞してしまったりして、パッチの提供が停止する場合や、OSS を組み込んでシステムを開発するシステム・インテグレータがサポー

ロックイン（Lock in）とは、ソフトウェア･ライセンスとの関係でいうと、ユーザが特定ベンダの独自技術に依存してしまうと、そのベンダのソフトウェアを使い続けざるを得ず、価格が高騰しても他のソフ
トウェアに乗り替えることができずに囲い込まれた状態をいいます。財団法人ソフトウェア情報センター「ソフトウェアの適正取引に関する調査研究報告書」（平成 21 年 6 月）12～14 頁参照。
http://www.softic.or.jp/publication/reports/2009/200906tekiseitorihiki.pdf
12749

トを停止してしまう場合があり得るので、OSS が時間の経過とともに陳腐化する可能性があります。
（３）対処方法①社内管理体制
OSS を利用する企業は、利用ポリシーを定め、社内教育で OSS の使い方を啓蒙するとともに、社内の技術者を OSS 開発コミュニティと交流させ、自らその OSS の改良版をコミュニティに還元する等の活動を通じて、当該分野の技術に習熟させることも検討すべきでしょう。
②戦略的な利用
OSS を利用する企業としては、内外製方針を確立して、外部調達する部品領域（commodity platform/shared cost）や、アプリケーションをインフラ上で稼動させるための OS や周辺技術などの領域（delivery support for the innovation/cost）については、
積極的に自社の改良ソースコードをコミュニティに提供していくとともに、価値ある技
術 ノ ウ ハ ウ を 秘 匿 し て 差 別 化 を 図 る べ き ア プ リ ケ ー シ ョ ン 領 域 （ uniqueinnovation/value）については、OSS を自社ソフトと一緒に使わないという開発戦略も選択肢の一つでしょう128。
（作成日：2018 年 3 月 10 日）

福安徳晃「オープンソース経済モデル ～IT 産業振興に関する一考察～」（The Linux Foundation、2011年）http://www.ospn.jp/osc2011-spring/pdf/osc2011spring_the_linux_foundation.pdf 11 頁参照。原典は、James Bottomley 氏の LinuxCon Japan 2010 における講演“Is the future Open Source?”である。
128

50

Question A-4

クラウドサービス129を提供するためのソフトウェアに OSS を利用する場合の留意点

新たに立ち上げるサービスをクラウドで提供する予定です。サービスを提供するためのソ
フトウェアは OSS を活用して開発する予定ですが、どのような点に注意すべきでしょうか？

Answer１．従来のソフトウェア製品とクラウドサービスとの違い
クラウドによるサービスが登場する以前、利用者は、求める機能を備えたソフトウェア
を媒体に格納された製品として購入する、あるいはインターネットからダウンロードするなどして入手し、利用者自身の PC やサーバにソフトウェアをインストールして利用していました。つまりソフトウェアは、何らかの形で提供元から利用者に対して“配布”されていました。
一方、クラウドサービスでは、事業者のサーバ上で動作するソフトウェアに利用者がアクセスして使用するため、利用者への“配布”という行為が伴うとは限りません。この点が従来とクラウドサービスとの大きな違いとなります。以下で説明するように、この違い
は OSS にとっては大きな意味を持ちます。
２．クラウドサービスが及ぼす OSS への影響
一般に、OSS は広く配布されることを前提にして、その利用条件が定められています。
しかしながら、先に説明したように、クラウドサービスにはソフトウェアの配布が伴うとは限りません。つまり、ソフトウェアに OSS が含まれていたとしても、クラウドサービスの利用者にはその OSS が配布されないため、利用者には OSS の利用条件を遵守する義務が生じないと考えられます。このことは GPL130 などのコピーレフト131を特徴とするライセンスにとっては重要な問題となります。
コピーレフト型のライセンスでは、OSS の“配布時”にオリジナルの OSS のソースコー
ドだけでなく、それを改変した場合は改変後のソースコードも利用者が入手できるように

ここではクラウドサービスとして、ASP、SaaS、PaaS を想定している。一般的に ASP はクラウドサービスとは区別されることが多いが、サービスとしてソフトウェアを提供するという観点では同じであるため、ここではそのような区別はしていない。
130 GPLv2：https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
GPLv3：https://www.gnu.org/licenses/gpl.html
131 著作権者が、自ら著作権を保持しつつ、誰もが自由に著作物の複製、改変、配布を行うことを許諾し、それら行為を行った者に対して元と同じ条件を維持することを義務付けることで、著作物の利用を広めようとする考え方のこと。
129

51

することを条件としています。コピーレフトが有効に機能するためには、OSS の“配布”という行為が不可欠となりますが、クラウドサービスでは配布行為が伴うとは限りません。
したがって、クラウドでのサービス提供はコピーレフトの効果を妨げるものと考えることもできます132。GPL を支持する人達を中心として、そのことを“Loophole”（抜け穴）と呼んでいます。
３．クラウドサービスで OSS を活用する場合の注意点
クラウドサービスではソフトウェアの配布行為がないためにコピーレフトの効果が及ばず、一見すると、GPL の伝搬のように十分な注意を払うべき事象がないようにも思えます
が、実はそうではありません。
クラウドでのサービス提供のために活用できる OSS の中には、GPL をベースにして作られた Affero General Public License（AGPL）133を適用している OSS があります。AGPL
は GPL で定めている内容を一通り引き継いでいますが、GPL との大きな違いがあります。
それは、ネットワークアクセスしてクラウドサーバのソフトウェアを利用する場合にも、アクセスする利用者へソフトウェアのソースコードを提供することを義務付けていることです。つまり、AGPL プログラムがクラウドサービスを提供するサーバで利用されていた
場合、クラウドサービスにアクセスしてきた利用者が求めるならば、その OSS（改変したものだけでなく、伝搬している部分を含む）のソースコードを提供しなければならないことをライセンスに定めているのです。
したがって、クラウドサービスを提供するためのソフトウェアを開発する際は、活用を考えている OSS の中に AGPL が適用されているものが含まれていないかを十分に確認する必要があります。それを怠れば、自社の意図に反して利用者にソースコードを提供せざるを得ない事態に陥ることも考えられます。
４．JavaScript ライブラリの使用に関する留意事項
クラウドサービスをはじめ、WEB サイトを使ったサービスでは利用者のブラウザでJavaScript を実行させていることが多くあります。そうした JavaScript にソースコードの提供義務のあるライセンス条件が適用されていた場合、JavaScript のソースコードを利用者が確実に入手できるようにしなければならないにもかかわらず、必ずしもそれが実現されていないのは問題であるとする主張があります。
例えば、クラウドサービスを提供するサーバ上のソフトウェアが GPL 適用の JavaScript
ライブラリを使って HTML などの WEB コンテンツを生成し、利用者のブラウザでhttps://www.gnu.org/licenses/why-affero-gpl.html
GPLv2 をベースにして作られたものが Affero General Public License version 1（AGPLv1）であり、GPLv3 をベースにして作られたものが GNU Affero General Public License version 3（AGPLv3）である。Affero General Public License version 2 は、AGPLv1 適用のソフトウェアを AGPLv3 で配布できるようにするためのライセンスであり、AGPLv1 から AGPLv3 への移行を容易にする目的で作られた。

132
133

52

JavaScript が実行されるとします。このとき、生成された WEB コンテンツは JavaScript
ライブラリにリンクしており、GPL が伝搬するとみなされます。GPL が伝搬した WEB コ
ンテンツが利用者のブラウザで実行されることは一種の“配布”にあたり、利用者に対してソースコードを提供する義務が生じますが、提供されるソースコードに難読化が施されていたり、その中でソースコードの入手方法が不明な他のスクリプトを動的にロ－ドしていたりするため、利用者によるソースコードの入手や改変を阻害しているというのがこの主張の概要です134。
ただし、JavaScript ライブラリのライセンス条件において例外条項が設けられている場
合は、JavaScript ライブラリとそれを呼び出したソフトウェアとは一体とはみなされず、GPL の伝搬が及ばないと考えられているようです135。したがって、例外条項の有無を把握しておくことは、自社の意図に反してソフトウェアのソースコードを提供することを防ぐ
ためには有効だと思われます。
ライセンス条件をよく確認せずに JavaScript ライブラリを使ってしまった結果、後になってソースコードの提供を求められて慌てることのないよう、念のため、このことを意識に留めておくと良いでしょう。
（作成日：2018 年 3 月 7 日）

134
135

https://www.gnu.org/philosophy/javascript-trap.en.html
https://www.gnu.org/licenses/gpl-faq.html#WMS

53

B．課題領域
１．OSS の両立性／混入
２．OSS の教育
３．OSS とサポート・セキュリティ（脆弱性）
４．OSS の管理

54

Question B-1-1

OSS の両立性とは？

OSS のライセンスの両立性（License Compatibility）とは何ですか？
OSS の混入によりライセンス間の矛盾が生じた場合（両立しないライセンスが含まれる場
合）、どのような対処をすればよいでしょうか？

Answer
１．OSS のライセンスの両立性とは？
OSS のライセンスの両立性とは、OSS のライセンスの条件を比較した場合、求められる条件において、他の OSS のライセンス条件との矛盾の有無を意味し、矛盾する場合「両立しない」と言います。
複数の OSS を結合してソフトウェア製品を開発する場合、例えば、一方のライセンス条
件 X には、もう一方のライセンス Y に含まれていない条件があり、ライセンス Y では「結合してできたソフトウェア製品のライセンスには追加的な条件を定めてはいけない」と定めてあったとします。その場合、ライセンス条件 X とライセンス条件 Y を同時に満たすことは不可能であるため、結合してできたソフトウェア製品を配布できなくなってしまうという問題が生じます。
Free Software Foundation の WEB サイトでは、GNU のさまざまなライセンスについて両立性を紹介しています136。また、Apache Software Foundation の WEB サイトでは、
GPLv2 と Apache License ver2.0 はライセンス条件が両立しないものとして記述されています137。
ソフトウェア開発の現場では、多数の OSS を利用するケースが増えています。OSS の利用を検討する際は、対象となる OSS と OSS に適用されるライセンスを OSS ごとに特定することに加え、
ライセンスの両立性も考慮して、利用する OSS を選択することが大切です。
２．OSS の混入によりライセンス間の矛盾が生じた場合の対処の考え方
利用したい OSS のライセンスに矛盾が生じる場合の対処としては、次の２つの方法が考えられます。ただし、OSS の利用方法によっては、ライセンスの矛盾が生じる利用方法に該当しない場合も考えられますので、OSS の具体的な利用方法をもとに、法務・知財担当
部署にライセンスの矛盾が生じる利用方法となっていないかを確認すると良いでしょう。
（１）矛盾しないライセンスを選択して OSS を利用する
136
137

両立性のマトリックスの紹介 http://www.gnu.org/licenses/gpl-faq.html
Apache Software Foundation の説明 http://www.apache.org/licenses/GPL-compatibility.html

55

OSS によっては、ライセンスの矛盾が生じることを想定し、複数のライセンスから選択することを前提に配布されているものがあります（Dual License 等）。選択した OSS がこのようなライセンスである場合は、複数のライセンスの中から、矛盾しないライセンスを選択可能な場合もありますので、それぞれのライセンスの内容を確認すると良いでしょう。
（２）ライセンスが矛盾しない同種の機能を有する OSS に入れ換える
ライセンスが矛盾しない、同種の機能を有する OSS やソフトウェアに入れ換えることが考えられます。
（３）OSS 開発者にライセンスの変更を依頼する
OSS の開発者が限定されている場合、ライセンスを変更してもらえないかを依頼することが考えられます。
（OSS の開発者が多数になる場合は、全員の合意を得るのは難しいと思われます）
例えば、ダウンロードしてきた OSS の中に複数の OSS が含まれており、この OSS 間でライセンスの矛盾が生じている場合もあります。この場合、OSS の開発者自身がライセンス条件に違反していることになるため、矛盾しないライセンスに変更してもらえることが期待できます。
（４）独自に開発する
矛盾するライセンスの OSS と同等機能を独自に開発することが考えられます。独自に開発した場合、著作権者として自由にライセンス条件を設定可能となります。
なお、上記（１）～（４）は、利用したい OSS のライセンスが明確に特定できている場
合の対処方法となります。実際は、OSS は多数の当事者が関与して開発され、また、コン
ポーネントとして多数の OSS が含まれているため、利用者が意図しない OSS が混入するケースもあるようです。
この場合は、本書「B-1-2」で紹介しますように、OSS の混入をチェックするツールを活用することにより、利用したい OSS がどのような OSS 群から構成されているか、OSS のライセンス条件はどのような内容であるのかを確認することができるようです。
このようなツールを活用することも、ライセンス遵守の一つの方法として検討すると良いでしょう。
（作成日：2017 年 11 月 27 日）

56

Question B-1-2

OSS チェック方法

自社ソフトウェアは、社内で作成したものや外部委託先に委託制作したものが組み合わさって成り立っていますが、許可された OSS 以外に、意図しない OSS が使用されてしまうことがあるかもしれません。そのため、製品をリリースする前に、意図しない OSS が含まれていないか把握したいと思います。どのような方法が考えられますか？

AnswerOSS を活用する開発時には OSS 活用ポリシーに従って、使用するべき OSS を選定することが求められます。しかし、外部委託先を使って開発する場合や過去の資産を母体として流用する場合など、必ずしもガバナンスが有効ではない場合があります。したがって、製品をリリースする前に、意図しない OSS が含まれていないかをチェックすることは非常に大切なことです。
意図しない OSS の混入を検知する方法としては、人手で確認する方法と、専用のツールを使用する方法の 2 種類があります。本項では人手で確認する方法について説明します。
ツールを使用する方法については、本書「B-1-3」を参照してください。
OSS のソースコードをそのままの形（As-Is）で使用している場合には、本項で説明する「人手で確認する方法」で、ある程度カバーすることができますが、OSS を部分的に複製して使用している場合や、OSS の中に複数の OSS が利用されている場合などは、人手での確認では不十分ですので、専用のツールを使用することを検討してください。
１．ライセンスヘッダを利用した検索人手で行う確認として、最も一般的な方法は文字列検索です。OSS の中には、ソースコードのファイルの一番上の部分に「ライセンスヘッダ」と呼ばれるライセンス表示が記載されているものがあります。ライセンスヘッダには、OSS の名称やライセンス、著作権表示などの情報が記載されており、どこから引用されたファイルかが一目で解るようになっています。ですから、例えばソースコード全体に対して「copyright」や「License」等の文字列を検索することで、ライセンスヘッダの存在を確認することができ、意図しない OSSの混入を検知することができます。ライセンスヘッダの検索は、例えば「GNU General
License」、「MIT License」等のライセンス名称の文字列を検索することで、特定のライセ
ンスの OSS が含まれているかどうかを確認することもできます。
ライセンスヘッダの例を、「【１】ライセンスヘッダの例」に示します。ただし、ライセ
ンスヘッダが書き換えられている場合は検索することができないので、注意が必要です。

57

２．OSS 由来のファイルの検知
その他の方法としては、「OSS 由来の可能性があるファイルを探す」方法があります。
OSS のパッケージには、COPYRIGHT、COPYING、README、LICENSE といった名称のファイルが含まれていることが多いため、これらのファイル名を検索することで、OSS由来のファイルを検知することができます。この方法は、パッケージとして使用されている OSS の場所や構造を特定する方法としても有効です。
３．入れ子構造への注意事項
ここで注意しなければならないこととして、「OSS ライセンスの入れ子構造」というものがあります。これは、「Deep License Data」や「エンベロープ（封筒）OSS」とも呼ばれるもので、あるライセンスの OSS の中に、別のライセンスが適用される OSS が内包されている状態を言います。特に大きな OSS のプロジェクトでは、別の OSS を活用して開発されているものも多く、入れ子構造になっていることは一般的なことです。入れ子構造の例を、「【２】入れ子構造の例」に示します。それらの内包されている「子」の OSS が、「親」の OSS とは異なるライセンスである場合もあり得るため、それぞれの単位ごとに、どのラ
イセンスが適用されるものかを確認しなければなりません。README ファイルなどに内包している OSS を列挙してある OSS もありますが、全ての OSS がそのように説明しているとは限りませんので、必ず自分自身で確認をするようにしてください。
【１】ライセンスヘッダの例
GNU General Public License Version 3 では、ライセンスヘッダについて下記の様な書き方を推奨しています138。
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public Licence as published by
the Free Software Foundation, either version 3 of the License, or(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Seee the
GNU General Public License for more details.
You should have received a copy of the GNU General Public Licensealong with this program. If not, see <http://www.gnu.org/licenses/>.
138

https://www.gnu.org/licenses/gpl.html

58

【２】OSS ライセンスの入れ子構造の例
Eclipse BIRT Runtime139は、the Eclipse Public License Version 1.0 が適用される OSS
ですが、その内部に the mozilla.org License Policy version 1.1、the Apache Software
License version 2.0、the sourceforge.net License Policy などのライセンスが適用されるファイルを含んでいることが、readme.txt に記載されています。
birt-runtime-4.6.0-20160607.zip（runtime_readme.txt より抜粋）
License------The Eclipse Foundation makes available all content in this plug-in ("Content").
Unless otherwise indicated below, the Content is provided to you under the terms andconditions of the Eclipse Public License Version 1.0 ("EPL"). A copy of the EPL isavailable at http://www.eclipse.org/legal/epl-v10.html.
For purposes of the EPL, "Program" will mean the Content.
Redistributed Content--------------------The Content includes items that have been sourced from third parties as follows:
Rhino 1.6R1------------The plug-in is accompanied by software developed by Mozilla( http://www.mozilla.org/rhino).
The Rhino 1.6R1 binaries included with the plug-in includes no modifications. Your useof Rhino 1.6R1 in both source and binary code form contained in the plug-in is subject tothe terms and conditions of the mozilla.org License Policy version 1.1 which is available
at http://www.mozilla.org/MPL/license-policy.html. The binary code is located in js.jar
and used indirectly via an exported library from the dependent plug-inorg.eclipse.birt.core
Jakarta Commons CLI 1.0-----------------------The plug-in is accompanied by software developed by Apache( http://jakarta.apache.org/commons/cli/).
The Commons CLI 1.0 binaries included with the plug-in includes no modifications.
Your use of Commons CLI 1.0 in both source and binary code form contained in theplug-in is subject to the terms and conditions of the Apache Software License version 2.0
which is available at http://jakarta.apache.org/commons/license.html. The binary code
is located in commons-cli-1.0.jar.
JTidy R7--------The plug-in is accompanied by software developed by
SourceForge( http://jtidy.sourceforge.net/ ).
The JTidy R7 binaries has been modified. org.xml.sax and org.w3c.dom were removed
from the original Tidy.jar. Your use of JTidy R7 in both source and binary code form
contained in the plug-in is subject to the terms and conditions of the sourceforge.net
License Policy which is available at http://jtidy.sourceforge.net/license.html. The binary
code is located in Tidy.jar.
（作成日：2017 年 11 月 27 日）
139

http://www.eclipse.org/birt59

Question B-1-3

OSS の混入をチェックするチェックツールの種類

OSS 混入のチェックツールというのがあると聞きますが、それはどのようなものですか？

AnswerOSS のチェックツールとは、対象のプログラムの中にどのような OSS が含まれているかを検出するツールで、検出精度により下記の 2 種類に分けられます。
（１）ライセンスに関する記述を検索するツール
既知のライセンス記述とソースコード中の文字列の一致を検索し、OSS の利用箇所をレポートするツール。代表的なものは、FOSSology140。
（２）ソースコードを解析し、OSS のコードとの一致を検出するツール
検証対象のソースコードと OSS のコードを比較し、一致する点や類似している点をOSS 利用箇所としてレポートするツール。数行程度の一致も検出することができる
ものや、変数名の変更やロジックの変更にも対応可能なものもある。代表的なもの
は、Black Duck HUB141や Flexnet Code Insight142、Protecode143、WhiteSource144、
FOSSID145。
上記（１）のツールは、ライセンス記述をもとに OSS の利用を検出するのに対し、（２）のツールはソースコードの記述をもとに検出するため、ライセンス記述が無い場合（ソースコードの部分的な流用など）にも対応することができ、（１）と比べて検出精度が高いと言えます。
また、これらのツールは、単に内包する OSS のリストを作成するだけではなく、それらのライセンス情報やセキュリティ脆弱性の有無などの付随する情報を提供するものもあり、利用している OSS の管理全般に活用できるものもあります。
これらのツールを使った混入チェックは、仮に、リリース直前に初めてツールを適用し、意図しない OSS の混入が発覚してしまった場合、手戻りが大きくなってしまうため、開発工程の中のいくつかのフェーズで繰り返し使用することが推奨されています。具体的には、①設計時（既存のプログラムを検証する）、②実装完了時、③リリース直前などのタイミン

140
141

http://archive15.fossology.org/projects/fossology
https://www.blackducksoftware.com/ja142

https://www.flexera.com/enterprise/products/software-vulnerability-management/flexnet-code-insight/
143 https://www.synopsys.com/jp2/software/protecode/Pages/default.aspx
144 https://www.whitesourcesoftware.com/?lang=ja
145 http://fossid.com/

60

グが効果的です。ツールの中には、ビルドツールや自動化ツールとの連携が可能なものもあるため、これらを使用して実装中、継続的に検証することも可能です。このように、なるべく早い段階で完全な OSS リストを作成できれば、ライセンスの見落としやライセンス
違反のリスクを軽減することができます。
また、これらのツールはあくまで個々のパッケージやライブラリ、ファイルに対するライセンスを検出してくるため、OSS リストを参照しながら、人手で、プログラムの構造を考慮しながら、GPL 等のライセンスが伝搬する範囲やライセンスの両立性について検証する必要があります。
（作成日：2017 年 11 月 27 日）

61

Question B-1-4

OSS 混入のチェックツールの種類

OSS の混入は、高価なチェックツールを使わないとわかりません。しかしチェックツール
は中小企業にとっては高価です。それでもソフトウェア製品の開発で高価なチェックツー
ルを使わないといけないのでしょうか？チェックツールの種類（金額？ランク？）によって、責任が認められたり否定されたりすることはあるのでしょうか？

AnswerOSS の混入は、人手で確認する方法と専用のツールを用いて確認する方法があり、本書のそれぞれ「B-1-1」「B-1-2」で説明しています。
OSS 混入の有無自体は、人手によるチェックでも専用のチェックツールによってでも確認できますので、高価なチェックツールを用いなければならないということではなく、チェックツールの種類によって責任に違いが生じるものではありません。OSS の活用に即して、チェック方針、方法を定めて適切に実施してください。
以下では、「自社ソフトウェア」の開発方針として（１）～（３）を掲げる場合を想定
例として、考えられる OSS ライセンス遵守のための製品開発時、販売時の対応例について説明します。
＜「自社ソフトウェア」開発方針＞（１）一部作業を開発委託先に委託する。自社、開発委託先ともに多数の OSS を活用する。
（２）GPL ライセンス適用 OSS の利用方針は次とする。
・自社は改変、自社独自開発部分との結合を許可する。結合する自社独自開発部分
は API 部分とし、独自ノウハウ部分は含まない。
・開発委託先は、改変、開発委託先独自開発部分との結合を許可しない。
（３）販売先には「自社ソフトウェア」の改変、結合を許可しない。
＜OSS ライセンス遵守のために考えられる対応＞①製品開発時(a) OSS の活用状況の把握
自社、開発委託先それぞれで活用した OSS と OSS のライセンス条件を正しく把握する必要があります。多数の OSS を活用していますので、人手に比べ短期、高精度

62

の把握が可能な専用ツール146を用いることをお勧めします。
開発委託先には、OSS の活用リストを納品物に含めることを、開発委託契約で合意しておくと良いでしょう。
(b) 開発の記録化
自社、開発委託先それぞれの独自開発部分と OSS を活用して開発する部分を記録化します。OSS を改変している部分、自社独自開発部分と OSS を結合している部分についても、ブログラム、モジュール、ルーチン単位などで具体的に記録します。
(c) OSS のライセンス遵守のための対応
開発委託先の納品物、自社開発部分が「自社ソフトウェア」開発方針に従って開発されたどうか、ライセンス遵守のための対応が適切であるかを確認します。方法としては、人手で開発記録を確認する方法と専用ツールによる方法が考えられますが、
ソースコードマッチング形式での検出が可能な専用ツールを用いれば、細かな確認が可能であり、お勧めします。
②製品販売時(d)「自社ソフトウェア」に関する以下の情報の販売先への説明と契約としての合意-

OSS に関するメリットやリスク147-「自社ソフトウェア」への OSS 活用状況と OSS のライセンス遵守の対応方法-「自社ソフトウェア」の契約条件（責任範囲、保証内容等）「自社ソフトウェア」への OSS 活用状況と OSS のライセンス遵守の対応方法について
は、製品開発時の(a)～(c)の結果を流用することが考えられます。開発記録、専用ツールの確認結果を DB 化しておくことにより、販売先への説明も適切に実施することができます。
なお、専用ツールを用いる場合においても、ツールである以上、一定の制約があることを理解して活用することが必要です。
一例をあげますと、ソースコードを OSS コードとマッチングして OSS を検出するツー
ルの検出精度は OSS コードを含む OSS 情報が格納されているデータベースの正確性や更新頻度、ソースコードと OSS コードとのマッチング技術の精度に依存します。ツール活用
時点でデータベースに未登録の新種 OSS が開発で活用されていても検出されませんし、部分一致した内容を確認すると、あり触れたプログラム表現形式で、ソースコードと OSS コ
ードと一致していただけ、ということもありえます。
したがい、専用ツールを用いる場合であっても、最終的には専用ツールの検出結果をもソースコードマッチング形式のツールでは、ライセンスの両立性「B-1-1」、Deep License「B-1-2」について、コードベースでの確認が可能。
147 第三者の知的財産権を侵害していないこと、品質・脆弱性について無保証・無補償であること。GPLなどコピーレフト型ライセンスでは改変・配布時に改変者の技術情報の開示が必要となること。
146

63

とに人手で OSS 活用状況を確認のうえ、OSS の活用状況と OSS のライセンス遵守の対応
方法を確定させる必要がありますので留意してください。
（作成日：2017 年 11 月 1 日）

64Question B-2

OSS 利用ポリシーと社内教育

OSS を取り扱うための「OSS 利用ポリシー」には、どのような内容を定めればいいですか？
また、社内の意識向上のためには、どのような教育を行えばいいですか？

Answer
１．OSS 利用ポリシー
OSS 利用ポリシー（以下、「ポリシー」と記載します。
）には、自社ビジネスにおける OSSの利用方針や、実際に利用する際の社内手続き、承認フロー等の社内ルール148を定めます。
ポリシー作成の際は、以下を検討のうえ、内容を決定することをお勧めします。
（１）OSS を利用する対象ビジネスの明確化
自社のビジネスのうち、どのようなシーンで OSS を利用することがあるのかを明確にすることが大切です。
例えば、ソフトウェア製品や組込み機器の開発での利用、受託開発やコンサルティング、
サポートビジネスでの利用、クラウドサービスやアウトソーシングでの利用、社内システ
ムや従業員の効率化ツールでの利用等が考えられます。
さらに、ソフトウェア開発を外部発注した際の納品物や、他社からライセンスを受けた
他社製品に OSS が含まれるケースも考えられます。
OSS の利用シーンを特定したら、そのビジネスでの関係者が誰になるのかも明確しておき、関係者に必要な教育や情報共有ができるようにします。関係者としては、例えば、社内の開発者、営業、システム管理者、購買部門、法務部門の他、社外の発注先や販社、ライセンス元の他社、ユーザ等の取引先が考えられます。
（２）OSS を採用する際の判断基準と社内手続き
上記（１）のビジネスを考慮したうえで、自社で OSS を採用する際の判断基準を明確にします。
ポイントとしては、以下を考慮する必要があります。
①OSS のライセンス条件の遵守の可否②バグや脆弱性が発生した場合の対応方法(影響の評価、対処方法や費用の確定、顧客への説明等の対応手順の確立)

148

平成 17 年 5 月に社団法人情報サービス産業協会から以下が発行されている。
・「企業ポリシー策定ガイドライン」 http://www.jisa.or.jp/Portals/0/report/16-J013.pdf

65

③OSS 開発者や開発コミュニティの評価（参加企業、開発者の人数、更新頻度、ライセンス変更のリスク等)④問題発生時の責任の所在（契約での修正責任、損害賠償責任、サポート条件等の確認）⑤発注先が OSS を利用する際の確認方法⑥意図していない OSS の混入チェックの方法⑦ユーザ等の取引先への OSS 情報の提供方法や契約条件
上記のポイントを考慮したうえで、以下を含めた社内手続きを定めておきます。
a. 誰が何の情報をもとに承認するか、
b. エビデンスをどのように保存、管理するか
c. 会社全体の OSS の利用状況をどのように管理するか（OSS に関する権利侵害等の問題発生時に関係者へ通知可能とする)（３）他社製品での OSS 利用確認
他社製品のライセンスを受けて自社製品と共に、あるいは自社製品に組み込んで販売するケースがあります。この場合、他社製品で利用している OSS 情報の把握、OSS のライセ
ンス条件の遵守確認、問題発生時の責任分担、バグや脆弱性の対応方法等について、他社との契約条件を含めて、確認しておくことが大切です。
（４）自社プログラムの OSS 化の社内手続き
OSS に修正や機能追加を行った際、もとの OSS の開発元に反映してもらうために、自社プログラムを投稿するケースがあります。また、自社が独自開発したソフトウェアを新たな OSS として公開するケースもあります。
このような場合は、自社の知的財産権の許諾や秘密情報の漏洩防止、他社の知的財産権の侵害回避の方法、OSS に適用されるライセンス条件の評価や輸出管理等について、判断基
準や社内承認手続きを定めておくことが大切です。
（５）OSS ライセンスの採用方針
ビジネスによっては、OSS のライセンス条件によって採用方針を決定しておく方法もあります。例えば、以下のような方針を立てておくことも有効です。
①コンシューマ向けの組込み機器には、GPLv3 のようにインストール情報の提供義務のあるライセンスの OSS は採用しない。
②クラウドサービス等では、AfferoGPL のようにクライアント側へソースコードの提供義
務のあるライセンスの OSS は採用しない。
③自社の特許活用を重要視している場合、特許権を広範囲に許諾しなければならない OSS

66

は採用しない（あるいは、OSS のコミュニティには投稿しない）。
２．社内の意識向上のための教育（１）立場に応じた教育の実施
上記１（１） にて明確にしたビジネス毎の OSS 関係者の立場に合わせて必要な知識を整理し、①各関係者に共通する OSS の基礎知識、②各関係者の役割に応じた個別の知識、③自社のポリシーに従った手続き等を教育する必要があります。
例えば、基礎知識149としては、OSS の特徴や、知的財産権とライセンス条件との関係、自社のポリシーの概要等を教育します。
役割別の教育としては、例えば、開発者向けには、各 OSS ライセンスの遵守方法や、開発工程毎に関連するポリシーの内容を教育する方法があります。特に、意図していない OSSの混入防止や、OSS のライセンス違反を防止するためには、直接、OSS を使用する開発者への教育が重要になります。
（参考）「OSS ライセンス遵守活動のソフトウェアライフサイクルプロセスへの組込み」
http://www.ipa.go.jp/osc/osslegal.html
発行元:独立行政法人情報処理推進機構（IPA）
その他、営業向けには、ユーザが関係するポリシー部分、購買担当者向けには外部発注
やライセンス製品に関するポリシー部分、法務担当者向けには OSS のライセンスに関連する技術情報等を教育することが考えられます。
（２）OSS のライセンス遵守のための教育
ライセンス条件を遵守するためには、まず、基礎知識として、ライセンス条件と知的財産権との関係や、大まかなライセンス条件の分類を紹介することが有効です。分類については、例えば、ソースコードの提供の要否の観点で分類する方法があります。
（参考）[基礎]：「【表１】著名なライセンスとソースコードの提供義務」
次に、自社内で利用頻度の多いライセンスを抽出し、これらを遵守するために実施しなければならない事項（例えば、ライセンス文書の提示やソースコードの提供等）について、各ビジネスケースに応じた具体的な対応策を教育することが大切です。また、ライセンス
条件に記載された禁止事項（例えば、OSS 名や開発者名の宣伝活動での利用禁止等)も教育する必要があります。さらに、GPL 関連の OSS を利用する場合は、自社プログラムへの影響についても教育することが大切です。
実際に教育を実施する際は、教育内容に合わせた必須対象者を決定し、受講したことを
149

OpenChain が Curriculum（英語）を公開

https://www.openchainproject.org/curriculum67確認できるように管理することが大切です。また、受講時間の長さや教材の理解のしやすさを考慮して、e-learning にするか、あるいは集合教育にするかを決定します。内容によっては、毎年、教育を実施することにより、ノウハウを定着させる方法もあります。
（３）開発者と法務担当者との知識ギャップへの対応
開発者と法務担当者では、技術や法的知識が異なるため、相手の立場を考慮した会話を行なうことが大切です。例えば、開発者の中には、「インターネットで公開されているソ
フトウェアは、ダウンロードして利用されることを前提に公開しているのであるから、禁止事項が提示されていない限り、自由に利用可能である」、と誤解しているケースがあります。この前提のままライセンスを参照すると誤った解釈をするおそれがあります。
したがって、法務担当者は、開発者の知識レベルを確認したうえで、会話することが大切です。
一方、法務担当者の中には、例えば、動的リンク/静的リンク等の技術用語を理解していないため、ライセンス条件を正しく理解できないケースがあります。そのため、法務担
当者は開発者にプログラムの動作を図解してもらう等して理解できるように努力するとともに、IT 用語の基礎知識を習得する努力も必要です。
（参考）「OSS ライセンスを理解するための IT 用語の基礎知識（法務・知財部門向け）」
発行元:OSS ライセンス研究所 [技術用語解説分科会]
https://www.osll.jp/outline/reference/#_33
個々のプロジェクトにて OSS を利用する際は、開発者と法務担当者にて協力のうえ、双方の知識を補いながら、ライセンス毎に実施しなければならない事項を明確にしていくことが大切です。
（更新日：2017 年 11 月 27 日）

68Question B-3-1

OSS のサポートと脆弱性対策

OSS を利用する場合のサポートサービスやセキュリティ脆弱性対策に関して
１．OSS のサポートサービスを受けることは可能ですか？
２．利用している OSS が、開発コミュニティなどでのバグフィックス対応が終了するかもしれないとき、どのようにするのがいいでしょうか？
３．ソフトウェアの脆弱性対応で、OSS であることに起因する事情がありますか？
４．脆弱性への対応の観点から、OSS を選択する場合の注意点はありますか？

Answer
１．OSS サポートサービスの有無
OSS のサポートサービスを有償で提供する企業は多数あります。OSS の種類も、サポー
トサービスの提供企業も多種多様ですので、次の様な点に注意する必要があります。
（１）すべての OSS のサポートが受けられるか
世の中のすべての OSS についてサポートサービスが存在するわけではありません。しかし、企業の情報システムで採用の多い OSS については、サポートする企業が見つかる可能性が高いでしょう。
（２）サポートを提供する企業
ある企業が開発したソフトウェアを OSS として公開している場合に、その開発元企業が提供する場合もあれば、他の企業がサポートを提供している場合もあります。開発元でない企業がサポート内容などで付加価値を付けている場合もあり、一概に開発元企業の方が良いとは言い切れませんので、提供サービス内容をよく調べる必要があります。
（３）サポート内容の差異
それぞれの企業が提供するサポートサービスによって、対象とする OSS や、サポートの内容、サービス提供時間帯などが異なります。同一の OSS についてもサポート企業によってサポート内容や対象バージョンなどが異なることがあるので、比較検討が必要です。特定の OSS 単品を対象としたサービスもありますし、複数の OSS をまとめて対象にできるサービスもあります。

69

２．開発コミュニティなどでのバグフィックスの終了などへの対応
新しいバージョンではバグフィックスの対応が続いている場合と、その OSS そのもののメンテナンスが止まってしまう場合によって対応は異なります。
（１）古いバージョンがバグフィックスされなくなる場合
新しいバージョンに更新することが基本対応になります。しかし、何らかの理由があってバージョンアップができない場合には、下記（３）の対応を検討してください。
（２）その OSS のメンテナンスが止まっている場合
一般論としては、その OSS の利用を諦めて他の製品（OSS もしくは非 OSS）への切り替えを検討すべきでしょう。しかし、利用するソフトウェアを他のものに置き換えることは容易ではありません。時間も要することが多いでしょう。置き換えることが難しい場合には、下記（３）の対応を検討してください。
（３）開発コミュニティなどでバグフィックスされない OSS の利用を継続する場合
ソースコードが公開されて改変の自由がある OSS の特性を活かして、自分たち（自社）
でバグフィックスを行うことが可能です。技術力も時間やコストも必要ですが、他のソフ
トウェアに置き換えたり、対象の情報システムを作り替えたりすることの代替案として検討する価値はあるかもしれません。
有償のサポートサービスによっては、開発コミュニティがメンテナンスを終了した OSSのバグフィックスを提供することをサービス範囲に含めているものもあります。バグフィックスの作成まで可能なサポートサービスや、対象にできる OSS の種類はあまり多くはありませんが、調べて見る価値はあるでしょう。
３．OSS 特有の脆弱性対応
ここでの脆弱性は、情報セキュリティの懸念につながるソフトウェア上の不具合に限定します。その様な脆弱性対応について、OSS 特有の事情として次の様な点が挙げられます。
（１）OSS であることの最大の特徴は、前述の２．
（３）の様に、自分たち（自社）で修正したり、開発元コミュニティや開発元企業ではない第三者のサポートサービス提供者に修正を依頼したりすることも可能な点です。
（２）その他にも OSS だから安心だと言われる面があります。ソースコードが公開されていないソフトウェアへのバックドアの存在や、開発元が脆弱性を公開していない（隠している）可能性への懸念から OSS を支持している場合もあります150。また、OSS の場合は多150「平成 26 年度我が国経済社会の情報化・サービス化に係る基盤技術（クラウドコンピューティング時

70

数の開発者がソースコードを読んでいるために、脆弱性やその他のバグが迅速に発見・修正される特徴があると言われます。しかし、この後者については、長期間残留していた脆弱性が発見されるケースもあり、OSS だから常に安心というわけでは無いのも事実です。
（３）逆に、OSS だから心配だと言われる面もあります。本節で述べたサポートされなくなる懸念などのほかに、そもそも元の品質が悪いのではないかという懸念が代表的です。
多種多様な OSS が存在し、かつ、市場で淘汰されていないものが多数あるので、OSS の品
質がまちまちであるのは事実です。したがって、利用する OSS を選択する際の評価が重要になります。
（４）元は同じ OSS であっても分岐（フォーク）している場合があり、注意が必要です。
分岐した一方では脆弱性が修正されてバグフィックスが提供されていたとしても、分岐した別バージョンでは提供されておらず、かつ、他方のバグフィックスは適用できないというケースがあります151。
４．脆弱性対応の観点からの OSS 選択の注意点注意すべき主要な観点は、開発コミュニティや開発の中心企業の活動がアクティブかどうかという点と、サポートサービスが提供されているかどうかの 2 点でしょう。
（１）開発コミュニティや開発中心企業の活動が安定し、かつ、アクティブであるかを確認します152。
①コミュニティの設立もしくは初期バージョンのリリースから利用開始時点（検討している現時点）までの経過期間がある程度長いこと。
②新バージョンが長期間リリースされていないものは要注意。つまり比較的最近に新バージョンがリリースされていること。
③リリース計画やサポートポリシーが明示されていること。
上記①②において目安とする期間については、利用の仕方や、対象の OSS による個別事情の影響も大きいので、定量的な基準を設定するのは困難です。自分たち（自社）
で問題の解析や不具合の修正などが可能な場合には、スタートして間もない OSS や、
メンテナンス期間が長い OSS でも許容できるかもしれません。また、昨今は、特定のOSS がスタートしてから急速に普及しコミュニティも成長する場合が多くあり、コミ
ュニティ設立・初期バージョンリリースからの期間（①）は短くなる傾向にあります。

代におけるオープンソースソフトウェアの活用に関する調査事業）」調査報告書 pp.85-87、http://www.meti.go.jp/meti_lib/report/2015fy/000438.pdf
151 分岐した OSS の双方に脆弱性が見つかった例（2015 年）:
https://opensource.srad.jp/story/15/09/17/0633233/
152 OBCI、「オープンソース入門」（2016 年 11 月版）、http://www.obci.jp/2016event/2338/

71

（２）サポートサービスが提供されているかどうかを確認します。
サポートサービスを必要としない場合でも、有償のサポートサービスが提供されている
OSS であるかどうかは、多くの利用企業がいることの目安になります。サポートサービスを受けようとする場合、サポートサービスを契約すれば必ず脆弱性対策が提供されるとは限らないため要確認です（上述の１．
（３））
。
（作成日：2017 年 8 月 28 日）

72

Question B-3-2

OSS のバグを発見した場合の対処

OSS の脆弱性などのバグを発見した場合、どのような対処をすればよいでしょうか？

Answer
１． 情報を共有すること
もっとも基本的な点は、開発コミュニティ（開発中心組織）や利用者コミュニティなどと、発見した問題点を共有することです。自分たち（自社）で不具合を直せる場合も直せない場合でも、この点は同じです。発見した問題点を報告して共有することも、その OSSに対する大事な貢献の一つです。
対象の OSS についてサポートサービスを受けている場合には、サポート提供会社に連絡をすることになるでしょう。既知の問題であったり、すでに修正版が存在したりすることもあります。
２．脆弱性情報共有の注意と通報先
コミュニティへの報告方法が、メーリングリストであったり、掲示板型の WEB サイトであったりなど、報告によってその問題点（セキュリティ上の脆弱性）が公に知られるものになることにも気を配る必要があるでしょう。問題点が修正される前に、いわゆるゼロデ
イ攻撃を受けるおそれが皆無ではないためです。ただし、これは発見した脆弱性を共有す
る順番や時間軸に気を配るということであって、脆弱性情報を秘密にした方が安全だということを意味するわけでは決してありません。
発見した脆弱性の連絡先ですが、開発コミュニティや開発元企業に直接連絡する以外に、
脆弱性届出制度や団体を利用する方法があります。日本国内だと、「情報セキュリティ早期警戒パートナーシップ153」という制度があり、独立行政法人情報処理推進機構（IPA）154が受付機関となり、一般社団法人 JPCERT コーディネーションセンター（JPCERT/CC）155が調整機関となって運営されています。この制度を使うことで、発見者の匿名性が確保できたり、複数の開発ベンダや開発者との調整をしてくれるといったメリットがあります。また、希望する場合には、脆弱性対策情報ポータル156公開時に名前を掲載してもらえます。
ただし、この制度は、一時に非常に多数の届出が寄せられたために、現在対応に時間が掛

153

脆弱性関連情報の届出受付、https://www.ipa.go.jp/security/vuln/report/
IPA – 情報セキュリティ早期警戒パートナーシップガイドライン
https://www.ipa.go.jp/security/ciadr/partnership_guide.html
155 JPCERT/CC、 https://www.jpcert.or.jp/
156 脆弱性対策情報ポータル https:/jvn.jp/15473

ウェブサイト運営者が脆弱性を攻撃される可能性を低減することができます。
関係者

情報セキュリティ早期警戒パートナーシップ メリット

発見者

• 公的機関を介して製品開発者やウェブサイト運営者に脆弱性対応を促すことができる• 製品脆弱性 発見者 、脆弱性対策情報 公表時に名前を掲載することができる• 自社製品に影響する未公表 脆弱性を知ることができる• 脆弱性 対策方法を利用者に広く周知することができる
157。
かっているといった課題もあるようです• 脆弱性問題に真摯に取り組む姿勢を示すことができる
製品開発者

158。
情報セキュリティ早期警戒パートナーシップの体制を下図に示します
ウェブサイト運営者 • 脆弱性 存在が広く知れ渡る前に、修正することができる• 自分で 気づかなかった脆弱性を確認し修正することができる• 自分 ウェブサイト 利用者 安全性向上につながる
情報セキュリティ早期警戒パートナーシップ

脆弱性関連
情報届出

ソフトウェア製品 脆弱性

脆弱性関連
情報通知

受付・分析機関

発
見
者

報告された
脆弱性関連情報
内容確認・検証

調整機関

対応状況 集約、
公表日 調整等

脆弱性対策情報ポータル

対応状況等
公表

ユーザ

公表日 決 定、
海外 調整機関と 連携等
ソフトウェア
システム
製品開発者
導入支援者
検証、対策実施

分析支援機関セキュリティ対策推進協議会等

ウェブアプリ
ケーション
脆弱性

脆弱性関連
情報届出

産総研など

脆弱性関連情報通知

ウェブサイト運営者

政府
企業
個人

個人情報 漏えい時 事実関係を公表

検証、対策実施※IPA:独立行政法人情報処理推進機構, JPCERT/CC:一般社団法人 JPCERTコーディネーションセンター、産 総研：独立行政法人産業技術総合研究所*1) 脆弱性に関する情報であり、脆弱性情報（脆弱性の性質、特徴）、検証方法、攻撃方法[情報セキュリティ早期警戒パートナーシップ]のいずれかに該当する情報を指します。

1

また、民間による脆弱性届出窓口もあり、報告者に報奨金が支払われる脆弱性報奨プログラムも存在します。この届出窓口には、ベンダ独自のものや、ベンダ中立の団体があります。
（作成日：2017 年 8 月 23 日）

InternetWeek 2016 - 「脆弱性情報と賢く付き合う～発見から対策までの最前線～」、
https://www.nic.ad.jp/ja/materials/iw/2016/proceedings/d3/ （資料非公開）
158 http://www.ipa.go.jp/files/000044731.pdf
157

74

Question B-4

OSS の管理について

１．OSS を管理するとはどのようにすることなのですか？
２．ソースコードを OSS として公開する時の品質についての考え方を教えてください。

Answer
１．OSS の管理について
OSS の利用は、開発コスト削減や納期短縮などが期待できるメリットから、企業での OSS
利用が一般的になる一方、その品質やセキュリティ脆弱性への対応、ライセンス条件の面でリスクは存在します。企業が OSS を安全かつ効率的に利用するために、以下の観点から
社内管理基準を策定し、運用を周知化することが望ましいです。
（１）品質
安全で品質の高い OSS を選定して利用するプロセスを構築します。
例）OSS 選定基準とその評価方法、使用履歴と不具合対応の記録、保存（２）開発体制
通常の開発に加えて OSS を意識した体制の構築とその周知をはかります。
例）OSS の実装、テスト、構成管理方法、メンテナンス、人材育成（教育）（３）セキュリティ脆弱性
開発時および製品出荷後も継続して情報の収集と改善に努めます。
例）セキュリティ脆弱性の情報収集、適用要否判断、情報提供、対応ルーチン（４）ライセンス管理
使用したライセンスとそれらの組み合わせ、遵守の状況を記録し保存します。
例）ライセンスの種類とバージョンの記録、保存、組合せ可否、遵守対応（５）コミュニティへの貢献
情報提供など貢献が適時にかつ円滑に行われるプロセスを構築します。
例）ソースコード提供方法、バグ報告などのコミュニティへの情報提供プロセス
２．ソースコードを OSS として公開する時の品質についての考え方
GitHub などへソースコードを公開することは、OSS コミュニティに対する大きな貢献
であり、企業にとっては自社の技術力をアピールすることができます。
製品の場合、企業は品質担保のための社内プロセスに相当の時間をかけていますが、OSSの場合、タイムリーさが評価され、かつ公開後も開発コミュニティの支援が期待できます。

75

したがって OSS を公開する場合、そのソースコードに対して製品と同等レベルの品質は受領者からは求められていないと考えます。
ただし、公開する際のライセンス条件の確認や、不正コードが混入していないか、第三者の知的財産権を侵害していないことの確認は必要です。
（作成日：2018 年 3 月 12 日）

76

C．取引上の留意点
１．OSS と免責条項
２．契約条項等
３．OSS 化と会計・税務処理

77

Question C-1-1

免責条項の文例

OSS を利用したソフトウェアを提供する際、契約上、OSS に関する障害（知的財産権の侵害、セキュリティ障害を含む）について、免責条項を付して提供したいと考えています。
具体的には、どのような文言の免責条項を付すことが考えられますか？

Answer
免責条項で採用されている文言は、大きく分けて以下の４つのケースが考えられます。
① ソフトウェアを提供する事業者の主観面（故意の有無・過失の程度等）にかかわらず、一切の損害賠償義務を免れるとする場合（以下「ケース１」といいます。
）② ソフトウェアを提供する事業者の主観面（故意の有無・過失の程度等）によって、損
害賠償義務を負う場合を限定する場合（以下「ケ―ス２」といいます。）③ 損害賠償額の上限を設定することで、損害賠償義務の範囲を限定する場合（以下「ケ－ス３」といいます。
）④ ソフトウェアを提供する事業者の主観面（故意の有無・過失の程度等）と損害賠償額の上限額の設定を組み合わせることで、損害賠償義務の範囲を限定している場合（以下「ケ－ス４」といいます。
）（１）ケース１：全て免責とする場合
ケース１としては、以下のような文例が考えられます。ただし、本書「C-1-2」で詳述するとおり、訴訟になった場合、故意、重過失が認められると、適用を制限されたり、合意内容が無効とされることも考えられるため、文言とおりの効果が得られるか否かについては疑義が残ります。

【ケース１の文例】
ベンダは、OSS に関して、著作権その他の権利の侵害がないこと及び瑕疵のないことを保証するものではなく、何らの責任を負わないものとする。

（２）ケース２：故意／重過失を除き免責とする場合
ケース２としては、以下のような文例が考えられます。この文案では、ベンダの主観面（障害等の存在を知っていたか否か、知らなかったことについての過失の程度等）を考慮して、瑕疵を知っていたか、若しくは重大な過失によって知らなかった場合、免責の効力

78

が生じないことを文言上も明らかにしている点で、ケース１と異なります。また、経済産業省が公表しているモデル契約書159も、ケース２に分類することができます。

【ケース２の文例】
ベンダは、OSS に関して、著作権その他の権利の侵害がないこと及び瑕疵のないことを保証するものではなく、本契約の締結時に権利侵害又は瑕疵の存在を知りながら、若しくは重大な過失により知らずに告げなかった場合を除き、何らの責任を負わないものとする。

（３）ケース３：損害賠償額を限定する場合
ケース３としては、以下のような文例が考えられます。この文例では、1 項本文で、原則として損害賠償義務を肯定した上、1 項ただし書で、逸失利益を損害賠償の対象外とし、2項で損害賠償額の上限を設定しています。ただし、主観面を考慮せず免責するという点で、
本書「C-1-2」で詳述するとおり、訴訟になった場合、故意、重過失が認められると、適用を制限されたり、合意内容が無効とされることも考えられるため、1 項ただし書や 2 項の文
言とおりの効果が得られるか否かについては疑義が残ります。

【ケース３の文例】
ベンダは、OSS に関して、著作権その他の権利の侵害又は瑕疵が確認された場合、ベンダは、損害賠償義務を負うものする。但し、逸失利益は損害賠償義務の対象外とする。
２

前項の場合、請求原因の如何を問わず、ベンダの損害賠償額は、損害が発生する
直接の原因となった個別契約の契約金額を上限とする。

（４）ケース４：故意／重過失を含む損害賠償額を限定する場合
ケース４としては、以下のような文例が考えられます。ケース３とは異なり、重過失が認められた場合の処理を明記しています。ただし、本書「C-1-2」で詳述するとおり、訴訟になった場合、故意、重過失が認められると、適用を制限されたり、合意内容が無効とさ
159「情報システムの信頼性向上のための取引慣行・契約に関する研究会」～情報システム・モデル取引・契約書～（受託開発（一部企画を含む）、保守運用）〈第一版〉100 頁の「第三者ソフトウェアの利用」に関する【A 案 ベンダが主体で選定する場合】の第 48 条 4 項及び 101 頁の【B 案 ユーザが主体で選定する場合】の第〇条 2 項、102 頁の「FOSS の利用」に関する【A 案 ベンダが主体で選定する場合】の第 49 条 3 項、【B 案 ユーザが主体で選定する場合】の第〇条 2 項参照。
https://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwiH6ZvSnY7a
AhVDk5QKHSNwCZ0QFgg2MAA&url=http%3A%2F%2Fwww.meti.go.jp%2Fpolicy%2Fit_policy%2F
keiyaku%2Fmodel_keiyakusyo.pdf&usg=AOvVaw1h7kCqVtydFZ1-o1HijQGR

79

れることも考えられるため、２項の文言に従った効果が得られるか否かについては疑義が残ります。

【ケース４の文例】
ベンダは、OSS に関して、著作権その他の権利の侵害がないこと及び瑕疵のないことを保証するものではなく、本契約の締結時に権利侵害又は瑕疵の存在を知りな
がら、若しくは重大な過失により知らずに告げなかった場合を除き、何らの責任を負わないものとする。
２

前項に従ってベンダが損害賠償義務を負う場合であっても、請求原因の如何を問わず、ベンダの損害賠償額は、損害が発生する直接の原因となった個別契約の契約金額を上限とする。

（作成日：2018 年 3 月 15 日）

80

Question C-1-2

受託開発において受託者の故意・重過失により免責条項の適用が制限される場合

ソフトウェアの受託開発をするベンダが、OSS の不具合（脆弱性等）を知っていた場合や、知らなかったことについて重過失が認められる場合でも、免責条項に記載された文言とおりの免責の効果を得ることができるのでしょうか？

Answerベンダの「損害賠償義務が免責され又は損害賠償額の責任が制限される」という趣旨の文言が免責条項に記載されていたとしても、訴訟となった場合、ベンダが OSS の瑕疵について存在を知っていた場合や知らなかったことについて重過失が認められる場合は、免責条項の適用が制限され、免責の効果を得ることができない場合があると考えるべきです。
ここでは、東京地裁平成 26 年 1 月 23 日判決／平成 23 年（ワ）第 32060 号を引用して説明します。
１．東京地裁平成２６年１月２３日判決の概要
脆弱性の問題を扱った事例として、東京地裁平成 26 年 1 月 23 日判決（以下「本件」といいます。
）があります。本件について、免責条項の適用との関係で重要と思われる事実を整理すると、以下のとおりです。
【本件の概要】① 原告（ユーザ）はインテリア商材の通信販売等を行う株式会社であり、被告（ベンダ）は業務システムの開発、WEB サイトの制作等を行う株式会社である。
② 被告は原告から、商品の WEB 受注システム（以下「本件システム」という。）の開発について基本契約及び個別契約を締結することで受託し、本件システムを完成させ納品した。
③ 原告が被告から本件システムの引渡しを受けた後、SQL インジェクション攻撃を受け、原告の顧客のクレジットカード情報が流出し、原告に約 3,200 万円の損害が発生した。
④ 被告が SQL インジェクション対応を怠った点に債務不履行を認めた上、原告も、セキ
ュリティ上はクレジットカード情報を保持しない方が良いことを認識し、被告から本件システム改修の提案を受けていながら、何ら対策を講じずにこれを放置した点を考慮して、過失相殺により原告の損害賠償請求が可能となる金額は約 2,262 万円と判断された
160。

160

ベンダの損害賠償義務が免責されない場合であっても、本件の事案のように、過失相殺により損害賠償

81⑤ 原告・被告間で締結した基本契約の第 29 条には以下の記載があることから、更に、損害賠償請求が可能となる金額が、個別契約の契約金額まで限定されるか否かが争われた。
「乙（ベンダ）が委託業務に開連して、乙又は乙の技術者の故意又は過失により、甲（ユーザ）若しくは甲の顧客又はその他の第三者に損害を及ぼした時は、乙はその損害について、甲若しくは甲の顧客又はその他の第三者に対し賠償の責を負うものとする。
（一項）
前項の場合、乙は個別契約に定める契約金額の範囲内において損害賠償を支払うもの
とする。
（二項）
」
本件では、ベンダが損害賠償責任を負うものの、損害賠償額については契約金額を上限とする免責条項（責任制限条項）が規定されていました。しかし、判決では、重過失が認められる場合の免責条項の適用の有無について、免責条項には「一定の合理性がある」としつつも、重過失が認められる場合にも適用することは、「著しく衡平を害するものであって、当事者の通常の意思に合致しない」として、「適用されない」としました。
２．重過失が認められる場合の免責条項（責任制限条項）の適用について
本件では、重過失が認められる場合の免責条項（責任制限条項）の適用について、以下のとおり判示しています。

【重過失が認められる場合の免責条項（責任制限条項）の適用に関する本件の判示内容】
本件基本契約二九条二項は、ソフトウェア開発に関連して生じる損害額は多額に上るおそれがあることから、被告が原告に対して負うべき損害賠償金額を個別契約に定める契約
金額の範囲内に制限したものと解され、被告はそれを前提として個別契約の金額を低額に設定することができ、原告が支払うべき料金を低額にするという機能があり、特に原告が顧客の個人情報の管理について被告に注意を求める場合には、本件基本契約一七条所定の「対象情報」とすることで厳格な責任を負わせることができるのであるから、一定の合理性があるといえる。しかしながら、上記のような本件基本契約二九条二項の趣旨等に鑑みても、被告（その従業員を含む。以下、この（２）項において同じ。
）が、権利・法益侵害の結果について故意を有する場合や重過失がある場合（その結果についての予見が可能か
つ容易であり、その結果の回避も可能かつ容易であるといった故意に準ずる場合）にまで同条項によって被告の損害賠償義務の範囲が制限されるとすることは、著しく衡平を害するものであって、当事者の通常の意思に合致しないというべきである（売買契約又は請負契約において担保責任の免除特約を定めても、売主又は請負人が悪意の場合には担保責任を免れることができない旨を定めた民法五七二条、六四〇条参照。）。
したがって、本件基本契約二九条二項は、被告に故意又は重過失がある場合には適用さ額が減額されることも多い。

82

れないと解するのが相当である（下線は、筆者が加筆）
本件は、最二小判平成 15 年 2 月 28 日と同様の考えに基づくものであると考えられます。
この判例は、宿泊客がホテルを提訴した判例であり、宝飾品を入れたバッグをベルボーイに預けた後、ベルボーイが宿泊客の部屋に運ぶ前に盗難にあったというものです。具体的には、宿泊約款で規定されていた「宿泊客が当ホテル内にお持込みになった物品又は現金並びに貴重品であって、フロントにお預けにならなかったものについて、当ホテルの故意又は過失により滅失、毀損等の損害が生じたときは、当ホテルは、その損害を賠償します。
ただし、宿泊客からあらかじめ種類及び価額の明告のなかったものについては、一五万円を限度として当ホテルはその損害を賠償します。」との特則について、「ホテル側に故意又は重大な過失がある場合に、本件特則により、被上告人の損害賠償義務の範囲が制限されるとすることは、著しく衡平を害するものであって、当事者の通常の意思に合致しない。」と判示しました。
３．重過失の有無の判断について
次に、本件で、ベンダに重過失が認められたか否かを紹介します。
判例をみると、重過失の意義について、最三小判昭和 32 年 7 月 9 日では、「重大な過失とは、通常人に要求される程度の相当な注意をしないでも、わずかの注意さえすれば、たやすく違法有害な結果を予見することができた場合であるのに、漫然これを見すごしたよ
うな、ほとんど故意に近い著しい注意欠如の状態を指すものと解するのを相当とする。」と判示していました。しかし、その後、東京高裁平成 25 年 7 月 24 日判決では、「過失は主観的要件である故意とは異なり、主観的な心理状態ではなく、客観的な注意義務違反と捉えることが裁判実務上一般的になっている。そして、注意義務違反は、結果の予見可能性
及び回避可能性が前提になるところ、著しい注意義務違反（重過失）というためには、結果の予見が可能であり、かつ、容易であること、結果の回避が可能であり、かつ、容易であることが要件となるものと解される。」と判示しており、本件でも、ほぼ同趣旨の判断基準が採用され、以下のとおり判示しています。

【東京地裁平成２６年１月２３日判決】
被告は、情報処理システムの企画、ホームページの制作、業務システムの開発等を行う会
社として、プログラムに関する専門的知見を活用した事業を展開し、その事業の一環として本件ウェブアプリケーションを提供しており、原告もその専門的知見を信頼して本件システム発注契約を締結したと推認でき、被告に求められる注意義務の程度は比較的高度なものと認められるところ、前記のとおり、SQL インジェクション対策がされていなければ、第三者が SQL インジェクション攻撃を行うことで本件データベースから個人情報が流出す83

る事態が生じ得ることは被告において予見が可能であり、かつ、経済産業省及び IPA が、
ウェブアプリケーションに対する代表的な攻撃手法として SQL インジェクション攻撃を挙げ、バインド機構の使用又は SQL 文を構成する全ての変数に対するエスケープ処理を行う
こと等の SQL インジェクション対策をするように注意喚起していたことからすれば、その事態が生じ得ることを予見することは容易であったといえる。また、バインド機構の使用又はエスケープ処理を行うことで、本件流出という結果が回避できたところ、本件ウェブ
アプリケーションの全体にバインド機構の使用又はエスケープ処理を行うことに多大な労力や費用がかかることをうかがわせる証拠はなく、本件流出という結果を回避することは容易であったといえる。
（下線は、筆者が加筆）

本件は、SQL インジェクションの脆弱性が、ウェブアプリケーションに対する代表的な攻撃手法として知られており、対処方法も、事故が発生する約５年前に IPA が公表していたため、ベンダ（被告）の予見可能性及び容易性、結果回避の可能性及び容易性のいずれも肯定されたものと考えられます。
この判例の考え方を前提とすると、仮に OSS の不具合（脆弱性等）により、ユーザに損害が発生した場合でも、ベンダが脆弱性対応を怠ったことについて、故意・重過失が認められる場合、本件と同様、免責条項（責任制限条項）の適用が制限され、免責の効果を得ることができない可能性が高いといえます。
ただし、OSS の脆弱性の対策情報が公開された直後に攻撃を受けた場合には161、結果回避の容易性が否定される等、重過失まで認められない可能性も十分にあります。
もっとも、本件やホテルの荷物の預かりに関する裁判例（最二小判平成 15 年 2 月 28 日）
は、いずれも当事者の合理的な意思に合致するか否かを重視しているものと考えられます。
したがって、契約上、重過失の場合にも損害賠償額の上限を設定しているなど、当事者の意思が、契約書等の文書に記載されている場合（本書「C-1-1」の Answer のケース４の場合等）まで、同様の判断がなされるか否かは判例の蓄積を待つ必要があります。
裁判においては、①契約当事者の交渉力（法人間の契約であるか、あるいは消費者契約であるのか）、②約款による契約であるか、あるいは相対取引による契約であるのか、③過失の程度、④損害の額等の事情を考慮して、免責されるか否かが判断されると考えられます。
（作成日：2018 年 3 月 15 日）

例えば、IPA が発行している「情報セキュリティ 10 大脅威 2015～被害に遭わないために実施すべき対策は？～」24 頁には、OpenSSL の脆弱性について、脆弱性の対策情報の公表日から不正アクセスを検知した日まで約４日という短期間で攻撃が行われた事例が紹介されている。

161

84

Question C-1-3

受託開発におけるベンダのユーザに対する説明義務

OSS を利用して情報システムを受託開発して提供する場合、ベンダがユーザに対して負う
説明義務とは法律上どのように位置づけられ、どのような説明が必要となるのでしょうか？

Answerベンダの説明義務については、ベンダとユーザとの契約が締結される前の企画・提案段階と契約締結後とでは法律的な扱いが異なると思われますので、以下、企画・提案段階と契約締結後の段階に分け、裁判例や経産省モデル契約162の解説を引用しながら整理します。
１．企画・提案段階について
企画・提案段階における、ベンダのユーザに対する説明義務について、東京高裁平成 25
年 9 月 26 日判決は以下のように判示しています。
【東京高裁平成２５年９月２６日判決】
プロジェクトの目標の設定、開発費用、開発スコープ及び開発期間の組立て・見込みなど、プロジェクト構想と実現可能性に関わる事項の大枠が定められ、また、それに従って、プロジェクトに伴うリスクも決定づけられるから、企画・提案段階においてベンダに求められるプロジェクトの立案・リスク分析は、システム開発を遂行していくために欠かせないものである。そうすると、ベンダとしては、企画・提案段階においても、自ら提案するシステムの機能、ユーザーのニーズに対する充足度、システムの開発手法、受注後の開発体制等を検討・検証し、そこから想定されるリスクについて、ユーザーに説明する義務があるというべきである。このようなベンダの検証、説明等に関する義務は、契約締結に向けた交渉過程における信義則に基づく不法行為法上の義務として位置づけられ、控訴人はベンダとしてかかる義務（この段階におけるプロジェクト・マネジメントに関する義務）を負うものといえる。
（下線は、筆者が加筆）
162 「情報システムの信頼性向上のための取引慣行・契約に関する研究会」～情報システム・モデル取引・契約書～（受託開発（一部企画を含む）、保守運用）〈第一版〉平成 19 年 4 月（経済産業省商務情報政策局
情報処理振興課）、
https://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwiH6ZvSnY7a
AhVDk5QKHSNwCZ0QFgg2MAA&url=http%3A%2F%2Fwww.meti.go.jp%2Fpolicy%2Fit_policy%2F
keiyaku%2Fmodel_keiyakusyo.pdf&usg=AOvVaw1h7kCqVtydFZ1-o1HijQGR

85

この判決では、ベンダのユーザに対するリスクの説明義務について、契約締結に向けた交渉過程における信義則に基づく不法行為法上の義務と位置付けています。
また、経産省のモデル契約の解説では、以下のとおり記述されています。

【経産省のモデル契約の解説の抜粋】「ユーザに第三者ソフト及び FOSS の選定の知見等がなく、ベンダがユーザに導入の可否について判断機会及び判断を行うために、合理的に必要とされる情報を与えることなく自主的判断で選択した場合については、ベンダも一定の責任を負う（特に、ベンダは当該ソフトの選定（利用方法、機能上・利用上の制限、保証期間等）について、専門家としての情報提供義務を契約上の責任として負う。）」

上記の経産省のモデル契約の解説では、「情報提供義務」と記述されていますが、説明義務と同義であると考えられます。そして、経産省のモデル契約の解説では、説明義務が要求される時点を明記しないまま「契約上の責任」とのみ記載されています。契約締結以前の段階で契約を締結するか否かを判断するために要求される説明義務については、最判平成 23 年 4 月 22 日163が、債務不履行責任を否定し、不法行為責任の構成を採用していることからすると、今後は、企画・提案段階での説明義務は、不法行為責任の問題であるという前提で判断される可能性が高いといえます。
以上のとおり、企画・提案段階での説明義務については、不法行為法上の責任と位置づけた上、提案書等の提出時に、OSS を採用した場合のリスク（利用方法164、機能上・利用上の制限、保証期間、不具合対応の考え方、ソースコードの提供義務の有無等）を記述し、説明することが必要となる可能性があります。
２．契約締結後の説明義務について
契約締結後における、ベンダのユーザに対する説明義務について、東京高裁平成 25 年 9月 26 日判決は以下のように判示しています。
【東京高裁平成２５年９月２６日判決】
控訴人は、前記各契約に基づき、本件システム開発を担うベンダとして、被控訴人に対し、
本件システム開発過程において、適宜得られた情報を集約・分析して、ベンダとして通常
163

信用協同組合の出資者が、出資前に信用協同組合が債務超過の状態である旨の説明を行わなかったのは説明すべき義務に違反するとして、債務不履行、不法行為等を根拠に信用協同組合に対して損害賠償請求した。
164 企画・提案段階では、ベンダはユーザの要望事項をすべて把握しているわけではなく、説明義務の対象となる利用方法も、提案依頼書で依頼された事項等、ソフトウェアの採否を決定する上で必要となる事
項に限定されるものと考えられる。

86

求められる専門的知見を用いてシステム構築を進め、ユーザーである被控訴人に必要な説明を行い、その了解を得ながら、適宜必要とされる修正、調整等を行いつつ、本件システ
ム完成に向けた作業を行うこと（プロジェクト・マネジメント）を適切に行うべき義務を負うものというべきである。
（下線は、筆者が加筆）したがって、契約締結後に、新たに OSS を使用する必要が生じた場合、ベンダ・ユーザ
間の契約に基づいて、ベンダはユーザに対し、OSS を採用した場合のリスク等についての説明義務を負うものと考えられます。
また、経産省のモデル契約の解説では、以下のとおり記述されており、説明義務の発生根拠について明言はされていませんが、必要に応じて協議することを要求していることから
すると、東京高裁平成 25 年 9 月 26 日判決と同様、説明義務を肯定しているものと考えられます。

【経産省のモデル契約の解説の抜粋】「内部設計の過程で必要となった機能を充足するために、契約締結後に限定的な機能を有する第三者ソフトウェアを選定する場合もあるが、この場合も当該ソフトウェアの利用を決定する前にユーザとの協議を行う必要がある。」

以上のとおり、契約締結後の説明義務違反については、債務不履行責任と構成することも可能であり（不法行為責任を排除する趣旨ではないと考えられます。）、企画・提案段階の場合と同様、ステアリング・コミッティ等の進捗会議において、新たに OSS を採用した
場合のリスク等（利用方法、機能上・利用上の制限、保証期間、不具合対応の考え方、ソースコードの提供義務の有無等）について説明することが必要となる可能性があります。
（作成日：2018 年 3 月 15 日）

87Question C-1-4

受託開発でユーザが OSS を選定した場合のベンダの責任

ユーザ側で OSS を選定した場合のベンダの責任は、ベンダ側で選定した場合と比較して軽減されるのでしょうか？

Answer
ベンダ側で OSS を選定した場合、ベンダは、瑕疵担保責任や説明義務を負うことになり（本書「基礎 3-2」、
「C-1-3」）、免責条項（免責特約）に基づく合意が認められれば、これに従うことになります（本書「C-1-1」及び「C-1-2」）。これに対し、ユーザ側で OSS を選定した場合、ベンダの責任は軽減される可能性があります。
１．民法６３６条本文の適用の有無について
民法 636 条では、ベンダの瑕疵担保責任について以下のとおり規定し、瑕疵担保責任に基づく契約の解除や損害賠償請求について、注文者（ユーザ）の与えた指示によって生じたときは、適用しないとしています165。

【民法６３６条】
前二条の規定は、仕事の目的物の瑕疵が注文者の供した材料の性質又は注文者の与えた指図によって生じたときは、適用しない。ただし、請負人がその材料又は指図が不適当であることを知りながら告げなかったときは、この限りでない。
（下線は、筆者が加筆）
ユーザが OSS を選定した場合、現行法及び改正案の 636 条で規定されている「注文者の与えた指図」に該当し、ベンダの瑕疵担保責任等が否定される可能性があります。
もっとも、請負人が設計に際して注文者の希望をいれただけでは「注文者が与えた指図」には当たらない（大判昭和 10.5.31166）とされ、請負人が専門家であり、注文者が素人である場合には、「注文者の与えた指図」に該当するか否かは慎重に判断すべきとの指摘もあります167。このことからすると、単に、費用を低減するために OSS を使ってほしいとの要望があったというだけでは「注文者の与えた指図」に該当しないと考えられます。逆に、特平成 29 年 5 月 26 日に可決し、同年 6 月 2 日に公布された改正民法第 636 条においても、同趣旨の規定がある。
166 機械装置の製作に関する請負契約において、注文者の希望を受け入れただけでは、「注文者の指図」に該当しないとした事例である。
167 論点体系判例民法 6 契約Ⅱ 62 頁（第一法規）
16588

定の OSS を利用することを受注の条件としているような場合や、連携させるシステムへの影響等を考慮して、ユーザから OSS に修正パッチの適用をしないように依頼された場合等
は、「注文者の与えた指図」に該当する可能性が高いのではないかと考えられます。
また、ユーザが OSS を選定した場合は、ベンダが瑕疵担保責任等に基づく損害賠償義務を負う場合であっても、損害額を算定するにあたり、過失相殺事由として考慮される可能性があります（民法 418 条）。
２．民法６３６条但書の適用の有無についてユーザが OSS を選定した場合、ベンダの説明義務が軽減される可能性があります。
ユーザが選定した OSS を利用することが受注の前提となっており、民法 636 条で規定されているような「注文者の与えた指図」に該当すると認められる場合、指図する以上、ユーザ自身も OSS を使用したリスクを把握しておくべきであり、少なくとも、ベンダが選定した場合における信義則を根拠とした説明義務（本書「C-1-3」で言及した説明義務）と同等の説明義務が課せられる可能性は低いのではないかと考えられます。
ただし、民法 636 条ただし書きにおいても、「指図が不適当であることを知りながら告げなかったとき」には、瑕疵担保責任等を負うことになるとされているため、ユーザが OSSを選定した場合であっても、ベンダが OSS のリスク（例えば、脆弱性等の不具合が解消されていないこと等）について知っていた場合には、説明が必要となります。なお、民法の明文の規定では、「請負人がその材料又は指図が不適当であることを知りながら告げなかったとき」とされており、過失により不適当であることを知らなかった場合についての規定はありませんが、重過失により不適当であることを知らずに告げなかった場合には、瑕疵
担保責任等を負うと解釈される余地があります168。
また、経産省のモデル契約を使用している場合、「権利侵害又は瑕疵の存在」について、「重大な過失により知らずに告げなかった場合」、ベンダが責任を負うことが明記されています169。
したがって、ユーザが OSS を選定した場合でも、少なくとも、当該 OSS の脆弱性に関する情報が何年も前から公開170された上、報道等でも頻繁に取り上げている等して、容易に脆弱性情報を確認することができたにもかかわらず、ベンダが全く調査していないため
例えば、東京地裁平成 15 年 5 月 16 日判決は、民法 572 条についての裁判例であるが、「被告の重過失は悪意と同視できる以上、重過失ある場合も民法 572 条が類推適用されると解するのが相当」と判示している。
169 「情報システムの信頼性向上のための取引慣行・契約に関する研究会」～情報システム・モデル取引・契約書～（受託開発（一部企画を含む）、保守運用）〈第一版〉平成 19 年 4 月（経済産業省商務情報政策局
情報処理振興課）102 頁
https://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwiH6ZvSnY7a
AhVDk5QKHSNwCZ0QFgg2MAA&url=http%3A%2F%2Fwww.meti.go.jp%2Fpolicy%2Fit_policy%2F
keiyaku%2Fmodel_keiyakusyo.pdf&usg=AOvVaw1h7kCqVtydFZ1-o1HijQGR
170 例えば、JVN iPedia（IPA と JPCERT コーディネーションセンターが共同運営している脆弱性対策情報
データベース）の公開情報などが考えられるが、ベンダのみならず、ユーザも指図をする前提として、公開情報を活用してリスクの有無を検討すべきであるといえる。
168

89

に、OSS のリスクについて知らなかったという状況にならないようにしておく必要があり（作成日：2018 年 3 月 15 日）

そうです。

90

Question C-1-5

契約書等の書面による合意がない取引でユーザから免責の同意を得る方法

１．契約書等の、記名・捺印をした書面による合意がない取引類型において、OSS を含む
ソフトウェアの免責条項に関するユーザの同意を得るためには、どのような方法を採用すれば良いのでしょうか？
（１）ソフトウェア製品を CD-ROM 等の媒体に記録して提供する場合（２）ソフトウェアを組み込んだ機器を提供する場合（３）WEB サイトからダウンロードする方式でソフトウェアを提供する場合
２．OSS を含むソフトウェアを提供する会社が、修正パッチを提供する場合、修正パッチを提供する度に免責条項に関するユーザの同意を得る必要があるのでしょうか？
また、OSS を開発したコミュニティ等が提供した修正パッチをユーザが自ら入手し、このパッチに不具合が発生した場合、免責の効果に影響を及ぼすことはあるのでしょうか？

Answer
上記の取引においてベンダが免責条項で規定した内容について、法律上の効果を得るためには、前提として、ユーザが商品を使用する前に免責条項の内容を把握し、その同意を得る必要があります。このような視点から、各取引類型について、どのような対応をすべきか検討した上で、修正パッチも免責の対象としたい場合の取り扱いについて説明します。
１．ソフトウェア製品を CD-ROM 等の媒体に記録して提供する場合
ソフトウェア製品を CD-ROM 等の媒体に記録して提供する場合、ユーザの同意を得る方
法としては、以下の二つの契約方式が知られています171。
・シュリンクラップ契約方式
ライセンス条件をライセンサーが一方的に定め、媒体の引渡し時点ではライセンス
条件について明示の合意がないままフィルムラップやシール等を破った時点で契約が成立するという方式
・クリックオン契約方式
ライセンス条件をライセンサーが一方的に定め、媒体の引渡し時点ではライセンス
条件について明示の合意がないまま、プログラム等を初めて起動しライセンス契約締
結画面で同意した時点で契約が成立するという方式「電子商取引及び情報財取引等に関する準則」平成 29 年 6 月（経済産業省）220 頁～222 頁
http://www.meti.go.jp/press/2017/06/20170605001/20170605001-1.pdf
17191シュリンクラップ契約方式で提供する場合、商品パッケージのフィルムラップやシールを破った時点でユーザが免責条項の内容を把握することができていなければ、ユーザが同意したと評価することは困難です。
したがって、ユーザが免責条項の内容を事前に把握できる状況にする必要があります。
例えば、①商品パッケージに、ユーザが十分に認識できる方法で免責条項の内容を表示する、②免責条項が含まれる約款等を WEB サイト上に公開し、ユーザが十分に認識できる方
法で商品パッケージに免責条項の URL を表示する方法等が考えられます。
クリックオン契約方式で提供する場合、ライセンス契約締結画面においてユーザが免責条項の内容を確認した上で、これに同意していただく必要があります。具体的には、免責条項が明記された約款を表示し、ユーザに「同意」ボタン等をクリックしていただくことで同意を得るという方法が一般的に行われています172。この場合、ユーザに免責条項の内容を十分に確認していただくという趣旨で、ライセンス契約締結画面全体をスクロールさせ、約款等の内容をすべて確認した上でないと「同意」ボタンをクリックできないように設計したり、「同意」ボタンをクリックしない場合は、ソフトウェアのインストールを続行できないという設計にしたりすることが望ましいと考えられます173。
２．ソフトウェアを組み込んだ機器を提供する場合
デジタルカメラ等の組込型の機器にソフトウェアを記録して提供する場合、組込型の機器についての売買契約を締結する時点（代金の支払いをする時点）では、ユーザが免責条項の内容を把握することができないと、ユーザの同意を得たと評価することは困難です。
したがって、前述のシュリンクラップ方式の場合と同様、①組込型の機器の商品パッケージに、ユーザが十分に認識できる方法で免責条項の内容を表示する、②免責条項が含まれる約款等を WEB サイト上に公開し、ユーザが十分に認識できる方法で商品パッケージに免責条項が公開されている URL を表示する等、ユーザが免責条項の内容を把握できる状況を用意する必要があると考えられます。

172

この方法を採用した場合、ライセンス契約締結画面において、免責条項を含むライセンス条項に同意できない場合の返品の可否も問題となりうるが、「電子商取引及び情報財取引等に関する準則」平成 29 年
6 月（経済産業省）227 頁～228 頁では、
「単に返品不可の特約が明示されていることのみを理由として返品を認めないと解することは相当でなく、不同意の場合であっても返品できないことについて個別同意があったと認められる場合、例えば、返品ができない旨が販売店から口頭で説明されたり、媒体の外箱に明らかに認識できるような形態で明示されていた場合において、これに同意の上、代金を支払った場合に限り、ライセンス契約に不同意であることを理由として返品することができないものと解される」とされている。
173 「電子商取引及び情報財取引等に関する準則」平成 29 年 6 月（経済産業省）221 頁では、「
（同意ボタ
ンをクリックした場合返品できない（ライセンス契約が成立した）と思われる例」として、「画面上でライセンス契約の内容を最後までスクロールさせた後に同意ボタンをクリックした場合」と記載されている。
http://www.meti.go.jp/press/2017/06/20170605001/20170605001-1.pdf

92３．WEB サイトからダウンロードしてソフトウェアを提供する場合
ベンダが WEB サイトからダウンロードする方式でソフトウェアを提供する場合も、ユー
ザが免責条項の内容を把握した上で、その同意を得る必要があり、ダウンロード前に免責条項を確認していただくことが望ましいとされています174。
この場合、前述したクリックオン契約方式で提供する場合と同様、ダウンロード前にライセンス契約締結画面を表示し、ユーザに「同意」ボタン等をクリックしていただくことで同意を得ることになるものと考えられ、ライセンス契約締結画面全体をスクロールさせ、
約款等の内容をすべて確認した上でないと「同意」ボタンをクリックできないように設計したり、「同意」ボタンをクリックしない場合は、ソフトウェアのダウンロードができない
ように設計したりすることが望ましいと考えられます。
４．OSS の不具合についての修正パッチも免責の対象とする場合
ソフトウェアを開発した会社が修正パッチを提供する場合、実務としては、「当初の利用
規約や約款において修正パッチにも免責の効力が及ぶことを明記して同意を得ておく」という方法（以下「方法１」といいます。）と、「修正パッチを提供する都度、同意を得る」という方法（以下「方法２」といいます。）のいずれも利用されています。
方法２は、都度、同意を得るため、方法１よりもより確実な方法といえますが、取引当事者の合理的な意思を考慮すると、「商品本体については免責の対象となっているが、修正パッチは免責の対象とならない」と考える当事者は少数ではないかと思われます。
したがって、方法１でも、方法２と同様、同意による免責の効果を得ることができるのではないかと考えられます。
また、OSS を含むソフトウェアを提供する会社ではなく、OSS を提供する会社や OSSを開発したコミュニティ等が修正パッチを提供し、ユーザがこれを独自で入手して利用している場合は、OSS を利用したソフトウェア製品を提供する会社とユーザとの間でなされた同意による免責の効果に影響を及ぼすものではないと考えられます。
５．上記の措置を講じたとしても、免責の効果が得られない場合
上記のような措置を講じたとしても、免責の効果が得られない場合があることは、本書「C-1-2」、「C-1-6」、「C-1-7」で詳述したとおりです。
（作成日：2018 年 3 月 15 日）

174

ダウンロード後、ソフトウェアを使用する前に同意を得るという方法も考えられなくもないが、同意できない場合、返金処理等が発生する可能性があるため（「電子商取引及び情報財取引等に関する準則」平成29 年 6 月（経済産業省）232 頁）、本稿では推奨しない。

93Question C-1-6

消費者契約法により免責条項の適用が制限される場合

消費者契約法が適用される取引において、OSS に関する免責条項の適用が制限される場合はありますか？

Answer
消費者契約法が適用される消費者契約とは、消費者と事業者との間で締結される契約175をいい（同法 2 条 3 項）
、OSS に関する免責条項の適用が制限される場合があると考えられます。例えば、OSS 開発をしている事業者と個人消費者が OSS ライセンスに基づく契約をした場合の免責条項や、OSS を利用してソフトウェアを開発した事業者と消費者が契約を締結した場合における免責条項等が対象になると考えられます。消費者契約法の規定を確認した上、関連する裁判例について説明します。
１．消費者契約法の規定について
消費者契約法では、消費者契約において、情報や交渉力において事業者よりも劣位にある消費者の正当な利益が不当な内容の契約条項により侵害された場合に、不当条項の効力を否定することで消費者の利益を回復することを目的とし176、同法 8 条において、以下のとおり免責条項の効力を否定しています。

175

消費者契約法において、「消費者」とは、個人（事業として又は事業のために契約の当事者となる場合
におけるものを除く。
）をいい（消費者契約法 2 条 1 項）、「事業者」とは、法人その他の団体及び事業として又は事業のために契約の当事者となる場合における個人をいい（同法 2 条 2 項）、
「消費者契約」とは「消費者」と「事業者」との間で締結される契約をいいます（同法 2 条 3 項）
。OSS のコミュニティが「法人その他の団体」に該当し、「事業者」となるのかという点について、「コンメンタール消費者契約法【第２版】
日本弁護士連合会/消費者問題対策委員会（編）」（商事法務）38 頁によると、「その他の団体」とは、民法上の組合のほか、法人格を有していない労働組合をはじめ、客観的には法人となるに適した実態をもつ社団や財団である。社会的に存在している「団体」がすべて「事業者」となるわけではなく、本法の目的に照らし、消費者契約の当事者となり、消費者との関係で、情報や交渉力において優位に立っていると評価できる団体である。
」「「その他の団体」にあたるかどうかは、法人格なき社団に関する最高裁判例（最判昭39･10･15 民集 18 巻 8 号 1671 頁）で示された要件である、（ⅰ）団体としての組織を備え、（ⅱ）代表の方法、総会の運営、財産の管理、その他社団としての主要な点が規則によって確定していることが、本法でもその基準の１つとなりうるが、前述したとおり、本法の目的に照らして総合的に判断されるべきである。
」とされており、コミュニティ毎に判断が必要となるものと考えられる。
176 「逐条解説消費者契約法【第 2 版】消費者庁企画課編」（商事法務）176 頁。

94

【消費者契約法第８条】
次に掲げる消費者契約の条項は、無効とする。
一 事業者の債務不履行により消費者に生じた損害を賠償する責任の全部を免除する条項
二 事業者の債務不履行（当該事業者、その代表者又はその使用する者の故意又は重大な過失によるものに限る。）により消費者に生じた損害を賠償する責任の一部を免除する
条項
三 消費者契約における事業者の債務の履行に際してされた当該事業者の不法行為により消費者に生じた損害を賠償する民法の規定による責任の全部を免除する条項
四 消費者契約における事業者の債務の履行に際してされた当該事業者の不法行為（当該事業者、その代表者又はその使用する者の故意又は重大な過失によるものに限る。）に
より消費者に生じた損害を賠償する民法の規定による責任の一部を免除する条項
五 消費者契約が有償契約である場合において、当該消費者契約の目的物に隠れた瑕疵があるとき（当該消費者契約が請負契約である場合には、当該消費者契約の仕事の目的物に瑕疵があるとき。次項において同じ。）に、当該瑕疵により消費者に生じた損害を賠償する事業者の責任の全部を免除する条項
要するに、消費者契約法の債務不履行責任及び不法行為責任については、事業者の損害賠償責任を全部免除する条項や、事業者の重過失が認められる場合に損害賠償責任の一部でも免除する条項は、無効とされています。
また、瑕疵担保責任については、有償契約であることを前提として、事業者の損害賠償責任の全部を免除する条項を無効としています。
２．消費者契約法の規定を考慮して免責条項の適用を制限した裁判例
裁判例においても、インターネットによる外国為替証拠金取引を行なっていた個人が、システムの不具合により損害を被ったとして、取引業者に対し損害賠償請求した事例に関する判決（東京地裁平成 20 年 7 月 16 日判決）のように、消費者契約法 8 条の規定を考慮して、免責条項の適用を制限したものがあります。

【東京地裁平成２０年７月１６日判決】
本件約款２２条(７) C は、「次に掲げる損害については、当社は免責されるものとします。」、「当社のコンピュータシステム、ソフトウェアの故障、誤作動、市場関係者や第３者が提供するシステム、オンライン、ソフトウェアの故障や誤作動等と取引に関係する一切のコンピュータのハードウェア、ソフトウェア、システム及びオンラインの故障や誤作動により生じた損害」と規定していることが認められる。しかし、消費者契約法８条１項１号が、「事業者の債務不履行により消費者に生じた損害を賠償する責任の全部を免除する条項」
を、同項３号が、「消費者契約における事業者の債務の履行に際してされた当該事業者の不95

法行為により消費者に生じた損害を賠償する民法の規定による責任の全部を免除する条
項」をそれぞれ無効とする旨定めていることに照らせば、本件約款４条(４)及び２２条(７) C
は、コンピュータシステム、通信機器等の障害により顧客に生じた損害のうち、真に予測不可能な障害や被告の影響力の及ぶ範囲の外で発生した障害といった被告に帰責性の認められない事態によって顧客に生じた損害について、被告が損害賠償の責任を負わない旨を規定したものと解するほかはなく、本件約款４条(５)は、被告とヘッジ先とのカバー取引が被告の責に帰すべき事由により成立しない場合にまで、原告と被告との売買が成立しない
ことについて被告を免責する規定であるとは解し得ない。
（下線は、筆者が加筆）したがって、ソフトウェア（OSS が含まれている場合を含むがこれに限られない）の提供を前提とする消費者契約において、消費者に発生した損害を全部免責する規定を契約書や約款等に規定していたとしても、消費者契約法 8 条 1 項１号ないし 4 号に該当する場合
は、債務不履行や不法行為に基づく損害賠償義務は、免責規定が無効と判断され、又は、適用が制限され、全部免責される可能性は低いし、瑕疵担保責任に基づく損害賠償義務については、有償契約の場合、消費者契約法 8 条 1 項 5 号に該当し、免責規定が無効と判断され、又は、適用が制限され、全部免責される可能性は低いと考えられます。
（作成日：2018 年 3 月 15 日）

96

Question C-1-7

製造物責任法上の責任を排除する免責条項について

製造物責任法が適用される場合において、契約で製造物責任法上の責任を排除する免責特約に合意していたとしても、このような免責特約の適用が制限される場合はありますか？

AnswerOSS の不具合によって事故が発生し、製造物責任法 3 条本文が適用される場合、免責特約が無効であると判断される可能性が高いと考えられます。以下、同法が適用される場面を確認した上で、事例を設定して検討することとします。
１．製造物責任法の適用場面
同法 3 条本文では、「製造物」177に「欠陥」があり、これにより「他人の生命、身体又は財産を侵害した」場合における「製造業者等」178の損害賠償義務を規定しています。

【製造物責任法３条】
製造業者等は、その製造、加工、輸入又は前条第三項第二号若しくは第三号の氏名等の表示をした製造物であって、その引き渡したものの欠陥により他人の生命、身体又は財産を侵害したときは、これによって生じた損害を賠償する責めに任ずる。ただし、その損害が当該製造物についてのみ生じたときは、この限りでない。
同法の「製造物」とは、「製造又は加工された動産をいう」と定義されています（同法 2条 1 項）。無体物であるソフトウェアそれ自体は「製造物」に該当しないと解釈されていますが、ソフトウェアがハードディスクやメモリ等に記憶され、製品の一部となっている場
合には、製品全体について製造物責任法上の問題が生じると考えられています179。
また、「欠陥」とは、「当該製造物の特性、その通常予見される使用形態、その製造業者
等が当該製造物を引き渡した時期その他の当該製造物に係る事情を考慮して、当該製造物が通常有すべき安全性を欠いていることをいう。
」と定義されています（同法 2 条 2 項）。
ソフトウェアには不具合がつきものですが、不具合が発生したからといって、直ちに製造
厳密には、製造物責任法 3 条は、「製造、加工、輸入又は前条第三項第二号若しくは第三号の氏名等の表示をした製造物」と規定している。
178 「製造業者等」とは、同法 2 条 3 項 1 号ないし 3 号に該当する者をいう。
179 「製造物責任 判例ハンドブック」（青林書院）33 頁、「逐条講義 製造物責任法－基本的考え方と裁判例」（勁草書房）38 頁等
17797

物責任の問題となるわけではなく、「安全性を欠いている」ことが要件となっています。例
えば、検索に時間がかかる、希望したとおりの仕様になっていないというだけでは、「安全性を欠いている」とはいえず、このような場合には、製造物責任法の適用はないものと考えられます180。これに対し、OSS の不具合により携帯端末の発火事故が発生し、これにより利用者が負傷した場合には、「安全性を欠いている」との要件を満たすことになると考えられます。
２．免責規定の適用の有無
同法 4 条は、製造業者等の免責事由（開発危険の抗弁、設計指示の抗弁）を明文で規定しており、これらの要件を満たす場合、製造業者等は免責されます181。
法律で明記された免責事由以外に、当事者間の合意で損害賠償義務が免責されるかという点について、東京高裁平成 25 年 2 月 13 日判決（自衛隊ヘリコプターの落着事故について、国がヘリコプターのエンジン製造業者を提訴した判例）では、以下のとおり判示し、公序良俗に反する法律行為であることを根拠に、民法 90 条により、合意が無効となる可能性があることを示唆しています。

【東京高裁平成２５年２月１３日判決】
製造物の欠陥は、人の生命、身体を損なうというような重大の損害を発生させる可能性もあるものであるから、一般に、法の定める製造物責任を制限、排除する合意については、
民法九〇条に反する可能性があるというべきである。仮に、契約当事者が被控訴人（国）である本件においては、そのような合意も民法九〇条に反しないと解する余地があるとしても、控訴人も、被控訴人も、本件製造請負契約の締結に当たって、本件エンジンの欠陥は本件事故機の墜落につながり、本件事故機だけでなく、搭乗者の生命、身体を損なうことになりかねないことを十分に予見していたものと認められるから、そのような重大な損害を発生させる可能性のある本件エンジンの欠陥による製造物責任を制限、排除する合意がなされたとすれば、疑義を許さない明確な合意がなされたはずである。
（下線は、筆者が加筆）

更に、立法過程での法務省の説明では、当事者間で免責に関する特約が締結されていた

180「製造物責任 判例ハンドブック」（青林書院）33 頁
製造物責任法 4 条は、以下のとおり規定している。
「前条の場合において、製造業者等は、次の各号に掲げる事項を証明したときは、同条に規定する賠償の責めに任じない。
一 当該製造物をその製造業者等が引き渡した時における科学又は技術に関する知見によっては、当該製造物にその欠陥があることを認識することができなかったこと。
二 当該製造物が他の製造物の部品又は原材料として使用された場合において、その欠陥が専ら当該他の製造物の製造業者が行った設計に関する指示に従ったことにより生じ、かつ、その欠陥が生じたことにつき過失がないこと。
」
181

98

としても「当該特約は公序良俗違反（民法 90 条）により無効と判断される場合が多いと考えられる。
」と説明され、少なくとも人身損害に関する免責特約は公序良俗違反を理由に一律に無効となるとの解釈がなされています。
したがって、これらの裁判例等に鑑みると、免責条項により、製造業者等が製造物責任法 3 条に基づく損害賠償義務を免責される場面は、相当限定されるといえます。
３．事例検討
例えば、「事業者 Y３が開発した充電器の制御に利用する OSS を、充電器メーカである事
業者 Y２が利用して充電器を開発し、携帯端末を製造販売している事業者Ｙ１に販売した。
事業者Ｙ１は Y２から購入した充電器を部品として携帯端末を開発し、ユーザ X に販売した。携帯端末を利用したユーザ X の従業員が、OSS の不具合が原因による発火事故で負傷したため、Y１ないし Y３に対し、損害賠償請求しようとしている。ただし、事業者 Y１・
ユーザ X 間の契約では、製造物責任法上の責任を排除する趣旨の免責特約が規定されている。
」という場面を前提として製造物責任法上の Y１ないし Y３の責任を検討してみます。
携帯端末を販売
製造物責任を排除する免責特約が規定

Y１

X

OSS で制御する充電器を提供

Y２
X：携帯端末のユーザ
Y1：携帯端末の製造販売業者
OSS を提供

Y2：携帯端末の充電器の製造販売業者
Y3：充電器を制御する OSS の開発業者

Y３（１）Y１の責任
Y１・X 間では、製造物責任法上の責任を排除する趣旨の免責特約が合意されていますが、前述のとおり、人身損害に関する免責特約は無効であると判断される可能性が高いと考え99られます。
したがって、同法 3 条の要件を満たしていると考えられる上記の事例では、同法 4 条により免責されない場合、Y１は X に対し、同法 3 条に基づく損害賠償義務を負うものと考えられます。
（２）Y２の責任
Y２・X 間では、契約関係がない場合が多いと思われますので、免責特約の検討をするまでもありません。また、同法 3 条の要件を満たしていると考えられる上記の事例では、同法 4 条により免責されない場合、Y２が X に対して同法 3 条に基づく損害賠償義務を負うものと考えられます。仮に、Y２・X 間に契約が成立しており、製造物責任法上の責任を排除する趣旨の免責特約が規定されていたとしても、Y１の場合と同様、人身損害に関する免責特約は無効であると判断される可能性が高いので、結局、同法 3 条に基づく損害賠償義
務を負うものと考えられます。
（３）Y３の責任Y３が提供する OSS それ自体は無体物であって「製造物」に該当しないため、同法３条に基づく損害賠償義務を負わないと考えられます。ただし、民法 709 条（不法行為による損害賠償）の要件を満たす場合（例えば、故意に事故を起こす目的で OSS に不具合を混入した場合等）、不法行為責任を負うものと考えられます。
（作成日：2018 年 3 月 15 日）

100

Question C-2-1

ソフトウェア開発委託契約について①

１．OSS に留意した委託先へのソフトウェア開発委託契約書として、モデル契約書はありますか？
２．自社ソフトウェアの一部の開発を、委託先に発注する場合、こちらが許可していない
OSS が含まれないようにするために、契約書で縛ることを考えています。どのような条項がいいですか？ また、注意点はありますか？（ソフトウェア開発委託契約書における OSS への対応）
３．ユーザから特定の OSS の利用を指示された場合と、ベンダから提案する場合とで異なる点がありますか？

Answer
１．ソフトウェア開発委託契約に関するモデル契約書
経済産業省商務情報政策局情報処理振興課「情報システムの信頼性向上のための取引慣
行・契約に関する研究会」（平成 19 年 4 月）182では、ユーザがベンダに対して、ソフトウ
ェア開発を委託する場合のモデル契約書「『情報システムの信頼性向上のための取引慣行・契約に関する研究会』～情報システム・モデル取引・契約書～（受託開発（一部企画を含む）、保守運用）〈第一版〉」（以下「経産省モデル契約」といいます。）を提供しています。
経産省モデル契約第 49 条（FOSS の利用）では、ベンダは OSS の瑕疵や権利侵害の有無を完全には管理できないとし、OSS の採否の最終的な判断をユーザに委ね、OSS の利用のリスクについて、その採用を決定したユーザが負担することとしています。その上で、OSS の選定をユーザとベンダのどちらが主体的に行うかによって、ベンダの負うべき責任の範囲を区別し、ベンダが主体的に OSS を選定する場合には、ベンダに情報提供義務を課し、OSS の利用についてユーザの負担する責任とのバランスをとっています。
また、納品物に利用した OSS に起因する第三者の知的財産権侵害については、ベンダは一切の責任を負わず、そのリスクをユーザが引き受けるとしています（経産省モデル契約
第 47 条（知的財産権の侵害の責任）参照）。
ベンダが委託先へ開発の一部を委託する契約の場合も同様の考え方が参考になると思われます。
２．委託先による OSS の混入の防止
自社が、意図しない OSS の混入を防止するため、契約において、委託先に対して、OSS
182

http://www.meti.go.jp/policy/it_policy/softseibi/index.html
101を利用したソフトウェア開発を明示的に禁止するといった方法が考えられます。
また、委託先の同意が得られるのであれば、このような契約上の義務に加え、委託先にOSS の検証・管理ツール（本書「B-1-3」参照）を導入し、ソフトウェアの納入前に当該ツールを用いて実際に OSS が含まれていないことの確認を求めることも有効であると考えられます。その場合、OSS の検証・管理ツールの導入コストの費用負担等の詳細を予め合意しておかないと将来疑義が生ずるおそれがありますので、注意が必要です。
（甲：自社、乙：委託先）
第○条 乙は、本契約に別段の定めがある場合183又は別途甲の書面による同意を得た場
合を除き、受託業務を遂行するに当たり、本ソフトウェアに OSS を利用しないものとする。
（OSS の検証・管理ツールを導入することについて、委託先の同意が得られた場合に追加することが想定される条項）
２． 乙は、本ソフトウェアの納入に当たり、甲の指定した OSS の検証・管理ツールを用いて、納品物に OSS が含まれていないことを確認し、その結果を書面で甲に交付するものとする。

３．OSS の選定主体の違いによる責任分担
ユーザが特定の OSS の利用を指示する場合と、ベンダから提案する場合とでは、ベンダの法的な責任が異なってきます。詳細は、本書「C-1-4」を参照ください。
経産省モデル契約第 49 条（FOSS の利用）では、OSS の選定をユーザとベンダのどちらが主体的に行ったかにより、２つの条項案（「【A 案 ベンダが主体で選定する場合】」、「【B 案
ユーザが主体で選定する場合】」）を用意しています。ただし、ユーザ、ベンダのいずれが主体となって選定するかにかかわらず、情報システムに関する専門家であるベンダは、権利侵害又は瑕疵の存在を知りながら、若しくは重大な過失により知らずに告げなかった場合には責任を免れないとしています。
（１）ベンダが OSS 選定の主体となる場合
ベンダが主体となって OSS を選定し、その利用を提案する場合、ユーザが OSS の利用を評価・検討できるよう、ベンダに以下の情報の提供義務を課し、他方、ユーザは、ベンダから提供を受けた情報を自らの責任で評価・検討し、OSS の採否を決定するとしています。
① OSS の性格に関する情報（利用許諾条項、機能、開発管理コミュニティの名称など）
183

経産省モデル契約第 49 条のような規定が想定されている。

102

② OSS の機能上の制限事項、品質レベル184等に関して適切な情報（２）ユーザが OSS 選定の主体となる場合
上記のとおり、ベンダが権利侵害や瑕疵の存在を知りながら、若しくは重大な過失によ
り知らずに告げなかった場合を除き、ベンダは OSS の利用について責任を負いません。ユーザの指示でベンダに OSS の利用を求める場合、ユーザは、第三者との間で OSS の保守、障害対応支援契約の締結等の必要な措置を講じるものとしています。
【参考】
以下、経産省モデル契約より第 49 条（FOSS の利用）と第 47 条（知的財産権の侵害の責任）を以下に抜粋します。
（甲：ユーザ、乙：ベンダ）※第 49 条（FOSS の利用）
【A 案 ベンダが主体で選定する場合】（FOSS の利用）
第 49 条 乙は、本件業務遂行の過程において、本件ソフトウェアを構成する一部としてFOSS を利用しようとするときは、当該 FOSS の利用許諾条項、機能、開発管理コミュニ テ
ィの名称・特徴など FOSS の性格に関する情報、当該 FOSS の機能上の制限事項、品質レベル等に関して適切な情報を、書面により提供し、甲に FOSS の利用を提案するもの とする。
2. 甲は、前項所定の乙の提案を自らの責任で検討・評価し、FOSS の採否を決定する。
3. 乙は、FOSS に関して、著作権その他の権利の侵害がないこと及び瑕疵のないことを保証するものではなく、乙は、第 1 項所定の FOSS 利用の提案時に権利侵害又は瑕疵の存在を知りながら、若しくは重大な過失により知らずに告げなかった場合を除き、何らの責任を負わないものとする。

【B 案 ユーザが主体で選定する場合】（FOSS の利用）
第○条 甲の指示により乙に本件ソフトウェアを構成する一部として FOSS を利用させる
場合、甲は、甲の費用と責任において、甲と第三者との間で FOSS の保守、障害対応支援契約の締結等、必要な措置を講じるものとする。
2. 乙は、前項所定の FOSS の瑕疵、権利侵害等については、当該 FOSS 利用の指示を甲から受けた時に、権利侵害又は瑕疵の存在を知りながら、若しくは重大な過失により知らずに告げなかった場合を除き、何らの責任を負わない。
OSS の機能上の制限や品質レベルは抽象的であるため、これらの情報提供にあたっては、ユーザ・ベ
ンダ間で内容につき十分な協議が必要になると思われる。
184

103

※第 47 条（知的財産権の侵害の責任）【A 案】（ユーザが権利者に対して支払うこととなった損害賠償額等をベンダが負担）（知的財産権侵害の責任）
第 47 条 甲が納入物に関し第三者から著作権、特許権その他の産業財産権（以下本条において「知的財産権」という。
）の侵害の申立を受けた場合、次の各号所定のすべての要件が充たされる場合に限り、第 53 条（損害賠償）の規定にかかわらず乙はかかる申立によって甲が支払うべきとされた損害賠償額及び合理的な弁護士費用を負担するものとする。但し、第三者からの申立が甲の帰責事由による場合（甲乙間で別段合意が ない限り、第 48 条に定める第三者ソフトウェア又は第 49 条に定める FOSS に起因する場合を含む。
）にはこの限りではなく、乙は一切責任を負わないものとする。
① 甲が第三者から申立を受けた日から○日以内に、乙に対し申立の事実及び内容を通知すること② 甲が第三者との交渉又は訴訟の遂行に関し、乙に対して実質的な参加の機会及びすべてについての決定権限を与え、並びに必要な援助をすること③ 甲の敗訴判決が確定すること又は乙が訴訟遂行以外の決定を行ったときは和解などにより確定的に解決すること
2.

乙の責に帰すべき事由による知的財産権の侵害を理由として納入物の将来に向けての使用が不可能となるおそれがある場合、乙は、乙の判断及び費用負担により、（ⅰ）権利侵害のない他の納入物との交換、（ⅱ）権利侵害している部分の変更、（ⅲ）継続使用のための権利取得のいずれかの措置を講じることができるものとする。

3. 第 1 項に基づき乙が負担することとなる損害以外の甲に生じた損害については、第 53 条
（損害賠償）の規定によるものとする。

【B 案】（ユーザ主導で紛争解決）（知的財産権侵害の責任）第○条 本契約及び個別契約に従った甲による納入物の利用が、第三者の著作権、特許権その他の産業財産権（以下本条において「知的財産権」という。
）を侵害したとき、乙は第53 条（損害賠償）所定の金額を限度として、甲に対してかかる侵害によって甲に生じた損害（侵害を回避した代替プログラムへの移行を行う場合の費用を含む。
）を賠償する。
但し、知的財産権の侵害が甲の責に帰する場合（甲乙間で別段合意がない限り、第 48 条に定める第三者ソフトウェア又は第 49 条に定める FOSS に起因する場合 を含む。）
はこの限りでなく、乙は一切責任を負わないものとする。
2. 甲は、本契約及び個別契約に従った甲による納入物の利用に関して第三者から知的財産権の侵害の申立を受けた場合、すみやかに書面でその旨を乙に通知するものとし、乙は、甲の要請に応じて甲の防御のために必要な援助を行うものとする。
（作成日：2017 年 12 月 27 日）

104Question C-2-2

ソフトウェア使用許諾契約書について－モデル契約の有無と留意点

OSS を一部に利用したソフトウェア製品をベンダがユーザに提供する際の使用許諾契約（ライセンス契約）書に関し、モデル契約書のようなものはありますか？

Answer１．モデル契約の有無、使用許諾契約書中の記載について
OSS を用いたソフトウェア製品を提供する際の契約条件について定めた、一般に広く知られたモデル契約書は存在しないようです。
OSS のライセンス条件では、OSS を配布する際に、著作権表示や無保証である旨の表示を含めることや当該 OSS のライセンス文書のコピーを提供すること等が求められることがあります。したがって、ベンダは、OSS を配布する際は、それぞれの OSS のライセンス条
件に従う必要があります（本書「A-1-2」参照）。
例えば、OSS のライセンス文書のコピーを提供するにあたっては、ベンダの定めるソフ
トウェア製品の使用許諾契約書に以下のように記載した上で、OSS のライセンス文書のコピーを当該ソフトウェアとともに配布することが考えられます。

【OSS について OSS 所定の条件が適用されるとする場合】
本ソフトウェアには、別紙に示す OSS が含まれています。当該 OSS との関係では、それぞれの OSS で指定されているライセンス条件が適用されます。OSS のライセンス条件は、別紙をご参照ください。

また、OSS のライセンス条件の中には、GPL のように、ユーザが GPL で認められた権利を行使することに対して、GPL で定める以上の制限（追加的制限）を課すことを禁止するライセンスもあります（本書「D-4-2」参照）。ベンダの定めるソフトウェア製品の使用許諾契約書の内容と OSS のライセンス条件で認められた権利の内容とが矛盾・抵触しないことを明確にするため、更に以下のように、当該ソフトウェア製品の使用許諾契約書において記載することが考えられます。

105

【GPL で定める以上の制限を課すものではないことを明確にする場合】
本ソフトウェアの使用許諾契約の条項は、GNU General Public License（以下「GPL」といいます。
）において認められた権利を制限するものではありません。本ソフトウェアの
うち、GPL に基づき配布されたソフトウェアについては、本ソフトウェアの使用許諾契約の条項は適用されず、GPL のみが適用されます。

２．ソースコードの提供について
OSS のライセンス条件として、OSS を用いたソフトウェア製品をユーザに配布するにあたり、ソースコードの提供を求めるものがあります。例えば GPL では、オブジェクトコー
ド形式で配布する場合には、ソースコードの配布を義務付けており、以下の配布方法があります。
（詳細は本書「D-1」参照）。
（ア）対応したソースコードを添付する。
（イ）最低 3 年間（これに加えて、GPL v3 では、物理的な製品に格納又は組み込んでオブジェクトコードを配布する場合は、その補修部品又はカスタマーサポートの提供期間）は、オブジェクトコードの保有者から請求があった場合に、配布に必要となる費用を上回らない手数料でソースコードを提供することを申し出た書面を添付する。
（ウ）（イ）と同様の期間、ネットワークからダウンロード可能とする。
このため、OSS を用いたソフトウェアを提供する際には、OSS のライセンス条件に応じ、ソースコードの提供の方法や提供に関する通知についても配慮する必要が出てくる場合があります。
この点に関し、2008 年に公表された Software Freedom Law Center「A Practical
Guidance to GPL Compliance」185 では、GPLv2 及び GPLv3 に従ったソースコード提供の申し出について記載案を示しており、参考になります。この参考訳として IPA オープン
ソフトウェア・センター リーガルタスクグループが公開した「GPLv3 逐条解説」の別紙３に「日本語訳（GPL 遵守のための実践的ガイドライン）」186（以下「ガイドライン」といいます。
）が掲載されています。
以下は、GPLv2 に基づく申し出として、ガイドラインに例示されたものです。GPLv2
においては、ソースコードの提供方法としてネットワークを用いることが認められていません（オブジェクトコードをネットワークから提供するケースを除きます。
）ので、物理的媒体でのソースコード提供の申し出とともに、ユーザ・ベンダ双方の利便性の観点から、
ダウンロード可能な WEB サイトを記載することを推奨しています。

185
186

https://www.softwarefreedom.org/resources/2008/compliance-guide.html
独立行政法人情報処理推進機構（IPA）「GPL v3 逐条解説」（2009 年 4 月）別紙 3。
https://www.ipa.go.jp/files/000028320.pdf

106この製品は、GPL でライセンスされる著作権保護されたソフトウェアを含みます。
ライセンスのコピーは、本文書の X ページ に掲載されています。対応するソースコードは、本製品を最終出荷より 3 年間、早くとも 2011 年 8 月 1 日までの期間、当社より入手できます；ソースコ〔ママ〕

ードをご希望の方は、郵便為替または小切手または小切手で 5 ドルを次の住所にご送付ください：
GPL Compliance Division
Our Company
Any Town, US 99999
支払いのメモ欄に「製品 Y のソース」と記載してくださるようお願いいたします。
ソースのコピーは次のサイトにも掲載されています。
http://www.example.com/sources/Y/
この申し出は、本情報を受領された方全員に有効です。
（情報処理推進機構（IPA）「GPL v3 逐条解説」（2009 年 4 月）
【別紙 3】229 頁）

GPLv2 に対し、GPLv3 に基づく申し出の例示では、下記のとおり、WEB サイトからダウンロードできる旨のシンプルな記載となります。
この製品は、GPLv3 でライセンスされる著作権保護されたソフトウェアを含みます。
ライセンスのコピーは、本文書の X ページ に掲載されています。対応するソースコードは、本製品の最終出荷より 3 年間、早くとも 2011 年 8 月 1 日までの期間、弊社ウェブサイトより入手できます；また、ソースコードは、当社の Web サイト（http://www.example.com/sources/productnum/）からダウンロードできます。
（情報処理推進機構（IPA）「GPLv3 逐条解説」（2009 年 4 月）
【別紙 3】231 頁）（作成日：2017 年 12 月 28 日）

107Question C-3

ソフトウェアを OSS 化する場合の会計上、税務上の取扱い（資産計上・費用処理）について

ソフトウェアを OSS 化したいと考えています。この場合、会計上、税務上どのような処理を行えばよいでしょうか？

Answer
①会計上は、ソフトウェアを製作する際に発生する支出が、（a）将来的な収益獲得又は費用削減に貢献することが確実な場合に、当該支出を資産計上した上で毎期減価償却を行い、（b）そうでない場合には一括費用処理する、というのが基本的な考え方になります。
OSS は無償で利用許諾されることが一般的ですので、将来的な収益獲得又は費用削減に貢献しないということであれば、資産計上せずに、研究開発費（研究開発に伴い発生しており、将来的な収益獲得又は費用削減に紐づかない費用）であるものとして、その全額が一括費用処理されるものと考えられます。しかし、企業は OSS を無償で利用許諾されるものの、メンテナンス等のサービスを有償で提供することを目的としているとも考えられることから、「研究開発費等に係る会計基準」187の趣旨に照らせば、資産計上した上で毎期減価償却を行うことが必要になる場合もあると考えられます。
他方、②税務上は、（a）将来的な収益獲得又は費用削減が見込めないことが明らかな場合についてのみ一括損金処理が認められており、（b）そうでない場合には当該支出を資産計上した上で毎期減価償却を行う、というのが基本的な考え方になります。したがって、
OSS を無償で利用許諾し、将来的に何らの収益獲得又は費用削減も見込めないのであれば、一括損金処理が行えますが、そうでない場合には、資産計上した上で毎期減価償却を行うことが必要となります。
なお、OSS を企業から OSS 提供団体に対して移転させる場合には、会計上も税務上も資産計上せずに、一括費用処理（一括損金処理）されることになると考えられます。ただし、
いわゆる「寄付」に該当する場合、税務上は損金算入限度額までしか損金処理が行えない点についてご留意頂く必要があるかと思われます。
以下では、OSS の会計処理・税務処理に関する主な留意点を解説しますが、OSS 化には様々な状況が想定されますので、実際の処理に際しては、ご所属会社の経理・財務担当部
署や税理士・会計士等の専門家、税務署等にご確認ください。

187

http://www.fsa.go.jp/p_mof/singikai/kaikei/tosin/1a909e2.htm

108１．OSS に関する会計処理（１）ソフトウェア製作費の会計処理188に関する基本的な考え方
ソフトウェアを製作する際に発生する支出（以下「ソフトウェア製作費」）については、①費用処理するのか、②資産計上するのか、③資産計上する場合にどのように減価償却するのか、の 3 点が重要な問題となります。
この点、ソフトウェア製作費が、（a）将来的な収益獲得又は費用削減に貢献することが確実な場合には資産計上し、（b）そうでない場合には費用処理する、というのが会計処理の基本的な考え方になります。また、資産計上する場合には、将来的な収益獲得又は費用削減が見込める期間・販売数量等を合理的に見積もり、当該期間・販売数量等に基づいて減価償却を行うことになります。
以下では、どのような基準で、資産計上・費用処理されるか、また、資産計上された場
合に、どのように減価償却を行うかについてご説明致します。なお、会計基準上、ソフトウェアが資産計上される場合は、（あ）受注製作ソフトウェア189、（い）市場販売目的ソフ
トウェア190、（う）自社利用ソフトウェア191の３つに分けられていますが、OSS は無償で利用許諾されることが一般的であり192、基本的には（あ）「受注製作ソフトウェア」及び（い）「市場販売目的ソフトウェア」に該当することはないと思われますので、（う）自社利用ソ
フトウェア193であることを前提に記載致します。
（２）研究開発費に係る会計処理
ソフトウェア製作費を会計処理する上で、「研究開発費」という概念が非常に重要となります。
「研究開発費等に係る会計基準」においては、①「研究とは、新しい知識の発見を目的とした計画的な調査及び探求」であり、②「開発とは、新しい製品・サービス・生産方法（以下「製品等」）についての計画若しくは設計又は既存の製品等を著しく改良するため
188 『研究開発費等に係る会計基準』、『研究開発費及びソフトウェアの会計処理に関する実務指針』及び『「研究開発費及びソフトウェアの会計処理に関する Q&A」について』に基づいた会計処理という前提で記載致します。
189 受注製作ソフトウェアとは、特定のユーザから、特定の仕様で、個別に製作することを受託して製作するソフトウェアを指します。
190 市場販売目的ソフトウェアとは、ソフトウェア製品マスターを製作し、これを複製して不特定多数のユーザに販売するパッケージ・ソフトウェア等を指します。
191 自社利用ソフトウェアとは、（ⅰ）ユーザへのサービス提供を行ってその対価を得るために利用される
ソフトウェア、又は（ⅱ）社内の業務を効率的に行う等、社内の管理目的等で利用するためのソフトウェ
アを指します。
192 OSI（Open Source Initiative）という任意団体によれば、OSS を以下のように定義しています（http://opensource.jp/osd/osd-japanese.html）。
「オープンソース」であるライセンス（以下「ライセンス」と略）は、出自の様々なプログラムを集めた
ソフトウェア配布物（ディストリビューション）の一部として、ソフトウェアを販売あるいは無料で配布することを制限してはなりません。ライセンスは、このような販売に関して印税その他の報酬を要求してはなりません。
193 OSS は無償で提供されるものの、メンテナンス等のサービスを有償で提供することを目的としているとも考えられることから、上記脚注 5 の「（ⅰ）ユーザへのサービス提供を行ってその対価を得るために利用されるソフトウェア」に近いのではないかと考えられます。

109

の計画若しくは設計として、研究の成果その他の知識を具現化すること」であるとされて
います。
要するに、
「研究開発費」とは、ソフトウェアを製作する初期段階における研究開発のために行った支出であると言えます。このような「研究開発費」については、発生時に将来的な収益獲得又は利益削減が見込めるか否か不明であることから、資産として計上することなく発生時の費用として処理することになります。
また、発生時に費用として処理する方法には、①一般管理費として処理する方法と、②
当期製造費用として処理する方法の 2 つがありますが、OSS は一般的に販売され、かつ、売上計上されるソフトウェアとは異なりますので、②当期製造費用（その後、売上原価）として処理する方法は合理的とは考えられず、①一般管理費として処理する方法が選択されることになるかと思われます。
前述のとおり、OSS は販売することを目的として製作されるわけではなく、ユーザに自由に使用させることを目的として無償で利用許諾されることが一般的であることから、将来の収益獲得又は費用削減が見込めないとも考えられます。そうであるならば、OSS の製作費は発生時に一括費用処理されることになります。
（３）自社利用ソフトウェアに係る会計処理
上記（２）に記載のように、OSS はユーザに自由に使用させることを目的として無償で利用許諾されるのみであるという前提であれば、製作費を発生時に費用処理すべきことになりますが、例えば、OSS 自体は無償で利用許諾するとしても、OSS の利用に付随するサービスを有償で提供するようなケースも考えられ、その場合には、自社利用ソフトウェア194
として資産計上が必要になることもあるかと思われます。
現状、OSS のソースコード自体が膨大となっていることから、そのメンテナンスについても相当のノウハウを要します。一般的な商用ソフトウェアであれば、開発過程で様々な設計ドキュメントに相当するものが製作され、また、マニュアルや操作説明等も提供されますが、OSS の場合にはこれらの資料が製作されないことが多いと言えます。この点、OSSを解説した市販本等も存在しますが、これらは概念的な理解の助けにはなるものの、ソースコードとの対応が難しく、保守ドキュメントとして十分であるとは言えません。
したがって、ユーザは OSS を無償で利用できたとしても、仮に不具合が発生した場合には、OSS の改良版の製作や OSS の操作説明等のサポートサービスを有償で受けることが必要となります。OSS 製作企業がこのような有償サービスを提供することを目的として OSSを無償で利用許諾するのであれば、当該有償サービスによって生じる収益に対応する形で、OSS 製作に要した支出を費用化させる必要がありますので、資産計上した上で、一定期間
194

ソフトウェア自体を有償で提供しているわけではなく、ソフトウェアを利用させた上で、付随する有償サービスを提供しているに過ぎないため、企業は当該ソフトウェアを利用して収益を得ている（本来発生すべき費用の削減が図られている）との解釈になるものと考えられます。ただし、直接的な自社利用であるとも言いにくいため、他の解釈（市場販売目的等）もあるかと思われます。

110

にわたり減価償却を行うこと等が必要になると考えられます。
しかし、資産計上する場合であっても、OSS の開発に要した全ての支出がソフトウェア
として資産計上されるわけではありません。一般に、ソフトウェア開発には長期間を要す
るものであり、開発開始の時点において、ユーザが要求する機能を備え、かつ、実際の業務での使用に耐えうるレベルのソフトウェアの完成が確実に予測できるわけではないと思われます。そのような場合には、将来的な収益獲得又は費用削減が確実であると認められた時点から後に発生した支出について資産計上し、それ以前の支出については費用処理するものとされています。
OSS についても、基本的には上記の考え方に基づき、資産計上の要否を決定することになります。本問においては、既存 OSS を利用してパッチ版を製作するケースを想定していますが、開発開始前の段階で、有償サービスによる収益見通しがある程度立っていることも考えられます。そのような場合であれば、開発開始時点から発生した支出を資産計上していくことになると考えられます。例えば、パッチ版の製作に際しては、開発にどの程度の支出が生じ、当該パッチ版を無償で利用許諾した後に、どの程度の有償サービスの受注が見込めるかについて事業計画や予算を作成し、また、これらの事業計画や予算について
社内的な稟議・承認プロセスを経て実際の開発に着手することになるかと思われます。このような場合、社内的な稟議・承認が行われたことが分かる稟議書や議事録等が作成された時点で将来的な収益獲得又は費用削減が確実になったものとされ、当該時点より後に発生した支出について資産計上することになります。
なお、資産計上された自社利用ソフトウェアについては、事業計画や予算等に基づいて合理的に減価償却できる場合を除き、通常は定額法を採用することが合理的であると考えられています。また、耐用年数は、当該ソフトウェアの利用可能期間によるべきですが（既存 OSS の利用可能期間等を考慮して決定）、原則として 5 年を超えないものとされており、５年を超えて減価償却を行う場合には合理的な根拠に基づくことが必要となります。

111

（４）会計処理に関する小括
以上の議論より、OSS を製作する場合の会計処理については、下表のようにまとめることができます。
会計処理

研究開発費

ソフトウェ

将来的な収益獲にア得又は費用削減

資産計上

該当するか

の製作目的

の確実性

の要否

該当する

否

具体的な処理全て発生時に費用として処理する。
確実となった段階で資産計

①確実
該当しない

要

自社利用

上し、原則として定額法により 5 年以下で減価償却を行
う。

②不明確

否

③ない

全て発生時に費用として処理する。

２．OSS に関する税務処理（１）ソフトウェアの税務上の取得価額195
ソフトウェアを自社で製作する場合、「製作等に要した原材料費、労務費及び経費の額＋事業の用に供するために直接要した費用」を取得原価と考え、税務上の資産として処理することになります。
逆に、取得原価に算入しないことができる費用は以下のように規定されています。
イ) 製作計画の変更等により、いわゆる仕損じがあったため不要となったことが明らかであるものに係る費用
ロ) 研究開発費（自社利用のソフトウェアについては、その利用により将来の収益獲得又は費用削減にならないことが明らかであるものに限ります。
）
ハ) 製作等のために要した間接費、付随費用等で、その合計額が少額（その製作原価のおおむね 3％以内の金額)）であるもの
要するに、税務上は、基本的にソフトウェアの製作に要した支出の全額を資産計上することが前提となっており、資産計上しなくてもよい支出が例外的に規定されるという建付けになっております。
OSS が無償で利用許諾されるのみであるという前提であれば、上記ロ）に該当して、一括で損金計上できることになります。他方、何らかの収益獲得又は費用削減が期待される
国税庁 HP タックスアンサー 法人税 No.5461 ソフトウェアの取得価額と耐用年数
https://www.nta.go.jp/taxanswer/hojin/5461.htm
195

112

のであれば、それが明確でなくても資産計上して減価償却を行うことになります。
この点、どちらの処理とすべきかについては、状況により異なるため一概には言えませんが、少なくとも、一括で損金計上するためには、「将来の収益獲得又は費用削減にならないことが明らか」であるという点について、税務署を納得させるだけの合理的な説明が必要になるかと思われます。
（２）ソフトウェアの税務上の耐用年数
ソフトウェアの耐用年数については、その利用目的に応じて以下のように規定されています。
1． 「複写して販売するための原本」又は「研究開発用のもの」
・・・・・・・・・3 年
2． 「その他のもの」
・・・・・・・・・・・・5 年
OSS については、「複写して販売するための原本」又は「研究開発用のもの」には該当しないものと思われますので、５年で償却することになります。
（３）税務処理に関する小括
以上の議論より、OSS を製作する場合の税務処理については、下表のようにまとめることができます。
税務処理

将来的な収益獲
得又は費用削減

資産計上

の確実性

の要否

①確実
②不明確
③ない

要
否

具体的な処理
下記以外の場合には、全て資産計上した上で、定額法によって 5 年間で償却します。
将来的な収益獲得又は費用削減が見込めないことが明らかである場合は損金処理します。

３．OSS に関する会計処理と税務処理の相違点（１）会計処理と税務処理に関する考え方の相違点
会計処理を行う上で重視されるのは、期間損益を正しく計算することであると考えられており、収益が計上されている期と同じ期に、それに伴い発生した費用が計上されることが求められます。したがって、将来的な収益獲得又は費用削減が見込める場合に限り、ソフトウェア開発に係る支出を資産計上し、将来の費用とすべく繰り延べることができると言えます。
逆に、そのような効果が見込めない場合には、保守的に（利益が過大に計上されないよ113

うにするため）、支出が発生した期の費用として処理することになります。
また、収益の計上に伴い費用が発生しているとの前提のもと、あるいは、一定の合理的な仮定に基づき費用が発生しているとの前提のもと、耐用年数についても、原則は５年以下と規定されているものの、合理的な説明がつけばそれ以上長い期間にわたり減価償却することが認められています。
他方、税務処理を行う上で重視されるのは、恣意的に損金計上額を増加させることによる納税の繰延べを排除しようとすることであると言えます。そのため、ソフトウェア開発に係る支出については、基本的には発生した期に一括して損金処理することは認められず、
資産計上した上で、減価償却を通じて損金算入することが求められています。また、恣意
的に耐用年数を操作することにより減価償却費を増加させることができないようにするため、税務上の耐用年数は画一的に「３年」又は「５年」と規定されており、短縮したり延長したりすることが基本的には認められていません。
以上をまとめると、会計処理と税務処理には、下表のような傾向があると言えます。
①費用（損金）計上

②資産計上

③耐用年数

会計処理

大きめに計上

小さめに計上実態に応じて決定

税務処理

小さめに計上

大きめに計上

画一的に決定（２）会計処理から税務処理への変換
会計処理と税務処理では、上記のような相違点がありますが、それぞれ別々に存在しているわけではありません。税務申告を行う際には、会計上の利益（損益計算書における利益）をスタートとし、これに調整を加えることで税務上の課税所得を計算します。つまり、会計処理で計上された費用を税務処理で認められる損金計上額に修正する作業を税務申告書上で行うことになります。
上述のとおり、「会計上の費用≧税務上の損金」という関係にありますので、会計上の利益から税務上の課税所得を計算する場合には、会計上の費用のうち税務上の損金算入限度額を超える部分について「加算」するという処理を行うことになります。
４．OSS 化に要した支出の捉え方
上記では、OSS 化を行う際の一般的な会計・税務処理を解説していますが、費用（損金）処理又は資産計上の対象となる金額をどのように捉えるかについての考え方を実際に想定される以下のようなケースに従って示します。
１. 顧客から有償で受託開発したソフトウェアを利用して OSS 化する場合
２. 上記 1．と自社開発ソフトウェアを結合させて OSS 化する場合
３. Apache Software Foundation 等のコミュニティから無償配布された OSS を改良してパッチ版を作成し、当該パッチ版を OSS 化する場合

114

１．顧客から有償で受託開発したソフトウェアを利用する場合であれば、元となるソフ
トウェアの製作費は、受託開発したソフトウェアの販売に係る売上原価として計上されているものと思われます。したがって、OSS 化を行う際に費用（損金）処理又は資産計上の対象となるのは、元のソフトウェアからの改変・改良等に要した支出であると考えられます。
２．上記１．と自社開発ソフトウェアを結合する場合、自己開発ソフトウェアが OSS 化のためだけに開発されたのであれば、OSS 化を行う際に費用（損金）処理又は資産計上の対象となるのは、その開発費用全額になるものと考えられます。自己開発ソフトウェアが他の目的でも利用されているのであれば、当該他の目的と OSS 化への寄与割合を合理的に見積もり、その開発費用のうちの一部を OSS 化に伴う費用（損金）処理又は資産計上の対象とすべきであると考えられます。
３．Apache Software Foundation 等のコミュニティから無償配布された OSS を改良してパッチ版を作成し、当該パッチ版を OSS 化する場合であれば、開発の元となった OSSからの改良に要した支出を、OSS 化に伴う費用（損金）処理又は資産計上の対象とすべきであると考えられます。
以上のとおり、OSS 化を行う際に追加的に発生した支出を把握し、OSS の性質に応じて費用（損金）処理又は資産計上を行うというのが基本的な考え方になるかと思われます。
５．OSS を OSS 提供団体に移転する場合の会計・税務処理
企業が OSS 化を行う場合、OSS 提供団体（例：Apache Software Foundation）に対して OSS のパッチ版等を移転させるケースが圧倒的に多いと言えます。この際、ソフトウェ
アを当該団体に対して譲渡ないし寄付する場合には、ソフトウェアの著作権が企業から当該団体に移転することとなるため、会計上も税務上も、企業側で OSS を資産計上することはないと考えられます。
この点、会計上は、ソフトウェアの製作に要した支出を（資産計上せずに）一括費用処理するということになるだけですが、税務上は、いわゆる「寄付」に該当しますと、損金算入限度額を超える部分については損金処理が認められなくなってしまう場合があります
ので、ご留意頂く必要があります。もっとも、いわゆる「寄付」ではなく、企業が有償サービスを提供するための、広告宣伝費や販売促進費的な位置づけと捉えられるのであれば、損金算入が可能であると考えられます。このあたりの考え方は、ケースバイケースになろ
うかと思われますので、税理士等の専門家や所轄税務署にお問い合わせ頂くことをお勧め
致します。
６．まとめ
以上の議論より、（A）OSS 移転の有無、（B）研究開発費への該当性及び（C）収益獲得
及び費用削減の確実性の観点から、どのような会計処理・税務処理が行うべきであるかに

115

ついては、下表のようにまとめることができます。

（A）
OSS
移転
の有

（B）

（C）

研究

収益獲得又は

開発費

費用削減の

会計処理

税務処理

税務調整

一括費用処理一括損金処理（※）

不要（※）

①確実

一括費用処理定額法 5 年で減価償却

必要

②不明確

一括費用処理定額法 5 年で減価償却

必要

③ない

一括費用処理一括損金処理不要

定額法 5 年で減価償却

不要

確実性

無
有
該当
する
無

①確実
該当
しない

定額法 5 年で減
価償却

②不明確

一括費用処理定額法 5 年で減価償却

必要

③ない

一括費用処理一括損金処理不要（※）OSS を企業から OSS 提供団体に移転する際に、いわゆる「寄付」とみなされてしまう場合には、税務上は損金算入限度額の範囲内でしか損金処理が行えませんので、一括損金処理が行えず、税務調整が必要となります。
（作成日：2018 年 2 月 9 日）

116

D．GPL その他の OSS ライセンス上の留意点
１．ライセンス表示やソースコードの提供
２．ライセンスの解釈
３．GPL の伝搬
４．GPL ライセンス契約上の諸問題

117

Question D-1

JavaScript や、一つのプログラム中に多数のライセンスが含まれる場合の表示方

WEB サイトにて JavaScript の OSS を利用した結果、クラアイント側のユーザにこのOSS が配信されます。この OSS に適用されるライセンスの名称やライセンス文書等を記載しないといけないのでしょうか？

Answer１．問題点
一般に OSS のプログラムを配布する際には、ライセンス名称やライセンス文書等を添付することが必要とされています。JavaScript の場合、ユーザが WEB サイトにアクセスした場合、ブラウザに配信され、そこで実行されることになります。この場合、配信される
ファイルは、JavaScript の実行に必要なファイルとなり、例えば、GPL のような長いライセンス文書を含めると配信するファイルの分量が大きくなってしまい、実務上支障を来すことになります。
また、一つのプログラム中に、それぞれライセンスを異にする複数のプログラムが含まれている場合も、データ的に全てを記載するのは実務上支障がある、という意味では、
JavaScript と同様の問題があります。
そこで、そのような場合、どのような形であれば実務的にライセンス条件を遵守したことになるのかが問題となります。
２．JavaScript について FSF が示唆する方法（１）ライセンス告知
上記のような問題点は、ライセンス作成側も認識しており、GPL を策定している FSF のページでは、例えば、下記のようなライセンス告知をすれば、GPL のライセンス文書のコ
ピーの配布を要求しないことが示唆されています196。
Copyright (C) YYYY Developer
The JavaScript code in this page is free software: you canredistribute it and/or modify it under the terms of the GNU
General Public License (GNU GPL) as published by the Free Software
Foundation, either version 3 of the License, or (at your option)
any later version. The code is distributed WITHOUT ANY WARRANTY;
196

https://www.gnu.org/philosophy/javascript-trap.html

118

without even the implied warranty of MERCHANTABILITY or FITNESSFOR A PARTICULAR PURPOSE. See the GNU GPL for more details.
As additional permission under GNU GPL version 3 section 7, you
may distribute non-source (e.g., minimized or compacted) forms ofthat code without the copy of the GNU GPL normally required bysection 4, provided you include this license notice and a URL
through which recipients can access the Corresponding Source.
（訳：本ページの JavaScript はフリーソフトウェアであり、あなたは、Free Software
Foundation が発表した GPL の Version 3 又は（あなたの選択可能）それ以降のバージョンの元で、これを再配布又は修正することができます。本コードは、商品性または特定目的への適合性の保証を含め、何らの保証なく配布されています。詳細については、GNU
GPL を確認してください。GNU GPL Version3 の７項による追加的許諾として、あなたは通常４項で求められる GNU GPL のコピーを添付することなく、ソース形式でない（例
えば、最小又はコンパクト化された）形式での配布を行うことができますが、これは、
本ライセンス告知及び、受領者が「対応するソース」にアクセスできるような URL を含めることを条件とします。
）（２）JavaScprit ライセンス・ウェブ・ラベル
上記のような記載を含めるだけでも、ライブラリ・ファイルの最小化という点では問題があるため、上記に代わる方法として、JavaScript ライセンス・ウェブ・ラベルという方法も示唆されています197（ただし、HTML ページに直接、インラインの JavaScript に適用される場合には適用されず、この場合は上記のライセンス告知の方法による必要があるとされています）。
具体的には198、JavaScript のライセンス・ウェブ・ラベル用のページを WEB サイト中に作成し、JavaScript を使う各ページで上記ページへのリンクを下記のとおり含めます。
<a href="/about/javascript" rel="jslicense199">JavaScript のライセンス情報</a>
なお、リンク先のページには、id=”jslicense-labels1”とマークされた一つのテーブルを含めます。テーブルのそれぞれの行は以下の３つのセルから構成されます。
https://www.gnu.org/licenses/javascript-labels-rationale.ja.html
インラインの場合、ソースについては、//@source: に続き、URL を記載することで足りるとされている。
198 https://www.gnu.org/licenses/javascript-labels.html
199 これは、自動化ツール（FSF の LibreJS プログラム）の検索を容易にするもので、これにより、ユーザ側がページ内に含まれた JavaScript の内容を確認し、実行するかどうかを判断するための機会を得ることができる。
197

119

第１セル：WEB サイトで使われるスタンドアローンの JavaScript ファイルの名称を表示します。このセルには、そのファイルへとリンクするアンカータグが必要となります。
第２セル：上記 JavaScript のライセンス情報を表示します。ここでは、ライセンスのテキスト全体を参照するアンカータグを含める必要があり、かつ、アンカータグのテキストは、ライセンスのフルネーム（複数のバージョンがある場合はバージョン
ナンバーも含む）を記載しなければなりません200。
第３セル：ソースコードの取得方法を表示します。基本的には、JavaScript のソースコー
ドへのリンクを記載します。ソースコードのアーカイブが複数の JavaSript ファ
イルを含む場合、00-INDEX という名前のファイルを作成し、WEB サイトから配信されているものと同じファイルを生成できるように、その順番等を明記しなけ
ればなりません。
FSF は、以下をテーブルの例としてあげています。
<table id="jslicense-labels1"><tr><td><a href="/js/jquery-1.7.min.js">jquery-1.7.min.js</a></td><td><a href="http://www.jclark.com/xml/copying.txt">Expat</a></td><td><a href="/js/jquery-1.7.tar.gz">jquery-1.7.tar.gz</a></td></tr></table>３．他のライセンスの場合
他のライセンスに関しても、JavaScript の場合に、上記の方法で足りるかどうかは必ずしも明らかではありません。しかしながら、他のライセンスの場合でも、実務上大きな支障が生じるような態様を要求するとは考えにくいです。
例えば、ソースコードに関してですが、Mozilla Public License 2.0 では、”Is minified”
JavaScript Source Code? という Q を設けています201。
200

正しいとされるライセンスの識別子については下記参照。
https://www.gnu.org/licenses/javascript-labels.html
201 MPL 2.0 FAQ
https://www.mozilla.org/en-US/MPL/2.0/FAQ/120

同 Q においては、簡略化された JavaScript が同ライセンスでのソースコードではないことを前提として、MPL の定型文言全てを記載する必要がないこと、一つの方法としては、
JavaScript を使ったページか、JavaScript のファイルそのものに、ソースコードへのリン
クと共にコメントを記載することが考えられることが記載されています。ここから考えれば、必要な情報を受領者に合理的に提供できるのであれば、表示内容は、ライセンス条件の要求に厳密に遵守していなくても許容される場合があり得るのではないでしょうか。
（作成日：2017 年 11 月 6 日）

121Question D-2-1

OSS ライセンスの解釈

OSS のライセンス条項には、内容がわかりにくいものがあります。その場合、どうやって解釈すればいいのでしょうか？

Answer
ライセンスの内容を解釈するためには、まずどの国の法律に則って解釈をするか、すな
わち準拠法がどこなのかを決めなければなりません。準拠法を決める場合、日本では法の適用に関する通則法に従い決めることになりますが、この点については本書「F-4-2 OSSと越境問題－準拠法」を参照してください。ここでは日本法を前提として検討することとします。
次に、ライセンスの内容を解釈するためにはライセンス条項の文言の解釈が中心となります。しかしライセンス条項の文言だけからでは意味が明らかではない場合、他の情報も参照しながら解釈を行っていく必要があります。
参照する情報として、ライセンス条項を公開した団体等（GPL の場合 Free Software
Foundation, Inc.（FSF）、Apach License の場合 Apache Software Foundation（ASF））
が自ら提供している FAQ202があります。また、ライセンス条項の策定経緯や rationale（策定理由説明）なども有用でしょう。他に著作権法の解釈やこれまでの裁判例なども参考とできるものがあれば利用することになります。さらに、第三者が解釈を示したものなども参考となり得るでしょう203。もっともその解釈が一般的に受け入れられるようなものかを慎重に判断する必要があります。（情報処理推進機構（IPA）が出している『GNU GPLv3
逐条解説書』204は、IPA が FSF の意見も聞きながら作成したものであることから FAQ と同様頼りになります。）。その他、同業者等、同じ立場の者がどのように考えているかという情報も、一定程度、参考になるでしょう。なお、ライセンス条項の最終的解釈は裁判所が行うことになりますが、裁判所も先例のない事案の場合、上記の情報をかなり参考にす（作成日：2018 年 3 月 15 日）

ると思われます。

GPL について https://www.gnu.org/licenses/gpl-faq.ja.html
GPLv2.0 について https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html
Apach license について http://www.apache.org/foundation/license-faq.html
Creative Commons について https://creativecommons.org/faq/
日本語版 Creative Commons について https://creativecommons.jp/faq/
MPLv2.0 について https://www.mozilla.org/en-US/MPL/2.0/FAQ/
203 「ビジネスユースにおけるオープンソース ソフトウェアの法的リスクに関する調査」（独立行政法人情報処理推進機構）https://www.ipa.go.jp/about/jigyoseika/04fy-pro/open/2004-741d.pdf「OSS ライセンスの比較および利用動向ならびに係争に関する調査報告書」（独立行政法人情報処理推進機構） http://www.ipa.go.jp/osc/license2.html
204 https://www.ipa.go.jp/osc/license1.html
202

122

Question D-2-2「非営利」目的の利用のみ認められているソフトウェア
について「非営利」目的の利用のみ認められているソフトウェアを企業内で利用することはできま
すか？

Answer
1. はじめにOpen Source Initiative（OSI）が定める OSS の定義を満たすものであれば、営利目的の利用（商用利用）は認められます（本書「基礎-1 OSS とライセンスの基礎知識」参照）。そのため、
OSI は、営利目的の利用禁止を認めるようなライセンスを OSS とは認めませんが、そのようなライセンスパターンを含むものであっても、クリエイティブ・コモンズ・ライ
センスは OSS と言われることがあります。そのためここでは、クリエイティブ・コモンズ・
ライセンスを取り上げることとします。
このクリエイティブ・コモンズ・ライセンスは、著作権者の選択により、営利目的の利用の可否を決められるとしています。具体的には、非営利（Noncommercial, NC）のマー
ク、
日本版

米国版

NC

NC

が付されているコンテンツを営利目的に利用することはできません。
では、（非）営利目的の利用とはどういう場合をいうのでしょうか。例えば、企業が提供するクラウドサービスのために利用することはできるのでしょうか。また、非営利として配布されているソフトウェアを、営利企業が社内で利用することはできるのでしょうか。
このような検討を行う場合、準拠法がどれかを決定する必要がありますが（本書「F-4-2 OSSと越境問題－準拠法」参照）、ここでは日本法を前提として検討します。
ソフトウェアを使用することは、日本の著作権法上、原則自由と考えられています。そのため使用自体は自由と思われますが、使用する前段階としてソフトウェアの複製が生じることから、著作権法上、この複製が許されるかが問題となり得ます。そのため営利目的の使用か否かが重要な問題となり得ます。（ただし、クリエイティブ・コモンズのライセン
スは写真や画像等のコンテンツを想定したものであるため、クリエイティブ・コモンズも123

これをソフトウェアのライセンスに適用することは推奨していません205。
）
２．ライセンス条項の検討
この点について、まずライセンス条項に、どのように「営利」ないし「非営利」を規定しているか確認します。クリエイティブ・コモンズのライセンス条項には、以下のとおり「非営利」の定義規定が設けられています。

「非営利」とは、商業的な利得や金銭的報酬を、主たる目的とせず、それらに主に向けられてもいないことを意味します。本パブリック・ライセンスにおいては、デジタル・ファイル共有または類似した手段による、ライセンス対象物と、著作権およびそれに類する権利の対象となるその他のマテリアルとの交換は、その交換に関連して金銭的報酬の支払いがない場
合は、非営利に該当します。206

この定義によれば、商業的な利得や金銭的報酬を主たる目的とするかどうか、それらに主に向けられた利用かどうかが営利目的か否かの判断要素となっています207。しかしその具体的内容は判然としません。
３．FAQ の参照
そこで、クリエイティブ・コモンズ・ジャパンの FAQ を見てみます。しかしここでも、何が「営利」で何が「非営利」かは、最終的には裁判所の解釈によって定まることから、
クリエイティブ・コモンズ・ジャパンはこの点について答えることはできないとするにとどまります208。
Creative Commons の FAQ209や、「非営利」の解釈に関する記載をしたウェブページ210においても、「営利」か「非営利」かはその使用態様に依るものであって、利用者の属性（営利企業か NPO 法人かなど）によって一意的に決まるものではないとしていますが、それ以上の詳細な事項に関する判断は記載されていません。
４．解釈（１）クラウドサービスへの利用
https://creativecommons.jp/faq/#a6「クリエイティブ・コモンズ 表示-非営利 4.0 国際 パブリック・ライセンス」
第 1 条（定義）i 号。 https://creativecommons.org/licenses/by-nc/4.0/legalcode.ja「クリエイティブ・コモンズ 表示 - 非営利 -継承 4.0 国際 パブリック・ライセンス」
第 1 条（定義）k 号。 https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode.ja
207 「非営利」の定義条項第 2 文は、ファイル交換ソフトを用いてソフトウェアを受領した場合であっても非営利に該当し得ることを規定したものである。https://creativecommons.jp/faq/#b10
208 https://creativecommons.jp/faq/#a8
209 https://creativecommons.org/faq/#does-my-use-violate-the-noncommercial-clause-of-the-licenses
210 https://wiki.creativecommons.org/wiki/NonCommercial_interpretation
205
206

124

そうすると、他の要素、例えば著作権法の解釈や他のユーザがどう考えているかなどを参考にしながら解釈していくことになります。では、まず企業が提供するクラウドサービ
スのために利用する場合は、ここでいう「非営利」と言えるでしょうか。
クラウドサービスを有償で提供している場合、たとえソフトウェア自体を有償で提供していな
くても、金銭報酬を主たる目的とし、それに主に向けられた使用のため、「営利」目的と判断されるでしょう。

無償のクラウドサービスの場合であっても、たとえ直接金銭が得られなくとも、企業の宣伝広告に資するなど、商業的な利得を目的としていると考えられやすいと思われます。
したがって、このような場合であっても「営利」目的での利用と判断される可能性は十分あるでしょう211。
（２）企業内利用
次に、企業内利用はどうでしょう。この場合、ソフトウェアの使用により直接対価を得るのではなく、また企業の宣伝広告に資するものでもありません。そのため「非営利」と判断される余地はあるでしょうが、おおよそ営利目的の企業の活動は、商業的利得を目的としているとも考えられ、この場合も「営利」と考えられる可能性はあるでしょう。
ちなみに、本書「D-2-1」に記載した『GNU GPLv3 逐条解説書』は「非営利」を条件として公開されていますが212、「企業・団体等の内部における利用（講習会、勉強会等）を目的とした複製及び翻訳については、無償で許可します。
」と明記することで、企業内利用を明示的に認めています。
５．他のユーザなどの理解「営利」か「非営利」かについてクリエイターとユーザに対してアンケートが行われたものがあります213,214 。そこでは、「営利企業による利用。ただしお金儲けはされない。
」という利用について、クリエイターとユーザのいずれも３割以上の者が「営利」目的の使用であると考え、３割弱の者が「非営利」と考えているとの回答結果があります。このアンケート結果をふまえても、企業内利用は「非営利」と認められない可能性が高いように思われます。
（作成日：2018 年 3 月 15 日）
211 著作権法 38 条では、
営利を目的としない著作物の上演等は自由とされているが、この場合における「営利を目的」には、営利事業に関する広告宣伝に際しての利用など間接的効果を目的とする利用行為も営利を目的としたものに含まれると考えられている。そして、レストランや美容室の BGM として音楽を流すことも「営利を目的」としたものと考えられている。
212 「クリエイティブ・コモンズ・ライセンス表示-非営利-改変禁止 2.1」(Creative Commons License
Attribution Non-Commercial No Derivatives 2.1)
213 『Defining “Noncommercial” A Study of How the Online Population Understands “NoncommercialUse”』(September 2009) https://wiki.creativecommons.org/wiki/Defining_Noncommercial
214 同『Defining “Noncommercial”』54 頁、Appendix 5.6, Slide 44
http://mirrors.creativecommons.org/defining-noncommercial/Defining_Noncommercial_fullreport.pdf

125ライセンスの「継承」と修正

Question D-2-3

ライセンスの継承義務というのがありますが、これはどのようなものですか？

Answer
1. 改変ソフトウェアのライセンス
特定の OSS ライセンスで提供されているソフトウェアを修正、改変し、新しいソフトウ
ェアを制作した場合、この新たなソフトウェア（以下「改変ソフトウェア」と言います。）のライセンスは、どうなるでしょうか。このような検討を行う場合、準拠法がどれかを決定する必要がありますが（本書「F-4-2」参照）、ここでは日本法を前提として検討します。
改変者は、改変ソフトウェアの利用許諾の条件（ライセンス）を元のソフトウェア（以下「オリジナルソフトウェア」と言います。
）のライセンスとは別途、自由に決めることができます。
他方、あるソフトウェアを修正、改変して新たなソフトウェアを制作した場合、この改変ソフトウェアは、一般にオリジナルソフトウェアを原著作物とした二次的著作物215となります。そのためこれを利用するユーザは、オリジナルソフトウェアの著作権者（主にオリジナルソフトウェアの制作者。オリジナル制作者）と、改変ソフトウェアを制作した者（改変者）の両方から利用の許諾を得る必要があります。すなわち、オリジナルソフトウ
ェアのライセンス条項と、改変者が付した改変ソフトウェアのライセンス条項の両方を遵守する必要があるわけです。

オリジナル制作者

改変者

改変
ソフト
ウェア

オリジナル
ソフトウェアライセンス………………
………………
………………

どんなライセンス？

………………
ライセンス………………
………………
………………
………………

２．ライセンスの「継承」
改変者が別途自由にライセンスを付けられると言っても、オリジナルソフトウェアのラ215

著作権法 2 条 1 項 11 号

126

イセンス条項が、オリジナルソフトウェアを改変する前提として、改変ソフトウェアのラ
イセンスもオリジナルソフトウェアのライセンスと同じにしなければならないと定めている場合があります。これがライセンスの「継承」ということになります。

オリジナル制作者

改変者

改変
ソフト
ウェア

オリジナル
ソフトウェアライセンス………………
………………
………………

＝
継承

ライセンス………………
………………
………………

例えばクリエイティブ・コモンズには、改変した作品のライセンスもオリジナルの作品と同じライセンスで提供するように求めることがあります。このような作品には、以下の「継承（Share Alike）」のマークが付されます。

SA

この場合、改変者は、改変ソフトウェアをオリジナルソフトウェアのライセンスと同じライセンスで提供することが求められ、その他の制限条項などは付してはならないとされています216。
３．継承義務のないライセンスの修正（１）BSD ライセンス
では逆に、ライセンスの継承義務がない場合はどうでしょうか。
例えば、BSD ライセンス（ここでは修正 BSD ライセンス・３条項 BSD ライセンス217を例に挙げます。
）には、改変ソフトウェアを BSD ライセンスと同じライセンスで提供しなければならないといったライセンスの継承義務はありません。そのため、改変者が新たに様々な条件を付すことはできます。
ただし、改変ソフトウェアを受領したユーザとしては、先ほど述べましたように、改変者が付したライセンスのみならず、オリジナルソフトウェアのライセンスも遵守しなけれhttps://creativecommons.org/licenses/by-sa/4.0/legalcode.ja、
https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode.ja（第 3 条 b.）
217 https://opensource.org/licenses/BSD-3-Clause
216

127

ばなりません。そうすると、たとえ改変者が自由に改変ソフトウェアのライセンスを付けられるといっても、オリジナルソフトウェアのライセンス条件と矛盾するような条項をつけてしまうと、ユーザは両方のライセンスを遵守できなくなります。
BSD ライセンスで言えば、著作権表示、BSD ライセンス条件一覧、免責条項を含めて配布する必要があること、また書面による許可なしに改変ソフトウェアの宣伝・販売促進のためにオリジナルソフトウェアの著作権者等の名前を使用してはならないことという条件があるにもかかわらず、改変ソフトウェアのライセンスに「著作権表示は削除してもよい」などの条項を入れると矛盾が生じ、その結果として改変ソフトウェアをユーザが利用できなくなります。
このように、オリジナルソフトウェアのライセンスに継承義務がなく、改変ソフトウェ
アに自由にライセンスを付けられるといっても、そこには自ずと限界があることから、この点には注意が必要となります。
（２）Apache License2.0
次に Apache License2.0 の場合はどうでしょうか。Apache License2.0 は218、第 4 条においてオリジナルソフトウェアを改変したソフトウェア（修正したもの、または派生著作物）には、追加のまたは異なるライセンス条件を付けられると規定しています219。そして「異なるライセンス条件」が付けられるということから、改変ソフトウェアは、Apache
License2.0 と矛盾するようなライセンスで提供してもよいように思えます。
しかし、この点については議論があります。Apache License2.0 の場合も、改変ソフトウ
ェアのライセンスに Apache License2.0 と矛盾する条件は付けられず、矛盾しない範囲でライセンス条項を自由に追加・変更ができるにとどまるという考えがあるからです。その理由としては、一度改変をしただけで、それまでオリジナルソフトウェアに適用されていた Apache License2.0 の条件が無視できるようになるということはあまりにも不合理であるというものです。したがって Apache License2.0 が適用されているオリジナルソフトウ
ェアを改変したソフトウェアにライセンスを付ける場合、Apache License2.0 とは矛盾しな
い範囲のものにとどめておくのが安全でしょう。
（作成日：2018 年 3 月 15 日）

https://www.apache.org/licenses/LICENSE-2.0「You … may provide additional or different license terms and conditions for use, reproduction, or
distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with the conditions stated in thisLicense.」
218
219

128

Question D-2-4

ライセンスが未添付などにより確認できない場合

ライセンス条項が付されていないソフトウェアはどのように扱えばいいでしょうか？

Answer
１．ライセンス未添付のソフトウェア
受け取ったソフトウェアに、ライセンスファイルが同梱されていない場合（またはライセンス条項の表記がなされていない場合）について考えます。このような検討を行う場合、準拠法がどれかを決定する必要がありますが（本書「F-4-2」参照）、ここでは日本法を前提として検討します。
ライセンスファイルが同梱されていない場合、そのソフトウェアを自由に利用してよいのか判断する手が掛かりません。ソフトウェアの利用（配布や改変等）には、著作権者（一般的には作者）の許諾が必要です。その許諾が明らかではないのであれば、そのソフトウ
ェアを利用する場合、ソフトウェアの著作権者を自ら探し出し、利用の許諾を得なければならないことになります。
２．OSS ソフトウェアのライセンス未添付受け取ったソフトウェアが特定の OSS ライセンスに従うことがわかる場合もあるでしょう。例えば、著名なライセンスの名称のみが記載されているようなケースです。その場合、適用されるライセンスの条件に従って利用する限り問題が生じるとは考えにくいです。
もっとも、そのソフトウェアを第三者に提供する場合、注意が必要です。なぜなら、もしその OSS ライセンスが、ソフトウェアの利用者に対しライセンス文書の同梱をライセンス条件として求めているならば、たとえ受け取ったソフトウェアにライセンス文書が同梱されていなくても、これを同梱せずに第三者へ提供することはライセンス違反（ひいては著作権侵害）となる可能性があるからです。ライセンス文書の同梱が求められているものの、入手した OSS には、そのライセンスの URL が適示されているだけに過ぎないような場合も同様です。URL の摘示だけでライセンス文書を同梱したとはやはり言い難く、同じ問題が生じることになるでしょう。
ただし、OSS の開発者自身が、配布時にライセンス文書を同梱せず、ライセンス名称やURL のみを記載していた場合に、OSS の受領者がライセンス文書を付さずにこの OSS を配布しても、そのような配布に対して黙示の許諾があるとか、信義則などの理由から、著作権侵害の責めを負わないと考えられる場合もあるでしょう。
いずれにせよ、自らがライセンス違反となることを明確に避けるためには、自らライセ

129

ンス文書を探し、それを添付しなければならないことになります。
３．パブリックドメインソフトウェア（PDS）
他に、受け取ったソフトウェアの著作権が放棄ないし切れている場合（そのようなソフ
トウェアを、パブリックドメインソフトウェア（Public Domain Software：PDS）と呼ぶことがあります。
）もあるでしょう。この場合、その利用は自由です。しかし、受け取った
ソフトウェアが PDS であるとの表記もないのであれば、これが本当に著作権放棄された
PDS であるのか、その判断は慎重に行う必要があります。なお、もし PDS と判断したならば、具体的にどのような理由から PDS と判断したのか、後に問われても回答できるよう、
その理由や根拠資料を記録・保存しておくのが望ましいでしょう。
（作成日：2018 年 3 月 15 日）

130Question D-3-1

GPL の伝搬性 - Application Programing Interface

１．自社開発プログラムを GPL プログラムと結合または連係動作させる場合、自社開発プ
ログラムに GPL を適用しなければならない（GPL が伝搬する）範囲をどのように判断すればよいでしょうか。
２．API（Application Programing Interface）を介して、自社開発プログラムを GPL プロ
グラムと連携動作させる場合には、GPL の伝搬性をどのように判断すればよいのでしょうか。特に、Linux については、API（システムコール）によって OS（Kernel）の機能を呼び出して連携動作する自社開発プログラムについては、GPL のラセンス条件が適用されない（伝搬しない）という話を聞いたのですが、どういうことでしょうか。

Answer
１．GPL のライセンス条件を遵守しなければならない理由
最初に、自社開発プログラムを GPL プログラムと結合ないし連携動作させる場合に、GPL を利用する者が、GPL のライセンス条件を遵守しなければならない理由を解説します。
GPL プログラムは、プログラムの著作物であり、著作権法で保護されています。著作権法上、著作物を複製や改変等をする権利は、著作権者（開発者等）だけに与えられています（著作権法21 条乃至 28 条）。著作権法で定める著作権の制限を除き、著作権者の許諾を得ることなく、無断で著作物を複製または改変（著作者人格権の侵害）ないし翻案（著作財産権の侵害）をした場
合には、著作権の侵害に該当し、損害賠償の対象となるとともに（民法 709 条）、場合によっては刑事罰の対象ともなります（著作権法 113 条 1 項 2 号）。
そこで、著作権者以外が、著作物を複製や改変、翻案等をする場合には、著作権者の許諾を受ける必要があります。許諾を受けたとしても、著作権者が著作物の利用を許諾する際に一定の条件（利用料の支払、再販売の禁止等）を付けることもあります。この条件がいわゆる利用許諾条件であり、GPL も利用許諾条件の一つです。すなわち、GPL 等のオープンソースは、著作権を放棄するのではなく、自由な利用の促進等の目的のために一定の条件を付しており、著作権法上、原作品を翻案した二次的著作物に該当するプログラムについては、利用者が GPL プログラムを利用する条件に違反すると、ライセンス条件を充たさないために著作権の不行使（ライセンス）が消滅し、利用者は無権原な者となり、当該 OSS を利用する行為が著作権侵害となります。

２．GPL が契約かライセンスかによって伝搬性の判断が異なるかGPL が契約220なのかライセンス221なのかについては、両方の考え方がありますが、GPL プロ
220

契約とは、法律上の効果を発生させる、相対する意思表示（申込と承諾）の合致によって成立する法律131

グラムの伝搬性を判断する場面においては、いずれの説を採ったとしても、結果的に自社開発プ
ログラムに GPL が伝搬する判断基準を考えるときには、実務上は有意な差異がないものと考えられますので、GPL の趣旨にしたがい、FSF（Free Software Foundation）の FAQ222に基づいて伝搬性を判断するアプローチの方が、GPL プログラムを利用する企業にとって安全であると考えます223。この点に関して、詳しくは本書「D-4-1 GPL の法的性質」を参照してください。

３．GPL 伝搬性の判断基準
企業が自社開発プログラムと GPL プログラムを連携動作させる場合、GPLv2 または GPLv3の効力が及ぶ二次的著作物の範囲224あるいは GPL が伝搬225する範囲をどのように画定すべきでしょうか。
GPLv2226における派生物（derivative works）、GPLv3227における改変物（modified version）
あるいは GPL プログラムに基づく作品（work base on the Program）に該当するか否か、そして著作物として一個の作品（a single work）であるか否かに関する判断基準については、プロ
グラムの結合方法や内容によって個別具体的に判断するしかなく、最終的には裁判所の判断になりますが、GPL の解釈について FSF が公開している FAQ によれば、GPLv2、GPLv3 のいずれにおいても、次のように考えられます228。

（１）静的リンク
同一の実行ファイルに含まれる場合（プログラムが実行される前の段階で同一ファイルになっている場合）、すなわち静的リンクは伝搬します。

行為で、現在又は将来の給付の義務を負う相互の約束であって、法律によってその履行が保障されているものである（民法 526 条以下参照。非典型の無名契約）。
221 ライセンスとは、無許諾ならば違法となる行為である著作権が及ぶ利用行為について、権利者が、許諾に係る利用条件の範囲内で、著作権を行使しない意思を一方的に表示し、著作物の利用を許諾する法律行為であり（著作権法 63 条参照）
、単独行為で発効するが、契約によっても可能である。See Noam Shemtov& Ian Walden, FREE AND OPEN SOURCE SOFTWARE, Oxford Univ. Press (2013) pp.87-99. なお、FSFの弁護士であるエベン・モグレン氏は、GPL は契約ではなくライセンスであると主張している。
222 GNU ライセンスに関してよく聞かれる質問（FAQ）参照。
https://www.gnu.org/licenses/gpl-faq.ja.html
223 独立行政法人情報処理推進機構（IPA）「GPLv3 逐条解説」（2009 年）147 頁参照。なお、GPL 違反に関する訴訟事件は、米国とドイツに集中している。
224 GPL が適用されて、ソースコードの提供義務が及ぶ場合を「伝搬する」という。
225 日本の著作権法では、翻案（著作権法 27 条）二次的著作物（同 28 条）に関する規定が Derivative workに対応する。二次的著作物の作成すなわち翻案は、最高裁平成 13 年 6 月 28 日判決〔江差追分事件〕で次のように定義されている。
「言語の著作物の翻案とは，既存の著作物に依拠し，かつ，その表現上の本質的な特徴の同一性を維持しつつ，具体的表現に修正，増減，変更等を加えて，新たに思想又は感情を創作的に表現することにより，これに接する者が既存の著作物の表現上の本質的な特徴を直接感得することのできる別の著作物を創作する行為をいう。
」なお、アメリカ著作権法 101 条、103 条(b)、106 条、107 条（フェアユース）乃至 121 条（排他的権利）および 107 条（フェアユース）参照。
226 GPL Version 2 のライセンス条項参照。https://opensource.org/licenses/GPL-2.0
227 GPL Version 3 のライセンス条項参照。https://opensource.org/licenses/GPL-3.0
228 独立行政法人情報処理振興事業協会（IPA）「オープンソース・ソフトウェアの現状と今後の課題について」（2003 年）61 頁以下（8 部 GPL に関する法的問題の整理）参照。

132

（２）動的リンク
同一の実行ファイルに含まれないけれども、共有アドレス空間内でモジュールがリンクされて実行するよう設計されている場合（共有ライブラリ）およびモジュールの動的リンクは、伝搬します229。

（３）コマンド起動、パイプ、ソケット同一の実行ファイルに含まれず、共有アドレス空間内でリンクされることなく、プログラム間で通信する場合、プログラム間の通信のメカニズム（構造）および通信のセマンティクス（どのような種類の情報が交換されるか）を分析して、個別具体的に判断することになります。コマン
ド起動（fork、exec など）、パイプ、ソケットは原則として別個のプログラム間の通信にすぎず、原則として伝搬しませんが、通信の態様が密接である場合には伝搬することがあります。また、プラグイン（Plug-in）は、通信の態様が密接である場合は伝搬することがあります。

（４）伝搬しない実装方法
GPL プログラムと自社開発プログラムを組み合わせる場合、次の条件をすべて満たす利用態
様であれば、GPL プログラムが自社開発プログラムに伝搬しないと考えられます。
① 自社開発プログラムは、独自開発したコードであって、GPL のコードを複製または翻案（GPL のコードに依拠して実質的に類似）していない。
② それぞれのプログラムは、分離可能で、メモリ空間（プロセス空間）を共有しない230。
③ 標準インターフースを介して通信をおこなう。
④ コミュニケーションのメカニズムについては、静的にも動的にもリンクしない通信方法（パイプ・ソケット、プロセス間通信、プラグイン、コマンド起動）を選択する 。
⑤ 自社開発プログラムと GPL プログラムの間で相互交換される情報は、関数やパラメータのタイプや数の定義 (ほとんどが非著作物) である（セマンティクスが親密でない）。
⑥ 相互依存性が低い（自社開発プログラムの有無が GPL のコード動作の正否に影響しない）
231。

以下、なぜこのように考えるかについて、解説していきます。

リンクの伝搬性に対する例外として、GPL v2 with Classpath exception は、Java の標準クラスライブ
ラリのフリーな実装を作るプロジェクトで、ライブラリコードを提供する企業の自社開発プログラムにGPL の全ての条項を適用せず、自社開発プログラムがリンクしても伝搬しないという例外ライセンスもある。https://www.gnu.org/software/classpath/license.html
230 外観上一個の著作物で、「２つの作品（プログラム）が一体不可分の有機的関係を持って結合した形態
で、表現を分離抽出して論じられないもの」は、全体として一個の著作物になる。
231 「相互に牽連性を持つ機能の集合体」で「一の結果を得る（著作権法 2 条 1 項 10 の 2 号参照）
」シー
ケンスに組み込まれている場合には、二次的著作物（同 2 条 1 項 11 号）になる可能性がある。サイボウズ･
ユーザインタフェースについて、東京地裁平成 13 年 6 月 13 日判例時報 1761 号 131 頁〔評釈〕山本隆司「ユーザインターフェースの著作物性」判例時報 1782 号 206 頁（2002 年）参照。
229

133

４．伝搬性判断基準の根拠（１）この FAQ が採る解釈基準①GPLv2 が適用されるプログラムを基礎とした作品（work based on the Program）とは、米国著作権法 101 条に規定されている派生物ないし二次的著作物（derivative work undercopyright law）と同一の意義であるものと考えられますが、この FAQ では、翻案、二次的著作物ないし派生物に関する著作権法の解釈に加えて、GPL のライセンス文言を重視して考えます。
②同一の課題については、GPLv2 と GPLv3 を統一的に解釈します。FSF の解釈としては、バージョンによらず基本的な考え方は変わらないという建前をとっていますから、GPLv2についても GPLv3 についての現時点の考え方に従って解釈されるでしょう。
③FSF（Free Software Foundation）が著作権者であるか否かにかかわらず、FSF の公式見
解や FAQ を尊重して、ライセンサーの合理的意思を解釈します。著作物の利用許諾においては、ライセンス条件を決定する権利は著作権者が持っています。しかし、FSF が著作権者である場合はもちろん、FSF が著作権者でない場合であっても、FAQ やその他の FSFの見解が、裁判においても参酌されて、ライセンス条件の解釈に影響すると考えられますから、事実上これらに従って考えておくことが安全であると思われます。すなわち、企業が避けるべきリスクについて、OSS コミュニティとの係争事件の予防に重点を置くならば、FSF が採用する見解寄りでライセンス条件を解釈することが安全でしょう。

（２）単一の一個のプログラム
FSF の FAQ によると、「単なる集合物（collective works）」と「結合（combining）」との区別について、次のように述べています232。

Combining two modules means connecting them together so that they form a single
larger program.

If either part is covered by the GPL, the whole combination mustalso be released under the GPL--if you can't, or won't, do that, you may not combinethem.
二つのモジュールを結合するとは、それらを一緒に接続しそれらが単一のより大規模なプログラムを形成することを意味する。もし、いずれかの部分が GPL でカバーされていれば、結合物全体も GPL の下でリリースされねばならない。もし、あなたがそうできないとかしたくないなら、あなたは結合してはならない。

Free Software Foundation, FAQ「GNU ライセンスに関してよく聞かれる質問」『「集積物」とそのほかの種類の「改変されたバージョン」の違いは何ですか?』の第 2 パラグラフ
https://www.gnu.org/licenses/gpl-faq.ja.html#MereAggregation
232

134

FAQ は、続けて次のとおり述べています233。
If the modules are included in the same executable file, they are definitely combinedin one program.
モジュールが同じ実行ファイルに含まれている場合、それらは、言うまでもなく一つのプログラムに結合されている。

すなわち、２つのプログラムを結合して１つの大きなプログラムにする場合、一方が GPL なら全体も GPL にしなければなりませんが、同じ実行ファイルに含まれているなら単一のプログラムであるとしているので、GPL が伝搬しているといえます。したがって、静的リンクは、プログラム実行前のコンパイルまたはリンクされた段階で１つのものとなりますから、複数のプログラムが実行前の段階で結合していることは明らかであって、伝搬するものと考えられます234
著作権法の解釈としても、GPL プログラムを複製し、自社開発プログラムと一体化して、一個プログラムとして合体してしまえば、複製物または著作権が及ぶ派生物（derivative works，
翻案して作成した二次的著作物）になる可能性が高いでしょう（３）メモリ空間の共有
動的リンクおよび共有ライブラリは、プログラム実行時に共有メモリ空間上で、プログラムが実行される仕組みです。この点について GPLv3 第１条は、次のとおり、共有アドレス空間上で実行されるもの（動的リンクおよび共有ライブラリ）の場合、サブプログラムのソースコードを提供する必要があると規定しており、GPL が伝搬すると考えられます235。

The “Corresponding Source” includes （中略）the source code for shared libraries anddynamically linked subprograms that the work is specifically designed to require,
such as by intimate data communication or control flow between those subprograms
and other parts of the work.
コレスポンディング・ソース（提供を要求されるソースコード）には、サブプログラムと作品のその他の部分との間に親密なデータ交換またはコントロールフロー等により、作品が特定的に必要とするよう設計された共有ライブラリやダイナミックリンク・サブ
プログラムを含む。

Free Software Foundation, FAQ 前掲（注 13）第 3 パラグラフ参照。
Free Software Foundation, FAQ『（GPL の）及ぶ作品に対し、静的 vs 動的にリンクされたモジュールについて、GPL には異なる要求がありますか?』参照。
https://www.gnu.org/licenses/gpl-faq.ja.html#GPLStaticVsDynamic
235 GPLv3 第 1 条第４パラグラフ参照。
https://www.gnu.org/licenses/gpl-3.0.ja.html
233
234

135

If modules are designed to run linked together in a shared address space, that
almost surely means combining them into one program.
もし、モジュールが共有アドレス空間でリンクされるなら、それはそれらのモジュールを１つのプログラムに結合していることを意味するのはほとんど確実である。
さらに、FAQ は、次のように規定しています236。
A compilation of a covered work with other separate and independent works, which
are not by their nature extensions of the covered work, and which are not combinedwith it such as to form a larger program, in or on a volume of a storage or
distribution medium, is called an “aggregate” if the compilation and its resulting
copyright are not used to limit the access or legal rights of the compilation's users
beyond what the individual works permit. Inclusion of a covered work in an
aggregate does not cause this License to apply to the other parts of the aggregate.
カバーされる作品と、別の分離・独立した作品（性質上カバーされた作品の拡張物ではなく、一個のより大きなプログラムとなるよう合体されていないもの）の編集物が一つのストレージまたは頒布媒体上にある場合、―もし、その編集物及び結果としての著作権が当該編集物のユーザのアクセス又は法的権利を当該独立した作品の許容する限度を超えて制限するために用いられてないなら、―「集合物」と称する。カバーされた作
品を集合物に入れたとしても、本ライセンスを当該集合物の他の部分に適用させるものではない。

したがって、動的リンクは GPL が伝搬すると考えられます237。さらに、メモリ空間の共有については、GPLv3 の 5 条に次のような記述があります238。自社開発プログラムに GPL が適用されないように設計するためには、メモリ空間を共有しないことが一つの要件になるでしょう。

Free Software Foundation, FAQ 前掲（注 13）第 4 パラグラフ第 2 文参照。
GPLv2 では“Derivative Works”という用語が使われており、これはアメリカ著作権法の用語なので、
アメリカ著作権法の解釈が問題となり、学説によっては、GPL を契約ではなくライセンスと位置づけた上で、伝搬する範囲を著作権法上の派生物に限定し、GPL プログラムを改変しない動的リンクは、伝搬しないと主張する見解もある。See Curt Blake and Joseph Probst, LOADED QUESTION: EXAMININGLOADABLE KERNEL MODULES UNDER THE GENERAL PUBLIC LICENSE V2, 7 Wash J.L. Tech. &Arts 265 (2012). グレーゾーンの法律判断は、各国の裁判所による著作権法の解釈によって左右される。
238 https://www.gnu.org/licenses/gpl-3.0.ja.html
236
237

136

なお、FAQ には次のとおり規定されており、メイン関数を使うだけでは伝搬しないものと考えられます239。
If the program dynamically links plug-ins, but the communication between them islimited to invoking the `main' function of the plug-in with some options and waiting
for it to return, that is a borderline case.
プログラムがプラグインと動的にリンクされていますが、それらの間のコミュニケーションはいくつかのオプションと共にプラグインのメイン関数を呼び出して返値を待つだけという場合は、限界事例でしょう。

（４）標準インターフェース
GPLv3 において、「標準インターフェース（Standard Interface）」とは、標準化団体として認知された組織によって定義された公式な標準か、ある特定のプログラミング言語向けに指定されたインターフェースの場合には、その言語を利用する開発者の間で広く使われているインター
フェースのことを指すと定義されています。
自社開発プログラムを GPL プログラムと連係動作させるときに、標準インターフェースを介したというだけでは、伝搬しないとは判断できず、自由なプログラムと自由ではないプログラムとがそれぞれ独立を保った形で通信（communicate）し、それらが事実上単一のプログラムとなってしまうような方法で結合されていないことを確認する必要があります 240。当該自社開発プログラムのみが動作可能なように特殊なインターフェースを作成して、自社開発プログラムを
GPL プログラムと連係動作させる場合、全体として分離不能な一個のプログラムであると判断される可能性が高くなります241。

Free Software Foundation, FAQ「GPL の及ぶプログラムで使うためにプラグインをわたしが書いたとして、わたしのプラグインの配布に際して、わたしが使えるライセンスにはどのような要請があります
か?」https://www.gnu.org/licenses/gpl-faq.ja.html#GPLAndPlugins
240 Free Software Foundation, FAQ「GNU ライセンスに関してよく聞かれる質問」『「集積物」とそのほかの種類の「改変されたバージョン」の違いは何ですか?』https://www.gnu.org/licenses/gpl-faq.ja.html#MereAggregation
241 「相互に牽連性を持つ機能の集合体」で「一の結果を得る」シーケンスに組み込まれている場合には、二次的著作物（Derivative Works）になる可能性がある。http://www.itlaw.jp/saibouzu.pdf
サイボウズ･ユーザーインタフェイスについて、
東京地裁平成 13 年 6 月 13 日判例時報 1761 号 131 頁参照。
239

137

（５）コミュニケーションのメカニズム
コミュニケーションのメカニズムに関して、FAQ は、次のように規定しています242。
We believe that a proper criterion depends both on the mechanism ofcommunication (exec, pipes, rpc, function calls within a shared address space, etc.)
and the semantics of the communication (what kinds of information areinterchanged).
私たちは、適切な基準はコミュニケーションのメカニズム（exec、パイプ、rpc、共有
アドレス空間でのファンクションコール）とコミュニケーションのセマンティクス（どのような種類の情報が相互交換されるか）の両方によると考えている。
By contrast, pipes, sockets and command-line arguments are communication
mechanisms normally used between two separate programs. So when they are used
for communication, the modules normally are separate programs.
これ（共有アドレス空間内のモジュールのリンク）と逆に、パイプ、ソケット及びコマ
ンド引数は通常２つの別個のプログラム間で使われる通信手段である。よって、これらが通信のために使われるとき、モジュールは通常別個のプログラムである。

Plug-in もプログラムですが、GPL や FAQ において原則的には許されるというような記述はありません。FSF の FAQ によれば、“If the program uses fork and exec to invoke plug-ins, thenthe plug-ins are separate programs･･･” と記載されており、プラグインを呼び出すために forkと exec を用いる場合は、GPL が伝搬しないということは明確に記載されています243。これによれば、自社開発プログラムから Fork コマンドによってプロセスの枠を作成し、別個のメモリ空間に存在する GPL プログラムを exec コマンドによって起動し、自社開発プログラムの処理はexec された GPL プログラムの処理結果に依存しないで、独立に処理可能である場合、この２つは別個のプログラムであって、伝搬しないと考えられます。
したがって、パイプ、ソケットおよびコマンドライン引数の場合は、原則として、自社開発プ
ログラムは GPL プログラムとは別個のプログラムであり、伝搬しないものと考えられます。ただし、セマンティクスが親密である場合には伝搬するとされているので、注意を要します。

Free Software Foundation, FAQ)『わたしのプロプライエタリ・システムに、GPL の及ぶソフトウェ
アを組み入れたいのです。わたしには、このソフトウェアを使う許可は GPL が与えてくれるもの以外にはなにもありません。わたしはできますか? 』の第 3 パラグラフおよび第 5 パラグラフ参照。
https://www.gnu.org/licenses/gpl-faq.ja.html#GPLInProprietarySystem
243 Free Software Foundation, FAQ『GPL の及ぶプラグインをロードするように設計された不自由なプ
ログラムをリリースすることはできるでしょうか?』参照。
https://www.gnu.org/licenses/gpl-faq.ja.html#NFUseGPLPlugins
242

138

（６）セマンティクス
別個のプログラムが何のやり取りもしなければ伝搬することはありませんが、情報のやり取りをする場合には、原則として別のプログラムだとしても、その関係が密接になるために伝搬の対象に含まれるようになります。ただし、GPLv3 や FAQ などの関連文書は、一義的に明確な規定はしていません。FAQ の「コミュニケーションのメカニズム（exec、パイプ、rpc、共有アドレス空間でのファンクションコール）とコミュニケーションのセマンティクス（どのような種類の情報が相互交換されるか）の両方による」との記述があり、かつ、「複雑な内部データ構造を交換し、コミュニケーションの Semantics が親密である場合」という記述があります244。
But if the semantics of the communication are intimate enough, exchanging
complex internal data structures, that too could be a basis to consider the two parts
as combined into a larger program.
しかし、複雑な内部データ構造を交換し、コミュニケーションのセマンティクス（Semantics）が親密である場合は、それらも２つの部分がより大規模なプログラムに結合されているという基準になり得ます。

コミュニケーションのメカニズムとセマンティクスが、伝搬性を判断する上で重要な要因であるものの、データ（構造）やコントロールフローが如何に複雑、密接、意味的に関連付けられているか否かについては、程度問題であって、裁判例もなく、GPL の条文や FSF の FAQ もどの程度かについて判断基準を提示していません。したがって、プログラム間のやり取りをできる限り単純で少なくするほど安全であるとしかいえません。

（７）相互依存性
外観上一個の著作物で、２つのプログラムが一体不可分の有機的関係を持って結合した形態で、表現を分離抽出して論じられないもの（個別に利用することができないプログラム）は、全体として一個の著作物であると判断され、原著作物（GPL プログラムの著作権）と結合した自社開発プログラム全体が二次的著作物となる可能性があります245。
自社開発プログラムと GPL プログラムが相互に依存しており、結合した相手方のプログラム
を特定的に必要とする場合には、GPL が自社開発プログラムに適用されるものと解釈される可能性が高いでしょう。この点について、GPLv3 第 1 条には、次のとおり規定されています 246。

Free Software Foundation, FAQ「「集積物」とそのほかの種類の「改変されたバージョン」の違いは何ですか?」参照。
https://www.gnu.org/licenses/gpl-faq.ja.html#MereAggregation
245 最一小判平成 13 年 10 月 25 日判例時報 1767 号 115 頁〔キャンディキャンディ事件〕参照。
246 GPLv3 https://www.gnu.org/licenses/gpl-3.0.ja.html
244

139

Corresponding Source includes ・・・dynamically linked subprograms that the workis specifically designed to require, such as by intimate data communication orcontrol flow between those subprograms and other parts of the work.
Corresponding Source（すなわち提供を要求されるソースコード）には、サブプログラ
ムと作品のその他の部分との間に親密なデータ交換またはコントロールフロー等により、作品が特定的に必要とするよう設計されたダイナミックリンク・サブプログラムを含む。
さらに、GPL3 second draft footnote 20 によれば、容易に代替できるサブプログラムライブ
ラリなどのソースは、Corresponding Source に含まれないとされており、代替可能なサブプロ
グラムライブラリなどは、GPL プログラムと結合されていても直ちに伝搬するわけではないと考えられます。
したがって、自社開発プログラムから Fork コマンドによってプロセスの枠を作成し、別個のメモリ空間に存在する OSS を exec コマンドによって起動し、自社開発プログラムの処理は exec
されたプログラムの処理結果に依存しないで、独立に処理可能である場合、この 2 つは別個のプログラムであって、伝搬しないと考えられます。

５．API を介した連携動作
API とは、あるコンピュータプログラムの機能や管理するデータなどを、外部の他のプログ
ラムから呼び出してプログラム同士を繋ぎ、その機能を利用するための手順やデータ形式などを定めたインターフースです。API は、仕様を定めたドキュメントという意味で使われることもありますが、ここでは仕様を実現するプログラムという意味で用います。
API を介して GPL プログラムを動作させる場合であっても、GPL プログラムを配布する以上は、著作物の利用になります。したがって、Linux kernel 以外の OSS プログラムについては、それぞれのプロラムの著作権者のライセンス条件によって伝搬性の判断が異なる可能性があり、自社開発プログラムに GPL が適用されない旨を明示的に表示していない場合には、GPL のライ
センス条件に基づいて、GPL プログラムと連携動作する自社開発プログラムへの伝搬性を検討する必要があります。
API を介して、自社開発プログラムを GPL プログラムと連携動作させる場合、通常、メモリ
空間は論理的に GPL プログラムとは異なるユーザ空間に存在しているものと考えられますが、通信のメカニズムやセマンティクスを分析して、上記の基準に沿って伝搬性を判断することになります。

６．Linux システムコール
API のうち、特に、OS（Linux kernel）の機能をアプリケーションから呼び出してタスク（kernel に対して指示した処理）を実行するために使用される機構のことをシステムコール

140

（System Call）といいます247。
Linux においては、Linux kernel の創作者である Linus Torvalds 氏によって、Linux の著作権は、通常のシステムコールによってカーネルのサービスを使用するユーザ・プログラムには及ばないと宣言しているため248、Linux 上で動作する自社開発プログラム（アプリケーション）
が、kernel とは別のアドレス空間から、通常のシステムコールで kernel を利用する場合、そのアプリケーションに GPL が適用されない（伝搬しない）とされています249。
カーネルモジュールに関する GPLv2 の README ファイル冒頭の NOTE!
This copyright does *not* cover user programs that use kernel services by normal
system calls - this is merely considered normal use of the kernel, and does *not* fallunder the heading of "derived work".

Also note that the GPL below is copyrighted

by the Free Software Foundation, but the instance of code that it refers to (the linux
kernel) is copyrighted by me and others who actually wrote it.

Linus Torvalds

法律的には、上記の NOTE は、GPL の適用を除外する例外条項（GPLv3 の「追加的許可条項」）ではなく、派生物に関する Linus Torvalds 氏の解釈ですから、伝搬しないという結論が裁判所に確実に採用されるという保証はありませんけれども、著作権者である contributors から特段の異議がない状態が継続していますので、Linux kernel の通常の用法としてコミュニティの多数派に許容されているものと推定されます。
（作成日：2018 年 2 月 10 日）

Linux Programmer's Manual SYSCALLS(2)に system call の関数が記載されている。
http://man7.org/linux/man-pages/man2/syscalls.2.html
248 Linux の GPL のライセンス条項に記載されている宣言。
https://www.kernel.org/pub/linux/kernel/COPYING
249 Linux kernel の Read me ファイル（Appendix B: The Open Source Definition, Version 1.0）
http://www.oreilly.com/openbook/opensources/book/appb.html
なお、Linux のシステムコールの扱いについて、Linus Torvalds 氏のコメントが次のドキュメントに記載されている。Open Sources: Voices from the Open Source Revolution,
http://www.oreilly.co.jp/BOOK/osp/OpenSource_Web_Version/Web_version000106.html
http://www.oreilly.com/openbook/opensources/book/linus.html
http://www.oreilly.co.jp/BOOK/osp/OpenSource_Web_Version/chapter08/chapter08.html
247

141

Question D-3-2-1

GPL が適用されたエディタやコンパイラの出力と GPL

GPL が適用されたエディタ、データ変換などを行うコンバータ、コンパイラを利用して開発したソフトウェアなどに GPL は適用されますか？

Answer
1. エディタについて
GPL が適用されたエディタを用いてプログラムのソースコードを作成しても、通常、作成されたソースコードにエディタの一部やエディタの改変部分が含まれることはありません。そのため、エディタを用いて作成したソースコードは、エディタの著作権とは無関係に自由に利用できるものです。
GPL を作成した Free Software Foundation, Inc.（FSF）が示す FAQ250においても、GPLが適用されるエディタやツールを用いてプログラムのソースコードを作成しても GPL は当
該ソースコードに適用されない旨が述べられています251。この見解からも、GPL が適用されるエディタを用いて作成したソースコードに GPL が適用されることがないことが裏付けられます。
２．コンバータについて
では、データ変換を行うコンバータに GPL が適用されていた場合はどうでしょう。コン
バータは、エディタと異なり、入力した情報がそのまま出力されるものではなく一定の改変（形式変換）がなされたのが出力されるという点でエディタと異なります。
しかし、単なるデータ変換を行うコンバータの場合、入力されたデータの形式が変換され出力されるにすぎず、コンバータの一部が出力ファイルに含まれるようなことがないのが通例でしょう。その場合、エディタによるソースコードの作成と同様、当該出力ファイ
ルに GPL が及ばないと考えられます。もっとも、仮にコンバータの一部が変換後の出力ファイルに含まれてしまうようなものであった場合、後述するような GPL を適用させない旨の例外規定がない限り、出力ファイルにも GPL が適用されることとなります。
３．コンパイラについて252
次に、GPL が適用されたコンパイラを用いてコンパイルする場合はどうでしょう。
http://www.gnu.org/licenses/gpl-faq.ja.html
http://www.gnu.org/licenses/gpl-faq.ja.html#CanIUseGPLToolsForNF
http://www.gnu.org/licenses/gpl-faq.ja.html#GPLOutput
252 本稿では、コンパイル実行後、リンクも併せて実行した場合を前提として検討している。
250
251

142

（１）出力ファイルに GPL プログラムが取り込まれず、GPL が適用されるライブラリにリンクすることもないような場合、エディタやコンバータの場合と同様、出力ファイルに
GPL は適用されません253。
（２）次に、コンパイラの場合、出力結果に GPL が適用されたライブラリが取り込まれることがあります（静的リンク）。また、ときにコンパイラがあらかじめ用意しているイン
ラインコードが挿入されたり、コンパイラの一部が出力ファイルに取り込まれたりする場
合もあるかもしれません。これらの場合、GPL が適用された部分が出力ファイルに含まれますので、当該ファイルに GPL が適用されることになります。独立行政法人情報処理推進機構オープンソフトウェア・センター（IPA）が策定した『GPLv3 逐条解説』254（46頁）においても同様な言及がなされています。
もっとも、コンパイルの種類によっては、このような出力ファイルに GPL が適用されない場合があります。例えば GCC（GNU Compiler Collection）は、GCC が用意したライブラリが出力ファイルに含まれたとしても、当該出力ファイルに GPL は適用されないことを、例外規定を設けることによって明確に謳っています（Question D-3-2-2 参照）。
すなわち、このようなコンパイラを利用している限り、出力ファイルに GPL が適用されてしまうことを心配する必要はありません。したがって、利用するコンパイラ等の例外規定等を確認することも大切となってきます。
（３）
出力プログラムに GPL プログラムまたはその一部が取り込まれない場合であっても、実行時に GPL が適用されるライブラリと動的リンクする場合があります。
この場合、FSFの FAQ によれば、当該出力プログラムに GPL が適用されると記載されています255。し
たがって、例外規定において GPL が適用されない旨が定められている場合を除き、GPLが出力プログラムに適用されることになります。もっとも、FSF による FAQ は GPL の解釈の参考とはなりますが、FAQ はあくまでも解釈のガイドラインに過ぎず、裁判所においてこれと全く同じ判断がなされるとは限りませんので、この点には注意が必要です。
（作成日：2017 年 7 月 21 日）

FSF の FAQ も参照。
http://www.gnu.org/licenses/gpl-faq.ja.html#CanIUseGPLToolsForNF
http://www.gnu.org/licenses/gpl-faq.ja.html#WhatCaseIsOutputGPL
254 独立行政法人情報処理推進機構オープンソフトウェア・センター
https://www.ipa.go.jp/osc/license1.html
GPLv3 の策定に携わったエベン・モグレン（Eben Moglen）教授や Software Freedom Law Center（SFLC）
がその作成に協力している。
255 http://www.gnu.org/licenses/gpl-faq.ja.html#GPLStaticVsDynamic
253

143

Question D-3-2-2

GCC コンパイルによる GCC ランタイムライブラリとのリンクによる GPL への適用

GNU Compiler Collection256（gcc）でコンパイルして、GCC ランタイムライブラリ（libgcc,
libstdc++等）とリンクするプログラムが作成されました。GCC ランタイムライブラリはGPL ですが、GCC でコンパイルして作成されたプログラムにも GPL を適用しなければならないのでしょうか？

Answer
１．GCC を用いてコンパイルしたプログラム（出力プログラム）は、GCC のランタイムラ
イブラリ（libgcc, libstdc++等）をリンクして使用することが多いです。この場合、GCC
ランタイムライブラリは GPL が適用されていますので、GPL の原則からすれば、この出力プログラムにも GPL を適用する必要があるように思われます。
しかしそうすると、GPL以外のライセンスが適用されたプログラム（非 GPL プログラム）のコンパイラとしてGCC が利用されなくなるおそれがありますので、GCC の活躍の場が大きく制限されます。
そこでこの不都合を解消するため、GCC のランタイムライブラリについては、「GCC ラ
ンタイムライブラリ例外」257というものが規定されています。
この「GCC ランタイムライブラリ例外」とは、GCC を適切に用いてコンパイルしたプ
ログラムが、GCC ランタイムライブラリ（libgcc、libstdc++等）とリンクするようなものであっても、当該出力プログラムに GPL を適用する必要がないことが規定されていま
す258,259。よって、非 GPL プログラムが GCC ランタイムライブラリとリンクしたとしても、この規定により非 GPL プログラムに GPL が適用されることはありません。すなわ
ち、非 GPL プログラムのコンパイラとして GCC を用いることも可能です。260
２．上記のように、GCC によって適切にコンパイルされたプログラムは、「GCC ランタイ
ムライブラリ例外」の規定により GPL を適用する必要がないため、GPL の制限を受けず
GNU C Compiler と称されることもある。
GCC RUNTIME LIBRARY EXCEPTION version 3.1
http://www.gnu.org/licenses/gcc-exception-3.1.ja.html
この GCC ランタイムライブラリ例外は、GPL に対する追加的許可条項（GPLv3 第 7 条第 1 パラグラフ参照）と考えられている。またこの例外に言及した FSF の FAQ として
http://www.gnu.org/licenses/gpl-faq.ja.html#LibGCCException がある。
258 GCC RUNTIME LIBRARY EXCEPTION version 3.1 第 1 条
259 GCC ランタイムライブラリのソースコードの冒頭には、GPL が適用されることに加え「GCC ランタ
イムライブラリ例外」が適用される旨の記述がある。
260 GCC 以外のコンパイラである Bison も、コンパイル出力結果に GPL が及ばないとされている。Cf.
http://www.gnu.org/licenses/gpl-faq.ja.html#CanIUseGPLToolsForNF
256
257

144

に配布できます。もっとも GCC ランタイムライブラリのみを配布する場合は、GPL が適用され、GPL の条件に従って配布する必要がありますので、この点は留意してください。
（原稿作成日：2018 年 3 月 15 日）

145

Question D-3-3

GPL の OSS とのリンクによる GPL の伝搬－受託開発

ユーザの受託開発で GPL の OSS を利用したいと考えています。受託開発の場合、GPL の OSSと自社プログラムをリンクしても GPL は伝搬しませんか？

Answer
１．GPL の伝搬とは、GPL の OSS と一体化したソフトウェア全体（OSS の派生物）に対して、GPL の条件の効力が及ぶことをいいます。
受託開発においては、OSS を改変する等して OSS の派生物を作成しても受託者側が GP
L の要求するソースコードの提供等の義務を負わないことがあり得ます。
GPLv3261において、第 2 条は以下のような規定となっています。
2. Basic Permissions.
All rights granted under this License are granted for the term of copyright on the
Program, and are irrevocable provided the stated conditions are met. This License
explicitly affirms your unlimited permission to run the unmodified Program. The
output from running a covered work is covered by this License only if the output,
given its content, constitutes a covered work. This License acknowledges yourrights of fair use or other equivalent, as provided by copyright law.
You may make, run and propagate covered works that you do not convey, without
conditions so long as your license otherwise remains in force. You may convey
covered works to others for the sole purpose of having them make modifications
exclusively for you, or provide you with facilities for running those works, provided
that you comply with the terms of this License in conveying all material for which
you do not control copyright. Those thus making or running the covered works foryou must do so exclusively on your behalf, under your direction and control, on
terms that prohibit them from making any copies of your copyrighted material
outside their relationship with you.
Conveying under any other circumstances is permitted solely under the conditions
261

https://www.gnu.org/licenses/gpl-3.0.ja.html

146stated below. Sublicensing is not allowed; section 10 makes it unnecessary.
「GPLv3 逐条解説」（独立行政法人情報処理推進機構）262によれば、GPLv3 においては、
同条より、下図のような関係において、システム開発会社 B が、ユーザ企業 A の管理監督下において開発を行い、ユーザ企業 A 以外のためにプログラム C’の複製を行わないのであれば、システム開発会社 B の行為は、GPLv3 におけるコンベイ（プログラムの譲渡）に該当するものの、GPLv3 が定める対応ソースの提供義務等を負うことなくプログラム
C’をユーザ企業 A に提供できるとされており、また、GPLv2 においても、B から A への納品行為は、distribute に該当しないため、対応ソースコードの提供義務等が生じないとされています。

（「GPLv3 逐条解説」（独立行政法人情報処理推進機構）44 頁より）
上記解釈からすれば、顧客から特定の OSS の使用を要求されている受託開発で、当該顧客のためにのみプログラムの開発を行うようなものであれば、GPL の OSS と自社プログ
ラムをリンクした場合に、たとえ GPL が伝搬したとしても、対応ソースコードの提供義務等を免れることが可能と考えられます。
２．GPL の OSS と自社プログラムをリンクした場合に、自社プログラムにまで GPL が伝搬するかどうかは、リンクにより、OSS と自社プログラムが一体化していると見られるかによります。どのような場合に、リンクにより OSS と自社プログラムが一体化し、GPL が伝搬するといえるかについては幾つかの考え方がありますが、FSF（Free Software Foundation）の FAQ などを踏まえると、一般に、GPLv2 においては、以下のようになると考えられています263。
①静的リンクの場合は、OSS と自社プログラムは一体化している。
②動的リンクの場合は、
http://www.ipa.go.jp/files/000028320.pdf
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.ja.html#LinkingWithGPL、
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.ja.html

262

263

147

(ⅰ)相互にファンクションコールを行ったり、データ構造を共有したりする場合、OSS と自社プログラムは一体化している。
(ⅱ) main 関数を呼び出すだけという場合は、別プログラムとみなされることもある。
受託開発であることをもって、GPL の伝搬が否定されるというような基準はないため、受託開発による場合であっても上記の基準で GPL が伝搬するか否かを考える必要があります。したがって、貴社において、GPL の OSS と自社プログラムをリンクし、両者を委託者に提供する場合には、GPL の伝搬が生じ得ることになりますが、上記１で述べたよ
うな場合には、対応ソースコードの提供義務等が生じないことになります。
GPL の OSS をユーザに別途取得させ、貴社は OSS とリンクするようにした自社ソフ
トウェアのみを提供し、OSS と自社ソフトウェアをユーザ自身によって組み合させるよ
うな場合の GPL の伝搬に関しては、本書「D-3-4」を参照下さい。
（原稿作成日：2018 年 2 月 9 日）

148Question D-3-4

OSS のユーザによる取得・リンク－ ベンダによる代行

OSS 自体を、ユーザに別途取得させ、自社ソフトウェアと OSS を、ユーザの手元でユーザ自身によって組み合させることを考えています。この場合、自社ソフトウェアには OSS が含まれていませんので、自社ソフトウェアが OSS に伝搬する可能性を回避できると考えて良いでしょうか？ 上記で、ユーザが行う作業をユーザからの委託によりベンダが作業を行う（代行する）場合は、どのように考えれば良いでしょうか？

Answer１．
（１）本書「D-3-3」において説明したとおり、GPL の OSS とリンクされた自社ソフト
ウェアは、リンクの態様次第で OSS の派生物として GPL の適用を受けることになります。
しかしながら、貴社が開発する自社ソフトウェアが、OSS と結合しなくても稼働するものである場合や、OSS 以外のソフトウェアと結合しても稼働するような、OSS とは独立したソフトウェアである場合、当該ソフトウェア単体では、そのソフトウェアから OSS の表
現上の本質的な特徴を直接感得することができるようなものである264というような事情がない限り、OSS の派生物とは言えないことになります。
したがって、このような自社ソフトウェアのみを貴社がユーザに提供する行為に関し、
GPL の適用はなく、貴社は、ユーザに対し、自社ソフトウェアの使用条件を自由に定めることが可能となります（ユーザへのソースコードを提供しない合意、ユーザによる第三者
へのソースコードの提供の禁止等）。
一方、ユーザは OSS を入手して貴社のソフトウェアと組み合わせるため、リンクの態様
次第で OSS とこれにリンクした貴社のソフトウェアはともに GPL の適用を受けることになり、GPL に拘束されます。このため、仮にユーザがこれらのソフトウェアを配布（distribute 又はコンベイ）したときには、ユーザは第三者からプログラムのソースコードの提供を請求された場合、GPL にしたがって、貴社のプログラムに関するソースコードについても提供義務を負うことになります。この結果、貴社とユーザ間の契約において、ユーザがソースコードの提供を受けていなかったり、ソースコードの第三者への提供が禁止されたりしている場合、ユーザは GPL に違反することになり、GPL のライセンスを失うというような事態が生じ得ることになるため、貴社が自社ソフトウェアをユーザに提供するにあたっては、ユーザの使用態様を考慮した使用条件を定めることが必要になると考えられます。
なお、貴社が開発する自社ソフトウェアが，上述のとおり OSS の表現上の本質的な特徴
264

最判平成 13 年 6 月 28 日〔江差追分事件〕

149

を直接感得することができるようなものとなっているような場合には、そのソフトウェア
は OSS の派生物であるために当然、GPL の適用を受けることになります。
（２）貴社が開発する自社ソフトウェアが、OSS と結合した場合にのみ稼働するものであり、ユーザ側は OSS と動的リンクで結合させる以外、当該ソフトウェアを動作させる上で選択の余地がないものである場合、OSS とリンクをさせていない状態のソフトウェアしか提供（配布）をしていない以上、貴社の行為に関し GPL の適用はないとの考えがある一方で、貴社は、ユーザの元で全体として一個の著作物（プログラム）である OSS の派生物が生成され、ユーザにおいて全体として GPL が適用されることを知りながら、自ら敢えて自社ソフトウェアを提供（配布）するものであることから、自社プログラムをユーザに配布した時点で、GPL が適用されることについて承諾していると見られて、貴社に対し GPLが適用されると解釈される可能性もあると考えられますので注意が必要です。
FSF（Free Software Foundation）の FAQ においても GPL の及ぶプラグインをロードするように設計されたメインプログラムを、そのプラグインの使用のために配布する時には GPL の条項に従う必要があるとされ265，また，GPLv2 が適用される Linux のカーネルとリンクすることを意図した GPLv2 に準拠しないドライバを配布することは GPL に違反するとされていることから266，FSF も同様の立場に立っていると考えられます。
２．ユーザが行う作業をユーザからの委託によりベンダが作業を行う（代行する）場合、自社ソフトウェアの開発から OSS と組み合わせることまで、全てベンダ側で行うことになり、実質的には、ベンダの通常の受託開発と違いがないといえます。この場合については、
本書「D-3-3」で説明したとおり、一定の場合には、受託者側が GPL の要求するソースコードの提供等の義務を負わないことがあり得るといえます。
（原稿作成日：2018 年 3 月 29 日）

265
266

https://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins
https://www.gnu.org/licenses/gpl-faq.ja.html#NonfreeDriverKernelLinux150

Question D-3-5

GPL のソフトウェアによる社内システムのグループ
会社への提供GPL 適用のソフトウェアは、社内利用であればソースコードの提供は不要だと聞いています。GPL 適用のソフトウェアで作った社内システムを、ソースコードの提供を不要とした
まま、グループ会社でも使えるようにできますか？

Answer
１．GPL においては、GPL でライセンスされたソフトウェアを、自社内でコピーを作成して使用したり、改変したバージョンを開発し、使用したりすることは distribute（GPLv2）、又は conveying（GPLv3）に該当せず、ソースコードを提供する必要はないとされています267。したがって、社内利用であれば、ソースコードの提供は不要です。
２．また GPLv3 においては、同一企業グループ内268の行為が「内部的」なものとみなされpropagate に該当しないと解されることから269、conveying にも該当しないことになります。このため、本件のように、社内向けに開発したソフトウェアの複製をグループ会社（自社が議決権の 50%超を直接又は間接に支配している会社、又は自社の議決権の 50%超を直接又は間接に支配している会社）に提供し、当該グループ会社において使用させたとしても、conveying（GPLv3）に該当せず、ソースコードの提供は不要と考えられます。
GPLv2 においても、少なくとも、グループ会社における使用が、貴社の指揮管理のもとで行われているようなものである場合には、同様に distribute に該当せず270、ソース
コードの提供は不要と考えられます。
３．更に、貴社が ASP のように、自社で当該システムを運用して、グループ会社にはネットワーク経由で当該システムを利用させるようにする場合には、そのような行為は、著作物を配布する行為を伴わないため271、distribute（GPLv2）、又は conveying（GPLv3）に該当せず、したがって、ソースコードの提供義務等が発生することもないと考えられ
http://www.gnu.org/licenses/gpl-faq.ja.html#InternalDistribution, https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#InternalDistribution, http://www.gnu.org/licenses/gpl-faq.ja.html#Unreleas
edMods, https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLRequireSourcePostedPublic
268 ある企業とその企業が議決権の 50%超を直接又は間接に支配している企業群をいいます。
269 「GPLv3 逐条解説」（独立行政法人情報処理推進機構）27 頁（http://www.ipa.go.jp/files/000028320.pdf）
270 https://www.gnu.org/licenses/gpl-faq.html#DistributeSubsidiary, https://www.gnu.org/licenses/gplfaq.html#ConveyVsDistribute
271 これは、グループ会社以外にネットワーク経由で当該システムを利用させる場合も同様となります。
267

151

ます。特に GPLv3 では、「コンピュータネットワーク上での単なるやりとりであって複製物の伝送を伴わない場合は、コンベイに当たらない。
」272として、このことが明確になっています273。GPLv2 に関しても、FSF（Free Software Foundation）の FAQ274には、同様の考えを前提にしていると思われる記載があります。
したがって、ソースコードの提供義務等が発生することを避けながら、システムをグ
ループ会社に使わせるのであれば、ASP として提供するというやり方を検討する余地があるといえます。
なお、GPL と異なり、ネットワーク上で動作するソフトウェアを考慮した OSS ライセ
ンスとしては、Affero General Public License や、GNU Affero General Public License、
version 3（GNU AGPLv3）といったものがあります。
（原稿作成日：2018 年 2 月 10 日）

273

GPLv3 第 0 条第 7 パラグラフ「GPLv3 逐条解説」（独立行政法人情報処理推進機構）30～31 頁（http://www.ipa.go.jp/files/000028320.pdf）。

274

https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html

272

152

Question D-3-6

GPL ライセンスのソフトウェアをインストールした PCの貸出しが配布に該当するか

GPL の OSS を改変したアプリケーションをインストールした PC を、デモを見せたり試用させたりするために、日本において、特定の顧客へ貸し出した場合、ソースコードの提供は必要でしょうか？

AnswerGPLv3 では、ソースコードの提供義務等を発生させる conveying という行為について、第 0
定義において、「To “convey” a work means any kind of propagation that enables ot

条

her parties to make or receive copies.」（「著作物の『コンベイ』（convey）とは、プロパゲートに当たる行為のうち、他者が複製すること又は複製物を受領することを可能にする行為をいう。」）275と規定しており、プログラムを第三者に渡したり、第三者が入手可能な状態に置くこと、例えば、プログラムを第三者に配付したり、プログラムを組込みソフトウェアとして内蔵した組込み機器を販売したり、プログラムを WEB サイトにアップロードするような行為をいうと解されています276。
本件のように、アプリケーションをインストールした PC を、日本において、デモを見せたり試用させたりするために、特定の顧客へ貸し出す行為は、自己の顧客のうちの一人に貸し出す行
為であり、
「公衆」
（著作権法第 2 条第 5 項）への貸し出しとして、著作権者の承諾がなければ貸与権277の侵害（著作権法 26 条の 3）となる行為であることから、propagate（プロパゲート）に該当すると考えられること、わが国著作権法においては、プログラムに関する支分権（著作権法 21 条〜28 条）については、conveying と propagate の範囲は同一であり、conveying に該当しないが propagate には該当する行為はないものと考えられていることからすれば278、本件は、conveying に該当するとして、ソースコードの提供義務が生じると考えられます279。
（原稿作成日：2018 年 2 月 25 日）

275「GPLv3 逐条解説」（独立行政法人情報処理推進機構）22～23 頁（http://www.ipa.go.jp/files/000028320.pdf）。
276 前掲注 1, 27 頁
277 著作物（映画の著作物を除く。
）をその複製物（映画の著作物において複製されている著作物にあっては、当該映画の著作物の複製物を除く。
）の貸与により公衆に提供する権利。
278 前掲注 1, 30 頁
279 ただし、FSF（Free Software Foundation）が FAQ において、GPL のソフトウェアをラップトップにインストールし、そのソフトウェアのソースコードを提供することなく、そのラップトップを知人に貸す場合は、conveying に該当しないとの見解を示していることからすると（https://www.gnu.org/licenses/
gpl-faq.ja.html#LaptopLoan）、本件のような貸与行為は、未だソフトウェアが貸与者の管理範囲にあるものであり、「他者が複製すること又は複製物を受領することを可能にする行為」とはいえず、conveying には該当しないとして、ソースコードの提供は必要でないと解する余地も残ると考えられます。FAQ での説
明はないものの、GPLv2 についても GPLv3 と同様に考えられることから、本件の貸与行為は distribution に該当せず、ソースコードの提供は必要ではないと解する余地が残ることになると思われます。

153

Question D-3-7-1

R 言語の規約に従ったスクリプトと GPL

GPL が適用された R 言語280に従い作成したプログラム（スクリプト言語）に GPL は適用されるのでしょうか？

Answer
１．処理系のプログラムである「R 言語」には GPLv2 が適用されるところ、この「R 言語」に用いられるためのプログラム（スクリプト言語281）がプログラム言語としての R 言語の規約に従い作成された場合、このプログラムにも GPLv2 が適用されるかという問題があります。
２．日本の著作権法では、プログラム言語やその規約には著作権法による保護は及ばないとされています（著作権法 10 条 3 項）
。R 言語の規約は、ここに言うプログラム言語の規約にあたると考えられることから、これに著作権の保護は及ばないと考えられます。
そのため、R 言語の規約に基づきプログラムを作成することは、著作権法上自由です。
GPL の制限も含め、何ら制限に従う必要はありません。
３．では、R 言語の規約に従って作成したプログラムを入力し、処理系プログラムである「R言語」から出力された統計結果についてはどうでしょうか。
「R 言語」の出力は、統計解
析情報が出力されることになりますが、当該出力に「R 言語」の一部が含まれず、単なる解析結果が出力されるのであれば GPL が適用されることにはなりません（GPL が適用されるソフトウェアの出力と GPL の適用につき本書「D-3-2-1 GPL が適用されたエディタ
やコンパイラの出力と GPL」参照）。
４．ところで「R 言語」には、それに用いるための関数があらかじめプログラム（スクリプト）として作成され提供されているもの（「ライブラリ」と呼ばれたりします。）が多数存在します。そしてこれらのライブラリは、GPL の条件で提供されているものが少なくありません。このような GPL が適用されたライブラリを用いて「R 言語」用のプログラ
ムを自らが作成した場合、GPL の伝搬に関する議論に従い、自らのプログラムにも GPLが適用され、作成プログラムを配布する時に GPL の条件に従うことが求められる可能性
R 言語とは、OSS の名称であり、Wikipedia によれば、統計解析向けプログラミング言語及びその開発実行環境のこととされる。もっとも R 言語の仕様を実装した処理系についても、慣用的呼称として日本
では「R 言語」と呼ばれることが多いようである（なおフリーソフトウェア財団（FSF）によればこのよ
うな処理系は「GNU R」と呼ぶべきもののようである。
（https://ja.wikipedia.org/wiki/R%E8%A8%80%E8%AA%9E））
本稿では処理系プログラムについては括弧書きの「R 言語」として表記し、プログラム言語としての R 言
語は括弧書きを用いない表記とすることで区別した。
281 ここでいうスクリプトとは、GPLv2 が適用される R 言語のモジュール（プログラム）で統計処理を行わせるために入力するスクリプトのこと。
280

154

があります。もっともそのようなプログラムであっても、当該作成プログラムは配布せず自社内で「R 言語」に用いてその出力結果だけを配布するにすぎないような場合は、
GPL が適用されるプログラムの自社内利用に過ぎませんので当該作成プログラムのソー
スコード提供義務までは求められません。また出力結果についても、上述のように「R 言語」の一部や入力ライブラリの結果がそこに含まれないのであれば GPL が適用されることはありません。
（作成日：2018 年 3 月 10 日）

155

伝搬性－ソフトウェアの開発方法

Question D-3-7-2

当社は、商用のライブラリ製品（A）を開発し、再配布を許可する条件付きの独自のライセンス（非 GPL）で、ソースコードとオブジェクトコードを取引先に提供しています。商用のライブラリ製品（A）は、他のプログラムから動的リンクで呼び出される可能性があります。商用のライブラリ製品（A）を取引先に提供した場合において、取引先が、GPLv2
で配布されている他のプログラム（B）と動的リンクで結合したとき、再配布先の第三者から、商用のライブラリ製品（A）のソースコードの提供を請求される可能性があります。
（１）当社が第三者から商用のライブラリ製品（A）のソースコードの提供を請求された場
合、当社はどうすればよいでしょうか？
（２）取引先が第三者から商用のライブラリ製品（A）ソースコードを請求される可能性もあります。当社は、商用のライブラリ製品（A）のソースコードが取引先によって提供されることを防ぐために、どのような予防手段をとり得るでしょうか？

Answer
１．当社が第三者から商用のライブラリ製品（A）のソースコードを請求された場合（１）義務者は誰か
GPLv2 が伝搬する自社開発プログラムのソースコードを提供する義務を負う当事者は、
当該 GPLv2 プログラムを「配布（distribution）」した者（本件では取引先）です。自社開発プログラムのみを配布した当社は、原則として、ソースコードを提供する義務を負いません。取引先が当社に無断で、自社開発プログラムを GPLv2 プログラムと動的リンクし、結合したプログラムを第三者に配布した場合、当該取引先がソースコードを提供する義務を負うことになります。問題は、そのソースコードが自社開発プログラムを含むことです。
この場合における当事者の関係を図示すると、次のようになります。
①商用ライブラリ

当社③商用ライブラリ製品（A）
が GPLv2

製品（A）を提供

プログラム（B）の派生物となって、取引先

GPLv2 が伝搬する
商用ライブラ⑤ソースコーリ製品（A）

ドの提供を請

商用ライブ

ラリ製品（A） リンク

求する

④再配布

用していないので、第三者は当供を請求する権利がない。

GPLv2
プログラム
(B)

⑥当社は GPLv2 の OSS を利社に対するソースコードの提

②動的

第三者

156

（２）ソースコードを提供するか拒否するか
当社が第三者から商用ライブラリ製品（A）のソースコードの提供を請求された場合、当社は GPLv2 のプログラムを配布していないので、GPLv2 のライセンス条件に従う義務を負わないのですから、ソースコードの提供を拒否することができると考えられます。しかし、例外として、当社が商用ライブラリ製品（A）を取引先に提供するときに、GPLv2 プ
ログラムと動的リンクして動作することを設計上の前提としており、リンク以外のコミュ
ニケーションのメカニズムを採用することができない場合には、注意を要します。当社がGPLv2 の伝搬を予見しかつ認容していたものと判断された場合には、当社と取引先の間のライセンス契約における信義則上の附随義務として、ソースコードを提供することを命じる判決が出される可能性を否定できません282。
なお、当社がライブラリ製品（A）のソースコードを提供するビジネスを行っている場合
であれば、取引先からの再配布ではなく、当社と特定の第三者との間において、商用ライ
ブラリ製品（A）に関するライセンス契約を締結し、有償または無償で、当社から商用ライ
ブラリ製品（A）のソースコードを当該第三者に直接提供することも選択肢となるでしょう。
２．取引先が第三者から商用のライブラリ製品（A）のソースコードを請求された場合（１）契約による予防策
取引先は、GPLv2 プログラムを利用しているので、GPLv2 のライセンス条件を遵守しなければなりません。GPLv2 プログラムと商用ライブラリ製品（A）を動的リンクして、再配布する場合、商用ライブラリ製品（A）には GPLv2 が伝搬しますから、取引先が第三者から商用ライブラリ製品（A）のソースコードを請求されたときは、ソースコードを第三者に提供しなければなりません。当社がそれを防ぐためには、取引先にソースコードを提供する必要があるならば、商用ライブラリ製品（A）を提供する取引先とのライセンス契約において、次の義務を課すことによって、ソースコードが第三者に提供されることを防ぐことが実務的な対策になるでしょう。
① 配布する行為の禁止： 商用ライブラリ製品（A）の使用許諾条件として、取引先の社内使用に限定し、商用ライブラリ製品（A）のソースコードを第三者に再配布する
本書「D-4-1」参照。商用ライブラリ製品（A）が GPLv2 のプログラムとリンクされて実行されるように設計されているならば、GPLv2 とリンクして配布した者が第三者であったとしても、当社が商用ライブ
ラリ製品（A）のソースコードを提供しなければならないという考え方もある。
GPLv2 プログラムの著作権者の許諾を得ないで利用した場合に「著作権侵害になる主体」が、GPLv2のライセンス（著作物の利用許諾）を得てライセンス条件に従わなければならないとすると、物理的にGPLv2 プログラムをダウンロードした者が取引先であったとしても、例えば、自動的に GPLv2 プログラ
ムをダウンロードするインストーラと一緒に配布する等、その利用行為を「管理・支配」している当事者が当社である場合、当社が、著作権侵害の主体となり、適法な利用を主張するためには、GPLv2 ライセン
スがあると構成しなければならず、その結果、当社が GPLv2 ライセンス条件を遵守してソースコードを提供する義務を負う可能性があるかもしれない。最三小判平成 23 年 1 月 18 日民集 65 巻 1 号 121 頁〔まねき TV 事件〕、最一小判平成 23 年 1 月 20 日民集 65 巻 1 号 399 頁〔ロクラクⅡ事件〕参照。ただし、当社が GPLv2 プリグラムを物理的に「配布」していないので、反対の意見もあるであろう。この問題は、ケース・バイ・ケースの規範的判断になりそうであり、確立された見解がない。
282

157

行為を禁止する283；または② 伝搬する利用行為の禁止：

取引先が商用ライブラリ製品（A）を第三者に再配布する行為を許諾するのであれば、動的リンクではなく、GPLv2 が伝搬しない技術的な結合方法を用意し、商用ライブラリ製品（A）に GPLv2 が伝搬する結合方法を用いて GPLv2 プログラムとともに再配布する行為を禁止する284。
（２）契約違反の救済手段
このようなライセンス契約を締結した場合、取引先が第三者から商用ライブラリ製品（A）のソースコードを請求されたときは、その取引先は、GPLv2 のライセンス条件を遵守する
ならば、ソースコードを提供しなければならず、当社との契約違反になります。反対に、当社との契約を遵守するならば、ソースコードの提供を拒否しなければならず、GPLv2 のライセンス条件違反になるというデッドロック状況になります。
GPLv2 のライセンス条件に違反したことの責任は取引先が負い、取引先は、ライセンスが消滅すれば、GPLv2 プログラムの利用を止めなければならない結果になります。そして、取引先が GPLv2 に従って商用ライブラリ製品（A）のソースコードを第三者に提供した場
合、当社は取引先に対して、当社とのライセンス契約違反（債務不履行）に基づく損害の金銭賠償を請求することになるでしょう（民法 415 条）。
（作成日：2018 年 3 月 10 日）

283

一つの組織あるいは会社の内部において、GPLv2 プログラムの複数のコピーを作成して使うことは、「配布」とならないと考えられている。FSF「GNU ライセンスに関してよく聞かれる質問」
https://www.gnu.org/licenses/gpl-faq.ja.html#InternalDistribution
284 GPL が伝搬する結合方法については、本書「D-3-1」参照。

158

Question D-3-8

LGPL－リバースエンジニアリングの許可

１．LGPL プログラムに自社開発プログラムをリンクさせて利用する場合、どのような利用態様で配布するときに、自社開発プログラムのソースコードを提供する義務がありますか？
２．オブジェクトコードで自社開発プログラムを配布できる場合に、ユーザに対して自社開発プログラムのリバースエンジニアリングを許可しなければなりませんか？
３．リバースエンジニアリングを許可しなければならない場合、自社開発プログラムのどの部分について許可しなければならないのでしょうか？

Answer
１．ソースコード提供義務が及ぶ範囲（１）LGPL ライブラリそれ自体の複製および改変
LGPL（GNU Lesser General Public License）は、他のソフトウェアと組み合わされて実行されたり配布されたりする「ライブラリ」を対象に、GPL よりも緩和されたコピー･
レフト性の条件で、著作物の利用を許諾するライセンスです。以下、LGPL ライセンスが適用される OSS を「LGPL ライブラリ」といいます285。
LGPL ライブラリのコードそれ自体（original code）については、LGPL ライブラリを複製してそのまま配布する場合には LGPL が適用されます286。LGPL ライブラリを改変して配布する場合、(1) 改変物がライブラリのときは、LGPL のライセンス条件が適用され、(2)
改変物がライブラリでないプログラムのときは、ライブラリ部分だけ LGPL を適用することも可能ですが、LGPL の適用対象がライブラリであるため、全体を一つの作品として GPLに従うことも選択肢になります287。すなわち、LGPL ライブラリとその改変物については、
ソースコード提供義務があります288。
ライブラリの定義について、LGPLv2.1 第 0 条第二パラグラフは、” A "library" means a collection ofsoftware functions and/or data prepared so as to be conveniently linked with application programs(which use some of those functions and data) to form executables.”「ライブラリ」とはソフトウェア関数
やデータを集めたもので（ライブラリに含まれるいくつかの関数やデータを利用する）アプリケーション
プログラムとリンクして実行形式を作成するのに便利なよう準備されたものを意味する」と定めています。
http://www.opensource.jp/lesser/lgpl.ja.html
286 LGPLv2.1 第 2 条(c)項参照。
287 LGPLv2.1 第 3 条第三パラグラフ参照。
288 LGPLv2.1 第 4 条は、「あなたは上記第 1 節および 2 節の条件に従い、『ライブラリ』(あるいはその一部、または第 2 節における派生物)をオブジェクトコードないし実行形式で複製 または頒布することができる。ただし、その場合あなたはそれらに対応する完全かつ機械で読み取り可能なソースコードを添付し、
上記第 1 節および 2 節の条件に従いソフトウェアの交換で習慣的に使われる媒体で頒布しなければならない。
」と定めている。
285

159

（２）LGPL ライブラリに「基づく」派生物
LGPL ライブラリとともに配布される自社開発プログラムのうち、LGPL ライブラリを複製、改変、翻案し、LGPL ライブラリに基づいて作成されたものは、「LGPL ライブラリに基づく作品（work based on the LGPL ライブラリ）」、すなわち二次的著作物（derivative
works）と位置づけられ、LGPL が適用されますから289、LGPL ライブラリを「含む」自社
開発プログラムについて、ソースコードの提供を要します。
（３）LGPL ライブラリを「利用する」派生物 － リンクの場合 －LGPL ライブラリのコードの全部または一部の複製を含まず、LGPL ライブラリを自社開発プログラムとリンクして共に動作するように設計して利用する場合、自社開発プログ
ラムは、単体では LGPL ライブラリの二次的著作物になりません。しかし、リンクされて一体となった状態については、動的リンクか静的リンクであるかに関わらず290、自社開発
プログラムは二次的著作物（derivative works）になる可能性があり291、「LGPL ライブラ
リを利用した作品（work that uses the library）」と位置づけられています。
この場合、LGPL ライブラリを利用した作品に該当する自社開発プログラムには LGPLが適用されないとされており、LGPL ライブラリと自社開発プログラムをリンクしたプログラム（Combined Work）について、企業独自のライセンス（Proprietary なライセンス）
条件で、バイナリ形式で配布することができます292。ただし、次の条件を遵守しなければなりません293。
(1) LGPL ライブラリの使用事実、ライセンス条件および著作権表示を示すこと。
(2) LGPL ライブラリそれ自体とその改変物の完全かつ機械で読み取り可能なソースコー

LGPLv2.1 第 2 条第三パラグラフは、「あなたが同じ部分を『ライブラリ』を基にした著作物全体の一部として頒布するならば、全体としての頒布物は、この契約書が課す条件に従わなければ ならない。
」と定めている。また、LGPLv3 第 0 条は、結合された作品（combined work）に LGPL が適用されることを示している。
290 静的リンクの場合、LGPL ライブラリと自社開発プログラムの実行ファイルを繋ぐ中間オブジェクト（自社開発部分）にもソース提供義務が及ぶ可能性があり、この点において動的リンクと区別する実益がある。
291 LGPLv2.1 前文第 10 パラグラフには、”When a program is linked with a library, whether statically or
using a shared library, the combination of the two is legally speaking a combined work, a derivative of
the original library.”「あるライブラリがあるプログラムとリンクされる場合、それが静的にリンクされるか共有ライブラリとして利用されるかは問わず、両者の結合したものは法的に言って結合著作物、すなわ
ち元のライブラリの派生物となります。
」と定められている。
292 LGPLv2.1 第 5 条第二パラグラフには“However, linking a "work that uses the Library" with the
Library creates an executable that is a derivative of the Library (because it contains portions of the
Library), rather than a "work that uses the library". The executable is therefore covered by thisLicense. Section 6 states terms for distribution of such executables.”「LGPL ライブラリ の派生物を含
まないが、それとコンパイルされるかリンクされることにより、LGPL ライブラリと共に動作されるよう設計されているプログラムは、単体では、LGPL ライブラリの派生物ではなく、LGPLv2 の適用対象外だ
が、LGPL ライブラリをリンクして実行形式を作成すると LGPL ライブラリ の派生物となるため、その実行形式はこのライセンスで保護され第 6 条が適用される」と定められています。
https://www.gnu.org/licenses/old-licenses/lgpl-2.1.ja.html
293 LGPLv2.1 第 6 条参照。
289

160

ドを提供すること（LGPLv2.1 第 6 条(a)項）および 3 年間は提供する書面をユーザに申し出ること（同(c)項）。
(3) リンクに適切な共有ライブラリ機構を用いること（同(b)項）。この条件は、再結合または再リンクするのに適した形式であることが理由と考えられます。
(4) 著作物の頒布が指定された場所からコピーするためのアクセス手段の提供によって為される場合、上記で指定されたものを同じ場所からコピーするのに要する同等のアクセス手段を提供すること（同(d)項）。
(5) そのユーザが以上で指定されたもののコピーを既に受け取っているか、あなたがすでにこのユーザにコピーを送ったかどうか確かめること（同(e)項）。
さらに重要な条件として、ユーザ自身の利用のために著作物の改変を許可し、その改変物をデバッグするためのリバースエンジニアリングを許可しなければなりません294。
２．リバースエンジニアリングの許可
上記のように、LGPL ライブラリについては、LGPL ライブラリを利用する著作物を
LGPL ライブラリと結合またはリンクして295、LGPL ライブラリの一部を含む自社開発プ
ログラムを作成し、その自社開発プログラムを企業が選んだ自由なライセンス条件で配布することができ296、自社開発プログラムをオブジェクトコードで配布することができます。
ただし、LGPL ライブラリとリンクした自社開発プログラムのライセンス条件において、ユーザに対してリバースエンジニアリングを許可しなければならないとされています（LGPLv2 第 6 条）
。その理由は、ユーザが LGPL ライブラリを改変して、任意のプログラ
ムと再リンクしてデバッグし利用する自由を保障するためです297。
次に、ライブラリにリンクした自社開発プログラムを配布する場合、ユーザによる再リンクを可能にし、対応する LGPL ライブラリのソースコードを自由に改変して利用できる状態を維持するために、自社開発プログラムのオジェクトコード『又は』ソースコードを提供しなければなりません（LGPLv2.1 第 6 条(a)、LGPLv3 第 4 条 d1 項）。そして、LGPLv3の場合、「最小限の対応するソース（Minimal Corresponding Source）」の提供（LGPLv3
第 4 条(d0)）および特定のケースで「インストール情報」の提供についても定められていま
LGPLv2.1 第 6 条第一パラグラフ参照。
結合した作品（combined work）について、LGPLv3 第 0 条は、次のように規定している。
“Combined Work” is a work produced by combining or linking an Application with the Library. The
particular version of the Library with which the Combined Work was made is also called the “Linked
Version”.
https://www.gnu.org/licenses/lgpl-3.0.ja.html
296 LGPLv2.1 第 6 条(b)および LGPLv3:第 4 条(d)(1)参照。
297 LGPL LGPLv2.1 第 6 条第 1 パラグラフは、次のように規定している。
「As an exception to the Sections above, you may also combine or link a "work that uses the Library"with the Library to produce a work containing portions of the Library, and distribute that work underterms of your choice, provided that the terms permit modification of the work for the customer's own
use and reverse engineering for debugging such modifications.」
。
294
295

161

す（LGPLv3 第 4 条(e)）
。
LGPL ライブラリを利用する場合、自社開発プログラムをバイナリ形式で配布できることは、ソースコードの秘匿に有利であるものの、これらのライセンス条件を遵守しなければなりませんから、その影響として、自社開発プログラムの一部分について技術情報が流出する場合があり得ることは留意点でしょう。
LGPL に関するライセンス条件の骨子をまとめると、次の【図 1】のようになります298。
【図１】
配布すると、LGPL ライブラリのソースコード提供義務がある※ LGPL ライブラリそれ自体の複製・改変は、LGPL
に従ってソースコード提供義務がある。

LGPL ライブラリを利用して自社開発プログラムを製作・販売する場合※ LGPL ライブラリを自社開発プログラムとリンクして（静的リンクでも動的リンクでも）して利用する場合の伝搬性がGPL よりも緩和されている。
（work that uses the library）

LGPL ライブラ
リに「基づく」派生物・二次的
著作物

LGPL ライブラリを「利用する」派生物は、リンクであっても、任意のライセンス条件で配布可。
自社開発プログラムのソー
スコード提供義務なし

NO

LGPLv2.1 第 6 条

LGPLv2.1 第 5 条、
第6条

YES

（work based on the library）

LGPL ライブラリおよびそれに「基づく」改変物（derivative works）は、LGPL に従う※LGPLv2.1 は「ある種の特定のライブラリに適用されるもの」と定められており、適用対象を限定されている（前文第九パラグラフ。
「ライブラリ」の定義は、
第 0 条第二パラグラフ参照）。LGPLv2.1 第 3 条により、ライブラリのコードの一部をライブラリではない
プログラムの一部としてコピーする場合、GPL が選択肢となると記載されている。

バイナリの配布条件には、リバースエンジニア
リングを許可することが含まれている。

ヘッダファイルのインクルード

適用除外部分NO
YES
数値パラメータ
データレイアウ
ト小さいマクロ小さい関数 等

LGPLv2.1 第 5 条
第四パラグラフ、
LGPLv3 第 3 条但書

LGPL に従う義務なし

FSF「GNU ライセンスに関してよく聞かれる質問」（FAQ）
https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic
および「LGPL に対する動的リンクの誤解」（2013 年）参照。
http://atmarksharp.v01.jp/posts/lgpl-dynamic-link.html
298

162

３．リバースエンジニアリングを許可する範囲- 自社開発プログラム全部かライブラリ部分に限定されるか リバースエンジニアリングを許可すべき自社開発プログラムの範囲は、LGPL のライブ
ラリとリンクによって結合した部分であり、ユーザの自己利用目的の改変を許可し、かつ、
それをデバッグすることを許可しなければなりません。
LGPLv2.1 の場合、自社開発プログラム（the work）の修正（modification）を可能とし、かつ、その修正をデバッグするためのリバースエンジニアリングを許可すべきとされています。したがって、LGPLv2.1 の場合、LGPL のライブラリとリンクした自社開発プロ
グラム全体（the work）について、リバースエンジニアリングを許可しなければならないという解釈が成り立ちます299。ただし、このライセンス条件の趣旨･目的からみて、全体ではなく、一定の範囲で許可すれば足りると解釈する余地もあるものと考えられます。
LGPLv3 の場合、第 4 条のリバースエンジニアリングに関する文言が LGPLv2.1 と異なります。LGPLv3 は、LGPL ライブラリの改変された部分についてリバースエンジニアリ
ングを許可すれば足りるという解釈も成り立ちます 300 。しかし、技術的には、ユーザがLGPL ライブラリをデバッグする場合、コールスタック301をたどる対象モジュールが自社開発プログラム及ぶ可能性があり、デバッグを認める以上は、限定的に自社開発プログラ
ムのリバースエンジニアリングを許可せざるを得ないでしょうから、その範囲は LGPLv2.1の解釈に近づいていきます。
企業の実務上は、この解釈論の違いは、実益がないかもしれません。リバースエンジニ
アリング行為は一般的に密室で行われるので、自社開発プログラムを配布した企業にとって顕現性（外部から見えるのから、事実を探知し、証拠を提出できる可能性）がありません。実際にリバースエンジニアリングを許可する範囲を限定することは、相当困難であると考えられます。そして、問題が判明し、かつ放置できない事態というのは、自社開発プ
ログラムと類似するソフトウェアが市場で販売されたときではないでしょうか。
したがって、企業の対応としては、ユーザとのソフトウェア使用許諾契約において、LGPLの趣旨と文言に従って、「LGPL 適用される部分については、ユーザが LGPL ライブラリを改変、任意のプログラムと再リンク、デバッグして利用するために必要なリバースエンジ
ニアリングを許可」するとともに、その必要性を超える解析行為および営業秘密（自社開LGPLc2.1 第 6 条は、次のように規定している。
「As an exception to the Sections above, you may also combine or link a "work that uses the Library"with the Library to produce a work containing portions of the Library, and distribute that work underterms of your choice, provided that the terms permit modification of the work for the customer's own
use and reverse engineering for debugging such modifications.」
300 LGPLv3 第・・・条は、次のように規定している。
「You may convey a Combined Work under terms of your choice that, taken together, effectively do not
restrict modification of the portions of the Library contained in the Combined Work and reverse
engineering for debugging such modifications.」
301 コールスタック（Call Stack）は、プログラムに実行中にサブルーチンに関する情報を格納するスタッ
クである。
299

163

発プログラムのソースコードを含む）の提供・使用を禁止しておき、もしも契約違反があれば、解釈も証明も難しいリバースエンジニアリング禁止条項ではなく、契約違反（守秘義務違反）または不正競争防止法あるいは著作権侵害に基づいて、差止めや損害賠償を請求することが一つの対策であろうと考えられます。
４．ヘッダファイルのインクルード（１）ヘッダファイルとは何か
ヘッダファイル（Header file）は、C 言語や C++でのプログラミングで使われるファイ
ルで、ソースファイルの先頭部分に書かれたディレクティブによって、自動的にそのコードの内容を展開（include）して、コードを複製したのと同じ機能を使用することができる
ものです。
【図 2】
LGPL

include xxx.h…
自社開発プログラム

LGPL（２）LGPL が適用されないヘッダファイル
ヘッダファイルが、ライブラリ内の関数を呼び出すための関数名および引数と返値の定義のみから構成される場合であれば、LGPL は伝搬しないと考えられます。引数と返値の定義については、著作権法で保護されない規約（特定のプログラムにおけるプログラム言語の用法についての特別の約束（著作権法第 10 条第 3 項第 2 号））と考えることが可能であり、また、関数名のみでは、「電子計算機を機能させて一の結果を得ることができるようにこれに対する指令を組み合わせたものとして表現したもの」ではなく、「思想又は感情を創作的に表現したもの」でもありません302。したがって、これらは著作権で保護される著作物ではないと考えられることから、LGPL の対象であるライブラリの著作権者の許諾を得ることなく、ヘッダファイルをインクルードできることになります。
ヘッダファイルは、このような著作権で保護されないプログラムとは限らないのですが、
LGPLv2.1 第 5 条において、LGPL ライブラリの一部であるヘッダファイルから採られた
コード等を利用する場合が規定されており、LGPL ライブラリの一部分のオブジェクトフ
ァイルとして、数字のパラメータやデータ構造のレイアウト、アクセス機構または小さな
マクロや小さなインライン関数（長さが 10 行かそれ以下）のみを利用する場合、法律上、著作権法で保護される著作物は、「思想又は感情を創作的に表現したもの」（著作権法第 2 条第 1 項第 1号）であって、プログラム著作物の場合には、「電子計算機を機能させて一の結果を得ることができるようにこれに対する指令を組み合わせたものとして表現したもの」（著作権法第 2 条第 10 号の２）とされている。そして、プログラムの場合、プログラム言語（C++等の体系）、規約（プロトコル等）、解法（アルゴリズム等）は、著作権法で保護しないことを明確に規定している（著作権法第 10 条第 3 項）
。
302

164

二次的著作物（derivative works）と判断されたとしても、制限されないとしています303。
（３）LGPL が適用されるヘッダファイル
ヘッダファイルに関数のマクロやインライン関数などの実行されるコードを含む場合、それらのコードがプログラムの著作物であると、コードを複製して一個のプログラムを構成する二次的著作物になるので、著作権者の許諾を要する行為になり、LGPL のライセン
ス条件に従って、ソースコードを提供しなければなりません。
LGPLv3 の場合、第 3 条において、ヘッダファイルからの利用が数字のパラメータ等に限定されない場合であっても、①LGPL ライブラリが使用されていること及び当該ライブ
ラリには LGPLv3 が適用されること、ならびに②GPLv3 と LGPLv3 のライセンス文書を添付すれば、自社開発プログラムは自己が選択した条件のもとでライセンスしてかまわないとされています304。したがって、利用されている情報の性質や量にかかわらず、ヘッダ
ファイル情報のインクルードの場合は、共用プログラムについてソースコードの提供は要求されないものと解釈でき、この点は、GPLv2.1 とはライセンス条件の文言が異なります。
法的な文言解釈ではそのようになると考えるのですが、OSS コミュニティが採る解釈としては、最終的には各国の裁判所が判断すべき法律問題であるとしつつ、GPLv2.1 と GPLv3を統一的に解釈する立場もあり得るでしょう。そして、技術者にソフトウェアの開発中に困難な法律判断をさせることも推奨できません。さらに、一個の自社開発プログラムとリンクする OSS の中に LGPLv2.1 と LGPLv3 が混在する場合には、分別管理も難しくなる可能性があります。そこで、企業の実務としては、LGPLv2.1 と LGPLv3 に共通に適用する最大公約数的な実装技術標準を定め、ヘッダファイルのインクルードに関しては、安全サイドで管理するならば、GPLv2.1 の解釈に沿って一律に対応することも選択肢の一つかもしれません。
（作成日：2018 年 3 月 15 日）

LGPLv2.1 第 5 条の第四パラグラフは、次のように規定している。
If such an object file uses only numerical parameters, data structure layouts and accessors, and small
macros and small inline functions (ten lines or less in length), then the use of the object file isunrestricted, regardless of whether it is legally a derivative work. (Executables containing this object
code plus portions of the Library will still fall under Section 6.)
304 LGPLv3 第 3 条は次のように規定しており、”only”ではなく“not limited to”になっている。
「The object code form of an Application may incorporate material from a header file that is part of the
Library. You may convey such object code under terms of your choice, provided that, if the incorporated
material is not limited to numerical parameters, data structure layouts and accessors, or small macros,
inline functions and templates (ten or fewer lines in length), you do both of the following:(a) Give prominent notice with each copy of the object code that the Library is used in it and that the
Library and its use are covered by this License.
(b) Accompany the object code with a copy of the GNU GPL and this license document」
https://www.gnu.org/licenses/lgpl-3.0.ja.html
303

165

Question D-4-1

GPL の法的性質

GPL は契約なのでしょうか、開発者による権利不行使の一方的宣言なのでしょうか？

Answer
日本では、一般には GPL は契約であると考えられています。
１．問題の所在FSF（Free Software Foundation）の法律顧問であった Moglen 教授は、「ライセンスは契約ではない」と述べており305、この言葉を巡って、GPL の法的性質が議論されることがあります。この問題は、具体的には、OSS の改変物の配布者は、法的に、改変物のソース
コードを提供する義務を負っているか、という問題として議論されます。
GPLv2 に関して提起された問題ですが、GPLv3 においても明示的には解決されていない
問題です。
２．考え方
考え方としては、GPL は契約であるという考え方と、GPL は契約ではなく開発者による権利不行使の一方的宣言である、との考え方があります。
前者の考え方によると、GPL が適用されるためには、まず OSS の開発者と当該 OSS の利用者との間に、GPL による契約が成立する必要があります。そして、契約が成立した後は、当該 OSS の開発者と当該 OSS の利用者の双方が、GPL による法的義務を負います。
GPL には OSS の改変物の配布者に改変物のソースコードの提供を義務付ける条項があり
ますが、この考え方によると、改変物の配布者は契約上の義務として改変物のソースコー
ドの提供義務を負うこととなります306。
これに対して、後者の考え方によると、GPL は開発者が一方的に一定条件において権利を行使しないと宣言するものにすぎませんので、OSS の利用者は GPL に承諾する必要はありません。また、GPL は利用者を契約としては拘束しませんので、上記の例で、OSS の改
変物の配布者は改変物のソースコードの提供を行う契約上の義務を負いません。ただし、この場合は、配布者が改変物のソースコードを提供しないと、当該 OSS の利用について

https://www.gnu.org/philosophy/enforcing-gpl.html
契約と考えたとしても、配布者は、契約当事者ではない改変物の受領者に対し、契約上ソースコードの提供義務を負うのか、という問題がる。第三者のためにする契約の成立を認めることができるかどうか、という問題である。
305
306

166

GPL によるライセンスは及ばず、開発者に対し著作権侵害の責任を負うこととなります307。
３．検討
GPL が契約か開発者による権利不行使の一方的宣言か、という問題は、背反的なものではなく、GPL に基づく契約が成立していると法的に評価される場合には GPL は契約としての効力を有し、一方、契約成立の要件を満たしていない場合には GPL は契約の効力を有しない（そのため、開発者による権利不行使の一方的宣言となる）、という問題と整理できます308。
契約の成立は、契約の効力が裁判で争われる国の国際私法により準拠法が決定され、その準拠法に基づいて判断されます。例えば、日本法が適用される場合には、契約が成立しているというためには申込と承諾が存在する必要がありますし、英米法が適用される場合には、申込、承諾及び約因（consideration）が必要となります。
日本においては、一般には、GPL は契約であると考えられているようです309。これに対して、アメリカにおいては、契約の成立に必要な OSS の利用者による「承諾」が存在するかどうかが議論されています。多くの場合、OSS の利用者は、GPL の適用を受けることについて明示的に同意しておらず、利用する OSS に GPLv2 や GPLv3 が記載されたテキスト
ファイルが同梱されているに過ぎません。このような場合に、OSS の利用者が OSS を利用したからといって、GPL に拘束されることを承諾したといえるのか、という問題です。
理論的にはこのような問題が議論されていますが、現実的には GPL の法的効力が問題となることはほとんどありません。すなわち、OSS の配布、改変、業務上の複製等をおこなう利用者（OSS の著作権が及ぶ行為を行なう利用者）においては、開発者の許諾なく OSSを業務上複製、改変、配布する行為は著作権侵害となるため、GPL の効力を否定するインセンティブはありません。また、著作権が及ばない行為しか行なわない利用者（主にエンドユーザ）においては GPL により特段の義務を課されることはないため、やはり通常はGPL の効力を否定するインセンティブがないためです310,311。
307

なお、「権利不行使の一方的宣言」の法的性質については余り議論されていない。法律行為性の認められる単独行為と解した場合には、単独行為は原則として条件を付すことが出来ないとされていることや、単独行為は撤回することができないとされていることが問題となると考えられる（前者については OSS ラ
イセンスに付された条件は利用者を一方的に不利にするものではなく有効であり、後者については撤回しなくても条件を遵守しない利用はライセンスの範囲外であり権利行使が可能と解され、開発者が条件を遵守しない者に権利行使することについて支障はないように思われる。
）。事実行為と解した場合は、開発者が権利不行使の一方的宣言を行ったにも関わらず権利行使することは可能か（権利濫用、禁反言または信義則により権利行使は制約されるべきではないか、と思われる。
）、との問題がある。財団法人ソフトウェ
ア情報センター「オープンソフトウェアライセンスの最新動向に関する調査報告書」39 頁（2007）は、事実行為と解しているようです。
308 独立行政法人情報処理推進機構「GPLv3 逐条解説」149 頁（2009）309
財団法人ソフトウェア情報センター「ビジネスユースにおけるオープンソースソフトウェアの法的リス
クに関する調査 調査報告書」11 頁（2005）。同「オープンソフトウェアライセンスの最新動向に関する調査報告書」39 頁（2007）は、GPLv3 について、民法 526 条 2 項により、convey（伝搬行為。許諾がなければ侵害となる行為）の着手があった時に契約が成立するとしている。
310 Heather J. Meeker, THE OPEN SOURCE ALTERNATIVE, 223-232（2007）167

４．参考裁判例GPL ではありませんが、Artistic License という OSS ライセンスが契約かどうかが争われたアメリカの事件があります（Jacobsen v. Katzer, 535 F.3d 1373（Fed. Cir. 2008））。
この事件では、開発者である Jacobsen 氏は、Artistic License の下に、コンピュータを使って模型の電車をコントロールするデコーダチップをプログラムするのに用いるアプリ
ケーションを提供していました。Katzer 氏らは、同様のソフトウェアを提供していましたが、そのソフトウェアには Jacobsen 氏のソフトウェアの一部が利用されていました。しかし、Katzer 氏らは、Artistic License の条件である著作者の名前や著作権の表示等の条件を遵守していなかったため、開発者 Jacobsen 氏は、Katzer 氏らに対して訴訟を提起しました。被告側は、ライセンス違反は契約の条件違反に過ぎないため、著作権侵害にならない、と主張して、著作権侵害の際に認められる法定賠償を避けようとしたため、 Articstic
License の法的性質が問題となりました。
控訴審である連邦巡回区（US Court of Appeals for the Federal Circuit）は、著作権を非排他的にライセンスした者は著作権侵害の請求をする権利を放棄したものであり契約違反の請求のみが可能であるが、ライセンスの範囲に限定がありライセンシーがその範囲を超えた行為を行った場合には著作権侵害に基づく訴訟を提起することができる、とした上、被告の行為はライセンスの範囲外であるとして、著作権侵害を認めました。
この判決においては、主にライセンス条件の範囲内かどうかが検討され、ライセンスが契約であるかどうかについては明示的には判断されませんでした。
（作成日：2018 年 3 月 2 日）

エンドユーザが効力を争う GPL の条項としては、無保証や損害賠償義務の免責（GPLv2 11 条、12 条、GPLv3 15 条、16 条）が考えられる。
311

168

Question D-4-2

GPL が定める以上の制限の追加

GPL では、自由を制限するような条項は付加できないと聞きましたが、それはどのようなことでしょうか？
また、次の行為は GPL 違反となりますか？
①アプリの配信事業者の利用規約において「利用者は配信を受けたアプリを第三者に再配布できない」と定めている場合に、この配信事業者を通じて GPL プログラムを配信すること。
②GPL プログラムを配布するにあたり、受領者に法令遵守を誓約させたり、反社会的勢力ではないことを表明保証させること。

AnswerGPLv2 及び v3 は、OSS の配布者が受領者に対して GPL が認めている権利を制約することを禁じています。したがって、①の場合は GPL 違反となると考えられます（自らが著作権者であったり、著作権者から直接ライセンスを受けている場合を除く。）。これに対し、②の場合は GPL が認めている権利を制約するものではなく、GPL 違反とはならな
いと考えられます。
１．GPL の規定
GPLv2 は、OSS の配布者が、OSS の受領者に対し、GPL で認められた権利を制約すること一切を禁じています（第 6 条第 2 文）。
また、GPLv3 は、OSS の配布者が、OSS の受領者に対し、第 7 条第 3 パラグラフに定める例外を除き、GPL が定める以上の制約を課すことを禁じています（第 10 条第 3 パラ
グラフ）
。GPLv3 の第 7 条第 3 パラグラフで認められている例外は、利用者が追加した部
分に、次のような制約を追加することです。
①追加部分の保証の否認又は責任の限定を第 15 条および第 16 条とは異なる内容とする
こと②追加部分に関して特定の合理的な法的告知や作成者の記載をそのまま維持するよう求
めること③追加部分に関して出所に関する虚偽の表示を禁じること、または改変バージョンにオ
リジナルバージョンとは異なる表示をすることを求めること④追加部分に関して追加部分の作成者等の名前を宣伝目的で利用することを制限すること169

⑤商品名、商標、サービスマークの利用に関して、商標権の許諾を拒否すること⑥追加部分の配布により、直接追加部分の作成者等が受領者に責任を負う場合、追加部
分の作成者等が負う責任について配布者に免責を求めること
２．追加的制限の禁止規定の趣旨
上記のように GPL で受領者に認められた権利について、GPL が定める以上の制限を行なうことを禁じているのは、コピーレフトの思想によるものです。すなわち、コピーレフトの思想では、プログラムの利用は、改変されたバージョンを含めて誰にとっても自由であるべき、との考え方です。GPL はこの考え方を実現するために、GPL の利用者に対し、GPL で定める以上の制限を追加することを禁止しているのです。
GPL は、組み合わせて利用される他のプログラムに対しても適用され（詳細は本書「D-3-1」、「D-3-7-2」を参照）、他のプログラムのライセンス条件が GPL で定める以上の制限となる場合があります。このような場合は、当該プログラムを GPL プログラムと組み合わせることができません。この問題を、ライセンスの両立性（compatibility）の問題といいます。Free Software Foundation（FSF）は、他の OSS ライセンスが GPL と両立するかどうかについて、WEB サイトで見解を公表しています312。
なお、GPLv3 にて、一定の制限を認めた（第 7 条第 3 パラグラフ）のは、より多くの
OSS ライセンスとの両立性を実現するためです313。
３．①アプリの配信事業者の利用規約において「利用者は配信を受けたアプリケーション
を第三者に再配布できない」と定めている場合に、この配信事業者を通じて GPL プログ
ラムを配信すること。
この問題は、GPL で受領者に認められた権利について GPL が定める以上の制限を行なうことを禁じている GPLv2 第 6 条第 2 文、GPLv3 第 10 条第 3 パラグラフの解釈が関連します。この解釈を検討するためには、準拠法を決めた上で、その法律が適用される国でどのように GPL が解釈され、それを前提に本設問は GPL に違反しているか、という問題となります。我が国では、次のように考えられます。
（１） GPL プログラムの著作権を自らが保有している場合著作権者として、当該プログラムを GPL を適用させずに配信すれば、そもそも GPL 違反の問題は生じませんが、GPL を適用させた上で配信する場合は GPL と矛盾した行動を著
作権者自身が行っていることとなります。この場合、GPL 違反に対して権利行使は行われず、事実上問題は発生しないと考えられますが、プログラムの受領者から、利用規約によ

312
313

https://www.gnu.org/licenses/license-list.html
独立行政法人情報処理推進機構「GPLv3 逐条解説」88-89 頁（2009）170

る再配布の禁止について、GPL と矛盾するとのクレームがなされる可能性があります。
（２）著作権者全てからこの配信事業者を通じて配信することについて許諾を得た場合
上記１．同様、著作権者から別途許諾を得て当該プログラムを GPL を適用させずに配信すれば、そもそも GPL 違反の問題は生じませんが、GPL を適用させて配信する場合は、
GPL 違反に対する著作権者の権利行使はなされないものの、プログラムの受領者から、利用規約による再配布の禁止について、GPL と矛盾するとのクレームがなされる可能性があります。
（３） GPL プログラムの著作権者ではなく、著作権者から許諾も得ていない場合
この場合は GPL 違反になると考えられます。GPL プログラムをダウンロードした受領者
は、利用規約により GPL プログラムの再配布を制限されるため、GPL が定める以上の制限を課していると考えられます。
なお、これに関して、Free Software Foundation（FSF）が、2010 年、Apple 社の App
Store における GPL プログラム（GNU Go）の配信について、App Store の利用規約は、配信されたアプリを利用できるのは認証された端末 5 台までとするなどの制限があるため、
App Store による GPL プログラムの配信は GPL に違反するとの声明を出したことがあり
ます314,315。このときは、Apple 社は当該ソフトウェアの配信を中止する、という対応を取りました316。
４．②GPL が適用される OSS を配布するにあたり、受領者に法令遵守を誓約させたり、反社会的勢力ではないことを表明保証させることこの問題も準拠法を定めた上で検討すべき問題ですが、我が国では、次のように考えられます。
（１） GPL が禁じているのは、受領者が GPL により認められているプログラムの利用（複製、配布、改変）を制限することです（GPLv2 第 6 条第 2 文、GPLv3 第 10 条第 3 パラグ
ラフ）。
（２）受領者に配布する際に法令遵守を誓約させることや 反社会的勢力ではないことの表
明保証は、契約を締結するにあたり、当事者が法令遵守を誓約したり、自らは反社会的勢
http://www.fsf.org/news/2010-05-app-store-compliancehttps://www.fsf.org/blogs/licensing/more-about-the-app-store-gpl-enforcement
316 現在の Apple 社の利用規約は、利用規約によるアプリケーションの利用制限について、OSS ライセン
スにより認められたものは除かれる旨定めているが（ライセンスアプリケーションエンドユーザ使用許諾
契約 a 項 ）、除外される範囲が必ずしも明らかではないため、App Store の利用規約が GPL と両立するよ
うになったのかどうかは、必ずしも明らかではない。
314
315

171

力とは関係がないことを表明するものです。受領者によりこれが誓約・表明されなければ、配布者は受領者とはそもそも契約を締結しませんから、GPL 対象プログラムは受領者に配布されません。
したがって、法令遵守の誓約や反社会的勢力ではないことの表明保証は、受領者となる「資格」に関する規定であり、GPL により受領者に認められた「権利の制限」に関する規定ではない、と考えられます。
したがって、配布の際に当事者に法令遵守を誓約させたり受領者に反社会的勢力ではないことを表明保証させることは、GPL 違反とはならないと考えられます。
（３）なお、FSF は、配布者が受領者に対し、「合衆国にいること、あるいは、そのソフトウェアを関係する輸出規制の法律に従って配布することを意図している、と『表明し保証する』と要求」することについて、GPL に違反しないと説明しています。
（作成日：2018 年 3 月 2 日）

172

Question D-4-3

ライセンスを遵守していない OSS の利用

当社は、OSS を取り込んで自社製品を開発しようとしています。取り込もうとする OSS の配布者がライセンス条件を遵守していない場合、どのように対応すればよいでしょうか？
例えば、取り込もうとする OSS は LGPLv3 によるライセンスとしていますが、入手したファイルには LGPLv3 のライセンス文書しか存在しない場合、GPLv3 のライセンス文書を準備して同梱する必要があるのでしょうか？

Answer
配布元がライセンス条件を遵守していない場合でも、貴社はライセンス条件を遵守する必要があります。
OSS は、適用されるライセンス条件に従って利用することが、OSS の開発者が利用許諾する条件とされており、ライセンス条件を遵守しなければ、OSS の業務上の複製、改変、配布等の行為は OSS の著作権侵害となります。このことは、配布元がライセンス条件を遵守していない場合も同様であり、配布元がライセンス条件を遵守していない場合でも貴社
はライセンス条件を遵守する必要があります。
なお、配布元がライセンス条件を遵守しているか否かについては、ライセンス文書が必ずしも一義的ではない場合や、OSS の開発者自身がライセンス条件を理解しておらず、ライセンス条件と矛盾した対応を行っている場合317等、遵守しなければならないライセンス条
件とは何かの判断が容易ではない場合があり、このような場合には貴社による判断が必要となります。
設例の場合、LGPLv3 は、GPLv3 によるライセンスを前提として追加的許可を行なうものですので、提供すべきライセンス文書は GPLv3 と LGPLv3 となります。
したがって、入手したファイルに LGPLv3 のライセンス文書しか存在しない場合は、原則的には GPLv3 のライセンス文書を準備して同梱すべきと考えられます。なお、OSS の開発者自身が LGPLv3 のライセンス文書しか同梱していない場合には、FSF の意図とは異なり、ライセンサーである開発者自身は LGPLv3 のみの同梱でライセンス条件を満たすと認識しているものと考え、GPLv3 のライセンス文書を同梱しなくてもライセンス違反にはならないと考えることも可能と思われます。
（作成日：2018 年 3 月 2 日）

例えば、配布時に OSS 開発者の著作権表示を付すことをライセンス条件としているにもかかわらず、
OSS に著作権表示が記載されていない等。
317

173

E．コミュニティや OSS 関連団体
１．OSS コミュニティ
２．Openchain の取組

174Question E-1

コミュニティや OSS 関連団体

OSS コミュニティとはどういうものですか？ コミュニティとはどう関わるのが良いですか？ 代表的な OSS コミュニティにはどういうものがありますか？

Answer
１．OSS コミュニティとはどういうものですか？
OSS は、誰でも自由に複製、改変、配布ができるという特徴があります。誰かが機能強化、性能向上、不具合修正などを目的として行った改変は、元となった OSS へ還元されることにより、その OSS がより良いソフトウェアへすすむ素となります。広く普及している
OSS は、その作成者と、改良に携わる開発者、普及を支えるユーザやプロモータといった多くの人たちが協力して作り上げています。このように、OSS の作成者、開発者、ユーザ、
そのほか OSS の発展に貢献する人々の有志の集団を「コミュニティ」と呼んでいます318。
「コミュニティ」は、それぞれのコミュニティごとに違った特性を持っています。プロ
グラムを開発する場合、OSS 以外のプログラム開発で一般的に行われているように、プロ
グラムの設計図である仕様書をもとに、プログラムを作成する担当、テストをする担当、
プロジェクトの進捗を管理する担当など役割をもった人たちが協力して、あたかも頑強な建築物を建てるような進め方をするものもあります。一方、成功した OSS として有名なLinux OS の開発コミュニティでは、仕様書を作らず、誰もが自由にプログラムへ貢献することで、誰もが必要とする機能を持ちかつ安定した OSS を常に進化させ続けられています
319。

Linux OS のコミュニティでは、ゆるく開発の方向性を合わせるために、最初の開発者であるクリエーターを頂点とし、各パートにそれぞれの管理者であるメインテナをおき、その下に複数のサブメインテナをおくというプログラムの管理構造があります。別のコミュ
ニティでは、このような管理構造がないものもあります。さらにコミュニティによっては、クリエーターが離れていて、誰がその OSS を主導しているか不明な場合があります。このように、OSS はその著作権を多数の人が同時に持つ場合があること、コミュニティは誰でも開発の当事者になれる可能性があること、これらの曖昧さが知的財産権にかかわる諸課
題を複雑なものにしていると考えられます。
「コミュニティ」は、さまざまな立場にある OSS 開発者同士を結びつける場を提供して
http://ossforum.jp/node/491 「OSS の概要に関する知識 I」 日本 OSS 推進フォーラム
http://www.catb.org/~esr/writings/cathedral-bazaar/ “The Cathedral and the Bazaar” Eric S.
Raymond
318
319

175

いるといえます。また、コミュニティで OSS を開発する際、他のコミュニティの OSS を利用することも多く行われます。このように OSS 同士が結びついて、大きなソフトウェアの集合体へ発展する場合があります。このような OSS の発達の流れは、生物の場合になぞらえて「エコシステム320」と呼ばれます。OSS のエコシステムは、オープンなシステムであり、さまざまなアイデアを取り込むことで常にイノベーションを続けられる可能性を持っています。
成功している OSS コミュニティは、まさにオープンイノベーションを実現した例であるといえます321。近年ソフトウェアが大規模化することにともない、ソフトウェアのコモデ
ィティ化が認識されるようになりました。ソフトウェアに関わる企業は、すべてのソフト
ウェアを自前で調達していくことは難しく、OSS のエコシステムであるコミュニティに参画し、OSS を活用して自らのイノベーションを起こしていくことが重要になってきています322。
２．コミュニティとはどう関わるのが良いですか？
「コミュニティ」は、それぞれのコミュニティごとに違った特性を持っているため、どのように関わっていけば良いのか一様には説明できません。しかし、多くの（特に成功している）OSS のコミュニティは、目的を共有する者を誰でも受け入れ、より良いプログラムへの改善を繰り返しています。そのコミュニティが開発者のものであれば、プログラムを改善することが第一の優先事項になるはずです。
以下に、開発コミュニティに参加するときの留意事項を紹介します。
（１）communicate with each other
良いコミュニケーションをとるように心がけましょう。まずはどのようなコミュニティの活動をしているのか、そのメンバが共有している目的をよく知ることです。そして自分たちが必要としていること、その目的を表明してみましょう。両者には違いがあり対立するかもしれませんが、お互いを知ることはコミュニティを形成するための第一段階となります。
コミュニティのメンバ間でコミュニケーションをとる方法としては、インターネットを活用した方法があります。世界中から時差を越えて参加することが可能になるからです。
ツールとしては、mailing-list によるメールの一斉同報、wiki を用いた議論や情報交換、gitを用いたソフトウェアの流通などがあります。どのツールを用いているか、そこへどのよ
うに参加登録するか、参加登録なしに使えるのか、公開しているかどうかなどは、それぞれコミュニティで異なる運営をしています。
ecosystem : 生態系
http://www.nedo.go.jp/content/100790825.pdf 「オープンイノベーション白書（初版）」 オープンイ
ノベーション協議会
322 本書「基礎-2」
320
321

176

また、コミュニティのメンバが会合を行うことがあります。これらの会合は、非公開や、招待制のもの、一般に公開されるものもあります。一般に公開される会合に参加できれば、その OSS の主要な開発者と直にコミュニケーションをとるよい機会が得られるでしょう。
（２）contribute by various ways
コミュニティに参画するためには、そのコミュニティもしくは OSS へ貢献をすることが一般的に求められます。OSS への貢献というのは、OSS に対してソースコードを提供することを意味しています。それがその OSS を進化させるのに必要な行為であるからです。ときには、だれがどれだけ OSS へ貢献しているのか、その大きさがソースコードを提供した量で表されることもあります。
しかし貢献は、それだけに限定されているものではありません。例えば、その OSS を使用してバグを発見した場合、その状況を詳しくレポートすることは OSS の品質を向上させることにつながります。また例えば、カンファレンス等の公の場において、その OSS の使用に関するノウハウとか、改良の提案とか、何かを発表することも貢献になります。多くの人とその OSS の知識を共有することが、OSS を広くプロモートすることにつながるからです。さらに、そのようなコミュニケーションの場を提供することも大きな貢献です。それ以外に、OSS を開発するのに必要な計算機や開発者といったリソースを提供することも貢献に含まれます。
もちろん OSS を直接開発するだけではなく、知的財産権の保護を行うことなどさまざまな支援も貢献になります。
（３）collaborate for the better solution
企業にとって OSS を活用していくことは、さまざまな製品やサービスを実現するために不可欠になっています。これらの製品やサービスによってより良い社会を実現するために、企業は OSS への貢献を行うことにより、多くの OSS を育成していくことが必要です。それは良い社会を実現するための、さまざまな課題を解決することと言い換えられます。どのような課題があり、どのように解決していくのか、OSS コミュニティと企業はコミュニ
ケーションによって目的を共有していくことで双方が進化していくと考えられます。
OSS コミュニティとは、そこに従属するものでも、また敵対するものでもありません。
誰もがコミュニティと関係する当事者であり、協調して新しいイノベーションを起こしていく場として、コミュニティへ参画することが望まれます。
３．代表的な OSS コミュニティにはどういうものがありますか？
OSS の開発は、開発者がボランタリなコミュニティを形成することで発展しました。しかし、OSS をプロモートし、その規模を維持し続けるためには、主に資金的なサポートが必要であり、そのための様々な形態の非営利法人（NPO）が組織されています。また複数

177

の OSS コミュニティで共通で利用されるサービスを提供する団体もあります。ここでは代表的なコミュニティ、NPO、関連団体を紹介します。
(1) Apache Software Foundation
略称

ASF

正式名称

THE APACHE SOFTWARE FOUNDATION

種別

NPO

設立年

1999 年 3

所在地

月

324

501(c)(3)323

米国デラウェア州

メンバ構成

個人会員 500 名以上 企業会員 50 団体 貢献者 4500 名以上

対象

Apache HTTP Server, Tomcat, Struts, Subversion, Hadoop など OSS 350 以
上概要

もともと HTTP server の OSS 版開発からスタートし、WEB サイト関連ソフ
トウェア、分散システム向けなど多くの OSS プロジェクトを持つ。スタート
時は開発者同士のコミュニティであったが、WEB サイトの普及にともない支援企業も拡大した。
OSS ライセンスは独自に定めた Apache License (V1.0, V1.1, V2.0)がある。

参照 URLhttps://www.apache.org/foundation/(2) Free Software Foundation
略称

FSF

正式名称

FREE SOFTWARE FOUNDATION, INC.

種別

NPO

設立年

1985 年 10 月

所在地

米国マサチューセッツ州

501(c)(3)
メンバ構成

貢献者 3000 名以上

対象

gcc, gdb, glib, gpg, emacs など GNU プロジェクト の OSS 約 400

概要

エディタソフトウェア emacs の作者 Richard Stallman により設立。UNIX
OS を OSS で実現するために種々のソフトウェア開発を行っている。開発プロ
ジェクトは GNU (Gnu is Not Unix の略) プロジェクトと名付けられていて、FSF は支援団体という位置づけになっている。主に開発者によって構成されることを特徴とする。OSS ライセンスに関しては、
「複製」
「改変」
「配布」の自由を遵守する Copyleft という考え方を提唱していて、Gnu General Public
License (GPL)、Lesser GPL (LGPL)、Affero GPL (AGPL)などを定めている。

参照 URLhttp://www.fsf.org/about/https://www.gnu.org/gnu/gnu.html

The federal law of the United States of America according to Title 26 section 501 (c) ［アメリカ合衆
国内国歳入法（USC 26）第 501 条 c 項］を登記した非営利法人(Non-Profit Organization) - (3)は教育、技術、アマチュアスポーツなどの分類
324 登記簿上の住所
323

178

(3) Linux Foundation
略称

LF

正式名称

THE LINUX FOUNDATION

種別

NPO

設立年

2000 年

所在地

米国オレゴン州

501(c)(6)325
メンバ構成

企業会員 約 260 団体

対象

Linux kernel および Linux 関連プロジェクト 50 以上

概要

設立時は Open Source Development Labs (OSDL)といい、2007 年に Free
Standards Group と合併し改組。Linux に協賛する企業を中心に構成されることを特徴とし、Linux 主要開発者を雇用するなど全般的な支援を行っている。
近年は産業への適用推進を行う Linux Standard Base (LSB), Carrier Grade
Linux (CGL: 通信キャリア向け), Automotive Grade Linux (AGL: 自動車向け), Civil Infrastructure Platform (CIP: 社会インフラ向け)など多くの関連
プロジェクトを運営している。また Linux のトレードマーク管理、OSS ライ
センスを理解するための Open Compliance Program, ライセンス表記の標準
化 SPDX, 検出ツール Fossology, ワークフローOpenChain326 など知的財産面での支援を行っている。

参照 URLhttps://www.linuxfoundation.org/about(4) Linux Kernel Developers
略称

－

正式名称

－

種別

開発者コミュニティ

設立年

メンバ構成

メインテナ/サブメインテナ 200 名以上、開発者 15,600 名以上(2005 年以降)

対象

Linux kernel

概要

OSS のオペレーティングシステムとして広い分野で活用されている Linux を1991 年

活動場所

管理ツール Git など開発する開発者の集まり。ほぼ 10 週ごとにバージョンアップを繰り返し、多くの修正や進化が短期間で行われている。年数回のミーティングのほか、ソースコード管理は Git システムを、日常の議論は Linux Kernel Mailing List
（LKML）を使うなど、インターネットによる情報交換を活用した開発が行われる。
参照 URLhttps://www.kernel.org/

The federal law of the United States of America according to Title 26 section 501 (c) ［アメリカ合衆
国内国歳入法（USC 26）第 501 条 c 項］ を登記した非営利法人(Non-Profit Organization) - (6)は商業組合などの分類326 本書「E-2」を参照
325

179

(5) Open Invention Network
略称

OIN

正式名称

OPEN INVENTION NETWORK, LLC

種別

LLC327

設立年

2005 年

メンバ構成

運営メンバ 10 社 ライセンシー 約 2150 社

対象

Linux 関連技術に関する特許（パテントプール）

概要

Linux System（Linux カーネルおよび関連するソフトウェア全体）使用にと所在地

米国ノースカロライナ州

もなう特許訴訟を防衛する目的で、設立。運営を行っているのは、Google, IBM,
NEC, Philips, Red Hat, Sony, SUSE, Toyota など。ライセンシーはクロスラ
イセンス契約によって自社の Linux System に関連する特許を無償で提供する代わりに、自由にプールされている特許を使用できる。加盟しているライセン
シーは 2000 社を越える。
参照 URLhttp://www.openinventionnetwork.com/about-us/(6) Open Source Initiative
略称

OSI

正式名称

Open Source Initiative

種別

NPO

設立年

1998 年

所在地

米国カリフォルニア州

501(c)(3)
メンバ構成

協賛団体 58 団体 スポンサー 13 団体

対象

OSS の定義（OSD: Open Source Definition）、普及、教育、個人会員 不明

およびライセンスが OSD を見たすか認定など
概要

OSS 関連団体の連合組織のような団体。主要な団体が加盟している。
ライセンスが OSS の定義に合致しているかどうかについて、承認を与えている。

参照 URLhttps://opensource.org/about(7) Software Freedom Law Center
略称

SFLC

正式名称

Software Freedom Law Center

種別

NPO

設立年

2005 年

所在地

米国ニューヨーク州

501(c)(3)
メンバ構成

不明

対象

OSS のライセンス、トレードマーク、特許等知的財産に関する法的サポート

概要

FSF の関連団体として発足。Eben Moglen を議長とし主に GPL に関する訴
訟の法廷代理人などを行っている。

参照 URL327

https://www.softwarefreedom.org/services/

Limited Liability Company

180

(8) 日本 PostgreSQL ユーザ会
略称

JPUG

正式名称

日本 PostgreSQL ユーザ会

種別

ユーザコミュニティ

設立年

1999 年

メンバ構成

正会員 45 名、協賛会員 13 団体、ウェブ会員 不明（2017 年 6 月）

対象

PostgreSQL (DBMS)

概要

世界各国にある PostgreSQL ユーザ会の日本支部。ウェブによる情報発信のほ

所在地

東京都

か、ユーザ同士のカンファレンス、勉強会、mailing-list などによる情報交換
を通じて、PostgreSQL の普及と発展のため活動を行っている。
参照 URLhttps://www.postgresql.jp/npo/about（作成日：2018 年 1 月 23 日）

181

Question E-2

OpenChain の取組み

最近、Linux Foundation で、OpenChain という取り組みが始まっているようですが、これはどういうものですか？

Answer
１．OpenChain との目的と期待効果（１）目指す姿（ビジョン）
OpenChain のビジョンは、OSS が信頼性と一貫性のあるコンプライアンス情報とともに提供される、ソフトウェア・サプライチェーンを実現することであり、OSS のサプライチ
ェーンにおいて、上流の OSS 提供者が下流の OSS 利用者に対して、配布する OSS に関する情報を一貫性と信頼性を維持して伝達していくことによって、容易かつ確実にソフトウェアライセンス条件を遵守できることを目指すプロジェクトです。
（２）使命（ミッション）
OpenChain のミッションは、OSS の効果的マネジメントを実現するための要件をソフト
ウェア・サプライチェーンに参加する人々のために確立することです。OpenChain の目的
は、上流の OSS 提供者の OSS ライセンス条件に対する法的解釈や判断を下流に伝えることではなく、事実として、配布するソフトウェアを構成する部品である OSS を正確に記載し、そのライセンス条件、著作権表示、ソースコード等をサプライチェーンに入る当事者がそのまま情報を共有していくことです。
（３）期待効果
OpenChain の仕様書は、OSS を利用する企業が遵守すべき必要最小限の基本的な要件を定義しています。その要件を満たすことによって、OSS ライセンス条件がすべて遵守されたことの保証にはなりませんが、OSS コンプライアンス・プログラムの品質、一貫性および完全性が十分なレベルに到達する可能性が大きく高まります。
企業の OSS 管理体制を OpenChain が定める仕様に合致させ、標準化された様式を用いて作成されたデータを受け渡していくことによって、業界全体で共有されるオープンソー
ス コンプライアンス関連情報の品質と一貫性の向上促進、および、コンプライアンス作業の再実施に起因するオープンソース関連の作業コストを低減する効果が期待されています。

182

２．経緯と性質2013 年、非営利団体の The Linux Foundation328のもとに、OpenChain Working Groupが作られ、ARM, Qualcomm, Samsung, SanDisk および Wind River.が参加して活動を開始しました。2016 年 4 月に、Open Chain が Linux Foundation の協業プロジェクトになって、企業が社内で守るべき OSS コンプライアンスのベスト・プラクティス（最良手法）として提案されました。
OpenChain は、OSS のライセンス条件を遵守するためのルールと手順を定めた仕様であって、法的な義務ではなく、国際的な標準規格制定団体（ISO 等）が定める規格でもありません。したがって、OSS を利用する企業が OpenChain の仕様に準拠しなかったとしても、法律に違反するわけではなく、従う義務はありませんが、企業の OSS 管理体制を改善するためには有益な提案であると考えられます。
２．OpenChain の仕様329
OpenChain 仕様書（第 1.1 版）によれば、OSS を利用する企業には、以下の項目を実行することが求められています330。この仕様は、組織による実現可能性の差異を考慮して、柔軟性がある仕様を目指しており、さまざまな組織が自社の目的に最適なポリシーやプロセスを作成することができます。説明用のスライド331 やハンドブックと合わせて参照すると良いでしょう332。
G1. すべての人が自分の利用する OSS に関する責任を理解し認識すること。
1.1. 供給ソフトウェアの配布について OSS ライセンス コンプライアンスを統制する
FOSS ポリシーが書面として存在し、組織内に周知されていること。
1.2. 社内のソフトウェア関係者に受講を義務付けた教育があること。
1.3. 各ライセンスで負う義務、条件および権利を判断できるように、確認したライセンスをレビューするプロセスが存在すること。
G2. コンプライアンスを履行するための責任者を任命すること。
2.1. OSS に関する門口機能を明確にし、責任者を任命すること。責任者の任命手続きを内部文書化し、窓口機能の連絡先が公開されていること。
2.2. 組織内部における OSS コンプライアンスを履行する役割を明確にすること。責任者を任命して、十分な予算や時間が与え、担当者に法的知識を習得させ、問題解決プロ

The Linux Foundation については、https://www.linuxfoundation.org/参照。
OpenChain の主な資料の日本語版は、次のサイトでダウンロードできる。
https://github.com/OpenChain-Project/Specification-Translation-JP
330 https://wiki.linuxfoundation.org/_media/openchain/openchainspec-2016-05-16-1.pdf
331 The OpenChain Curriculum, FOSS Training Reference Slides for the OpenChain Specification 1.1 ,https://wiki.linuxfoundation.org/_media/openchain/openchain-curriculum-for-1-1.pdf
332 Miriam Ballhausen, Shane Coughlan, Conformance Handbook for OpenChain Specification 1.1,
The OpenChain Project (2017)には、Self-Certification のためのチェックリストがある。
https://wiki.linuxfoundation.org/_media/openchain/openchain_conformance_conformance_check_1.1.p
df
328
329

183

セスも定めること。
G3. OSS を構成する部品のレビューと承認
3.1. OSS のソフトウェア・パッケージの全ての構成をリスト化し、適用されるライセン
ス条件を特定した OSS 構成部品表（Bill of material）を作成し管理するためのプロセスが存在すること。その情報を記録し、追跡可能な状態で保存し、手続きが適正に実施されていることを。
3.2. OSS のマネジメント・プログラムは、ソフトウェア・スタッフが OSS を利用する供給ソフトウェアに共通な OSS ライセンス使用態様（バイナリ形式、ソースコード形式、改変の有無、複数の OSS 間のライセンスの両立性など）に対応できること。
G4. OSS の内容物と生成物を引き渡す。
4.1. 供給ソフトウェアの各リリースに対し、OSS のマネジメント・プログラムの生成物一式（適用されるライセンス条件に従った著作権表示、ライセンス条件、改変の事実、
ソースコード等のコンプライアンス関連資料）が用意されていること。それを確実にする手続きも文書化し、コンプライアンス関連資料を保存すること。
G5. OSS コミュニティとの関係を理解する。
5.1.OSS プロジェクトに対して貢献することを統制するポリシーが文書化されて、組織内に周知されていること。周知させる手続きも文書化すること。
5.2.OSS プロジェクトへの貢献を組織が許容する場合、貢献ポリシーを実践するプロセスが整備されていること。
G6. OpenChain 要件適合の認定
6.1.組織が OpenChain に適合していると認定されるためには、OpenChain 仕様書第 1.1
版に記載された基準を満たす OSS マネジメント・プログラムを有していることを確認する。
6.2.仕様書への適合は、適合が認定された日から 18 か月間持続する。適合認定のための要件は OpenChain プロジェクトのウェブサイトで確認できる。
４．情報伝達フォーマット統一の動向
提供すべき情報である OSS の構成表の様式、記載内容、共有方法を定めた標準ファイル・
フォーマットとして、SPDX® Working Group が提唱しているのが、XML Tag フォーマッ
トを用いて標準化された Software Package Data Exchange®というメタ・データの形式です。サプライチェーンに入る当事者が共通のフォーマットを使用することによって、OpenChain の仕様に準拠することが容易になることが期待されます。
（作成日：2018 年 3 月 10 日）

184

F．知的財産に関する問題
１．特許条項を有する OSS ライセンスの概観と留意事項
２．特許調査３．OSS と越境問題

185Question F-1-1

GPLv3、Apache2.0 などの特許条項を有するライセンスの概観と留意事項（１）

特許ライセンス義務の条項333を有するライセンスにより配布された OSS を利用したことにより、特許権侵害の責任を負う場合はあるのでしょうか？

Answer
１．はじめに一般的には、ある特許の権利範囲に属しているソフトウェアを利用した場合、当該特許権者の許諾がなければ、当該利用者は当該特許権の侵害責任を負うことが原則です。
特定の OSS ライセンスで配布された OSS が、ある特許の権利範囲に属していた場合、当該特許権を有している者が当該 OSS と一定の関係にあるか否かが、当該特許に関する許諾の有無に影響を与えると考えられますので、以下の二つに分けて検討します。
ア

特許権者が当該 OSS と無関係な第三者である場合

イ

特許権者が当該 OSS の上流の配布者である場合

２．上記ア（特許権者が当該 OSS と無関係な第三者）の場合
この場合の特許権者は、当該 OSS と無関係であり、OSS ライセンスに何ら拘束されるものではありません。
したがいまして、当該特許権者から許諾を得ていない限り、当該特許の技術的範囲に含まれる OSS を利用した者は、原則として当該特許権の侵害責任を負うものと考えられます。
３．上記イ（特許権者が当該 OSS の上流の配布者）の場合
OSS の上流の配布者は、OSS ライセンスに従うことを条件に、配布した OSS の利用を許諾しています。
このため、OSS を受領した下流の利用者は、OSS ライセンスに従わずに OSS を利用していれば特許権の侵害責任を負う可能性がありますが、OSS ライセンスに従って OSS を利用している限り、特許権の侵害責任を負わないのが原則です。
しかし、OSS ライセンスの中には、特許ライセンス義務の条項において対象となる特許権を限定していたり、改変行為について特許ライセンスを明示的に与えていなかったりす
るものもみられます。中流者334が OSS を改変することにより、それ以降の受領者には特許
333

GPLv3 では 11 項、Apache License V2.0 では 3 項にてコントリビュータが特許をライセンスする旨を定めており、本 QA では、この条項を「特許ライセンス義務」と記載します。
334 OSS を受領した下流者からみて、OSS の配布者である上流者以降に OSS の受領を受けた上で、更に当該 OSS を配布した者をいうものとする。

186

ライセンスが及ばなくなる場合も考えられ、この場合には、OSS を受領した下流の利用者
は、自己が OSS ライセンスに従って OSS を利用していたとしても特許権侵害の責任を負う可能性があり得ます。

Ａ

Ｂ

Ｃ

上流者

中流者

下流者

特許権保有

OSS を改変

OSS ライセンスに従って利用

以下においては、上記に関係する範囲で OSS ライセンスを分類したうえで、さらに詳細を検討していきます。
まず、特許ライセンス義務の条項を有する OSS ライセンスには、上流者の特許ライセンスに関する規定を有しているのが一般的ですが、その規定内容は様々なものがあります335。

OSS ライセンス中の上流者の特許ライセンスに関する規定については、中流者の改変行為の観点からみますと、以下の二つが特に問題となります。
ａ 権利ライセンスの対象とする特許権に関する規定
ｂ 権利ライセンスの対象とする受領者の利用行為に関する規定
上記ａの規定としましては、規定方法に違いはあるものの、配布される OSS を権利範囲に含む特許権などのように、配布される OSS と一定の関係にある特許権に限定していることが通常です336,337。
これに対して、上記ｂの規定には様々なものがありますが338、改変行為の観点からみま
すと、以下の二つに大きく分けられます。

「オープンソースソフトウェアのライセンスと特許権」パテント Vol.59 No.6（2006 年）64 頁以降の
表 2 に、多数の OSS ライセンスについて、どのような規定が含まれているかが詳細に分類されている。
336 「オープンソースソフトウェアの特許に関する諸問題」知財管理 Vol.55 No.12（2005 年）の 1759 頁
では、対象となる特許についての規定は５つに集約されるとし、更にこれらは、対象プログラムを利用す
ると侵害することになる特許（Apache Software License、CPL、MPL 等）と、対象プログラムで実施されている特許（Apple Public Source License、Open Software License 等）の２つに分類されると整理されている。
337 特許ライセンスを規定しつつ、配布時の OSS そのものと一定の関係にある特許権にライセンス対象となる特許を限定していないものは Jabber Open Source License Ver1.0 等ごく一部に限られる。
338 この規定としては、配布ソースに対する改変、削除等による利用行為を制限するもの、他のソフトウェアとの組み合わせによる利用行為を制限するものなど、様々な規定が存在している。
335

187

ア

OSS の改変行為をライセンスの対象として明示していない規定

イ

OSS の改変行為についてもライセンスの対象として明示する規定

そこで、特許ライセンスの規定を有している OSS ライセンスのうち、よくみられるものについて、上記ａの内容も加えたうえで、大別しますと、以下の二つに分類されます。
① 特許ライセンスの対象とする特許権については、配布される OSS と一定の関係にある特許権に限定するとともに、特許ライセンスの対象とする利用行為に改変行為を明示していないライセンス339② 特許ライセンスの対象とする特許権については、配布される OSS と一定の関係にある特許権に限定するとともに、特許ライセンスの対象とする利用行為に改変行為も含
むことを明示しているライセンス340
上記のいずれの場合においても、中流および下流の利用者が、上流の配布者かつ特許権者が配布した OSS を改変せずにそのまま利用している限り、当該利用方法は、上記特許ライセンス義務の条項に従ったものといえますので、OSS 利用者が当該上流の配布者に対して特許権侵害の責任を負うことはないと考えられます。
これに対して、上記①のライセンスの場合においては、特許権者である上流の配布者が配布した OSS を、下流の受領者が自ら改変したうえで利用した場合に特許権侵害の責任を負うおそれがあります。さらに、下流の受領者が受領した OSS を何ら改変せずに利用していたとしても、特許権者である上流の配布者が配布した OSS をその後の中流者が改変して

Ａ

Ｂ

Ｃ

上流者

中流者

下流者

OSS

改変 OSS

改変 OSSαの権利範囲αの権利範囲αの権利範囲

特許権α保有OSS を改変

受領した改変 OSS を
そのまま利用図１

いた場合には、原則として、そこから先は特許ライセンスが及ばないことになりかねず、
特許権侵害の責任を負う可能性があると考えられますので、この点について注意が必要で

339

340

Apache Software License v2.0、CPLv1.0 等がある。
GPLv3 等がある。

188

す。
具体例として、図１を前提に検討します。
図１では、Ａが、OSS を配布した上流者であるとともに、当該 OSS を権利範囲に含む特許権αの特許権者であるところ、Ａから当該 OSS を受領した中流者であるＢが当該 OSSを改変したうえで、改変された OSS を更に下流のＣに配布し、Ｃが受領した OSS を何ら改変することなくそのまま利用していたものとします。なお、Ｂによって改変された OSSにつきましても、特許権αの権利範囲に含まれているものとします。
上記①のライセンスで OSS が図１のように上流者Ａから中流者Ｂを経て下流者Ｃに配布されていた場合、中流者Ｂによる当該 OSS の改変行為には特許ライセンスが明示的に与えられておらず、改変された OSS には特許ライセンスが及ばない可能性がありますので、下流者Ｃが受領した改変 OSS をそれ以上改変することなくそのまま利用していたとしても、特許権αに関する権利侵害の責任を追求される危険性があります。
これに対して、上記②の場合には、改変行為につきましても特許ライセンスが明示的に付与されていますので、特許権者である上流の配布者から配布された OSS を利用している行為については、中流者が改変行為を行っていたとしても、下流者Ｃは原則として特許権侵害の責任を負わないと考えられます。
ただし、上記②の場合におきましても、上記ａにより権利ライセンスの対象となる特許権は上流者が配布した OSS と一定の関係にある特許に限定されています。その後の中流者による OSS の改変物が上流者の別の特許の権利範囲に属する場合、当該別の特許権につきましては、そもそも特許ライセンスの対象ではありません。したがって、特許ライセンス
義務の条項の効力が及ばず、当該特許権侵害の責任を負うものと考えられますので、この場合も注意が必要です341。
具体例として、図２を前提に検討します。
図２では、Ａが、OSS を配布した上流者であるとともに、当該 OSS を権利範囲に含む特許権αと、当該 OSS を権利範囲に含まない別の特許権βの特許権者であるところ、Ａから
当該 OSS を受領した中流者であるＢが当該 OSS を改変したうえで、改変された OSS を更に下流のＣに配布し、Ｃが受領した OSS を何ら改変することなくそのまま利用していたものとします。なお、改変された OSS は、Ｂの改変行為により、特許権βの権利範囲に含まれることになったものとします。

341

GPLv3 では 11-2 において、「A contributor's "essential patent claims" are all patent claims owned
or controlled by the contributor, whether already acquired or hereafter acquired, that would be
infringed by some manner, permitted by this License, of making, using, or selling its contributor
version, but do not include claims that would be infringed only as a consequence of further
modification of the contributor version.」と規定されているとおり、改変されることによって権利範囲に含まれることになる特許権は、特許ライセンスの対象とならないことが明示的に規定されている。

189

Ａ

Ｂ

Ｃ

上流者

中流者

下流者

OSS

改変 OSS

改変 OSSαの権利範囲βの権利範囲βの権利範囲

特許権α保有OSS を改変

受領した改変 OSS を
そのまま利用特許権β保有図２

上記②のライセンスで配布され、かつ OSS が図２のように上流者Ａから中流者Ｂを経て下流者Ｃに配布されていた場合、特許権βは特許ライセンスの対象外ですので、下流者Ｃが受領した改変 OSS をそれ以上改変することなくそのまま利用していたとしても、特許権βに関する権利侵害の責任を追求される危険性があります。
上記のとおり、OSS ライセンスに特許ライセンス義務の条項を有する場合であっても、当該ライセンスの範囲で特許権侵害の責任を負わないとされているに過ぎませんので、当該条項に反していないかの詳細な調査、確認が必要です。
特に、受領した OSS に何ら改変を加えることなく下流者がそのまま利用し、表面的にはOSS ライセンスに従って下流者が利用していた場合であっても、中流者によってなされた
改変行為の内容と OSS ライセンスの特許ライセンス義務の条項の内容次第では、上流者から特許権侵害の責任を追求される可能性があります。
したがいまして、特許権侵害のリスクを低減するためには、上流の特許権者が配布した
OSS と、自らが受領した OSS の間に改変行為がないかを調査、確認するとともに、仮に改変行為が合った場合には、具体的な改変部分の特定と上流の特許権者が有している特許権との対比、OSS ライセンスにおける特許ライセンス義務の条項の内容等を詳細に検討することが必要になると考えられます。
（作成日：2018 年 2 月 6 日）

190

Question F-1-2

GPLv3, Apache2.0 などの特許条項を有するライセンスの概観と留意事項（２）OSS を自ら提供する場合、自社特許について無償ライセンスが付与されたものとみなされると言われますが、それはどのような提供をした場合でしょうか？ またその場合、どの範囲の特許権まで、無償ライセンス義務が生じるのでしょうか？

Answer
１．はじめにOSS ライセンスには、配布される OSS に関連する特許について、以下の２種類が存在します。
ア 特許ライセンスの規定（特許権の行使が OSS ライセンスの終了条件となっている場合を含む、以下同じ）を有している OSS ライセンス
イ 特許ライセンスの規定を有しない OSS ライセンス
そこで、上記について分けて検討します。
２．上記ア（受領者に対する特許ライセンスの規定を有している OSS ライセンス）の場合
OSS ライセンスにおける特許ライセンスが規定されている場合、規定されるライセンス
条件としては、本書「F-1-1」で説明されているとおり、大別すると、以下の二つに分類されます。
① 特許ライセンスの対象とする特許権を、配布される OSS と一定の関係にある特許権に限定するとともに、特許ライセンスの対象とする利用行為に改変行為を明示していないライセンス② 特許ライセンスの対象とする特許権を、配布される OSS と一定の関係にある特許権に限定するとともに、特許ライセンスの対象とする利用行為に改変行為も含むことを明示しているライセンス
そこで、更に、上記に分けて検討します。
（１）上記①の場合
上記①の OSS ライセンスに従って、OSS を権利範囲に含む特許権を有する特許権者がOSS を自ら提供した場合には、当該 OSS を改変せずにそのまま利用している下流の受領者に対しては、当該特許に関する無償ライセンス義務が生じるものと考えられます。
ただし、あくまで無償ライセンス義務が生じる特許権は、配布される OSS と一定の関係にある特許に限定されるものであり、これと無関係な特許のライセンス義務が生じるもの

191

ではないと考えられます。
なお、無償ライセンス義務が生じる特許を限定する規定内容は各 OSS ライセンスによって微妙に異なりますので、厳密には、提供時の OSS ライセンスの規定を確認することが必要となります。
更に、下流の受領者が OSS を改変して利用している場合であっても、バグの修正等当該
OSS を利用するうえでやむを得ない合理的な範囲の修正や、軽微な修正にとどまり実質的に同一であるとみなせる場合には、無償ライセンス義務が失われないこともあると考えられますので、この点でも注意が必要です。
（２）上記②の場合
次に、上記②の OSS ライセンスに従って、OSS を権利範囲に含む特許権を有する特許権者が OSS を自ら提供した場合には、原則として、下流の受領者による当該 OSS の改変行
為を含むほぼ全ての利用行為に対する無償のライセンス義務が生じると考えられます。
ただし、この場合であっても、無償ライセンスの対象となる利用行為は、提供される OSSの利用行為に対してであり、提供された OSS と無関係なソフトウェアの利用行為にまで無償のライセンス義務は及ばないと考えられます。したがいまして、特許権者が、自らが有する特許と一定の関係にある OSS を上記②の条件で提供したとしても、下流の受領者が当該 OSS とは別個独立のソフトウェアを利用する行為については、当該ソフトウェアが当該特許の技術的範囲に含まれている限り、当該特許権に基づく権利行使は可能と考えられます。更に、OSS の受領者が、受領した OSS とは全く別個のものでありながら、専ら当該特許の技術的範囲に含まれるソフトウェアの利用のみを意図して、当該 OSS と形式的に合体させているにすぎない場合においても、当該利用行為はもはや当該 OSS の改変行為とは評価できないとして、無償の特許ライセンス義務が及ばないとされる場合もありうると考えられます。
３．上記イ（受領者に対してライセンスする規定を有しない OSS ライセンス）の場合342
この場合は、特許に関する無償のライセンス規定を有していないことから、特許に関して何らのライセンス義務も生じていないようにも考えられます。
しかし、OSS ライセンスは OSS の利用行為を自由に認めることに本質がありますから、
OSS ライセンスで認められた範囲内での OSS の利用行為が OSS 提供者の有する特許を不可避的に実施してしまう場合には、当該 OSS 提供者は、当該利用行為に対する無償のライセンス義務（少なくとも黙示の許諾343）が生じていると考えられます。
そして、認められた範囲での利用行為とは、いうまでもなく、提供された OSS の利用行為を意味しますから、無償のライセンス義務（少なくとも黙示の許諾）の対象となる特許
BSD、MIT License、X11 License、GPLv2、LGPLv2 等がある。
特許権の実施許諾が明示的になされていなくても、当然実施権が許諾されていると解される場合、黙示の許諾があるとされる。
342

343

192

は、提供された OSS を利用することにより不可避的に実施してしまうものに限定されると考えられます。
また、OSS ライセンスは OSS の改変行為を許容していることが通常ですから、無償のラ
イセンス義務（少なくとも黙示の許諾）の対象となる受領者の利用行為についても、基本
的にあらゆる改変行為に及ぶと考えられます。
上記のことから、この場合については、上記２（２）とほぼ同様になると考えられます。
（作成日：2018 年 2 月 6 日）

193

Question F-2

特許調査

OSS を組み込んだ新たな製品、それを利用したサービスを立ち上げる予定です。製品、サービスの開始前に、関連する他社特許が存在しないか調査を行いたいと思いますが、どのような点に注意すべきでしょうか？

Answer１． 特許調査一般（１）特許調査とは一般に新たな製品、サービスを立ち上げるに当たっては、当該製品、サービスが他社の特許権を侵害していないか調査を行います（以下、「特許調査」と呼びます。
）。
万が一、製品出荷後、又はサービス開始後に侵害が発見されれば、特許権者より、実施
料支払いや設計変更の要求を受けるおそれがあります。最悪の場合、製品回収や損害賠償金を支払った上で、当該ビジネスから撤退せざるを得ない状況に至るおそれもあるため、特許調査は非常に重要なビジネス開始前の手続きとなります。以下に一般的な特許調査の流れを示します。
■ 機会①：事業の流れの中


受注・見積もりの前

新製品設計、製品改良の時



新製品の出荷、販売、輸出の前

技術提携、技術輸出の時関連しそうな特許を検索で抽出

自社製品・サービスとの関連性を判断

NO
問題

完了

YES
■ 機会②：他社（顧客、コンペティタ、
特許権者等）からの指摘

知財・法務等の専門部署を交え、精査、対策検討

194

無事

（２）特許調査の計画策定①タイミングを決める
１．
（１）に示した機会①の時期に特許調査を行います。重要な他社特許が発見された
場合に備えて、対策が可能なタイミングで行うことが望ましいです。仮に、特許権利化段階で調査が完了した場合、重要性が高い特許出願についてはそのステイタスを経過観察し、特許登録後、適時のタイミングで再度調査を行うことが必要です。
②対象製品・サービスを決める
リリースする予定の製品・サービスのうち、どの機能に対して調査を行うかを決定します。
③程度、予算を決める
製品規模、リリース国、顕現性の有無等により、特許調査の要否や程度を決定します。
重要な案件の場合、外部の調査会社、弁護士・弁理士事務所に発注するか否かの判断も必要となります。
（３）関連しそうな特許の抽出
各種特許検索システムを用いて、発明の技術的特徴による分類体系（国際特許分類 IPC
や日本特許庁が編纂する FI/F ターム等344）による検索、及びキーワード検索を並行して行
い、関連しそうな特許の抽出を行います。最も簡易かつ無料の検索システムとして、独立行政法人工業所有権情報・研修館（INPIT）の検索システム（J-PlatPat345）があります。
また、各企業が運営する有料の特許検索サービスもありますので、必要に応じ並用することも検討します。
（４）自社製品・サービスとの関連性を判断
関連しそうな特許の抽出が完了した段階で、当該特許と自社製品・サービスとの関連性を検討します。日本特許法において、「特許権者は、業として特許発明の実施をする権利を占有する。
」（特許法第 68 条本文）とされています（ただし、試験又は研究のための実施等は除外されています（特許法第 69 条））346。
特許発明には、①権利化段階（将来、登録される可能性あり）のものと、②登録段階（現在、登録になっている）のもの、更に③権利消滅段階のものがあり、関連性の判断もこの 3
種類の段階のものを対象とします。②に関しては、特許回避検討の対象となります。①の権利化段階のものに関しては、将来、特許権が与えられないことが確定する場合もありますし、仮に特許権が与えられたとしても、現時点のものと内容が変わることもありえます
ので、経過観察の対象とするか、特許回避検討の対象とするか、検討することとなります。
なお、自社製品・サービスが対象とする特許発明の特許請求の範囲に入るか否かは専門
http://www.inpit.go.jp/content/100789231.pdf
https://www.j-platpat.inpit.go.jp/web/all/top/BTmTopPage
346 各国毎により法制度や権利範囲に違いがあるため、実際の侵害非侵害判定は各国毎に行う。
344
345

195

的な判断が必要となります。まずは自社内の専門部署（知財部、法務部等）に相談の上、場合によっては、（複数の）外部の調査会社、弁護士・弁理士事務所の意見を照会し、鑑定書を取得することも必要です。
（裁判となった場合に、故意に侵害行為を継続していたわけではないとの抗弁の有力な証拠となります。特に米国では、故意に侵害行為を継続していたと裁判で判断された場合、通常の賠償金額の三倍額を支払う旨の評決が出される場合があり、注意が必要です。
）（５）関連特許が発見された場合の対応策
自社製品・サービスと関連性の高い他社特許が発見された場合、又は他社から特許権侵害の警告を受領した場合、以下のいずれかの対応をとることになります。いずれの策も取れない場合、当該製品・サービス事業開始（又は継続）を断念することになります。
①特許有効性判断
当該特許権が有効か否かを検討します。無効理由があると判断した場合は、無効審判を提起する等の対抗策検討を行います。
②先使用権有無判断
当該特許権の出願より以前から当該特許発明に関し、自社での実施（又は実施の準備）があった場合、その証拠を収集し、侵害主張への対抗を準備します。
③設計回避可否判断
当該特許権の請求項のうち、いずれかの要素が回避可能な製品・サービス設計とできないかを検討します。
④実施権取得
当該特許の保有者が、一定の対価を支払うことを条件に実施権の許諾を与えていることが判明している場合は、実施権を取得した上でサービスインすることも選択肢として検討します。
⑤対抗可能な特許の確認、取得
当該特許権を有する者による生産物を権利範囲とする特許権を自社が保有しているかの確認や、そのような特許権を取得することが可能かを検討します。
この方法は、相手方からの権利行使を直接封じることはできませんが、相手方に相応のダメージを与えられる場合には、相手方に権利行使を躊躇させることができると考えられますし、クロスライセンスの可能性も出てきます。
２．OSS 関連特許に関する特許調査の特徴（１）顕現性の高さ
OSS はソースコードが公開されているため、ソースコードが公開されない自社開発プロ
グラムやフリーウェアに比べ、関連する特許権を保有する権利者にとって、当該 OSS が特定の特許を侵害するか否かの立証が容易という特徴があります（顕現性が高い）
。このこと

196

は、特許訴訟を考えている原告にとって、OSS の特許侵害訴訟前アセスメントにおいて証拠上優位に立っていることを意味します。このため、特許調査の計画策定に際しては、プ
ロプラエタリソフトに比べ、より保守的な計画（より広範に、より深く）を策定する必要があります。
（２）情報取得方法の多様性
Linux や Andriod 等の著名 OSS は既に多数の特許訴訟が存在しており、それらのウォッチを行うことにより、多くの情報を得ることが可能です。また、自社単独で特許調査を行うのではなく、対象となっている OSS のコミュニティや Open Invention Network(“OIN”)347のような団体からの情報提供も合わせて利用することにより、複合的、効率的な特許調査を行うことが可能です。
（３）各種ライセンスプログラムとの関係①OSS ライセンス
特許調査の結果、関連する可能性があるものとして抽出された特許（”対象特許”）の保有者が、自社 OSS を Apache v2.0 等の特許ライセンス義務を有するライセンスに基づき配布している場合は、当該特許保有者が配布する OSS を利用することにより、当該特許の権利行使を気にする必要がなくなります。
②特許プール自身が OIN 等の特許プール団体に加盟している場合、当該団体に加盟する他の会員が対象特許を保有していたとしても、特定の条件348を満たす場合には、当該他の会員からの特許権の権利行使を気にする必要がなくなります。
③Non-assertion Pledge
Google 349 等 が 特 定の 技術分 野 ・ 特許 に対 し て提供 し て いる 特許 権 不行使 特 約（”Non-assertion Pledge: “NAP”）により、自社製品・サービスと当該 NAP 対象特許との関連性を判断（1.(4)参照）した後は、その後の特許調査の対象より当該 NAP 対象
特許を除外できる場合があります。
（作成日：2018 年 3 月 8 日）

https://www.openinventionnetwork.com/
特許プールが対象としている特許の他会員への実施許諾、又は権利不行使等。
349 https://www.google.com/patents/opnpledge/pledge/
347
348

197

Question F-3

OSS の混入発見と守秘義務について

１．自社の開発するソフトウェアに組み込むために、A 社が開発したソフトウェアについてライセンスを受け、ソースコードの提供を受けました。ライセンス契約には秘密保持条項が含まれており、ソースコードは秘密保持の対象となっていますが、提供された
ソースコードを見たところ、その中に GPL の及ぶコードが含まれていることが分かりました。この場合、どのように対応すれば良いでしょうか？
２．従業員が、自社の proprietary なソフトウェアにソースコード公開義務がある GPL の及ぶコードが混入していることに気付いた場合、どのように対応をすればよいでしょうか？

Answer
１．設問１について（１）GPL は、GPL の及ぶソフトウェアを入手した者は、その複製物を、改変の有無にかかわらず再配布する権利を有するとしており、また、GPL の下でのソフトウェアの配布につき、GPL よりも厳しい制限をかけることを認めていません。
本件では、A 社が開発したソフトウェア（以下「A 社ソフトウェア」といいます。）に G
PL の及ぶコード（以下「本件コード」といいます。
）が含まれているため、GPL の適用があります。A 社が貴社に秘密保持義務を課して本件ソフトウェアをライセンスし、ソースコードを提供する行為は GPL に違反していることになり350、結果として、貴社が A 社ソフト
ウェアを組み込んでソフトウェアを作成する行為や（以下、貴社が作成するソフトウェア
を「貴社ソフトウェア」といいます。）、貴社ソフトウェアを複製し、第三者に提供する行
為等は、本件コードの著作権を侵害する行為となります。
（２）したがって、貴社が、貴社ソフトウェアを開発している段階で、A 社ソフトウェアにGPL の及ぶコードが含まれていることに気がついたのであれば、直ちに本件ソフトウェアの使用を中止するか、A 社に A 社ソフトウェアのライセンス内容が GPL に違反している旨の通知を行い、ソースコードを秘密保持義務の対象から外す等、GPL に適合するようライ
センス内容の変更を求め、A 社がこれに応じない場合には、A 社ソフトウェアの使用の中止を検討するといった対応をとる必要があります。
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#DoesTheGPLAllowNDA, https://www.gnu.org/licenses/gpl-faq.ja.html#DoesTheGPLAllowModNDA, https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#TradeSecretRelease, https://www.gnu.org/licenses/gpl-faq.ja.html#TradeSecretRelea
se
350

198

また、貴社が貴社ソフトウェアの開発を終え、第三者への提供を開始した後に、A 社ソフ
トウェアに GPL が及ぶコードが含まれていることが判明した場合、貴社ソフトウェアにつき GPL が適用され、貴社は、貴社ソフトウェアを配布（distribute（GPLv2）、又は conve
ying（GPLv3））しており、貴社は、A 社ソフトウェアを含む貴社ソフトウェアのソースコードを提供する義務を負うことになるため、A 社に問題を指摘し、貴社ソフトウェアのソー
スコードを提供することが、A 社とのライセンス契約上の秘密保持義務の対象から除外されるよう契約の変更を求める必要があります。
A 社がどうしても変更に応じない場合にどのように対応するかは、難しい問題となります。
貴社ソフトウェアのソースコードを提供できなければ GPL 違反となり、貴社が A 社の行為に起因して、本件コードの著作権を侵害することになるため、最終的には、権利濫用、信義則違反などを根拠にＡ社とのライセンス契約上の秘密保持義務の有効性を争うことを視野に入れ、貴社ソフトウェアのソースコードを提供することを検討する必要があるかもしれません。
上記のような問題を考慮すれば、A 社とライセンス契約を締結する際、提供を受けるソー
スコードについての秘密保持義務の例外として、GPL の及ぶコードが含まれていることが判明した場合を規定するといった手当をするよう努めるのが妥当といえます。
（３）なお、GPL 違反を発見した場合について、FSF（Free Software Foundation）の F
AQ では、GPL の及ぶプログラムの出版者や著作権者に事態を伝えることを勧めていますが351、貴社がこのような対応を直ちにとることは、A 社との秘密保持義務との関係で問題となるおそれがあるため注意する必要があります。
２．設問２について（１）proprietary なソフトウェアが、貴社の社内でのみ使用されており、未だ外部へ配布されたことがないのであれば、distribute（GPLv2）、又は conveying（GPLv3）に該当す
る行為がないため、ソースコードの提供義務等は発生していないことになります。今後、当該ソフトウェアを外部へ配布する可能性があり、その際、当該ソフトウェアに GPL が適用されるのを避けたいのであれば、速やかに問題となるコードを独自のコードに置き換えるといった対応をとる必要があると思われます。
（２）当該ソフトウェアが既に外部へ配布されている場合には、GPL 違反の状態で配布されていることになります。このことが発覚した場合、OSS コミュニティにおいて問題視され、貴社の信用・評判に傷がつく可能性があるため、社内の法務・知財その他の関連部門と連携をとりながらソフトウェアの用途・配布状況等の諸事情を勘案して、違反行為の中

https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#ReportingViolation, https://www.gnu.or
g/licenses/gpl-faq.ja.html#ReportingViolation
351

199

止と是正（配布の停止、ソフトウェアの修正、既にソフトウェアを配布した配布先への通知、GPL に正しく準拠した形態でのソフトウェアの提供等）のための対応策を検討する必要があります。
（原稿作成日：2018 年 3 月 15 日）

200

Question F-4-1

OSS と越境問題－国際裁判管轄

GPL には、裁判管轄を定めた規定がありませんが、OSS 利用者がライセンス条項を遵守しない場合、OSS 開発者は、どこの国の裁判所において、権利行使のための訴訟を提起できるのでしょうか？

Answer
国際裁判管轄352は、裁判が提起された国における民事訴訟のルールに従って決定されます。
原則として、被告の所在地のある国の裁判所に国際裁判管轄が認められますが、それ以外の国にも認められる場合があり、それは請求の内容等によって異なってきます。
本件のような場合、紛争の具体的内容としては、著作権者（OSS 開発者）からの著作権侵害に基づく訴えとなることが予想されるため、OSS 利用者の所在地や、OSS が使われた場所などに国際裁判管轄が認められると考えられます。
１．国際裁判管轄について
GPL には、裁判管轄を定めた規定が存在していません。特に、GPLv3 については、裁判管轄の条項を設けることは、additional restrictions として禁止されています。
いずれの国においても、事業者と消費者との間の契約は別として、裁判管轄に関する合意がある場合には、かかる合意が尊重されるのが一般的です。しかし、このような裁判管轄に関する条項のないライセンスに基づく紛争については、国際裁判管轄がどのように判断されるのかが問題となります。
２．具体例の検討（１）原則的な考え方
国際裁判管轄については汎用的に適用されるような条約等があるわけではありませんので、このような国際裁判管轄についてのルールは、各国で異なる場合があります。したがって、国際裁判管轄は、訴訟が提起された裁判所における民事訴訟のルールに従って、管轄権の有無が決定されることになります。
ただし、いずれの国においても、事業者と消費者との契約等の例外的な場合を除き、裁判管轄を有する裁判所が合意によって指定されている場合には、かかる合意が尊重されま
すし353、また、このような合意がない場合は、被告の所在地の裁判所に管轄が認められる354

352
353

複数の国に関連する民事事件において、どこの国の裁判所が管轄権を有するかを意味します。
例えば、民事訴訟法 3 条の 7。

201

のが原則的な考え方となっています355。
したがって、OSS 開発者が、OSS 利用者に対し、OSS 利用者が所在する国の裁判所で裁判を提起する場合には、国際裁判管轄が認められることになります。
では、日本で開発された OSS について、外国の OSS 利用者がライセンス違反していた
場合、日本で裁判することができるのでしょうか。
以下では、日本に所在する OSS 開発者が、外国（A 国）に所在する OSS 利用者に対し、日本で権利行使をする場合を検討します。

対象ソフ
トウェア
の著作者

日本

A国
利用行為
者

（２）日本で裁判を提起した場合
まず、日本所在の OSS 開発者が、外国（A 国）に所在する OSS 利用者に対し、日本で裁判を提起する場合、日本の裁判所に国際裁判管轄が認められるかを考えてみます356。
① 日本の民事訴訟法の規定
平成 24 年 4 月 1 日施行の民事訴訟法の改正で、国際裁判管轄に関する定めが追加されました。日本の民事訴訟法では、日本の裁判所に国際裁判管轄が認められる場合が列挙されています。
原則は、国内の普通裁判籍を定める第 4 条に相当する同法 3 条の 2 が、被告の住所等が日本国内に存在する場合に日本の裁判所に国際裁判管轄が認められることを規定しているというのは前述のとおりです。
3 条の 3 は、契約上の債務に関する訴え等について規定しています。具体的には、契約上の債務の履行請求や債務不履行による損害賠償請求等において、契約において定められた
例えば、民事訴訟法 3 条の 2。
米国の場合、連邦裁判所と各州の裁判所とがあり、州裁判所は、原則として全ての事件を扱う一方、連邦裁判所は特定の種類の事件のみを扱うこととなっています。
なお、各国の国際裁判管轄に関する考え方につき、平成 22 年 9 月 16 日付「経済産業省「国境を越える
電子商取引の法的問題に関する検討会報告書」が参考になります（ただし、同報告書作成後の法改正等は含まれていない点には注意が必要です）。
356 判決の執行を考えると、外国所在の OSS 利用者に対し、日本の裁判所で判決を取得することは効率的ではない可能性はあります。
354
355

202

債務の履行地、又は契約において選択された地の法によれば当該債務の履行地が日本国内にあるときは、日本の裁判所に国際裁判管轄が認められます（1 号）。
また、不法行為に関する訴えについては、不法行為があった地が日本国内にあるとき（外国で行われた加害行為の結果が日本国内で発生した場合において、日本国内におけるその結果の発生が通常予見することのできないものであったときを除く。
）は日本の裁判所に管轄が認められます（8 号）。民事訴訟法でいう不法行為のあった地（以下、「不法行為地」といいます）とは、一般に、原因行為地のみならず、結果発生地をも含むとされており、同条文中に「外国で行われた加害行為の結果が日本国内で発生した場合において、日本国内
におけるその結果の発生が通常予見することができないものであったときを除く」との例
外が定められていることからも、結果発生地を含むことが前提とされているといえます。
ただし、日本の裁判所に国際裁判管轄を認めるのが被告の利益等に鑑み、不適切な場合もありますので、民事訴訟法は「事案の性質、応訴による被告の負担の程度、証拠の所在
地その他の事情を考慮して、日本の裁判所が審理及び裁判をすることが当事者間の衡平を害し、又は適切かつ迅速な審理の実現を妨げることとなる特別の事情がある」場合には、日本の裁判所は、訴えの全部又は一部を却下することができると定めています（民訴法 3条の 9）。
② 著作権の行使
GPL が OSS 開発者による宣言か、あるいは OSS 開発者と OSS 利用者の合意に基づく契約かという法的性質に関する争いがあります。いずれの場合であっても、OSS 利用者が GPLのライセンス条項に違反し、ライセンスが自動終了したのであれば、OSS 開発者は、著作権に基づき、差止及び損害賠償を提起することが可能です。GPL を宣言と見る立場では、
OSS 開発者は、この形の請求しかできないものと考えられます（契約と見る場合は次項に記載します）。
著作権侵害についての救済には、主に、差止請求と損害賠償請求があります。損害賠償
請求は、不法行為に基づくものとされているため、前記民事訴訟法の不法行為に関する規定が適用されます。
したがって、もし、問題のソフトウェアが日本で使われていた場合には、著作権侵害の結果が日本で生じていると言えるため、それが通常予見できなかった場合、又は、日本の裁判所で審理を行うことが不適切な特別な場合を除き、日本の裁判所に国際裁判管轄が認められることになります。
なお、損害賠償に関して、日本の裁判所に不法行為としての国際裁判管轄が認められるとしても、それが差止にも及ぶかどうかは別途問題となります。差止請求は、不法行為の救済手段として直ちに認められるものではないからです。
この点、日本国内の裁判管轄に関し、民事訴訟法 5 条 9 号の「不法行為に関する訴え」
は、違法行為により権利を侵害され、又は侵害されるおそれがある者が提起する差止請求203

に関する訴えも含むとされていました（最決平 16･4･8 民集 58 巻 4 号 825 頁）。また、国際裁判管轄に関しては、米国判決の日本での執行を求めた事案に関する間接管轄357に関してではありますが、同管轄については、日本の民事訴訟法の定める国際裁判管轄に関する規定に準拠して決定すると判示した上で、前記最高裁決定を引用して、不法行為に関する訴えに、違法行為により権利利益を侵害され、又は侵害されるおそれがある者が提起する差止請求に関する訴えをも含む」とした事案があります（最判平 26･4･24 民集 68 巻４号
329 頁）。この内容は、原告が日本で訴えを提起する場合の管轄の有無を決定する直接管轄の考え方にも及ぶと解されていますので358、この考え方に従えば、差止請求についても、日本で著作権侵害の結果が生じていた場合には、日本の裁判所に国際裁判管轄が認められることになります。
本件では、利用者が外国に所在していますので、著作権侵害の行為及び結果は、当該外国（A 国）で発生していると考えられます。したがって、不法行為地としては、日本の裁判
所に国際裁判管轄を認めることはできません。
逆に、A 国で裁判を起こす場合、A 国の民事訴訟に関する法律にしたがって国際裁判管轄の有無が判断されるとはいえ、被告所在地ですので、問題なく国際裁判管轄が認められるといえます。
③ GPL 条項違反による請求
GPL の条項について、国際裁判管轄に関する考え方を検討します。
民事訴訟法は、契約上の債務の履行の請求を目的とする訴え等は、契約において定められた当該債務の履行地が日本国内にあるときは、日本の裁判所に国際裁判管轄がある旨を定めています（民訴法 3 条の 3 第 1 号）。
GPL を契約と解する場合、同ソフトウェアを利用するための条件が、契約上の債務と考えられます。GPL には、特段、ソースコードの提供等についての履行地を定めていないた
め、そもそも、債務履行地がどこか自体が問題となります。対象ソフトウェアが自由に使われることやソースコード等の提供を行うべき相手方は、OSS 開発者でないことに鑑みれば、世界のどこで求められるか分からない場所において、債務の履行を求めることは適切ではないようにも考えられます。
ただ、日本で開発された GPL プログラムについて、外国で GPL 違反した OSS 利用者に対して債務不履行に伴う損害賠償を請求する場合、日本の法律によれば、原則として債務
は持参債務とされていることから、日本所在の GPL プログラム開発者に対し日本で支払をしなければならないこととなるため359、その債務履行地として日本に国際裁判管轄を有す

民事訴訟法 118 条は、外国判決を日本で執行するため、同判決を承認するための要件を置いており、その要件の一つに、「法令又は条約により外国裁判所の裁判権が認められること」（つまり、同裁判所に適切な管轄が認められること）をあげています（民訴法 118 条１号）。
358 高部眞規子「民訴法 118 条１号のいわゆる間接管轄と不法行為地の証明」（金商 1458 号 8 頁など参照。
359 民法 484 条参照。
357

204

るとすることができるかもしれません。
④ 消費者契約の特例
民事訴訟法は、契約が消費者と事業者との間で締結された場合については、基本的には、消費者の常居所地法を提供する旨の特例規定を置いており、消費者から事業者に対する訴
えは、消費者の住所が日本国内にあるときは日本の裁判所に提起することができる旨が定められています（民訴法 3 条の 4 第 1 項）。また、事業者から消費者に対する訴えについて
は、結論として消費者の住所地の裁判所に国際裁判管轄が認められること（民訴法 3 条の 5
第 3 項）、及び国際裁判管轄に関する合意は、消費者が住所を有していた国の裁判所に国際裁判管轄を認めるか、実際の裁判において消費者が当該合意を援用した場合にのみ有効であること（民訴法 3 条の 7 第 5 項）が定められています。
したがって、日本所在の OSS 開発者が消費者であり、外国所在の OSS 利用者が事業者の場合は、GPL を契約と考えれば、日本の裁判所に国際裁判管轄が認められることになります。一方、外国所在の OSS 利用者が消費者であり、日本所在の OSS 開発者が事業者の場合、上記のような消費者に対する配慮を考えれば、日本の裁判所で審理を行うことが当事者間の衡平を害することとなる特別の事情があるとして、却下される可能性が高いと言えるでしょう（民訴法 3 条の 9）。
（３）EU における考え方
EU の場合、ブリュッセル Ia 規則360が、EU 域内での民商事紛争に関する国際裁判管轄を定めています361。
同規則の下でも、被告所在地の裁判所362、契約の履行地363、合意の場合には、合意が尊重されること364、不法行為の場合には損害発生地365が裁判管轄を有すること、及び、消費者契約においては特別な配慮がされること366は、日本の民事訴訟法と変わりませんので、ほぼ同じ考え方が適用されることになります。
上記は、EU 域内における国際紛争に関して適用されるため、本件のように、EU 域外の国との間での国際紛争については適用されませんが、原則的な考え方を示すものとして参考になるといえます。

Regulation (EU) No. 1215/2012 of the European Parliament and of the Council of 12 December
2012 on jurisdiction and recognition and enforcement of judgement in civil and commercial matters.
361 ここで記載されている規則については EU 域内で適用される規則であり、EU 域外との紛争に関してそのまま適用されるわけではありませんが（同規則 Article 6 参照）、考え方として参考となるので記載します。
362 Article 4 参照。
363 Article7(1)参照。
364 Article 25 参照
365 Article7(2)参照。
366 Article 17 参照。
360

205

（４）米国における考え方
米国の場合は、そもそも、扱う法律問題の性質（subject matter）によって、州の裁判所
か連邦裁判所かが異なります。契約違反の場合は、原則として各州の裁判所に、著作権侵害の場合は、連邦法に関する問題として367、連邦裁判所が管轄を有することになります。
上記のとおり事物管轄権（subject matter jurisdiction）があることを前提として、さらに、訴え提起がされた裁判所に人的管轄権（personal jurisdiction）が認められれば、同裁判所に管轄権が認められることになります。
人的管轄は、general jurisdiction（一般的管轄権）と特別管轄権（specific jurisdiction）の２種類に分けて考えられており、一般的管轄権については、被告が法廷地との間で継続的かつ体系的な接触がある場合に認められます。また、特別管轄権は、当該紛争が法廷地の接触から生じ又は関係する場合に認められます368。
３．クラウド上での利用
クラウド上で GPL 適用対象のプログラムを利用する場合でも、直ちに、GPL が適用になるわけではありません（詳細については、「A-4」をご覧ください）。とはいえ、インターネ
ットを介した利用の場合には、世界各地から接触が可能となることから、国際裁判管轄の考え方は複雑になるため、日本法を前提として、若干の検討を加えておきます。
インターネットによる配信行為の場合、どこで配信行為がされていても、日本から閲覧可
能ですが、閲覧可能であることの一事を持って、日本で侵害行為が生じているとは考えられていません。例えば、国際的なインターネットサービスにおいて、日本の裁判所に国際裁判管轄が認められた事例は、基本的にサービスが日本語で提供されているなど、日本国内での受信を想定していたものとなっています369。
なお、国際裁判管轄権の有無の判断において、サーバの所在地は直接影響せず 370、実際のサービスの全体から判断されています。
（作成日：2018 年 3 月 15 日）

367

著作権については、州の法律ではなく、連邦著作権法が適用されるためです。
特別管轄権については、一般にフェアプレイと実質的正義の伝統概念に反しない程度の最小限度の接触（minimum contacts）がある場合に認められると考えられています。
369 例えば,テレビ放送を国外の事業者が日本向けにインターネット配信していた事案では、裁判所は、当該サービスが日本在住者に向けられたサービスであり、被告による「不法行為があった地」の少なくとも一部は日本国内にあるとして日本の裁判所の国際裁判管轄を認めています（東京地判平 26・7・16 裁判所
HP）。（ただし、この事案では、同事業者は、日本における事業所を日本国内で登記していました。また、同じ事業者に対する別の裁判では、「被告は受信した本件番組の・・・データファイルを日本国内における被告サーバに保存しており、被告がした不法行為の少なくとも一部が日本国内にあると認められる」としており（東京地判 H26・9・5（裁判所 HP）、受信行為が日本で可能であったことのみで判断しているわけ
ではありません。また、合衆国ネバダ州に所在し、日本国内に事務所も営業所もないインターネットサー
ビス事業者に対する仮処分では、同サービスが日本語で提供されていることから、「日本において事業を行う者の日本における業務に関するもの」（民訴法 3 条の 3 第 5 号）として国際裁判管轄を認めた事例（東京地決平 25・2・6 判例集未登載）も存在します。
370 民事訴訟法上の国際裁判管轄に関する規定にはサーバの所在地に関する規定はありません。
368

206

Question F-4-2

OSS と越境問題―準拠法

GPL には、準拠法を定めた規定がありませんが、OSS 利用者がライセンス条項を遵守しな
い場合、OSS 開発者は、どこの国の法律に基づき、権利行使を行うことができるのでしょうか？

Answer
準拠法は、裁判が提起された国における国際私法371のルールに従って決定されるのが原則です。ただし、紛争の具体的内容としては、著作権者（OSS 開発者）からの著作権侵害に基づく訴えとなることが予想されるため、OSS が使われた場所の著作権法に基づく権利行使となることが多いでしょう。
１．準拠法について
GPL については、準拠法を定めた規定が存在していません。特に、GPLv3 については、準拠法の条項を設けることは、additional restrictions として禁止されています。
いずれの国においても、事業者と消費者との間の契約は別として、準拠法に関する合意がある場合には、かかる合意が尊重されるのが一般的です。しかし、このような準拠法に関する条項のないライセンスに基づく紛争については、準拠法がどのように判断されるのかが問題となります372。
２．具体例の検討（１）準拠法決定のルール
準拠法についてのルールを法律等で定めている国が殆どですが、汎用的に適用されるような条約等があるわけではありませんので、このような準拠法についてのルールは、各国で異なる場合があります。したがって、準拠法は、訴訟が提起された裁判所（当該裁判所

371

複数の国に関連する私法上の法律問題について、どの国の法律を適用すべきかを指定するための法則を意味する。
372 米国の場合は、全国統一の準拠法決定に関するルールは存在せず、各州によってルールが異なる。ただし、原則としては、準拠法に関する当事者の合意があれば、合意が尊重され、合意がない場合には、契約締結地、契約交渉地、義務履行地、契約目的物の所在地、法人の設立地、事業所所在地などを総合的に考慮した上で「最も重要な関係（most significant relationship）を有する州又は国の法律が適用されることになる。
なお、各国の準拠法の考え方につき、平成 22 年 9 月 16 日付「経済産業省「国境を越える電子商取引の法的問題に関する検討会報告書」が参考になる（ただし、同報告書作成後の法改正等は含まれていない点には注意が必要。

207

に国際裁判管轄373があることが前提ですが）における国際私法のルールに従って決定されることになります。
（２）日本で裁判を提起した場合
考えを整理するために、まずは、A 国に所在する OSS 開発者が、日本で問題の OSS が利用されているとして、日本において GPL に関する訴訟を提起する場合（F-4-1 とは事例が異なります）を考えてみます（日本の裁判所に国際裁判管轄が認められることが前提で
す）
。

対象ソフ
トウェア
の著作者

A国

日本
利用行為
者

① 法の適用に関する通則法
日本では、「法の適用に関する通則法」（以下「通則法」といいます）が準拠法決定のためのルールとされています。国際私法に関するルールは、当該行為の法的性質により適用される国の法律が異なるのが普通であり、通則法でも、問題となる法律行為の内容により、適用される条文が異なっています。そこで、訴えがどのような形で提起されるかを検討することとします。
② 著作権の行使
GPL が OSS 開発者による宣言か、あるいは OSS 開発者と OSS 利用者の合意に基づく契約かという法的性質に関する争いがあります。いずれの場合であっても、OSS 利用者が GPLのライセンス条項に違反し、ライセンスが自動終了した場合374、OSS 開発者は、著作権に基づき、差止及び損害賠償を提起することが可能です。GPL を宣言と見る立場では、OSS
開発者は、この形の請求しかできないものと考えられます（契約と見る場合は次項に記載
します）。
日本においては、著作権侵害の場合、差止については、ベルヌ条約 5 条 (2) 項に基づく
373
374

複数の国に関連する民事事件において、どこの国の裁判所が管轄権を有するかを意味する。
GPL v2 の４項、GPL v3 の 8 項により、違反があった場合は、ライセンスが自動終了する。

208

保護国法が適用され、損害賠償については不法行為として、通則法第 17 条（参照条文は脚注に記載します）375が適用されると考えられており、加害行為地の結果が発生した地の法が適用されます。
したがって、GPL 違反した問題のソフトウェアが日本で使われていた場合には、差止については、保護国法として日本国法が、損害賠償については、「加害行為の結果発生地」として、やはり日本国法が適用されることになります。
③ GPL 条項違反による請求
GPL の条項について、準拠法に関する考え方を検討します。
通則法は、第 8 条376において、準拠法に関する合意がない場合の「法律行為」377に関する規定を置いています。
第 8 条は、準拠法は、対象の法律行為に最も密接な関係がある地の法が準則であること、及び、当事者の一方のみが特徴的な給付378を行う場合、当該当事者の常居所地が最も密接な関係地の法と推定することが定められています。
GPL を契約と解する場合、これは「法律行為」ですので、上記条文が適用されることになります。第 8 条でいう特徴的な給付とは、その契約を特徴づける給付（他の契約類型から区別するための特徴を示す給付）を意味します。GPL の場合は、「特徴的な給付」とは、対象ソフトウェアの利用許諾ということになると考えられますから379、準拠法は、著作権者の常居所地の法が準拠法とされることになりますので、OSS 開発者が所在する A 国法が適用されることになります。
④ 消費者契約の特例
通則法は、第 11 条380において、契約が消費者と事業者との間で締結された場合について「法の適用に関する通則法」第 17 条（不法行為）
不法行為によって生ずる債権の成立及び効力は、加害行為の結果が発生した地の法による。ただし、その地における結果の発生が通常予見することのできないものであったときは、加害行為が行われた地の法による。
376 「法の適用に関する通則法」8 条（当事者による準拠法の選択がない場合）
１ （当事者による準拠法の）選択がないときは、法律行為の成立及び効力は、当該法律行為の当時において当該法律行為に最も密接な関係がある地の法による。
２ 前項の場合において、法律行為において特徴的な給付を当事者の一方のみが行うものであるときは、その給付を行う当事者の常居所地法を当該法律行為に最も密接な関係がある地の法と推定する。
375

377

当事者がその意思に基づいて一定の効果発生を求めて行う行為で、法律がその効果発生を認める行為を「法律行為」といいます。
378 「給付」とは、債権の目的となる債務者の行うべき行為を意味します。
379

双務契約の場合、いずれの当事者も特徴的給付を行うと考えられる場合もある。GPL では、利用者も一定の事項の遵守が要求されるため、利用者の遵守が特徴的給付ではないかという疑問も生じ得る。ただ、利用者の利用条件が、例えば、ソースコードの提供については、「You may convey a covered work in theobject code form under the terms of …」というようにという形で定められているため、利用者の契約上の義務というよりは、条件付きの許諾として解するのが自然ではないかと思われる。
380 「法の適用に関する通則法」11 条（消費者契約の特例）
１ 消費者（事業として又は事業のために契約の当事者となる場合におけるものを除く。
）をいう。
）

209

は、基本的には、消費者の常居所地法を提供する旨の特例規定を置いています。
したがって、OSS 利用者が消費者であり、OSS 開発者が事業者の場合は、GPL を契約と考えれば、消費者の常居所地法である日本国法が適用されることになります。また、OSS
開発者が消費者であり（趣味で開発した場合など）、OSS 利用者が事業者の場合は、逆に、OSS 開発者の常居所地法である A 国法が適用されることになります。
⑤ まとめ
A 国に所在する OSS 開発者が、日本でライセンス違反した問題の OSS が利用されているとして、日本において GPL に関する訴訟を提起するケースにおいて、準拠法に関する分析をまとめると以下の表になります。

と事業者（法人その他の社団又は財団及び事業として又は事業のために契約の当事者となる場合における個人をいう。
）との間で締結される契約（労働契約を除く。以下「消費者契約」という。
）の成立及び効力について（当事者の合意による）選択又は変更により適用すべき法が消費者の常居所地法以外の法である場合であっても、消費者がその常居所地中の特定の強行規定を適用すべき旨の意思を事業者に対し表示したときは、当該消費者契約の成立及び効力に関しその強行規定の定める時効については、その強行規定をも適用する。
２ 消費者契約の成立及び効力について第 7 条の規定による選択がないときは、第８条の規定にかかわらず、当該消費者契約の成立及び効力は、消費者の常居所地法による。
３ 消費者契約の成立について（当事者の合意）により消費者の常居所地法以外の法が選択された場合であっても、当該消費者契約の方式について消費者がその常居所地法中の特定の強行規定を適用すべき旨の意思を事業者に対し表示したときは、（他の）規定にかかわらず、当該消費者契約の方式に関しその強行規定の定める事項については、専らその強行規定を適用する。
４
消費者契約の成立について第七条の規定により消費者の常居所地法が選択された場合において、当該消費者契約の方式について消費者が専らその常居所地法によるべき旨の意思を事業者に対し表示したときは、（他の）規定にかかわらず、当該消費者契約の方式は、専ら消費者の常居所地法による。
５
消費者契約の成立について第七条の規定による選択がないときは、（他の）規定にかかわらず、当該消費者契約の方式は、消費者の常居所地法による。
６
前各項の規定は、次のいずれかに該当する場合には、適用しない。
① 事業者の事業所で消費者契約に関係するものが消費者の常居所地と法を異にする地に所在した場合であって、消費者が当該事業所の所在地と法を同じくする地に赴いて当該消費者契約を締結したとき。
ただし、消費者が、当該事業者から、当該事業所の所在地と法を同じくする地において消費者契約を締結することについての勧誘をその常居所地において受けていたときを除く。
② 事業者の事業所で消費者契約に関係するものが消費者の常居所地と法を異にする地に所在した場合であって、消費者が当該事業所の所在地と法を同じくする地において当該消費者契約に基づく債務の全部の履行を受けたとき、又は受けることとされていたとき。ただし、消費者が、当該事業者から、当該事業所の所在地と法を同じくする地において債務の全部の履行を受けることについての勧誘をその常居所地において受けていたときを除く。
③ 消費者契約の締結の当時、事業者が、消費者の常居所を知らず、かつ、知らなかったことについて相当の理由があるとき。
④ 消費者契約の締結の当時、事業者が、その相手方が消費者でないと誤認し、かつ、誤認したことについて相当の理由があるとき。

210

請求の性質準拠法

著作権侵害による差止請求

日本法

著作権侵害による損害賠償請求

日本法

GPL 条項違反による請求

双方とも事業者又は消費者

A 国法

OSS 利用者が消費者

日本法

OSS 開発者が事業者
OSS 利用者が事業者

A 国法

OSS 開発者が消費者（３）EU 域内の紛争場合① 原則的な考え方
EU の場合、EU 域内における契約については、「ローマ I 規則」（Regulation（EC）
No.593/2008 of the European Parliament and of the Council of 17 June 2008 on the law
applicable to the contractual obligations）に基づいて準拠法が決定されます381。
当事者が準拠法を選択していない場合は、個々の契約類型毎に定めるものとされており（第 4 条）、1 項において契約類型のリストがあげられていますが、ライセンス契約はリストにありません。したがって、下記の第２項が適用となります。
2 Where the contract is not covered by paragraph 1 or where the elements of thecontract would be covered by more than one of points (a) to (h) of paragraph 1,
the contract shall be governed by the law of the country where the party
required to effect the characteristic performance of the contract has his habitualresidence.
つまり、日本の通則法と同様、「特徴的な給付を行う者の常居所地法」が準拠法となります。
一方、EU 域内の不法行為／不当利得等に関しては「ローマ II 規則」（Regulation (EC)No.864/2007 of the European Parliament and of the Council of 11 July 2007 on the law
applicable to non-contractual obligations）に基づき、準拠法が決定されます。同規則では、
第４条382により、原則は、損害が発生した国の法律が適用されますが、加害者・被害者のここで記載されている規則については EU 域内で適用される規則であり、EU 域外との紛争に関してそのまま適用されるわけではないが、考え方として参考となるので記載する。
382 Regulation (EC) No.864/2007 of the European Parliament and of the Council of 11 July 2007 on thelaw applicable to non-contractual obligations
Article 4 General rule
1. Unless otherwise provided for in this Regulation, the law applicable to a non-contractual
obligation arising out of a tort/delict shall be the law of the country in which the damage occurs
irrespective of the country in which the event giving rise to the damage occurred and irrespective of
the country or countries in which the indirect consequences of that event occur.
2. However, where the person claimed to be liable and the person sustaining damage both havetheir habitual residence in the same country at the time when the damage occurs, the law of thatcountry shall apply.
381

211

常居所地が同一国である場合には、同常居所地国法が優先し、事案のすべての事情から、別の国と明らかに、より密接な関連があると判断されれば、当該密接関連地国法が適用されることになります。
また、第 8 条 1 項に、以下のとおり知的財産に関する特例があり、侵害行為の結果が発生した地の法（保護国法）が適用されることとなっています。
The law applicable to a non-contractual obligation arising from an infringementof an intellectual property right shall be the law of the country for which
protection is claimed.
つまり、EU で訴訟が提起された場合も、原則的には日本とほぼ同じ考え方で準拠法が決定されることになります。
② 消費者契約の特例「ローマ I 規則」は、第 6 条383で通則法と同様消費者契約についての特例を置いており、
3. Where it is clear from all the circumstances of the case that the tort/delict is manifestly moreclosely connected with a country other than that indicated in paragraphs 1 or 2, the law of that
other country shall apply. A manifestly closer connection with another country might be based inparticular on pre-existing relationship between the parties, such as a contract, that is closely
connected with the tort/delict in question.
383 Regulation (EC) No.593/2008 of the European Parliament and of the Council of 17 June 2008 on
the law applicable to the contractual obligations Article 8 Consumer contracts
1.
Without prejudice to Articles 5 and 7, a contract concluded by a natural person for a purpose
which can be regarded as being outside his trade or profession (the consumer) with anotherperson acting in the exercise of his trade or profession (the professional) shall be governed by thelaw of the country where the consumer has his habitual residence, provided that the professional:(a) pursues his commercial or professional activities in the country where the consumer has his
habitual residence, or(b) by any means, directs such activities to that country or to several countries including thatcountry, and the contract falls within the scope of such activities.
2.
Notwithstanding paragraph 1, the parties may choose the law applicable to a contract which
fulfils the requirements of paragraph 1, in accordance with Article 3. Such a choice may not,however, have the result of depriving the consumer of the protection afforded to him byprovisions that cannot be derogated from by agreement by virtue of the law which, in the absenceof choice, would have been applicable on the basis of paragraph 1.
3.
If the requirements in points (a) or (b) of paragraph 1 are not fulfilled, the law applicable to acontract between a consumer and a professional shall be determined pursuant to Articles 3 and 4.
4.
Paragraphs 1 and 2 shall not apply to:(a) a contract for the supply of services where the services are to be supplied to the consumer
exclusively in a country other than that in which he has his habitual residence;(b) a contract of carriage other than a contract relating to package travel within the meaning ofCouncil Directive 90/314/EEC of 13 June 1990 on package travel, package holidays and package
tours (15);(c) a contract relating to a right in rem in immovable property or a tenancy of immovable property
other than a contract relating to the right to use immovable properties on a timeshare basis
within the meaning of Directive 94/47/EC;(d) rights and obligations which constitute a financial instrument and rights and obligations
constituting the terms and conditions governing the issuance or offer to the public and public
take-over bids of transferable securities, and the subscription and redemption of units incollective investment undertakings in so far as these activities do not constitute provision of afinancial service;(e) a contract concluded within the type of system falling within the scope of Article 4(1)(h).

212i) 事業者が消費者の常居所地でかかる事業のために活動していたか、ii) 事業者が消費者の常居所地を目的として当該活動を行っていた場合であって、契約が当該活動の範囲内である場合には、消費者契約に関しては、消費者の常居所地の法が適用されることとなっています。
このような要件を満たすのは、OSS 開発者が事業者、OSS 利用者が消費者である場合と思われますので、EU の準拠法決定ルールによれば、OSS 利用者の国の法律が GPL について適用されることになります。
これらの規則は、EU 域内での紛争に適用されるものではありますが、考え方としては参考になります。
３．具体的訴訟における検討
実際に原告・被告が別の国に存在する裁判例として、オランダ所在の原告とドイツ所在の被告との間のドイツ裁判所における事案（2015 年７月 27 日 Regional Court of Halleの裁判例）があります。
本件では、GPLv3 第 8 項の Termination の解釈が問題となりましたが、準拠法の議論が特段されないまま、ドイツの著作権法に基づき、判断がされています。
Termination が認められれば、著作権に基づく権利行使の問題となるのですが、その前提として、Termination が認められるか否かは、GPL の解釈上の問題であるので、GPL の準拠法がどのような形であるかを検討してもよかったのではないかと思われます。
４．クラウド上での利用
クラウド上で GPL 適用対象のプログラムを利用する場合でも、直ちに、GPL が適用になるわけではありません（詳細については、本書「A-4」をご覧ください）。とはいえ、インターネットを介した利用の場合には、世界各地から接触が可能となることから、準拠法の考え方は複雑になります。
インターネットによる配信行為の場合、どこで配信行為がされていても、日本から閲覧可
能ですが、閲覧可能であることの一事を持って、日本で侵害行為が生じているとは考えられていません。例えば、国際的なインターネットサービスにおいて、日本の著作権法が適用された事例は、基本的にサービスが日本語で提供されているなど、日本国内での受信を想定していたものとなっています384。

384

例えば,テレビ放送を国外の事業者が日本向けにインターネット配信していた事案では、裁判所は、同サービスが日本在住者に向けられたサービスであることを前提に「加害行為の結果が発生した地」が日本国内であると認定して日本国法を適用しています（東京地判平 26・７・16 裁判所 HP）。また、法の適用に関する通則法制定前の法例の元での事案ではありますが、日本法人がカナダ所在のサーバを利用してファイル交換サービスを提供していた事案において、「本件サービスにおける著作権侵害行為は、実質的に日本国内で行われたものということができ」「被侵害権利も著作権法に基づくもの」であるので、条理（差止請求の関係）ないし法例 11 条１項（不法行為の関係）により、日本法が適用されるとしたものがあります（ファイルローグ事件。東京高判決平 17・3・13 裁判所 HP）。

213

なお、準拠法の決定において、サーバの所在地は直接影響せず385、実際のサービスの全体から判断されています。
５．結論
OSS 利用者が GPL の条項を遵守しない場合、OSS 開発者が権利行使をしようとする場
合、上記のとおり、著作権法に基づく権利行使が一般的です。この場合、著作物が利用された国の著作権法に基づいて判断されることになると思われます。
（作成日：2018 年 3 月 15 日）

385

法の適用に関する通則法において、サーバの所在地に関する規定はありません。

214

G．トラブル事例
１．OSS の過去の問題事例
２．OSS ライセンス違反の法的責任

215

Question G-1-1

OSS の過去の問題要因

OSS に関して、トラブルになりそうな要因として、どういうことがありそうですか？
どういう点に注意すればよいでしょうか？

Answer
１．OSS ライセンスの種類は多数かつ難解
OSS が広く普及し、企業においても OSS 利用は不可欠な状況になっています。ソフトウ
ェアを独自に開発するよりも、
既存の OSS を利用した方が、多くの人に広く使われており、導入コストが安価であり、主なバグ修正なども対応済みで、品質的にも安定しているものがあります。
一方、海外ではライセンス違反による OSS 関連の訴訟が起きているのも事実であり、その原因は、OSS ライセンスの種類が多く、しかも難解であることや、利用者側の知識不足などが考えられます。
制限が厳しい OSS として代表的な GPL、LGPL386については、FSF（Free Software
Foundation）や OSS 支援団体の SFLC（Software Freedom Law Center）によるライセ
ンス違反の摘発や訴訟を通じた啓蒙活動などにより周知されています。しかし、クラウドサービスなどで影響のある AGPL387のライセンス条件の理解不足や、ソフトウェアを組み合わせて利用する際に両立388できないライセンスの知識不足、あるいは調べたインターネット情報（Wikipedia 等）が古くて間違っていたという場合もあるかも知れません。
OSS を利用する場合には、正しいライセンス及びバージョンを確認し、条件に従って適正に利用することが重要です。
２．GPL と両立しないライセンス（GPL Incompatible Licenses）
あるソフトウェアに複数の OSS が利用されているが、ライセンス条件が矛盾しており両立しないため、組み合わせて使ってはいけないケースがあります。GPL と両立しないライセンスは「さまざまなライセンスとそれぞれについての解説」389に掲載されています。
また、ソフトウェア製品に OSS を利用して販売する場合、ソフトウェア製品の使用許諾契約と OSS のライセンス条件が矛盾することもあるため、OSS のライセンス条件を優先さ

GPL, LGPL の特徴や注意点については、本書「基礎-1」、「D-3-1」及び「D-４-1」を参照。
AGPL http://www.gnu.org/licenses/agpl-3.0.en.html
388 両立については、本書「B-1-1」を参照。
389 https://www.gnu.org/licenses/license-list.html
386
387

216

せる対策が必要となるケースもあります390。
３．GitHub のノーライセンス391
OSS ホスティングサイトとして有名な GitHub では、公開されているリポジトリにライ
センス条件が設定されていない場合があり、公開されているプログラムについて著作権者の明示的な許可が掲載されておらず、自由に複製・配布・改変できないという事例が報告されています。このようなプログラムを利用するためには、個別に著作権者へライセンス
条件を確認する必要があります。
４．特許侵害OSS の中には特許権を侵害しているケースがあり、企業がビジネスで利用した場合、権利者から権利行使されるケースがあります。リスクを低減するための対応策としては、利用する OSS について、インターネット上で特許侵害の情報がないか、README 等に特許に関する情報が記載されていないかを調査したり、また、特許調査392をする方法があります。
５．意図せぬ OSS の混入393
オフショア開発や第三者に研究委託した成果などに OSS が混入し、OSS 利用について申告がなく、納品時にソースコードやライセンス文書が付いていなかったため、企業が OSS
混入に気づかないままソフトウェアを製品化し、問題が発生するケースも考えられます。
M＆A などで買収した企業が OSS 管理をしていなかったなどという場合も同様です。
また、ダウンロードした OSS の中に、多数の OSS が含まれており、すべてのライセン
ス条件を調査しきれず、ライセンスに違反してしまうというケースも考えられます。OSSの混入を防止するためには、専用のツールを利用して調査する方法があります。
６．セキュリティ対策
判例にて、ＩＴベンダが顧客向けに受託開発したシステムにて脆弱性により情報漏洩が発生した事案にて、「専門家」としての暗黙の責務として、ベンダ側にセキュリティ対策の責務があると認定されたケースがあります394。たとえ、ユーザとの契約において、損害賠償責任の金額に上限が設けられていたとしても、重過失と判断された場合には、適用が制限される可能性があることを念頭におき、利用した OSS について脆弱性情報などを把握す（作成日：2018 年 2 月 8 日）

る必要があります。

390

本書「C-2-2 を」参照。
http://choosealicense.com/no-license/
392 本書「F-2」を参照。
393 本書「B-1-2」から「B-1-4」を参照。
394 SOFTIC 判例ゼミ http://www.softic.or.jp/semi/2014/5_141113/op.pdf
本書「C-1-2」を参照。
391

217

Question G-1-2

OSS の裁判事例

国内外で OSS について裁判となり、判決が出ている事例としてどのようなものがありま
すか？

Answer
１．米国での例
まず、2018 年１月現在、日本国内で OSS について大規模な訴訟事例は見当たりません。
一方、諸外国（特に米国）では 2000 年代初頭から GPL 条項違反等を理由に訴訟が提起された事例が多くあります。以下においてポイントとなった事案をいくつか紹介します。
（１）MySQL AB v. Progress Software, NuSphere（マサチューセッツ地区連邦地方裁判所（2001 年 6 月 15 日提訴））
［概要］
オープンソースデータベースの販売会社である MySQL AB 社（スウェーデン）が、NuSphere 社とその親会社である Progress Software Corporation を、GPL 条項違反（ソースコード非提供）、著作権及び商標権侵害等を理由に提訴した事案です。
「MySQL」等の商標使用に対する商標権に基づく使用差止等の仮処分は認容され、著作権違反については和解により終結しました。
［ポイント］
OSS ライセンスに対する米国初の訴訟に位置付けられます。原告のデータベースに対す
るアドオンコンポーネントである被告製品が、原告著作物の派生著作物にあたるかが争点となりました。
著作権に基づく差止めの仮処分については認められず、争点となった派生著作物の概念・範囲に対する判断もなされていません。
一方、GPL 条項違反に基づく差止の仮処分については、差止要件である回復不可能な損害が立証できていない等を理由に認められませんでしたが、GPL 条項が当事者の間で法的拘束力を有することが間接的に言明されています。もっとも、GPL の法的性質（契約か否か）については直接判断されていません。395

395

http://law.justia.com/cases/federal/district-courts/FSupp2/195/328/2485211/

218

（２）THE SCO GROUP INC. v. International Business Machines, Corp.（ユタ連邦地方
裁判所、2003 年提訴）
［概要］
原告が、自社保有の UNIX 関連技術のライセンシーである IBM に対し、IBM が UNIX
関連技術を OSS である Linux に流用しているとして、営業秘密の不正取得、不正競争、ライセンス契約違反等で提訴した事件です。
原告は同時に、Linux のユーザである世界中の大企業約 1,500 社に Linux 使用に関する警告状を送付し396、そのうち一部企業（AutoZone、DaimlerChrysler）にライセンス料の支払を求める訴訟を提起しています397。
さらに、原告により、UNIX 技術の著作権者・特許権者は自社であると主張した Novell
社が、自社権利に対する名誉棄損を理由に提訴されています。
地裁では Novell を権利者と判断し原告の請求が棄却されていますが、控訴審で当該判決が差し戻され398、地裁では再度 Novell が権利者と判断されました399。原告が Linux に使用された技術の知的財産権者でないことが確定したことにより、Linux ユーザへの一連の訴訟も収束しています。
［ポイント］
多くのユーザを擁する OSS である Linux が標的にされた事案です。OSS 開発企業の IBMだけでなく、世界的大企業を含む多くの OSS ユーザが訴訟や警告状送付により多額のライ
センス料を請求されたことは、業界に衝撃を与えました。
オープン戦略により多くのユーザを集めることにより発展していく OSS が第三者に権利侵害で訴訟提起された場合の影響力の大きさと、OSS 利用時の権利調査の重要性を知らしめた事件といえます。
（３）BusyBox v. Monsoon Multimedia（ニューヨーク南部地区連邦地方裁判所、2007 年
9 月 19 日提訴）
［概要］
「BusyBox」開発者のうち 2 名からの委託を受けた、非営利団体である「Software
Freedom Law Center」（SFLC）が、BusyBox 利用者である Monsoon Multimedia を訴えた事案です。BusyBox は、テレビや DVD プレイヤー等の組み込み式デバイスで多く利用されている軽量型の UNIX 用ユーティリティ集であり、ライセンスは GPLv2 を使用しています。
原告は、被告が製品（Hava）にソースコードの提供を申し出る文書を添付しておらず、
396

https://www.cnet.com/news/sco-targets-linux-customers/

397

https://www.networkworld.com/article/2331608/software/sco-sues-linux-users-daimlerchrysler--autozo
ne.html
398 http://www.groklaw.net/pdf/AppealRuling.pdf
399 http://www.groklaw.net/article.php?story=20100330152829622

219

これが GPLv2 の第 3 条（ソースコード提供義務、またはソースコードの提供に応じる旨を通知する義務）違反であるとし、GPL 準拠等を求めて訴訟が提起されました。
提訴から 1 ヶ月余り（2007 年 10 月 30 日）で和解が成立しています。
［ポイント］
本件は OSS ユーザに対し GPL 違反責任の追及及び GPL 準拠が直接求められた事案であり、和解条件として、被告側による今後の GPL 準拠、ソースコード提供等の GPL 適合性を監視監督するコンプライアンス責任者の設置、既に BusyBox を入手したユーザに対する権利告知に関する相当の努力、原告への金銭的解決等のきめ細かな合意がなされており400、
早期解決を図るためには OSS ユーザ側で相当の譲歩をする必要がある可能性が高いことが窺えます。
また、本件代理人である SFLC による、GPL 違反を追及された被告側にとっても GPLの無効を主張することにメリットはないとのコメントが注目され401（被告側が GPL 無効を主張した場合には原告から著作権侵害を追及される）、本件の早期和解成立にも影響しているものと考えられます。
（４）BusyBox v. Best Buy, Westinghouse Digital Electronics, JVC など 14 社（南ニューヨーク連邦地裁、2009 年 12 月 14 日提訴）
［概要］
BusyBox 開発者の代理人である SFLC が、被告がテレビや DVD 等の対象製品にソース
コードの提供を申し出る文書を添付していなかったことを理由に、GPLv2（第 3 条）違反
として、Best Buy、Samsung 等 14 社（他 Westinghouse、JVC、Western Digital、Robert
Bosch、Phoebe Micro、Humax USA、Comtrend、Dobbs-Stanford、Versa Technology、
Zyxel Communications、Astak、GCI Technologies）を訴えた事案です。
破産法適用を申請した Westinghouse 以外は 2012 年までに和解により決着しています。
Westinghouse については、故意の侵害が認められた結果、損害賠償（3 倍賠償）、BusyBox
ソフトウェアを組み込んだ HDTV 製品販売の永続的差止命令、侵害品の没収が命じられています。
［ポイント］
Monsoon 案件に続き、GPLv2 の第 3 条（ソースコード提供義務、またはソースコードの提供に応じる旨を通知する義務）違反を理由に訴訟提起された事案です。
和解成立に至った当事者間の和解条件は不明ですが、判決に至った当事者（Westinghouse）
については、3 倍賠償、該当製品の永続的販売禁止、侵害品の没収等の重い責任が課されています（もっとも、財政状況が悪化していた Westinghouse は discovery 手続に参加せず証拠提出要求に応答しなかった上、後に代理人を解任しており402、そうした訴訟追行の姿勢
400
401

https://www.softwarefreedom.org/news/2007/oct/30/busybox-monsoon-settlement/
https://www.linux.com/news/settlement-reached-busybox-monsoon-gpl-case

402

220

が招いた結果であるとも考えられます）。
また、上記は略式判決（Westinghouse 破産のため）により判示されていますが、略式判決では正式事実審理が省略されるため認定には確実性の高い証拠が一般に必要とされるところ、GPL が略式判決の証拠として用いられた点も注目されます。
（５）Robert Jacobsen v. Matthew Katzer（カリフォルニア北部地区連邦地方裁判所、2006
年 3 月 13 日提訴）
［概要］
自らが運営する OSS グループで鉄道模型操作用 OSS「Decoder Pro」（「原告製品」）を創作した原告（上訴人）が、原告製品の定義ファイルの一部を使用した被告（被上訴人）の製品が著作権を侵害しているとして、カリフォルニア地裁に使用差止等を求め提訴した事案です。
原告製品ダウンロード時に表示される「Artistic License」には、著作者の氏名、著作権に関する表示、定義ファイルのオリジナルソース、オリジナルソースコードからの改変箇
所等の表記が「condition」として定められていました403。
連邦地方裁判所は、Artistic License は有効範囲が限定されない非独占的ライセンスであり、condition の違反は当該ライセンス違反となりうるものの、当該条項はライセンスの範囲を制限する条項ではないため著作権侵害を構成しないと判断しましたが、これに対し原告が控訴。
二審の連邦控訴裁判所では、Artistic License は著作権ライセンスの許諾条件であるとし、当該条件に従わなかった場合には著作権侵害が成立すると判示しました。
［ポイント］
本件は GPL 以外の OSS ライセンスが争点となった事案です。本件では、原告 OSS ダウ
ンロード時に表示される Artistic License の法的性質が争点となりました。Artistic Licenseが（著作権使用許諾と別個の約定である）契約と判断される場合には、原告は契約法に基づく債務不履行責任を追及できるのみです。
一方、Artistic License が著作権ライセンスの条件であると判断される場合には、当該条件違反は著作権侵害となり、原告は著作権侵害訴訟を提起しうることとなります。
本件では、Artistic License の condition において、著作物の複製・改変・頒布をする権利が条件に従った場合に（「provided that」）付与されると記載されていたこと等を理由に、Artistic License の記載条件は著作権ライセンスの条件であると判断され、当該条件に従わなかった場合には著作権侵害が成立することが判示されました。

https://arstechnica.com/information-technology/2010/08/court-rules-gpl-part-of-a-well-pleaded-case/403 http://caselaw.findlaw.com/us-federal-circuit/1189790.html

221

（６）Free Software Foundation v.Cisco Sysems（ニューヨーク南部地区連邦地方裁判所、
2008 年 12 月 11 日提訴）
［概要］
非営利団体である Free Software Foundation（FSF）が（代理人は SFLC）、Cisco Systemsの販売する Linksys ブランド製品の多くに、FSF が著作権を保有する OSS プログラム（GNU Compiler Collection、GNU Binutils、GNU C Library 等）が利用されているにもかかわらず、当該 OSS が採用するライセンス条件（GNU General Public License（GPL）、
GNU Lesser General Public License（LGPL）等）を遵守していないとして提訴した案件です。2009 年 5 月 20 日和解が成立したことが発表されています。
［ポイント］FSF による初の OSS ライセンス条項違反訴訟とされます404。提訴から半年足らずで和解が成立しています。和解条件として、被告による Linksys ブランド製品の GPL 条項等の遵守とコンプライアンスに対する責任者の設置、当該責任者による FSF に対する定期的な報告、Linksys WEB サイトや他の出版物等にて、既に FSF のプログラムを含む製品を入手したユーザに対する権利告知、最新 Lynksys 製品で利用する FSF プログラムソースコードの WEB サイトでの無料提供、原告への和解金支払等が発表されています405。
本件では、FSF が 2003 年に最初に GPL 違反を指摘して以来、解決が模索されてきました
が、FSF が Cisco 側の対応が不十分であったことを理由に訴訟に踏み切ったことも注目されます406。
２．ドイツでの例（１）Christoph Hellwig v. VMWare（ハンブルグ地方裁判所、2016 年 8 月 7 日判決（一審被告勝訴））［概要］
LinuxカーネルのSCSIサブシステムのディベロッパーである原告（Hellwig氏）が、Linux
カーネルに提供したソースコードが被告（VMWare社）の製品で使用され（Linuxカーネルのコードを被告が著作権を有するソフトウェアと結合した製品を配布）、GPLv2の条項（ソースコード提供）に違反したことを理由に提訴した事案です。被告による原告ソースコー
ドの使用が立証されなかったことを理由に原告の訴えが退けられています。
［ポイント］
本件ではGPLが伝搬する範囲（派生著作物・結合著作物に該当するか否か）が争われました。
本件では、被告により、Linux カーネル用ドライバを被告製品（ESXi） に使用することを目的として、Linux カーネル（vmklinux）に対する改変が加えられています。被告製品
https://www.softwarefreedom.org/news/2008/dec/11/cisco-lawsuit/
https://www.fsf.org/news/2009-05-cisco-settlement.html
406 http://www.fsf.org/news/2008-12-cisco-suit
404
405

222

では、被告が著作権を有するソフトウェア本体に Linux カーネルコード（vmklinux）を含むモジュール（vmkernel）が結合されており（ドライバをカーネル本体に接続するコード（vmklinux）は GPL に基づきライセンスされています）、このようなソフトウェア（vmkernel）が Linux カーネルの結合・派生著作物として GPL の規律に服すかが争点となりました。
判決においては、原告が侵害を主張するソースコードが特定されていないことを理由に訴えが棄却され、上記争点に対する直接の判断は下されていません。407（２）AVM Computersysteme Vertiebs GmbH v. Cybits AG（ベルリン地方裁判所 2011年 11 月 7 日判決）
［概要］
ドイツのDSLルータの大手メーカである原告（AVM Computersysteme Vertiebs GmbH）
が、子供用フィルタリングソフトウェアのベンダである被告（Cybits AG）を、著作権法上の改変権違反であるとして提訴した事案です。被告ソフトウェア「Surf-Sitter DSL」では、
原告ルータ「FRITZ！Box」のファームウェア（OSSであるLinux kernelを含む）をユーザのコンピュータにダウンロードし修正した上で原告ルータ「FRITZ！Box」のファームウェ
アに再インストールするアプリケーションが使用されていました。
本件では、Linux Kernel開発者の一人であり、ソフトウェアのGPLに則った利用のチェックを行う非営利団体「gpl-violation.org」の主宰者であるHerald Welte氏が、原告の改変妨害はGPLの禁止事項（付加的制限の付与）に該当するとして訴訟参加しています408。
原告が求めた使用禁止の仮処分は、被告による修正がonline／offlineの表示誤りを訂正す
るものにすぎないことを理由に大筋で否定され、続いての本審でも原告の主張は認められませんでした。409［ポイント］
本件は、ソフトウェアの一部にGPL準拠のOSSが含まれる場合についての事案です。
被告側は、本件ファームウェアにはGPLでライセンスされるソフトウェアが含まれているため、ファームウェア全体が当該ソフトウェアの派生著作物でありGPLのライセンス条
件に服するところ、改変等を禁止することはGPL（付加的制限付与の禁止）に違反するた
め、GPLのライセンス解除条項により原告はライセンシーとしての地位を失い、当該プログラムの利用権限を失ったと主張しています。それに対する反論として、原告は、本件ファームウェアは複数のプログラムの寄せ集めであり、GPLのライセンス条件に服するプロ
グラムについては改変を禁止しないことを主張していました。
判決は、OSSがプリインストールされたデバイスのユーザに対し、OSSに改変を加えた
上でデバイスへの再インストール・顧客への販売等をする法的な自由を認めたものと評価
http://bombadil.infradead.org/~hch/vmware/Judgment_2016-07-08.pdf
https://fsfe.org/activities/ftf/avm-gpl-violation.en.html
409 https://fsfe.org/activities/ftf/avm-gpl-violation.en.html
407
408

223

されています。410（作成日：2018年3月7日）

410

https://fsfe.org/news/2011/news-20111110-01.en.html

224

Question G-2-1

OSS 混入によるライセンス違反

自社の発注先が自社開発プログラムのモジュールに混入させた OSS につき、自社ではその混入を知らなったことから、自社開発プログラムを配布する際、OSS のライセンス条件に従った配布をすることができませんでした。この場合、自社開発プログラムは差止めを受けるのでしょうか。また、当該 OSS の権利者に対し、自社は損害賠償の責任を負うのでしょうか？

Answer
１．OSS の混入によるライセンス違反のリスク
OSS の混入による OSS ライセンス違反は、OSS に関する代表的なリスクであるといえます。OSS の混入が生じるケースとしては、本問のように、自社の発注先が OSS を利用していることを報告しないまま成果物を納品するケースのほか、自社内においても、OSS の利用に関する社内ルールを知らない現場の開発者が、納期を遵守するために無断で OSS を利用してしまうケースなどが考えられます。
このような OSS の混入により、OSS ライセンスに従った配布ができなかった場合、すな
わち、OSS ライセンス違反を犯してしまった場合、違反者には、どのような法的責任が生じるのでしょうか。OSS ライセンスに違反した場合であっても、発覚後、迅速にライセン
ス違反の状態を解消し、再発防止策を講ずるなどすれば、法的責任を追及されずに済む場
合もあるでしょうが411、ここでは、そのような穏便な解決がなされず、OSS の権利者から違反者に対して法的責任追及がなされる場合について検討します。
なお、本問においては、日本の裁判所において、日本法によって判断されることを前提に検討します412。
２．OSS ライセンス違反に対する法的責任
OSS ライセンスは、OSS の権利者（著作権者）が、OSS の利用者に対し、OSS の利用許諾の条件を定めるものです。
したがって、
OSS の利用者がライセンス条件に違反して OSSを利用した場合413、その利用行為は OSS の著作権に対する侵害となります。本問のケース
411

本書「G-2-2」参照。
OSS の開発者（著作権者）が OSS 利用者をライセンス条件違反で提訴する場合の準拠法については、
本書「F-4-2」参照。
413 著作権法は、著作権侵害が成立する利用行為（法定利用行為）を 21 条から 27 条までに限定列挙している。プログラムの著作権に関連が深いものとして、複製権（21 条。例：パソコン内ハードディスクへの
ダウンロード）、公衆送信権（23 条。例：インターネット上のＨＰにおけるソースコードの提供）、頒布権（26 条）
・譲渡権（26 条の 2）、翻案権（27 条）等がある。
412

225

で、自社は、自社開発プログラムを配布する際、OSS ライセンスに従った配布をすることができませんでした。自社開発プログラムの配布には、通常、プログラムの「複製」が伴いますので、OSS ライセンスに違反して OSS を利用したものとして、自社には、著作権侵害が成立すると考えられます414。
著作権侵害に対する法的責任としては、①差止め（著作権法 112 条 1 項）、②損害賠償（民法 709 条）415のほか、故意に侵害した場合は③刑事罰（著作権法 119 条～124 条）も定められていますが、ここでは民事責任である①、②について検討します。
なお、自社開発プログラムを自社内でのみ使用する場合については、本稿３．で検討します。
（１）プログラムの差止め
著作権に基づく差止請求は、著作権侵害の事実があれば、侵害者（自社）に故意・過失がなくとも認められます（著作権法 112 条 1 項）
。したがって、自社開発プログラムの配布によって OSS ライセンス違反による著作権侵害が成立する場合、OSS 権利者から差止請求がなされたときには、自社は当該 OSS の複製や配布ができなくなります。また、当該 OSSが自社開発プログラムと一体となっている場合には、自社開発プログラムも含めてその複製・配布ができなくなると考えられます。
（２）損害賠償
著作権侵害に基づく損害賠償請求が認められるためには、侵害者（自社）の「故意・過失」や「損害」の発生等が要件となりますので、本問においてこれらの要件が認められるかを検討します。
ア 過失について本問のケースにおいて、OSS は自社の発注先によって混入されており、自社は OSS の混入を知らなったのですから、自社に故意は認められません。それでは、自社には過失もなかったという主張はできるでしょうか。
過失とは、一般に、「損害発生の予見可能性があるのにこれを回避する行為義務の履行を414

譲渡権は、譲渡権者またはこの者の許諾を得た者が原作品・複製物を他の者に譲渡した場合（適法な
譲渡がなされた場合）には、それ以降の譲渡には及ばない（譲渡権の消尽。著作権法 26 条の 2 第 2 項）。
そして、譲り受けた時点で譲渡権が消尽していないことについて善意無過失であった譲受人は、著作物の原作品、複製物等について、適法に公衆に再譲渡できるとされる（善意者に係る譲渡権の特例。著作権法
113 条の 2）。本問のケースで、著作権法 113 条の 2 によって、自社の配布行為について著作権侵害の成立が否定されるのではないかとも思えるが、譲渡を受けたプログラムを複製したうえで譲渡する場合、同規定は適用されない。そこで、自社開発プログラムの配布にプログラムの複製が伴う場合、同規定によって自社の著作権侵害が否定されることはない。
415 著作権法には損害賠償請求権の直接の根拠となる規定はないが、著作権の侵害行為は、民法上の不法行為を根拠に損害賠償が認められる（民法 709 条）。なお、著作権法には、著作権侵害に基づく損害賠償請
求における損害額の推定規定（著作権法 114 条）等が定められている。

226

怠った場合」（注意義務違反）と言われています。プログラムの著作権侵害の例でいえば、当該プログラムの著作権侵害行為により、著作権者に損害が発生することが予見可能であったにも拘らず結果回避義務を怠った場合には、不法行為に基づく損害賠償責任を追及されてもやむを得ないということになります。そして、この「予見可能性」及び「結果回避義務」の判断にあたっては、侵害行為当時の技術水準に照らして、予見可能であったか、
結果回避が可能であったかという点が、それぞれ問題となります。
それでは、本問で自社に過失が認められるでしょうか。
上記１．で述べた通り、OSS の混入による OSS ライセンス違反は、OSS に関する代表
的なリスクといえますので、侵害当時の技術水準に照らし予見可能性があったと判断されるものと思われます。次に、結果回避の点ですが、OSS の混入はチェックツールを導入することにより、相当の確度で OSS を検出することができるとされるため、裁判所においては、侵害当時の技術水準に照らし、結果回避が可能であったとの判断がなされる可能性もあります。
次に、侵害者（自社）が結果回避義務を尽くしていたかという点が検討されますが、OSSの混入防止手段として、どこまでの手段を講じていれば、結果回避義務を尽くしたとして過失が否定されるでしょうか。
OSS の混入を防止する手段としては、①発注先との契約によって OSS の利用に関するルールを明示的に合意する（OSS を利用するには自社の書面による承諾を必要とする等）、②
発注先に対して検収時における OSS の利用状況の報告を義務付ける、③発注先からの納入品について、自社においてチェックツール416を用いて OSS の混入がないかをチェックする等が考えられます417。
これらの手段を全て講じていれば、結果回避義務を尽くしているものとして過失は否定されるものと考えられます。もっとも、①～③の全ての手段を採っていない場合でも、自社の規模やプロジェクトの規模等に応じた適切な手段を講じることによって、過失の認定を避けられる場合もあると思われます。
したがって、各社は適切な OSS 混入防止措置を講じておくことが重要であると指摘できます。
イ 損害の発生について損害賠償の対象となる損害には、財産的損害と精神的損害418があり、前者には積極的損
害419と消極的損害420があります。プログラムの著作権が侵害された場合、当該侵害行為に

416 過失の認定を避けるためには、侵害当時の技術水準に照らし、標準的な技術水準を満たすチェックツールを用いる必要があると考えられる（本書「B-1-4」参照）。
417 詳細は本書「B-1-2」～「B-1-4」参照。
418 精神的に被った不利益のことを言い、精神的損害に対する賠償を慰謝料という。
419 既存の財産が現実に減少するという形で受けた損害
420 本来増加するはずであった財産が増加しなかったという形で受けた損害227

よって権利者の売上が減少し、それに伴い利益が減少した場合の利益の減少額（消極的損害）が、一般に想定される損害といえます。
OSS が無償で配布されている場合には、そもそも OSS の著作権が侵害されても権利者にライセンス料等の減少がなく消極的損害が発生しないとも思えます。しかし、著作権法は、著作権を故意又は過失により侵害された著作権者は、その著作物の使用料相当額を受けた損害の額として請求できるものと定められています（著作権法 114 条 3 項）
。この規定により、OSS の著作権料として本来であれば支払われるべき金額421が、権利者の損害として認定される可能性があります。422
３．自社開発プログラムを自社内でのみ使用する場合
自社が自社開発プログラムを対外的に配布せず、自社内で使用する場合にも OSS の著
作権侵害が成立するでしょうか。
日本の著作権法において、プログラムの複製・翻案等を伴わない使用行為は、原則として著作権侵害とならず、例外的に、著作権侵害により作成された複製物について、使用権原取得時に「情を知っていた」場合に限り、業としての使用が著作権侵害とみなされます（著作権法 113 条 2 項）
。すなわち、自社がプログラムの入手時に OSS の著作権を侵害していることを知らなければ、その後、それを知ったとしても、差止を受けたり、損害賠償義務を負うことなく、使用を継続することができます。また、その使用に必要な限りで、
当該プログラムのインストールやバックアップ等の複製・翻案も許されるものとされます（同法 47 条の 3 第 1 項）423。
したがって、本問において、自社はプログラムの入手時まで OSS の混入を知らず、著作権侵害の事実を知らなかった場合、自社が自社開発プログラムを自社内で使用する行為は
OSS の著作権侵害とならず、自社がプログラム入手時までに OSS の混入を知っていた場合には、自社内でのプログラムの使用についても、OSS の著作権侵害が成立するといえます。
（作成日：2018 年 2 月 18 日）

421

従前、著作権法 114 条 3 項は、「通常受けるべき金銭の額」と定めていたため、利用許諾を受ける際に支払われる使用料を損害と解釈する傾向があったが、平成 12 年の改正により、「通常」の文字が削除されたことにより、既存の使用料規程等に拘束されることなく、当事者間の具体的な事情を考慮した妥当な損害額の認定が可能になったとされる（島並良他「著作権法入門」有斐閣、2009 年、272 頁）。
422 なお、デュアルライセンスで提供され、GPL が遵守できない場合に別途有償ライセンスを要求している MySQL などの GPL プログラムの場合、GPL 違反者は有償ライセンス料相当額の損害賠償義務を負担することになる。
423 著作権法 113 条 2 項が適用される場合、同規定は適用されない（同法 47 条の 3 第 1 項但書）。

228Question G-2-2

GPL 違反に対する法的責任

GPL 違反が発覚した場合、これまでの事例を踏まえるとどのような事態が想定されますか？また、違反者は、GPL プログラムの権利者に対し、どのような法的責任を負いますか？
違反者にはソースコードの提供義務もあるのでしょうか？

Answer
１．GPL 違反が発覚した場合国内においては、現在までのところ、GPL 違反により訴訟が提起されたケースは報告されていませんが（2017 年 10 月現在）、ユーザからの指摘等によって GPL 違反が明らかになったケースが複数報告されています。
これらの事例においては、
ユーザが GPL 違反の事実や違反の指摘に対する企業（違反者）の対応等をネット上の掲示板に書き込んだり、コミュニティが違反の事実や違反者の対応
をネット上で発表したりすることによって、事態が明らかになるケースが多いようです。
もっとも、GPL 違反の指摘に対し、違反者が迅速に対応したケースでは、係争に発展せず問題が解決し、迅速かつ誠実な対応に対してコミュニティから高い評価が与えられたケースもあるようです。海外の事例424などを参考にすると、違反者が誠実に対応しない場合、コミュニティから強い警告が届き、その後、法的な責任追及に発展していくことが予想されます。
したがって、GPL 違反が発覚した場合には、違反の指摘に対して誠実に対応し、迅速に違反状態を解消するなどの対策をとることが最重要であると考えられます425。
【国内における GPL 違反事例】〇時期：2002 年 9 月
内容： Ａ社製のスキャナ及びプリンタに関して、①Linux 用のドライバの中で使用されていた gettext パッケージのソースコードの一部（libintl）が GPL であるにも関わらず、GPL に違反する状態で配布されている（GPL 違反）、②ソースコードを非公開とするライブラリ内において、LGPL ライブラリ（glibc）とリンクしていたが、Ａ社の使用許諾が LGPL に準拠するものではない（LGPL 違反）と指摘された。これに対して、Ａ社は、自社の WEB サイト上で謝罪したうえ、①gettext パッケージを、LGPL 準拠のバージョンに差し替えることによって、
424
425

海外における裁判事例については、本書「G-1-2」参照。
GPL 違反状態の解消方法については、本書「G-3」参照。

229

GPL 違反の状態を解消し、②LGPL 第 6 条に基づき非公開コンポーネントのリ
バース・エンジニアリングを許可するよう使用許諾を変更することによって
LGPL 違反の状態を解消した。Ａ社が従前から Linux コミュニティに貢献していたこともあり、Ａ社の対応はコミュニティから賞賛を受ける結果となった426。
〇時期：2002 年 12 月
内容：B 社が販売する MP3 プレーヤーに GPL が適用される Linux カーネルが含まれていたが、B 社は該当部分のソースコードを提供していなかったところ、製品を購入したユーザから B 社に問合せがなされ、また、そのやりとりがネット上の掲示
板へ書き込まれ、GPL 違反が発覚した。B 社は、その後、該当部分（改変した Linuxカーネル）のソースコードを公開した427。
〇時期：2007 年 11 月
内容：2001 年に販売された C 社のゲームソフトウェアに、GPL が適用されている
Libarc が含まれていた。2007 年ユーザがソフトウェアを解析して GPL 違反を発見し、C 社などに連絡したが、C 社は GPL 違反の指摘に対し、明確な対応をしないまま、翌 2008 年、同ゲームソフトウェアの生産、販売を中止した。同社のこの対応に対しては、疑問をもつユーザが多かったとされる428。
２．GPL 違反に対する法的責任（１）著作権侵害に基づく責任
GPL 違反者は GPL プログラムの権利者に対し、どのような法的責任を負うでしょうか。
GPL は、GPL プログラムの著作権者による利用許諾条件を定めています。したがって、その条件に違反する形で GPL プログラムを利用した場合429、違反者は GPL プログラムの著
作権侵害に基づく法的責任を負います。具体的には、著作権侵害に基づく差止め（著作権法 112 条 1 項）や損害賠償請求（民法 709 条）を受けることになります430。
（２）ソースコードの提供義務
GPL に違反した場合の法的責任として、違反者はソースコードの提供義務を負うのでし426

寺田雄一「図解ビジネス最新オープンソースがよ～く分かる本」（秀和システム、2016）144 頁、
岡村久道「『オープンソースでどこまでできる』第７回オープンソースのライセンス(2)、日経×TECH、2003 年 12 月 2 日 http://tech.nikkeibp.co.jp/it/members/SI/oss/20031127/1/
427 寺田雄一 前掲「図解ビジネス最新オープンソースがよ～く分かる本」145 頁
428 同上、146 頁
429 GPL において、GPL プログラムを受領または実行する限りにおいては、GPL の定める条件に従うことは要求されておらず、GPL の条件遵守が要求されるのは、GPL プログラムを改変または配布したときである（GPLv3 第 2 条、GPLv2 第 0 条）。
430 OSS の開発者（著作権者）が OSS 利用者をライセンス条件違反で提訴する場合の準拠法については本
書「F-4-2」参照。

230

ょうか。
この点は、GPL の法的性質と関連して議論されています431。
GPL の法的性質に関しては、GPL プログラムの開発者（権利者）による権利不行使の一方的宣言であるとの考え方があります（以下、「宣言説」といいます）。日本法において、契約の成立には「申込み」と「承諾」の意思表示が要件とされますが（民法 521 条以下）、宣言説は、GPL プログラムには GPL のライセンス条件が記載されたテキストファイルが同梱されているにすぎず、ライセンス条件の適用を受けることについて利用者の「承諾」があると評価できないこと等を根拠としています。契約の成立を否定する「宣言説」によれば、契約に基づくソースコード提供義務は認められず、権利者は違反者に対し、著作権に基づく責任を追及できるにとどまると考えられます。
他方、GPL は契約であるという考え方があります（以下、「契約説」といいます）。日本
においては、契約以外のライセンスという概念が日本法にはないとして「契約説」の立場をとり、利用者が改変や配布という権利者の許諾がなければなしえない行為に着手した時点で「承諾」があったものとみなすという解釈が一般的になされているようです。このよ
うに、GPL を契約と捉えると、違反者は、契約に基づくソースコードの提供義務を負うとの解釈が可能になります432,433。
なお、上述したとおり、国内においては、現在まで、GPL 違反の事例について訴訟が提起されたとの報告はなく、この点について裁判所における判断は示されていません434。
（作成日：2018 年 2 月 18 日）

GPL の法的性質については、本書「D-4-1」参照。
契約に基づくソースコード提供義務の履行請求に関しては、①GPLv3 の条項上、ソースコードを提供することなく改変ソフトウェアを配布した場合、GPL ライセンスが自動終了するものとされる（第 8 条）が、ライセンスが自動的に終了している状態で、ライセンス契約に基づく履行請求がなし得るのか、②
GPLv3 第 6 条には、ソースコードの提供方法が複数定められているが、義務の内容が特定されているといえるのか、等の問題点が指摘されている（片山史英弁護士・弁理士 SOFTIC LAW NEWS「GPLv3 のソ
フトウェアについてライセンス契約の成立が問われた事例」一般財団法人ソフトウェア情報センター、2017
年 16 頁）。また、③GPL を契約と解したうえで、その規定ぶりからソースコードの提供は利用許諾の「条件」に過ぎず、履行を強制できる契約上の義務とまではなっていないとして、違反後のソースコード提供義務を否定する立場もある。
（「ビジネスユースにおけるオープンソースソフトウェアの法的リスクに関する調査」財団法人ソフトウェア情報センター、2005 年）10 頁
https://www.ipa.go.jp/about/jigyoseika/04fy-pro/open/2004-741d.pdf）
433 GPL は、
GPL プログラムの著作権者と GPL プログラムの利用者の直接契約と解されることを根拠に、
GPL プログラムの著作権者がソースコード提供の請求権者であるとの指摘がある（片山史英弁護士・弁理士 前掲 SOFTIC LAW NEWS 17 頁）。もっとも、GPL プログラムの受領者が、ソースコードを提供しない配布者に対し、GPL の遵守を求め、ソースコードの提供を要求できることは当然である。
434 訴訟が提起された後、和解で解決する可能性もあるが、海外の事例において和解が成立したケースの和解条件としては、①GPL の遵守（ソースコードの提供を含む）、②和解金の支払、③再発防止策の策定（例：
社内監視体制の構築と権利者に対する報告）、④再度の違反時の違約金の合意などがある。
431

432

231

Question G-3

ライセンス違反等のトラブルへの対応

自社では GPL プログラムを活用したソフトウェアをユーザに配布していますが、ソフトウ
ェアのソースコードを提供していないのはライセンス違反であるとの指摘をユーザから受けました。どのように対処すれば良いでしょうか？

AnswerOSS のライセンス違反に限らず、トラブルが生じた場合は迅速かつ誠実な対応が求められます。その対応を誤ると、自社の評判をおとしめ、社会的な信頼を損なうおそれがありますので、慎重に対応を進める必要があります。トラブルの内容やその社会的なインパク
ト、会社の構造や規模などが異なれば、とるべき適切な対応ももちろん異なりますが、例えば以下のような対応が考えられます。
１．初動対応現場の担当者の判断に基づき対応した結果、トラブルを更に大きくすることがあります。
そのような事態が生じるのを避けるため、迅速に経営層へのエスカレーションを行って、会社としての対応に切り替えます。トラブルに関する社外とのコミュニケーションは、対応窓口を定めて一元化し、発信する情報を統制します。
指摘を行ったユーザに対しては、社内で調査を行っていて事実関係を確認中であることを速やかに伝え、互いの連絡方法を決めておきます。連絡は電話ではなく文書でやり取りするのが良いでしょう。特に、重要な連絡を行う場合は、内容証明郵便が有用です。
２．事実確認
まず、自社がライセンスのどの条件に違反しているのか、ライセンス違反を指摘したユーザの認識を確認します。その結果を踏まえ、自社内でライセンス違反の事実確認を行います。例えば、現場担当者に対して GPL プログラムの利用方法について詳細にヒヤリング
し、ライセンスで定める条件との整合を比較します。
調査担当者の知識やスキルでは収集した情報の分析やライセンス条件との整合性の判断が難しい場合は、弁護士、弁理士、コンサルタント等の外部の専門家に相談し、自社の判断で拙速に結論を出すことは避けるのが賢明です。対応を誤れば、トラブルの拡大や、対応コストの増加などを招くリスクがあります。
しかしながら、事実確認に要する時間が長くなり過ぎても同様のリスクが生じることが予想されますので、事実確認は期限を定めて迅速に行うことが求められます。

232

３．問題解決に向けた対応
事実確認の結果、自社がライセンスに違反していないことが客観的に明らかである場合には、ライセンス違反を指摘したユーザに対して、ソースコードの提供方法を含め、事実確認の結果を説明します。ユーザは、OSS の著作権者ではないため、内部情報について、どこまで詳細に説明するかは、現在進行中のビジネスはもちろんのこと、今後のビジネスへの影響も十分に鑑みて最適な対応をとるようにします。
自社がライセンスに違反していた場合やその疑いが強い場合は、ライセンス違反を指摘したユーザに対して事実確認の結果と是正を行う意思があることを誠実に説明し、当該ユーザの理解を得るようにします。その上で、違反事項を解消します。
例えば、GPL プログラムを利用していたにもかかわらず、そのことを明らかにせず、ライセンス条件やソースコードの提供方法を記した文書を添付していなかった場合に、ライセンス違反を解消するための具体的な方法として以下が考えられます。
① GPL で要求していることを忠実に実行するように改める。
② GPL プログラムとリンクした独自プログラムのソースコードを提供できない
場合、リンクしない形に実装方法を改める435。
③ GPL プログラムと同等の機能を持つ別のライセンス形態の OSS に取り替える。
④ GPL プログラムと同等の機能を持つソフトウェアを自社で独自に開発する。
どのような対処を行うかは、対応に要する期間、コスト、リソース、ビジネスへのインパクト等を考慮のうえ、総合的に判断する必要があります。GPL プログラムを既に多くのユーザに配布してしまっており、上記の対応が困難である場合には、以下の５項に記すようなコミュニケーションによる解決を目指すことが考えられます。
４．GPLv3 の違反によるライセンスの終了と回復
GPL の条項に違反した場合、GPL によるライセンスが自動的に終了することとされているため（GPLv2 第４条、GPLv3 第 8 条第 1 パラグラフ）、その後も GPL プログラムの配布等を続けようとする場合には、著作権者から著作権侵害に基づき、差止請求又は損害賠償請求を求められる可能性が生じます436。その一方で、GPLv3 からは、違反を是正した場
合にはライセンスが回復する旨が明文化されました。
GPLv3 第８条第２パラグラフは、違反行為がすべて中止された場合、①著作権保有者が明示的かつ確定的に終了させるまでは、ライセンスが暫定的に回復すること、及び②違反行為の中止後 60 日以内に同著作権者が合理的手段で違反の旨を通知しなかった場合には永久的にライセンスが回復することを定めています。
また、同条第３パラグラフは、著作権者から合理的な手段で違反の旨の通知を受けた場
GPL の伝搬やリンクの開発、伝搬を避ける設計手法については、本書の「D-3-1」を参照。
GPLv3 ではプログラムを実行する行為には、許諾が不要とされているため（第 9 条）
、自ら実行する行
為自体は制限されません。
435
436

233

合、それが同一著作権者から GPLv3 の違反についての最初の通知を受けた場合であって（GPL に基づく全てのプログラムに関しての最初の通知を意味します）、かかる通知受領後30 日以内に違反を是正した場合には、ライセンスが永久的に回復することを定めています。
したがって、GPLv3 については、違反の旨の通知を受けた場合には、是正対応をすれば、プログラムの配布等を中止する必要はないこととなります。
例えば、一つの OSS 中にライセンスを異にする複数の OSS が含まれていることが多い
ため、GPLv3 プログラムが含まれていることに気付いていなかった場合なども十分あり得ます。このような場合、通知が来て初めて GPLv3 適用の OSS があることに気付くこともあると思われます。上記のとおり、事後的な是正でもライセンスの回復が可能であるため、通知が来た場合には、真摯に対応することが望ましいと言えます。
５．社外とのコミュニケーション
ライセンス違反またはその疑いがあることが既に公になっている場合、自社の顧客や取引先からの問い合わせに備え、調査結果やそのことが及ぼす影響等について回答を用意しておき、顧客や取引先が抱いている不安や疑念を即座に解消できるようにします。仮に公になっていなかった場合でも、解決の結果によっては謝罪やソースコードの提供について
自社 WEB サイトでの周知やニュースリリースが必要になることも考えられますので、そのような対応も想定しておく必要があります。
また、ライセンス違反の有無にかかわらず、ブログや SNS などを通じて、ライセンス違反を指摘したユーザ以外の第三者が自社の対応等に関して批判的な情報発信を行うことも考えられます。不用意な情報発信により炎上を引き起こすことのないよう、必要に応じて外部の専門家に相談し、発信するタイミングや内容について慎重に判断することが重要です。
６．社内へのフィードバック
トラブルの解決後は、原因を明らかにして再発防止策を講じるだけでなく、解決の過程で得られた教訓を形式知化し、ノウハウとして自社内に蓄積できるようにします。そうすることで、同様のトラブルが生じることを回避でき、万が一同様のトラブルが起きても迅
速かつ適切な対応ができると期待されます。
すぐに実施するのが望ましいこととしては、全社周知による注意喚起です。開発者の認識不足に対する教育強化が必要なのか、あるいは開発委託の納品物における OSS 混入のチ
ェック強化が必要なのかなど、トラブルの原因に応じて注意すべき観点を明確にし、自社の社員が同様のトラブルを起こさないように強く意識付けをします。
長期的な観点では、社内研修の教材としてトラブルの内容とその対処をケーススタディの形で解説し、定期的にあるいは一定の階層になった時に必ず学習するような仕組みを設けることなどが考えられます。二度と同じ失敗を繰り返さないためには、研修はとても有234

効な施策です。
より高いレベルの再発防止策としては、OSS のライセンス条件の遵守を管理437する責任者とチームを設置し、専用ツール438を使って社外に出すソースコードや社外から受領した
ソースコードに OSS が混入していないか、使用している OSS がライセンス条件と矛盾していないか等を確認して、問題がないことが確認できた OSS のみ使用を認めるといった運用の徹底などが考えられます。
以上はあくまで一例です。本解説を参考にして、自社に合った対応をご検討ください。
（作成日：2018 年 3 月 7 日）

437

OSS ライセンスの遵守を徹底するためには、OSS の利用ポリシーの作成や社内での教育が有効です。
それらについては、本書の「B-2」を参照。
438 専用ツールについては、本書の「B-1-3」を参照。

235

H．今後の動向

236

Question H

OSS の今後の展望

今後の OSS への取り組み、展望としてどのようなことが考えられますか？

Answer
当初、OSS は、商用ソフトウェアの代替品として、主に「コスト削減」や「ベンダロッ
クイン」を排除するためのツールとして活用されていました。たとえば、商用 UNIX の代
わりに Linux を活用することで、ハードウェアを商用 UNIX 専用機から Intel アーキテク
チャの PC サーバへ移行することで、大幅にコスト削減を実現することができますし、PC
サーバであれば、どのハードウェアベンダの製品でも稼働させることができるので、特定のハードウェアベンダの製品でなくてもよくなり、ベンダロックインから解放されることになります。また、データベースも同様で商用データベースから OSS のデータベースを移行することで、高額なライセンス費用を削減することが期待されました。
このように Linux や OSS のデータベースなどを活用することで、多くのメリットが得られるため、採用が進められるかに見えましたが、これらの OSS を企業のシステムに活用するためには少し時間が必要でした。日本では、2000 年代前半に日本 OSS 推進フォーラム
で、これらの OSS が企業のシステムで活用されるためにベンダの壁を乗り越え、性能や信頼性などの検証を行い、OSS の Linux やミドルウェアの機能/信頼性の向上に貢献をし、現在では、Linux やミドルウェアを企業のシステムに活用できるレベルに到達しました。
ICT は、企業の従来型の業務システムである「SoR（System of Record）439」と呼ばれる領域で活用されてきましたが、近年は、「SoE（System of Engagement)）440」と呼ばれる企業のビジネスプロセス革新や新ビジネス創造などのデジタル革新を実現する分野での利活用が進んできました。この分野では、「クラウド」や「ビッグデータ」と呼ばれる領域のソフトウェアを活用することが必要になってきます。この領域のソフトウェアは非常に多くの機能を実現することが必要であり、単一の企業で開発することは大変な困難な状況になってきました。そのような問題意識の中で、旧来のソフトウェアベンダは、当初からソフトウェアを OSS として開発する方法に変わってきました。その代表的な OSS がOpenStack です。

439
440

SoR：従来型のトランザクション処理を中心にしたミッションクリティカルな基幹システム群
SoE：顧客との関係強化を目的に最新のインターネット技術を駆使したシステム群

237

OpenStack は、2010 年に米国の Rackspace 社と NASA がそれぞれ自社利用をするために開発していたソフトウェアを OSS 化すると共に、開発の趣旨に賛同する企業を集め、”OpenStack Foundation”を設立しました。この Foundation を核にし、開発を推進することになりました。機能の開発にあたっては、Design Summit と呼ばれるカンファレン
スを実施し、オープンな環境で開発する機能について議論してきました。Design Summitと呼ばれていたカンファレンスも回数を重ねるごとに利用者が増え、それに従い Summitと名前を変え、開発内容だけではなく、活用事例なども公開する形で実施されるようになりました。このプロジェクトの興味深いところは、ソースコードの修正である「コミット」
数などの統計データを公開していることです。OpenStack にかかわる企業は、自社のセミナーでその公開されている統計データを活用し、自社がいかに OpenStack の開発に貢献しているかを競い合っています。このようにソリューションを提供するベンダは、OSS にいかに貢献しているかを競争する時代になってきました。
また、自社で開発したソフトウェアを OSS 化する事例も出てきています。ミドクラは2014 年 11 月に足掛け 5 年 25 億円を要して開発した「MidoNet」を OSS 化しました。
「MidoNet」はネットワーク仮想化のソフトウェアで、企業の基幹ネットワークとして活用されるソフトウェアです。OSS 化した理由は、米国の大手企業から「ベンチャー企業が開発したソフトウェアは、OSS でなければ導入できない」と言われたからで、OSS であれ
ば開発企業がさまざまな理由で開発が継続できなくなる事態に陥っても、コミュニティの開発者によって、機能の維持やエンハンスが可能になり、継続的に活用できるようになるからです。一方、提供した企業も公開した OSS を他社のエンジニアが検証し、その結果をブログ等で公開してくれるようになると認知度がそれまでに比べ飛躍的に向上したという事例もあり、技術の高さを証明することもできます。
このように多くの会社の開発者と一緒になって開発するスタイルは「オープンイノベー
ション」の一種といえます。従来のように自社の閉鎖的な環境の中で、開発するだけではなく、さまざまな開発者と交流を持ちながら、開発していくことが開発者にとっては重要なことになってきます。また、活用する企業の側も OSS をいかに活用するかという視点でしか、議論していませんでしたが、それだけでは不十分で、単に活用するだけではなく、
開発コミュニティに入っていき、自社で実現したいサービスに必要な機能を取り入れるための活動や信頼性向上のための活動をしなければいけないようになってきています。
このように会社や国の壁を超えてソフトウェアを開発するスタイルが今後普及していくようになります。そうなると知的財産や法務担当者だけではなく、ソフトウェア開発者も著作権やライセンスに対して深い理解が必要になってきます。
（作成日：2017 年 10 月 17 日）

238

執

筆

者
（敬称略、五十音順）

阿久沢 剛

株式会社日立製作所 システム&サービスビジネス統括本部法務部部長代理

岩井 久美子 弁護士、曾我法律事務所
岩切 美和

株式会社日立製作所 知的財産本部知財マネジメント本部技術情報管理 G
GL 部長代理岩原 将文

弁護士、水谷法律特許事務所

上沼 紫野

弁護士、虎ノ門南法律事務所

梅谷 眞人

富士ゼロックス株式会社 知的財産部 知財渉外グループ長

大内 佳子

富士通株式会社法務・コンプライアンス・知的財産本部 知的財産イノベーション統括部

奥津 宏幸

株式会社日立製作所 知的財産権本部 知財ビジネス本部部長代理

小栗 久典

弁護士、弁護士法人内田・鮫島法律事務所

片山 史英

弁護士・弁理士、虎ノ門南法律事務所

北見 かおり 東芝デジタルソリューションズ株式会社 技術統括部知的財産担当部長
野末浩志

株式会社東芝 ソフトウェア技術センターオープンソース技術部シニア
エキスパート桝井 知子

弁護士、Next 法律事務所

松島 淳也

弁護士、松島総合法律事務所

溝口 則行

TIS 株式会社 IT 基盤技術本部 OSS 推進室室長

村尾 治亮

弁護士、東啓綜合法律事務所

本永 公章

NTT データ株式会社 技術開発本部知的財産室

吉田

株式会社日立ソリューションズ 業務統括本部技術革新本部研究開発部

行男

主管技師
［協力者］
金子 広行

公認会計士、曾我法律事務所

渡邊 歩

株式会社日立ソリューションズ OSS 利活用グループ技師

239

IoT 時代における OSS の利用と法的諸問題 Q&A
平成 30 年（2018 年）発行
発行者 一般財団法人ソフトウェア情報センター
東京都港区西新橋 3-16-11 愛宕イーストビル
Tel 03-3437-3071 Fax 03-3437-3398
Email res@softic.or.jp URL HTTP://www.softic.or.jp240