Legal Team/Minutes/2013-08-15 - Revision history

Jlovejoy at 19:24, 29 August 2013

2013-08-29T19:24:38Z

Jlovejoy at 22:50, 20 August 2013

2013-08-20T22:50:37Z

Jlovejoy: 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 *..."

2013-08-20T22:47:02Z

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 *..."

New page

== 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

← Older revision		Revision as of 19:24, 29 August 2013
Line 39:		Line 39:
	## need to have similar discussion re: license preambles - part of license for matching guidelines purposes?		## 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...)		## standard headers issue - where to put the markup for these? (as well as issue that this info still does not display on website...)
		+
		+	[[Category:Legal\|Minutes]]
		+	[[Category:Minutes]]

@@ 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 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.
 ** 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
 ** 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)'''
 ) 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