ソフトウェアライセンスとは？OSSライセンスの種類と発注時の確認事項
システム開発を外注したとき、開発ベンダーから「OSSライセンスの確認が必要です」と言われたことはないでしょうか。あるいは、納品されたシステムの検収時に「このシステムにはGPLのOSSが含まれています」という報告を受けたものの、それが何を意味するのか分からなかった、という経験をお持ちの方もいるかもしれません。
MITライセンス、GPL、Apacheライセンス——これらの名前を聞いたことはあっても、それぞれの違いや、自社のシステムにどんな影響があるかまで把握している非エンジニアの方は多くありません。特に「GPLのソフトウェアを使った場合、自社のソースコードを公開しなければならない」というリスクは、認知されていない企業が圧倒的多数です。
IPA（独立行政法人情報処理推進機構）の調査（2024年度）によると、ユーザー企業でOSSの利用ポリシーが「存在しない」または「わからない」と回答した割合は合計で8割を超えており、OSS管理の専門組織（OSPO）を設置していない企業は約7割にのぼります（IPA「2024年度オープンソース推進レポート」）。
この記事では、システム開発の発注者・担当者として最低限知っておくべきOSSライセンスの基礎知識と、開発ベンダーへの確認事項、そして万が一のライセンス違反リスクへの対処法を、非エンジニアにも分かるよう解説します。
目次
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
こんな方におすすめです
ソフトウェアライセンスとは？著作権との関係から理解する
著作権とソフトウェアの関係
ソフトウェアは「著作物」です。プログラムのコードは文章や音楽と同様に著作権によって保護されており、著作権者（開発者・企業）の許可なく複製・改変・配布することは原則として禁止されています。
普段私たちが何気なくインストールしているアプリやソフトウェアも、著作権者が「これを使ってよいですよ」と許可しているから利用できる——というのが法律上の仕組みです。
ライセンスとは何か（利用許諾条件）
ライセンス（license）とは、著作権者がソフトウェアの利用を許可する際に設ける「条件書き」のことです。つまり「この条件を守ればソフトウェアを使ってよい」という許諾書になります。
ライセンスに定められる条件の主な例を挙げると以下の通りです。
- 著作権表示の維持: 著作者名やライセンス文を削除してはいけない
- ソースコードの公開義務: 改変した場合、ソースコードを公開しなければならない
- 特許権の許諾: ライセンス利用者に特許権の使用を認める
- 商標の使用制限: 著作者の名称・ロゴを無断で使用してはいけない
OSSライセンスが重要な理由（無料≠条件なし）
OSS（オープンソースソフトウェア）は「無償で公開されているソフトウェア」というイメージを持つ方も多いですが、「無料だから制約なく使える」わけではありません。OSSにも必ずライセンスが存在し、そのライセンスの条件を守る義務があります。
特に問題になるのは「受託開発の成果物にOSSが使われているとき」です。開発ベンダーが作ったシステムの中には、一般的に多くのOSSのライブラリや部品が組み込まれています。これらすべてのOSSのライセンス条件に違反していないかを確認することが、発注者にとっても重要な責務となります。
主要OSSライセンスの種類と商用利用への影響
OSSライセンスは大きく3種類に分類できます。それぞれの特性と商用利用への影響を理解することが、発注者としての第一歩です。
非コピーレフト型ライセンス（MIT・Apache 2.0・BSD）の特徴
非コピーレフト型ライセンスは、「制約が少なく使いやすい」ライセンスです。著作権表示を維持さえすれば、商用利用・改変・再配布が自由に行えます。
MITライセンス GitHubで最も広く使われているライセンスです。著作権表示と許諾表示を記載することを条件に、商用・非商用を問わず使用・改変・再配布が可能です。自社のシステムに組み込んでも、ソースコードを公開する義務はありません。
Apache 2.0ライセンス MITに似た寛容なライセンスですが、特許権の許諾条件が含まれている点が特徴です。Apache Hadoop、Apache Kafkaなど、エンタープライズ利用が多いOSSで採用されています。
BSDライセンス MITと同様に制約が少ないライセンスです。バリエーション（2-clause、3-clause）があります。
コピーレフト型ライセンス（GPL v2/v3・AGPL）の特徴と制約
コピーレフト型ライセンスは、「派生物にも同じライセンスを適用する義務がある」という特徴を持ちます。この性質から「感染性がある」とも呼ばれます。
GPL（GNU General Public License） GPLで公開されているソフトウェアを改変したり、自社プログラムに組み込んで配布した場合、その成果物もGPLライセンスの下でソースコードを公開する義務が生じます（フューチャー技術ブログ「OSSライセンスの基礎知識」）。
重要なのは「配布する場合」という点です。社内利用のみで外部に配布しない場合、GPLの「感染性」は通常は問題になりません。しかし、顧客に成果物を納品したり、パッケージとして販売したりする場合には注意が必要です。
AGPL（Affero General Public License） GPLをさらに強化したライセンスで、ネットワーク経由でサービスを提供する場合も「配布」とみなします。SaaS型のシステム開発では特に注意が必要です。
準コピーレフト型ライセンス（LGPL・MPL）の特徴
コピーレフト型と非コピーレフト型の中間に位置するライセンスです。
LGPL（Lesser GPL） LGPLのライブラリを「呼び出す」だけであれば、自社コードのソースコード公開義務は生じません。ただし、LGPLのライブラリ自体を改変した場合は、改変部分のソースコードを公開する義務があります。
MPL（Mozilla Public License） ファイル単位でコピーレフトが適用されます。MPLライセンスのファイルを改変した場合はそのファイルのソースコードを公開する義務がありますが、それ以外のファイルへの感染性はありません。
比較表で一目確認：ライセンス別の制約まとめ
ライセンス |
商用利用 |
ソース公開義務 |
感染性 |
典型的な用途 |
|---|---|---|---|---|
MIT |
○（自由） |
なし |
なし |
React、Vue.js、jQuery等 |
Apache 2.0 |
○（自由） |
なし |
なし |
Kubernetes、TensorFlow等 |
BSD |
○（自由） |
なし |
なし |
FreeBSD、一部の学術研究 |
LGPL |
○（条件付き） |
ライブラリ改変時のみ |
部分的 |
Qt（LGPLバージョン）等 |
GPL v2/v3 |
○（条件付き） |
配布時は必須 |
あり |
Linux kernel等 |
AGPL |
○（条件付き） |
ネット提供含む |
強い |
MongoDB Community等 |
「コピーレフト」とは何か？発注者が知るべきリスク
コピーレフトの「感染性」とは
コピーレフト（Copyleft）とは、「著作物の自由な利用・改変・再配布を認め、かつ、そこから派生した著作物についてもこれらの行為を制限してはならない」という考え方です。GPLはこのコピーレフト思想を体現した代表的なライセンスです。
コピーレフトの「感染性」をシンプルに言い換えると、「GPLのコードを使ってシステムを作り、そのシステムを他者に配布した場合、システム全体のソースコードをGPL（無償・公開）で提供する義務が生じる可能性がある」ということです。
これは企業にとって非常に重大なリスクです。自社が何年もかけて開発した独自アルゴリズムや競争力の源泉となるコードが、OSSライセンスの条件によって公開を強いられる可能性があるからです。
GPLライセンスが問題になるケース・ならないケース
問題になりやすいケース
- GPLライセンスのOSSを自社プログラムに組み込み、顧客にシステムを納品する（配布）
- GPLライセンスのOSSを改変して、その改変版を販売する
- AGPLライセンスのOSSを使ってSaaSを提供する
問題になりにくいケース
- GPLライセンスのOSSを社内システム（外部配布なし）としてのみ利用する
- GPLライセンスのOSSをビルドツールとして使用する（成果物には組み込まれない）
発注者として確認すべき点: 自社が外注で作ったシステムが、将来的に顧客へ提供されたり、パッケージ販売されたりする可能性があるかどうかを確認してください。もしそのような利用が想定される場合、GPLのOSSが含まれていると重大な問題になる可能性があります。
LGPLとGPLの違い（ライブラリ利用時の注意点）
システム開発ではOSSを「ライブラリ（部品）として呼び出す」ケースが多くあります。LGPLはこのような利用形態に配慮したライセンスで、「呼び出すだけ」なら自社コードの公開義務は生じません。
ただし、LGPLライブラリを改変した場合は、改変部分のソースコード公開が必要になります。開発ベンダーが「LGPLです」と言った場合でも、そのライブラリを改変しているかどうかを確認することが重要です。
発注者がシステム開発でライセンス確認すべき3つのポイント
発注者として実際にどんな確認をすれば良いのかを、具体的なアクションとして整理します。
利用OSSの一覧（SBOM）の提出を要求する
SBOM（Software Bill of Materials：ソフトウェア部品表）とは、システムに含まれるすべてのOSSとそのライセンス情報を記載した一覧表です。経済産業省も「SBOM導入に関する手引き」を公表し、ソフトウェアの透明性確保を推進しています（経済産業省「SBOMの導入に関する手引 ver 2.0」）。
発注時のアクション: 開発ベンダーとの契約書や仕様書に「納品物のSBOM（利用OSSの一覧）を提出すること」を明記してください。SBOMが提出されたら、コピーレフト型ライセンス（GPL・AGPL等）が含まれていないかを確認します。
技術的な詳細は分からなくても、「GPLのOSSが含まれているか」「含まれている場合はどのように使われているか」を確認するだけで、多くのリスクに対処できます。
コピーレフト型ライセンスの使われ方を確認する
SBOMにGPLまたはAGPLのOSSが含まれていた場合、そのOSSがどのように使われているかを確認します。確認すべき主な点は以下の2点です。
- 配布（納品）の有無: 完成したシステムは外部（顧客や第三者）に配布・提供されるか
- 組み込み方法: GPLのOSSをシステムに「直接組み込んでいる」のか「独立したサービスとして呼び出しているだけ」なのか
「社内利用のみ」「配布しない」という場合には、GPLの感染性は一般的に問題になりません。一方、顧客向けに提供するシステムにGPLが含まれている場合は、法的リスクが高まります。
開発ベンダーに「このOSSをこのように使った場合、GPLの条件に抵触しないか？」と確認し、必要に応じて弁護士や専門家に相談することをお勧めします。
契約書にライセンス遵守条項を盛り込む
システム開発の発注契約に、以下のような条項を加えることで、ライセンス管理上の責任を明確化できます。
- OSSの申告義務: 「受注者は利用するOSSの種類とライセンスを発注者に報告すること」
- ライセンス遵守の保証: 「受注者は利用するOSSのライセンス条件を遵守することを保証する」
- 問題発生時の対応: 「ライセンス違反が発覚した場合は、受注者の費用と責任において対応する」
このような条項を事前に契約書に含めておくことで、万が一ライセンス問題が発生した際の責任範囲が明確になります。
ライセンス違反が発生したら？リスクと対処法
ライセンス違反の主なリスク（法的リスク・レピュテーションリスク）
OSSライセンスに違反した場合、主に以下のリスクが生じます。
著作権侵害リスク ライセンス条件に違反することは著作権の侵害にあたります。著作権者は訴訟を提起でき、損害賠償請求の対象となります。GPL違反の場合、違反が発覚してもすぐに提訴されるわけではなく、まず修正を求める警告が届くのが一般的です。ただし、是正されない場合は法的措置に発展します。
ソースコード公開の強制リスク コピーレフト型ライセンスに違反した場合、違反を是正するために自社のソースコードをすべて公開しなければならなくなる可能性があります。これは企業の競争優位を失うリスクであり、特に自社独自の技術を含むシステムでは深刻な影響を与えます。
レピュテーションリスク OSSコミュニティへの影響や、ライセンス違反企業としての報道により、企業の信頼性が大きく低下する可能性があります。
違反が発覚した場合の対応手順
万が一ライセンス違反の指摘を受けた場合、以下の手順で対応します。
- パニックにならず事実確認: まずどのライセンスのどの条件に違反しているかを具体的に確認する
- 開発ベンダーへの連絡: 納品物のライセンス問題の場合、開発ベンダーに即座に連絡し協力を求める
- 法的専門家への相談: OSSライセンスに詳しい弁護士や専門家に相談する
- 是正対応: 問題のOSSを代替品に変更するか、または適切なライセンス条件を満たす対応を行う
- 著作権者との対話: 警告を受けた場合は誠実に対応し、是正の意思と計画を示す
予防策：開発段階から取り組むライセンス管理
最善の対策は「発生させないこと」です。そのためには：
- 発注前の確認: 開発ベンダーのOSSライセンス管理体制を事前に確認する
- 契約書への条項追加: 上述のライセンス遵守条項を契約書に盛り込む
- 定期的なSBOMの更新: システムの保守・機能追加のたびに利用OSSのリストを更新してもらう
- コピーレフト型OSSの採用基準の明確化: GPLのOSSを使う場合は、事前に発注者に許諾を得るルールを設ける
まとめ：発注者がOSSライセンスで押さえるべき要点
この記事でお伝えしてきた内容を要約します。
ソフトウェアライセンスとは、著作権者がソフトウェアの利用条件を定めた許諾書です。OSSは無料で使えますが、ライセンスの条件を守る義務があります。
OSSライセンスの主要な分類は、制約が少ない「非コピーレフト型」（MIT・Apache・BSD）と、派生物にも同じライセンスを適用する「コピーレフト型」（GPL・AGPL）、その中間の「準コピーレフト型」（LGPL・MPL）の3種類です。
発注者として最も重要なことは、以下の3点です：
- SBOMの提出を求める：利用OSSの一覧と各ライセンスを納品物と一緒に提出してもらう
- コピーレフト型OSSの使われ方を確認する：特にGPL・AGPLが含まれる場合は、配布形態と組み込み方法を確認する
- 契約書にライセンス遵守条項を盛り込む：問題発生時の責任範囲を明確にしておく
システム開発を外注する際のライセンス管理は、一見技術的な話のように見えますが、実は発注者としても把握すべきリスク管理の重要な一環です。開発ベンダーと適切にコミュニケーションを取りながら、安全なシステム開発を進めてください。
ライセンス管理に限らず、システム開発の発注・受注に関わる契約上の注意点については、NDA（秘密保持契約）とは何かも合わせてご覧ください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
