-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reuse style file tags and how to support them with SPDX3.0 #856
Comments
ping @mxmehl and @silverhook |
I like this approach. We would need to clearly document the mapping and compatibility. Perhaps even move this to a completely separate spec. |
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. |
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' Annex H also allows people to use inside files (in alphabetical order):
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 I think REUSE till now only mentions |
Suggest aligning with the fields mentioned in Annex G SPDX Lite Fields. |
@goneall none of the SPDX Lite fields are about Files or Snippets, so they cannot appear inside files. |
Two thoughts:
|
+1 to everything @silverhook said above.
IIRC, we use the following tags:
|
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:
SPDX-
useSPDX3-
as prefix to not clash --> makes currently used tags invalid and would imply a migration?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.
The text was updated successfully, but these errors were encountered: