Legal Team/Minutes/2013-08-15

From SPDX Wiki
< Legal Team‎ | Minutes
Revision as of 22:47, 20 August 2013 by Jlovejoy (Talk | contribs)

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


  • Jilayne Lovejoy, OpenLogic
  • Jack Manbeck, TI
  • Zak White, Entente
  • Mark Gisi, Wind River
  • Tom Incoriva, Micro Focus
  • Scott Lamons, HP
  • Paul Madick, HP
  • Mike Dolan, Linux Foundation
  • Michael Herzog, NexB


1) License Matching Guidelines: status update, go over any questions for new templates

  • Jilayne added checklist to the Google Drive folder to keep track of status for each license: i.e. done and ready for Daniel or reviewed and does not need a template
  • Scott will communicate with Daniel about this part of the process
  • discussion regarding questions from review of GNU licenses
    • how much detail do we want the mark-up to go into? e.g. anything that *could* be omitted or replaced or only common words/phrases that are omitted or replaced?
    • we don't want to make a call or interpretation; need to stick with original mandate that we are not doing legal analysis - "just the facts, ma'am." if we start marking up beyond issues/replaceable text we know to exist in the wild, we are heading down a slippery slope towards making interpretations of the license text itself
    • we have the general guideline that licenses must be an exact match, let's stick with this guiding principle and only accommodate obvious and non-substantive differences
    • --> Zak to update templates according to conversation
  • What about items at end of the license, beyond "end of license terms" type of language; instructions on how to apply the license, etc.
    • if the license says "end of license" and there is additional text after that point, isn't this obvious enough? Do we really need to markup this up or is an additional guideline explaining this enough for toolmakers
    • discussion regarding pros and cons of specific guidance in the form of explicit markup in a template that weighs more towards rules (less room for interpretation, most consistent outcome among users and tool makers) v. a guideline describing the matching parameters (allows flexibility for implementation, we can always add more explicit guidance later, but hard to go in the other direction)
    • more discussion on "guidelines" versus "rules" (matching guidelines are just that right now)
    • possibility of some kind of certification of tools compliance down the road - good to keep in mind, but not there yet. by having a guideline, always allows option to be more specific later as certification process develops
    • perhaps a guideline but then can also have examples of license for illustrative purposes
    • --> Jilayne to draft new guideline for review on next call (or via email ahead of next call, if timing allows)

2) LinuxCon – we have time for legal face-to-face meeting on Tuesday morning; topics to discuss? (see previous meeting notes: