184
184

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ライブラリ・フレームワーク Qiita Tech Festa 2025
Qiita Tech Festa20252025年7月15日まで開催中！
@ShigemoriMasato(重盛 雅人)

[入門] オープンソースライセンス違反を防ぐための実践ガイド

184
Last updated at Posted at 2025-07-11

image.png

オープンソースライセンスの理解は、現代のソフトウェア開発において必須のスキルです。

個人プロジェクトや学習目的の開発では見過ごされがちですが、企業のプロダクト開発に携わるエンジニア、特に技術選定やアーキテクチャ設計に責任を持つ立場の方にとっては、ライセンス違反は企業の存続に関わる重大なリスクとなります。

実際、先日社内のTeamsで「YCに採択された企業がGPLライセンス違反で大きな批判を受けている」という話題が出ていました。調べてみると、Pickle社（YC採択企業）がGPLv3ライセンスのプロジェクトをApache 2.0ライセンスとして公開したという、かなり深刻な事例でした1。

この事例が示すように、ライセンス違反は企業に深刻な影響をもたらします。まず法的リスクとして、著作権侵害による訴訟の可能性があります。さらにレピュテーションリスクとして、オープンソースコミュニティからの信頼を失い、今後の採用活動や協業に支障をきたす恐れがあります。加えて、GPLライセンスの場合はソースコード公開義務が発生し、競争優位性を失うというビジネスリスクも抱えることになります。

さらに、生成AIを活用したコーディングが一般的になった現在、新たなリスクも生まれています。CopilotやCursorなどのAIアシスタントが推奨するコードをそのまま利用すると、どのようなライセンスのライブラリが使われているかまで意識が向かず、意図しないライセンス違反につながる恐れがあるためです。

本記事では、実際に起きた事例を基に、なぜライセンス違反が起きるのか、動的リンクと静的リンクの違い、生成AI時代の新たなリスク、そしてSBOMを活用した予防策まで、実務で使える形で解説します。

動的リンクと静的リンクの理解

ライセンス違反を防ぐ上で、動的リンクと静的リンクの違いを理解することは極めて重要です。特にLGPLライセンスは、この違いによって適用される制約が大きく変わります。

静的リンクと動的リンクの違い

静的リンクはコンパイル時にライブラリのコードを実行ファイルに直接組み込む方式です。実行ファイルが大きくなりますが、ライブラリが別途必要ありません。一方、動的リンクは実行時にライブラリを参照する方式で、実行ファイルは小さくなりますが、実行時にライブラリファイル（.so、.dll、.dylibなど）が必要です。

リンク方式 ライブラリの組み込み ファイルサイズ 配布時の注意 GPL/LGPL影響
静的リンク 実行ファイルに直接組み込み 大きい ライブラリ不要 全体に影響する可能性大
動的リンク 実行時に参照 小さい ライブラリ必要 LGPLなら影響を限定可能

LGPLライセンスとリンク方式

LGPLが「Lesser GPL」と呼ばれるのは、ライブラリとしての利用時にGPLよりも制約が緩和されるためです。特に動的リンクの場合は、アプリケーション本体を独自ライセンスのまま維持しやすくなります。

実際のプロジェクトでLGPLライブラリを使用する場合、以下の点に注意が必要です。動的リンクであれば、LGPLライブラリを使用してもアプリケーション本体は独自のライセンスを維持できる可能性が高いです（ただし、LGPLのバージョンや具体的な使用方法により異なります）。LGPLライブラリ自体の改変を行った場合は、その改変部分をLGPLで公開する必要があります。

一方、静的リンクした場合は、アプリケーション全体がLGPLの派生物とみなされる可能性が高くなります。ただし、LGPLは静的リンク自体を禁止しているわけではなく、ユーザーがライブラリを差し替えて再リンクできる手段（オブジェクトファイルの提供など）を用意すれば、独自ライセンスを維持することも可能です（LGPLv3 第4条）。とはいえ、この条件を満たすのは多くの商用プロジェクトにとって負担が大きく、具体的な法的義務は使用方法や配布形態により異なるため、専門家への相談を推奨します。

生成AI時代の新たなライセンスリスク

AIが生成するコードの落とし穴

最近のプロジェクトでは、GitHub CopilotやCursorなどの生成AIツールを使うことが当たり前になってきました。しかし、これらのツールが提案するコードには、学習元のライセンスを完全に追跡することが困難という課題があります。AIモデルは多様なソースから学習しており、生成されたコードがどのライセンスの影響を受けているかを判断することは技術的に難しいのが現状です。

GitHubによる調査では、生成されるコードが学習データと一定以上一致する確率は極めて低いとされています2。しかし、それでもリスクはゼロではありません。特に特徴的なアルゴリズムや独自の実装パターンは、GPLライセンスのプロジェクトから学習された可能性があります。

SBOMによる防御策

このような意図しないライセンス混入を防ぐため、SBOM（Software Bill of Materials）の重要性が高まっています。SBOMは、ソフトウェアに含まれるすべてのコンポーネントとその依存関係を文書化したものです。GitHubでは、リポジトリのDependency graphと連携してSBOMを自動生成できるようになりました。

# .github/workflows/sbom-check.yml
name: SBOM Generation and License Check
on:
  push:
    branches: [ main ]
  pull_request:

jobs:
  sbom-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          format: spdx-json
          output-file: sbom.json
      
      - name: Check for problematic licenses
        run: |
          # SBOMからライセンス情報を抽出
          jq -r '.packages[].licenseConcluded' sbom.json | sort | uniq > licenses.txt
          
          # GPL系ライセンスのチェック（"GPL"はLGPL/AGPLにもマッチする）
          if grep "GPL" licenses.txt; then
            echo "::warning::Copyleft license detected in dependencies"
            cat licenses.txt
          fi

ただし、SBOMは依存関係のライセンスは管理できますが、AIが生成したコード断片のライセンスリスクまでは検出できません。FOSSIDやMend.ioなどの類似コード検出ツールを併用することで、より包括的なライセンス管理が可能になりますが、完全なリスク排除は困難であることも認識しておく必要があります。

実際に起きた事例の詳細

事件の概要

2025年7月、オープンソースコミュニティで大きな議論を呼ぶ事件が発生しました。sohzm氏が開発した「cheating-daddy」3というGPLv3ライセンスのプロジェクトを、YCに採択されたPickle社がApache 2.0ライセンスとして公開したのです。これは、GPLv3のライセンス条件に反する行為でした。

Pickle社のDaniel氏はHacker Newsで謝罪し、「初めてのOSSプロジェクトだったため、ライセンスを誤って表記してしまった」と説明しました1。しかし、技術コミュニティからは厳しい批判が寄せられました。特に問題視されたのは、謝罪後にgit履歴をforce pushで改ざんしようとした点です4。

時系列でみる事件の流れ

なぜライセンス違反は起きるのか？

知識不足による違反

多くの開発者は「オープンソース = 自由に使える」という誤解を持っています。確かにオープンソースは誰でも利用できますが、それぞれのライセンスには明確な制約があります。これらの制約を理解せずに使用すると、意図せずライセンス違反を引き起こす可能性があります。

特にGPLライセンスは「コピーレフト」と呼ばれる強い制約を持っています。GPLv3のセクション5(c)では「派生物も同じライセンスで頒布しなければならない」と定められており5、これに違反すると著作権侵害に該当する可能性があります。ただし、実際の法的判断は個々の状況により異なるため、疑問がある場合は法律の専門家に相談することが重要です。

違反の疑いがある行動パターン

今回のPickle社の事例では、以下のような行動が確認され、コミュニティから批判を受けました。

行動 説明 証拠
履歴の削除 git履歴を意図的に削除 force pushの痕跡6
作者名の削除 Copyright表記を削除 現在は修正済み
虚偽の主張 「3日で作った」と主張 HNでの言及
証拠隠滅 指摘後にforce pushで改ざん コミット履歴

主要なオープンソースライセンスの理解

オープンソースライセンスは、その制約の強さによって大きく分類できます。

制約の強さ ライセンス 主な特徴
最も強い GPL ・ソースコード公開の要求
・派生物も同一ライセンス（コピーレフト）
・商用利用可だが制約多い
強い LGPL ・ライブラリとしての利用時は制約緩和
・動的リンクなら独自ライセンス可能な場合が多い
・修正部分は公開要求
弱い Apache/MIT ・著作権表示の要求
・商用利用自由
・独自ライセンスでの再配布可
最も弱い パブリックドメイン/CC0 ・一切の制約なし
・著作権放棄
・完全に自由な利用可能

制約の強さは表の上（GPL）から下（パブリックドメイン）に向かって弱くなっていきます。

ライセンスごとの特徴

ライセンス 商用利用 改変 再配布 ライセンス継承 静的リンク時 動的リンク時
GPLv3 ✓ ✓ ✓ 必須 全体に影響 全体に影響
LGPL ✓ ✓ ✓ 一部必須 条件付きで独自可※ 本体は独自可※
Apache 2.0 ✓ ✓ ✓ 不要 独自可 独自可
MIT ✓ ✓ ✓ 不要 独自可 独自可

※ LGPLの静的リンク時は、ユーザーがライブラリを差し替えて再リンクできる手段（オブジェクトファイルの提供など）を用意すれば独自ライセンスを維持できる（LGPLv3 第4条）。また、動的リンク時でも、ライブラリ自体を改変した場合はその部分の公開が必要

GPLv3は商用利用も改変も再配布も可能ですが、ライセンスの継承が必須という強い制約があります。これが「コピーレフト」と呼ばれる仕組みで、GPLのコードを使った派生物もGPLライセンスを適用する必要があります。この仕組みは、自由ソフトウェアの理念を守るために設計されています。

ライセンス違反を防ぐ実践的な方法

依存関係の可視化とツールの活用

プロジェクトの依存関係を把握し、継続的にライセンスをチェックすることが重要です。CI/CDパイプラインに組み込むことで、新しい依存関係が追加されるたびに自動でチェックが走るようにできます。

# license-checkerによるチェック例
npm install -g license-checker
# 許可するライセンスのリストは組織のポリシーに応じて調整してください
license-checker --onlyAllow 'MIT;ISC;Apache-2.0;BSD'

「GPL検出」だけでは防げない — "Unknown" ライセンスの罠

ここまで紹介した --fail-on="GPL" 方式のチェックには、重大な盲点があります。GPLでもなく、SPDX識別子ですらないライセンスは、grepでは絶対に検出できないのです。

実際に筆者が趣味でやっているプロジェクトで、Fable 5にAgentic Codingをさせていたところ、依存関係（約1,300パッケージ）のライセンスチェックで、大半はMIT/Apache-2.0/ISC/BSD系で問題なしだったものの、pnpm licenses list で "Unknown" と表示されるパッケージの中から本物のライセンス問題が1件見つかりました。

チャートライブラリのapexchartsです。package.jsonのlicenseフィールドは "SEE LICENSE IN LICENSE" となっており、LICENSEファイルの実物を読むと、v5系からMITをやめてデュアルライセンス化されていました。無料のCommunity Licenseは年商200万USD未満の組織限定で、それ以上の企業は商用ライセンスの購入が必須。しかも npm install した時点で該当ライセンスに同意した扱いになります。v3/v4系まではMITだったため、「昔MITだったから大丈夫」という思い込みも通用しません。

このケースは「GPL」という文字列をどれだけ探しても引っかかりません。CIに組み込むなら、GPL検出に加えて"Unknown" や "SEE LICENSE" を fail させる設定が必須です。

# pnpmの場合: Unknownライセンスのパッケージが1つでもあれば失敗
pnpm licenses list --json | jq -e '.Unknown | length == 0'

pip-licensesの場合も、fail-onに UNKNOWN を加えることで同様のチェックができます。

uv run pip-licenses --partial-match --fail-on="GPL;LGPL;AGPL;UNKNOWN"

ただし、Unknownが即アウトというわけではありません。同じチェックで、licenseフィールドの記載漏れだけでLICENSEファイル実物はMITだった、というパッケージも見つかりました。Unknownは「機械では判定できないので、人間がLICENSEファイルを読んで判断せよ」というシグナルです。CIで機械的にブロックするのではなく、failさせて人間のレビューを挟む運用が現実的です。

なお、ライセンス表記が正しくても油断はできません。デュアルライセンス（例: MIT OR GPL-3.0 はMITを選択すればOK）や、Apache-2.0 AND LGPL-3.0 のような複合表記（未改変の共有ライブラリ利用なら慣行上問題になりにくい）など、SPDX式の解釈が必要なケースもあります。ツールの出力を鵜呑みにせず、引っかかったものは個別に確認する姿勢が重要です。

社内ガイドラインの整備

組織として明確な基準を設けることで、開発者が迷わずに判断できるようになります。推奨ライセンスとしてはMIT、Apache 2.0、BSDなど、要相談ライセンスとしてLGPL（動的リンクのみ）、原則禁止ライセンスとしてGPL、AGPL、SSPLなどを定めるとよいでしょう。ただし、実際のガイドライン策定には法務部門との連携が推奨されます。

違反してしまった場合の対処法

もし違反してしまった場合、最も重要なのは迅速かつ誠実な対応です。

絶対にやってはいけないこと

履歴の改ざんは最悪の対応です。force pushで証拠隠滅を図ると、技術的にも倫理的にも信頼を完全に失います。「知らなかった」という理由だけでは責任を免れることは難しいでしょう。プロのエンジニアとして、使用するコードのライセンスを確認することは重要な責務の一つです。

実務で使えるライセンス管理ツール

統合的なライセンス管理

言語別のツール（license-checker、pip-licenses、go-licenses、cargo-license）に加えて、FOSSologyのような専門ツールやSBOM生成ツール（CycloneDX）を組み合わせることで、包括的なライセンス管理が可能になります。

類似コード検出ツール

生成AIのリスクに対応するため、以下のツールの導入も検討すべきです。

ツール 特徴 用途
FOSSID 商用ツール、高精度 エンタープライズ向け
Mend.io SaaS型、CI/CD統合 DevOps環境向け
ScanCode OSS、包括的スキャン コスト重視

uvとPEP 723でのPythonライセンス管理

最近、「[入門] PythonでuvとPEP 723を使うと開発体験が10倍向上する理由」という記事でuvとPEP 723の基本的な使い方を紹介しましたが、これらのツールはライセンス管理にも非常に有効です。ここでは、ライセンスチェックに特化した使い方を解説します。

uvでの簡単なチェック方法

uvはRust製の高速なPythonパッケージマネージャーです。公式ベンチマークによれば、従来のpipより大幅に高速で、ライセンスチェックも素早く実行できます。

# uvのインストール
curl -LsSf https://astral.sh/uv/install.sh | sh

# 仮想環境の作成と依存関係のインストール
uv venv
uv pip install -r requirements.txt pip-licenses

# コピーレフトライセンスの検出
# --partial-match が重要: これがないと "GPL" は
# "GNU General Public License v3 (GPLv3)" のような実際のライセンス名にマッチしない
uv run pip-licenses --partial-match --fail-on="GPL;LGPL;AGPL"

PEP 723を使った単一ファイルでの管理

PEP 723により、Pythonスクリプト内に依存関係を直接記述できるようになりました。これにより、小規模なツールやスクリプトでのライセンス管理が劇的に簡単になります。ここではライセンスチェックに特化した実装例を示します。

注意点として、uv run はスクリプトのメタデータブロックに宣言された依存関係だけを含む隔離環境を作成します。つまり、pip-licensesがチェックするのは「このスクリプトに宣言した依存関係」であり、プロジェクトのrequirements.txtの内容ではありません。チェックしたいパッケージは、必ずメタデータブロックに列挙してください。

# /// script
# requires-python = ">=3.11"
# dependencies = [
#   # チェック対象の依存関係をここに列挙する
#   "requests>=2.31",
#   "pandas>=2.0",
#   # チェックツール本体
#   "pip-licenses>=5.0",
# ]
# ///

import subprocess

# ライセンスチェックの実行
# --partial-match がないと "GPL" は正式なライセンス名にマッチしない点に注意
result = subprocess.run(
    ["pip-licenses", "--partial-match", "--fail-on=GPL;LGPL;AGPL"],
    capture_output=True,
    text=True
)

if result.returncode != 0:
    print("コピーレフトライセンスが検出されました!")
    print(result.stdout)
else:
    print("ライセンスチェック完了")

実行は単純にこれだけです。

uv run check_licenses.py

これだけで、宣言した依存関係の自動インストールとライセンスチェックが完了します。依存関係が少ない小規模なスクリプトやツールで特に便利で、requirements.txtやsetup.pyを別途管理する必要がありません。

uvとPEP 723を活用することで、小規模なPythonスクリプトのライセンス管理が格段に簡単になります。

CI/CDへの組み込み例

GitHub Actionsでuvを使ったライセンスチェックを組み込む例です。

name: License Check with uv
on: [push, pull_request]

jobs:
  license-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Install uv
        uses: astral-sh/setup-uv@v6
      
      - name: Install dependencies
        run: |
          uv venv
          uv pip install -r requirements.txt pip-licenses
      
      # レポート生成を先に行う（fail-onで失敗すると後続が実行されないため）
      - name: Generate license report
        run: |
          uv run pip-licenses --format=json > licenses.json
          echo "Total packages: $(jq length licenses.json)"
          # コピーレフトライセンスの一覧を表示（"GPL"はLGPL/AGPLにもマッチ）
          jq -r '.[] | select(.License | test("GPL")) |
            "Warning: \(.Name): \(.License)"' licenses.json
      
      - name: Fail on copyleft licenses
        run: |
          uv run pip-licenses --partial-match --fail-on="GPL;LGPL;AGPL"

まとめ

オープンソースライセンスの管理は、現代のソフトウェア開発において避けて通れない課題です。特に以下の点に注意が必要です。

動的リンクと静的リンクの違いを理解することで、LGPLライブラリを適切に活用できます。生成AIが提案するコードのライセンスリスクを認識し、SBOMや類似コード検出ツールで対策を講じることが重要です。また、GPL系の検出だけでは不十分で、apexchartsのような商用デュアルライセンスは "Unknown" として現れるため、Unknownライセンスをfailさせて人間のレビューを挟む運用が欠かせません。そして何より、違反した場合は迅速かつ誠実に対応することが、信頼回復への唯一の道です。

Python開発者の場合は、uvとPEP 723を活用することで、ライセンス管理を含む開発体験が大幅に向上します。詳しくは「[入門] PythonでuvとPEP 723を使うと開発体験が10倍向上する理由」も参照してください。

今回のPickle社の事例は、「知らなかった」では済まされないことを改めて示しました。プロのエンジニアとして、適切なライセンス管理を心がけることが私たちの責任です。なお、本記事は技術的な観点からの解説であり、具体的な法的判断については必ず専門家に相談してください。

もしこの記事が「役に立った！」「勉強になった！」と思ったら、LGTM（いいね！）で応援してくださると嬉しいです。

  1. 当事者のDaniel氏がHacker Newsで「GPLプロジェクトをApacheと誤表記した」と公式謝罪 https://news.ycombinator.com/item?id=44461271 ↩ ↩2

  2. GitHubのAlbert Ziegler氏による調査 "GitHub Copilot research recitation" (2021) では、Copilotの提案のうち約150文字以上が訓練データと一致する「暗唱（recitation）」の発生率は約0.1%と報告されている。ただし、短いコード片や一般的なパターンはより高い確率で一致する可能性がある https://github.blog/ai-and-ml/github-copilot/github-copilot-research-recitation/ ↩

  3. 元プロジェクト: https://github.com/sohzm/cheating-daddy （GPLv3ライセンス） ↩

  4. force pushによる履歴改ざんを指摘するコメント: https://news.ycombinator.com/item?id=44461095 ↩

  5. GPLv3 Section 5(c): "You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy." なお、「派生物」の定義や範囲については法的解釈が分かれる場合があります ↩

  6. Pickle社のリポジトリ: https://github.com/pickle-com/glass （現在はGPLv3に修正済み） ↩

184
184
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
184
184

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?