Legal Team/Minutes/2019-05-30

From SPDX Wiki
< Legal Team‎ | Minutes
Revision as of 18:28, 30 May 2019 by Jlovejoy (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Attendees

  • John Horan
  • Jilayne Lovejoy
  • Mark Atwood
  • Gary O’Neall
  • Steve Winslow
  • Jim Vitrano
  • Brad Edmondson
  • Paul Madick
  • Mike Dolan
  • Umang Taneja (GSoC student)

Agenda

1) GSoC update from Umang who is working on a project to enhance the workflow for online license request. See proposal here: https://docs.google.com/document/d/14WRI0cCVArYukVvc0T3thEW2HZ1fGwxn1Nrv65CCMUg/edit

  • Umang discussed the ideas for the proposal which will check new license submissions against the current SPDX Licensee List. Will also use an API. (see proposal for full description)
  • questions from team: would tool create XML file? what is output from tool if license gets accepted? XML already created in current tool but this will improve that output
  • question about how comparison will use the new license-diff tool? that tool does text match, but still needs someone to look at it, as doesn't use full matching guidelines and gives percentage match, which isn't definitive. the matching mechanism Umang is going to work on will implement the full matching guidelines
  • if finds a full match, proposal states it would pop-up to user and discard the request. discussed if we want a to track this or not. maybe have in the pop-up ask if the requestor wants a new issue or not (that way they don't have to if they would be embarrassed) and then have a label in Github that adds to the issue to note it's a duplicate.
  • if there is a close match, would be good if issue created provides a diff or link to diff so team can see that. maybe also ask requestor if they want to comment on those potential changes
  • could we put visual of diff in Archive Requests section and add a link to the issue that points to the diff there (and license text) or something along those lines
  • for ideas like above - record as issues in online tools repo https://github.com/spdx/spdx-online-tools
  • Mark raised awareness of a tool Amazon has for matching that implements full XML matching rules: https://github.com/amzn/askalono - pulls from SPDX repository. Does matching text and XML but not all matching guidelines. Could be helpful here? (Gary and Umang to review)
  • Gary noted that full implementation of matching guidelines is compute intensive and hard to do but key for this use-case (new license requests)

2) Release cycle description: 2 people asked about this recently. Didn't realize we hadn't published this anywhere so Jilayne added to Contributing doc. Discussed details of timing:

  • if release is to be published on last day of month for quarter
  • 1 week prior: all PRs have been merged that are going to be part of release and no more PRs merged
  • 4 weeks prior: any new issues after this point will likely be tagged for next release, unless it's an easy-to-resolve issue
  • add above to contributing doc

3) Need more feedback on documentation updates - see email sent earlier this week, comment on PRs in Github

  • discussed licenses that aren't squarely open source and variations on how far fall out and how to deal with this potential slippery slope. Some are clearly not open source (use, technology restrictions), then there are licenses intended to be open source, but impose new copyleft-type conditions (SSPL, Parity). We don't want to get into the business of defining what is open source, but we have to make a call on these licenses - how to do this without getting into the middle of the debate?
  • licenses that are project and/or entity-specific are likely not to be added, especially if have other factors that cuts against
  • need to get licesne inclusion guidelines merged and make further updates
  • NOTE: entire next call for discussing any remaining issues for 3.6 release - EVERYONE, PLEASE REVIEW NEW LICENSE REQUESTS AND HELP MOVE THINGS ALONG!!