THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx
Legal Team/Minutes/2016-09-15
From SPDX Wiki
== Attendees
- Jilayne Lovejoy
- Sam Ellis
- Gary O’Neall
- Brad Edmondson
- Alan Tse
- Paul Madick
== Agenda
Last call, Alan had made an attempt to revise the Matching Guidelines, which raised question as to where to put the description of the XML tags as well as other topics that need tech and legal team input. We discussed a variety of these (some of discussion capture below and final “action items” capture on updated list here:
- Sam brought up README on Github page - need info on contributions there and how to use the files - could put description of XML tags on Github
- Alan: probably should be appendix of actual spec, but also good to have it on Github
What is scope of first release - Is it a spec or is it internal to legal team?
- Kris thought: first release to include XML that people could use, but could stage it
- Gary: if we want to stage it, then want to be sure that people know names/tags are not stable (not consistent with spec or conflict). Kris’ goal was that once review was complete, then deal with this (updating tags). OK, but can we try to do this for first release?
- maybe shouldn’t release XML as a “product” to general consumers - maybe use it internally in a branch to generate the stuff that we do release — take XML and produce everything from that and that’s what other people consume. Later, make XML the official release (staged approach)
- appendix (current) for markup will need to be updated - e.g., var v. alt - debate on that
- does this mean we queue off of spec 2.2 release? Gary says no, can do first release to use internally
with understanding that tags might change
- Kris suggested - release same files we have been releasing (but use XML files to build it, XML files stay in a private branch
- Gary said we have this “problem” today in that people were using spreadsheet as THE source of record, so he updated the README on Github to say this is internal - so could use an in between approach and say, “this XML format is intended for internal use for producing the SPDX-LL - if you want a machine-readable format, see JSON, RDF, etc. - almost same as now
- discussed overall goals of switch to XML, twofold
- increase collaboration, this is accomplished without it being a public spec
- improve output of licenses for tools… are people waiting for this? one person that Gary knows of not on call (Sam and Gary may switch anyway)
needed follow-ups / plan forward from this discussion:
- delegate tag name issue to tech team - Gary to take it to tech team. bring back to legal team for final check
- documentation: go with Github documentation (don’t worry about wiki pages, and don’t publish outside of Github until we have final specification)
- update to 2 stages on action plan