THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx
Technical Team/Minutes/2017-06-27
From SPDX Wiki
June 27, 2017
Attendees
- Gary O’Neall
- Thomas Steenberg
- Anna Buhman
- Krys Nuvadga
- Alexios Zavras
- Yev Bronshteyn
- Uday Korlimarla
- Kate Stewart
- Aleksandr Lisianoi
- Rohit Lodha
- Philippe Ombredanne
GSoC Updates
- Rohit – online tools
- Verification complete
- Conversion tools nearly complete
- Would like to improve the Java tools to report line numbers for more validation errors
- May complete the work before end of August and would like to contribute to the Java tools if complete early
- Alex
- Transpiling to JavaScript
- Working on the Boolean expressions to support license expressions
- Would like to produce NPM package
- Krys
- License scoring project
- Able to get information from spec
- Target working prototype by start of next week
- Detailed information in the repo
- Using the DJango framework
- Philippe suggested getting the code working outside the framework first, then add a web framework
- Philippe suggested having more SPDX examples
- Anna
- Github SPDX integration – scans automatically
- Working on pull request approach to put SPDX document back into Repository
- Philippe suggested having a github user for the server to create the pull requests
- Gary suggested making that user configurable
- This could also help with private repositories where the user configured could have access – but we agreed that private repos would not be in scope for this week
Update on Spec Repository
- Thomas is working on OpenChain as well
- Travis CI is still failing – Thomas is working on the last bug
- Intent is to build all types of documents automatically (HTML, PDF, etc.)
- Problem has to do with permissions
Next SPDX Specification
- Discussed Yev’s proposal for more concise representation of relationships
- Agreed to pursue approach
- Yev will provide definitions (added to end of google docs)
- Discussed alternative package alias proposal from Thomas – Agreed this is useful
- Discussed whether to just change the cardinality of name to be multiple
- Agreed on the additional name approach rather than changing the cardinality
- Discussed alternateName or packageAlternateName – tag/value would be packageAlternateName, RDF would be alternateName
- Discussed if we still need to require packageName if alternateName is provided – agreed to require packageName for compatibility reasons
- Does alternatative name apply to other SPDX element?
- Could be useful for license names – follow-up with legal team
- Snippet names – not useful
- Document names – not useful
- File names – could be useful, but a different semantic and would be treated differently
