OSSライセンスとは｜種類一覧とGPL・MIT・Apacheの違い、商用利用の注意点

OSSライセンスとは

OSSライセンスとは、OSSを使う・改変する・配布する際の条件を定めた利用許諾です。 ソースコードが公開されているだけでは著作権が放棄されたことにはならず、利用者はライセンス条項に同意した範囲でだけ複製・改変・再配布ができます。

「オープンソース」の定義

「オープンソース」という言葉は感覚的に使われがちですが、業界標準の定義は Open Source Initiative（OSI）の The Open Source Definition にあります。ソースコード公開・自由な再配布・派生物の許可など10項目の条件を満たすライセンスだけが「OSI承認ライセンス」として認められます。

「ソースコードが読める＝OSS」ではありません。閲覧のみ許可し、競合サービスとしての提供などを制限する「ソースアベイラブル」ライセンス（SSPL、BUSL等）はOSIの承認を受けていません。社内で「OSSだから使ってよい」と扱うと事故につながります。

著作権とライセンスの関係

OSSライセンスは著作権を放棄する仕組みではなく、著作権者が「この条件を守るなら使ってよい」と示す利用許諾です。ライセンス条件に違反すると、許諾の範囲外利用として著作権侵害が問題になる可能性があります。

日本の著作権法では、著作物の複製・翻案・公衆送信は原則として著作権者の許諾が必要です。OSSライセンスは、この許諾をあらかじめ条件付きで与えておく仕組みと整理できます。

OSSライセンスに違反するとどうなるか

過去にはBusyBoxを組み込んだ製品でGPLv2違反が問われ、米国で差止・訴訟に発展した事例があります。国内でもGPL違反対応が問題化した事例があります。

フリーランス個人も無関係ではありません。納品したコードが原因でクライアントに損害が生じた場合、契約構成によっては損害賠償請求の対象になり得ます。

OSSライセンスの主な種類と分類

OSSライセンスは大きく3系統に分けて理解すると整理しやすくなります。境界がグレーな運用もありますが、案件で判断する場合はまずこの3分類にマッピングします。

3つの系統

強コピーレフト型は、組み込み方によっては、配布する派生物全体に同じライセンス条件が及び得ます。代表はGPL・AGPL。

弱コピーレフト型は、対象ライブラリや対象ファイルなど限定された範囲に同じライセンス条件を求めます。LGPLはリンクのしかた、MPLはファイル単位で範囲が決まります。

許可型（Permissive）は、著作権表示さえ残せば派生物のライセンスを自由に選べます。代表はMIT・BSD・Apache 2.0です。

主要OSSライセンス比較表（種類一覧）

案件で見かける頻度の高い8系統を整理しました（BSD 2/3-Clause、LGPL 2.1/3.0はそれぞれ1行にまとめています）。表は初期判断のための地図です。必ず案件の依存関係に合わせて、実物のLICENSEファイルを確認してください。

表の「ソース公開義務が問題になる場面」は、手元で改変しただけでは発生せず、主に配布・提供したときの論点です。

なお、PostgreSQLはBSDライセンスと同系統の「PostgreSQL License」で公開されており、上表の「BSD 2/3-Clause」とは厳密には別ライセンスです。

一次情報はSPDXの License List を参照してください。ライセンス識別子（SPDX ID）は依存関係管理ツールでも標準的に使われます。

コピーレフトの伝播範囲

強コピーレフトが厄介なのは「派生物」の解釈です。静的リンク・動的リンクは典型的な論点です。REST APIなど別プロセスでの呼び出しは一般に分離しやすい側ですが、構成次第で個別の評価が必要になります。

厳密な線引きは判例と技術構成に依存します。GPLコードを触るときは、組み込み方（リンク・呼び出し・プロセス分離）ごとに影響範囲を確認するのが現実的です。API連携なら常に影響を受けない、とも断定できません。判断の軸は「同じ配布物に含めるか」「密結合か（内部データ構造を共有するか）」「GPL側のプログラムを改変しているか」の3つです。

主要ライセンス別の商用利用ポイント

MIT・BSD・Apache 2.0（許可型）

許可型ライセンスは、著作権表示とライセンス文の同梱を守れば、商用製品への組み込み・改変・クローズドソース化まで幅広く認められます。フリーランス案件で扱う件数は許可型が多い部類に入ります。

Apache 2.0はMITやBSDと比べて特許条項が明示されている点が特徴です。コントリビューターが持つ特許を利用者に自動で許諾する一方、利用者側が特許訴訟を起こすと権利を失う「特許終了条項」が入っています。特許条項を重視する現場では、候補に挙がりやすいライセンスです。

GPL・AGPL（強コピーレフト）

GPLは組み込み方によって、派生物全体をGPLで公開する義務が発生し得ます。クライアントの受託開発では、GPLコードの扱いを事前に確認する必要があります。

特にAGPLは、対象プログラムを改変してネットワーク越しに利用させる場合、その改変版のソース提供義務が問題になり得ます。社内利用と外部提供の線引きが曖昧なプロダクトでは要注意です。

なお「GPLで公開する義務」は「無償で提供する義務」ではありません。有償でGPLソフトを販売することは可能で、受け取った人にソースコードを提供する形になります。この点はFSFの GPLに関するよくある質問 が明確に整理しています。

LGPL・MPL（弱コピーレフト）

LGPLは一般に、動的リンクなど一定の条件を満たす利用形態であれば、利用側アプリ全体の公開までは求められないことが多いライセンスです。ただしバージョン差・再リンク可能性・改変の有無で要件が変わるため、実装形態と対象バージョンを合わせて確認します。

MPL 2.0は「MPLで公開されたファイル」だけがコピーレフトの対象で、他のファイルは異なるライセンスにできます。プロプライエタリ製品にOSSを部分的に組み込む案件では、この弱コピーレフトが選ばれることがあります。

ミニFAQ（ライセンス選定）

Q. 受託案件で使うOSSはMITやApacheだけに絞ればよいですか？

A. 許可型に統一するとリスク管理は楽になりますが、GPLでも使い方を分離すれば導入できるケースがあります。「絶対禁止」より「用途と組み込み方でルール化」が実務的です。

Q. デュアルライセンスとは何ですか？

A. 同じソフトをGPLと商用ライセンスの両方で提供する形態です。MySQLやQtが代表例で、GPL条件を守れない企業は商用ライセンスを購入します。

フリーランス案件でOSSを使うときの実務フロー

案件でOSSを組み込むときは、コードを書く前後に以下の流れで確認しておくと後工程での指摘が減ります。

依存関係のライセンス確認手順

1. 直接依存だけでなく推移的依存まで含めて洗い出す（npm ls、pipdeptree、cargo tree、mvn dependency:tree等）

2. 各依存のLICENSEファイルを実物で確認する。パッケージ管理ツール上の表記と実ファイルがズレることがあります

3. SPDX識別子でリストを作成する。SBOM出力ツール（Syft・CycloneDX等）を使うと自動化できます

4. 強コピーレフト・弱コピーレフト・許可型で色分けし、コピーレフト系の使用箇所を可視化する

5. 社内標準やクライアント指定のOSSポリシーがあれば突き合わせる

業務委託契約書での扱い

業務委託契約書には、OSSの取り扱いを定める条項が入ることがあります。典型的な論点は次のとおりです。条項全体の考え方は業務委託契約書の確認ポイント｜フリーランスエンジニアが締結前に見る条項とチェックリストを参照してください。

• 成果物にOSSを組み込む場合の事前通知義務

• 強コピーレフト系ライセンスの原則不使用、または事前承諾の取得

• OSSのライセンス違反が生じた場合の責任分担

• 納品時にOSS一覧（SBOM）を添付する義務

• 将来的なライセンス変更リスクへの対応

契約段階でOSSに関する条項を確認せずに納品すると、後日クライアント側の法務チェックで差戻しになることがあります。特に大企業・官公庁系案件では、セキュリティ・ライセンスの遵守証跡が求められることがあります。準委任か請負かで納品物への責任の持ち方も変わるため、準委任契約と請負契約の違い｜フリーランスエンジニアが知るべきリスクと注意点もあわせて確認しておくと判断しやすくなります。

納品コードにOSSを含める際の注意点

著作権表示・ライセンス文書の同梱漏れが最頻出の指摘です。特にApache 2.0はLICENSEに加えてNOTICEファイルの取り扱いを求めるため、NOTICEを削除して納品してしまうミスに注意してください。

フロントエンドのビルド成果物では、Webpack・Viteのライセンス収集プラグイン（webpack-license-plugin、rollup-plugin-license 等）で生成物側にも表記を持たせる方法が現実的です。

ミニFAQ（納品実務）

Q. GitHubで公開されているコードは自由に使えますか？

A. 「公開されている」ことと「自由に使える」は別です。LICENSEファイルが同梱されていない、または不明確なリポジトリは著作権保護下にあると考え、利用の可否を作者に確認するか採用を見送るのが安全です。

よくある違反パターンとリスク

GPLの影響範囲が広がるケース

GPLコードの一部を切り出してプロプライエタリ製品に埋め込むと、意図せずGPLの範囲が広がることがあります（実務上の通称で「GPL汚染」と呼ばれることもあります）。特に「動作するプログラムの単一の集合体」に該当する組み込みは範囲が広くなりがちで、静的リンクの扱いは論争が続く領域です。判断が難しい構成では、プロセス分離＋API通信で切り離すなどのアーキテクチャ側の工夫が有効です。

帰属表示（Attribution）漏れ

MIT・BSD・Apacheでは著作権表示とライセンス文言の同梱が義務です。配布物へのライセンス文の同梱、スマホアプリの設定画面、Webで配信するフロントエンドなら「ライセンス情報」ページなど、配布形態に応じた実装が必要です。

ただし、必要な表示方法はライセンス条項と配布形態によって異なります（Apache 2.0のNOTICE同梱義務など）。ビルドフローに組み込まないと、リリースを重ねるうちに抜けが発生します。

依存ツリーの見落とし

自分が書いたコードは許可型でも、依存ライブラリの奥にGPLが混じっていることがあります。npmではlicense-checker、Pythonではpip-licenses、Rustではcargo-denyなど、依存ツリー全体を走査するツールでの継続的チェックが実務では欠かせません。

バージョン間のライセンス変更

OSSは開発元の判断でライセンスを変更することがあります。しかも一方向とは限りません。

いずれも公式の告知（Redisのライセンス一覧、ElasticのAGPL追加の発表）で確認できます。長期運用の案件では、依存ライブラリのライセンスをメジャーバージョンを上げるたびに見直す運用にしておくと、変更の見落としを防げます。

SBOM・ライセンス管理の実務

SBOM（Software Bill of Materials）とは

SBOMは、ソフトウェアに含まれる部品（コンポーネント）とそのライセンス・バージョンを列挙した一覧です。2021年の米国大統領令（Executive Order 14028）を契機に、政府調達を中心に提出要求が広がりました。日本でも経済産業省が SBOMの導入手引 を公開しています。

SBOMのフォーマットは SPDX と CycloneDX が主流です。生成ツールはオープンソースで整っており、CIパイプラインに組み込めば毎ビルドで最新のSBOMを出力できます。

EUサイバーレジリエンス法（CRA）の適用スケジュール

OSSライセンス管理とあわせて、2026年の実務で聞かれやすい補足論点がEUのサイバーレジリエンス法（Regulation (EU) 2024/2847）です。EU市場に出すデジタル製品の製造者に、脆弱性対応やセキュリティ要件を課す規則です。

日本の受託開発でも、クライアントがEU向けに製品やアプリを出している場合は影響を受けます。納品物にSBOMの添付を求められる場面は、2027年末に向けて増える可能性があります。SBOMを出せる状態にしておくことは、依存ライブラリのライセンス管理と同じ作業の延長です。

SCAツールでのライセンス管理

Software Composition Analysis（SCA）ツールは、依存ライブラリの脆弱性とライセンスをまとめてスキャンします。GitHub Dependency Graph、Snyk、FOSSA、Black Duckなどが代表例です。多くは無料枠か個人向けプランがあり、フリーランス案件でも導入余地があります。

CI連携の考え方はGitHub Actionsとは？CI/CDの仕組み・基本ワークフロー・案件単価をフリーランス視点で解説やGitLab CIとは｜CI/CDの仕組み・GitHub Actionsとの違い・案件単価をフリーランス視点で解説で紹介しているCI設計の応用として扱えます。

組織としてOSSの利用ルールを整える場合は、IPAのJapan Open Source Hub「OSSに取り組む・活かす」で、ガバナンス構築用のテンプレート集（OSPOスターターキット）が公開されています。

主要OSSプロジェクトのライセンス一覧

案件で触れる機会の多いOSSと、2026年10月時点で確認できたライセンスをまとめました。以下は代表的な現行例です。導入判断では、必ず対象バージョンの公式LICENSEを確認してください。

Linuxやコンテナ周辺はLinuxとは？仕組み・主要ディストリビューション・案件単価をフリーランスエンジニア視点で解説、Dockerとは？コンテナ技術の仕組み・できること・フリーランス案件の単価への影響を解説も併せて確認してください。

AI生成コード時代のライセンス論点

これはOSSライセンスそのものとは別論点ですが、実務上セットで確認されやすいため補足します。

GitHub Copilotなど生成AIとOSS

生成AIコード補完ツール（GitHub Copilotの使い方｜エンジニアの開発効率と案件単価への影響を解説、Cursorとは？AIコードエディタの特徴・使い方・料金とGitHub Copilotとの違いを解説）は、OSSを含む大規模なコードで学習しています。現時点では日本の裁判所・行政による確定的な判断は少なく、実務は運用ルールで対応するのが基本です。

主要な論点は次のとおりです。

• 生成されたコードが既存OSSと酷似した場合、その部分にGPL等の条件が及ぶ可能性があるか

• 生成コードの権利が誰に帰属するか（多くのツール提供事業者は利用規約で、生成物の権利を事業者側が主張しない立場をとっている）

• 案件でAIコード補完ツールの利用が契約上許可されているか

一部のツール提供事業者は、公開コードと一致する候補の検出・ブロック機能や、法人向けプランでの補償条項を設けています。契約時にAIツールの利用可否を明文化するクライアントもあり、フリーランスも案件受注前に確認しておくと安心です。

学習データとしてのOSS

「学習に使われたOSSのライセンス条項が生成物にどこまで及ぶか」は各国で議論が続いており、2026年10月時点で確定した実務基準はありません。「AIが書いたコードだからライセンスの心配はない」と即断せず、生成コードにも通常のライセンスチェックを通す運用が現実的です。

ケース別解説：フリーランス案件パターン別の判断

ケース1：SaaSプロダクトへの組み込み（AGPLに注意）

AGPLは、改変版をネットワーク越しに提供する場合にもソース提供義務が及ぶため、SaaS開発では特に警戒対象です。監視・BIツール系にもAGPLのものがあり、社内利用ならOKでも、外向けSaaSに組み込むと義務が及ぶ場合があります。Redis 8以降でAGPLv3を選んで使う場合も同じ観点で確認します。

要件定義段階でSaaS化予定の有無を確認してください。関連する案件像はSaaSスタートアップのフリーランスエンジニア案件｜契約・単価・働き方を解説で扱っています。

ケース2：クライアントへ納品するオンプレコード

オンプレ納品の受託開発では、ソースコード一式を提供することが多くなります。クライアントへの引渡しがライセンス上の提供・配布に当たるかを含めて、GPL上の義務が問題になることがあります。

クライアント内利用にとどまる限り、一般公開までは求められないケースが多い一方、LICENSE・NOTICEを漏れなく引き渡す運用が最低限求められます。

ケース3：クライアントの自社プロダクトを社内利用のみで運用

社内配布のみで外部配布がなければ、GPLでもソース公開の要求はあまり顕在化しません。ただし将来SaaS化・外部提供する可能性があるなら、AGPLコンポーネントの義務が顕在化したり、代替ソフトへの置換が必要になったりする可能性があります。設計段階で拡張シナリオを想定しておくことが望ましいです。

ケース4：AI SaaSに機械学習モデルを組み込む

TensorFlow（Apache 2.0）・PyTorch（BSD系）などフレームワーク側は許可型が多く、扱いやすい部類です。ただしモデルの重みファイル・学習データセット・派生モデルには、別のライセンス（Meta Llama系のカスタムライセンス、Creative Commons、非商用限定など）が付いていることが少なくありません。モデル選定時にライセンスを個別に確認する運用が必要です。

ケース5：EU向けに製品を出しているクライアントの案件

前述のサイバーレジリエンス法の対象になる製品なら、2027年12月11日以降はSBOMを含む構成要素の文書化が求められます。依存関係の一覧をSPDXかCycloneDX形式で出せるようにしておくと、後から慌てずに済みます。対象になるかどうかの判断はクライアント側の法務の領域なので、フリーランス側は「出せる状態」を用意しておく役割と割り切るのが現実的です。

OSSライセンスの知識が活きる案件

ライセンス確認やSBOM作成は、それだけで独立した案件になることは多くありません。依存関係の管理、CI/CDの整備、脆弱性スキャンの運用といった作業の一部として求められるのが一般的です。

そのため、この知識が活きやすいのはインフラ・DevOps寄りの案件や、セキュリティ要件の厳しいクライアントの開発案件です。フリコンではインフラエンジニアの案件一覧やセキュリティエンジニアの案件一覧から、職種別に募集内容を確認できます。

職務経歴書では「OSSライセンスを確認した」と書くより、「依存ライブラリ○件のライセンスをSPDX形式で棚卸しし、GPL系の使用箇所を事前承認制にした」のように、規模と仕組みで書くと伝わりやすくなります。

OSSライセンス確認チェックリスト（案件着手前）

案件着手時に手元で回せる簡易チェックリストです。すべてを毎回埋める必要はありませんが、契約書と依存関係の確認前に一通り目を通しておくと後工程がスムーズになります。

• 契約書にOSS利用に関する条項があるかを確認したか

• 強コピーレフト系OSS（GPL/AGPL）や、LGPLの組み込み方について発注元の方針を確認したか

• 依存関係を推移的にリスト化したか（直接依存だけで済ませていないか）

• 各依存のライセンスをSPDX識別子で分類したか

• 著作権表示・ライセンス文の同梱手順を確定したか

• Apache 2.0のNOTICEファイルの扱いを決めたか

• 納品時に提出するSBOMのフォーマット（SPDX/CycloneDX）を決めたか

• AIコード補完ツールの利用が契約上許可されているかを確認したか

• SaaS化・外部提供の可能性があるならAGPL対策を検討したか

• ライセンス変更モニタリングの担当とタイミング（メジャーバージョン更新時など）を決めたか

まとめ

OSSライセンスとは、OSSの利用・改変・配布の条件を定める利用許諾です。商用利用は主要ライセンスのほぼすべてで可能で、違いは表示義務と公開義務の範囲にあります。

• OSSライセンスは著作権に基づく利用許諾であり、条件を無視すると著作権侵害が問題になり得る

• 3系統（許可型・弱コピーレフト・強コピーレフト）で、組み込んだ側に及ぶ義務が変わる

• 案件では「依存の洗い出し・帰属表示・契約書での扱い」の3点セットで管理する

• ライセンスは変わり、戻ることもある（Redis 8・ElasticsearchのAGPL追加）。バージョン単位で確認する

• SBOMは2027年12月のEUサイバーレジリエンス法全面適用に向けて求められる場面が増える可能性がある

• AI生成コードにも通常のライセンスチェックを通す

• 迷ったら「配布するか」「改変するか」「SaaSとして提供するか」の3点から確認する

まずは手元の案件で、依存関係の一覧を1回出してみるところから始めると、どこにリスクがあるかが具体的に見えてきます。関連する契約実務は秘密保持契約（NDA）とは｜フリーランスエンジニアが押さえる条項とチェックポイントや競業避止義務とは｜フリーランスエンジニアの退職後・業務委託契約の有効性判断と実務ポイントも併せて確認してください。

参照した一次情報：

• Open Source Initiative The Open Source Definition

• Free Software Foundation GPLに関するよくある質問

• SPDX License List

• e-Gov法令検索 著作権法

• 経済産業省 ソフトウェア管理に向けたSBOMの導入に関する手引

• EUR-Lex Regulation (EU) 2024/2847（サイバーレジリエンス法）

• IPA Japan Open Source Hub「OSSに取り組む・活かす」

本記事は一般的な情報提供を目的としたもので、個別案件の法的判断を代替するものではありません。契約上のリスク判断や争いの兆しがあるケースでは、弁護士・法務部門への相談を検討してください。