Reuse style file tags and how to support them with SPDX3.0

[maxhbr]

The Annex H currently defines File tags by referencing the tag value format (as it is defined in 2.3). From that there arise multiple questions regarding the migration to and support in 3.0.

Problem 1: breaking changes in property names and the general structure

As this for 2.3 allows to use arbitrary properties from the file information, which might be renamed and restructured, it is not clear how to parse and support comments in existing files.

There are some options that come to mind:

• stay with the current set of properties from 2.3 and do not change --> a mapping needs to be maintained and not all features from 3.0 are available
• support both, names from 2.3 and 3.0 --> "old" parsers do not support everything and miss stuff or fail
• only support 3.0 --> this is breaking on both sides
• instead of SPDX- use SPDX3- as prefix to not clash --> makes currently used tags invalid and would imply a migration?
• add a version statement --> an additional line ...

Some Properties got moved

The license and copyright information was previously part of the file properties, but is expected to be expressed via relationships. This makes it more complex.

Problem 2: there is not yet a tag-value serialization

The current state of the model does not yet define a serialization, which could be used for defining the same concept on the level of SPDX3.

[maxhbr]

ping @mxmehl and @silverhook

[goneall]

stay with the current set of properties from 2.3 and do not change --> a mapping needs to be maintained and not all features from 3.0 are available

I like this approach. We would need to clearly document the mapping and compatibility. Perhaps even move this to a completely separate spec.

[silverhook]

I’d be most in favour of either:

stay with the current set of properties from 2.3 and do not change --> a mapping needs to be maintained and not all features from 3.0 are available

or

instead of SPDX- use SPDX3- as prefix to not clash --> makes currently used tags invalid and would imply a migration?

But would need to understand how the mapping thing would work in practice. I’m a tiny bit wary of introducing yet another spec just to keep things afloat.

[zvr]

I personally believe that the information on how to denote SPDX information in files has to get a major overhaul -- and with @mxmehl and @silverhook we have discussed a number of changes. For example specifying how to add this information not only inside files but alongside files (useful for non-text files).

Just to give more concrete info on the current state: we have good ol' SPDX-License-Identifier: (Annex E) which we can all agree will not change.

Annex H also allows people to use inside files (in alphabetical order):

File	Snippet
1. SPDX-ArtifactOfProjectHomePage:	17. SPDX-SnippetBegin
2. SPDX-ArtifactOfProjectName:	18. SPDX-SnippetEnd
3. SPDX-ArtifactOfProjectURI:
4. SPDX-FileAttributionText:
5. SPDX-FileChecksum:	19. SPDX-LicenseInfoInSnippet:
6. SPDX-FileComment:	20. SPDX-SnippetAttributionText:
7. SPDX-FileContributor:	21. SPDX-SnippetByteRange:
8. SPDX-FileCopyrightText:	22. SPDX-SnippetComment:
9. SPDX-FileDependency:	23. SPDX-SnippetCopyrightText:
10. SPDX-FileName:	24. SPDX-SnippetFromFileSPDXID:
11. SPDX-FileNotice:	25. SPDX-SnippetLicenseComments:
12. SPDX-FileType:	26. SPDX-SnippetLicenseConcluded:
13. SPDX-LicenseComments:	27. SPDX-SnippetLineRange:
14. SPDX-LicenseConcluded:	28. SPDX-SnippetName:
15. SPDX-LicenseInfoInFile:	29. SPDX-SnippetSPDXID:
16. SPDX-SPDXID:

I'm not even sure that all 29 of them are useful, so we might as well be explicit to what is allowed instead of a blanket "use anything by prepending SPDX-".

I think REUSE till now only mentions SPDX-FileCopyrightText (no. 8) above so we can definitely keep this one.

[goneall]

I'm not even sure that all 29 of them are useful, so we might as well be explicit to what is allowed instead of a blanket "use anything by prepending SPDX-".

Suggest aligning with the fields mentioned in Annex G SPDX Lite Fields.

[zvr]

@goneall none of the SPDX Lite fields are about Files or Snippets, so they cannot appear inside files.

[goneall]

none of the SPDX Lite fields are about Files or Snippets, so they cannot appear inside files.

Two thoughts:

• We include a union of the Lite fields with the file fields
• Alternatively, we include the file fields in the Lite definition

[mxmehl]

I’d be most in favour of either:

stay with the current set of properties from 2.3 and do not change --> a mapping needs to be maintained and not all features from 3.0 are available

or

instead of SPDX- use SPDX3- as prefix to not clash --> makes currently used tags invalid and would imply a migration?

But would need to understand how the mapping thing would work in practice. I’m a tiny bit wary of introducing yet another spec just to keep things afloat.

+1 to everything @silverhook said above.

I think REUSE till now only mentions SPDX-FileCopyrightText (no. 8) above so we can definitely keep this one.

IIRC, we use the following tags:

• SPDX-License-Identifier
• SPDX-FileCopyrightText
• SPDX-FileContributor (via reuse annotate --contributor, will be in 2.x)
• SPDX-SnippetBegin
• SPDX-SnippetEnd
• SPDX-SnippetCopyrightText