ライセンスと依存ライブラリ

あなたが今日書いたコードのうち、自分で書いた行は数パーセントです。 残りは node_modules と go.sum の中にあります。

そして依存ライブラリは、技術的な負債であると同時に、法的なリスクでもあります。

・ライセンス違反 → 会社が訴えられる。最悪、製品のソースコード公開を求められる
・脆弱性         → 攻撃される
・乗っ取り       → 気づかないうちに悪意あるコードを取り込む

バグは直せますが、ライセンス違反は「直しました」で済まないことがあります。 この章は、多くの入門書が飛ばすところです。

ライセンスが無いものは使えない

まず前提として、世界中のコードには自動的に著作権があります。

ライセンスとは、著作権者が「この条件なら使っていい」と示した許諾です。

つまり、

GitHub に公開されている = 自由に使ってよい ← 誤り
LICENSE ファイルが無いリポジトリ            → 原則、使う権利がない

公開されていることと、使ってよいことは別です。 LICENSE が無いコードをコピーしてくるのは、実務では避けてください。

主要なライセンス

実務で出会うものは、だいたい次のどれかです。

コピーレフトの強さ

「自分たちのコードも公開しなければならなくなるか」の強さで並びます。

なし          MIT / BSD / Apache-2.0
  ↓
ファイル単位   MPL-2.0
  ↓
リンク条件つき LGPL
  ↓
派生物全体     GPL          ← 配布した場合
  ↓
SaaS も対象   AGPL          ← 配布しなくても、サービスとして提供したら対象

go-licenses report ./...        # Go
npx license-checker --summary   # Node

Apache-2.0 の特許条項

Apache-2.0 には特許の許諾が明示されています。 また、貢献者が特許訴訟を起こすと、その人の権利が終了する条項もあります。

企業が Apache-2.0 を好むのは、この明確さのためです。 MIT には特許についての記述がありません（そのぶん解釈の余地が残ります）。

依存の構造を把握する

直接依存    自分で package.json / go.mod に書いたもの
推移的依存  そのライブラリが依存しているもの（自分では選んでいない）

問題の大半は、推移的依存で起きます。 自分が入れた覚えのないパッケージが、数百個入っているのが普通です。

# なぜこの依存が入っているのかを追う
go mod why github.com/some/pkg
pnpm why some-package
npm ls some-package

脆弱性

依存ライブラリに脆弱性が見つかるのは、日常です。

govulncheck ./...          # Go（実際に到達するコードだけ報告してくれる）
pnpm audit                 # Node

サプライチェーン攻撃

依存を通じて悪意あるコードを送り込む攻撃が、近年増えています。

対策は地味なものばかりですが、効きます。

□ パッケージ名を目視で確認してから入れる（コピペ元を信用しない）
□ ロックファイルを使い、CI では pnpm install --frozen-lockfile / go mod verify
□ 依存の自動更新は、まとめず小さく、CI を通してからマージする
□ 見慣れないパッケージが増えていたら、PR で必ず質問する

依存を足すかどうかの判断

ライブラリを入れるのはタダではありません。

入れると得られるもの: 実装時間の節約、実績のある実装
入れると背負うもの  : ライセンス、脆弱性対応、更新追従、ビルド時間、学習コスト

判断のチェックリストです。

□ 自分で書くと何行になるか（10行で済むなら書く）
□ 最終コミットはいつか（2年動いていないなら要注意）
□ メンテナは何人か（1人だけなら、その人が離れたら終わる）
□ Issue と PR が放置されていないか
□ 依存の依存はいくつ増えるか
□ ライセンスは何か
□ 同じ用途のものが既にプロジェクトに入っていないか

AI が生成したコードのライセンス

AI と一緒に開発するでも扱いますが、ここでも触れておきます。

生成されたコードが既存の OSS とほぼ同一になることがあります。 その OSS が GPL だった場合、由来を知らないまま取り込むリスクがあります。

□ 生成されたコードが、特定のライブラリの実装と酷似していないか
□ 会社が定めた AI ツールの利用ルールに従っているか
□ 大きな塊をそのまま貼り付けていないか

「AI が書いたので分かりません」は、法務上の説明になりません。

迷ったら聞く

ライセンスの判断は、エンジニアが1人で決めるものではありません。

□ AGPL / GPL のライブラリを入れたい     → 必ず上長・法務に相談
□ OSS に会社のコードを出したい          → 会社の手続きを確認
□ 顧客に納品する製品に依存を追加する    → ライセンス条件を確認
□ ライセンスが書かれていないコードを使いたい → 使わない

実務の落とし穴まとめ

1. LICENSE の無いコードをコピー — 使う権利が無い
2. AGPL / GPL を自己判断で導入 — 自社コードの公開義務が生じ得る
3. MIT だから何もしなくてよいと思う — 著作権表示とライセンス文の同梱が必要
4. ロックファイルをコミットしない — 再現性が失われ、すり替えにも気づけない
5. CVSS スコアだけで判断 — その機能を使っているかを先に見る
6. ロックファイルの差分をレビューしない — 依存の混入に気づけない
7. 数行で書けるものにライブラリを使う — 他人のリリース都合を背負う
8. メンテされていないライブラリを選ぶ — 脆弱性が出ても直らない
9. AI 生成コードの由来を確認しない — 説明できない権利関係を抱える

まとめ

• ライセンスが無い = 使えない。公開されていることと使ってよいことは別
• AGPL はネットワーク提供でも公開義務が生じ得る。GPL は配布時。 どちらも自己判断で入れない
• MIT / BSD / Apache-2.0 でも表示義務がある。ライセンス一覧は自動生成して同梱する
• 問題の多くは推移的依存で起きる。go mod why / pnpm why で追う
• ロックファイルは必ずコミットする
• 脆弱性は CVE / CVSS で管理されるが、自分たちが使っているかを先に見る
• サプライチェーン攻撃に対しては、ロックファイル・小さな更新・ ロックファイルの差分を読むことが効く
• 依存を足すのはタダではない。メンテ状況・依存の数・ライセンスを見て決める
• 判断に迷ったら法務・上長へ。 これは相談すべき事柄であって、面倒ではない

公式ドキュメント

迷ったら一次情報に戻ってください。

章末問題

次の章では、こうした日々の判断をチームでどう回すか—— スクラム、見積もり、そして詰まった時にいつ声を上げるかを扱います。