Legal Team/Minutes/2018-03-09

Attendees:

• Steve Winslow
• Jack Manbeck
• Yev
• Dennis Clark
• Philippe
• Mark Gisi
• Kate Stewart
• Jilayne Lovejoy
• Aaron Williamson
• Paul Madick (phone)
• Bradlee Edmondson (phone)
• Alan Tse (phone)
• Trevor King (phone)

Agenda

Kate has stickers - she’ll get more printed for next time we are together; if you want one sooner, email her your physical address

Updates to spec and next release planning

• last merges on 2.1.1 are pretty close; Thomas doing last merges then ready. Main change is from Google doc to Github .md file and renders
• Jack wants an extra week to read the whole thing
• have already looked at some changes for 2.2 - aim to do that be end of summer for Vancouver (Open Source Summit North America) and time for announcement) and have a bake-off
• work on spec 3.0 will come after that, probably 2019
• all of these are tagged in Github. rule is if incremental and doesn’t break anything, then .y release; if going to break things, then major release
• can we link to specific version and section and have that be consistent - will change, so will need to update

SPDX License List and it’s related material: better organization to make it easier to find - should this all go into an Appendix in the Spec? How to get people to notice and understand SPDX specification fields that relate to licenses,

SPDX License List “spec” // SPDX License Registry // SPDX License Collateral // Working with the SPDX License List // SPDX License Handling Guide or Rules

• overview inclusion guidance (web)
• license list (web, spec appendix)
• exception list (web, spec appendix)
• expressions (spec appendix)
• matching guidelines (web only) - but referenced in spec appendix
• reference to sections of spec that are relevant (spec proper)
• request a new license instruction (web and Github)
• how do apply short identifiers in source files (spec appendix only)

implementation:

• Appendix 1 of spec(and one-pager on website) would have summary of above and links
• each of items in list above would be own web page… (generated from file in Github account)
• would we also want to generate out a .pdf of the entire thing together
• put new .md file here: https://github.com/spdx/spdx-spec/tree/master/chapters (or a separate folder above?) for the above items related to license list
• for 2.2 release (and might force 3.y of license list

Steve’s license id explanations

• some of this will be helpful for re-do as described above
• Jack to give Steve edit rights on website to update “use SPDX” page. this page is now one long page, sub-divide different sections

Communicating and explaining relationship and versioning for spec, license list, matching guidelines, tools, etc. Where/how to update website to clarify this?

• once we implement SPDX License Lifestyle Suite, this will be easier. Tools have own versioning as it is
• put on Use / Overview page; Jack to take first stab at re-writing with this

Using Github for SPDX: what is our process for different repos, identify improvements, generate or update documentation

• ok as is, each repo has its own contributing page
• main Participate pages on website, needs some updating:
  • main page https://spdx.org/participate
  • each page for sub-groups; Philippe on tech page; Jack on outreach; Jilayne on legal

Adding more licenses to SPDX License List: from the Linux kernel, other licenses

• ~10 licenses for kernel to request to add; Dennis and Philippe to add via Github in next week, discuss on mailing list as needed (in time for 3.1 release
• Steve is doing scanning on LF projects, will also keep eye out for new licenses to add
• reach out to FreeBSD (? Jack)
• add example of how to do LicenseRef for licenses not on SPDX License List
• Sun/Oracle binary licenses and a few from Microsoft - that are not open source, but apply to very common components - versioning issue, not open source, change randomly. would be good to have a write-up on this issue
• is there a limit to add more open source licenses or how long we want the license list to be?
  • need updated tool to match if it gets much longer
  • may want to make sure Github process works before we open flood gates, getting used to new model first
  • what about stuff not used much?
  • if it can be easily identified, add it - that’s what list is for
• agreed on timeline/approach:
  • work on 3.1 additional licenses as noted
  • documentation/example on how to use LicenseRef - easier when using SPDX doc, but hard to use when using outside of that. want to encourage use of SPDX identifiers
  • focus on web matching tool (and using Github for new license more easily)
  • tool to generate XML (original tool that Kris wrote, won’t work) - long term plan to have this; maybe web-based where fill in boxes? (talk to Gary and Trevor on where we are at with this, who can help from tech team)
  • then can add more licenses, prioritize open source - then discuss other options (again)

• SPDX “relaxed” - some people are providing SPDX documents that lack some of mandatory fields, thus are not SPDX compliant, but this is still useful info. Should we have a “relaxed” option or some kind of grading for SPDX documents to encourage more use?
  • don’t really have quorum for this discussion
  • discussed where this is coming from
  • Yev suggested that any mandatory field that allows NOASSERTION could be optional
  • Philippe has example of documents with useful info tracking on SPDX but not mandatory fields
• action: do comparison of Philippe’s example, Yev’s suggestion against mandatory list - https://spdx.org/sites/cpstandard/files/pages/files/spdx_onepager.pdf
• consider publishing examples