THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx
Difference between revisions of "Legal Team/Minutes/2019-07-11"
From SPDX Wiki
< Legal Team | Minutes
(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 ==...") |
|||
| Line 10: | Line 10: | ||
* Paul Madick | * Paul Madick | ||
* Steve Winslow | * Steve Winslow | ||
| − | |||
== Agenda == | == Agenda == | ||
| − | |||
1) Joint tech/legal team calls: | 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 | * 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 | * 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 | ||
| − | + | 2) “SPDX-Copyright:” tag – suggestion from REUSE folks and discussion in Github issue here: | |
https://github.com/spdx/spdx-spec/issues/122 | 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 | + | * 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: | 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. | * 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) | * 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 | * 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 | |
| − | + | ** 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 | |
| − | + | ** 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 | |
| − | + | ** Looking at e.g. “SPDX-FileCopyrightText:” - maps on SPDX field, uses "SPDX" to queue relationship and definition in spec | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | Looking at e.g. “SPDX-FileCopyrightText:” | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | SPDX | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | 3) SPDX-License-Identifier: should it be confined to only one line? (not delineated either way currently) | ||
| + | * can possible have more than one line/tag if files are combined, so probably not good to constrain this | ||
| + | * this led to comment about when more than one license, but don't know if it's "and" or "or" - issue raised already for using semicolon as operator to indicate unknown relationship (another topic to discuss on joint call with tech/legal team) | ||
| − | + | 4) 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. | |
Revision as of 03:49, 18 July 2019
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
2) “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 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 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
- 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
- Looking at e.g. “SPDX-FileCopyrightText:” - maps on SPDX field, uses "SPDX" to queue relationship and definition in spec
3) SPDX-License-Identifier: should it be confined to only one line? (not delineated either way currently)
- can possible have more than one line/tag if files are combined, so probably not good to constrain this
- this led to comment about when more than one license, but don't know if it's "and" or "or" - issue raised already for using semicolon as operator to indicate unknown relationship (another topic to discuss on joint call with tech/legal team)
4) 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.
