Legal Team/Minutes/2018-01-11

Attendees

• Steve Winslow
• Gary O’Neall
• Jilayne Lovejoy
• Brad Edmondson
• Dennis Clark
• Alan Tse

Agenda

1) 3.0 release - plan to do 3.1 around end of Jan, what should we aim to tidy up?

• LLVM exception - should hear from them soon (JL has been in contact)
• assembly exception that Wayne requested - need to follow-up (JL to follow-up)
• AGPL-1.0-only and AGPL-or-later need to be added
• automated testing and deployment: any time anyone commits anything into repo (whether merged, PR, etc.) a test runs to see if it is valid (e.g.,. missing end tags, or misspelled XML tag) & will run test to run a match against license it is based on. Gary has seen a lot of the latter, this way person submitting can fix it. Typical errors to this end he’s seen are just structural (XML tags) or typos; most of matching errors are due to trying to get too fancy with alt/var tags; some are problems with tools themselves.
  • only change will be that when you add a new license, you need to add text of license in
• there is also an automatic deployment PR - so that when a change is merged, it will automatically updates the license-list-data repo and then when there is a release tagged. (this will be really helpful for Gary!)
  • question as to automatic tagging or review before tagging - do we want some kind of formal review of license-list-data before we way that is complete (there isn’t now)
  • there is also question as to updating website - should that be automated as well? could push to preview site for every commit and then for live site for a tagged release automatically. All agreed that preview push is kind of nice, as we can see things in advance and fix weird formatting issues, but maybe hold off on automatic release for tagged releases for time being. Also consider using release candidates in between and use that for review.

• change settings as to who can merge directly / identify process of who’s doing what
  • for example: tech team goes through PRs on call to decide what release and assign tasks; and then actual work done off call (for PRs). Usually have a couple people for each repo who do the actual merges - for license list repo, we probably want both legal folks and tech folks, maybe two of each: Jilayne, Brad for legal; Gary, and maybe Alexios (Gary to reach out); Dennis offered to be assigned to anything content oriented
  • discuss on call anything content-related
  • always add milestone, even if merge right away

other thoughts:

• should we test for broken URLs to test run? this is not part of test now, could add this later
• we might also add a note in the field list on Overview page - might be worth adding a note that we can’t control external URLs - ok to PR to do so; but need to make sure new link is actually same license and/or use web archive for original link

went through some of issues