Make the matching template formats of license part of the spec - add matching guidelines annotation to SPDX licenses and to NON-SPDX licenses.

[kestewart]

Thomas: Make the matching template formats of license part of the spec - both SPDX listed licenses and NON-SPDX listed licenses. Would like to add matching guidelines annotation to SPDX licenses and to NON-SPDX licenses. Also add templating for copyright holders and dates.
XML specification of license texts. Has templating. Matching guidelines.
Want to add cross references to license that are on the SPDX license list.
Concern: schema to store information about license is ok, but matching templates could become problematic. May be differnently to apply consistently. Old templating language in specification is only available on listed licenses. Make other properties to listed licenses. XML language is being used by legal team to line up with guidelines, but may not be standardized enough. Non-standardized input format, move to output format.
This is possibly 3 different proposals:
Add additional properties to OTHER LICENSE INFORMATION file to bring up to same level as SPDX listed licenses.
Add additional fields for listed licenses, so information present in XML can be made visible as start of output representations (for instance bullets, copyright) (we don’t want them using the input format)
Add in OTHER LICENSE INFORMATION that is not in SPDX license list model to the SPDX license lists (ie. comment)

Some harmonization here is going to be needed. We probably want to include license exceptions in remodeling discussion. This is probably a 3.0 feature.

[wking]

On Tue, Sep 05, 2017 at 05:09:08PM +0000, Kate Stewart wrote: Thomas: Make the matching template formats of license part of the spec…

Yes please :). This would address [1].

Some harmonization here is going to be needed. We probably want to include license exceptions in remodeling discussion. This is probably a 3.0 feature.

I'm in favor of simplifying the matching guidelines by moving more of the human-oriented language there into something that's easier to automate. But I don't think we need to block spec-inclusion until that happens. We already reference the wiggly human-oriented language from the spec [2], and having that text in a spec appendix instead of an external, unversioned doc is a step in the right direction regardless of how solid the matching content is. [1]: https://lists.spdx.org/pipermail/spdx-legal/2017-August/002103.html Subject: Version the matching guidelines Date: Fri, 4 Aug 2017 12:20:48 -0700 Message-ID: <[email protected]> [2]: https://spdx.org/spdx-specification-21-web-version#h.2mjng0vqrghe

[goneall]

Since this is a non-breaking change, moving this to 3.1