OSSを採用する前に確認すること — 7項目のチェックリスト

このチェックリストは、確認にかかる時間が短く、判断への影響が大きい順に並んでいます。

ライセンスが合わなければ、他をどれだけ調べても採用できません。 逆に、開発プロセスの細かい指標は、確認に時間がかかるわりに あなたのプロジェクトへの影響が間接的です。

上から順に見て、途中で「これは採れない」と分かったら、そこで止めてかまいません。

最初に見ます。数十秒で終わり、結果によっては検討そのものが終わります。

• SPDX の識別子を見る（MIT、Apache-2.0、AGPL-3.0-only など）
• 最低限、次の3点を自分の用途と照らす
  • 商用利用ができるか
  • 改変して配布できるか
  • 自分のソースを公開する義務が生じるか（コピーレフト系かどうか）
• リポジトリの LICENSE と、パッケージのメタデータの両方を見る。 食い違っていることが実際にあります
• vendor/、third_party/、assets/ に別ライセンスの同梱物が無いか

判断に迷う条項があれば、技術者だけで決めずに確認を取ってください。 このサイトを含め、どのツールも法的な判断はしません。

→ License

**「そのライブラリに脆弱性があるか」ではなく、「使うバージョンに影響するか」**を見ます。

1. 使う予定のバージョンを決める
2. 公開されている Advisory の Affected versions と Patched versions を読む
3. 修正版が出ていれば、そこへ上げられるかを検討する
4. 出ていなければ、Advisory に回避策の記載が無いかを見る

件数の多さを危険度と読まないでください。 広く使われているものほど多くの人が調べ、多くの Advisory が公開されます。 誰も見ていないライブラリの Advisory が 0 件なのは、調べられていないだけかもしれません。

自分のプロジェクト側でも、npm audit / pip-audit / composer audit や osv-scanner で、 依存の依存まで含めて走査しておくと確実です。

→ Vulnerabilities

見落とされがちですが、事故になったときの影響が最も大きい項目です。

npm や PyPI のパッケージが宣言している repository は自己申告で、 別のリポジトリを指すように書くことができます。

名前を1文字変えた偽のパッケージが、有名なリポジトリを指しているケースは実在します。 このとき、リポジトリの情報だけを見て判断すると、 本物の評価を偽物に貼り付けてしまいます。

確認すること。

• レジストリのページで、公開者と公開日を見る
• ダウンロード数が不自然に少なくないか
• 名前が、意図したものと1文字も違わないか
• npm なら provenance の表示があるか（どのリポジトリのどのワークフローから作られたか）
• リポジトリ側に、そのパッケージ名が実在するか

OSSカルテでは、この紐付けが検証できたかどうかをバッジで表示し、 検証できない場合はリポジトリ由来の指標を出さない方針にしています。

4. 保守の状態

• Archived になっていないか。 ここだけは推測が要りません
• パッケージが Deprecated になっていないか
• 直近のリリースの日付と、その変更が何だったか
• 未解決の Issue に、最近のものへの返信があるか

更新が少ないこと自体は問題ではありません。 完成して仕様が固まったライブラリは、直す場所がないので更新が止まります。 見るべきは「止まっているか」ではなく「必要なときに動くか」です。

→ Maintained

5. 脆弱性の報告先

自分が問題を見つけたとき、どこへ連絡するかを採用時に確認しておきます。 SECURITY.md があるか、無ければ組織の .github リポジトリにあるか。

過去の Advisory が公開されているなら、 報告から公開までの流れが実際に機能していた証拠になります。 これは SECURITY.md の有無より強い材料です。

→ Security-Policy

6. 代替手段

同じ目的のライブラリが他にあるかを、採用の時点で1つは調べておきます。 必要になってから探すと、移行の判断まで時間がかかります。

• 標準ライブラリや言語機能で置き換えられないか
• 移行先として現実的なものがあるか
• 後から差し替えられるよう、薄いラッパを1枚挟んでおく価値があるか

7. 止まったときの対応

これが最後で、最も重要です。

• そのライブラリの更新が止まったとき、自分たちは困るか
• コードの規模は、最悪フォークして引き取れる大きさか
• 依存の中心にあるのか、周辺にあるのか

1人で保守されている小さなライブラリでも、 数百行なら最悪自分で引き取れます。この場合、 Contributors や Code-Review が 低くても、実務上のリスクは小さくなります。

逆に、大きく複雑なライブラリを事業の中心に置く場合は、 継続性を正直に見積もってください。これは品質の問題ではなく、事業判断です。

コピーして使ってください。

[ ] 1. ライセンスを確認した（SPDX / 商用 / 改変 / 公開義務）
[ ] 2. 使うバージョンに影響する脆弱性を確認した
[ ] 3. パッケージとリポジトリの紐付けを確認した
[ ] 4. 保守の状態を確認した（Archived / Deprecated / 直近の変更）
[ ] 5. 脆弱性の報告先を確認した
[ ] 6. 代替手段を確認した
[ ] 7. 更新が止まったときの対応を決めた

すべてに丸が付く必要はありません。 付かない項目について「承知のうえで使う」と決められていれば、それで十分です。

判断を記録に残しておくと、あとで引き継ぐときに役立ちます。