個人開発でも必要なライセンス監査 — 601パッケージを調査して分かったこと

はじめに — 「ライセンスなんて気にしなくていい」は本当か

npmパッケージのライセンス。npm install するたびに数十・数百の依存パッケージが追加されますが、そのライセンスをひとつずつ確認している開発者はどれくらいいるでしょうか。

「MITだから大丈夫」「個人開発だしそこまで気にしなくていい」。正直なところ、自分もそう思っていました。しかし ZERONOVA LAB で6つのプロダクトを公開し、無料ツールを76個提供するようになると、「もし GPL のパッケージが紛れ込んでいたら？」という不安が無視できなくなりました。

2026年2月9日、IdeaSPool（601パッケージ）と Wakulier（260パッケージ）のライセンスを一斉監査しました。この記事では、その過程で直面した実務的な判断と学びを共有します。

なぜライセンス監査をやったのか

きっかけは FFmpeg WASM の GPL 問題でした。

ZERONOVA LAB の動画フォーマット変換ツール（/tools/video-converter）で使っていた @ffmpeg/core のデフォルトビルドには、GPL ライセンスのライブラリ（libx264、libx265、libpostproc）が含まれていました。

@ffmpeg/core のデフォルトビルドに libx264（GPL v2+）、libx265（GPL v2+）、libpostproc（GPL v2+）が含まれていた。FFmpeg は --enable-gpl フラグ付きでビルドすると全体が GPL になるため、この WASM バイナリをサイトに配信すると GPL のソースコード公開義務が発生するリスクがあった

この問題を是正する過程で、「他のパッケージは大丈夫なのか？」という疑問が生まれ、全プロダクトの依存パッケージを監査することにしました。

監査の方法

license-checker を使って、本番依存パッケージのライセンスを一括で取得しました。

npx license-checker --production --json > licenses.json

出力された JSON から、各パッケージのライセンスを集計し、GPL/LGPL/MPL などコピーレフト系のライセンスを重点的に確認しました。

IdeaSPool: 601パッケージの監査結果

IdeaSPool の本番依存パッケージ601件の内訳は以下の通りでした。

npm packages: 601 dependencies in production。MIT: 510, ISC: 42, Apache-2.0: 21, BSD: 17。すべてパーミッシブ。LGPL-3.0（sharp-libvips）はdevDependencyのみ。MPL-2.0（Vercel Analytics, lightningcss）は未改変で使用

全体の97%以上がMIT・ISC・BSDといったパーミッシブライセンスでした。しかし、残りの数パーセントに判断が必要なパッケージが含まれていました。

LGPL-3.0: sharp-libvips

画像処理ライブラリ sharp の内部依存である sharp-libvips がLGPL-3.0でした。LGPLは「動的リンクなら利用側のソースコード公開義務は発生しない」という特徴があります。

ただし重要な注意点があります。

Zeronova

LGPL の sharp-libvips は SaaS として配信する分には問題ないと理解している。ただ、将来的にElectronアプリやオンプレミスに展開する場合はどうなる？

Zeronova

了解。現時点は問題なし。配布形態の変更時にレビューするというアクションを残しておこう。

MPL-2.0: Vercel Analytics, lightningcss

MPL-2.0（Mozilla Public License）はファイル単位のコピーレフトです。MPLのファイルを改変した場合、そのファイルのソースコードを公開する義務がありますが、改変せずに使う分には問題ありません。Vercel Analytics も lightningcss も、ソースコードを改変せずにそのまま利用しているため、追加の義務は発生しませんでした。

Apache-2.0 のグレーゾーン

監査で最も判断が難しかったのが Apache-2.0 ライセンスでした。

Apache-2.0 のセクション4には「再配布時に NOTICE ファイルの内容を含めること」という義務があります。問題は、「SaaS での配信は再配布に当たるのか」という点です。

Apache-2.0 詳細分析: サーバーコード（@ai-sdk/google, ai）は再配布ではないので義務なし。クライアントJSバンドル（class-variance-authority via shadcn）はグレーゾーン

IdeaSPool で使っている Apache-2.0 パッケージを2つのカテゴリに分けて判断しました。

サーバーサイドのみで実行されるパッケージ（@ai-sdk/google、ai）は、コードがユーザーに配布されないため再配布義務は発生しません。

クライアントサイドのJSバンドルに含まれるパッケージ（class-variance-authority via shadcn）は、ミニファイされたJavaScriptがブラウザに配信されるため、技術的には「配布」と解釈する余地があります。

NOTICE ファイルが存在しない → Section 4(d) は適用されない。業界慣行として、SaaS 企業が JS バンドルのライセンスを公開しているケースはない。Next.js/Vercel 自体もやっていない

最終的に「法的義務としては不要だが、透明性のベストプラクティスとして /licenses ページに主要パッケージのライセンス情報を掲載する」という方針にしました。

Wakulier: 260パッケージの監査と Gemini SDK 移行

Wakulier では260パッケージを監査し、82%がMIT、2%がコピーレフト系という結果でした。

監査と同時に、Gemini SDK の移行（@google/generative-ai → @google/genai）もClaude Codeで実施しました。

Gemini SDK 移行: @google/generative-ai → @google/genai。API 変更: result.response.text() → result.text（プロパティ）。systemInstruction が正式サポートに

旧 SDK では systemInstruction を設定するためにフェイクのチャット履歴を使うワークアラウンドが必要でしたが、新 SDK では config.systemInstruction で正式にサポートされました。返り値の型も result.response.text() (メソッド) から result.text (プロパティ、string | undefined) に変わり、?? "" でのフォールバックが必要でした。

FFmpeg GPL 問題の是正

監査の発端となった FFmpeg WASM の GPL 問題は、以下の手順で是正しました。

1. @ffmpeg/core の CDN 配信を停止し、セルフホストに移行
2. GitHub Actions で LGPL 準拠の WASM をビルド（GPL ライブラリを sed パッチで除外）
3. MP4（H.264）出力を廃止し、WebM（VP8/libvpx）に統一
4. /licenses ページを新設し、FFmpeg に含まれる全ライブラリのライセンスを一覧表示

@ffmpeg/core の GPL → LGPL ビルドに移行。libx264, libx265, libpostproc を sed パッチで除外。MP4 出力を廃止し WebM に統一

GitHub Actions のビルドワークフロー（.github/workflows/build-ffmpeg-wasm.yml）では、FFmpeg のソースコードをクローンした後に sed パッチで --enable-gpl フラグと GPL ライブラリ（libx264、libx265、libpostproc）の有効化行を削除し、LGPL のみで WASM をビルドします。ビルド成果物は site/public/ffmpeg/ にセルフホストし、外部CDNへの依存を排除しています。

H.264 のデコードは FFmpeg 内蔵デコーダー（LGPL）で引き続き利用可能なため、入力側の対応形式には影響がありません。出力を WebM（VP8/libvpx、BSD ライセンス）に限定することで、GPL コンポーネントを完全に排除しました。ユーザーから見ると MP4 の出力オプションがなくなりますが、WebM は主要ブラウザで再生可能であり、実用上の影響は軽微です。

CI での自動ブロック

今後 GPL パッケージが誤って追加されるのを防ぐため、CI に license-checker を組み込みました。

npx license-checker --production --failOn "GPL-2.0;GPL-3.0;AGPL-3.0"

これにより、GPL/AGPL パッケージが本番依存に含まれた場合、CI が自動的にビルドを失敗させます。

Zeronova

ライセンス監査を1回やるだけだと、次に npm install した時にまた GPL が紛れ込む可能性がある。CI で自動チェックしたい。

Zeronova

それを入れよう。GPL と AGPL を対象に。LGPL は SaaS なら問題ないが、将来の配布形態変更に備えて別途ウォッチする。

プライバシーポリシーの更新

ライセンス監査と合わせて、プライバシーポリシーも更新しました。

IdeaSPool では GitHub 連携によるデータ共有の開示、Supabase のリージョン明記（AWS 東京リージョン ap-northeast-1）、Cloudflare Turnstile による IP・ブラウザ情報の取得開示を追加。

Wakulier では AI データ処理セクションを新設し、Gemini API へのデータ送信、最大55日間の保持（有料ティアでの非ML利用）、モデルトレーニングには使用されない旨を明記しました。

プライバシーポリシー v2.0 → v2.1 更新。AI データ処理セクション追加: Gemini へのデータ送信、最大55日保持、モデルトレーニング非使用を明記

まとめ — 個人開発でもライセンス監査をやるべき理由

601 + 260 = 861パッケージの監査を通じて得た学びをまとめます。

1. 全体の97%はパーミッシブだが、残り3%に判断が必要なものが潜む: MIT/ISC/BSDだけなら安心だが、LGPL・MPL・Apache-2.0 には配布形態に応じた実務判断が必要
2. SaaS と配布は区別する: SaaS はサーバー実行なので LGPL の配布義務は発生しない。ただし Electron やオンプレミス展開時は再検討が必要
3. Apache-2.0 の帰属義務は「再配布時」にのみ発生する: SaaS のクライアント JS バンドルは法的にはグレーゾーンだが、業界慣行として義務は課されていない
4. CI で自動チェックを入れる: license-checker --failOn で GPL/AGPL の混入を自動ブロックする仕組みは必須
5. /licenses ページは法的義務ではなく透明性のベストプラクティス: LGPL 義務の対応（差し替え手段の提供）とは別に、主要パッケージのライセンスを一覧表示することで信頼性を高める

ライセンス監査は地味な作業ですが、プロダクトが成長してから問題が発覚すると対応コストが跳ね上がります。個人開発の早い段階で、四半期ごとの定期レビューの仕組みを入れておくことを推奨します。

関連記事:

• 個人開発でもやるべきセキュリティ監査チェックリスト — セキュリティ面の監査手法
• E-E-A-T × SEO改善を個人開発サイトに実装した全記録 — /licenses ページの実装経緯