Legal Team/Minutes/2017-02-15-OSLS - Revision history

Jlovejoy at 17:30, 23 February 2017

2017-02-23T17:30:30Z

Jlovejoy: /* Agenda (morning legal team meeting) */

2017-02-16T19:53:01Z

‎Agenda (morning legal team meeting)

Jlovejoy: /* Agenda (morning legal team meeting) */

2017-02-16T19:52:15Z

‎Agenda (morning legal team meeting)

Jlovejoy at 19:51, 16 February 2017

2017-02-16T19:51:51Z

Jlovejoy at 19:50, 16 February 2017

2017-02-16T19:50:12Z

Jlovejoy: /* Agenda */

2017-02-16T19:48:58Z

‎Agenda

Jlovejoy: /* Agenda */

2017-02-16T19:38:59Z

‎Agenda

Jlovejoy: /* Attendees */

2017-02-16T19:28:54Z

‎Attendees

Jlovejoy: Created page with "== Attendees == * Jilayne Lovejoy * Paul Madick * Alexios Zavrias * Hung Chang * Steven Esser * Gary O'Neall * Mark Gisi * Yev * Brad Edmondon (phone) * Sam Elllis (phone) ==..."

2017-02-16T19:28:02Z

Created page with "== Attendees == * Jilayne Lovejoy * Paul Madick * Alexios Zavrias * Hung Chang * Steven Esser * Gary O'Neall * Mark Gisi * Yev * Brad Edmondon (phone) * Sam Elllis (phone) ==..."

New page

== Attendees ==
* Jilayne Lovejoy
* Paul Madick
* Alexios Zavrias
* Hung Chang
* Steven Esser
* Gary O'Neall
* Mark Gisi
* Yev
* Brad Edmondon (phone)
* Sam Elllis (phone)

== Agenda ==

Go through, update, and identify areas that are done, need work, need help from Action Plan - http://wiki.spdx.org/view/Legal_Team/Templatizing/ActionPlan --> see page for updates, further notes below:
*

@@ Line 11: / Line 11: @@
 * Sam Elllis (phone)
-== Agenda (morning legal team meeting) ==
+== Agenda (morning legal team meeting w/follow-up from afternoon session noted) ==
 Went through, update, and identify areas that are done, need work, need help from Action Plan - http://wiki.spdx.org/view/Legal_Team/Templatizing/ActionPlan --> see page for updates, further notes below:
-Items identified for later, broader meeting in bold.
+Items identified for later, broader meeting in bold below.
 * Kris' conversion tool made available:
@@ Line 33: / Line 33: @@
 *** define a new XML tag = listVersionAdded as an attribute; value would be: 2.3 (see https://docs.google.com/document/d/1z9n44xLH2MxT576KS_AbTOBtecyl5cw6RsrrQHibQtg/edit for full info)
 *** do we want to display this or just have it in the file? no for now, do not display
-*** '''make sure tech team is ok with this plan and name'''
+*** '''make sure tech team is ok with this plan and name''' - checked during later session, OK
 * incorporating synonyms into XML - wait on this. method - central dictionary or per license basis? Added to action plan as was not listed there before
@@ Line 41: / Line 41: @@
 ** start with improving messages on lead-in, e.g., start with "The SPDX License List is comprised of..." and then list all aspects. Move up Matching Guidelines, add hooks to relevant sections of spec
 ** should we add sentence in every license page that links to Matching Guidelines?
-** '''other feedback on improvements to this end?'''
+** '''other feedback on improvements to this end?''' - legal team to make suggested revisions for others to review
 ** also need “how to” doc on how to use the license list or examples of how to use the license list, including matching guidelines and examples — to go here: http://wiki.spdx.org/view/Documents —> Jack to add link // Sam and Jack to do first draft
-** '''Appendix II will need to be updated when go live - should this be with v2.2 of spec or can it be maintenance release?'''
+** '''Appendix II will need to be updated when go live - should this be with v2.2 of spec or can it be maintenance release?''' - would be a v2.2 release of spec

@@ Line 33: / Line 33: @@
 *** define a new XML tag = listVersionAdded as an attribute; value would be: 2.3 (see https://docs.google.com/document/d/1z9n44xLH2MxT576KS_AbTOBtecyl5cw6RsrrQHibQtg/edit for full info)
 *** do we want to display this or just have it in the file? no for now, do not display
-*** ' ' 'make sure tech team is ok with this plan and name' ' '
+*** '''make sure tech team is ok with this plan and name'''
 * incorporating synonyms into XML - wait on this. method - central dictionary or per license basis? Added to action plan as was not listed there before
@@ Line 41: / Line 41: @@
 ** start with improving messages on lead-in, e.g., start with "The SPDX License List is comprised of..." and then list all aspects. Move up Matching Guidelines, add hooks to relevant sections of spec
 ** should we add sentence in every license page that links to Matching Guidelines?
-** ' ' 'other feedback on improvements to this end?' ' '
+** '''other feedback on improvements to this end?'''
 ** also need “how to” doc on how to use the license list or examples of how to use the license list, including matching guidelines and examples — to go here: http://wiki.spdx.org/view/Documents —> Jack to add link // Sam and Jack to do first draft
-** ' ' 'Appendix II will need to be updated when go live - should this be with v2.2 of spec or can it be maintenance release?' ' '
+** '''Appendix II will need to be updated when go live - should this be with v2.2 of spec or can it be maintenance release?'''

@@ Line 33: / Line 33: @@
 *** define a new XML tag = listVersionAdded as an attribute; value would be: 2.3 (see https://docs.google.com/document/d/1z9n44xLH2MxT576KS_AbTOBtecyl5cw6RsrrQHibQtg/edit for full info)
 *** do we want to display this or just have it in the file? no for now, do not display
-*** ' ' ' make sure tech team is ok with this plan and name' ' '
+*** ' ' 'make sure tech team is ok with this plan and name' ' '
 * incorporating synonyms into XML - wait on this. method - central dictionary or per license basis? Added to action plan as was not listed there before

@@ Line 32: / Line 32: @@
 *** don’t add them for all the “old” licenses; add as of 2.6 and going forward so that it shows up somewhere as example; anyone can pull request to go back for older versions and add it
 *** define a new XML tag = listVersionAdded as an attribute; value would be: 2.3 (see https://docs.google.com/document/d/1z9n44xLH2MxT576KS_AbTOBtecyl5cw6RsrrQHibQtg/edit for full info)
-*** do we want to display this or just have it in the file? no for now
+*** do we want to display this or just have it in the file? no for now, do not display
-*** ' 'make sure tech team is ok with this plan and name' '
+*** ' ' ' make sure tech team is ok with this plan and name' ' '
 * incorporating synonyms into XML - wait on this. method - central dictionary or per license basis? Added to action plan as was not listed there before
@@ Line 41: / Line 41: @@
 ** start with improving messages on lead-in, e.g., start with "The SPDX License List is comprised of..." and then list all aspects. Move up Matching Guidelines, add hooks to relevant sections of spec
 ** should we add sentence in every license page that links to Matching Guidelines?
-** other feedback on improvements to this end?
+** ' ' 'other feedback on improvements to this end?' ' '
 ** also need “how to” doc on how to use the license list or examples of how to use the license list, including matching guidelines and examples — to go here: http://wiki.spdx.org/view/Documents —> Jack to add link // Sam and Jack to do first draft
-** Appendix II will need to be updated when go live - should this be with v2.2 of spec or can it be maintenance release?
+** ' ' 'Appendix II will need to be updated when go live - should this be with v2.2 of spec or can it be maintenance release?' ' '

@@ Line 11: / Line 11: @@
 * Sam Elllis (phone)
-== Agenda ==
+== Agenda (morning legal team meeting) ==
 * Kris' conversion tool made available:
 ** Tool requires a bunch of environment stuff, so would be too much to ask people requesting a new license to use it.   Better workflow to have someone from team set it up.
@@ Line 23: / Line 25: @@
 ** done but for a handful, needs non-deprecated GPL licenses to be done
-* when a new license is added to the list, it is currently recorded in the SPDX License List master spreadsheet. Where will this info be in the new XML world? Should we put this meta data in license itself, as a new tag or can we use Github release magic to track that way?
+* When a new license is added to the list, it is currently recorded in the SPDX License List master spreadsheet. Where will this info be in the new XML world? Should we put this meta data in license itself, as a new tag or can we use Github release magic to track that way?
 ** discussion on various options for this and why we want to retain this info:
 *** what licenses were added for a given release?
@@ Line 31: / Line 33: @@
 *** define a new XML tag = listVersionAdded as an attribute; value would be: 2.3 (see https://docs.google.com/document/d/1z9n44xLH2MxT576KS_AbTOBtecyl5cw6RsrrQHibQtg/edit for full info)
 *** do we want to display this or just have it in the file? no for now
-*** make sure tech team is ok with this plan and name
+*** ' 'make sure tech team is ok with this plan and name' '
 * incorporating synonyms into XML - wait on this. method - central dictionary or per license basis? Added to action plan as was not listed there before

← Older revision		Revision as of 19:48, 16 February 2017
Line 33:		Line 33:
	*** make sure tech team is ok with this plan and name		*** make sure tech team is ok with this plan and name

−	*	+	* incorporating synonyms into XML - wait on this. method - central dictionary or per license basis? Added to action plan as was not listed there before
		+
		+	* Updates to spec as result of XML conversion and general discussion on ensuring people understand all the aspects of the SPDX License List (not just a "list", also includes matching guidelines, etc.)
		+	** should the SPDX License List and all it entails (e.g. Appendix 1, 2, 4) be its own spec, which would enable development at a different pace
		+	** start with improving messages on lead-in, e.g., start with "The SPDX License List is comprised of..." and then list all aspects. Move up Matching Guidelines, add hooks to relevant sections of spec
		+	** should we add sentence in every license page that links to Matching Guidelines?
		+	** other feedback on improvements to this end?
		+	** also need “how to” doc on how to use the license list or examples of how to use the license list, including matching guidelines and examples — to go here: http://wiki.spdx.org/view/Documents —> Jack to add link // Sam and Jack to do first draft
		+	** Appendix II will need to be updated when go live - should this be with v2.2 of spec or can it be maintenance release?

← Older revision		Revision as of 19:38, 16 February 2017
Line 14:		Line 14:

	Go through, update, and identify areas that are done, need work, need help from Action Plan - http://wiki.spdx.org/view/Legal_Team/Templatizing/ActionPlan --> see page for updates, further notes below:		Go through, update, and identify areas that are done, need work, need help from Action Plan - http://wiki.spdx.org/view/Legal_Team/Templatizing/ActionPlan --> see page for updates, further notes below:
		+	* Kris' conversion tool made available:
		+	** Tool requires a bunch of environment stuff, so would be too much to ask people requesting a new license to use it. Better workflow to have someone from team set it up.
		+	** Gary thinks it may be just as easy to hand-code it, but would need a good example or .xsd so then could use that and validation (instead of Kris' tool). Then can use an XML editor to load .xsd that can then check. Need to finalize tags/clean-up run before creating .xsd schema. If requestor wants to run it, then they can use pull request, if not up for it then they can submit issue.
		+	*** Jack, Gary, Brad to work on this. will put this in license list repo
		+	*** NOTE: this will also impact instructions for requesting a new license, so will need to update documentation to reflect this
		+
		+	* Convert and add deprecated licenses to repository (GARY)
		+	** done but for a handful, needs non-deprecated GPL licenses to be done
		+
		+	* when a new license is added to the list, it is currently recorded in the SPDX License List master spreadsheet. Where will this info be in the new XML world? Should we put this meta data in license itself, as a new tag or can we use Github release magic to track that way?
		+	** discussion on various options for this and why we want to retain this info:
		+	*** what licenses were added for a given release?
		+	*** (what licenses were updated for a given release?) - captured in Git commit messages
		+	** decision to have meta data in license for version. This would require adding an optional XML field/tag.
		+	*** don’t add them for all the “old” licenses; add as of 2.6 and going forward so that it shows up somewhere as example; anyone can pull request to go back for older versions and add it
		+	*** define a new XML tag = listVersionAdded as an attribute; value would be: 2.3 (see https://docs.google.com/document/d/1z9n44xLH2MxT576KS_AbTOBtecyl5cw6RsrrQHibQtg/edit for full info)
		+	*** do we want to display this or just have it in the file? no for now
		+	*** make sure tech team is ok with this plan and name
		+
	*		*

@@ Line 7: / Line 7: @@
 * Gary O'Neall
 * Mark Gisi
-* Yev
+* Yev Bronshteyn
 * Brad Edmondon (phone)
 * Sam Elllis (phone)