Dealing with discovered license "noise"

I'm looking at the record for [npm/npmjs/-/util-promisify/2.1.0](https://clearlydefined.io/definitions/npm/npmjs/-/util-promisify/2.1.0). The package.json file states MIT. But the LICENSE file mentions a bunch of different licenses, with each license annotated with what part of the content it applies to. None of the annotations reference the actual project content, rendering (IMHO) the LICENSE file basically meaningless. I believe that the declared license, MIT, is the actual license and the rest is just noise. Anthony opened [an issue](https://github.com/juliangruber/util-promisify/issues/7) against the project repository and the resulting discussion confirms my analysis (FWIW, it occurred to me to open the issue, but I hesitated when I noticed that the last commit was two years ago; lesson learned).

When I look at the ClearlyDefined record, I see a _declared_ license and a bunch of _discovered_ licenses, but am not aware of a means of determining whether or not the list of discovered licenses is actually valid. In this particular example, the discovered licenses are just noise.

Contrast this with [npm/npmjs/-/jsdom/15.1.1](https://clearlydefined.io/definitions/npm/npmjs/-/jsdom/15.1.1). In this case, the declared license is `MIT`, and `LGPL-2.0-or-later` and `MIT` are discovered. In this case, the discovery is valid: there is a file in the content with a header that declares LGPL-2.0-or-later. I conclude, then, that the license for this content is `MIT and LGPL-2.0-or-later`.

So the problem statement is this... the automated tools that I'm working with have no way of distinguishing between the two (other than to ignore LICENSE files, I suppose).

There's a bit of a philosophical aspect to this. In the first case, the LICENSE file describes how the content is licensed, but is not itself licensed under the licenses it describes (it gets really philosophical when you factor in that all/most license files are not themselves generally licensed under the the terms that they describe). I'll admit that when you think about it like this, it all just gets weird (at least in the general case).

The _Files_ section describes the license of the file as being the conjunction of all of the licenses discovered in the file. IMHO, this is wrong: in this case, the LICENSE file neither expresses the license of the rest of the content, nor does it express what license by which it itself is distributed; and so the concluded license on the LICENSE file should be `NONE` or perhaps `NOASSERTION` (my understanding is that `NOASSERTION` means "something else").

If we do something like that, then we have a fighting chance of making the discovered licenses useful information in a lot more cases.

Note that test data is yet another case. I've run into numerous projects (including one of my own), especially ones that work with licenses, where license scanners identify licenses expressed in test data as the license of the content. [This](https://github.com/eclipse/dash-licenses/blob/master/core/src/test/java/licenses.json) file, for example, lists a bunch of SPDX codes, but is itself licensed under the EPL-2.0 (as expressed in the `/.reuse/dep5` file).

I suggested on today's curation call that introducing a notion of a _concluded_ license might be helpful. I suspect that for most content, the concluded license is relatively obvious (e.g., when the declared license matches the discovered licenses). I can understand, however, how including a notion of a concluded license might introduce some liability and that taking a "just the facts" approach is probably the best approach.