⚠ 本書式は弁護士監修前の草稿である。監修完了まで販売・配布・公開を禁止する。 本書式は一般的な情報提供を目的としたものであり、個別・具体的な法律相談に代わるものではない。

オープンソースソフトウェア利用ポリシー

第1部: 書式本文

第1条(目的) 本ポリシーは、〇〇〇〇(以下「当社」という。)が製品及びサービスにオープンソースソフトウェア(以下「OSS」という。)を組み込む際の審査手順及び管理体制を定め、ライセンス条件違反による法的リスクを防止することを目的とする。

第2条(適用範囲) 本ポリシーは、開発部門が自社製品に組み込むすべてのOSS(直接組み込むものだけでなく、依存ライブラリとして間接的に組み込まれるものを含む。)に適用する。

第3条(OSS管理責任者の設置) 当社は、OSSの利用状況を一元的に管理する管理責任者(以下「OSS管理責任者」という。)を法務・管理部門に設置する。

第4条(組込み前の事前審査) 1. 開発部門は、新たにOSSを組み込もうとする場合、事前にOSS管理責任者に対し、OSS名、バージョン、ライセンス種別及び組込み方法(静的リンク、動的リンク、コピー&改変の別)を申請しなければならない。 2. OSS管理責任者は、当該OSSのライセンスが別紙に定める禁止ライセンス一覧に該当しないかを確認し、該当する場合は組込みを承認しない。

第5条(ライセンス種別の分類) 1. 当社は、OSSライセンスを、寛容型ライセンス(MIT、Apache License 2.0、BSD等)、弱いコピーレフト型ライセンス(LGPL、MPL等)及び強いコピーレフト型ライセンス(GPL、AGPL等)に分類する。 2. 強いコピーレフト型ライセンスのOSSを組み込む場合、原則として事業部門長及びOSS管理責任者双方の承認を要する。

第6条(著作権法上の二次的著作物の扱い) 開発部門は、OSSを改変して自社製品に組み込む場合、当該改変部分が著作権法第27条にいう翻案に該当し、組込み後の成果物全体が同法第28条にいう二次的著作物としての性質を帯びうることを踏まえ、ライセンス条件に定める表示義務及びソースコード開示義務の要否を確認しなければならない。

第7条(表示義務の履行) 開発部門は、組み込んだOSSについて、当該OSSのライセンスが要求する著作権表示及びライセンス条文の表示を、製品のマニュアル、Webサイトの謝辞ページ又はアプリ内の設定画面等、適切な箇所に掲載しなければならない。

第8条(OSSインベントリの管理) OSS管理責任者は、組み込まれたOSSの名称、バージョン、ライセンス種別及び用途を記載した一覧(以下「OSSインベントリ」という。)を作成し、四半期ごとに更新する。

第9条(脆弱性対応) 開発部門は、組み込んだOSSに関して公表された脆弱性情報を定期的に確認し、重大な脆弱性が公表された場合は速やかにアップデート又は代替措置を講じる。

第10条(第三者への配布時の追加確認) 製品を第三者に配布(販売、無償公開又はSaaS提供を含む。)する場合、開発部門は、配布形態がコピーレフト型ライセンスにおけるソースコード開示義務の発生要件(配布、ネットワーク経由の提供を含む場合はAGPL等)に該当しないかを、配布前にOSS管理責任者と確認する。

第11条(違反時の対応) 本ポリシーに違反してOSSが組み込まれたことが判明した場合、当社は速やかに当該OSSの利用を停止又は代替ライブラリへの置換を行い、必要に応じて権利者への対応を検討する。

第12条(教育及び周知) 当社は、開発部門の従業員に対し、OSSライセンスに関する研修を年1回以上実施する。

第13条(改定) 本ポリシーは、OSSライセンスに関する実務動向の変化に応じ、法務・管理部門の判断により改定することができる。

第2部: 立場別・場面別の書き換えパターン

A. 開発部門向けの修正

A-1. 事前審査の迅速化条項の追加

追加条文例:「寛容型ライセンス(別紙掲載のものに限る。)に該当するOSSについては、開発部門の判断のみで組込みを行うことができ、OSS管理責任者への申請は事後報告(組込み後1週間以内)で足りるものとする。」 一言解説: リスクの低いライセンスについてまで逐一事前承認を要求すると開発速度が損なわれるため、リスクに応じた審査プロセスの簡素化を求める修正である。

A-2. 依存関係の自動スキャンツール導入の明記

追加条文例:「開発部門は、ビルドパイプラインにOSSライセンススキャンツールを組み込み、間接依存を含めたライセンス情報を自動的に検出する体制を整備する。」 一言解説: 手作業でのOSSインベントリ管理には限界があるため、継続的インテグレーションの過程で自動検出する仕組みを求める現場側の修正である。

B. 法務・管理部門向けの修正

B-1. 強いコピーレフト型ライセンスの原則禁止の明確化

修正後:「AGPL及びこれに準ずるライセンスのOSSは、事業部門長、OSS管理責任者及び法務責任者の三者が個別に承認した場合を除き、組込みを禁止する。」 一言解説: サービス提供型のビジネスにおいてAGPLはネットワーク経由の提供にもソースコード開示義務を及ぼしうるため、法務部門は原則禁止に近い運用を求める傾向がある。

B-2. 監査及び是正措置の権限強化

追加条文例:「法務・管理部門は、OSSインベントリの正確性を確認するため、開発部門に対し年1回以上のソースコード監査(自動スキャン結果の確認を含む。)を実施する権限を有する。」 一言解説: 自己申告制のみでは漏れが生じうるため、法務部門主導での定期監査権限を明記する修正である。

第3部: 書き方と法的ポイント解説

使う場面/使ってはいけない場面 本書式は、自社製品にOSSを組み込む開発体制を持つ企業が、社内規程としてOSS利用の審査手順とライセンス管理体制を整備する場面で用いる。他方、特定のOSSの利用許諾を第三者から個別に得る場面(商用ライセンスへのデュアルライセンス切替等)には適さず、個別の契約書を締結すべきである。

根拠法令 OSSはプログラムの著作物として著作権法の保護対象であり(同法第10条第1項第9号)、その利用条件は各OSSのライセンス条文によって定められる。OSSを改変して組み込む行為は同法第27条の翻案に該当し、改変後の成果物は同法第28条の二次的著作物としての性質を持つ場合があるため、OSSライセンスが定める表示義務や派生物への同一ライセンス適用義務(コピーレフト条項)が組込み後の自社製品にも及ぶかどうかを検討する必要がある。特にGPL系のライセンスは、リンク方式(静的リンクか動的リンクか)によってコピーレフト条項の適用範囲に関する解釈が分かれるとされ、AGPLはネットワーク経由でのサービス提供のみを行いバイナリを配布しない場合であってもソースコード開示義務が生じうる点で他のGPL系ライセンスと異なる。これらはいずれも契約(ライセンス)の解釈問題であり、著作権法そのものが個別に定める規律ではないため、各OSSのライセンス条文を個別に確認することが不可欠である。

実務でよくある失敗と対策 第一に、直接組み込んだOSSのライセンスのみを確認し、依存関係を通じて間接的に組み込まれるOSS(トランジティブ依存)のライセンスを見落とす失敗がある。A-2のような自動スキャンツールの導入とOSSインベントリの継続的な更新(第8条)が対策となる。第二に、静的リンクか動的リンクかによってコピーレフト条項の適用範囲が変わりうることを認識せず、GPL系OSSを安易に組み込んでしまう失敗がある。第6条のように改変・組込み方法を申請時に明記させ、リンク方式ごとのリスク評価を行う体制が対策となる。第三に、SaaS形態でサービス提供する場合、バイナリ配布を伴わないためGPLの開示義務は及ばないと誤解し、AGPLの適用を見落とす失敗がある。第10条のように配布形態(ネットワーク経由の提供を含む)を確認する手続を組み込むことが対策となる。

コピーレフト条項の適用範囲についての解釈は個別のOSSライセンス文言や組込み方法によって異なるため、個別事案は専門家に確認することが望ましい。

第4部: 使用前チェックリスト

• [ ] OSS管理責任者及び審査フローを設置したか
• [ ] 禁止ライセンス一覧(強いコピーレフト型等)を策定したか
• [ ] 事前審査の対象と簡素化対象(寛容型ライセンス等)を区分したか
• [ ] トランジティブ依存(間接依存)のライセンス検出体制を整備したか
• [ ] リンク方式(静的・動的)ごとのコピーレフト適用リスクを評価する手順があるか
• [ ] 表示義務(著作権表示・ライセンス文の掲載)の履行方法を定めたか
• [ ] OSSインベントリの作成・更新頻度を定めたか
• [ ] 脆弱性情報の監視・対応フローを整備したか
• [ ] 第三者への配布・SaaS提供時の追加確認手続を定めたか
• [ ] 開発部門への研修計画を策定したか
• [ ] 違反判明時の是正措置(利用停止・置換)のフローを定めたか