spdx / spdx-spec

The SPDX specification in MarkDown and HTML formats.
https://spdx.github.io/spdx-spec/
Other
287 stars 137 forks source link

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

Open kestewart opened 7 years ago

kestewart commented 7 years ago

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 commented 7 years ago

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.

 Subject: Version the matching guidelines
 Date: Fri, 4 Aug 2017 12:20:48 -0700
 Message-ID: <20170804192048.GV23356@valgrind.tremily.us>
goneall commented 5 months ago

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