THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx

Difference between revisions of "Legal Team/Minutes/2012-10-31"

From SPDX Wiki
Jump to: navigation, search
 
(Convert to MediaWiki syntax)
 
Line 1: Line 1:
−
<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>
+
== Attendees ==
 +
 
 +
* Jilayne Lovejoy, OpenLogic
 +
* Phil Odence, Black Duck
 +
* Jason Buttara, Cisco
 +
* Jack Manbeck, TI
 +
* Tom Incorvia, Micro Focus
 +
* Paul Madick, HP
 +
* Tom Vidal, outside counsel
 +
 
 +
== license request to add Flora License ==
 +
 
 +
License text: http://www.tizenopensource.org/license/
 +
 
 +
* issue is that it appears to be a commercial license (Tom Incorvia sent a good summary on this:
 +
** 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.
 +
* is this consistent with our part of our mission to assist compliance with FOSS licenses? if these are not FOSS licenses?
 +
** 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?
 +
* difficulty in tracking commercial versions of licenses, especially when tied to a particular company (such that not anyone can use it)
 +
* not an OSI license, that would cut towards adding it, but this one probably couldn't even be submitted
 +
* 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
 +
* any pros? what about extremely common licenses, like Oracle Binary Code License? or licenses for widely used "open source" projects?
 +
** those licenses change all the time, sometimes very small changes, but changes nonetheless
 +
** 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?
 +
* → general consensus of folks on call that this license and these types of licenses should NOT be added to license list
 +
* so, if we draw this line in the sand, how do we define this?
 +
** can we decided not to add this license today, but leave the door open in the future, to be flexible
 +
** what is "common" anyway? even Sun stuff is not "common" to everyone
 +
** maybe make a statement, but still leave some room for flexbility (never say never...)
 +
** maybe be better to do one thing well (i.e. collecting/identifying FOSS licenses) before we start adding other categories
 +
** noted that Tizen is a LF project and SPDX is a LF workgroup... should that be part of the consideration?
 +
* first stab at where we draw the line:
 +
** ? have the "new guy" do a first draft? (Tom Vidal)
 +
** 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
 +
** 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...
 +
** 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)
 +
** 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
 +
** also can use some of OSI and FSF lists as the affirmative guidlines of this
 +
** 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
 +
** 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
 +
** '''→ Tom Vidal to draft first stab and send to group before next meeting for discussion'''
 +
 
 +
== 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. 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.
 +
 
 +
== process for adding (or rejecting licenses) ==
 +
 
 +
re: Flora in particular and generally. our process guidelines for this doesn't really address what happens when it is rejected.
 +
 
 +
* confer with LF on this license (contact Karen Copenhaver on this - Paul to do this)
 +
* get back to license submitter that it's under review (Tom I.)
 +
 
 +
[[Category:Legal|Minutes]]
 +
[[Category:Minutes]]

Latest revision as of 17:49, 5 March 2013

Attendees

  • Jilayne Lovejoy, OpenLogic
  • Phil Odence, Black Duck
  • Jason Buttara, Cisco
  • Jack Manbeck, TI
  • Tom Incorvia, Micro Focus
  • Paul Madick, HP
  • Tom Vidal, outside counsel

license request to add Flora License

License text: http://www.tizenopensource.org/license/

  • issue is that it appears to be a commercial license (Tom Incorvia sent a good summary on this:
    • 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.
  • is this consistent with our part of our mission to assist compliance with FOSS licenses? if these are not FOSS licenses?
    • 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?
  • difficulty in tracking commercial versions of licenses, especially when tied to a particular company (such that not anyone can use it)
  • not an OSI license, that would cut towards adding it, but this one probably couldn't even be submitted
  • 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
  • any pros? what about extremely common licenses, like Oracle Binary Code License? or licenses for widely used "open source" projects?
    • those licenses change all the time, sometimes very small changes, but changes nonetheless
    • 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?
  • → general consensus of folks on call that this license and these types of licenses should NOT be added to license list
  • so, if we draw this line in the sand, how do we define this?
    • can we decided not to add this license today, but leave the door open in the future, to be flexible
    • what is "common" anyway? even Sun stuff is not "common" to everyone
    • maybe make a statement, but still leave some room for flexbility (never say never...)
    • maybe be better to do one thing well (i.e. collecting/identifying FOSS licenses) before we start adding other categories
    • noted that Tizen is a LF project and SPDX is a LF workgroup... should that be part of the consideration?
  • first stab at where we draw the line:
    •  ? have the "new guy" do a first draft? (Tom Vidal)
    • 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
    • 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...
    • 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)
    • 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
    • also can use some of OSI and FSF lists as the affirmative guidlines of this
    • 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
    • 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
    • → Tom Vidal to draft first stab and send to group before next meeting for discussion

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. 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.

process for adding (or rejecting licenses)

re: Flora in particular and generally. our process guidelines for this doesn't really address what happens when it is rejected.

  • confer with LF on this license (contact Karen Copenhaver on this - Paul to do this)
  • get back to license submitter that it's under review (Tom I.)
Retrieved from "https://wiki.spdx.org/index.php?title=Legal_Team/Minutes/2012-10-31&oldid=2258"