THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx
Difference between revisions of "Legal Team/Minutes/2015-08-06"
From SPDX Wiki
< Legal Team | Minutes
Line 1: | Line 1: | ||
− | + | == ATTENDEES == | |
* Dennis Clark | * Dennis Clark | ||
Line 9: | Line 9: | ||
* Kate Stewart | * Kate Stewart | ||
− | + | == AGENDA == | |
1) update from last week's call from Mark: | 1) update from last week's call from Mark: |
Latest revision as of 04:30, 7 August 2015
ATTENDEES
- Dennis Clark
- Alan Tse
- Ansel Haliburton
- Mark Gisi
- Kris Reeves
- Phil Odence
- Kate Stewart
AGENDA
1) update from last week's call from Mark:
- some of headers probably need templatizing, still need to go over these.
- recommended headers - for those licenses that don't have a standard header, should we recommend one? this was discussed, generally thought this was a good idea. Mark has tasks on how to proceed
2) Kris had raised request via tech list regarding markup on licenses and matching rules and joined to discuss some issues
- matching guidelines that are programmatically difficult to implement, wanted to be able to make suggestions
- global review or make small improvements
- examples: ISC License - now default license for NPM, has reference to ISC in text (needs markup); one link broken on SPDX list and one goes to link with slightly different text (generic v. specific to ISC)
- Apache exhibit - can we exclude? Guideline says you can lop off end stuff, but that may not be easy to implement and in some cases, there could be extra terms in an exhibit
- markup in there helpful? not so much, format not so well-defined; problem parsing it, some tags have start and end tag and some don't, and can often to simply match anything (can't really identify anything more specific than that, but maybe this could be left out in the markup, as it's really just match anything that could be a name or something reasonable. more markup could help, but refined
- Jilayne gave a bit of background on matching guidelines and markup; Gary has already suggested to allow pull requests on Github. everyone
- Kate - also will need a FAQ explaining how to request changes, etc.
- another example: ignore copyright declarations, but found BSD license that had copyright metadata, first line with markup but also copyright clause... (BSD-3-Clause) - the/its/his/her/their/project contributors - need programmer and legal mind ...
- next steps: get pull request set-up, define process (Kris has some suggestions on this)
- * Kate is going to make a Wiki page and then Kris will post his thought there (once that's done, circulate link to both tech and legal list)
- * Jilayne to email Gary back, re: creating pull requests
- * will need to make new web page on how to submit changes and patches; guidelines, etc. - where to have this? page like other pages on Requesting a new license? or Wiki? (link to from Github account). include info on why the change, etc.
3) more discussion of headers: Mark has come up with the following requirements for recommended headers (and items we discussed):
- it's recommended, not required - things that are easy for machines to recognize, "other ways of recognizing this license" suggested, "recognizable headers"
- do no lose information already present
- solution should be as simple as possible, not complicated. no ambiguity. incremental changes from standard conventions.
- allow for multiple recommendations (tool can see that) - when there is nothing standard, favor common ways to make reference
- Mark to send along revised list of requirements
Next call:
- go over standard headers that may need markup