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

Legal Team/Minutes/2018-03-09

From SPDX Wiki
Jump to: navigation, search

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:

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
Retrieved from "https://wiki.spdx.org/index.php?title=Legal_Team/Minutes/2018-03-09&oldid=4554"