Re: [spdx-tech] matching guidelines updates

William Bartholomew <iamwillbar@...>

During the discussion about SPDX 3.0 and positioning SPDX as an option for the various SBoM efforts that are going on, one of the discussion points was about making the specification more digestible by moving content that is secondary to the format of an SPDX document out of the specification and into a separate document (or documents), this suggestion included the license list, license matching guidelines, and applying SPDX identifiers to source code.

There is a variety of content we could position beside the specification (best practices, sample scenarios and example documents, how to apply to source code, license matching) so I don't think we should be beholden to how it is laid out today and possible create a new section on the site that could house that information (which could be referenced from the specification where relevant). I'm happy to help out with the technical aspects of that but since I'm focusing on SPDX 3.0 for the moment I'd prefer to do it in the context of that if it's not urgent.

On Thu, Oct 17, 2019 at 7:41 AM J Lovejoy <opensource@...> wrote:
Thanks Mike - responses below!

On Oct 17, 2019, at 7:34 AM, Michael Dolan <mdolan@...> wrote:

My personal responses in-line below. I've not discussed this with Steve or anyone... (and I will openly admit I'm not as familiar with these parts are you all are).

On Wed, Oct 16, 2019 at 11:14 PM J Lovejoy <opensource@...> wrote:

1) what do we do with the webpage/URL and various places that link to such? redirect to the appendix in the spec? but then what happens when the spec updates?  (It’s really important for people to be able to easily read/find this).  Could we generate the webpage from the spec Appendix markup?

For specs that have subcomponents with faster moving sections, we have had other communities pull those out into separate GitHub .md file and the spec includes the current snapshot of that file at the time of the spec being approved and published as final. That way they have a record of the version at the time it was approved in the spec itself. But the .md file evolves at the pace it needs to.

Yes, I think this is how it has been set up in the PR - as it’s own Appendix and .md file, so one can refer to it separately there. I suppose we could change links to point to the Github .md, rather than the spec, that way it’s “standalone” - but I’m not familiar enough with how the spec is pushed and updated at the individual PR/file level, so could use Gary and Kate’s input here. 

2) does this then mean the matching guidelines must follow the cycles/versions of the spec? (it has had it’s own cycle because it doesn’t update very often)

Similar to my answer above, but is it possible to move the "current source" for the guidelines out into a separate .md file? 
yes, already done.

3) what about the list of equivalent words- can we have that live as a separate file in the license list Github repo and then have the main relevant matching guideline link to it? and if so, should that list live in the license list repo or with the spec?

Similar reaction as above.
I think the idea of having this list as a separate file is the easy part (apparently this makes it easier for tools to consume), but the question is: where should that file live?

Join to automatically receive all group messages.