1) Different headers for thesame license issue (and header matching guidelines):

How to capture in License List and for license matching guideline purposes

A)    Key examples: MPL v2.0 (Exhibit A or Exhibit A & B); L/GPL licenses ("or later" or "only")

B)    Agreement that this information (e.g. is it GPL v2 only or GPL v2 orlater - effectively creating a disjunctive license scenario) needs to be captured. Question is how to capture/implement?

i)      PROPOSAL 1:  leave as is on license list now: capture as a different "line item" (with distinct license name and identifier) for each header scenario that can change the meaning of the license (e.g. GPL-2.0-only; GPL-2.0+)

a)     if we stay with this route, propose that short identifier says "only" in it.  

(1)   But then, what about when you aren't sure?  Default to "or later."

b)     potential problems - won't match with other lists (e.g. Email from Debian guy)

ii)     PROPOSAL 2: license list is just the licenses themselves.  Headers or alternative exhibits are captured on a separate list that then modifies the license list.  

a)     e.g. On the master license list, GPL v2 would be just that GPL-2.0 (without indicating "or later" or "only"), then the header list would have the headers variations of the "or later" text present or removed.  The short identifier could then be modified by a sub-set of identifier or identifier extension, such as "GPL-2.0" + "or later" or "GPL-v2.0" + "only" - likewise for MPL and its exhibits.  Presumably, each scenario would have it's own extensionmodifier

(1)   potential problems - more to keep track of and more complicated.  Is the net result all the different than Proposal 1?

b)     this could also be extended to include disjunctive licensing scenarios - which can then be broken into two types:

(1)   choose X or Y license OR this is under X license (i.e. default license) with the option to license it under Y or Z; if Y or Z, you have to designate in header

(a)   PROPOSAL: to not get into this level of detail at this point... Already have a way to identify disjunctive license sets in spec, so have a starting point.  

C)    Tangent issue here: GPL exceptions - how to display license text?  Should it be the entire GPL license + exception; or just the header and exception; or just match on the exception text?   

i)      How does this interplay with proposals above? If #1, then as is on list, but still need to answer above questions, if #2, then could treat exceptions as part of modifier/extension list?

ii)     either way, practical matching guidelines for tool-makers is difficult - how can this work practically speaking

2) License text itself/matching guidelines:

What is included as the license text itself? Is this what is matched against, i.e. entire or how much of license text in file (currently .txt files)

A)    License name/title - we have our SPDX naming protocol which may or may not track verbatim on the license name, e.g. SPDX's "GNU General Public License v2.0" shows up as "GNU General Public License" in the license itself, with "Version 2, June 1991" on a separate line.

i)      seems like our license files on SPDX website/download should have the SPDX full name - but should it also have whatever the actual license says?

ii)     How does this play out in terms of matching? i.e. don't want a non-match on slight variations in license name/title where rest of actual license text is verbatim match

a)     PROPOSAL: ignore the title line and match on actual text so don't end up with non-matches just because someone titled it differently or left off the title

B)    Extra text issue:  extra text or notice at end of beginning of license or after it says "end of terms" - is this part of the license text for matching purposes?  Put another way, if it was missing, should it not be considered a match?  Should theses bits be part of the license text for our list and for purposes of matching?

i)      e.g. Creative Commons licenses - text at end re: "Creative Commons Notice" at end; notices in GPL, LGPL, Apache on how to apply the license -

a)     PROPOSAL:  matching guidelines say you can ignore this text.  

(1)   If so, then remove from license text in SPDX license text files?  If leave it in files, do we want to indicate where/what can be "ignored" for tool-makers (instead of leaving it up to them to make the call)?

C)    Replaceable text issue:  comes into play with "vanity" BSD and Apache 1.1 licenses

i)      "copyright holder" v. "copyright owner" - can we agree (jurisdictionally) that this is the same meaning?

ii)     where to put the brackets around what can be "ignored" by scanning tools for matching purposes?

iii)   also see Historical Permission Notice license