Miqto
一次データの全数調査

NOASSERTIONの意味

GitHubのAPIやSBOMでライセンスが NOASSERTION と出て、意味を調べに来た方向けの記事です。
結論から言うと、NOASSERTIONは「ライセンスが無い」でも「危険」でもなく、「判定しなかった・できなかった」という意味です。仕様の定義と、GitHubの判定ライブラリのソースコードで確かめました。
そのうえで、GitHubでNOASSERTIONと判定されたセルフホスト向けソフトウェア179件のライセンスファイルを、1件ずつ全部読みました。中身は標準ライセンスから、オープンソースではないものまでバラバラでした。

公開:2026-09-18読了:約14分データ取得日:2026-09-18
先に免責
本記事は法律上の助言ではありません。ライセンスの解釈には専門的な判断が必要です。ライセンスは変更されます。本記事の分類は2026年9月18日時点の各リポジトリの既定ブランチにあるライセンスファイルに基づきます。「オープンソースではない」は「OSI(Open Source Initiative)承認のライセンスではない」という意味で使っています。実際に利用・提供する前に、必ず最新のライセンス本文を確認し、必要に応じて専門家に相談してください。
結論を先に(2026年9月18日取得)
179NOASSERTIONと判定GitHub上の1,122件中16.0%
46中身は標準のOSSライセンス書式や前置きの差だけ
37OSI承認ライセンスではないソースアベイラブル・非営利・商用
98判定の閾値(既定値)判定ライブラリLicenseeの設定

01SPDX仕様での定義

NOASSERTION は、ソフトウェアのライセンス情報を表す標準形式 SPDX の特別な値です。SPDX 2.3 仕様「7.13 Concluded license」(作成者が結論づけたライセンス)には、次のように書かれています。

SPDX 2.3 仕様 7.13 Concluded license(原文)
NOASSERTION if: the SPDX document creator has attempted to but cannot reach a reasonable objective determination; the SPDX document creator has made no attempt to determine this field; or the SPDX document creator has intentionally provided no information (no meaning should be implied by doing so).

つまり次の3つのどれかです。

判定できなかった
客観的な判定を試みたが、合理的な結論に至らなかった
判定しなかった
この項目を判定しようとしなかった
あえて書かなかった
意図的に情報を出さなかった。「そこから何らかの意味を読み取るべきではない」と明記されている

※「7.15 Declared license」(作者が宣言したライセンス)のNOASSERTIONは、このうち後の2つ(判定しなかった・あえて書かなかった)だけです。「判定できなかった」は含まれません。

「ライセンスが無い」ことは NOASSERTION ではなく NONE で表します。7.13では「利用できるライセンスが無いと結論した場合」、7.15では「パッケージにライセンス情報がまったく含まれていない場合」が NONE です。

SPDXの特別な値
意味読み違えやすい解釈
NOASSERTION判定しなかった・判定できなかった・あえて書かなかった「ライセンスが無い」「危険」ではない
NONEライセンスが無い(無いと結論した/情報がまったく無い)「自由に使える」ではない

02GitHubで「Other」と出る仕組み

GitHubのリポジトリ画面やAPIで NOASSERTION(画面上は「Other」)と出る場合、その判定に使われているのは Licensee というオープンソースのライブラリです。GitHubの公式ドキュメントにこうあります。

GitHub Docs「Licensing a repository」(原文)
The open source Ruby gem Licensee compares the repository's LICENSE file to a short list of known licenses.

そこでLicenseeのソースコードを直接読みました(2026年9月14日のコミット時点)。

# lib/licensee.rb
CONFIDENCE_THRESHOLD = 98

# lib/licensee/license.rb
# `other` - The project had a license, but we were not able to detect it
# `no-license` - The project is not licensed (e.g., all rights reserved)
# NOTE: A lack of detected license will be a nil license

# lib/licensee/license/identity_methods.rb
return 'NOASSERTION' if key == 'other'
'NONE' if key == 'no-license'

NOASSERTION は「ライセンスファイルはあったが、既知のライセンスとして検出できなかった」という意味です。Licenseeの一致の閾値の既定値は98で、標準ライセンスの本文に少し文章を足しただけでも届かないことがあります。

※GitHub本番で使われている設定値そのものは、公開情報では確認できませんでした。ここで示すのはLicenseeのソースコード上の既定値です。

実際のAPIの応答はこうなります。

# gh api repos/csa-admin-org/csa-admin/license --jq .license
{"key":"other","name":"Other","node_id":"MDc6TGljZW5zZTA=","spdx_id":"NOASSERTION","url":null}
GitHub APIでのライセンス表示の読み方
spdx_idLicenseeの判定意味
MIT など既知のライセンス既知のライセンスとして検出できた
NOASSERTIONotherライセンスファイルはあるが、既知のどれとも判定できなかった
nullnilライセンスファイルを検出できなかった

031,122件のうち179件がNOASSERTION

では、実際にどのくらいの頻度で出るのか。セルフホスト向けソフトウェアの定番リスト awesome-selfhosted-data(2026年9月17日のコミット)に載っている1,348件を対象にしました。このうち、ソースコードのURLがGitHubのリポジトリを指しているもの1,123件(組織ページを指す17件は除外)について、GitHub APIでライセンス判定を取得し、取得できた1,122件を集計しました。

GitHubのライセンス判定(1,122件)
既知のライセンス910
NOASSERTION179
null(検出なし)33
約6件に1件がNOASSERTIONでした。取得はGitHub GraphQL APIで80件ずつ、計15リクエストです。

04179件の中身を全部読んだ

179件すべてについて、GitHubが判定に使ったライセンスファイルの本文を取得し、1件ずつ読んで分類しました。

NOASSERTION 179件の中身
① 標準ライセンス46
⑥ OSI承認ではない37
② オープンコア30
③ 複数ライセンス28
④ 本文が無い26
⑤ 追加条項つき8
⑦ 比較対象に無い4
標準ライセンスとして使えそうなのは約4分の1。一方でOSI承認ライセンスではないものが約5分の1、一部に商用ライセンスが混ざるオープンコア(②)と追加条項つき(⑤)を足すとさらに約5分の1あります。NOASSERTIONという表示だけでは、どれなのか分かりません。
7つの分類と実例(2026年9月18日時点・既定ブランチのライセンスファイル)
分類件数中身実例
① 中身は標準のOSSライセンス46標準ライセンスの全文に、プロジェクト名や告知文の前置き、見出し、コメント記号などが付いているだけmautic/mautic(GPL-3.0の前にプロジェクト名・告知・同梱物の一覧)、calzoneman/sync(MIT全文が /* */ で囲まれている)、jhuckaby/Cronicle(MIT全文の前に見出し)
② オープンコア30基本は標準ライセンスだが、ee/enterprise/ などのディレクトリだけ別ライセンスchatwoot/chatwoot(MIT+enterprise/は別)、PostHog/posthog(MIT+ee/は別)、metabase/metabase(AGPL+最上位のenterpriseディレクトリは商用ライセンス)
③ 複数ライセンス28選択制、部分ごとに別、同梱物のライセンスを1つのファイルに連結openremote/openremote(AGPLの告知+同梱物のライセンス全文を連結)、odoo/odoo(LGPL-3.0+GPL-3.0本文)、mattermost/mattermost(コンパイル版はMIT、ソースはAGPLか商用、Admin Toolsなど一部はApache)
④ ライセンス本文が無い26告知文やSPDX識別子、別ファイルへの参照だけKinto/kinto(Apacheの告知文のみ)、xbmc/xbmc(SPDX識別子と参照のみ)、easysoft/zentaopms(2つのライセンスの参照のみ)
⑤ 標準ライセンス+追加条項8標準ライセンスに、ブランド表示の維持や公開先の制限などの条項が足されているopen-webui/open-webui(BSD-3+ブランド表示の条項。30日間の利用者50人以下などの例外あり)、Countly/countly-server(AGPL第7条でロゴ表示の維持)、pretalx/pretalx(AGPL第7条で生成ページ下部の帰属表示の維持)、Websoft9/websoft9(LGPL-3.0+クラウドのマーケットプレイスへのイメージ公開を書面許可なしに禁止)
⑥ OSI承認ライセンスではない37ソースアベイラブル、非営利限定、商用ライセンス、独自規約n8n-io/n8n(Sustainable Use License)、getsentry/sentry(Functional Source License)、outline/outline(BSL 1.1)、invoiceninja/invoiceninja(Elastic License 2.0)、getumbrel/umbrel(PolyForm Noncommercial)
⑦ SPDX登録済みだが比較対象に無い4SPDXに登録されたライセンスだが、GitHubの比較対象の一覧に無いMacWarrior/clipbucket-v5(Attribution Assurance License)、opensource-socialnetwork/opensource-socialnetwork(Cryptographic Autonomy License 1.0)。この2つはOSI承認ライセンス

※⑥の各プロジェクトは、自らを「fair source」「open core」などと説明していることがあります。ここでの分類はOSI承認ライセンスかどうかだけを基準にしたもので、プロジェクトの姿勢を評価するものではありません。

MITとそっくりでも、OSI承認ライセンスではない例
⑥の中に、O'Saasy License というライセンスが3件ありました(csa-admin-org/csa-adminmarcantondahmen/automadHemmeligOrg/Hemmelig.app)。本文の大部分はMITとまったく同じですが、次の条件が足されています。

「No licensee or downstream recipient may use the Software (including any modified or derivative versions) to directly compete with the original Licensor by offering it to third parties as a hosted, managed, or Software-as-a-Service (SaaS) product or cloud service where the primary value of the service is the functionality of the Software itself.」

つまりライセンサーと直接競合する形で、そのソフトウェアの機能そのものを主な価値とするホスティング・マネージド・SaaSとして第三者に提供することを禁じています。SaaSでの利用を一律に禁じているわけではありません。冒頭数行だけ読むとMITに見えます。GitHubの表示がMITではなくNOASSERTIONになっているのは、この追加の1文があるからでした。

05リストの記載と中身が違うもの

awesome-selfhosted-data は各ソフトのライセンスを人の手で記載しています。その記載(2026年9月17日のコミット)と、2026年9月18日時点の既定ブランチのライセンスファイルを比べると、食い違うものがありました。ただし理由は1つではありません。

ライセンスが変更されたもの

リストでは自由なライセンスと記載されていて、現在の既定ブランチはOSI承認ライセンスではないものです。古いブランチや古いバージョンは、旧ライセンスのまま残っているものが多くあります。

リストの記載と、現在の既定ブランチのライセンスファイル
リポジトリリストの記載現在の既定ブランチ旧ライセンスが残っている範囲
csa-admin-org/csa-adminMITO'Saasy License
marcantondahmen/automadMITO'Saasy License(v2ブランチ)v1ブランチはMIT
HemmeligOrg/Hemmelig.appMITO'Saasy License(v7ブランチ)mainブランチはMIT
emqx/emqxApache-2.0BSL 1.1READMEに「5.9.0からApache 2.0からBSL 1.1へ移行」と明記
chartbrew/chartbrewMITFunctional Source License(FSL-1.1-MIT)
baptisteArno/typebot.ioAGPL-3.0Functional Source License(FSL-1.1、Apache 2.0 Future)v3.0.0から。それより前のバージョンは別ライセンス
pimcore/pimcoreGPL-3.0Pimcore Open Core Licensev12.0.0から。v11系はGPLv3と商用のデュアル
coreshop/CoreShopGPL-3.0CoreShop Commercial License5.0.0から。4.1系はGPLv3と商用のデュアル

逆に、オープンソースライセンスのまま種類が変わったものもあります。HaschekSolutions/pictsharepretalx/pretalx はリストではApache-2.0ですが、現在はAGPL-3.0です。

ライセンスは変わっておらず、範囲や記載の違いだったもの

flipt-io/flipt
既定のv2ブランチはFair Core Licenseですが、mainブランチは今もGPL-3.0です。リストの記載(GPL-3.0)はmainブランチと一致します
sbpp/sourcebans-pp
Elastic License 2.0 なのは LICENSE.txt が対象とするWebパネルで、プラグインは LICENSE-plugins.txt でGPLv3です
apankrat/nullboard
2019年の最初のLICENSEからBSD-2-Clause に Commons Clause が付いていて、ライセンスは変わっていません。リストは BSD-2-Clause とだけ記載しています

リストの誤りだと言いたいのではありません。ライセンスは後から変更されますし、ブランチやコンポーネントごとに違うこともあります。人手で整備されたリストがそれを1行で表すのは難しいことです。リストや紹介記事、GitHubの表示を根拠にせず、自分が使うブランチ・バージョン・部分のライセンスファイルを読む必要があるということです。

06NOASSERTIONを見たら確認すること

179件を読んで、見分けるための手がかりはほぼ決まっていました。

ライセンスファイルを開いて、上から順に確認する
  1. 自分が使うのは既定ブランチか、特定のバージョンか → ブランチやタグによってライセンスが違うことがある
  2. 冒頭に「Portions of this software are licensed as follows」や ee/enterprise/ の指定があるか → あればオープンコア(②)。使う部分がどのディレクトリに入っているかを確認する
  3. ライセンスの名前:Business Source License/Functional Source License/Fair Core License/Elastic License/Sustainable Use License/Commons Clause/PolyForm/O'Saasy/Creative Commons の NonCommercial → OSI承認ライセンスではない(⑥)。何が禁止されているかは本文の条件を読む
  4. 「Additional Terms」「Section 7」「branding」「logo」「attribution」 → 追加条項(⑤)がないか、その段落を例外まで含めて読む
  5. 本文が短い告知文や参照だけ → 参照先のファイル(LICENSE-APACHECOPYING.GPLv2 など)を開く(④)
  6. 複数のライセンスの全文が続いている → 自分が使う部分にどれが適用されるかの説明を探す(③)
  7. ここまで該当しなければ、標準ライセンスの全文と見比べる(①か⑦のことが多い)
GitHubでは gh api repos/{owner}/{repo}/license --jq '.path' で、GitHubが判定に使ったファイル名が分かります。

なお、SPDX形式のSBOM(ソフトウェア部品表)でNOASSERTIONと出た場合も、意味は01の仕様どおりです。そのツールがなぜ判定しなかったかは、ツールごとに違います。

07調べる途中で間違えたこと

この調査で出した誤り
#何を間違えたかどう気づいたか
1最初はキーワードで機械的に分類しようとし、「proprietary」「noncommercial」を含むファイルをオープンソースではないと判定した。この2語はGPLやAGPLの本文そのものに含まれる("proprietary programs"、"noncommercially")ため、GPL・AGPLのファイルがまとめて誤分類された誤分類した分類に、リストでAGPLやGPLと記載されたものが大量に入っていた
2固有名で判定するように直した機械分類も、人手で読んだ結果と179件中26件しか一致しなかった全件を読んで比べた。この記事の分類はすべて人手によるもの
3公開前の原稿で、flipt-io/fliptsbpp/sourcebans-ppapankrat/nullboard を「リストでは自由なライセンスだが、現在はオープンソースではない」例として並べていた公開前の検証で、3件ともライセンスを変えたのではなかった(ブランチ・コンポーネントの違い、最初からの条項)と分かり、05で分けて書いた
4公開前の原稿で、O'Saasy License を「SaaSでの提供を禁止」と要約していた本文を読み直すと「ライセンサーと直接競合し、ソフトウェアの機能そのものが主な価値のサービス」に限定されていた。要約で条件を落とすと、ライセンスを実際より厳しく描いてしまう
5以前の記事で、openremote/openremote を「API表示はNOASSERTIONだが本文はAGPL」と書いていたライセンスファイルはAGPLの告知に、同梱物のライセンス全文を連結したもので、判定できないのはその連結が理由。「本文はAGPL」という説明は不正確だったので、該当記事も直した

データ・出典

  1. SPDX Specification v2.3「7 Package information」(7.13 Concluded license・7.15 Declared license の NOASSERTION と NONE の定義)
  2. GitHub Docs「Licensing a repository」(Licenseeで判定している旨)
  3. licensee/licenseelib/licensee.rblib/licensee/license.rblib/licensee/license/identity_methods.rb、2026-09-14のコミット時点)
  4. awesome-selfhosted/awesome-selfhosted-data(コミット 730207c・2026-09-17。software/*.ymlsource_code_urllicenses
  5. OSI Approved Licenses(Attribution Assurance License・Cryptographic Autonomy License 1.0 の承認状況)
  6. 取得方法:GitHub GraphQL API の repository.licenseInfo を80件ずつ(15リクエスト)、NOASSERTIONの179件は REST API GET /repos/{owner}/{repo}/license でファイル本文を取得(2026-09-18)。ブランチ・バージョンごとの違いは各リポジトリのファイルとREADMEで確認。いずれもGitHub公式APIです
  7. 分類:179件すべてのライセンスファイルを人手で読んで分類しました。判断が分かれるものは該当段落の全文を確認し、公開前に別の検証者が名前を出したリポジトリを1件ずつ取り直して確認しています
本記事は法律上の助言ではありません。分類は筆者がライセンスファイルを読んで行ったもので、法的な解釈を保証するものではありません。「オープンソースではない」はOSI承認ライセンスではないという意味であり、各プロジェクトの姿勢やライセンスの妥当性を評価するものではありません。ライセンスは変更されます。本記事の内容は2026年9月18日時点の各リポジトリの既定ブランチのライセンスファイルに基づき、その後の変更は反映していません。ブランチやバージョン、コンポーネントによって異なるライセンスが適用される場合があります。リストの記載との違いは、記載の時点とライセンス変更の時点のずれや、1行で表しきれない複雑さによって生じうるものであり、リストの正誤を評価するものではありません。実際に利用・改変・提供する前に、必ず最新のライセンス本文を確認し、必要に応じて専門家に相談してください。