THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx

Difference between revisions of "Legal Team/Minutes/2013-08-15"

From SPDX Wiki
Jump to: navigation, search
(Created page with "== Attendees == * Jilayne Lovejoy, OpenLogic * Jack Manbeck, TI * Zak White, Entente * Mark Gisi, Wind River * Tom Incoriva, Micro Focus * Scott Lamons, HP * Paul Madick, HP *...")
 
Line 18: Line 18:
 
** 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 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
 
** 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
+
'''** -->  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.
 
* 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
 
** 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
Line 25: Line 25:
 
** 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
 
** 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
 
** 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)
+
'''** --> 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: http://wiki.spdx.org/view/Legal_Team/Minutes/2013-08-01
+
 
 +
'''2) LinuxCon – we have time for legal face-to-face meeting on Tuesday morning; topics to discuss? (see previous meeting notes: http://wiki.spdx.org/view/Legal_Team/Minutes/2013-08-01'''
 +
* did not have time to discuss; will deal with via email
 +
 
 +
== Actions Items ==
 +
# Zak to update GNU license matching templates as per discussion
 +
# Jilayne to add other BSD templates
 +
# Jilayne to add Scott and Mike D. access to Google Drive folder for matching guideline templates (anyone else missing, email Jilayne)
 +
# Scott to talk to Daniel about license matching guidelines process (checklist for tracking)
 +
# Next meeting items:
 +
## need to have similar discussion re: license preambles - part of license for matching guidelines purposes?
 +
## standard headers issue - where to put the markup for these?  (as well as issue that this info still does not display on website...)

Revision as of 22:50, 20 August 2013

Attendees

  • 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

Agenda

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: http://wiki.spdx.org/view/Legal_Team/Minutes/2013-08-01

  • did not have time to discuss; will deal with via email

Actions Items

  1. Zak to update GNU license matching templates as per discussion
  2. Jilayne to add other BSD templates
  3. Jilayne to add Scott and Mike D. access to Google Drive folder for matching guideline templates (anyone else missing, email Jilayne)
  4. Scott to talk to Daniel about license matching guidelines process (checklist for tracking)
  5. Next meeting items:
    1. need to have similar discussion re: license preambles - part of license for matching guidelines purposes?
    2. standard headers issue - where to put the markup for these? (as well as issue that this info still does not display on website...)