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.

other thoughts (that are not urgent, need to be dealt with for 3.1):

• should we test for broken URLs as part of 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 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 (may not want to dictate one over the other?)

Process for reviewing issues and PRs:

• plan to change who can merge directly. we had more people on the XML repo at first, to get through initial review. (not that we don't trust people, but have too many right now and some of those people aren't actively contributing at this point in time.) JL to sort out, may need advice from more Github-savvy folks!
• identify process of who’s doing what, etc. - discussed how tech team operates for its repos:
  • each repo has main owner - in our case, we really have one and probably need designated reviewers/committers for both technical issues and legal issues, preferably at least 2 of each kind so we don't have logjams (or 3)
    • Jilayne, Brad for legal; Gary, and maybe Alexios? (Gary to reach out) - these people would have decision making say, or can boot to calls if more discussion is wanted/needed/desired
  • some PRs may be obvious, minor, don't need discussion - committers can mark for next release milestone and just merge at their discretion (always add milestone, so that is consistent)
  • use calls to go through new PRs on call to decide what release and assign tasks; and then actual work done off call (for PRs)
    • Dennis offered to be assigned to anything content oriented
• use labels for things that need to be discussed, are mostly legal or mostly technical, etc.
• need to write this process up after a bit more feedback - and post where?

went through some of issues open and set milestones, assigned with rest of time on call