NOASSERTION on 5,792 project pages: what that label means, and when it is wrong

Open SourceDevn Nie3 replies

Devn NieMember#1

5,792 of the 45,667 projects we track have a licence field reading NOASSERTION. It is the third most common value on this site, after MIT and Apache-2.0, and it means something quite narrow.

What the detector does

GitHub reads the licence file and compares it against a list of known texts. When the comparison is confident, it returns an SPDX identifier — MIT, Apache-2.0, GPL-3.0 and so on. When the file is a licence the list does not have, or a known licence with something attached, it returns NOASSERTION, which in SPDX means "the licence could not be determined".

That is all. It is a statement about the detector, not about the project, and in particular it is not a legal conclusion.

The three things behind the number

Licences the detector does not know. The Business Source License, the Sustainable Use License, the Elastic License, a project's own licence with a custom name: no standard identifier, so NOASSERTION. Terraform, Vault, n8n, Open WebUI and Dify are all in this group, and all of them have a licence that is perfectly clear to a human and a commercial problem for a deployer.

Known licences with extra text. A file that is the Apache licence plus a branding clause, or the AGPL plus a preamble the detector does not recognise. The extra text is what breaks the match.

Files that are not licences at all. Documentation about licensing, a NOTICE file, a licence for one directory of a monorepo, or a repository where the licence lives somewhere else entirely.

When the label is wrong

The label is wrong in the case that matters most to a reader: when the repository genuinely has no licence and the detector still found a file it did not recognise. A LICENSE file that is a copyright notice with no permission grant is not a licence, and it looks the same on our page as a custom licence.

This is why the answer cannot be automated. Distinguishing "a licence we do not recognise" from "no licence" is exactly the judgement a detector cannot make, and it is why the reviewed field being asked for on the licence-header thread is worth doing by hand for the projects people actually deploy.

3 replies

ValerieRegular#2

The framing "a statement about the detector, not about the project" is the useful part, and it is worth putting on the page itself.

I read NOASSERTION as a warning sign by reflex, and half the time the project is under a perfectly ordinary Apache licence that happens to have a NOTICE file next to it. The label is doing its job by being honest; we are the ones who over-read it.

JudyMember#3

In reply to Valerie (#2)

The fourth case is worth naming: a monorepo where the licence is per package. The root file covers one directory and the others have their own, or have none. The detector reads the root and reports on the root, and the page then describes the whole repository with a licence that may not apply to the package you are about to install.

That is a case where the link to the file helps but does not solve it, because you have to know which directory you care about.

Devn NieAuthorMember#4

In reply to Judy (#3)

Both additions are right, and both point at the same fix: a link to the file, at a known commit, with the date we read it. A reader who can click through does not need our label to be perfect, and the label stops being a judgement call once the file is one click away.

More in Open Source