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

はじめに

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

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

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

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

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

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

ソフトウェアライセンスとは

ソフトウェアライセンスは、著作権者（開発者や提供企業）が利用者に対して、ソフトウェアを使用・複製・改変・再配布・販売してよい範囲を定めた利用許諾です。ソフトウェアそのものを譲り渡すのではなく、「どの条件で使ってよいか」を許可する仕組みなので、著作権者と利用者の権利と義務がライセンスによって決まります。

ライセンスの内容によって、利用できる人数や端末、商用利用の可否、改変したコードの扱い、第三者への配布方法が変わります。見落としやすいのは、ライセンスが書かれていないコードです。GitHubで公開されていても、ライセンスが明示されていなければ、一般に作者から利用・改変・共有の許可を得ていない状態と扱われます（Choose a License「No License」）。

ソフトウェアライセンスの種類と確認する範囲

ソフトウェアライセンスは、大きく「商用ライセンス」と「オープンソースライセンス」に分けて説明されることが多いです。ただし業務システムの開発では、この2分類だけでは足りません。UIライブラリ、バックエンドのパッケージ、外部API、画像素材、フォント、地図、決済、メール配信、分析ツールまで確認対象になります。

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

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

何を組み込むかは、開発に着手する時期と範囲を決める段階で整理すると手戻りを抑えられます。着手の時期や進め方は「中小企業向け システム開発 タイミング」を考える記事でまとめています。

SaaSテンプレートや既製の部品を土台にする開発では、テンプレート自体の利用条件も確認対象に入ります。テンプレートを使ったsaas システム 開発の進め方は別の記事で整理しています。

組み込むライブラリや外部サービスの管理は、開発を社内で担うか外部に任せるかでも負担が変わります。開発体制を検討している場合は、ソフトウェア開発を内製化するメリットもあわせてご覧ください。

利用するデータやソフトウェアの条件を整理したら、データの関連付けやアクセス権も設計します。具体的な確認点はソフトウェア開発のデータベース設計の極意で解説しています。

複数部門でソフトウェアや外部サービスを利用する大企業では、利用条件の棚卸しとあわせて、システム間の連携や担当部門の役割も整理する必要があります。関連する論点は、大企業のソフトウェア開発の課題とその解決策で解説しています。

商用ライセンスの種類と課金形態

商用ライセンスは、企業が有償で提供するソフトウェアに付く利用許諾です。ソースコードは公開されず、契約で決められた範囲だけ使えます。サポートが付くことが多い一方、自由度はOSSより低くなります。

形態	内容	向いているケース
フルライセンス（買い切り）	一度の支払いで利用権を得る。バージョンアップは別料金のことがある	長期間同じ版を使う社内ツール
サブスクリプションライセンス	月額・年額で利用料を払い、契約期間中だけ使える	常に最新版やクラウド版を使う場合
パーペチュアル（永続）ライセンス	期限なく使えるが、保守・更新は別契約になることが多い	更新頻度が低く、長く運用する基幹系

同じ製品でも、何を単位に数えるかで必要な契約数が変わります。

課金単位	数え方	確認点
ユーザー単位	利用者1人ごと（指名ユーザー）	退職・異動時の付け替え可否
デバイス単位	インストールする端末ごと	私物端末や検証機の扱い
同時接続単位	同時に使う人数の上限	ピーク時の人数
従量課金	API呼び出し数や処理量	上限設定、超過時の請求

商用ライセンスの選び方と注意点

商用ライセンスを選ぶときは、利用目的、予算、サポート体制に加えて、次の3点を契約前に確認します。

1つ目は使用制限です。ユーザー数や端末数、利用できる部署や拠点、社外の利用者に使わせてよいかが決まっていることがあります。受託開発で顧客向けシステムに組み込む場合は、開発会社の名義で契約したライセンスを顧客環境で使ってよいかを必ず確認します。

2つ目は更新とサポートの有無です。サポートの範囲や費用で運用後のコストが変わり、永続ライセンスでも保守契約を切ると更新を受けられない製品があります。

3つ目はライセンスの移転や譲渡の規定です。納品後に顧客へ契約を引き継げるか、契約終了後にデータをどう扱うかを確認しておきます。

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を整理しており、2026年9月27日時点ではVersion 3.29.0（2026-09-16公開）が最新です（SPDX License List）。ライセンス一覧を作るときは、SPDXの識別子（MIT、Apache-2.0、GPL-3.0-onlyなど）で書くと表記ゆれを防げます。

種類	代表例	実務で見る点
パーミッシブ	MIT、BSD、Apache 2.0	著作権表示、NOTICE、特許条項
弱いコピーレフト	LGPL、MPL	リンク方法、改変部分の扱い
強いコピーレフト	GPL、AGPL	再配布、SaaS提供、ソース公開条件
ソース公開型（OSI非承認）	Elastic License v2、SSPL、Business Source License系	競合サービスとしての提供禁止など、提供形態の制限

ソース公開型は、コードを読めてもOSSの定義を満たさない独自ライセンスです。ElasticsearchとKibanaのソースコードは、2024年9月からSSPL 1.0、Elastic License v2に加えてAGPLv3も選べるようになりました（Elastic「FAQ on Software Licensing」）。製品名だけで判断せず、どのライセンスで使うかまで記録します。

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

オープンソースライセンスの選び方と注意点

OSSを使うときに最初に押さえるのは、ライセンスごとに守るべき条件が違うことです。MITやApache 2.0は、著作権表示やライセンス文を残せば改変や商用利用ができます。Apache 2.0では、NOTICEファイルがあればその内容も引き継ぎます。

GPLは条件が厳しいと言われますが、商用利用そのものを禁止しているわけではありません。GPLv3は商用利用を許可しており、条件になるのは配布時のソース公開と同じライセンスの適用です（Choose a License「GPLv3」）。GPLのコードを組み込んだアプリを顧客へ配布・販売すると、改変部分を含めたソースコードの提供を求められる可能性があります。AGPLはこの条件をネットワーク越しの利用にも広げており、SaaSとして提供するだけで公開義務が生じる可能性があります。

選ぶときは、利用目的（社内利用、顧客への納品、SaaS提供、アプリ配布）を先に決め、その用途で課される条件を確認してから部品を選びます。

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

商用ライセンスは、料金を払えば何でもできる契約ではありません。SDKやテンプレートを組み込む場合は、納品後も使い続けられるかを確認します。

SaaSやAPIは、利用規約、商用利用、禁止用途、レート制限、解約後のデータ扱いを見ます。生成AIを組み込む場合は、入力データの扱いも確認します。生成AI導入時の情報管理の論点は、AIセキュリティの課題と対策で整理しています。

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

ライセンス違反を避けるための注意点

ライセンスに違反すると、利用停止、損害賠償、追加費用の請求、製品の公開停止といった損失につながります。違反の多くは、何を使っているかを誰も把握していないことから起きます。

まず、使うソフトウェアのライセンスを導入前に確認します。無料版を試した後にそのまま本番で使う、個人向けライセンスを業務で使う、といった違反は確認の順番を変えるだけで防げます。次に、OSSは依存関係まで確認します。直接入れたライブラリがMITでも、その依存先がGPLということがあります。

そのうえで、管理の仕組みを作ります。商用ソフトの契約数と利用状況はソフトウェア資産管理（SAM）ツールで、組み込んだOSSは部品表で管理します。経済産業省は、ソフトウェアの構成部品を一覧にするSBOM（ソフトウェア部品表）の導入手引を2024年8月にver2.0へ改訂し、委託先との契約で定めるべき事項も示しています（経済産業省「SBOMの導入に関する手引ver2.0」）。受託開発では、納品時にこの部品表を渡せるかが、発注者側の管理のしやすさに直結します。

ソフトウェアライセンス契約書の重要性

システム開発でソフトウェアを使うときや開発を外部へ委託するときは、ライセンス契約書や利用規約が権利と義務を確認する根拠になります。次の項目を明確にしておくと、後のトラブルを避けられます。

項目	確認する内容
使用許可範囲	利用できる人数・端末・用途、商用利用や配布の条件
支払い条件	ライセンス料金、支払い周期、更新時の価格改定
サポート・更新条件	サポート期間、更新方法、保守契約の要否
知的財産権に関する規定	著作権や特許権の帰属、改変物の扱い
納品物の権利帰属（受託開発）	開発会社と発注者のどちらが著作権を持つか、再利用の可否
第三者ライセンスの一覧（受託開発）	組み込んだOSS・素材・SaaSと、その条件を納品物に含めるか

受託開発の契約では、成果物の著作権を発注者へ移すかどうかと、開発会社がもともと持っている部品やOSSを移転の対象から外すかどうかを分けて書いておくと、納品後の再利用や保守移管で解釈が割れにくくなります。契約書の内容を理解したうえで署名することが、法的トラブルを防ぐ基本です。

想定ケース: 受託開発でライセンス棚卸を行う

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

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

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

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

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

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

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

注意点とnocoderiが補える範囲

失敗しやすいのは、無料で使えることと、商用プロダクトに組み込めることを同じ意味で扱うケースです。無料画像も、再配布、商標、人物写真の扱いに注意が必要です。

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

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

まとめ

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

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

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

料金やプランが絡む商用サービスでは、見積時点の価格だけでなく、契約主体、支払い方法、アカウント移管、解約後のデータ取得も確認します。

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