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

MartinMichlmayr: Convert to MediaWiki syntax

2013-03-05T18:52:24Z

Convert to MediaWiki syntax

Jlovejoy at 19:01, 6 April 2012

2012-04-06T19:01:19Z

Jlovejoy at 21:49, 5 April 2012

2012-04-05T21:49:30Z

New page

SPDX Legal Work Group meeting minutes - 5 April 2012face-to-face meeting at Linux Collab SummitSPDX 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<ol class="ol1"><li class="li3">A)Key examples: MPL v2.0 (Exhibit A or Exhibit A & B); L/GPL licenses ("or later" or "only")</li><li class="li3">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?</li><ol class="ol2"><li class="li3">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+) </li><ol class="ol3"><li class="li3">a)if we stay with this route, propose that short identifier says "only" in it.  </li><ol class="ol4"><li class="li3">(1)But then, what about when you aren't sure?  Default to "or later."</li></ol><li class="li3">b)potential problems - won't match with other lists (e.g. Email from Debian guy)</li></ol><li class="li3">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.  </li><ol class="ol3"><li class="li3">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</li><ol class="ol4"><li class="li3">(1)potential problems - more to keep track of and more complicated.  Is the net result all the different than Proposal 1? </li></ol><li class="li3">b)this could also be extended to include disjunctive licensing scenarios - which can then be broken into two types: </li><ol class="ol4"><li class="li3">(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</li><ol class="ol3"><li class="li3">(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.  </li></ol></ol></ol><li>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?  </li><ol><li class="li3">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? </li><li class="li3">ii)either way, practical matching guidelines for tool-makers is difficult - how can this work practically speaking</li></ol></ol></ol>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)<ol class="ol1"><ol class="ol2"><li class="li3">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.</li><ol class="ol3"><li class="li3">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?</li><li class="li3">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</li><ol><li class="li3">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</li></ol></ol><li>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?</li><ol><li class="li3">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 - </li><ol class="ol4"><li class="li3">a)PROPOSAL:  matching guidelines say you can ignore this text.  </li><ol><li class="li3">(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)? </li><li class="li3">(C) Replaceable text issue:  comes into play with "vanity" BSD and Apache 1.1 licenses</li></ol></ol><li class="li3">i) "copyright holder" v. "copyright owner" - can we agree (jurisdictionally) that this is the same meaning?</li><li class="li3">ii) where to put the brackets around what can be "ignored" by scanning tools for matching purposes?</li><li class="li3">iii) also see Historical Permission Notice license</li></ol></ol></ol>3) License addition process<ol class="ol1"><ol class="ol2"><li class="li3">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</li></ol></ol>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:<ol class="ol1"><ol class="ol2"><li class="li3">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; </li><ol><li class="li3">i)Option to use HTML to indicate some of matching rules?</li></ol><li class="li3">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…</li></ol></ol>5) Other administrative to-dos <ol class="ol1"><ol class="ol2"><li class="li3">Add licenses to list or other updates for v1.15 (due THIS WEEK)</li><ol><li class="li3">i) Add FreeBSD - JL DONE</li><li class="li3">ii) Add NetBSD licenses  - JL DONE</li><li class="li3">iii) Add 4-clause UC BSD license - JL DONE, but still need official url</li><li class="li3">iv) Add CDDL v1.1 - JL DONE</li><li>v) Add MPL 2.0 other header version (for time being to be consistent with GPL)</li><li class="li3">vi) AGPL full name is "v3" not "v3.0" like everything else (short identifier is correct) - JL DONE</li><li class="li3">vii) finish license text review of .txt files - still some to do</li><li class="li3">viii) PHP license issue (see email) - JL DONE</li><li class="li3">ix)? add US Gov't works - add short identifier to list; see email from David Wheeler</li></ol><li class="li3">B) Other to-dos for THIS WEEK</li><ol><li class="li3">i) update License List fields protocol on website</li><li class="li3">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")</li><li class="li3">iii)</li></ol><li class="li3">C) Other issues (some to be discussed over next legal calls upcoming)</li><ol class="ol3"><li class="li3">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?</li><li class="li3">ii) eCos is really a GPL header with an exception... (see bigger issue above)</li><li class="li3">iii) Lucent Public License - naming issues - see notes in spreadsheet</li><li class="li3">iv) Sugar CRM license - see notes in spreadsheet</li><li class="li3">v) Propose short identifier for copyright notice only "all rights reserved"</li><li class="li3">vi) OSI issues - waiting on them</li><li class="li3">vii) FSF license list match-up - licenses that need to be added?</li><li class="li3">a)JL has done initial pass - needs further research</li><li class="li3">viii) Fedora license list reach-out via email (he won't be at LF Collab Summit)</li><ol><li class="li3">a)JL has begun discussion with Tom Calloway</li></ol></ol></ol></ol>

← Older revision		Revision as of 18:52, 5 March 2013
Line 1:		Line 1:
−	~~<p><span style="text-decoration: underline;"><strong>SPDX Legal Work Group meeting minutes - 5 April 2012</strong></span></p><p> </p><p class="p1"><strong>~~Linux Foundation Collab Summit - SPDX face-to-face~~</strong></p><p class="p1"><strong>~~Thursday, April 5, 2012~~</strong></p><p class~~=~~"p2"> </p><p class~~=~~"p3"><span class="s1"><strong>1)~~ Different headers for the same license issue~~</strong></span>: </p><p class~~=~~"p3">~~How to capture in License List where the same license text has different "meanings' indicated by different headers.~~ ~~ Key examples: MPL v2.0 (Exhibit A or Exhibit A & B); L/GPL licenses ("or later" or "only").~~ ~~ Complete agreement that this information needs to be captured. Question is how to capture/implement?~~</p><ul><li>~~A)~~<span class="s1">~~PROPOSAL 1~~</span>~~:~~ ~~ leave 'as is' on license list now which is that these scenarios are captured 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; GPL-2.0+)~~ </li></ul><ol class="ol1"><ul><li class="li3">~~i)Pros:~~</li><ul><li class="li3">~~a)Fedora and Fossology already uses similar short names as we have now (i.e. GPLv2 or GPLv2+)~~</li><li class="li3">~~b)Predictable and specifically identified, which is intrinsic to goal of license list~~</li></ul><li class="li3">~~ii)Cons:~~</li><ul><li class="li3">~~a)Won't match other lists~~</li></ul><li class="li3">~~iii)Other considerations:~~</li><ul><li class="li3">~~a)if we stay with this route, propose that short identifier says "only" in it?~~<span class="s2"> </span></li><ul><li class="li3">~~(1)But then, what about when you aren't sure - which short identifier do you use? ~~ ~~Default to "or later?"~~ ~~ Is more intuitive to use "GPL-2.0" plain?~~</li></ul></ul></ul></ol><ul><li>~~B)~~<span class="s1">~~PROPOSAL 2~~</span>~~: license list is just the licenses themselves. ~~ ~~Headers or alternative exhibits are captured on a separate list that then modifies the license list. ~~ </li></ul><ol class="ol1"><ul><li class="li3">~~i)e.g. On the master license list, GPL v2 would be just that GPL-2.0 (without indicating "or later" or "only"), then the separate 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~~</li><ul><li class="li3">~~a)potential problems - more to keep track of and more complicated. ~~ ~~Is the net result all the different than Proposal 1?~~ </li></ul></ul></ol><p class="p3"><strong>~~DISCUSSION~~</strong>:</p><ul class="ul1"><li class="li3"><em>~~vigorous discussion around pros and cons of #1 and #2~~ </em></li><li class="li3"><em>~~variation proposed that combined both proposals~~</em></li><li class="li3"><em>~~major problem/drawback with proposal #2 and any variation thereof is potential for explosion of scenarios where modifiers could be used in non-conformant way causing ambiguity or confusion which goes against goal of license list~~ </em></li><li class="li3"><em>~~advantage of current scenario - it's simple (even if lengthy) and has rigidity needed; but some clarification needed~~</em></li></ul><p class="p3"><strong>~~DECISION~~</strong></p><p class="p3"> ~~leave as is = separate "line items" for GPL v2 only and GPL v2 or later~~</p><p class="p2"> </p><p class="p3"><strong>~~TO-DOs~~</strong></p><ul><li>~~add in Notes field for all GNU licenses that short identifier "GPL-2.0" = GPL v2 only and vice versa~~ </li><ul><li>~~(Jilayne to do for next version of license list)~~</li></ul><li>~~add other MPL 2.0 scenarios for Exhibit B (see Luis email and meeting minutes)~~ </li><ul><li>~~(Jilayne to do for next version of license list)~~</li></ul><li>~~need to come up with list of all licenses that fall into this category (same license text appearing more than once on license list) and determine the "default" if SPDX file creator only files license with no delineating header or other information~~</li><ul><li>~~(Jilayne or someone else? to come up with list and then discuss on one of next legal calls)~~</li></ul></ul><p class="p6"> </p><p class="p3"><strong>~~OTHER RELATED DISCUSSION~~</strong></p><ul><li>~~C)~~<span class="s1">~~GPL exceptions~~</span> </li></ul><ol class="ol1"><ul><li>~~i)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? ~~ </li></ul><ol class="ol2"><ul><li><em>~~a)Did not discuss~~</em></li></ul></ol><ul><li>~~ii)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?~~ </li></ul><ol class="ol2"><ul><li class="li3"><em>~~a)Also leave as is in terms of separate line items~~</em></li><li class="li3"><em>~~b)acknowledgement that SPDX license list does not have all exceptions and will need to add more (research needed on this to identify holes)~~</em></li><li class="li3"><em>~~c)could we come up with a system of separate license modifiers that could be added on modularly to a "GPL-2.0"?~~ </em></li></ul></ol></ol><p class="p7"> </p><ul><li>~~D)~~<span class="s1">~~Standard headers for ~~license</span>s</li></ul><ol class="ol1"><ul><li class="li3"><em>~~i)Currently this field only shows up on license list spreadsheet, but not on spdx.org license pages~~;&nbsp~~; need to add this field including ability to indicate there isn't a standard header, as is the case for most licenses~~ </em></li><ul><li class="li3"><em>~~a) ~~</em>~~(Jilayne and Gary to begin working on)~~</li></ul><li class="li3"><em>~~ii)need to review license list, to make sure standard headers are correct; remove or indicate "replaceable" text; check if any are missing~~ </em></li><ul><li class="li3">~~a)(Karen C. and Bill to start this task)~~</li></ul></ul></ol><p> </p>~~	+	'''Linux Foundation Collab Summit - SPDX face-to-face'''
		+
		+	'''Thursday, April 5, 2012'''
		+
		+	== Different headers for the same license issue ==
		+
		+	How to capture in License List where the same license text has different "meanings' indicated by different headers. Key examples: MPL v2.0 (Exhibit A or Exhibit A & B); L/GPL licenses ("or later" or "only"). Complete agreement that this information needs to be captured. Question is how to capture/implement?
		+
		+	* A)PROPOSAL 1: leave 'as is' on license list now which is that these scenarios are captured 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; GPL-2.0+)
		+	** i)Pros:
		+	*** a)Fedora and Fossology already uses similar short names as we have now (i.e. GPLv2 or GPLv2+)
		+	*** b)Predictable and specifically identified, which is intrinsic to goal of license list
		+	** ii)Cons:
		+	*** a)Won't match other lists
		+	** iii)Other considerations:
		+	*** 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 - which short identifier do you use? Default to "or later?" Is more intuitive to use "GPL-2.0" plain?
		+	* B)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.
		+	** i)e.g. On the master license list, GPL v2 would be just that GPL-2.0 (without indicating "or later" or "only"), then the separate 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
		+	*** a)potential problems - more to keep track of and more complicated. Is the net result all the different than Proposal 1?
		+
		+	'''DISCUSSION'''
		+
		+	* ''vigorous discussion around pros and cons of #1 and #2 ''
		+	* ''variation proposed that combined both proposals''
		+	* ''major problem/drawback with proposal #2 and any variation thereof is potential for explosion of scenarios where modifiers could be used in non-conformant way causing ambiguity or confusion which goes against goal of license list ''
		+	* ''advantage of current scenario - it's simple (even if lengthy) and has rigidity needed; but some clarification needed''
		+
		+	'''DECISION'''
		+
		+	leave as is = separate "line items" for GPL v2 only and GPL v2 or later
		+
		+	'''TO-DOs'''
		+
		+	* add in Notes field for all GNU licenses that short identifier "GPL-2.0" = GPL v2 only and vice versa
		+	** (Jilayne to do for next version of license list)
		+	* add other MPL 2.0 scenarios for Exhibit B (see Luis email and meeting minutes)
		+	** (Jilayne to do for next version of license list)
		+	* need to come up with list of all licenses that fall into this category (same license text appearing more than once on license list) and determine the "default" if SPDX file creator only files license with no delineating header or other information
		+	** (Jilayne or someone else? to come up with list and then discuss on one of next legal calls)
		+
		+	'''OTHER RELATED DISCUSSION'''
		+
		+	* C)GPL exceptions
		+	* i)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?
		+	* ''a)Did not discuss''
		+	* ii)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?
		+	* ''a)Also leave as is in terms of separate line items''
		+	* ''b)acknowledgement that SPDX license list does not have all exceptions and will need to add more (research needed on this to identify holes)''
		+	* ''c)could we come up with a system of separate license modifiers that could be added on modularly to a "GPL-2.0"? ''
		+	* D)Standard headers for licenses
		+	* ''i)Currently this field only shows up on license list spreadsheet, but not on spdx.org license pages; need to add this field including ability to indicate there isn't a standard header, as is the case for most licenses ''
		+	** ''a) ''(Jilayne and Gary to begin working on)
		+	* ''ii)need to review license list, to make sure standard headers are correct; remove or indicate "replaceable" text; check if any are missing ''
		+	** a)(Karen C. and Bill to start this task)
		+
		+	[[Category:Legal\|Minutes]]
		+	[[Category:Minutes]]

← Older revision		Revision as of 19:01, 6 April 2012
Line 1:		Line 1:
−	<p><span style="text-decoration: underline;"><strong>SPDX Legal Work Group meeting minutes - 5 April 2012</strong></span></p><p>face-to-face meeting at Linux Collab Summit</p><p>SPDX Legal Team - To-Dos</p><p class="p2"> </p><p class="p3"><span class="s2"><strong>1) Different headers for the same license issue</strong></span><span class="s1"><strong> (and header matching guidelines)</strong>: </span></p><p class="p3"><span class="s1">How to capture in License List and for license matching guideline purposes</span></p><ol class="ol1"><li class="li3">A)<span class="s1">Key examples: MPL v2.0 (Exhibit A or Exhibit A & B); L/GPL licenses ("or later" or "only")</span></li><li class="li3">B)<span class="s1">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?</span></li><ol class="ol2"><li class="li3">i)<span style="text-decoration: underline;"><span class="s2">PROPOSAL 1</span></span><span class="s1">:  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+) </span></li><ol class="ol3"><li class="li3">a)<span class="s1">if we stay with this route, propose that short identifier says "only" in it.  </span></li><ol class="ol4"><li class="li3">(1)<span class="s1">But then, what about when you aren't sure?  Default to "or later."</span></li></ol><li class="li3">b)<span class="s1">potential problems - won't match with other lists (e.g. Email from Debian guy)</span></li></ol><li class="li3">ii)<span style="text-decoration: underline;"> <span class="s2">PROPOSAL 2</span></span><span class="s1">: license list is just the licenses themselves.  Headers or alternative exhibits are captured on a separate list that then modifies the license list.  </span></li><ol class="ol3"><li class="li3">a)<span class="s1">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</span></li><ol class="ol4"><li class="li3">(1)<span class="s1">potential problems - more to keep track of and more complicated.  Is the net result all the different than Proposal 1? </span></li></ol><li class="li3">b)<span class="s1">this could also be extended to include disjunctive licensing scenarios - which can then be broken into two types: </span></li><ol class="ol4"><li class="li3">(1)<span class="s1">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</span></li><ol class="ol3"><li class="li3">(a)<span style="text-decoration: underline;"><span class="s2">PROPOSAL</span></span><span class="s1">: 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.  </span></li></ol></ol></ol><li>C)<span class="s2">Tangent issue here</span><span class="s1">: 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?  </span></li><ol><li class="li3">i)<span class="s1">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? </span></li><li class="li3">ii)<span class="s1">either way, practical matching guidelines for tool-makers is difficult - how can this work practically speaking</span></li></ol></ol></ol><p class="p3"><span class="s2"><strong>2) License text itself/matching guidelines</strong></span><span class="s1"><strong>:</strong> </span></p><p class="p3"><span class="s1">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)</span></p><ol class="ol1"><ol class="ol2"><li class="li3">A) <span class="s2">License name/title</span><span class="s1"> - 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.</span></li><ol class="ol3"><li class="li3">i) <span class="s1">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?</span></li><li class="li3">ii) <span class="s1">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</span></li><ol><li class="li3">a) <span style="text-decoration: underline;"><span class="s2">PROPOSAL</span></span><span class="s1">: 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</span></li></ol></ol><li><span style="text-decoration: underline;">B) <span class="s2">Extra text issue</span></span><span class="s1">:  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?</span></li><ol><li class="li3">i) <span class="s1">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 - </span></li><ol class="ol4"><li class="li3">a)<span class="s2">PROPOSAL</span><span class="s1">:  matching guidelines say you can ignore this text.  </span></li><ol><li class="li3">(1) <span class="s1">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)? </span></li><li class="li3">(C) <span class="s2">Replaceable text issue</span><span class="s1">:  comes into play with "vanity" BSD and Apache 1.1 licenses</span></li></ol></ol><li class="li3">i) <span class="s1">"copyright holder" v. "copyright owner" - can we agree (jurisdictionally) that this is the same meaning?</span></li><li class="li3">ii) <span class="s1">where to put the brackets around what can be "ignored" by scanning tools for matching purposes?</span></li><li class="li3">iii) <span class="s1">also see Historical Permission Notice license</span></li></ol></ol></ol><p class="p3"><span class="s2"><strong>3) License addition process</strong></span></p><ol class="ol1"><ol class="ol2"><li class="li3">A) <span class="s1">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</span></li></ol></ol><p class="p3"><span class="s2"><strong>4) Formatting and "master list" for License List (i.e. actual license text files)</strong></span></p><p class="p3"><span class="s1">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:</span></p><ol class="ol1"><ol class="ol2"><li class="li3">A) <span class="s1"><span style="text-decoration: underline;">PROPOSAL</span>:  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; </span></li><ol><li class="li3">i)<span class="s1">Option to use HTML to indicate some of matching rules?</span></li></ol><li class="li3">B) <span class="s1">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…</span></li></ol></ol><p class="p3"><span class="s2"><strong>5) Other administrative to-dos </strong></span></p><ol class="ol1"><ol class="ol2"><li class="li3"><span class="s1">Add licenses to list or other updates for v1.15 (due THIS WEEK)</span></li><ol><li class="li3"><span class="s3">i) </span><span class="s4">Add FreeBSD</span><span class="s1"> - JL DONE</span></li><li class="li3"><span class="s4">ii) Add NetBSD licenses</span><span class="s1">  - JL DONE</span></li><li class="li3"><span class="s3">iii) </span><span class="s4">Add 4-clause UC BSD license</span><span class="s1"> - JL DONE, but still need official url</span></li><li class="li3"><span class="s3">iv) </span><span class="s4">Add CDDL v1.1</span><span class="s1"> - JL DONE</span></li><li>v) <span class="s1">Add MPL 2.0 other header version (for time being to be consistent with GPL)</span></li><li class="li3"><span class="s3">vi) </span><span class="s4">AGPL full name is "v3" not "v3.0" like everything else (short identifier is correct)</span><span class="s1"> - JL DONE</span></li><li class="li3">vii) <span class="s1">finish license text review of .txt files - still some to do</span></li><li class="li3"><span class="s3">viii) </span><span class="s4">PHP license issue (see email)</span><span class="s1"> - JL DONE</span></li><li class="li3">ix)<span class="s1">? add US Gov't works - add short identifier to list; see email from David Wheeler</span></li></ol><li class="li3">B) <span class="s1">Other to-dos for THIS WEEK</span></li><ol><li class="li3">i) <span class="s1">update License List fields protocol on website</span></li><li class="li3">ii) <span class="s1">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")</span></li><li class="li3">iii)</li></ol><li class="li3">C) <span class="s1">Other issues (some to be discussed over next legal calls upcoming)</span></li><ol class="ol3"><li class="li3">i) <span class="s1">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?</span></li><li class="li3">ii) <span class="s1">eCos is really a GPL header with an exception... (see bigger issue above)</span></li><li class="li3">iii) <span class="s1">Lucent Public License - naming issues - see notes in spreadsheet</span></li><li class="li3">iv) <span class="s1">Sugar CRM license - see notes in spreadsheet</span></li><li class="li3">v) <span class="s1">Propose short identifier for copyright notice only "all rights reserved"</span></li><li class="li3">vi) <span class="s1">OSI issues - waiting on them</span></li><li class="li3">vii) <span class="s1">FSF license list match-up - licenses that need to be added?</span></li><li class="li3">a)<span class="s1">JL has done initial pass - needs further research</span></li><li class="li3">viii) <span class="s1">Fedora license list reach-out via email (he won't be at LF Collab Summit)</span></li><ol><li class="li3">a)<span class="s1">JL has begun discussion with Tom Calloway</span></li></ol></ol></ol></ol><p class="p2"> </p><p> </p>	+	<p><span style="text-decoration: underline;"><strong>SPDX Legal Work Group meeting minutes - 5 April 2012</strong></span></p><p> </p><p class="p1"><strong>Linux Foundation Collab Summit - SPDX face-to-face</strong></p><p class="p1"><strong>Thursday, April 5, 2012</strong></p><p class="p2"> </p><p class="p3"><span class="s1"><strong>1) Different headers for the same license issue</strong></span>: </p><p class="p3">How to capture in License List where the same license text has different "meanings' indicated by different headers.  Key examples: MPL v2.0 (Exhibit A or Exhibit A & B); L/GPL licenses ("or later" or "only").  Complete agreement that this information needs to be captured. Question is how to capture/implement?</p><ul><li>A)<span class="s1">PROPOSAL 1</span>:  leave 'as is' on license list now which is that these scenarios are captured 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; GPL-2.0+) </li></ul><ol class="ol1"><ul><li class="li3">i)Pros:</li><ul><li class="li3">a)Fedora and Fossology already uses similar short names as we have now (i.e. GPLv2 or GPLv2+)</li><li class="li3">b)Predictable and specifically identified, which is intrinsic to goal of license list</li></ul><li class="li3">ii)Cons:</li><ul><li class="li3">a)Won't match other lists</li></ul><li class="li3">iii)Other considerations:</li><ul><li class="li3">a)if we stay with this route, propose that short identifier says "only" in it?<span class="s2"> </span></li><ul><li class="li3">(1)But then, what about when you aren't sure - which short identifier do you use?  Default to "or later?"  Is more intuitive to use "GPL-2.0" plain?</li></ul></ul></ul></ol><ul><li>B)<span class="s1">PROPOSAL 2</span>: license list is just the licenses themselves.  Headers or alternative exhibits are captured on a separate list that then modifies the license list.  </li></ul><ol class="ol1"><ul><li class="li3">i)e.g. On the master license list, GPL v2 would be just that GPL-2.0 (without indicating "or later" or "only"), then the separate 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</li><ul><li class="li3">a)potential problems - more to keep track of and more complicated.  Is the net result all the different than Proposal 1? </li></ul></ul></ol><p class="p3"><strong>DISCUSSION</strong>:</p><ul class="ul1"><li class="li3"><em>vigorous discussion around pros and cons of #1 and #2 </em></li><li class="li3"><em>variation proposed that combined both proposals</em></li><li class="li3"><em>major problem/drawback with proposal #2 and any variation thereof is potential for explosion of scenarios where modifiers could be used in non-conformant way causing ambiguity or confusion which goes against goal of license list </em></li><li class="li3"><em>advantage of current scenario - it's simple (even if lengthy) and has rigidity needed; but some clarification needed</em></li></ul><p class="p3"><strong>DECISION</strong></p><p class="p3"> leave as is = separate "line items" for GPL v2 only and GPL v2 or later</p><p class="p2"> </p><p class="p3"><strong>TO-DOs</strong></p><ul><li>add in Notes field for all GNU licenses that short identifier "GPL-2.0" = GPL v2 only and vice versa </li><ul><li>(Jilayne to do for next version of license list)</li></ul><li>add other MPL 2.0 scenarios for Exhibit B (see Luis email and meeting minutes) </li><ul><li>(Jilayne to do for next version of license list)</li></ul><li>need to come up with list of all licenses that fall into this category (same license text appearing more than once on license list) and determine the "default" if SPDX file creator only files license with no delineating header or other information</li><ul><li>(Jilayne or someone else? to come up with list and then discuss on one of next legal calls)</li></ul></ul><p class="p6"> </p><p class="p3"><strong>OTHER RELATED DISCUSSION</strong></p><ul><li>C)<span class="s1">GPL exceptions</span> </li></ul><ol class="ol1"><ul><li>i)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?  </li></ul><ol class="ol2"><ul><li><em>a)Did not discuss</em></li></ul></ol><ul><li>ii)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? </li></ul><ol class="ol2"><ul><li class="li3"><em>a)Also leave as is in terms of separate line items</em></li><li class="li3"><em>b)acknowledgement that SPDX license list does not have all exceptions and will need to add more (research needed on this to identify holes)</em></li><li class="li3"><em>c)could we come up with a system of separate license modifiers that could be added on modularly to a "GPL-2.0"? </em></li></ul></ol></ol><p class="p7"> </p><ul><li>D)<span class="s1">Standard headers for license</span>s</li></ul><ol class="ol1"><ul><li class="li3"><em>i)Currently this field only shows up on license list spreadsheet, but not on spdx.org license pages;  need to add this field including ability to indicate there isn't a standard header, as is the case for most licenses </em></li><ul><li class="li3"><em>a) </em>(Jilayne and Gary to begin working on)</li></ul><li class="li3"><em>ii)need to review license list, to make sure standard headers are correct; remove or indicate "replaceable" text; check if any are missing </em></li><ul><li class="li3">a)(Karen C. and Bill to start this task)</li></ul></ul></ol><p> </p>