THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx
Difference between revisions of "Legal Team/Minutes/2016-01-07"
From SPDX Wiki
< Legal Team | Minutes
(Created page with "Attendees * Jilayne Lovejoy * Sam Ellis * Kris Reeves * Paul Madick * Kate Stewart * Alan Tse * Brad Edmundsen Agenda 1) A discussion came up on the tech team regarding how...") |
|||
Line 1: | Line 1: | ||
− | Attendees | + | == Attendees == |
* Jilayne Lovejoy | * Jilayne Lovejoy | ||
Line 7: | Line 7: | ||
* Kate Stewart | * Kate Stewart | ||
* Alan Tse | * Alan Tse | ||
− | * Brad | + | * Brad Edmondson |
− | Agenda | + | == Agenda == |
1) A discussion came up on the tech team regarding how to identify when there truly is no license and a package is just “all rights reserved” - please read the thread here: https://bugs.linuxfoundation.org/show_bug.cgi?id=1289 including my response at the bottom. | 1) A discussion came up on the tech team regarding how to identify when there truly is no license and a package is just “all rights reserved” - please read the thread here: https://bugs.linuxfoundation.org/show_bug.cgi?id=1289 including my response at the bottom. | ||
− | * issue in Node and NPM - they were looking at specification for node package, has a license field, but may not have room for other info as is done in SPDX specification; looking for what to populate that field with. For more info, see: https://docs.npmjs.com/files/package.json | + | * issue in Node and NPM - they were looking at specification for node package, which has a license field, but may not have room for other info as is done in SPDX specification; looking for what to populate that field with. For more info, see: https://docs.npmjs.com/files/package.json |
* what can we do to help the situation? more than explanation on bugzilla needed? | * what can we do to help the situation? more than explanation on bugzilla needed? | ||
− | * Kris suggested something in the Appendix to clarify use of NONE or NOASSERTION v. license expression or get NPM to modify to support for that use case in NPM nit command | + | * Kris suggested something in the Appendix to clarify use of NONE or NOASSERTION v. license expression and/or get NPM to modify to support for that use case in NPM nit command |
− | * seems also helpful to add clarification to Appendix IV in spec - | + | * seems also helpful to add clarification to Appendix IV in spec - (e.g., NONE as a valid option as license expression) - put as a bug and assign to Kate, will confer with Jilayne and legal team on wording |
− | * NONE makes sense (for Node) to be a valid "license expression" b/c there is no "i don't know" when it's the author declaring the license; NOASSERTION doesn't make sense in this case (unless developer was waiting on legal for approval). | + | * NONE makes sense (for Node) to be a valid "license expression" b/c there is no "i don't know" when it's the author declaring the license; NOASSERTION doesn't make sense in this case (unless developer was waiting on legal for approval). |
− | * also would help to amend node documentation to point this out b/c people coming in there may not be looking at SPDX spec - Kris to open a bug to amend language | + | * also would help to amend node documentation to point this out b/c people coming in there may not be looking at SPDX spec and looks like NPM is now suggesting "unlicensed" - Kris to reach out to them and open a bug to amend language there |
− | + | 2) 2016 priorities list, posted here: http://wiki.spdx.org/view/Legal_Team/Current_Projects_and_Issues-2016 | |
− | 2) | + | * looking for people to take the lead on some of these items (didn't get to on today's call) |
− | + | * Regarding the markup project - as we have earmarked this as a main priority for 2016 and this discussion has been resurrected on the tech call recently | |
− | Regarding the markup project - as we have earmarked this as a main priority for 2016 and this discussion has been resurrected on the tech call recently | + | * See above link for reminder of this issue; we had had a joint call in October and then the tech team was going to kick the tires and schedule another joint call |
− | * | + | * Tech team has earmarked call for Jan 19 for joint discussion; Kate will send invite to legal and tech teams with specific dial-in next week |
− | * | + | |
3) Open Gaming License | 3) Open Gaming License | ||
− | * Alan did some research - license seems to try to cover various aspects, including mechanics of game and things related to brand identity; seems like IP law concepts got a bit muddled in license drafting and perhaps trying to cover things by copyright that aren't really copyright-able. | + | * Alan did some research - license seems to try to cover / differentiate various aspects, including mechanics of game and things related to brand identity; seems like IP law concepts got a bit muddled in license drafting and perhaps trying to cover things by copyright that aren't really copyright-able. Tries to draw a line b/w what can be modified/shared and what can't (this stuff is often bundled together in reality) |
− | * | + | * We do have other "non-software", e.g., documentation licenses (FDL, CC licenses) on list, but they are truly open |
− | * question as to open-ness of license - attempts to allow "open game content" to be open, but limits open license to this and not "product identity" aspects. Kris explained this | + | * question as to open-ness of this license - attempts to allow "open game content" to be open, but limits open license to this and not "product identity" aspects. Kris explained this draws line around rules/mechanical functional part v. settings/universe in games and otherwise tried to educate those of us who are clueless on gaming as to what this license is trying to achieve |
− | * | + | * Brad wondered if the intent of the license was actually to have more items included in "open game content" definition than is articulated |
− | * | + | * How commonly used is this license? Alan thinks it is common within the gaming industry. Kris found that Wizards of the Coast owns (c) of license and uses it; they are big deal and means that it is probably used for their stuff |
− | + | * The license is both open, and very restrictive. how do we balance "open-ness" v. "use"? would wide use and more requests to add tip the balance? We have prioritized open-ness | |
− | + | * Decision: license is not open enough, too many restrictions. Alan to let submitter know | |
− | * Decision: license is not open enough, too many restrictions | + |
Latest revision as of 19:54, 7 January 2016
Attendees
- Jilayne Lovejoy
- Sam Ellis
- Kris Reeves
- Paul Madick
- Kate Stewart
- Alan Tse
- Brad Edmondson
Agenda
1) A discussion came up on the tech team regarding how to identify when there truly is no license and a package is just “all rights reserved” - please read the thread here: https://bugs.linuxfoundation.org/show_bug.cgi?id=1289 including my response at the bottom.
- issue in Node and NPM - they were looking at specification for node package, which has a license field, but may not have room for other info as is done in SPDX specification; looking for what to populate that field with. For more info, see: https://docs.npmjs.com/files/package.json
- what can we do to help the situation? more than explanation on bugzilla needed?
- Kris suggested something in the Appendix to clarify use of NONE or NOASSERTION v. license expression and/or get NPM to modify to support for that use case in NPM nit command
- seems also helpful to add clarification to Appendix IV in spec - (e.g., NONE as a valid option as license expression) - put as a bug and assign to Kate, will confer with Jilayne and legal team on wording
- NONE makes sense (for Node) to be a valid "license expression" b/c there is no "i don't know" when it's the author declaring the license; NOASSERTION doesn't make sense in this case (unless developer was waiting on legal for approval).
- also would help to amend node documentation to point this out b/c people coming in there may not be looking at SPDX spec and looks like NPM is now suggesting "unlicensed" - Kris to reach out to them and open a bug to amend language there
2) 2016 priorities list, posted here: http://wiki.spdx.org/view/Legal_Team/Current_Projects_and_Issues-2016
- looking for people to take the lead on some of these items (didn't get to on today's call)
- Regarding the markup project - as we have earmarked this as a main priority for 2016 and this discussion has been resurrected on the tech call recently
- See above link for reminder of this issue; we had had a joint call in October and then the tech team was going to kick the tires and schedule another joint call
- Tech team has earmarked call for Jan 19 for joint discussion; Kate will send invite to legal and tech teams with specific dial-in next week
3) Open Gaming License
- Alan did some research - license seems to try to cover / differentiate various aspects, including mechanics of game and things related to brand identity; seems like IP law concepts got a bit muddled in license drafting and perhaps trying to cover things by copyright that aren't really copyright-able. Tries to draw a line b/w what can be modified/shared and what can't (this stuff is often bundled together in reality)
- We do have other "non-software", e.g., documentation licenses (FDL, CC licenses) on list, but they are truly open
- question as to open-ness of this license - attempts to allow "open game content" to be open, but limits open license to this and not "product identity" aspects. Kris explained this draws line around rules/mechanical functional part v. settings/universe in games and otherwise tried to educate those of us who are clueless on gaming as to what this license is trying to achieve
- Brad wondered if the intent of the license was actually to have more items included in "open game content" definition than is articulated
- How commonly used is this license? Alan thinks it is common within the gaming industry. Kris found that Wizards of the Coast owns (c) of license and uses it; they are big deal and means that it is probably used for their stuff
- The license is both open, and very restrictive. how do we balance "open-ness" v. "use"? would wide use and more requests to add tip the balance? We have prioritized open-ness
- Decision: license is not open enough, too many restrictions. Alan to let submitter know