Legal Team/Minutes/2012-06-13 - Revision history

MartinMichlmayr: Convert to MediaWiki syntax

2013-03-05T18:10:56Z

Convert to MediaWiki syntax

Jlovejoy at 17:02, 13 June 2012

2012-06-13T17:02:57Z

New page

Attendees:
<ul>
<li>Jilayne Lovejoy, OpenLogic </li>
<li>Kate Stewart, Canonical </li>
<li>Peter Williams, OpenLogic </li>
<li>Adam Cohn, Cisco </li>
<li>Paul Madick, HP </li>
<li>Karen Copenhaver, Linux Foundation </li>
<li>Scott Lamons, HP </li>
<li>Phil Odence, Black Duck</li>
<li>Jason Buttara, Cisco</li>
</ul>

AGENDA:

1) update on website revise from Mark - Mark not on call, but sent update to Jilayne. TBD

2) quick update on to-do list (see: http://spdx.org/wiki/legal-team-current-issues-last-updated-june-11
<ul>
<li>item #1 completed, will be removed</li>
<li>under item #2 - note license list field guidelines have been updates, legal team please review</li>
<li>OSI list updated and email sent - should have gone to legal list too, but not sure it did, Jilayne to check and resend if necessary (and add additional issue re: zlib/libpng license(s)</li>
<li>Paul still working on going through FSF list; may be some to add, but will need to discuss on legal call; not going to make this for v1.16</li>
<li>version 1.16 of license list to be uploaded and published by 6/20 for inclusion in Spec 1.1</li>
</ul>

3) license matching guidelines
 Please see http://spdx.org/wiki/spdx-license-list-match-guidelines for reference.
Items outstanding:

A) License Headers – see current description of purpose which contains reference to "non-standard" headers
 PROPOSAL: change to: "To identify standard headers that are used to indicate a particular license and provide a match in the License-Info-in-File field. Standard license headers are defined by the SPDX License List as specific text specified within the license itself to be put in the header of files (see http://spdx.org/wiki/spdx-license-list for more info.) The same matching guidelines (white space, punctuation, etc.) used here for license text apply here as well."
<ul>
<li>overall agreement on above proposal (!)</li>
<li>apply same guidelines - put this in section 8.1.1</li>
<li>should we check standard headers for anything in [brackets] - is it anything other than a copyright info in the brackets that can be ignored? easier to indicate where to ignore specifically for each header where this would apply, as opposed to a general guideline</li>
<li>looked at a couple examples of standard headers, which currently include text such as "Exhibit A" or notes on how to apply the header - agreed this text should be removed from the standard header field, such that this field only includes the actual header itself --> JL to make first pass on this and Karen to do a review and check text against license itself (also need to update field guidelines with this info)</li>
</ul>

B) Verbatim Text – we need to identify what can be ignored in BSD and Apache 1.1 licenses. (any others?) There essentially two potential ways to do this:
<ol>
<li> create a "guideline" describing what can be ignored. For example, "In clause three of the BSD-3-clause license, for matching purposes, ignore any actual name of the copyright holder or owner." or "In clause three of the Apache 1.1 license, ignore the text within quotation marks having to do with the acknowledgement statement."
 - could this simply be summarized as "ignore any name within license text" or something along those lines and let tool makers figure out the specifics? Versus license-by-license list of guidelines.
<ul>
<li>probably too general - not enough guidance for tool makers and risks being open for interpretation</li> </ul></li>

<li>create templates with indicated text to ignore (so, more precise than explanations as in previous suggestion), See attached file for examples.
<ul>
<li>demarcate any bit to be ignored or able to replaceable with double curly brackets - {{ }} these are not often used in text, so unlikely to run into this.</li>
<li>then question is where to record this? in license text and standard header fields or create separate field/list? - vote to do it inline with fields as is (like OSI sort of does) as less redundant and provides ability to see in human-readable form</li>
<li>this means someone needs to make a pass on all licenses and standard headers. will also need to add this to process of adding licenses to license list. if we don't look through entire list, make process to review after the fact - go with the ones we know right now and scrub later for feedback (BSDs, Apache 1.1) - Jilayne to make first pass
on this and on standard headers (since already looking at those as per above</li></ol>

C) full review of entire guidelines by legal team and technical team in tandem (special meeting?) Revise or edit as needed for clarification. process going forward, other issues?
<ul>
<li>update matching guidelines as per today's call</li>
<li>outstanding issues include: redux on Copyright Notice guideline; go through comments already posted on bottom of page</li>
<li>send update to Phil for distribution to general list (and Jilayne to send to Legal list) and give people until 6/20 to post any more comments</li>
<li>have special call to tackle all outstanding issues/comments on Thursday, 6/21 at 10amPT/12 ET (right after SPDX biz call) - this we we still have 6/27 legal call for overflow (goal to have matching guidelines first version done by 6/30</li>
</ul>

@@ Line 1: / Line 1: @@
-Attendees:
+== Attendees ==
-<ul>
-<li>Jilayne Lovejoy, OpenLogic </li>
-<li>Kate Stewart, Canonical </li>
-<li>Peter Williams, OpenLogic </li>
-<li>Adam Cohn, Cisco </li>
-<li>Paul Madick, HP </li>
-<li>Karen Copenhaver, Linux Foundation </li>
-<li>Scott Lamons, HP </li>
-<li>Phil Odence, Black Duck</li>
-<li>Jason Buttara, Cisco</li>
-</ul>
-<p><strong>AGENDA:</strong></p>
+* Jilayne Lovejoy, OpenLogic
-<p><strong>1) update on website revise from Mark</strong> - Mark not on call, but sent update to Jilayne.  TBD
+== update on website revise from Mark ==
-<p><strong>2) quick update on to-do list</strong> (see: http://spdx.org/wiki/legal-team-current-issues-last-updated-june-11
+Mark not on call, but sent update to Jilayne. TBD
-<ul>
-<li>item #1 completed, will be removed</li>
-<li>under item #2 - note license list field guidelines have been updates, legal team please review</li>
-<li>OSI list updated and email sent - should have gone to legal list too, but not sure it did, Jilayne to check and resend if necessary (and add additional issue re: zlib/libpng license(s)</li>
-<li>Paul still working on going through FSF list; may be some to add, but will need to discuss on legal call; not going to make this for v1.16</li>
-<li>version 1.16 of license list to be uploaded and published by 6/20 for inclusion in Spec 1.1</li>
-</ul>
-<p><strong>3) license matching guidelines</strong>
+== quick update on to-do list ==
-<br>Please see http://spdx.org/wiki/spdx-license-list-match-guidelines for reference.
-<p>Items outstanding:
-<p>A) License Headers – see current description of purpose which contains reference to "non-standard" headers
+see: [[Legal_Team/Current_Projects_and_Issues]]
-<br>PROPOSAL: change to: "To identify standard headers that are used to indicate a particular license and provide a match in the License-Info-in-File field.  Standard license headers are defined by the SPDX License List as specific text specified within the license itself to be put in the header of files (see http://spdx.org/wiki/spdx-license-list for more info.)  The same matching guidelines (white space, punctuation, etc.)  used here for license text apply here as well."</p>
-<ul>
-<li>overall agreement on above proposal (!)</li>
-<li>apply same guidelines - put this in section 8.1.1</li>
-<li>should we check standard headers for anything in [brackets] - is it anything other than a copyright info in the brackets that can be ignored? easier to indicate where to ignore specifically for each header where this would apply, as opposed to a general guideline</li>
-<li>looked at a couple examples of standard headers, which currently include text such as "Exhibit A" or notes on how to apply the header - agreed this text should be removed from the standard header field, such that this field only includes the actual header itself --> JL to make first pass on this and Karen to do a review and check text against license itself (also need to update field guidelines with this info)</li>
-</ul>
-<p>B) Verbatim Text – we need to identify what can be ignored in BSD and Apache 1.1 licenses. (any others?)  There essentially two potential ways to do this:<p>
+* item #1 completed, will be removed
-<ol>
+* under item #2 - note license list field guidelines have been updates, legal team please review
-<li> create a "guideline" describing what can be ignored.  For example, "In clause three of the BSD-3-clause license, for matching purposes, ignore any actual name of the copyright holder or owner." or "In clause three of the Apache 1.1 license, ignore the text within quotation marks having to do with the acknowledgement statement."
+* OSI list updated and email sent - should have gone to legal list too, but not sure it did, Jilayne to check and resend if necessary (and add additional issue re: zlib/libpng license(s)
-<br>- could this simply be summarized as "ignore any name within license text" or something along those lines and let tool makers figure out the specifics?  Versus license-by-license list of guidelines.
+* Paul still working on going through FSF list; may be some to add, but will need to discuss on legal call; not going to make this for v1.16
-  <ul>
+* version 1.16 of license list to be uploaded and published by 6/20 for inclusion in Spec 1.1
-   <li>probably too general - not enough guidance for tool makers and risks being open for interpretation</li>     </ul></li>
-<li>create templates with indicated text to ignore (so, more precise than explanations as in previous suggestion), See attached file for examples.
+== license matching guidelines ==
-  <ul>
-   <li>demarcate any bit to be ignored or able to replaceable with double curly brackets - {{ }} these are not often used in text, so unlikely to run into this.</li>
-  <li>then question is where to record this?  in license text and standard header fields or create separate field/list? - vote to do it inline with fields as is (like OSI sort of does) as less redundant and provides ability to see in human-readable form</li>
-  <li>this means someone needs to make a pass on all licenses and standard headers. will also need to add this to process of adding licenses to license list. if we don't look through entire list, make process to review after the fact - go with the ones we know right now and scrub later for feedback (BSDs, Apache 1.1) - Jilayne to make first pass
-on this and on standard headers (since already looking at those as per above</li></ol>
-<p>C) full review of entire guidelines by legal team and technical team in tandem (special meeting?)  Revise or edit as needed for clarification. process going forward, other issues?
+Please see [[Legal_Team/License_List/License_Matching_Guidelines]] for reference.
-<ul>
-<li>update matching guidelines as per today's call</li>
+Items outstanding:
-<li>outstanding issues include: redux on Copyright Notice guideline; go through comments already posted on bottom of page</li>
-<li>send update to Phil for distribution to general list (and Jilayne to send to Legal list) and give people until 6/20 to post any more comments</li>
+A) License Headers – see current description of purpose which contains reference to "non-standard" headers
-<li>have special call to tackle all outstanding issues/comments on Thursday, 6/21 at 10amPT/12 ET (right after SPDX biz call) - this we we still have 6/27 legal call for overflow (goal to have matching guidelines first version done by 6/30</li>
-</ul>
+PROPOSAL: change to: "To identify standard headers that are used to indicate a particular license and provide a match in the License-Info-in-File field. Standard license headers are defined by the SPDX License List as specific text specified within the license itself to be put in the header of files (see http://spdx.org/wiki/spdx-license-list for more info.) The same matching guidelines (white space, punctuation, etc.) used here for license text apply here as well."