フリーランスのOSSライセンス違反リスク｜納品前チェック実務5ステップ

「これ、GPL入ってますよね?」——受託開発で納品直後にクライアントの法務部からこう指摘され、対応に追われた経験を持つフリーランスエンジニアは少なくありません。契約書にOSS条項が明記されていなくても、後日のSBOM（Software Bill of Materials）監査や法務レビューで発覚し、賠償請求・契約解除・失注につながるケースが増えています。

背景にあるのは、npmやpipで導入するライブラリの「推移依存（Transitive Dependency）」の複雑化です。自分が直接インストールしたパッケージが数十件でも、その先の依存ツリー全体では数百〜数千件に膨れ上がることも珍しくなく、その中にGPL/AGPLが紛れ込むリスクは常に存在します。しかも大半の一般記事は直接依存のライセンス表を示すだけで、フリーランス個人が納品前にひとりで完結できる実務手順まで踏み込んでいません。

AI生成コードの著作権対応が業界的に整いつつある一方で、この「OSSライセンスの推移依存問題」は依然として盲点です。企業向けSBOMツール導入記事は数多くありますが、直請け・二次請けを並行で回すフリーランスにとって「今日から自分のプロジェクトで実行できる手順」に落とし込んだ記事は限られています。

本記事では、受注者側のフリーランスエンジニア視点で、GPL/AGPL混入を納品前に検出する5ステップの実務ワークフローを解説します。npm/pipの実コマンド、無償ツールの比較、CycloneDX形式のSBOM生成方法、クライアントへ提出する「OSS使用申告書」テンプレート、契約書にOSS条項がない案件での事前合意の切り出し方まで、案件開始から納品まで一貫して使える型を示します。読み終える頃には、次の案件で「AGPLは避けたい」「事前に想定OSSリストを共有します」と自分から先回りできる状態になり、継続受注の基盤としてこのチェック体制を標準運用に組み込めるはずです。

フリーランスエンジニアがOSSライセンス違反で失注する構造

まず、なぜフリーランスエンジニアがOSSライセンス違反リスクを負いやすいのか、その構造を整理します。ここを言語化しておくと、後の実務チェックで「なぜこの手順が必要か」が腹落ちしやすくなります。

なぜフリーランス側にリスクが集中するのか

受託開発において、成果物の著作権と品質責任は多くの場合「納品時点で受注者が保証する」形になっています。契約書の免責条項が薄い場合、納品物に含まれるOSSのライセンス違反が後日発覚したとき、その責任は受注者（つまりフリーランス側）が負う建て付けです。

さらに二次請け構造では、「直請け企業→フリーランス」の間で契約書がテンプレート化されており、OSS使用に関する明示的な合意条項がないまま、法務チェックの負担だけが下流に落ちてくる事例もあります。エンドクライアントの法務部が「GPL混入不可」というポリシーを持っていた場合、そのポリシーは契約書に書かれていなくても、納品後の監査で問題化されることがあります。

もう一つの構造的リスクは「実装当時は問題なくても、後から法務チェックのタイミングが来る」という時間差です。案件開始時にはOSSに一切触れなかったクライアントが、半年後に「今度SBOMを義務化するので過去の納品物を全部洗い直します」と言い出すケースは、コンプライアンス要求の強化とともに増えています。

納品後に指摘される典型3パターン

フリーランスエンジニアが遭遇しやすいOSSライセンス関連の指摘は、大きく3つのパターンに分かれます。

第一は「推移依存で入るGPL」です。直接インストールしたパッケージ（例: MITライセンス）が、内部で使っているライブラリの奥深くでGPLライブラリを引き込んでいる、というケースです。10エコシステムを横断した実証研究では、npmの推移依存は直接依存の平均約4.32倍に膨らみ、12%のプロジェクトでは10倍を超えるとされています（How Deep Does Your Dependency Tree Go? An Empirical Study of Dependency Amplification Across 10 Package Ecosystems（arXiv:2512.14739））。平均値でも直接依存の数倍、極端なケースでは10倍以上にまで膨らむため、package.json の見た目だけでは絶対に検出できません。

第二は「Webサービス公開時のAGPL」です。AGPL（Affero GPL）は、ユーザーがネットワーク越しに（HTTP・WebSocket・API等で）改変版のソフトウェアを利用しただけで、ソースコード公開義務が発生します（The SaaS Loophole In GPL Open Source Licenses）。「配布していないから大丈夫」というGPLの感覚のままAGPLパッケージを組み込むと、SaaSとして公開した瞬間に自作コードの公開義務が発生します。

第三は「ライセンス表記漏れ」です。MIT・Apache 2.0のような許容型ライセンスであっても、著作権表示・ライセンス文の複製・NOTICEファイルの同梱などが要求されます。GPL混入ゼロでも、この表記義務を果たしていないだけで「ライセンス違反」と指摘されるケースがあります。

AI生成コード著作権とは何が違うのか

近年フリーランス界隈で語られる「AI生成コードの著作権リスク」と、本記事で扱う「OSSライセンス違反リスク」は、扱う対象が別です。前者はChatGPTやGitHub Copilotが生成したコードが第三者のコードに類似していた場合の著作権侵害リスクで、後者はライブラリ導入時のライセンス条項違反リスクです。前者の実務対応は姉妹記事フリーランスエンジニアのAI生成コード著作権リスクで詳しく解説しています。フリーランスが継続受注のために納品前に確認すべき法務チェックとしてはこの2つが「両輪」であり、片方だけでは不十分です。本記事はOSSライセンス側の実務チェックに絞って解説します。

フリーランスが最低限押さえるOSSライセンス3分類

OSSライセンスは細かく数えると数百種類存在しますが、フリーランスエンジニアが日常業務で判断するために覚えるべきは以下の3分類のみです。「これは即断で避ける」という判断基準を持っておけば、納品前チェックの意思決定は大幅にシンプルになります。ライセンスの基礎的な種類・特徴の一覧はソフトウェアライセンスの種類と選び方でも整理していますので、体系的に整理したい場合はあわせてご覧ください。

許容型（MIT / Apache 2.0 / BSD）——商用配布に最も向く

許容型（Permissive License）は、著作権表示さえ守れば商用利用・改変・再配布が原則自由なライセンス群です。代表例はMIT、Apache 2.0、BSD（2条項/3条項）です。

受託開発でこのライセンスのライブラリを使う場合、基本的にリスクは最小です。ただし、以下の義務は残るため納品時にNOTICEファイル等で明示する必要があります。

• 著作権表示（copyright notice）の複製
• ライセンス文の同梱
• Apache 2.0の場合、変更したファイルには変更点を明記

React、Vue、Express、Django、FastAPIといった主要フレームワークの大半はこの許容型です。「使ってはいけない」わけではなく、「表記義務は果たす必要がある」という理解が正解です。

弱コピーレフト（LGPL / MPL）——組み込み方で変わるグレーゾーン

弱コピーレフト（Weak Copyleft）は、そのライブラリ自体を改変した場合はソースコード開示が必要だが、ライブラリを「呼び出すだけ」の自作コードには開示義務が及ばないライセンス群です。代表例はLGPL（Lesser GPL）、MPL 2.0（Mozilla Public License）です。

問題は「呼び出すだけ」の判定が、動的リンク・静的リンク・埋め込みバンドルなどの組み込み方によって変わる点です。特にJavaScriptのように「ビルド時に自作コードとライブラリを一つのバンドルにまとめる」現代的なフロントエンド構成では、LGPLの解釈が分かれることがあります。

フリーランス個人としては、「LGPLはできれば代替を探す、避けられない場合は動的リンク相当の呼び出し方を維持する」という運用が安全策です。契約書にOSS条項がない案件であっても、LGPL採用時は事前にクライアントへ共有しておくと後日のトラブルを回避できます。

強コピーレフト（GPL / AGPL）——混入すると自作コードまで公開義務

強コピーレフト（Strong Copyleft）は、そのライブラリを組み込んだソフトウェア全体にソースコード公開義務が及ぶライセンス群です。代表例はGPL v2、GPL v3、AGPL v3です。

受託開発の納品物にGPL/AGPLライブラリが混入した場合、原則として自作コード全体を同じライセンス条件で公開する義務が発生します。これはクライアントのビジネスモデル（クローズドソースSaaS等）と根本的に衝突するため、実質的に「即失注」に直結します。発注者側から見た同じリスクの整理は発注者が知るべきOSSライセンスリスクにまとまっており、クライアントに説明する際の参考にできます。

特にAGPLは「配布していないから大丈夫」というGPLの直感が通用しません。AGPL 3.0の追加条項では、ユーザーがネットワーク越しに改変版のソフトウェアを利用しただけで、そのユーザーに対して完全な対応ソースコードをAGPL条件で提供する義務が発生します（FOSSA Blog: Open Source Software Licenses 101: The AGPL License）。SaaSやWebサービスを開発する案件では、AGPLの混入は最も警戒すべき事象です。

フリーランスが「即断で避ける」ライセンスと確認手順の優先度

以上を踏まえ、フリーランスエンジニアの実務では以下の判断基準を持つことをおすすめします。

確認手順の優先度は「まずAGPLゼロを確認、次にGPLゼロを確認、その後LGPL/MPLの有無と組み込み方をチェック」という順に進めれば、致命的リスクを短時間で潰せます。

納品前チェックの5ステップ実務ワークフロー

ここからは、実際に今日から自分のプロジェクトで実行できる5ステップの実務手順を解説します。npm / pipの両方でコマンド例を示し、各ステップに「所要時間の目安」と「よくある落とし穴」を添えます。

STEP1: 依存ツリーを棚卸しする

まずは自分のプロジェクトが「実際に何を引き込んでいるか」を可視化します。所要時間: 5〜10分。

Node.js（npm）の場合

# 直接依存のみ
npm ls --depth=0

# 推移依存を含む全依存ツリー
npm ls --all

# JSON形式で出力（後続のツールで扱いやすい）
npm ls --all --json > deps.json

Python（pip）の場合

# 直接依存のみ
pip list

# 推移依存を含む依存ツリー（pipdeptreeを使用）
pip install pipdeptree
pipdeptree

# JSON形式
pipdeptree --json > deps.json

Ruby（bundler）の場合

bundle list
bundle info <gem-name>  # 個別ライブラリの情報

よくある落とし穴は、package.json の dependencies だけを見て安心してしまうことです。10エコシステムを横断した実証研究によれば、npmの推移依存は直接依存の平均約4.32倍に達し、12%のプロジェクトでは10倍を超えます（How Deep Does Your Dependency Tree Go?（arXiv:2512.14739））。平均でも数倍、プロジェクトによっては桁違いに膨らむため、実際の混入リスクは推移依存の中に潜んでいます。必ず --all オプションや pipdeptree で全体を可視化してください。

STEP2: ライセンス一覧を自動生成する

次に、依存ツリー全体のライセンスを自動抽出します。所要時間: 5分。

Node.js（license-checker）の場合

# インストール
npm install -g license-checker
# または npx で単発実行
npx license-checker --production --json > licenses.json

# GPL/AGPL のみを抽出
npx license-checker --production --failOn "GPL;AGPL"

# 許可リスト方式（MIT / Apache-2.0 / BSD のみ許容）
npx license-checker --production --onlyAllow "MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC"

--production フラグを付けることで、devDependencies（開発時のみ使用）を除外できます。納品物に含まれるのは基本的にproduction依存のみですので、実運用ではこのフラグを付けるのが標準です。

Python（pip-licenses）の場合

# インストール
pip install pip-licenses

# 全ライセンスの一覧
pip-licenses

# JSON形式で出力
pip-licenses --format=json > licenses.json

# 許可リスト方式
pip-licenses --allow-only "MIT;Apache Software License;BSD License;ISC License"

pip-licensesは --allow-only オプションで許可リストを指定することで、それ以外のライセンスが検出された場合にエラー終了させることができます（pip-licenses PyPI）。CI組み込みに便利です。

よくある落とし穴は、UNKNOWN や Unlicense のように判定できなかったライセンスを見逃すことです。これらは手動で該当パッケージのGitHubリポジトリを確認し、実際のライセンスを特定する必要があります。

STEP3: SBOMを生成する（CycloneDX / SPDX形式）

続いて、業界標準フォーマットのSBOMを生成します。所要時間: 5分。

SBOM（Software Bill of Materials）は、ソフトウェアに含まれる全構成要素の一覧を機械可読形式でまとめたものです。代表的なフォーマットは以下の2つです。

• CycloneDX: OWASP発。セキュリティ・ライセンス管理に強く、フリーランス個人のプロジェクトから大企業まで幅広く使われる
• SPDX: Linux Foundation発。ISO標準（ISO/IEC 5962:2021）としての位置づけがある

どちらを選ぶかで迷ったら、まずはCycloneDXから始めることをおすすめします。ツールのエコシステムが充実しており、生成も容易です。

Node.jsでCycloneDX形式のSBOM生成

# CycloneDX for npmを使用
npm install -g @cyclonedx/cyclonedx-npm
cyclonedx-npm --output-format JSON --output-file sbom.json

# もしくはnpm標準のnpm-sbomコマンド（npm v9以降）
npm sbom --sbom-format cyclonedx > sbom.json

CycloneDX for npmは、npmベースプロジェクト向けの高精度なSBOM生成ツールで、OWASPのSoftware Component Verification Standardの基準に照らして高いレベルの完成度を持ちます（CycloneDX/cyclonedx-node-npm）。またnpm v9以降では npm sbom コマンドが標準で用意されており、SPDX/CycloneDX両形式に対応しています（npm-sbom公式ドキュメント）。

PythonでCycloneDX形式のSBOM生成

pip install cyclonedx-bom
cyclonedx-py requirements requirements.txt -o sbom.json --format json

よくある落とし穴は、SBOMを一度生成して満足してしまうことです。SBOMは「その時点のスナップショット」ですので、依存を更新するたびに再生成する必要があります。次のSTEP4でCIに組み込むと自動化できます。

STEP4: 危険ライセンス（GPL / AGPL）をCIで検出する

続いて、CIに組み込んで「気付いたときには手遅れ」を防ぎます。所要時間: 15〜30分（初回セットアップ）。

GitHub Actionsの例（Node.js）

name: License Check

on:
  pull_request:
    branches: [main]

jobs:
  license-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - name: Check for prohibited licenses
        run: npx license-checker --production --failOn "GPL;AGPL;LGPL"

--failOn に検出したいライセンスを列挙すると、該当ライセンスが混入している場合にCIがfailします。PRマージ前にブロックできるため、混入リスクを実装フェーズで潰せます。

GitHub Actionsの例（Python）

name: License Check

on:
  pull_request:
    branches: [main]

jobs:
  license-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - run: pip install -r requirements.txt pip-licenses
      - name: Check for prohibited licenses
        run: |
          pip-licenses --allow-only "MIT License;Apache Software License;BSD License;ISC License;Python Software Foundation License;Mozilla Public License 2.0 (MPL 2.0)"

よくある落とし穴は、--failOn の指定漏れです。特にAGPLはGPLと別カウントされることが多く、GPL;AGPL と両方明示しておくのが安全です。

STEP5: ライセンス表記・NOTICEファイルを整備する

最後に、納品物に含めるライセンス表記を整えます。所要時間: 10〜20分。

許容型ライセンス（MIT / Apache 2.0 / BSD）でも、著作権表示とライセンス全文の複製義務があります。これを納品物に含めていない場合、「GPL混入ゼロ」でもライセンス違反と指摘される可能性があります。

以下のツールで、依存ライブラリのライセンス文をまとめて抽出できます。

Node.jsの場合

# ライセンス全文を含むテキストファイルを生成
npx license-checker --production --out licenses.txt --customPath customFormat.json

# あるいはNOTICEファイル形式で出力
npx generate-license-file --input package.json --output NOTICE.txt

Pythonの場合

# ライセンス全文をまとめて出力
pip-licenses --with-license-file --format=markdown > LICENSES.md

納品時は以下のファイルをリポジトリのルートまたはドキュメントディレクトリに配置します。

• LICENSE（自作コードのライセンス）
• NOTICE.txt または THIRD-PARTY-LICENSES.txt（依存ライブラリの著作権表示・ライセンス全文）
• sbom.json（依存ライブラリの機械可読一覧）

よくある落とし穴は、NOTICEファイルを一度作って放置することです。依存を追加・更新するたびに再生成する必要があります。STEP4のCIに組み込んでおくと運用が楽になります。

フリーランスが使えるOSSライセンス確認ツール比較

STEP2〜STEP5で登場したツール群を、フリーランス個人が選ぶ観点から比較します。有償の企業向けツール（Black Duck等）でなくても、無償ツールだけで十分実用的なチェック体制が組めます。

言語別ライセンスチェッカー

まず自分のプロジェクトの言語に対応するチェッカーを1本導入し、STEP2〜STEP4の運用に組み込むのが最短ルートです。

プロジェクト横断のスキャナ

複数言語をまたぐプロジェクトや、コード内のライセンス文自体をスキャンしたい場合は、プロジェクト横断のスキャナが便利です。

• ScanCode Toolkit: Python製のCLIスキャナ。Windows・Linux・macで動作し、パッケージのライセンス・著作権・依存関係を検出します（ScanCode Toolkit）
• FOSSology: Webベースのライセンス管理プラットフォーム。ScanCode Toolkitをエージェントとして統合可能で、OSSライセンスとして自由に利用できます（FOSSology）

フリーランス個人で本格的に運用する場合、ScanCode Toolkitのほうが導入負担が軽くおすすめです。

SaaS型ツール

CI連携が中心で運用負担を減らしたい場合は、以下のSaaS型ツールが候補になります。

GitHubで案件のリポジトリを管理している場合、まずはDependency graphとDependabotを有効化するだけで、追加コストなくベースラインの検出体制が作れます。

フリーランスの選び方——案件規模別の推奨組み合わせ

案件規模が大きくなるほど、SBOM生成と危険ライセンス検出のCI組み込みは必須になります。逆に小規模案件では、言語別チェッカー1本でも十分な効果が得られます。

クライアントへの説明と納品時に添える書類

ツールで検出できても、クライアントに「安心して受け取れる形」で提出できなければ、フリーランスとしての信用蓄積にはつながりません。ここでは納品時に添える書類のフォーマットと、説明文の例を示します。発注者側がどのような観点でOSSリスクを見ているかは発注者が知るべきOSSライセンスリスクにまとまっており、提出時のコミュニケーション設計の参考になります。

SBOMの提出フォーマット

SBOMの提出フォーマットは、以下の3種類が実務でよく使われます。

フリーランスからクライアントへ提出する場合、まずはCycloneDX JSONを主とし、副本としてCSV形式（pip-licenses --format=csv や license-checker --csv で生成可能)を添えるのが実用的です。CSV形式なら法務担当者がExcelで開いて目視レビューできます。

OSS使用申告書テンプレート

契約書にSBOM提出義務が明記されていない案件でも、以下の項目を含む「OSS使用申告書」を自主的に添えると、後日のトラブルを未然に防げます。

このテンプレートを1度作っておけば、次案件以降は自動生成したCSVをベースに埋めるだけで済みます。フリーランスとしての運用効率も上がります。

「危険ライセンス混入ゼロ」を伝える説明文の例

納品時にSBOMと申告書を添付するだけでなく、簡潔な説明文を添えると信頼度が上がります。以下はメール本文またはREADMEに添える文面の例です。

納品物には、CycloneDX形式のSBOM（sbom.json）と、OSS使用申告書（oss-usage.csv）を同梱しています。

依存ライブラリの全ライセンスを license-checker （Node.js）／ pip-licenses （Python）にてスキャンし、GPL・AGPL・LGPLは含まれていないことを確認済みです（CIワークフローにも組み込み済み）。

使用しているライセンスはMIT・Apache 2.0・BSD・ISCの許容型のみで、各ライブラリの著作権表示およびライセンス全文は NOTICE.txt に集約しています。

この形式で提出すれば、クライアントの法務担当者が確認する労力を大幅に削減でき、次回案件の継続依頼にもつながります。

契約書にOSS条項がない場合の実務対応

実務でよく直面するのは「契約書にOSS条項が一切書かれていない」案件です。この場合、後日のトラブル回避には受注者側からの先回りが不可欠です。ここではフリーランスが自分から切り出せる型を提供します。

契約前——想定OSSリストと許容ライセンスを事前合意する

契約前の段階で、以下を先方に共有すると事後トラブルの多くを回避できます。

1. 想定使用OSSのカテゴリー: 「フロントエンドはReact + Next.js、バックエンドはExpress + PostgreSQL」といった主要ライブラリのカテゴリー
2. 許容ライセンスの範囲: 「MIT・Apache 2.0・BSD・ISCの許容型のみを想定。GPL・AGPL・LGPLは使用しない方針」
3. 納品時の提出書類: 「SBOMおよびOSS使用申告書を納品物に含める」

これを提案書または見積書に1〜2行添えるだけでも、クライアントの法務部門から見た信頼度は大きく変わります。

契約後・納品前——免責事項を追記合意する方法

すでに契約締結済みで、契約書にOSS条項がない場合は、以下の免責事項をメールベースで追加合意する方法があります。

【納品物のOSS使用に関する補足】

本案件の納品物には、業界標準的なOSSライブラリを使用しております。使用ライブラリの一覧はSBOM（sbom.json）およびOSS使用申告書（oss-usage.csv）に記載しております。

使用OSSはすべて許容型ライセンス（MIT・Apache 2.0・BSD・ISC）のみで、GPL・AGPL・LGPLは含まれておりません。

本OSS使用について、貴社側で法務レビューが必要な場合は、納品前にご指摘いただければ調整いたします。指摘なく検収いただいた場合、本OSS使用について合意いただいたものとみなさせていただきます。

このような文面を検収依頼メールに添えることで、後日「知らなかった」というトラブルを回避できます。

「AGPLは避けたい」を切り出す実務的な言い回し例

案件のヒアリング段階で、AGPLの回避方針を切り出す言い回しの例です。押し付けにならず、自然にリスクを説明できます。

「差し支えなければ、本案件で採用するOSSライブラリの方針について事前に合わせておきたく思います。特にAGPLライセンスのライブラリは、SaaSとしてWeb公開した瞬間に自社コードのソースコード公開義務が発生する仕様のため、御社のビジネス上避けたほうが安全と考えております。私のほうでもAGPLを避けた実装方針で進めますが、既存システムに含まれるライブラリで確認したいものがあれば教えてください。」

このように「相手のビジネスリスクを説明する形」で切り出せば、経験の浅いクライアントでも納得しやすくなります。フリーランス側の一方的な要求ではなく、双方のリスク回避という文脈で提案するのがポイントです。

継続案件を守るために「納品前チェック」を標準化する

ここまで、OSSライセンス違反リスクを納品前に検出する5ステップの実務ワークフローと、クライアントとの合意形成の型を解説してきました。最後に、これを「単発の対応」で終わらせず、継続受注の基盤として運用に組み込むためのヒントで締めくくります。

まずは自分のプロジェクトテンプレートに、license-check スクリプトを常設することをおすすめします。npm/pip/gem等の主要言語ごとに、テンプレートリポジトリを1つずつ用意し、以下を最初から組み込んでおきます。

• license-checker / pip-licenses の設定ファイル
• GitHub Actionsの license-check.yml ワークフロー
• NOTICE.txt の生成スクリプト
• SBOM生成のnpmスクリプト（npm run sbom）
• OSS使用申告書のCSVテンプレート

こうしておけば、新規案件を始めるときに git clone するだけで、初日から納品前チェックの体制が整った状態でスタートできます。

さらに、案件のキックオフ時に「本案件では以下のOSSライセンス管理方針で進めます」というドキュメントを1枚共有できれば、フリーランスとしての信頼度は一段上がります。案件ごとに毎回ゼロから作る必要はなく、テンプレートを1度用意すれば以降は使い回せます。

OSSライセンス違反リスクは、確率としては高くありませんが、発生したときの影響（賠償・契約解除・失注）は継続受注に致命的です。逆に、納品前チェックを標準化しておけば、それ自体が「他のフリーランスとの差別化ポイント」になります。「OSSライセンスまで見てくれるエンジニア」として認識されれば、継続案件・単価交渉・紹介案件のいずれにおいても有利に働きます。

AI生成コードの著作権対応と並行して、このOSSライセンス側の実務チェックも標準運用に組み込むことで、フリーランスとしての持続可能性——継続的な案件獲得と収入安定化——の基盤を一段固められるはずです。今日のうちに1つの案件で npx license-checker --failOn "GPL;AGPL" を試してみるところから始めてみてください。