https://wiki.spdx.org/index.php?title=Legal_Team/Minutes/2012-10-31&feed=atom&action=historyLegal Team/Minutes/2012-10-31 - Revision history2024-03-29T05:53:34ZRevision history for this page on the wikiMediaWiki 1.23.13https://wiki.spdx.org/index.php?title=Legal_Team/Minutes/2012-10-31&diff=2258&oldid=prevMartinMichlmayr: Convert to MediaWiki syntax2013-03-05T17:49:35Z<p>Convert to MediaWiki syntax</p>
<table class='diff diff-contentalign-left'>
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr style='vertical-align: top;'>
<td colspan='2' style="background-color: white; color:black; text-align: center;">← Older revision</td>
<td colspan='2' style="background-color: white; color:black; text-align: center;">Revision as of 17:49, 5 March 2013</td>
</tr><tr><td colspan="2" class="diff-lineno">Line 1:</td>
<td colspan="2" class="diff-lineno">Line 1:</td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div><del class="diffchange diffchange-inline"><p><strong></del>Attendees<del class="diffchange diffchange-inline"></strong>:</p><ul><li></del>Jilayne Lovejoy, OpenLogic<del class="diffchange diffchange-inline"></li><li></del>Phil Odence, Black Duck<del class="diffchange diffchange-inline"></li><li></del>Jason Buttara, Cisco<del class="diffchange diffchange-inline"></li><li></del>Jack Manbeck, TI<del class="diffchange diffchange-inline"></li><li></del>Tom Incorvia, Micro Focus<del class="diffchange diffchange-inline"></li><li></del>Paul Madick, HP<del class="diffchange diffchange-inline"></li><li></del>Tom Vidal, outside counsel<del class="diffchange diffchange-inline"></li></ul><p><strong>Agenda</strong>:</p><p>1) </del>license request to add Flora License <del class="diffchange diffchange-inline">-&nbsp;</del>http://www.tizenopensource.org/license/<del class="diffchange diffchange-inline"></p><ul><li></del>issue is that it appears to be a commercial license (Tom Incorvia sent a good summary on this:<del class="diffchange diffchange-inline">&nbsp;</li><ul><li></del>This will flow in to our ongoing discussions regarding the inclusion of freeware licenses. This license is issued by Samsung. I noticed that it has very specific commercial terms such as prohibition of assignment of the license without Samsungs prior written consent, including an automatic voiding of the license in the event of an assignment without their consent.<del class="diffchange diffchange-inline">&nbsp;&nbsp;</del>There is also no "not to be reasonably withheld" provision in the assignment.<del class="diffchange diffchange-inline">&nbsp;&nbsp;</del>There are other restricting terms. <del class="diffchange diffchange-inline">&nbsp;</del>Although I am a fan of a comprehensive SPDX list, we should look carefully at this before including, since it opens up the list to a large number of potentially restrictive and changeable freeware licenses.<del class="diffchange diffchange-inline"></li></ul><li></del>is this consistent with our part of our mission to assist compliance with FOSS licenses? <del class="diffchange diffchange-inline">&nbsp;</del>if these are not FOSS licenses?<del class="diffchange diffchange-inline"></li><ul><li></del>how do we define FOSS anyway? where do we draw the line in terms of what we add and what we do not add to the list?<del class="diffchange diffchange-inline"></li></ul><li></del>difficulty in tracking commercial versions of licenses, especially when tied to a particular company (such that not anyone can use it)<del class="diffchange diffchange-inline"></li><li></del>not an OSI license, that would cut towards adding it, but this one probably couldn't even be submitted<del class="diffchange diffchange-inline">&nbsp;</li><li></del>this license is restrictive - is SPDX a bill of materials for software in general or just FOSS? seems easy answer is keep it off the list<del class="diffchange diffchange-inline"></li><li></del>any pros? <del class="diffchange diffchange-inline">&nbsp;</del>what about extremely common licenses, like Oracle Binary Code License? or licenses for widely used "open source" projects?<del class="diffchange diffchange-inline"></li><ul><li></del>those licenses change all the time, sometimes very small changes, but changes nonetheless<del class="diffchange diffchange-inline"></li><li></del>they way the Oracle site is set up, you sometimes click through multiple licenses <del class="diffchange diffchange-inline">&nbsp;</del>- would this even add any value when it's not entirely clear what the license is or if it's changed?<del class="diffchange diffchange-inline"></li></ul><li>--&gt; </del>general consensus of folks on call that this license and these types of licenses should NOT be added to license list<del class="diffchange diffchange-inline"></li><li></del>so, if we draw this line in the sand, how do we define this? <del class="diffchange diffchange-inline">&nbsp;</li><ul><li></del>can we decided not to add this license today, but leave the door open in the future, to be flexible<del class="diffchange diffchange-inline"></li><li></del>what is "common" anyway? <del class="diffchange diffchange-inline">&nbsp;</del>even Sun stuff is not "common" to everyone<del class="diffchange diffchange-inline"></li><li></del>maybe make a statement, but still leave some room for flexbility (never say never...)<del class="diffchange diffchange-inline"></li><li></del>maybe be better to do one thing well (i.e. collecting/identifying FOSS licenses) before we start adding other categories<del class="diffchange diffchange-inline"></li><li></del>noted that Tizen is a LF project and SPDX is a LF workgroup... should that be part of the consideration?<del class="diffchange diffchange-inline"></li></ul><li></del>first stab at where we draw the line:<del class="diffchange diffchange-inline"></li><ul><li></del>? have the "new guy" do a first draft? (Tom Vidal)<del class="diffchange diffchange-inline"></li><li></del>problem is with different definitions of open source, already a few and different companies have different definitions; could be difficult to put this down, lots of shoulder examples; don't want to look like we are being cavalier about what we select<del class="diffchange diffchange-inline"></li><li></del>are open source licenses like IRS rules around independent contractors - not a clear line; many examples of licenses that are open source but that don't technically meet OSI defintion, kind of like the Supreme Court's definition of pornography... I know it when I see it...<del class="diffchange diffchange-inline"></li><li></del>could we treat this less like a concrete definition and more like a prefatory guideline and admit there is some case-by-case analysis (for when a license gets rejected)<del class="diffchange diffchange-inline"></li><li></del>can we come up with a list of types of things it has that will cause it to get rejected; i.e. if it has one or more of these types of restrictions, we probably won't add it<del class="diffchange diffchange-inline"></li><li></del>also can use some of OSI and FSF lists as the affirmative guidlines of this<del class="diffchange diffchange-inline"></li><li></del>really just a way to provide insight into the process, so if a license gets rejected or accepted, we know why and there is tranparency into process and around guiding principles<del class="diffchange diffchange-inline"></li><li></del>instead of a definition of statement, have guidelines both for: things that we'd like to see to add a license; and things that if it has this, it may be rejected<del class="diffchange diffchange-inline"></li><li><strong>--&gt; </del>Tom Vidal to draft first stab and send to group before next meeting for discussion<del class="diffchange diffchange-inline"></strong></li></ul></ul><p>2) </del>quick update on Roadmap<del class="diffchange diffchange-inline">; </del>most direct thing for legal group is regular updates on license list to coincide with updates on spec + one other "scheduled" time. <del class="diffchange diffchange-inline">&nbsp;</del>this does not mean we can't udpate it more frequently if need be, but wanted to have some kind of schedule to set expectations.<del class="diffchange diffchange-inline"></p><p>3) </del>process for adding (or rejecting licenses) re: Flora in particular and generally. <del class="diffchange diffchange-inline">&nbsp;</del>our process guidelines for this doesn't really address what happens when it is rejected.<del class="diffchange diffchange-inline"></p><ul><li></del>confer with LF on this license (contact Karen Copenhaver on this - Paul to do this)<del class="diffchange diffchange-inline"></li><li></del>get back to license submitter that it's under review (Tom I.)<del class="diffchange diffchange-inline"></li></ul></del></div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">== </ins>Attendees <ins class="diffchange diffchange-inline">==</ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">* </ins>Jilayne Lovejoy, OpenLogic</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">* </ins>Phil Odence, Black Duck</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">* </ins>Jason Buttara, Cisco</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">* </ins>Jack Manbeck, TI</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">* </ins>Tom Incorvia, Micro Focus</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">* </ins>Paul Madick, HP</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">* </ins>Tom Vidal, outside counsel</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">== </ins>license request to add Flora License <ins class="diffchange diffchange-inline">==</ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">License text: </ins>http://www.tizenopensource.org/license/</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">* </ins>issue is that it appears to be a commercial license (Tom Incorvia sent a good summary on this:</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">** </ins>This will flow in to our ongoing discussions regarding the inclusion of freeware licenses. This license is issued by Samsung. I noticed that it has very specific commercial terms such as prohibition of assignment of the license without Samsungs prior written consent, including an automatic voiding of the license in the event of an assignment without their consent. There is also no "not to be reasonably withheld" provision in the assignment. There are other restricting terms. Although I am a fan of a comprehensive SPDX list, we should look carefully at this before including, since it opens up the list to a large number of potentially restrictive and changeable freeware licenses.</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">* </ins>is this consistent with our part of our mission to assist compliance with FOSS licenses? if these are not FOSS licenses?</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">** </ins>how do we define FOSS anyway? where do we draw the line in terms of what we add and what we do not add to the list?</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">* </ins>difficulty in tracking commercial versions of licenses, especially when tied to a particular company (such that not anyone can use it)</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">* </ins>not an OSI license, that would cut towards adding it, but this one probably couldn't even be submitted</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">* </ins>this license is restrictive - is SPDX a bill of materials for software in general or just FOSS? seems easy answer is keep it off the list</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">* </ins>any pros? what about extremely common licenses, like Oracle Binary Code License? or licenses for widely used "open source" projects?</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">** </ins>those licenses change all the time, sometimes very small changes, but changes nonetheless</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">** </ins>they way the Oracle site is set up, you sometimes click through multiple licenses - would this even add any value when it's not entirely clear what the license is or if it's changed?</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">* → </ins>general consensus of folks on call that this license and these types of licenses should NOT be added to license list</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">* </ins>so, if we draw this line in the sand, how do we define this?</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">** </ins>can we decided not to add this license today, but leave the door open in the future, to be flexible</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">** </ins>what is "common" anyway? even Sun stuff is not "common" to everyone</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">** </ins>maybe make a statement, but still leave some room for flexbility (never say never...)</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">** </ins>maybe be better to do one thing well (i.e. collecting/identifying FOSS licenses) before we start adding other categories</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">** </ins>noted that Tizen is a LF project and SPDX is a LF workgroup... should that be part of the consideration?</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">* </ins>first stab at where we draw the line:</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">** </ins>? have the "new guy" do a first draft? (Tom Vidal)</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">** </ins>problem is with different definitions of open source, already a few and different companies have different definitions; could be difficult to put this down, lots of shoulder examples; don't want to look like we are being cavalier about what we select</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">** </ins>are open source licenses like IRS rules around independent contractors - not a clear line; many examples of licenses that are open source but that don't technically meet OSI defintion, kind of like the Supreme Court's definition of pornography... I know it when I see it...</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">** </ins>could we treat this less like a concrete definition and more like a prefatory guideline and admit there is some case-by-case analysis (for when a license gets rejected)</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">** </ins>can we come up with a list of types of things it has that will cause it to get rejected; i.e. if it has one or more of these types of restrictions, we probably won't add it</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">** </ins>also can use some of OSI and FSF lists as the affirmative guidlines of this</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">** </ins>really just a way to provide insight into the process, so if a license gets rejected or accepted, we know why and there is tranparency into process and around guiding principles</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">** </ins>instead of a definition of statement, have guidelines both for: things that we'd like to see to add a license; and things that if it has this, it may be rejected</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">** '''→ </ins>Tom Vidal to draft first stab and send to group before next meeting for discussion<ins class="diffchange diffchange-inline">'''</ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">== </ins>quick update on Roadmap <ins class="diffchange diffchange-inline">==</ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>most direct thing for legal group is regular updates on license list to coincide with updates on spec + one other "scheduled" time. this does not mean we can't udpate it more frequently if need be, but wanted to have some kind of schedule to set expectations.</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">== </ins>process for adding (or rejecting licenses) <ins class="diffchange diffchange-inline">==</ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>re: Flora in particular and generally. our process guidelines for this doesn't really address what happens when it is rejected.</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">* </ins>confer with LF on this license (contact Karen Copenhaver on this - Paul to do this)</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">* </ins>get back to license submitter that it's under review (Tom I.)</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">[[Category:Legal|Minutes]]</ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">[[Category:Minutes]]</ins></div></td></tr>
</table>MartinMichlmayrhttps://wiki.spdx.org/index.php?title=Legal_Team/Minutes/2012-10-31&diff=2257&oldid=prevJlovejoy at 15:59, 31 October 20122012-10-31T15:59:28Z<p></p>
<p><b>New page</b></p><div><p><strong>Attendees</strong>:</p><ul><li>Jilayne Lovejoy, OpenLogic</li><li>Phil Odence, Black Duck</li><li>Jason Buttara, Cisco</li><li>Jack Manbeck, TI</li><li>Tom Incorvia, Micro Focus</li><li>Paul Madick, HP</li><li>Tom Vidal, outside counsel</li></ul><p><strong>Agenda</strong>:</p><p>1) license request to add Flora License -&nbsp;http://www.tizenopensource.org/license/</p><ul><li>issue is that it appears to be a commercial license (Tom Incorvia sent a good summary on this:&nbsp;</li><ul><li>This will flow in to our ongoing discussions regarding the inclusion of freeware licenses. This license is issued by Samsung. I noticed that it has very specific commercial terms such as prohibition of assignment of the license without Samsungs prior written consent, including an automatic voiding of the license in the event of an assignment without their consent.&nbsp;&nbsp;There is also no "not to be reasonably withheld" provision in the assignment.&nbsp;&nbsp;There are other restricting terms. &nbsp;Although I am a fan of a comprehensive SPDX list, we should look carefully at this before including, since it opens up the list to a large number of potentially restrictive and changeable freeware licenses.</li></ul><li>is this consistent with our part of our mission to assist compliance with FOSS licenses? &nbsp;if these are not FOSS licenses?</li><ul><li>how do we define FOSS anyway? where do we draw the line in terms of what we add and what we do not add to the list?</li></ul><li>difficulty in tracking commercial versions of licenses, especially when tied to a particular company (such that not anyone can use it)</li><li>not an OSI license, that would cut towards adding it, but this one probably couldn't even be submitted&nbsp;</li><li>this license is restrictive - is SPDX a bill of materials for software in general or just FOSS? seems easy answer is keep it off the list</li><li>any pros? &nbsp;what about extremely common licenses, like Oracle Binary Code License? or licenses for widely used "open source" projects?</li><ul><li>those licenses change all the time, sometimes very small changes, but changes nonetheless</li><li>they way the Oracle site is set up, you sometimes click through multiple licenses &nbsp;- would this even add any value when it's not entirely clear what the license is or if it's changed?</li></ul><li>--&gt; general consensus of folks on call that this license and these types of licenses should NOT be added to license list</li><li>so, if we draw this line in the sand, how do we define this? &nbsp;</li><ul><li>can we decided not to add this license today, but leave the door open in the future, to be flexible</li><li>what is "common" anyway? &nbsp;even Sun stuff is not "common" to everyone</li><li>maybe make a statement, but still leave some room for flexbility (never say never...)</li><li>maybe be better to do one thing well (i.e. collecting/identifying FOSS licenses) before we start adding other categories</li><li>noted that Tizen is a LF project and SPDX is a LF workgroup... should that be part of the consideration?</li></ul><li>first stab at where we draw the line:</li><ul><li>? have the "new guy" do a first draft? (Tom Vidal)</li><li>problem is with different definitions of open source, already a few and different companies have different definitions; could be difficult to put this down, lots of shoulder examples; don't want to look like we are being cavalier about what we select</li><li>are open source licenses like IRS rules around independent contractors - not a clear line; many examples of licenses that are open source but that don't technically meet OSI defintion, kind of like the Supreme Court's definition of pornography... I know it when I see it...</li><li>could we treat this less like a concrete definition and more like a prefatory guideline and admit there is some case-by-case analysis (for when a license gets rejected)</li><li>can we come up with a list of types of things it has that will cause it to get rejected; i.e. if it has one or more of these types of restrictions, we probably won't add it</li><li>also can use some of OSI and FSF lists as the affirmative guidlines of this</li><li>really just a way to provide insight into the process, so if a license gets rejected or accepted, we know why and there is tranparency into process and around guiding principles</li><li>instead of a definition of statement, have guidelines both for: things that we'd like to see to add a license; and things that if it has this, it may be rejected</li><li><strong>--&gt; Tom Vidal to draft first stab and send to group before next meeting for discussion</strong></li></ul></ul><p>2) quick update on Roadmap; most direct thing for legal group is regular updates on license list to coincide with updates on spec + one other "scheduled" time. &nbsp;this does not mean we can't udpate it more frequently if need be, but wanted to have some kind of schedule to set expectations.</p><p>3) process for adding (or rejecting licenses) re: Flora in particular and generally. &nbsp;our process guidelines for this doesn't really address what happens when it is rejected.</p><ul><li>confer with LF on this license (contact Karen Copenhaver on this - Paul to do this)</li><li>get back to license submitter that it's under review (Tom I.)</li></ul></div>Jlovejoy