「コストと開発期間を圧縮するためにオープンソースを活用します」——開発会社の提案書でこの一文を目にして、漠然とした不安を覚えたことはないでしょうか。「無料で使えるなら問題ない」と受け止めていいのか、それとも何か落とし穴があるのか。同僚から「GPL は危ないらしい」と聞いた記憶はあるけれど、何がどう危ないのかまでは説明できない。法務部に確認されても答えに窮してしまう。そんな状況に置かれている発注者の方は少なくありません。
オープンソースソフトウェア（以下、OSS）の活用は、現代のシステム開発で避けて通れません。世界的にもソフトウェアの約 9 割が何らかの OSS を含んでいるとされ、ゼロから自社開発するよりも品質・スピード・コストの面で圧倒的に有利だからです。問題は、OSS の「無料」が金銭面のことだけを意味しており、利用条件として様々な義務が課されている、という事実が発注者側に十分理解されていない点にあります。
特にコピーレフト型と呼ばれるライセンス（代表例は GPL）は、組み込み方によっては自社の業務システムのソースコードまで外部に公開しなければならない事態を引き起こします。実際、Cisco や Skype、Vizio といった世界的な企業がこのリスクを軽視し、訴訟や差止命令、ソースコード開示命令に発展した事例が複数存在します。これは技術者個人ではなく、発注した企業そのものの経営問題です。
本記事では、開発会社に対して「OSS を使います」と言われた発注者が、(1) OSS とライセンスの基本的な仕組み、(2) 判断すべき 3 つのライセンス分類、(3) コピーレフトの本当の怖さを実例で理解、(4) 開発会社への確認チェックリスト、(5) 開発委託契約に盛り込むべき具体条項、を順を追って理解できるよう解説します。技術的な細部や法律論には深入りせず、発注者が自分の業務判断と契約交渉に使える形に整理しました。
読み終えた頃には、開発会社に「使用予定の OSS リストとそれぞれのライセンス分類を提出してください」と落ち着いて要求でき、契約書に何を盛り込むべきかを法務部と相談できる状態になっているはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
オープンソースソフトウェア（OSS）とは何か
OSS のリスクを語る前に、そもそも OSS とは何か、なぜ「無料」だけで判断してはいけないのかを整理しておきましょう。発注者がつまずきやすい 3 つの誤解を、ここで先に解いておきます。
OSSの定義と「無料」の意味
OSS（オープンソースソフトウェア）とは、ソースコード（プログラムの設計図にあたる文字列）が公開されていて、誰でも自由に入手・利用・改変・再配布できるソフトウェアの総称です。LinuxやMySQL、React、TensorFlow など、ビジネスシステムの裏側で動いている主要なソフトウェアの多くが OSS です。
ここで重要なのは、「無料で使える」が金銭的にライセンス料が不要であることを指しているだけで、「自由に何でもしてよい」という意味ではない、という点です。OSS には必ず「ライセンス」と呼ばれる利用条件が付随しており、利用者はその条件を守ることを前提に無償で使える、というのが本来の構造です。
たとえば「商用利用は OK だが、改変版を配布する場合はソースコードも公開すること」「クレジット表記を入れること」「特許権の主張を放棄すること」など、ライセンスの種類によって課される義務は様々です。これを軽視すると、後述するように経営上の重大なリスクに発展します。
OSSは誰のもの？著作権と利用許諾の関係
OSS は無料で公開されていますが、著作権が放棄されているわけではありません。各 OSS には開発者・コミュニティ・財団といった「著作権者」が存在し、彼らが「このライセンス条件で使ってよい」と利用許諾を与えている、という形をとっています。
これは、市販ソフトウェアを購入する際に「使用許諾契約書」に同意するのと、構造としては同じです。違うのは、許諾が「無償」で、かつ条件として「ソースコード開示」や「クレジット表記」が要求される点です。
つまり OSS を使うということは、著作権者が定めた利用条件に「同意した」ことになります。これを破ると、著作権侵害として法的責任を問われる可能性があります。
ライセンスは「契約」と同等の効力を持つ
OSS ライセンスは、形式的には「ライセンス」（利用許諾）ですが、実務的には契約と同等の効力を持つと扱われています。日本の著作権法の下でも、ライセンス条件に違反した利用は著作権侵害に該当しうると解釈されており、海外でも訴訟や差止命令の根拠として実際に機能してきました。
「無料だから訴えられない」「個人が公開しているものだから問題視されない」というのは大きな誤解です。後述するように、世界的な大企業が OSS ライセンス違反で訴えられ、ソースコードの開示や賠償金の支払いを命じられた実例が複数あります。
この前提を踏まえた上で、では具体的にどのライセンスにどんな義務があるのかを、次のセクションで整理していきます。
発注者が知っておくべき主要OSSライセンスの種類
OSS ライセンスは細かく分けると 200 種類以上ありますが、発注者の判断に必要な分類は実は 3 つで十分です。義務の強さによって「寛容型」「準コピーレフト型」「コピーレフト型」に分けて理解しましょう。
寛容型ライセンス（MIT・Apache 2.0・BSD）— 商用利用しやすい
最も使い勝手が良く、発注者が安心して使いやすいのが寛容型（パーミッシブ型）と呼ばれるライセンスです。代表例は MIT License、Apache License 2.0、BSD License です。
このグループのライセンスは「著作権表示とライセンス文を残してくれれば、商用・改変・再配布を自由にしてよい」という、非常にゆるやかな条件です。改変したコードや、それを組み込んだ自社製品のソースコードを公開する義務はありません。
代表的な OSS としては、JavaScript フレームワークの React（MIT）、データ処理ライブラリの NumPy（BSD）、Web サーバーの Apache HTTP Server（Apache 2.0）などがあります。これらを業務システムに組み込んでパッケージ販売する場合でも、ソースコードを開示する義務は発生しません。
ただし「義務がない」のではなく「義務が軽い」だけです。著作権表記・ライセンス文の同梱は必須ですし、Apache 2.0 には特許関連の条項もあります。完全に何もしなくていいわけではない点には注意してください。
準コピーレフト型ライセンス（LGPL・MPL）— 部分的に制約あり
寛容型とコピーレフト型の中間に位置するのが、準コピーレフト型と呼ばれるグループです。代表例は LGPL（Lesser GPL）、MPL（Mozilla Public License）です。
このグループの特徴は、「OSS そのものを改変した場合はソースコード開示が必要だが、OSS をライブラリとして外部から呼び出すだけなら自社コードの公開義務は発生しない」という、限定的な条件です。
たとえば LGPL でライセンスされたライブラリを、自社の業務システムから「動的リンク」と呼ばれる方式で呼び出して使う場合、自社コードは LGPL の影響を受けません。しかしライブラリ自体に手を加えてバグ修正や機能拡張をした場合、その改変部分は LGPL の条件に従って公開する必要があります。
この「動的リンク」「静的リンク」「改変したかどうか」といった区別は技術的に微妙な判断を要するため、発注者単独で判断するのは現実的ではありません。準コピーレフト型のライブラリを使う計画がある場合は、開発会社に組み込み方式を必ず確認し、必要に応じて法務や専門家に相談すべき領域です。
コピーレフト型ライセンス（GPL・AGPL）— 強い制約と公開義務
最も注意が必要なのがコピーレフト型と呼ばれるライセンスです。代表例は GPL（GNU General Public License）と AGPL（GNU Affero General Public License）です。
このグループの最大の特徴は、「GPL のコードを組み込んだソフトウェアを配布する場合、自社が書いたコードも含めてすべてのソースコードを GPL で公開しなければならない」というルール（コピーレフト）にあります。これは、しばしば「ライセンスの感染性」とも呼ばれる強力な義務です。
代表的な OSS としては、Linux カーネル、WordPress（GPL v2）、MongoDB（旧バージョン、現在は独自ライセンスへ移行）などがあります。AGPL はさらに強力で、Web サービス（SaaS）として提供する場合も「ネットワーク越しに利用させる行為」を配布とみなし、ソースコード公開を要求します。代表例は MongoDB（旧 AGPL）、Grafana（旧 AGPL）などです。
GPL/AGPL のリスクは、発注者にとって最も切実な経営リスクです。詳しくは次のセクションで具体例とともに解説します。
一覧で比較する主要OSSライセンス
ここまでの 3 分類を、発注者が実務で参照できる一覧表にまとめます。
分類 | 代表ライセンス | 代表OSS | 商用利用 | 改変版の配布 | 自社コード公開義務 | 発注者にとっての扱いやすさ |
|---|---|---|---|---|---|---|
寛容型 | MIT, Apache 2.0, BSD | React, NumPy, Apache HTTP | 可 | 可 | なし（著作権表記は必要） | 高 |
準コピーレフト型 | LGPL, MPL | glibc, Firefox 関連ライブラリ | 可 | 可 | 改変部分のみ／組み込み方式による | 中（要確認） |
コピーレフト型（配布） | GPL v2, GPL v3 | Linux カーネル, WordPress | 可（条件あり） | 可（GPLで公開） | 全体に及ぶ | 低（要慎重判断） |
コピーレフト型（ネット越し） | AGPL v3 | MongoDB（旧）, Grafana（旧） | 可（条件あり） | 可（AGPLで公開） | SaaS提供時も対象 | 低（要慎重判断） |
この表だけで判断するのではなく、開発会社が実際にどう組み込もうとしているかをセットで確認することが重要です。「LGPL だから安全」「GPL だから危険」と二者択一で判断できないケースもあるため、次の章で具体的なリスクシナリオを見ていきましょう。
GPLのコピーレフトが発注者にもたらす最大のリスク
ここからが本記事の核心です。コピーレフトのリスクは、「自社の業務システムのソースコードが、思いがけず外部に公開する義務を負う」という、極めて具体的な経営リスクとして現れます。抽象論ではなく、実際に起きた違反事例を見ながら腹落ちしていきましょう。
コピーレフトとは何か（発注者向けの平易な説明）
コピーレフト（Copyleft）とは、著作権（Copyright）に対する皮肉から生まれた造語で、「このソフトウェアを使って作られた派生物にも、同じ自由を与えなければならない」というルールを指します。
発注者の言葉に翻訳すると、こうなります——「GPL のコードを組み込んだソフトウェアを配布する場合、自社で書いた部分も含めて、すべてのソースコードを GPL の条件で公開しなければならない」。
ここでの「組み込んだ」とは、たとえば GPL のライブラリを取り込んで、それを利用するコードを書いて配布する、という技術的な操作を指します。発注者が知っておくべきポイントは、「GPL コードを 1 行でも自社製品に取り込んで配布すると、自社の独自コードも含めて GPL の制約に巻き込まれる可能性がある」という点です。
これは「ソースコードを盗まれる」のではなく、「自分から公開する義務を負う」状態を指します。法的に強制力を持つ義務であり、違反すれば著作権侵害として訴えられる可能性があります。
パッケージ配布する場合の影響（顧客にソースコードを開示する義務）
最も典型的なリスクシナリオが、「自社の業務システムやハードウェア製品にコピーレフト型 OSS を組み込んで顧客に納品・販売する」ケースです。
たとえば家電製品や IoT 機器のファームウェアに Linux カーネルや GPL ライブラリを組み込んで販売すると、購入した顧客に対して「このファームウェアのすべてのソースコードを請求があれば開示する」義務が発生します。これは、自社が独自に開発した独自機能や、競争優位の源泉となるロジックも含まれる場合があります。
「顧客が請求してこなければいいのでは？」という反論もあり得ますが、実務上は競合他社や OSS 監視団体（Software Freedom Conservancy 等）が請求するケースが多く、結果として競合に自社の実装が筒抜けになるリスクがあります。
SaaS・社内利用の場合の影響（AGPLに注意）
「自社では SaaS（Web サービス）として提供するだけで、お客様にソフトウェアを配布しないから GPL のリスクはない」——これも一面では正しい理解ですが、AGPL を使う場合は話が別です。
AGPL は、GPL の「配布しなければ公開義務は発生しない」という抜け穴（SaaS ループホール）を塞ぐために作られたライセンスです。AGPL を組み込んだソフトウェアをネットワーク越しに利用させた場合、利用者に対してソースコードを公開する義務が発生します（AGPL Section 13）。
具体的には、Web サービスのバックエンドで AGPL ライセンスのデータベースや分析ツールを改変して使っている場合、その改変部分を含むソースコードを、エンドユーザー（サービスの利用者）に対して開示する必要があります。
このため、SaaS 事業者にとって AGPL は GPL より厄介な存在です。「SaaS だから安全」と判断するのは禁物で、開発会社が AGPL ライセンスのソフトウェアを使う計画がある場合は、組み込み方式と改変有無を必ず確認してください。
なお、社内利用（社外に提供しない、純粋に内部業務だけで使う）であれば、GPL も AGPL も基本的には公開義務は発生しません。配布も提供もしていないからです。ただし、関連会社への提供や、業務委託先への提供が「配布」と解釈される可能性もあり、実務判断は慎重に行う必要があります。
実際に起きた違反事例から学ぶ
抽象論では危機感が湧きにくいので、実際に世界的企業が GPL 違反で問題化した事例を見ていきましょう。いずれも「自社には関係ない」とは言えない規模・業種の企業です。
事例1: Cisco / Linksys（米国・2008年）
ネットワーク機器大手のCiscoは、買収した Linksys ブランドのルーター製品に Linux カーネルや GCC、GNU C ライブラリなど GPL/LGPL ライセンスの OSS を組み込んでいました。Free Software Foundation（FSF）は 2008 年、Cisco が GPL の条件（ソースコード提供義務など）を遵守していないとして訴訟を提起しました（Free Software Foundation, Inc. v. Cisco Systems, Inc.）。
2009 年に和解が成立し、Cisco は (1) Linksys ブランド向けに「フリーソフトウェア・ディレクター」を新たに任命してライセンス遵守体制を構築すること、(2) FSF への財政的貢献、(3) 製品に組み込まれた OSS のソースコードを Web サイトで継続的に公開すること、に応じました（FSF Settles Suit Against Cisco）。
教訓: 大企業であっても、OSS 管理体制を専門のポジションで組織的に運用しなければ違反は防げないこと、違反すると公開義務だけでなく組織体制まで踏み込んだ対応を求められること、を示しています。
事例2: Skype（ドイツ・2007年）
通話サービスの Skype（当時の運営会社はルクセンブルク籍）は、Linux ベースの VoIP 電話「SMCWSKP100」を販売していましたが、製品に Linux カーネルのソースコードを十分な形で提供していなかったため、GPL の権利行使団体 gpl-violations.org（Harald Welte 主宰）がミュンヘン地方裁判所に提訴し、GPL 違反と判断されました（A German court held Skype responsible for having failed to meet GPL terms）。
Skype はパッケージに「ソースコード入手用 URL を記載したフライヤー」を後から同梱して対応しようとしましたが、裁判所はこれを GPL 第 3 条に違反すると判断しました。Skype は控訴したものの後に取り下げ、結果として下級審の判断が確定しました（Skype Withdraws Appeal Case and GPL Wins）。
教訓: 「URL の記載で済ませよう」「後付けで対応すれば許される」という安易な対応は通用しないこと、裁判所が GPL の文言を厳格に解釈すること、を示しています。
事例3: Vizio（米国・2021年〜）
テレビメーカーの Vizio は、SmartCast と呼ばれるスマートテレビのソフトウェア基盤に Linux カーネルなど GPLv2/LGPLv2.1 ライセンスの OSS を使用していました。Software Freedom Conservancy（SFC）は 2021 年、Vizio に対して SmartCast のソースコード公開を求める訴訟をカリフォルニア州で提起しました（TV maker Vizio sued for GPL infringement）。
この訴訟の特徴は、SFC が「著作権者」としてではなく、「ソフトウェアの受領者（第三受益者）」として GPL の履行を求めた点にあります。つまり、製品の購入者が「GPL の受益者」として開発元にソースコード提供を請求できる、という新しい法的アプローチが認められつつあります（SFC v. Vizio survives motion for summary judgment）。2025 年 12 月にはカリフォルニア州上級裁判所の判事が Vizio に対しソースコード提供を命じる暫定的判断を示しました（California Judge Tentatively Orders Vizio to Release SmartCast Source Code）。
教訓: GPL 違反を訴える権利が「著作権者」だけでなく「ソフトウェアの受領者」にも認められる流れにあること、製品を購入したエンドユーザーやその支援団体が訴訟主体となりうること、を示しています。発注者にとっては、エンドユーザーからの請求リスクが現実的に高まっていることを意味します。
これらの事例に共通するのは、「OSS を組み込んで配布する」という、現代のソフトウェア開発でごく一般的な行為が、ライセンスを軽視した結果として大きな法的・経営的問題に発展した、という点です。自社が違反企業になるリスクは、規模を問わず存在します。
発注者が確認すべきOSSリスクのチェックポイント
リスクの全体像を理解したら、次は「発注者として明日から何をすればよいか」です。開発会社任せにせず、発注者側から主導権を持ってチェックすべきポイントを段階ごとに整理します。
提案段階で確認すること
開発会社から提案書を受け取った段階で、まず以下を確認してください。
- 使用予定の OSS リストを提出してもらう: 「コストと開発期間の圧縮のために OSS を活用します」と書かれていたら、具体的にどの OSS をどう使うのかを書面で出してもらいます。最低限、OSS 名・バージョン・ライセンス種別の3点セットを要求しましょう。
- コピーレフト型 OSS の有無を確認する: リストに GPL や AGPL のライセンスが含まれていないかを確認します。含まれている場合、組み込み方式（動的リンク／静的リンク／改変の有無）も合わせて聞いてください。
- 配布形態を整合させる: 自社で開発するシステムが「パッケージ販売」「SaaS」「社内利用のみ」のどれに該当するかを開発会社と共通認識にし、その形態でリスクとなるライセンスが含まれていないかを確認します。
提案段階でこれを確認することで、後から「GPL を使っているのを知らなかった」という事態を防げます。
契約締結時に確認すること
提案を受けて契約を締結する段階では、契約条項として OSS リスクへの対処を盛り込みます。具体的な条項案は次のセクションで紹介しますが、ここでは合意すべきポイントを整理します。
- OSS 利用には発注者の事前承認を要する旨を合意する: 開発期間中に新たな OSS を組み込む際は、発注者の事前承認を取ることを契約上の義務とします。
- 使用 OSS リスト提出義務を明文化する: 納品時に使用 OSS のリストとライセンス分類を書面で提出してもらう義務を契約条項として明記します。
- 違反時の責任分担を明確にする: 開発会社が OSS ライセンスに違反した結果として発注者に損害が生じた場合、開発会社が補償する旨を契約に盛り込みます。
これらは契約交渉時に最初から提示しておくと、開発会社側も納得感を持って合意しやすくなります。後から追加するより、最初から含めておく方が摩擦が少なく済みます。
納品時に確認すること
開発が完了して納品を受ける段階では、以下を必ず確認します。
- SBOM（ソフトウェア部品表）の受領: 納品物に組み込まれている OSS の一覧を、Software Bill of Materials（SBOM）という形式で提出してもらいます。これはサプライチェーンセキュリティの観点からも、近年強く推奨されている納品物です。
- ライセンス一覧と組み込み方式の整合性を確認: 提案・契約段階で合意した OSS リストと、実際の納品物に含まれる OSS が一致しているかを確認します。新たに追加された OSS があれば、契約上の事前承認手続きが守られていたかを検証します。
- ライセンス義務の履行状況を確認: クレジット表記、ライセンス文の同梱、ソースコード提供方法（GPL の場合）など、各 OSS のライセンス義務がどう履行されているかを確認します。
開発会社への確認質問テンプレート
最後に、発注者がそのまま開発会社に投げかけられる質問テンプレートを示します。これをコピーして使い、回答を書面で受領してください。
【OSS 利用に関する確認事項】
1. 本プロジェクトで使用予定の OSS の一覧（OSS名・バージョン・ライセンス種別）を提出してください。
2. 上記のうち、GPL/LGPL/AGPL/MPL など、コピーレフト型または準コピーレフト型に
分類されるライセンスのものがあれば、組み込み方式（動的リンク／静的リンク／改変有無）と、
そのライセンス要件への対応方針を説明してください。
3. 本プロジェクトの最終納品形態（パッケージ販売／SaaS／社内利用／その他）に対して、
使用予定 OSS のライセンス条件が抵触する可能性はありますか。あればその内容を説明してください。
4. 納品時に SBOM（ソフトウェア部品表）を提供いただけますか。提供形式（SPDX, CycloneDX 等）も
明示してください。
5. 開発期間中に新たな OSS を追加で利用する必要が生じた場合、発注者への事前承認手続きを
遵守できますか。
6. OSS ライセンス違反が原因で発注者に第三者から請求・訴訟があった場合の責任分担に
ついての貴社の見解を教えてください。
質問項目を絞ってもよいですが、最低でも 1〜3 は必ず確認してください。回答を書面で残すことが、後の交渉・トラブル対応で重要な証拠となります。
開発委託契約に盛り込むべきOSSリスク対処条項
提案・納品時のチェックを補完するのが、契約書での明文化です。ここでは契約書に盛り込むべき 4 種類の条項について、参考レベルの文例を示します。
重要な注意: 以下に示す文例はあくまで参考であり、実際の契約書作成にあたっては必ず弁護士または法務部門の確認を受けてください。契約条項は個別の取引内容・自社のリスク許容度・相手方との力関係などを踏まえて調整する必要があり、本記事の文例をそのまま使用することは推奨しません。本記事は、発注者が法務部や顧問弁護士と相談する際の「論点提示の出発点」として活用してください。
事前承認義務の条項例
開発会社が独断で OSS を組み込むことを防ぐ条項です。
（OSSの利用）
第○条 受託者は、本契約に基づく開発業務において
オープンソースソフトウェア（以下「OSS」という）を
利用する場合、利用予定のOSS名、バージョン、
ライセンス種別、組み込み方式を事前に書面（電子メールを含む）で
委託者に通知し、委託者の承認を得るものとする。
ポイントは、「事前承認」を要件にしている点と、「組み込み方式」まで明示させている点です。承認プロセスを設けることで、発注者側がリスク評価する機会を確実に確保できます。
使用OSSリスト提出義務の条項例
納品時の OSS リスト提出を義務化する条項です。
（OSS利用状況の報告）
第○条 受託者は、納品物に含まれるすべてのOSSについて、
OSS名、バージョン、ライセンス種別、入手元（URL等）、
ライセンス条件の履行状況（クレジット表記・ソースコード提供方法等）を
記載した一覧表を、納品時に委託者に提出するものとする。
2 委託者の要求があった場合、受託者はSBOM（ソフトウェア部品表）を
SPDXまたはCycloneDX等の標準形式で提供するものとする。
SBOM の提供方式（SPDX, CycloneDX）まで明示しておくと、後で受領形式で揉めることを防げます。SBOM はサプライチェーンセキュリティの観点からも各国規制で重要性が高まっており、契約に盛り込むメリットは大きいです。
違反時の責任分担・補償条項例
OSS ライセンス違反が起きた場合の責任分担を明確化する条項です。
（OSSライセンス違反に関する責任）
第○条 受託者は、納品物に含まれるOSSのライセンス条件を
すべて遵守したものを納品することを保証する。
2 受託者がOSSのライセンス条件に違反したことに起因して、
委託者が第三者から請求・訴訟・差止め等を受けた場合、
受託者は委託者を防御し、委託者に生じた損害
（弁護士費用、和解金、賠償金、ソースコード公開によって生じる損害等）を
補償するものとする。
ポイントは、「弁護士費用」「ソースコード公開によって生じる損害」まで補償範囲に含めている点です。実際の違反事例（Cisco・Skype・Vizio）で問題化したコストの多くは、訴訟対応費用とソースコード開示に伴う競争優位の喪失です。
契約条項を作る際の注意点
上記の文例を契約書に組み込む際の注意点を整理します。
- 必ず弁護士または法務部門の確認を受ける: 契約条項は個別の取引内容に応じて調整が必要です。本記事の文例をそのまま使うのではなく、自社の状況に合わせて専門家がチューニングしたものを使ってください。
- 開発会社との力関係を考慮する: 受託者側が小規模な会社の場合、補償条項を強く要求すると契約自体が成立しないリスクもあります。リスクの大きさと開発会社の規模・実績のバランスを見て、現実的な合意点を探ることが重要です。
- 既存の開発委託契約書テンプレートに追記する形が現実的: 契約全体を作り直すのではなく、既存の業務委託契約や開発委託契約のテンプレートに「OSS 条項」を追加する形が運用上スムーズです。
- 保証範囲・補償上限の設定を検討する: 補償条項は受託者にとって重い義務なので、補償上限額（例: 契約金額の○倍まで）を設定することで、双方が現実的に合意できる落としどころを作れる場合があります。
OSS リスクへの契約上の対処は、請負契約・準委任契約の違いの理解や、NDA（秘密保持契約）の実務知識、ISMS認証（ISO27001）取得企業の活用メリットと並ぶ、開発委託における重要な契約リスク管理項目です。関連する契約リスクや情報資産保護の論点と合わせて、社内の契約管理ルールとして整備していくことをおすすめします。
まとめ：発注者が今すぐできる3つのアクション
ここまで、OSS の基本、ライセンス分類、コピーレフトのリスク、確認チェックポイント、契約条項を一通り解説してきました。最後に、発注者として明日から取れる 3 つのアクションに集約します。
アクション1: 開発会社から「使用 OSS のリスト」と「ライセンス分類」を必ず受領する
提案段階・契約段階・納品段階の 3 つのタイミングで、OSS リストとライセンス種別を書面で受領してください。リスト化することで、社内の法務やセキュリティ担当者とリスク評価ができる状態になります。
アクション2: 契約書に「OSS 事前承認・リスト提出・違反時責任」の 3 条項を盛り込む
開発委託契約書に、(1) OSS 利用の事前承認義務、(2) 使用 OSS リスト・SBOM 提出義務、(3) ライセンス違反時の補償義務、の 3 つを最低限盛り込んでください。実際の文言は弁護士・法務部門と相談して調整するのが基本ですが、論点として 3 つを必ず議題に乗せることが重要です。
アクション3: GPL/AGPL の組み込み可否は法務と相談して判断する
寛容型（MIT・Apache・BSD）の OSS は基本的に発注者の判断で進めて問題ありません。準コピーレフト型・コピーレフト型（LGPL・MPL・GPL・AGPL）が含まれる場合は、組み込み方式と配布形態の組み合わせを開発会社から確認した上で、法務部門や顧問弁護士と相談して判断してください。「使ってはいけない」ではなく「使い方次第」というのが OSS の世界の基本的な作法です。
OSS は現代のシステム開発に欠かせない強力な武器ですが、ライセンスを軽視すれば経営リスクに直結します。逆に言えば、ライセンスを理解した上で適切に管理できれば、コスト・スピード・品質のすべてで大きな恩恵を受けられます。本記事をきっかけに、社内で OSS 管理ルールを整備し、開発会社との健全なパートナーシップを築いていきましょう。
関連記事
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
