外注成果物のOSSライセンス確認チェックリスト｜発注前に必ず確認すべき3つのポイント

本文

システム開発を外注する際、OSSライセンスをどこまで確認できていますか?

「開発会社に任せておけば大丈夫」——そう思っている発注担当者の方は少なくないはずです。しかし実際には、外注した成果物の中に含まれるオープンソースソフトウェア（OSS）のライセンス条件によっては、発注者側にソースコードの公開義務が生じるケースがあります。納品を受けてから問題が発覚しても、すでに本番稼働中のシステムを作り直すことは現実的ではありません。

OSSは「無料で使えるソフトウェア」として広く知られていますが、「無料」はあくまでも費用の話です。ライセンスという名の「利用条件」が必ず存在し、その条件を守らなければ著作権侵害となります。特にGPL・AGPLと呼ばれるコピーレフト型ライセンスを持つOSSを成果物に組み込んだ場合、そのシステムのソースコードを公開する義務が生じる可能性があります。これは、自社の競合優位性に関わる業務システムであっても例外ではありません。

この記事では、システム開発の発注担当者が「提案・発注前」「契約締結時」「開発中」「納品時」の各フェーズで確認すべきポイントをチェックリスト形式でまとめます。技術的な専門知識がなくても、開発会社に適切な質問ができ、自社を守る契約書を作れるようになることがゴールです。OSSライセンスの基礎から実務的なアクションまでを順を追って解説しますので、ぜひ最後までご確認ください。

OSSライセンスとは何か——発注者が知っておくべき最低限の知識

OSSライセンスは「ソフトウェアをどんな条件で使ってよいか」を定める利用許諾条件です。発注者がOSSそのものを直接使うわけではありませんが、外注先の開発会社が成果物の中にOSSを組み込む場合、そのライセンス条件は最終的に発注者にも影響します。

ここでは技術的な詳細ではなく、発注者がビジネス判断をするために必要な最小限の知識を整理します。

OSSの「無料」は「条件なし」ではない

OSSは誰でも無償で入手・利用・改変・再配布できるソフトウェアです。開発コストを抑えたい場合、開発会社がOSSを活用することは珍しくなく、提案書に「既存のOSSライブラリを活用してコストを削減します」と記載されているケースも増えています。

ただし「無料＝条件なし」ではありません。OSSには必ずライセンスが付属しており、ライセンスごとに「商用利用してよいか」「改変してよいか」「再配布する場合に何を公開しなければならないか」といった条件が異なります。

発注者が把握すべき核心は、「OSSはタダでも、使い方を間違えるとタダでは済まない」という点です。

発注者にリスクが及ぶ仕組み——受託者の違反が発注者の責任に

開発会社がOSSライセンスの条件を適切に管理せずに成果物を納品した場合、そのシステムを実際に運用・配布する発注者もリスクを負います。

具体的には次のようなシナリオが考えられます。

• GPL・AGPLライセンスのOSSが組み込まれた成果物を社内外に配布・公開した場合、ソースコードの開示義務が生じる
• ライセンス違反が判明した後、OSSの権利者から警告・差し止め請求・損害賠償請求を受ける可能性がある
• 開発会社に対して損害賠償を求めるにも、契約書にOSSに関する条項がなければ責任の所在が不明確になる

「受託者が責任をもって対処するはず」という前提は、契約書にそれが明記されていなければ根拠を持ちません。発注者側が確認の姿勢をもつことが、自社を守る第一歩です。

主要ライセンスの分類——リスク度別の3分類を覚えるだけでOK

OSSライセンスには多くの種類がありますが、発注者として把握すべきは「リスク度による3分類」だけです。技術的な条文を読む必要はありません。分類と、各分類で発注者として気をつけるべきことを押さえましょう。

低リスク：MIT・Apache 2.0——商用利用に向いている

MIT ライセンスおよび Apache 2.0 ライセンスは、最も制約が少ないライセンスです。商用利用・改変・再配布が自由に認められており、著作権表示・ライセンス文の保持のみが求められます。

発注者の観点では「特に問題なし」の分類です。開発会社に対して「できれば MIT または Apache 2.0 のOSSを中心に採用してください」と依頼することで、ライセンスリスクを大幅に軽減できます。

代表的なOSSとしては、React（MIT）、Spring Boot（Apache 2.0）などが挙げられます。

要注意：LGPL・MPL——組み込み方によって制約が変わる

LGPL（GNU Lesser General Public License）と MPL（Mozilla Public License）は、OSSの組み込み方によって制約内容が変わる「グレーゾーン」のライセンスです。

ライブラリとして動的リンクする場合は比較的自由ですが、成果物のソースコードと直接結合（静的リンク）する場合は制約が発生するケースがあります。

発注者としては「採用する場合は組み込み方を確認する」という姿勢が必要です。提案書にLGPL・MPLのOSSが含まれていたら、開発会社に「どのように組み込む予定か」を確認してください。

代表的なOSSとしては、Qt（LGPL）、Firefox（MPL）などが挙げられます。

高リスク：GPL・AGPL——ソースコード公開義務が生じる可能性

GPL（GNU General Public License）と AGPL（GNU Affero General Public License）は、コピーレフト型と呼ばれるライセンスです。このライセンスのOSSを成果物に組み込んだ場合、そのシステム全体のソースコードを同じライセンスで公開する義務が生じる可能性があります。

特に AGPL は、Webサービスやクラウドアプリケーションとして「外部に提供（ネットワーク越しに公開）」するだけで公開義務が発生します。社内利用システムでも、外部のユーザーがアクセスする形態であれば対象になり得ます。

発注者としては「GPLおよびAGPLの採用は原則禁止か、採用する場合は法務確認必須」とするルールを設けることを推奨します。

代表的なOSSとしては、Linux Kernel（GPL）、WordPress（GPL）などが挙げられます。

ライセンス分類早見表

フェーズ別チェックリスト——発注前・契約時・納品時に確認すること

OSSライセンスの確認は「発注後にまとめてやる」では間に合いません。各フェーズで確認のタイミングを設けることが重要です。

提案・発注前に確認すること

提案書を受け取った段階で、以下の項目を確認してください。この段階であれば、問題があっても要件や開発パートナーの選定を見直せます。

• 提案書・見積書に「使用予定OSSのリスト（ライセンス種別含む）」が記載されているか
• コピーレフト型ライセンス（GPL・AGPL）の採用有無と、採用する場合の影響範囲の説明があるか
• 開発会社のOSSライセンス管理プロセス（担当者・管理ツールの有無）が明確か

開発会社への確認文言例:

「本プロジェクトで使用予定のOSSのリストとライセンス種別を提案書に明記していただけますか?」

「GPLライセンスのOSSを採用する場合、ソースコード開示義務の影響範囲を具体的に説明いただけますか?」

OSSリストの提示を拒む、または「問題ありません」と説明なしで回答する開発会社は、ライセンス管理体制が不十分な可能性があります。この段階で確認姿勢を示すことで、開発会社のライセンス管理意識を高める効果もあります。

契約締結時に確認すること

契約書はOSSリスクに対する最大の防護壁です。以下の条項が契約書に含まれているか確認してください。含まれていない場合は、契約交渉の中で追加を求めてください。

• 「OSS利用には発注者の事前承認を要する」条項が明記されているか
• 「納品時にOSSリスト（SBOM: Software Bill of Materials）を提出する義務」が明記されているか
• 「OSS起因の第三者請求に対する受託者の補償義務」が記載されているか
• 知的財産権の帰属条項に「OSS由来部分を除く」旨の明記があるか

特に「納品時のSBOM提出義務」と「OSS起因の補償義務」は見落とされがちですが、後から問題が発覚した際の対処に直結する重要な条項です。

開発中に確認すること

開発が始まってからも、OSSの追加・変更が発生します。中間レビューのタイミングで以下を確認してください。

• 中間レビュー時に、提案段階から変更・追加されたOSSがないか確認する
• コピーレフト型OSSの新規追加がある場合は、内容確認と事前承認を求める

「開発が進んでいるから今さら言いにくい」と感じることがあるかもしれませんが、本番稼働後に発覚するリスクと比べれば、開発中の確認コストは微小です。承認フローを事前に決めておくと、開発会社にとっても対応しやすくなります。

納品時に確認すること

納品物の受け入れ時に、以下を確認してください。受け入れ検査のチェックリストに加えておくことを推奨します。

• SBOM（使用OSS一覧・ライセンス種別・バージョンを含む文書）を受領したか
• 成果物の配布形態（社内利用のみ・外部公開・SaaS提供など）とライセンス制約が整合しているか確認したか
• コピーレフト型OSSが含まれる場合、影響範囲が書面で確認できるか

SBOMはOSSの構成情報を記載した書類で、ソフトウェアの「部品表」に相当します。受領したSBOMをもとに、GPL・AGPLが含まれていないかを確認してください。GPL・AGPLが含まれている場合は、次のセクションで紹介する契約条項の確認と合わせて、法務部または弁護士への相談を検討してください。

開発委託契約に盛り込むべきOSSリスク対処条項

チェックリストを実行するために必要なのが、契約書への条項追加です。ここでは、発注者が最低限盛り込むべき4種類の条項を紹介します。

実際の契約書作成・交渉にあたっては、必ず弁護士への相談をお勧めします。以下はあくまで「何を目的にした条項が必要か」を把握するための参考情報です。

事前承認義務条項——OSSの変更・追加を発注者が管理する

目的: 開発中にGPL・AGPLなどのリスクの高いOSSが無断で追加されることを防ぐ

条項の内容（例）: 「受託者は、本件業務においてオープンソースソフトウェアを利用または追加する場合、事前に委託者の書面による承認を得なければならない。承認なく利用されたOSSに起因する損害は、受託者の責任とする。」

なぜ必要か: この条項がなければ、開発途中でGPLのOSSが採用されても、発注者は知る手段がありません。特に開発期間が長い案件では、当初の提案にはなかったOSSが追加されるケースが少なくありません。

OSSリスト提出義務条項——納品時に証跡を残す

目的: 納品物に含まれるOSSとそのライセンス条件を書面で確認する

条項の内容（例）: 「受託者は、成果物の納品時に、使用したすべてのオープンソースソフトウェアの名称・バージョン・ライセンス種別・出所URLを記載した一覧（SBOM）を委託者に提出しなければならない。」

なぜ必要か: SBOMの提出義務を契約書に明記することで、開発会社は自社のOSSを正確に把握した上で納品する必要が生じます。また、問題が発覚した際の証拠書類としても機能します。

違反時の責任分担・補償条項——万が一の備え

目的: OSSライセンス違反が発覚した際の費用・損害を受託者に求償できるようにする

条項の内容（例）: 「受託者の故意または過失によるOSSライセンス条件の違反に起因して委託者が第三者から請求を受けた場合、受託者はその損害（弁護士費用・対応費用を含む）を賠償しなければならない。」

なぜ必要か: ライセンス違反による訴訟・和解費用・システム修正費用は、場合によっては開発費用を大幅に上回ります。責任の所在を契約書で明確にしておくことで、万が一の場合に発注者が不当な損害を負わないようにします。

契約条項を盛り込む際の注意点

既製の契約書ひな形（情報処理推進機構・IPAが公開している「情報システム・モデル取引・契約書」等）を使用している場合、OSSに関する条項が含まれていない場合がほとんどです。以下の点に注意して交渉・追加を検討してください。

• 追加条項は「特約」または「別紙」として追加するケースが多い
• 開発会社側が難色を示す場合は、適用対象をGPL・AGPLのみに限定するなど段階的な合意を目指す
• 条項の文言は法的に拘束力のある形にする必要があるため、弁護士監修を必ず依頼する
• 既存契約の改定が難しい場合は、次回の契約更新・新規契約から適用することを検討する

まとめ——発注者が今すぐ取るべき3つのアクション

OSSライセンスのリスクは「知らなかった」では済まされません。しかし、適切なタイミングで適切な確認をすれば、発注者であっても十分に管理できます。

この記事で解説した内容を3つのアクションに集約します。

アクション1: 提案書受領時に「OSS使用リスト」を提出させる

提案書の段階で「使用予定OSSのリストとライセンス種別」を明記するよう開発会社に依頼してください。この一つの依頼が、その後のライセンス管理全体の質を高めます。

アクション2: 契約書に「事前承認・リスト提出・違反時補償」の3条項を入れる

既存の契約書にこれらの条項がない場合、次回の契約締結時から追加することを検討してください。法務部または弁護士と連携して、自社に合った文言を用意しましょう。

アクション3: GPL・AGPL含有ケースは法務部または弁護士と相談する

提案書や納品物にGPL・AGPLのOSSが含まれていた場合は、必ず専門家に確認してください。影響範囲の評価と対応策の判断には、専門的な知識が必要です。

OSSライセンスの基礎知識についてより詳しく理解したい方は、「外注成果物に潜むOSSライセンスリスク｜発注企業が知っておくべき基礎知識」もあわせてご覧ください。OSSの種類・コピーレフトの仕組み・企業が直面した実際のリスク事例を網羅的に解説しています。

信頼できるエンジニアへの開発委託をお考えの場合は、Workeeを通じてOSSライセンス管理の経験を持つエンジニアにご相談ください。発注から納品まで、ライセンスリスクを最小化した開発体制を整えるお手伝いをします。