THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx
Difference between revisions of "Legal Team/Minutes/2018-06-14"
From SPDX Wiki
< Legal Team | Minutes
(Created page with "== Attendees == * Dennis Clark * Steve Winslow * Mark Atwood * Brad Edmondson * Alexios Zavras * Paul Madick * Kate Stewart * Gary O’Neall == Agenda == Update from last cal...") |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 22: | Line 22: | ||
* next license list release (3.2) is pending for end of June; 3.3 would be end of Sept - Revisit in early Aug so we can make sure license list release planned for Sept/v3.3 corresponds with timing of v2.2 of spec. | * next license list release (3.2) is pending for end of June; 3.3 would be end of Sept - Revisit in early Aug so we can make sure license list release planned for Sept/v3.3 corresponds with timing of v2.2 of spec. | ||
| − | + | 4) GSoC update from Gary: going well, went through first evaluation period, all students passed. | |
* Good design on license submittal project, now need to get coding. | * Good design on license submittal project, now need to get coding. | ||
* There’s a prototype soon to be available for license XML editor, watch for link and Gary asked legal team to try it out and provide feedback. | * There’s a prototype soon to be available for license XML editor, watch for link and Gary asked legal team to try it out and provide feedback. | ||
| − | + | 5) Next release of license list for v3.2 - go over issues: | |
* reviewed and merged PRs: 644, 650 | * reviewed and merged PRs: 644, 650 | ||
* PR 651 - proposal to add info about case-insensitive identifiers: over-arching value here is something we've had since very beginning: make sure identifiers are unique. The additional aspect of case-sensitive is a detail of that broader theme. This info does not belong in the README but should be added to Overview page in section on short identifiers, (add comment, close PR) | * PR 651 - proposal to add info about case-insensitive identifiers: over-arching value here is something we've had since very beginning: make sure identifiers are unique. The additional aspect of case-sensitive is a detail of that broader theme. This info does not belong in the README but should be added to Overview page in section on short identifiers, (add comment, close PR) | ||
** JL to draft additional bullet and float that by group via email before updating webpage | ** JL to draft additional bullet and float that by group via email before updating webpage | ||
** ACII characters only, (also discussed UTF-8 - but that is broader scope than just identifiers) | ** ACII characters only, (also discussed UTF-8 - but that is broader scope than just identifiers) | ||
| − | * other PRs with 3.2 milestone to be sorted out and merged in next week/ by Monday, June 25th, so Gary can push new version of license list by Friday June 29th. Same for Issues, or move to 3.3 if can't be resolved without additional input. | + | * other PRs with 3.2 milestone to be sorted out and merged in next week/ by Monday, June 25th, so Gary can push new version of license list by Friday June 29th. Same for Issues, or move to 3.3 if can't be resolved without additional input. please be sure to assign any you are looking at so we don't overlap. |
Latest revision as of 18:29, 14 June 2018
Attendees
- Dennis Clark
- Steve Winslow
- Mark Atwood
- Brad Edmondson
- Alexios Zavras
- Paul Madick
- Kate Stewart
- Gary O’Neall
Agenda
Update from last call: smaller group, went over outstanding items in Issues/PRs - closed a few.
1) question re: upgrade spec license from CC-BY-3.0 to 4.0? (Issue 3 in spdx-spec)
- CC-BY-3.0 doesn’t have auto-upgrade / or-later clause, so in order to change to 4.0, would have to get everyone’s permission
- came up on tech call as something to look at, but didn’t seem to have a pressing need or compelling reason to change
- JL will note discussion in Issue and close
2) Issue 648 re: license for licenses - This was already addressed on the mailing list and answered by several lawyers. This has been asked before. (note about legal answers not being satisfying to engineers - but it's still an answer!). Paul to write up reason why we don't need this with help/review from Steve and Brad. We’ll post on wiki in “decisions” section (similar to what we did in past for repeating question as to why we don't have an identifier for "public domain")
3) From tech team: License List in appendix of Spec - will continue to do so for spec v2.2 and split out for 3.0. Want to make sure to have most recent version for v2.2 , which is aimed to be released Sept/Oct
- next license list release (3.2) is pending for end of June; 3.3 would be end of Sept - Revisit in early Aug so we can make sure license list release planned for Sept/v3.3 corresponds with timing of v2.2 of spec.
4) GSoC update from Gary: going well, went through first evaluation period, all students passed.
- Good design on license submittal project, now need to get coding.
- There’s a prototype soon to be available for license XML editor, watch for link and Gary asked legal team to try it out and provide feedback.
5) Next release of license list for v3.2 - go over issues:
- reviewed and merged PRs: 644, 650
- PR 651 - proposal to add info about case-insensitive identifiers: over-arching value here is something we've had since very beginning: make sure identifiers are unique. The additional aspect of case-sensitive is a detail of that broader theme. This info does not belong in the README but should be added to Overview page in section on short identifiers, (add comment, close PR)
- JL to draft additional bullet and float that by group via email before updating webpage
- ACII characters only, (also discussed UTF-8 - but that is broader scope than just identifiers)
- other PRs with 3.2 milestone to be sorted out and merged in next week/ by Monday, June 25th, so Gary can push new version of license list by Friday June 29th. Same for Issues, or move to 3.3 if can't be resolved without additional input. please be sure to assign any you are looking at so we don't overlap.
