Difference between revisions of "Legal Team/Minutes/2013-05-23"

Latest revision as of 20:06, 6 June 2013

Attendees:

• Jilayne Lovejoy, OpenLogic
• Gary O'Neall, Source Auditor
• Tom Incorvia, Micro Focus
• Jason Buttura, Cisco
• Karen Copenhaver, LF
• Daniel German, U. of Victoria
• Zac White, Entente
• Jack Manbeck, TI
• Phil Odence, Black Duck
• Paul Madick, HP
• Tom Vidal

Matching Guidelines joint discussion w/Legal and Tech teams

Review Current Proposal

• Review of the proposal on Github from Daniel German – overview, explanation of proposal which uses double-curly brackets (a field) that include multiple attributes, e.g. a name for the item, type (e.g. options or required text), and an example; some (but only a few) regular expression language terms are used for this proposal
  • issue that this proposal it requires two files: one with the markup and one that is "plain" text for the license

Comments, Feedback

• Gary's proposal to add another field which is the text to be used in the standard text output
  • or could re-purpose "example" text in Daniel's proposal
  • could this attribute first in field, for readability; order of attributes does not matter
  • make new attribute called "original" which contains text that was there, it would be required, but can be empty and have that listed first in field
  • more work for anyone doing this to create a new example, so using examples already there - seems more efficient
• we will need to document the fields and attributes and explain what it is, intention, and so forth - should that become part of the spec or an exhibit to the spec? - TBD, Kate not on call
• regular expression is common enough that it will not limit tool-makers/innovation for scanning development
  • SPDX tools will be updated to generate the standard text from the template and also generate a highlighted webpage for the license - thus allowing the license list to be maintained with 1 file per license (instead of two)
  • do people need to have a "plain" text files? can the templated text file be enough (i.e. idea of just having ONE file maintained and everything created from that? yes
  • can we take templates to GitHub (yes, we need to do this anyway)

• what needs to have markup?
  • no question that we need markup for text that is within the license or additional exhibits that do not need to be included for the license to be a match
  • what about titles - is the guideline enough or do we need markup? discussed, decided to not markup titles as a rule and decide further as we go along
  • what about copyright notices (and issue that some copyright notices are for the license itself and some are for the code)? should be marked up

Process for Implementation

• getting into process - what is the variability that we need to implement in current licenses? how to communicate that?
• regular expression language probably too complicated to have legal team take-on. Daniel offered to do this part, but will need guidance from legal team as to what is variable
• use text files and put {{ }} around
• start with most common or problematic licenses first; track what has been reviewed by legal team
• Gary and Daniel to sort out details for repository for getting files to Daniel, storing, access. etc - on GitHub or some such repository that we can all easily access