Legal Team/Minutes/2019-07-11 - Revision history

Jlovejoy at 03:50, 18 July 2019

2019-07-18T03:50:18Z

Jlovejoy at 03:49, 18 July 2019

2019-07-18T03:49:58Z

Jlovejoy: Created page with "== Attendees == * Alexios Zavras * Brad Edmondson * Gary O’Neall * Jilayne Lovejoy * John Horan * Kate Stewart * Mark Atwood * Mike Dolan * Paul Madick * Steve Winslow ==..."

2019-07-18T03:34:11Z

Created page with "== Attendees == * Alexios Zavras * Brad Edmondson * Gary O’Neall * Jilayne Lovejoy * John Horan * Kate Stewart * Mark Atwood * Mike Dolan * Paul Madick * Steve Winslow ==..."

New page

== Attendees ==
* Alexios Zavras
* Brad Edmondson
* Gary O’Neall
* Jilayne Lovejoy
* John Horan
* Kate Stewart
* Mark Atwood
* Mike Dolan
* Paul Madick
* Steve Winslow

== Agenda ==

1) Joint tech/legal team calls:
* Given the increase in cross-functional tech team/legal team topics coming up, it was suggested on the general call was right before legal call to have a standing joint tech & legal team call at a regular interval. This would avoid having to schedule something separate
* Since the tech team already meets every week, it was decided to do this for the third Tuesday tech team call every month. Dial info and time here: https://wiki.spdx.org/view/Technical_Team
* Recurring invite will be sent to the legal team
* If issues in tech call that legal team might not be aware of, tag in spec as “legal team review” and discuss in joint call

3) “SPDX-Copyright:” tag – suggestion from REUSE folks and discussion in Github issue here:
https://github.com/spdx/spdx-spec/issues/122
* REUSE requested it in SPDX because SPDX is a specification (whereas they are producing guidance documentation). If this was added to the SPDX specificaiton, it would be in the form of an appendix, which would explain the use-case and parameters, similar to how SPDX-LicenseIdentifier has its own appendix (see: https://github.com/spdx/spdx-spec/blob/master/chapters/appendix-V-using-SPDX-short-identifiers-in-source-files.md )
highlights of discussion on call:
* must make sure it’s not perceived as SPDX giving legal advice in the sense of recommending use of a copyright notice when most Berne jurisdictions don’t require it - the challenges of tooling being able to do this accurately has long been a known difficulty.
* goal of having this is if people are going to use a copyright, it provides a tag that makes finding the copyright notice easier/helps tooling (and extract, if needed for license compliance)
* consider two sides of colon in the tag - the name of the tag to the left of the colon and what goes on the left side of the colon. SPDX should not recommend or prescribe any format for the right side of the colon
• Discussed possible name of tag for left side:

Discussed various options and pros and cons, but key point that came to some consensus was that if this is tied to spec, it should be consistent with what is used in the spec. In this case, setion 4.8 of the spec defines the field for copyright text and uses “FileCopyrightText:” for the SPDX tag value, so would make sense to be consistent
– see: https://github.com/spdx/spdx-spec/blob/master/chapters/4-file-information.md#48-copyright-text-
o People have asked about using other fields from SPDX spec in source files, so if we defined a way to do so, then would answer that question and give people a path if they found other SPDX specification fields useful to be used in this way or elsewhere
o pros and cons of “SPDX” being part of the tag
• SPDX-License-Identifier: remains as an outlier b/c doesn’t map to corresponding tag
o
•

name of field could be confusing

Looking at e.g. “SPDX-FileCopyrightText:” or

left side of colon: looking at SPDX-FileCopyrightText:

forward-looking for adding other tags
SPDX-License-Identifier: remains as an outlier b/c doesn’t map to corresponding tag
Discussed SPDX spec fields for file copyright text, file notice and/or other attribution notices

5) Ad hoc request – how to tag this type of info from SPDX docs in source files? Should SPDX have recommendations?

6) SPDX-License-Identifier: should there be only one line?
Something that is composing / concatenating multiple source files could end up grabbing multiple versions of these
Issue for this already, along with semicolon operator => discuss on joint call

8) Collaboration with OSI, conversations between Jilayne and Pam Chestek – looking at OSI licenses list and differences with latest SPDX license list, using IDs consistently across lists, etc.

@@ Line 25: / Line 25: @@
 * goal of having this is if people are going to use a copyright, it provides a tag that makes finding the copyright notice easier/helps tooling (and extract, if needed for license compliance)
 * consider two sides of colon in the tag - the name of the tag to the left of the colon and what goes on the left side of the colon. SPDX should not recommend or prescribe any format for the right side of the colon
-• Discussed possible name of tag for left side: discussed various options and pros and cons, but key point that came to some consensus was that if this is tied to spec, it should be consistent with what is used in the spec. In this case, section 4.8 of the spec defines the field for copyright text and uses “FileCopyrightText:” for the SPDX tag value, so would make sense to be consistent, see: https://github.com/spdx/spdx-spec/blob/master/chapters/4-file-information.md#48-copyright-text-
+* Discussed possible name of tag for left side: discussed various options and pros and cons, but key point that came to some consensus was that if this is tied to spec, it should be consistent with what is used in the spec. In this case, section 4.8 of the spec defines the field for copyright text and uses “FileCopyrightText:” for the SPDX tag value, so would make sense to be consistent, see: https://github.com/spdx/spdx-spec/blob/master/chapters/4-file-information.md#48-copyright-text-
 ** People have asked about using other fields from SPDX spec in source files, so if we defined a way to do so, then would answer that question and give people a path if they found other SPDX specification fields useful to be used in this way or elsewhere, perhaps in one appendix
 ** noted that SPDX-License-Identifier: remains as an outlier b/c doesn’t map to corresponding tag, nature of the use and how it evolved, so it will be its own appendix

@@ Line 10: / Line 10: @@
 * Paul Madick
 * Steve Winslow
 == Agenda ==
 ) Joint tech/legal team calls:
 * Given the increase in cross-functional tech team/legal team topics coming up, it was suggested on the general call was right before legal call to have a standing joint tech & legal team call at a regular interval. This would avoid having to schedule something separate
@@ Line 20: / Line 18: @@
 * If issues in tech call that legal team might not be aware of, tag in spec as “legal team review” and discuss in joint call
 ) “SPDX-Copyright:” tag – suggestion from REUSE folks and discussion in Github issue here:
 https://github.com/spdx/spdx-spec/issues/122
-* REUSE requested it in SPDX because SPDX is a specification (whereas they are producing guidance documentation). If this was added to the SPDX specificaiton, it would be in the form of an appendix, which would explain the use-case and parameters, similar to how SPDX-LicenseIdentifier has its own appendix (see: https://github.com/spdx/spdx-spec/blob/master/chapters/appendix-V-using-SPDX-short-identifiers-in-source-files.md )
+* REUSE requested it in SPDX because SPDX is a specification (whereas they are producing guidance documentation). If this was added to the SPDX specification, it would be in the form of an appendix, which would explain the use-case and parameters, similar to how the SPDX-LicenseIdentifier has its own appendix (see: https://github.com/spdx/spdx-spec/blob/master/chapters/appendix-V-using-SPDX-short-identifiers-in-source-files.md )
 highlights of discussion on call:
 * must make sure it’s not perceived as SPDX giving legal advice in the sense of recommending use of a copyright notice when most Berne jurisdictions don’t require it - the challenges of tooling being able to do this accurately has long been a known difficulty.
 * goal of having this is if people are going to use a copyright, it provides a tag that makes finding the copyright notice easier/helps tooling (and extract, if needed for license compliance)
 * consider two sides of colon in the tag - the name of the tag to the left of the colon and what goes on the left side of the colon. SPDX should not recommend or prescribe any format for the right side of the colon
-• Discussed possible name of tag for left side:
+• Discussed possible name of tag for left side: discussed various options and pros and cons, but key point that came to some consensus was that if this is tied to spec, it should be consistent with what is used in the spec. In this case, section 4.8 of the spec defines the field for copyright text and uses “FileCopyrightText:” for the SPDX tag value, so would make sense to be consistent, see: https://github.com/spdx/spdx-spec/blob/master/chapters/4-file-information.md#48-copyright-text-
+** People have asked about using other fields from SPDX spec in source files, so if we defined a way to do so, then would answer that question and give people a path if they found other SPDX specification fields useful to be used in this way or elsewhere, perhaps in one appendix
-Discussed various options and pros and cons, but key point that came to some consensus was that if this is tied to spec, it should be consistent with what is used in the spec. In this case, setion 4.8 of the spec defines the field for copyright text and uses “FileCopyrightText:” for the SPDX tag value, so would make sense to be consistent
+** noted that SPDX-License-Identifier: remains as an outlier b/c doesn’t map to corresponding tag, nature of the use and how it evolved, so it will be its own appendix
- – see: https://github.com/spdx/spdx-spec/blob/master/chapters/4-file-information.md#48-copyright-text-
+** pros and cons of “SPDX” being part of the tag - could be confusing (it's not the copyright for SPDX...) but also queues as to where it is defined; will need to be clear on description in appendix
-o	People have asked about using other fields from SPDX spec in source files, so if we defined a way to do so, then would answer that question and give people a path if they found other SPDX specification fields useful to be used in this way or elsewhere
+** Looking at e.g. “SPDX-FileCopyrightText:” - maps on SPDX field, uses "SPDX" to queue relationship and definition in spec
-o	pros and cons of “SPDX” being part of the tag
-•	SPDX-License-Identifier: remains as an outlier b/c doesn’t map to corresponding tag
-−
-•
-−
-name of field could be confusing
-−
-Looking at e.g. “SPDX-FileCopyrightText:” or
-−
-left side of colon: looking at SPDX-FileCopyrightText:
-−
-forward-looking for adding other tags
-SPDX-License-Identifier: remains as an outlier b/c doesn’t map to corresponding tag
-Discussed SPDX spec fields for file copyright text, file notice and/or other attribution notices
-−
-−
-) Ad hoc request – how to tag this type of info from SPDX docs in source files? Should SPDX have recommendations?
-−
-) SPDX-License-Identifier: should there be only one line?
-Something that is composing / concatenating multiple source files could end up grabbing multiple versions of these
-Issue for this already, along with semicolon operator => discuss on joint call
-−
-) Collaboration with OSI, conversations between Jilayne and Pam Chestek – looking at OSI licenses list and differences with latest SPDX license list, using IDs consistently across lists, etc.
+) Collaboration with OSI:  Jilayne and Pam Chestek had a good chat and identified some items that need to be fixed/updated to align SPDX and OSI licenses, issues logged in SPDX where applicable and Jilayne sent email to OSI board with summary and suggestions. Aim to work on areas of potential collaboration going forward.