Legal Team/Minutes/2011-08-10 - Revision history

MartinMichlmayr: Convert to MediaWiki syntax

2013-03-05T18:45:37Z

Convert to MediaWiki syntax

Jlovejoy at 20:00, 16 December 2011

2011-12-16T20:00:19Z

Jlovejoy at 19:57, 16 December 2011

2011-12-16T19:57:49Z

New page

SPDX Legal Team Minutes - 10-August-2011  Attendees:Esteban Rockett, MotorolaKim Weins, OpenLogicPeter Williams, OpenLogicKirsten Newcomer, Black DuckBill Schneiller, Black DuckTom Incorvia, MicrofocusJack ManbeckTerry Ilardi, IBMAdam Cohn, CiscoKate Stewart, CanonicalJack Manbeck, TI Michael Herzog, NexBGary O'Neal, Source AuditorJordan Hatcher, ARMJilayne Lovejoy, OpenLogic Agenda:- focus on review and comments to the below draft SPDX Trademark license- further discussion re: confidentiality of spec as between users -- Rockett circulated the proposed trademark license text prior to meeting, copied here: --- SPDX‚Ñ¢ Trademark License The ‚ÄúSPDX‚Äù and ‚ÄúSoftware Package Data Exchange‚Äù trademarks (collectively, ‚ÄúSPDX Trademarks‚Äù) are owned by the SPDX Workgroup, which is sponsored by the Linux Foundation (‚ÄúLF‚Äù).  LF holds the SPDX Trademarks in trust for the SPDX Workgroup.  The SPDX Workgroup hereby grants you a royalty-free, non-exclusive, non-assignable, non-transferable, non-sublicensable, world-wide license to use its SPDX Trademarks in connection with files containing software licensing information if you: (i) solely use the SPDX Trademarks in connection with files containing all of the SPDX ‚ÄúMandatory Fields‚Äù as defined in the applicable version of the SPDX specification; (ii) solely uses the SPDX Trademarks in connection with files that do not utilize additional fields, unless such additional fields are ‚ÄúOptional Fields‚Äù as defined in the applicable version of the SPDX specification; (iii) recite the applicable SPDX Specification version in, or with, your use of any of the SPDX Trademarks; and (iv) fully comply with (a) the SDPX Specification and (b) the license (Creative Commons Attribution License 3.0 (also known as CC-BY-3.0)) under which the SPDX Specification is offered in its entirety.  This SPDX TM License shall automatically be revoked in perpetuity if you fail to comply with any of the above requirements.  A revoked SPDX TM License may only be restored by (i) you submitting a petition for restoration to the Legal Team of the SPDX Workgroup (‚ÄúLegal Team‚Äù), (ii) attending any required meetings for inquiry in the circumstances, and (iii) a consensus of the Legal Team to restore your license. --- MEETING:- Rockett went through the trademark license and gave an overview of the what/why of each part -- CC-BY-3.0 version issue: (raised via email prior to meeting) CC licenses currently have ports to various jurisdictions, so you need to identify the jurisdiction type.  I'm not sure what we are using, but if it is the Unported (raw) version, then suggest we slightly tweak it and change the reference to " Creative Commons Attribution 3.0 Unported License"- DECISION:  add "Unported" to designation in spec; -- Discussion about meaning of compliance with CC license: current license only requires attribution (but still could sell it) - Discussion on whether we want to allow selling it - okay b/c might be case where spec is built into a tool or larger product-- Clarification: CC applies to spec itself, whereas PddL covers the SPDX file itself - DECISION:  Should add to (iv)(a) - the SPDX Specification authored/published by the SPDX Working Group and provide url location of spec-- Also need to specify where and how to do the attribution (CC license assumes author will designate this) and include this info in the spec (and trademark license?)- Give a couple versions of this for full compliance versus based-on-SPDX scenario?- DECISION:  Rockett to make a cut on this and circulate to Legal and Technical and then let people comment with goal of closing on this during General Call tomorrow-- Section (ii) issue: (raised via email prior to meeting) This requirement provides no value and does significant harm to future prospects of SPDX.  It will stifle innovation by making experimentation with new fields and types of data illegal.  It also will drive people out of the SPDX community if they have business requirements that not meet by the current version of SPDX.  In both of these cases we should actively encourage people to extend SPDX to their needs.  We can use information resulting from such experimentation to guide improvements in future versions.  Some might be concerned that allowing data other than that in the specification will cause technical problems with interoperability butthis is not a problem.  RDF is designed to support safe and easy extension so SPDX data encoded in RDF will be readable by any compliant SPDX consumer regardless of any extra "fields" that are included.  The syntax of tag format does not allow any ad hoc extensions at all so consumers of the tag format are also safe.- Discussion/concerns/comments raised: -- most standard groups allow people to add other fields-- what about tag values and interoperability ‚Üí nothing enforceable and could have potential diversions-- some of extensions that could be added could veer into "making an interpretation" that we have tried to avoid and these fields could be added without review-- but anyone who added a field, doesn't mean field gets added to the spec-- if add field, then person getting SPDX file may assume its part of spec-- Currently, users can put other ideas into various existing free form comment fields - Want to allow extensibility over time - how to do this? May be that optional fields will grow faster than mandatory fields.  Want ability to have user defined fields ‚Üí how to do this requires later more in depth discussion‚Ä¶- the boundaries of change are spec issues, not trademark license discussion - trademark license need only be flexible enough to refer to spec and quality guidelines therein, while balancing trademark law concern with quality control- Fields in spec now are "mandatory" or "optional" - can be interpreted different ways, but by being specific, could be limiting, if add other language to allow room for adding other fields in future with less confusion-- DECISION:  put an "out" in clause (ii) - "as defined in applicable version of the SPDX‚Ä¶ or as extensions as defined‚Ä¶" - Rockett to draft something and table larger discussion of whether, and how to change spec to allow additional fields (what, if anything, and how much and how you can modify it)-- Interplay of confidentiality and SPDX: idea of labelling SPDX file as confidential raises concern that that labelling would only impact the parties to the NDA and downstream recipients would still see the label and shouldn't have to be concerned under PddL.  Downstream recipients may treat it as confidential or not.- No confidentiality field at all right now (was previously and just decided to drop this field) - no place to enter this in section 2, SPDX Information.  Parties would use a separate confidentiality agreement to achieve this goal, i.e. outside wrapper, you come up with this on your own, not part of SPDX spec or file itself- How do we allow parties to have confidentiality, but non-parties not see the label?-- DECISION:  Defer to technical team to propose solutions for next version of spec?

← Older revision		Revision as of 18:45, 5 March 2013
Line 1:		Line 1:
−	~~<p><strong>SPDX Legal Team Minutes - 10-August-2011 </strong></p><p>~~Attendees~~:</p><p>~~Esteban Rockett, Motorola~~</p><p>~~Kim Weins, OpenLogic~~</p><p>~~Peter Williams, OpenLogic~~</p><p>~~Kirsten Newcomer, Black Duck~~</p><p>~~Bill Schneiller, Black Duck~~</p><p>~~Tom Incorvia, Microfocus~~</p><p>~~Jack Manbeck~~</p><p>~~Terry Ilardi, IBM~~</p><p>~~Adam Cohn, Cisco~~</p><p>~~Kate Stewart, Canonical~~</p><p>~~Jack Manbeck, TI~~ </p><p>~~Michael Herzog, NexB~~</p><p>~~Gary O'Neal, Source Auditor~~</p><p>~~Jordan Hatcher, ARM~~</p><p>~~Jilayne Lovejoy, OpenLogic~~</p><p>~~Agenda~~:</p><p>-~~ focus on review and comments to the below draft SPDX Trademark license~~</p><p>-~~ further discussion re: confidentiality of spec as between users~~</p><p>--~~ Rockett circulated the proposed trademark license text prior to meeting, copied here:~~</p><p> </p><p>---</p><p> </p><p>~~SPDX Trademark License~~</p><p> </p><p>~~The SPDX and Software Package Data Exchange trademarks (collectively, SPDX Trademarks) are owned by the SPDX Workgroup, which is sponsored by the Linux Foundation (LF). ~~ ~~LF holds the SPDX Trademarks in trust for the SPDX Workgroup. ~~ ~~The SPDX Workgroup hereby grants you a royalty-free, non-exclusive, non-assignable, non-transferable, non-sublicensable, world-wide license to use its SPDX Trademarks in connection with files containing software licensing information if you:~~ </p><p>~~(i) solely use the SPDX Trademarks in connection with files containing all of the SPDX Mandatory Fields as defined in the applicable version of the SPDX specification;~~ </p><p>~~(ii) solely uses the SPDX Trademarks in connection with files that do not utilize additional fields, unless such additional fields are ~~‚ÄúOptional Fields‚Äù~~ as defined in the applicable version of the SPDX specification;~~ </p><p>~~(iii) recite the applicable SPDX Specification version in, or with, your use of any of the SPDX Trademarks; and~~ </p><p>~~(iv) fully comply with (a) the SDPX Specification and (b) the license (Creative Commons Attribution License 3.0 (also known as CC-BY-3.0)) under which the SPDX Specification is offered in its entirety.~~ </p><p> </p><p>~~This SPDX TM License shall automatically be revoked in perpetuity if you fail to comply with any of the above requirements. ~~ ~~A revoked SPDX TM License may only be restored by (i) you submitting a petition for restoration to the Legal Team of the SPDX Workgroup (Legal Team), (ii) attending any required meetings for inquiry in the circumstances, and (iii) a consensus of the Legal Team to restore your license.~~</p><p>--- </p><p>MEETING:</p><p>-~~ Rockett went through the trademark license and gave an overview of the what/why of each part~~ </p><p>--~~ CC-BY-3.0 version issue: (raised via email prior to meeting) CC licenses currently have ports to various jurisdictions, so you need to identify the jurisdiction type. ~~ ~~I'm not sure what we are using, but if it is the Unported (raw) version, then suggest we slightly tweak it and change the reference to " Creative Commons Attribution 3.0 Unported License"~~</p><p>-~~ DECISION: ~~ ~~add "Unported" to designation in spec;~~ </p><p>--~~ Discussion about meaning of compliance with CC license: current license only requires attribution (but still could sell it)~~ </p><p>-~~ Discussion on whether we want to allow selling it - okay b/c might be case where spec is built into a tool or larger product~~</p><p>--~~ Clarification: CC applies to spec itself, whereas PddL covers the SPDX file itself~~ </p><p>- <strong>~~DECISION~~</strong>~~: ~~ ~~Should add to (iv)(a) - the SPDX Specification authored/published by the SPDX Working Group and provide url location of spec~~</p><p>--~~ Also need to specify where and how to do the attribution (CC license assumes author will designate this) and include this info in the spec (and trademark license?)~~</p><p>-~~ Give a couple versions of this for full compliance versus based-on-SPDX scenario?~~</p><p>- <strong>~~DECISION~~</strong>~~: ~~ ~~Rockett to make a cut on this and circulate to Legal and Technical and then let people comment with goal of closing on this during General Call tomorrow~~</p><p>--~~ Section (ii) issue: (raised via email prior to meeting) This requirement provides no value and does significant harm to future prospects of SPDX. ~~ ~~It will stifle innovation by making experimentation with new fields and types of data illegal. ~~ ~~It also will drive people out of the SPDX community if they have business requirements that not meet by the current version of SPDX. ~~ ~~In both of these cases we should actively encourage people to extend SPDX to their needs. ~~ ~~We can use information resulting from such experimentation to guide improvements in future versions. ~~ ~~Some might be concerned that allowing data other than that in the specification will cause technical problems with interoperability butthis is not a problem. ~~ ~~RDF is designed to support safe and easy extension so SPDX data encoded in RDF will be readable by any compliant SPDX consumer regardless of any extra "fields" that are included. ~~ ~~The syntax of tag format does not allow any ad hoc extensions at all so consumers of the tag format are also safe.~~</p><p>-~~ Discussion/concerns/comments raised:~~ </p><p>--~~ most standard groups allow people to add other fields~~</p><p>--~~ what about tag values and interoperability ‚Üí nothing enforceable and could have potential diversions~~</p><p>--~~ some of extensions that could be added could veer into "making an interpretation" that we have tried to avoid and these fields could be added without review~~</p><p>--~~ but anyone who added a field, doesn't mean field gets added to the spec~~</p><p>--~~ if add field, then person getting SPDX file may assume its part of spec~~</p><p>--~~ Currently, users can put other ideas into various existing free form comment fields~~ </p><p>-~~ Want to allow extensibility over time - how to do this? May be that optional fields will grow faster than mandatory fields. ~~ ~~Want ability to have user defined ~~fields ‚Üí~~ how to do this requires later more in depth ~~discussion‚Ä¶</p><p>-~~ the boundaries of change are spec issues, not trademark license discussion - trademark license need only be flexible enough to refer to spec and quality guidelines therein, while balancing trademark law concern with quality control~~</p><p>-~~ Fields in spec now are "mandatory" or "optional" - can be interpreted different ways, but by being specific, could be limiting, if add other language to allow room for adding other fields in future with less confusion~~</p><p>-- <strong>~~DECISION~~</strong>~~: ~~ ~~put an "out" in clause (ii) - "as defined in applicable version of the ~~SPDX‚Ä¶~~ or as extensions as ~~defined‚Ä¶~~" - Rockett to draft something and table larger discussion of whether, and how to change spec to allow additional fields (what, if anything, and how much and how you can modify it)~~</p><p>--~~ Interplay of confidentiality and SPDX: idea of labelling SPDX file as confidential raises concern that that labelling would only impact the parties to the NDA and downstream recipients would still see the label and shouldn't have to be concerned under PddL. ~~ ~~Downstream recipients may treat it as confidential or not.~~</p><p>-~~ No confidentiality field at all right now (was previously and just decided to drop this field) - no place to enter this in section 2, SPDX Information. ~~ ~~Parties would use a separate confidentiality agreement to achieve this goal, i.e. outside wrapper, you come up with this on your own, not part of SPDX spec or file itself~~</p><p>-~~ How do we allow parties to have confidentiality, but non-parties not see the label?~~</p><p>-- <strong>~~DECISION~~</strong>~~: ~~ ~~Defer to technical team to propose solutions for next version of spec?~~</p>~~	+	== Attendees ==
		+
		+	* Esteban Rockett, Motorola
		+	* Kim Weins, OpenLogic
		+	* Peter Williams, OpenLogic
		+	* Kirsten Newcomer, Black Duck
		+	* Bill Schneiller, Black Duck
		+	* Tom Incorvia, Microfocus
		+	* Jack Manbeck
		+	* Terry Ilardi, IBM
		+	* Adam Cohn, Cisco
		+	* Kate Stewart, Canonical
		+	* Jack Manbeck, TI
		+	* Michael Herzog, NexB
		+	* Gary O'Neal, Source Auditor
		+	* Jordan Hatcher, ARM
		+	* Jilayne Lovejoy, OpenLogic
		+
		+	== Agenda ==
		+
		+	* focus on review and comments to the below draft SPDX Trademark license
		+	* further discussion re: confidentiality of spec as between users
		+	* Rockett circulated the proposed trademark license text prior to meeting, copied here:
		+
		+	== SPDX Trademark License ==
		+
		+	The SPDX and Software Package Data Exchange trademarks (collectively, SPDX Trademarks) are owned by the SPDX Workgroup, which is sponsored by the Linux Foundation (LF). LF holds the SPDX Trademarks in trust for the SPDX Workgroup. The SPDX Workgroup hereby grants you a royalty-free, non-exclusive, non-assignable, non-transferable, non-sublicensable, world-wide license to use its SPDX Trademarks in connection with files containing software licensing information if you:
		+
		+	(i) solely use the SPDX Trademarks in connection with files containing all of the SPDX Mandatory Fields as defined in the applicable version of the SPDX specification;
		+
		+	(ii) solely uses the SPDX Trademarks in connection with files that do not utilize additional fields, unless such additional fields are "Optional Fields‚" as defined in the applicable version of the SPDX specification;
		+
		+	(iii) recite the applicable SPDX Specification version in, or with, your use of any of the SPDX Trademarks; and
		+
		+	(iv) fully comply with (a) the SDPX Specification and (b) the license (Creative Commons Attribution License 3.0 (also known as CC-BY-3.0)) under which the SPDX Specification is offered in its entirety.
		+
		+	This SPDX TM License shall automatically be revoked in perpetuity if you fail to comply with any of the above requirements. A revoked SPDX TM License may only be restored by (i) you submitting a petition for restoration to the Legal Team of the SPDX Workgroup (Legal Team), (ii) attending any required meetings for inquiry in the circumstances, and (iii) a consensus of the Legal Team to restore your license.
		+
		+	== Minutes ==
		+
		+	* Rockett went through the trademark license and gave an overview of the what/why of each part
		+	* CC-BY-3.0 version issue: (raised via email prior to meeting) CC licenses currently have ports to various jurisdictions, so you need to identify the jurisdiction type. I'm not sure what we are using, but if it is the Unported (raw) version, then suggest we slightly tweak it and change the reference to "Creative Commons Attribution 3.0 Unported License"
		+	** DECISION: add "Unported" to designation in spec;
		+	* Discussion about meaning of compliance with CC license: current license only requires attribution (but still could sell it)
		+	* Discussion on whether we want to allow selling it - okay b/c might be case where spec is built into a tool or larger product
		+	* Clarification: CC applies to spec itself, whereas PddL covers the SPDX file itself
		+	** '''DECISION''': Should add to (iv)(a) - the SPDX Specification authored/published by the SPDX Working Group and provide url location of spec
		+	** Also need to specify where and how to do the attribution (CC license assumes author will designate this) and include this info in the spec (and trademark license?)
		+	* Give a couple versions of this for full compliance versus based-on-SPDX scenario?
		+	** '''DECISION''': Rockett to make a cut on this and circulate to Legal and Technical and then let people comment with goal of closing on this during General Call tomorrow
		+	** Section (ii) issue: (raised via email prior to meeting) This requirement provides no value and does significant harm to future prospects of SPDX. It will stifle innovation by making experimentation with new fields and types of data illegal. It also will drive people out of the SPDX community if they have business requirements that not meet by the current version of SPDX. In both of these cases we should actively encourage people to extend SPDX to their needs. We can use information resulting from such experimentation to guide improvements in future versions. Some might be concerned that allowing data other than that in the specification will cause technical problems with interoperability butthis is not a problem. RDF is designed to support safe and easy extension so SPDX data encoded in RDF will be readable by any compliant SPDX consumer regardless of any extra "fields" that are included. The syntax of tag format does not allow any ad hoc extensions at all so consumers of the tag format are also safe.
		+	* Discussion/concerns/comments raised:
		+	** most standard groups allow people to add other fields
		+	** what about tag values and interoperability ‚Üí nothing enforceable and could have potential diversions
		+	** some of extensions that could be added could veer into "making an interpretation" that we have tried to avoid and these fields could be added without review
		+	** but anyone who added a field, doesn't mean field gets added to the spec
		+	** if add field, then person getting SPDX file may assume its part of spec
		+	** Currently, users can put other ideas into various existing free form comment fields
		+	* Want to allow extensibility over time - how to do this? May be that optional fields will grow faster than mandatory fields. Want ability to have user defined fields‚ how to do this requires later more in depth discussion‚
		+	* the boundaries of change are spec issues, not trademark license discussion - trademark license need only be flexible enough to refer to spec and quality guidelines therein, while balancing trademark law concern with quality control
		+	* Fields in spec now are "mandatory" or "optional" - can be interpreted different ways, but by being specific, could be limiting, if add other language to allow room for adding other fields in future with less confusion
		+	** '''DECISION''': put an "out" in clause (ii) - "as defined in applicable version of the SPDX‚ or as extensions as defined‚"
		+	* Rockett to draft something and table larger discussion of whether, and how to change spec to allow additional fields (what, if anything, and how much and how you can modify it)
		+	* Interplay of confidentiality and SPDX: idea of labelling SPDX file as confidential raises concern that that labelling would only impact the parties to the NDA and downstream recipients would still see the label and shouldn't have to be concerned under PddL. Downstream recipients may treat it as confidential or not.
		+	* No confidentiality field at all right now (was previously and just decided to drop this field) - no place to enter this in section 2, SPDX Information. Parties would use a separate confidentiality agreement to achieve this goal, i.e. outside wrapper, you come up with this on your own, not part of SPDX spec or file itself
		+	* How do we allow parties to have confidentiality, but non-parties not see the label?
		+	** '''DECISION''': Defer to technical team to propose solutions for next version of spec?
		+
		+	[[Category:Legal\|Minutes]]
		+	[[Category:Minutes]]

← Older revision		Revision as of 20:00, 16 December 2011
Line 1:		Line 1:
−	<p>SPDX Legal Team Minutes - 10-August-2011 </p>~~<p> ~~</p><p>Attendees:</p><p>Esteban Rockett, Motorola</p><p>Kim Weins, OpenLogic</p><p>Peter Williams, OpenLogic</p><p>Kirsten Newcomer, Black Duck</p><p>Bill Schneiller, Black Duck</p><p>Tom Incorvia, Microfocus</p><p>Jack Manbeck</p><p>Terry Ilardi, IBM</p><p>Adam Cohn, Cisco</p><p>Kate Stewart, Canonical</p><p>Jack Manbeck, TI </p><p>Michael Herzog, NexB</p><p>Gary O'Neal, Source Auditor</p><p>Jordan Hatcher, ARM</p><p>Jilayne Lovejoy, OpenLogic~~</p><p> ~~</p><p>Agenda:</p><p>- focus on review and comments to the below draft SPDX Trademark license</p><p>- further discussion re: confidentiality of spec as between users~~</p><p> ~~</p><p>-- Rockett circulated the proposed trademark license text prior to meeting, copied here:</p><p> </p><p>---</p><p> </p><p>~~SPDX‚Ñ¢~~ Trademark License</p><p> </p><p>The ~~‚ÄúSPDX‚Äù~~ and ~~‚ÄúSoftware~~ Package Data ~~Exchange‚Äù~~ trademarks (collectively, ~~‚ÄúSPDX Trademarks‚Äù~~) are owned by the SPDX Workgroup, which is sponsored by the Linux Foundation (~~‚ÄúLF‚Äù~~).  LF holds the SPDX Trademarks in trust for the SPDX Workgroup.  The SPDX Workgroup hereby grants you a royalty-free, non-exclusive, non-assignable, non-transferable, non-sublicensable, world-wide license to use its SPDX Trademarks in connection with files containing software licensing information if you: </p><p>(i) solely use the SPDX Trademarks in connection with files containing all of the SPDX ~~‚ÄúMandatory Fields‚Äù~~ as defined in the applicable version of the SPDX specification; </p><p>(ii) solely uses the SPDX Trademarks in connection with files that do not utilize additional fields, unless such additional fields are ‚ÄúOptional Fields‚Äù as defined in the applicable version of the SPDX specification; </p><p>(iii) recite the applicable SPDX Specification version in, or with, your use of any of the SPDX Trademarks; and </p><p>(iv) fully comply with (a) the SDPX Specification and (b) the license (Creative Commons Attribution License 3.0 (also known as CC-BY-3.0)) under which the SPDX Specification is offered in its entirety. </p><p> </p><p>This SPDX TM License shall automatically be revoked in perpetuity if you fail to comply with any of the above requirements.  A revoked SPDX TM License may only be restored by (i) you submitting a petition for restoration to the Legal Team of the SPDX Workgroup (~~‚ÄúLegal Team‚Äù~~), (ii) attending any required meetings for inquiry in the circumstances, and (iii) a consensus of the Legal Team to restore your license.~~</p><p> ~~</p><p>---~~</p><p>~~ </p><p>MEETING:</p><p>- Rockett went through the trademark license and gave an overview of the what/why of each part </p><p>-- CC-BY-3.0 version issue: (raised via email prior to meeting) CC licenses currently have ports to various jurisdictions, so you need to identify the jurisdiction type.  I'm not sure what we are using, but if it is the Unported (raw) version, then suggest we slightly tweak it and change the reference to " Creative Commons Attribution 3.0 Unported License"</p><p>- DECISION:  add "Unported" to designation in spec; </p><p>-- Discussion about meaning of compliance with CC license: current license only requires attribution (but still could sell it) </p><p>- Discussion on whether we want to allow selling it - okay b/c might be case where spec is built into a tool or larger product</p><p>-- Clarification: CC applies to spec itself, whereas PddL covers the SPDX file itself~~</p><p>~~ </p><p>- DECISION:  Should add to (iv)(a) - the SPDX Specification authored/published by the SPDX Working Group and provide url location of spec</p><p>-- Also need to specify where and how to do the attribution (CC license assumes author will designate this) and include this info in the spec (and trademark license?)</p><p>- Give a couple versions of this for full compliance versus based-on-SPDX scenario?</p><p>- DECISION:  Rockett to make a cut on this and circulate to Legal and Technical and then let people comment with goal of closing on this during General Call tomorrow</p><p>-- Section (ii) issue: (raised via email prior to meeting) This requirement provides no value and does significant harm to future prospects of SPDX.  It will stifle innovation by making experimentation with new fields and types of data illegal.  It also will drive people out of the SPDX community if they have business requirements that not meet by the current version of SPDX.  In both of these cases we should actively encourage people to extend SPDX to their needs.  We can use information resulting from such experimentation to guide improvements in future versions.  Some might be concerned that allowing data other than that in the specification will cause technical problems with interoperability butthis is not a problem.  RDF is designed to support safe and easy extension so SPDX data encoded in RDF will be readable by any compliant SPDX consumer regardless of any extra "fields" that are included.  The syntax of tag format does not allow any ad hoc extensions at all so consumers of the tag format are also safe.</p><p>- Discussion/concerns/comments raised: </p><p>-- most standard groups allow people to add other fields</p><p>-- what about tag values and interoperability ‚Üí nothing enforceable and could have potential diversions</p><p>-- some of extensions that could be added could veer into "making an interpretation" that we have tried to avoid and these fields could be added without review</p><p>-- but anyone who added a field, doesn't mean field gets added to the spec</p><p>-- if add field, then person getting SPDX file may assume its part of spec</p><p>-- Currently, users can put other ideas into various existing free form comment fields </p><p>- Want to allow extensibility over time - how to do this? May be that optional fields will grow faster than mandatory fields.  Want ability to have user defined fields ‚Üí how to do this requires later more in depth discussion‚Ä¶</p><p>- the boundaries of change are spec issues, not trademark license discussion - trademark license need only be flexible enough to refer to spec and quality guidelines therein, while balancing trademark law concern with quality control</p><p>- Fields in spec now are "mandatory" or "optional" - can be interpreted different ways, but by being specific, could be limiting, if add other language to allow room for adding other fields in future with less confusion</p><p>-- DECISION:  put an "out" in clause (ii) - "as defined in applicable version of the SPDX‚Ä¶ or as extensions as defined‚Ä¶" - Rockett to draft something and table larger discussion of whether, and how to change spec to allow additional fields (what, if anything, and how much and how you can modify it)</p><p>-- Interplay of confidentiality and SPDX: idea of labelling SPDX file as confidential raises concern that that labelling would only impact the parties to the NDA and downstream recipients would still see the label and shouldn't have to be concerned under PddL.  Downstream recipients may treat it as confidential or not.</p><p>- No confidentiality field at all right now (was previously and just decided to drop this field) - no place to enter this in section 2, SPDX Information.  Parties would use a separate confidentiality agreement to achieve this goal, i.e. outside wrapper, you come up with this on your own, not part of SPDX spec or file itself</p><p>- How do we allow parties to have confidentiality, but non-parties not see the label?</p><p>-- DECISION:  Defer to technical team to propose solutions for next version of spec?</p>	+	<p><strong>SPDX Legal Team Minutes - 10-August-2011 </strong></p><p>Attendees:</p><p>Esteban Rockett, Motorola</p><p>Kim Weins, OpenLogic</p><p>Peter Williams, OpenLogic</p><p>Kirsten Newcomer, Black Duck</p><p>Bill Schneiller, Black Duck</p><p>Tom Incorvia, Microfocus</p><p>Jack Manbeck</p><p>Terry Ilardi, IBM</p><p>Adam Cohn, Cisco</p><p>Kate Stewart, Canonical</p><p>Jack Manbeck, TI </p><p>Michael Herzog, NexB</p><p>Gary O'Neal, Source Auditor</p><p>Jordan Hatcher, ARM</p><p>Jilayne Lovejoy, OpenLogic</p><p>Agenda:</p><p>- focus on review and comments to the below draft SPDX Trademark license</p><p>- further discussion re: confidentiality of spec as between users</p><p>-- Rockett circulated the proposed trademark license text prior to meeting, copied here:</p><p> </p><p>---</p><p> </p><p>SPDX Trademark License</p><p> </p><p>The SPDX and Software Package Data Exchange trademarks (collectively, SPDX Trademarks) are owned by the SPDX Workgroup, which is sponsored by the Linux Foundation (LF).  LF holds the SPDX Trademarks in trust for the SPDX Workgroup.  The SPDX Workgroup hereby grants you a royalty-free, non-exclusive, non-assignable, non-transferable, non-sublicensable, world-wide license to use its SPDX Trademarks in connection with files containing software licensing information if you: </p><p>(i) solely use the SPDX Trademarks in connection with files containing all of the SPDX Mandatory Fields as defined in the applicable version of the SPDX specification; </p><p>(ii) solely uses the SPDX Trademarks in connection with files that do not utilize additional fields, unless such additional fields are ‚ÄúOptional Fields‚Äù as defined in the applicable version of the SPDX specification; </p><p>(iii) recite the applicable SPDX Specification version in, or with, your use of any of the SPDX Trademarks; and </p><p>(iv) fully comply with (a) the SDPX Specification and (b) the license (Creative Commons Attribution License 3.0 (also known as CC-BY-3.0)) under which the SPDX Specification is offered in its entirety. </p><p> </p><p>This SPDX TM License shall automatically be revoked in perpetuity if you fail to comply with any of the above requirements.  A revoked SPDX TM License may only be restored by (i) you submitting a petition for restoration to the Legal Team of the SPDX Workgroup (Legal Team), (ii) attending any required meetings for inquiry in the circumstances, and (iii) a consensus of the Legal Team to restore your license.</p><p>--- </p><p>MEETING:</p><p>- Rockett went through the trademark license and gave an overview of the what/why of each part </p><p>-- CC-BY-3.0 version issue: (raised via email prior to meeting) CC licenses currently have ports to various jurisdictions, so you need to identify the jurisdiction type.  I'm not sure what we are using, but if it is the Unported (raw) version, then suggest we slightly tweak it and change the reference to " Creative Commons Attribution 3.0 Unported License"</p><p>- DECISION:  add "Unported" to designation in spec; </p><p>-- Discussion about meaning of compliance with CC license: current license only requires attribution (but still could sell it) </p><p>- Discussion on whether we want to allow selling it - okay b/c might be case where spec is built into a tool or larger product</p><p>-- Clarification: CC applies to spec itself, whereas PddL covers the SPDX file itself </p><p>- <strong>DECISION</strong>:  Should add to (iv)(a) - the SPDX Specification authored/published by the SPDX Working Group and provide url location of spec</p><p>-- Also need to specify where and how to do the attribution (CC license assumes author will designate this) and include this info in the spec (and trademark license?)</p><p>- Give a couple versions of this for full compliance versus based-on-SPDX scenario?</p><p>- <strong>DECISION</strong>:  Rockett to make a cut on this and circulate to Legal and Technical and then let people comment with goal of closing on this during General Call tomorrow</p><p>-- Section (ii) issue: (raised via email prior to meeting) This requirement provides no value and does significant harm to future prospects of SPDX.  It will stifle innovation by making experimentation with new fields and types of data illegal.  It also will drive people out of the SPDX community if they have business requirements that not meet by the current version of SPDX.  In both of these cases we should actively encourage people to extend SPDX to their needs.  We can use information resulting from such experimentation to guide improvements in future versions.  Some might be concerned that allowing data other than that in the specification will cause technical problems with interoperability butthis is not a problem.  RDF is designed to support safe and easy extension so SPDX data encoded in RDF will be readable by any compliant SPDX consumer regardless of any extra "fields" that are included.  The syntax of tag format does not allow any ad hoc extensions at all so consumers of the tag format are also safe.</p><p>- Discussion/concerns/comments raised: </p><p>-- most standard groups allow people to add other fields</p><p>-- what about tag values and interoperability ‚Üí nothing enforceable and could have potential diversions</p><p>-- some of extensions that could be added could veer into "making an interpretation" that we have tried to avoid and these fields could be added without review</p><p>-- but anyone who added a field, doesn't mean field gets added to the spec</p><p>-- if add field, then person getting SPDX file may assume its part of spec</p><p>-- Currently, users can put other ideas into various existing free form comment fields </p><p>- Want to allow extensibility over time - how to do this? May be that optional fields will grow faster than mandatory fields.  Want ability to have user defined fields ‚Üí how to do this requires later more in depth discussion‚Ä¶</p><p>- the boundaries of change are spec issues, not trademark license discussion - trademark license need only be flexible enough to refer to spec and quality guidelines therein, while balancing trademark law concern with quality control</p><p>- Fields in spec now are "mandatory" or "optional" - can be interpreted different ways, but by being specific, could be limiting, if add other language to allow room for adding other fields in future with less confusion</p><p>-- <strong>DECISION</strong>:  put an "out" in clause (ii) - "as defined in applicable version of the SPDX‚Ä¶ or as extensions as defined‚Ä¶" - Rockett to draft something and table larger discussion of whether, and how to change spec to allow additional fields (what, if anything, and how much and how you can modify it)</p><p>-- Interplay of confidentiality and SPDX: idea of labelling SPDX file as confidential raises concern that that labelling would only impact the parties to the NDA and downstream recipients would still see the label and shouldn't have to be concerned under PddL.  Downstream recipients may treat it as confidential or not.</p><p>- No confidentiality field at all right now (was previously and just decided to drop this field) - no place to enter this in section 2, SPDX Information.  Parties would use a separate confidentiality agreement to achieve this goal, i.e. outside wrapper, you come up with this on your own, not part of SPDX spec or file itself</p><p>- How do we allow parties to have confidentiality, but non-parties not see the label?</p><p>-- <strong>DECISION</strong>:  Defer to technical team to propose solutions for next version of spec?</p>