Repository navigation
Reuse style file tags and how to support them with SPDX3.0 #12
Description
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-useSPDX3-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.
Reacted by Arthit Suriyawongkul
Activity
maxhbr commentedon Jul 11, 2023
ping @mxmehl and @silverhook
goneall commentedon Jul 11, 2023
I like this approach. We would need to clearly document the mapping and compatibility. Perhaps even move this to a completely separate spec.
silverhook commentedon Jul 12, 2023
I’d be most in favour of either:
or
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 commentedon Jul 12, 2023
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):
SPDX-ArtifactOfProjectHomePage:SPDX-SnippetBeginSPDX-ArtifactOfProjectName:SPDX-SnippetEndSPDX-ArtifactOfProjectURI:SPDX-FileAttributionText:SPDX-FileChecksum:SPDX-LicenseInfoInSnippet:SPDX-FileComment:SPDX-SnippetAttributionText:SPDX-FileContributor:SPDX-SnippetByteRange:SPDX-FileCopyrightText:SPDX-SnippetComment:SPDX-FileDependency:SPDX-SnippetCopyrightText:SPDX-FileName:SPDX-SnippetFromFileSPDXID:SPDX-FileNotice:SPDX-SnippetLicenseComments:SPDX-FileType:SPDX-SnippetLicenseConcluded:SPDX-LicenseComments:SPDX-SnippetLineRange:SPDX-LicenseConcluded:SPDX-SnippetName:SPDX-LicenseInfoInFile:SPDX-SnippetSPDXID: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 commentedon Jul 12, 2023
Suggest aligning with the fields mentioned in Annex G SPDX Lite Fields.
zvr commentedon Jul 12, 2023
@goneall none of the SPDX Lite fields are about Files or Snippets, so they cannot appear inside files.
goneall commentedon Jul 12, 2023
Two thoughts:
mxmehl commentedon Jul 17, 2023
+1 to everything @silverhook said above.
IIRC, we use the following tags:
SPDX-License-IdentifierSPDX-FileCopyrightTextSPDX-FileContributor(viareuse annotate --contributor, will be in 2.x)SPDX-SnippetBeginSPDX-SnippetEndSPDX-SnippetCopyrightTextFreso commentedon Jul 28, 2024
A year tomorrow since the last activity in this issue. Should downstream users continue to rely on SPDX 2.3 for in-file tagging (e.g., using
SPDX-FileTypeinstead ofSPDX-SoftwarePurpose(and/or-ContentType))?silverhook commentedon Jul 28, 2024
IIRC,
SPDX-ArtifactOfProjetc*is deprecated (I suppose in favour of PURL and SWID), and it would be really useful to have a way to indicate the origin of the file or snippet (PURL/SWID don’t work, because they are limited to Package-level, so something would need to change in the spec or Annex H.).We have currently released REUSE 3.0 and made it to still rely on SPDX 2.3. It would be great if we can eventually bump that to the newest SPDX spec, though.
zvr commentedon Jul 28, 2024
Well, SPDXv2 was saying "you can use
SPDX-tagname: valuein files, where tagname is a tag defined in the tag-value format."In SPDXv3 we don't have a tag-value format (yet?), so the same approach would not work.
My comment above was an attempt to codify which such entries exist, so that we can have them listed somewhere. It will most probably not be in the spec itself (unless we come up with a final version of an informative annex in the next days), but it might be in another document, or even in REUSE.
goneall commentedon Aug 27, 2024
@kestewart @zvr - what do you think? Should we move this to 3.1? Resolve the issue?
zvr commentedon Aug 28, 2024
I don't think we have anything in the spec right now mentioning this, since the "how to put info in files" annex was moved to the spdx/using repo.
goneall commentedon Aug 29, 2024
I'll move this issue to the using repo
silverhook commentedon Sep 12, 2024
I‘m happy to help with this, but the calls are hard for me to join.
goneall commentedon Sep 13, 2024
Thanks @silverhook - Perhaps we can setup something like a Google Doc or some other method of collaborating on potential solutions. @zvr @kestewart - any thoughts?