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

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 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 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, do not display
    • 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

• 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? - 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? - would be a v2.2 release of spec