ソフトウェアライセンス 種類【2026年版】システム開発で確認すべき選び方

はじめに

ソフトウェアライセンス 種類を理解する目的は、法律用語を暗記することではありません。システム開発で使うコード、ライブラリ、SaaS、画像、フォント、データを、どの範囲で利用できるかを確認し、後から公開停止や作り直しにならないようにすることです。

2026年時点では、OSSライブラリ、API、生成AIツール、クラウドSaaS、商用テンプレートを組み合わせて開発するケースが増えています。1つのアプリの中に、MIT、Apache、GPL、商用利用規約、Creative Commons、独自契約が混在することも珍しくありません。

特に受託開発では、開発会社が使う部品と、顧客へ納品する成果物を分けて考える必要があります。開発中だけ使うツール、本番環境に組み込むライブラリ、顧客が契約を引き継ぐSaaSでは、確認すべき条件が変わります。

この記事は法律判断そのものを代替するものではありません。実務上の確認漏れを減らすために、開発前にどの範囲を棚卸しし、どのタイミングで専門家へ確認すべきかを整理する記事です。

発注側にとっても、ライセンス確認は他人事ではありません。納品後に運用するのは発注者であり、外部公開、機能追加、別会社への保守移管を行う場面で、利用条件を説明できる状態が必要になります。

ライセンス確認は、開発の最後に行うと手戻りが大きくなります。設計時点で、何を使うか、誰が権利を持つか、納品後に再利用できるか、顧客が外部公開できるかを整理する必要があります。この記事では、代表的なライセンスの種類と、受託開発で確認すべき実務ポイントを整理します。

ソフトウェアライセンスで確認する範囲

ライセンス確認は、OSSだけを見れば終わりではありません。業務システムでは、UIライブラリ、バックエンドのパッケージ、外部API、画像素材、フォント、地図、決済、メール配信、分析ツールまで確認対象になります。

対象	例	主な確認点
OSSライブラリ	MIT、Apache、GPL	表示義務、改変、再配布、ソース公開
商用ソフト	有料SDK、業務用部品	利用人数、用途、再配布可否
SaaS/API	認証、決済、地図、AI	利用規約、データ利用、商用利用
素材・フォント	画像、アイコン、Webフォント	クレジット、改変、商用利用
データ	統計、住所、業界DB	二次利用、公開範囲、更新条件

最初に確認すべきなのは、成果物に組み込むものと、開発中だけ使うものを分けることです。本番環境に含まれるものほど、影響範囲が大きくなります。

OSSライセンスの代表的な種類

OSSライセンスは、パーミッシブ型とコピーレフト型に分けると理解しやすくなります。MITやBSDは比較的制約が少なく、Apache 2.0は特許条項も含みます。GPLやAGPLは、再配布やネットワーク利用時の条件確認が重要です。

GitHubのChoose a Licenseは、MIT、Apache 2.0、GPLv3などの選び方を整理しています（Choose a License）。SPDX License Listは、短縮識別子、正式名称、ライセンステキスト、canonical URLを整理しており、検索結果時点でVersion 3.28.0（2026-02-20）と表示されています（SPDX License List）。

種類	代表例	実務で見る点
パーミッシブ	MIT、BSD、Apache 2.0	著作権表示、NOTICE、特許条項
弱いコピーレフト	LGPL、MPL	リンク方法、改変部分の扱い
強いコピーレフト	GPL、AGPL	再配布、SaaS提供、ソース公開条件
独自OSS系	Elastic、Business Source系	商用利用や提供形態の制限

受託開発では、納品後に顧客が販売、再配布、SaaS提供、外部委託をできるかまで確認します。ライセンス名だけで判断せず、利用形態とセットで確認することが重要です。

商用ライセンス・SaaS・素材ライセンスの違い

商用ライセンスは、料金を払えば何でもできる契約ではありません。利用人数、顧客向け提供、再配布、サポート範囲などが決まっていることがあります。SDKやテンプレートを組み込む場合は、納品後も使い続けられるかを確認します。

SaaSやAPIは、利用規約、商用利用、禁止用途、レート制限、解約後のデータ扱いを見ます。生成AIを組み込む場合は、入力データの扱いも確認します。

素材やフォントでは、Creative Commonsのように再利用条件が明示されているものがあります。CC BY 4.0では共有や翻案が可能ですが、クレジット、ライセンスへのリンク、変更表示などが条件になります（Creative Commons BY 4.0）。商用サイトでは、素材ごとの条件を一覧化します。

事例: 受託開発でライセンス棚卸を行う

たとえば、業務システムを受託開発する際に、管理画面、認証、PDF出力、メール配信、グラフ表示、地図API、画像素材を使うケースを考えます。納品時にライセンス一覧がなければ、顧客は何を継続利用してよいのか判断できません。

この場合は、設計段階で利用予定のライブラリとSaaSを一覧化します。名称、用途、ライセンス、公式URL、本番組み込み有無、顧客負担の費用、再配布可否、表示義務を記録します。開発中に追加したものも更新します。

この棚卸があると、納品時に権利関係を説明しやすくなります。後から問題が起きやすい論点は、業務システム開発が失敗する原因でも整理しています。

選定手順とチェックリスト

ライセンス選定は、開発者だけで完結させないほうが安全です。事業責任者、法務、発注者、運用担当が利用範囲を共有します。外部公開、SaaS化、再販売、複数法人利用時は、初期段階で確認します。

1. 利用するコード、SaaS、素材、データを一覧化する
2. 本番に組み込むものと開発中だけ使うものを分ける
3. 商用利用、再配布、改変、ソース公開条件を確認する
4. 表示義務やNOTICEファイルの要否を確認する
5. 納品物、契約書、運用資料にライセンス一覧を残す

チェックリストで大切なのは、後から「何を使っているか分からない」状態を避けることです。ライセンス一覧を保守できる粒度で残すことが重要です。

注意点とnocoderiが補える範囲

失敗しやすいのは、無料で使えることと、商用プロダクトに組み込めることを同じ意味で扱うケースです。GitHubに公開されているコードでも、ライセンスがない場合は自由に使えるとは限りません。無料画像も、再配布、商標、人物写真の扱いに注意が必要です。

nocoderiでは、業務システムやノーコード開発の要件定義時に、利用予定ツール、OSS、外部API、素材、納品範囲を整理できます。Bubbleで外部プラグインやAPIを使う場合は、アプリ本体、外部サービス、データ連携を分けて確認します。

ただし、最終的な法的判断は弁護士など専門家の確認が必要です。開発側でできるのは、棚卸、公式URLの記録、用途の整理、契約書に入れるべき論点の洗い出しです。ライセンス確認を要件定義の段階で扱うことがリスクを下げます。

まとめ

ソフトウェアライセンス 種類は、MIT、Apache、GPLのようなOSSだけでなく、商用SDK、SaaS利用規約、画像素材、フォント、データ、生成AIサービスまで含めて確認する必要があります。システム開発では、どのライセンスかだけでなく、どの利用形態で使うかが重要です。

受託開発では、成果物の権利、再利用、外部公開、SaaS化、顧客による再配布、第三者素材の表示義務まで確認してください。SPDXのような標準識別子を使ってライセンス一覧を整えると、開発中の変更や納品時の説明がしやすくなります。ライセンス確認は、法務だけでなく、開発品質と運用保守にも関わる作業です。

また、開発後もライセンス一覧は更新が必要です。ライブラリの入れ替え、外部APIの追加、素材差し替え、生成AIツールの導入が起きるたびに、利用条件は変わる可能性があります。納品時に一度作って終わりにせず、運用保守の中で見直す前提にしてください。

料金やプランが絡む商用サービスでは、見積時点の価格だけでなく、契約主体、支払い方法、アカウント移管、解約後のデータ取得も確認します。ライセンス確認を資料化しておくと、担当者が変わっても判断の背景を追いやすくなります。

nocoderiは、業務システム開発やBubble開発の初期段階で、利用ツール、外部API、OSS、素材の棚卸と、契約・運用上の確認ポイント整理を支援できます。法務判断が必要な部分は専門家に確認しつつ、開発側では「何を、どこで、どの条件で使っているか」を見える化することから始めてください。