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

Difference between revisions of "Legal Team/Minutes/2017-02-15-OSLS"

From SPDX Wiki
Jump to: navigation, search
(Agenda)
Line 11: Line 11:
 
* Sam Elllis (phone)
 
* Sam Elllis (phone)
  
== Agenda ==
+
== Agenda (morning legal team meeting) ==
 +
 
 +
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.
  
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:
 
* 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.  
 
** 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
 
** 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:
 
** 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 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)
 
*** 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
*** 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
 
* incorporating synonyms into XML - wait on this. method - central dictionary or per license basis? Added to action plan as was not listed there before

Revision as of 19:50, 16 February 2017

Attendees

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

Agenda (morning legal team meeting)

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.

  • 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' '
  • 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?