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 <[email protected]> wrote: > Thanks Mike - responses below! > > On Oct 17, 2019, at 7:34 AM, Michael Dolan <[email protected]> > 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 <[email protected]> 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? > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3781): https://lists.spdx.org/g/Spdx-tech/message/3781 Mute This Topic: https://lists.spdx.org/mt/34668773/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
