License とは — OpenSSF Scorecard の見方

何を見るチェックか

Scorecard は、リポジトリに LICENSE（LICENSE.md、COPYING、LICENCE なども対象）が置かれているかを探し、その中身が既知のOSSライセンスとして識別できるかを確認します。

評価は段階的です。

「既知」の判定には SPDX の識別子が使われます。 MIT、Apache-2.0、BSD-3-Clause、GPL-3.0-only などです。

点が低いということは、そのコードを使ってよいかどうかが、書面で明示されていない、という意味です。

ここは他の項目と性質が違います。実務上、直接の障害になります。

とくに 「GitHub に公開されているから自由に使える」というのは誤りです。明示が無い限り、再配布や改変の可否は不明のままです。

逆に、「ライセンスがあるから使える」も早合点です。

満点でも、あなたの用途で使えるとは限りません。 Scorecard が見ているのは「識別できるライセンスがあるか」であって、その条件があなたに合うかではありません。たとえば AGPL-3.0 は識別できる正当なOSSライセンスなので満点になりますが、自社サービスに組み込む場合には、ソース公開の義務が問題になることがあります。
リポジトリのライセンスと、配布パッケージのライセンスが違うことがあります。 package.json や composer.json の license フィールドと、 LICENSE ファイルの中身が食い違っているケースは実在します。
一部のディレクトリだけ別ライセンス、ということもあります。 同梱されたフォントや画像、ベンダリングされた第三者コードなどです。

このサイトを含め、どのツールも法的な判断はしません。 最終的には LICENSE の原文を読んでください。

SPDX の識別子を確認する。 MIT なのか GPL-3.0 なのかで扱いが変わります。
自分の使い方と照らす。 最低限、次の3点を確認します。
- 商用利用が可能か
- 改変して配布できるか
- 自分のソースを公開する義務が生じるか（コピーレフト系かどうか）
リポジトリと配布パッケージの両方を見る。 食い違っている場合は、より制限の強いほうを前提に検討してください。
同梱物を見る。 vendor/、third_party/、assets/ などに、別ライセンスのファイルが入っていないかを確認します。
判断に迷う条項があれば、法務に確認する。 ここは技術者だけで決めないほうがよい領域です。

なお、このサイトが表示するライセンス情報は参考です。 実際の利用条件はリポジトリ内の LICENSE 原文をご確認ください。

リポジトリのルートに LICENSE を置きます。GitHub の「Add file → Create new file」でファイル名を LICENSE にすると、テンプレートを選ぶボタンが出ます。

あわせて確認したいこと。

パッケージのメタデータにも同じライセンスを書く。 package.json の "license": "MIT"、composer.json の "license"、 Python なら pyproject.toml の license です。 ここと LICENSE ファイルが食い違っていると、利用者側の自動判定が割れます。
SPDX の識別子をそのまま使う。 MIT License ではなく MIT、Apache 2 ではなく Apache-2.0 と書きます。
文面を書き換えない。 著作権表示の行（年と名前）以外を編集すると、既知のライセンスとして識別されなくなり、利用者側で扱いが面倒になります。
同梱している第三者のコードがあれば、その旨を NOTICE などに残す。

ライセンスの明示は、利用者にとって最も確認コストが低く、かつ採用の可否に直結する情報です。ここは早めに整えておく価値があります。