Legal Team/Minutes/2012-04-05 (LF Collab Summit)

SPDX Legal Work Group meeting minutes - 5 April 2012

face-to-face meeting at Linux Collab Summit

SPDX Legal Team - To-Dos

 

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

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

1. A)Key examples: MPL v2.0 (Exhibit A or Exhibit A & B); L/GPL licenses ("or later" or "only")
2. B)Agreement that this information (e.g. is it GPL v2 only or GPL v2 or later - effectively creating a disjunctive license scenario) needs to be captured. Question is how to capture/implement?
1. 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+) 
1. a)if we stay with this route, propose that short identifier says "only" in it.  
1. (1)But then, what about when you aren't sure?  Default to "or later."
2. b)potential problems - won't match with other lists (e.g. Email from Debian guy)
2. 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.  
1. 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 extension modifier
1. (1)potential problems - more to keep track of and more complicated.  Is the net result all the different than Proposal 1? 
2. b)this could also be extended to include disjunctive licensing scenarios - which can then be broken into two types: 
1. (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
1. (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.  
3. 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?  
1. 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? 
2. 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)

1. 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.
1. 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?
2. 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
1. 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
2. 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?
1. 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 - 
1. a)PROPOSAL:  matching guidelines say you can ignore this text.  
1. (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)? 
2. (C) Replaceable text issue:  comes into play with "vanity" BSD and Apache 1.1 licenses
2. i) "copyright holder" v. "copyright owner" - can we agree (jurisdictionally) that this is the same meaning?
3. ii) where to put the brackets around what can be "ignored" by scanning tools for matching purposes?
4. iii) also see Historical Permission Notice license

3) License addition process

1. A) Legal team has taken this back over from business team; see Adam Cohn's email summarizing current proposal - To be discussed on next legal call 4/18

4) Formatting and "master list" for License List (i.e. actual license text files)

Currently the "master" consists of spreadsheet with list + individual .txt files for license text field = downloadable zip file.  This is then converted into html pages for website.  Peter, Gary, and Jilayne discussed this issue:

1. A) PROPOSAL:  License text files formatted in HTML instead of .txt files as default; can convert from there into text file with tool if people want that too; 
1. i)Option to use HTML to indicate some of matching rules?
2. B) For back-end management of License List overall: use Bugzilla and GIT repository in background for management  - easier tracking of changes and gets it off Jilayne's desktop/memory…

5) Other administrative to-dos 

1. Add licenses to list or other updates for v1.15 (due THIS WEEK)
1. i) Add FreeBSD - JL DONE
2. ii) Add NetBSD licenses  - JL DONE
3. iii) Add 4-clause UC BSD license - JL DONE, but still need official url
4. iv) Add CDDL v1.1 - JL DONE
5. v) Add MPL 2.0 other header version (for time being to be consistent with GPL)
6. vi) AGPL full name is "v3" not "v3.0" like everything else (short identifier is correct) - JL DONE
7. vii) finish license text review of .txt files - still some to do
8. viii) PHP license issue (see email) - JL DONE
9. ix)? add US Gov't works - add short identifier to list; see email from David Wheeler
2. B) Other to-dos for THIS WEEK
1. i) update License List fields protocol on website
2. ii) post above topics for discussion and let people know for Thursday meeting (have people read first, so we don't have to spend time on "back story")
3. iii)
3. C) Other issues (some to be discussed over next legal calls upcoming)
1. i) GPL exceptions - we don't have them all, list some of the others and variations on text - can someone do some research on this issue?
2. ii) eCos is really a GPL header with an exception... (see bigger issue above)
3. iii) Lucent Public License - naming issues - see notes in spreadsheet
4. iv) Sugar CRM license - see notes in spreadsheet
5. v) Propose short identifier for copyright notice only "all rights reserved"
6. vi) OSI issues - waiting on them
7. vii) FSF license list match-up - licenses that need to be added?
8. a)JL has done initial pass - needs further research
9. viii) Fedora license list reach-out via email (he won't be at LF Collab Summit)
1. a)JL has begun discussion with Tom Calloway