Clarify licenseInfoInFiles

[tsteenbe]

We are implementing SPDX-2.2 in OSS Review Toolkit and we would like some clarifications on how to correctly implement NONE and NOASSERTION in licenseInfoInFiles

Question 1) Is it correct to assume the NONE must imply that list size is 1? e.g.

licenseInfoInFiles:
- "NONE"

and invalid SPDX is

licenseInfoInFiles:
- "NONE"
- "NOASSERTION"
- "MIT"

Example say we have file foobar.c and ScanCode returns the following findings

• Apache-2.0 start at line 1 and ending at line 19
• MIT start at line 34 and ending at line 36
• NOASSERTION match at line 70

Question 2) is the correct way to encode this in licenseInfoInFiles below A) or B)?
Based on the text of licenseInfoInFiles in SPDX File and SPDX package - I would B is correct but that would mean we lose a NOASSERTION from ScanCode in our SPDX export.

Case A

licenseInfoInFiles:
- "Apache-2.0"
- "NOASSERTION"
- "MIT"

or

Case B

licenseInfoInFiles:
- "Apache-2.0"
- "MIT"

[swinslow]

cc'ing @jlovejoy who may have input and historical knowledge here also!

For question 1, my view is that yes, NONE and NOASSERTION should imply list size is 1. They should not be listed in combination with other licenses (or with each other) in the LicenseInfoInFile entries for one file.

According to the spec, NONE means "the file contains no license information whatsoever," so I don't think it could be used in a file where there is also NOASSERTION or any license for any part of it.

Similarly, the NOASSERTION meanings for that field I think imply that no other licenses could be listed.

If the SPDX creator was trying to communicate that some portions of the file had NONE while others were under one or more licenses, I think Snippets would be the correct way to do that.

For question 2, I think Case B is the correct outcome here, for similar reasons as mentioned above. If wanting to retain the precision to indicate NOASSERTION for portions of the file while certain licenses for other portions, I think that Snippets would be the correct way to do that with precision.

All that said, I didn't draft those sections so this is just my view, not authoritative :)

[goneall]

There is a related discussion issue #49 and #50 which looks like it should be resolved in 3.0.

Right now I don't think we have a definitive answer, but I would tend to agree with Steve that Snippets should be used if practical. Knowing how most scanners work, however, it may not be possible to capture the line range to create a snippet.

If you can't capture it as a snippet, I would go with Case B in answer to question 2.

[tsteenbe]

if we capture this via snippets we may think about adding a licenseInfoInSnippets - which I don't like as it would make the spec more complex...

[goneall]

if we capture this via snippets we may think about adding a licenseInfoInSnippets

It makes the spec a bit more complex, but it also makes it more consistent. I personally like the consistency.

[jlovejoy]

@swinslow analysis is correct. I think the spec definitions are clear, but maybe that's because I spent a fair amount of time on them and some example could be used? By way of explanation:

NONE, if the file contains no license information whatsoever; or

NOASSERTION, if:
(i) the SPDX file creator has made no attempt to determine this field; or
(ii) the SPDX file creator has intentionally provided no information (no meaning should be implied by doing so).

Note, the NOASSERTION was intended as a kind of "I don't know" value stemming from the real possibility that someone didn't even really look at all as indicated by (i) - in which case NONE would not be appropriate. (ii) was allowing it to be used more broadly, I suppose in the case where someone looked a little, but didn't feel comfortable (or the tooling 'wasn't comfortable') with a match.

What I don't understand about the original question from @tsteenbe is you state, "NOASSERTION match at line 70" in your example. How can there ever be a "match" for NOASSERTION? That doesn't make sense to me and seems to contradict the definition of NOASSERTION - am I missing something here?

I'm also wondering if the spec formatting is causing a bit of confusion. Note the last bit of text,
If license information for more than one license is contained in the file or if the license information offers the package recipient a choice of licenses, then each of the choices should be listed as a separate entry.
Is not meant to be part of the definition of NOASSERTION, but a standalone item. Perhaps an order change of the text might help clarify that?

[kestewart]

While I completely agree that NONE should only have 1 valued, I can see where we might want to use NOASSERTION to indicate there is something, but not sure what - ie. "I don't know".

@jlovejoy, @swinslow - if you're not comfortable with that use of NOASSERTION, then what should probably be done is that fragment be converted to a "LicenseRef" and referred to that way?

[swinslow]

@kestewart Given the definitions in 2.2 as the spec currently exists, I don't think that NOASSERTION is intended to be used in this way. A LicenseRef can always be used to indicate whatever the SPDX document creator wants it to indicate, so yes, I expect it could be used as you describe.

[zvr]

But @swinslow, Clause 10 https://spdx.github.io/spdx-spec/v2-draft/other-licensing-information-detected/ says that LicenseRef is to be used for licenses, not licensing information in general.
So I'm not sure how to create something that says "I don't know".

LicenseID: LicenseRef-IDontKnow
ExtractedText: <text> Mandatory... hmmm, I don't know </text>
LicenseName: NOASSERTION
LicenseComment: <text> what can I say?   LicenseName was mandatory </text>

[goneall]

Moving to the 3.0 milestone.

[goneall]

the licenseInfoInXXX properties have been removed in 3.0 resolving this issue. Closing.