THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx
Technical Team/Minutes/2017-05-15
From SPDX Wiki
< Technical Team | Minutes
May 15, 2017
Contents
Attendees
- Gary O’Neall
- Sai Uday Shankar
- Thomas Steenberg
- Kate Stewart
- Anna Buhman
- Yev Bronshteyn
SPDX specification to github
- Philippe gave Thomas access to repository
- Thomas still moving over, Appendix 1. Base content is there. see:
- Basic markdown is present. will work on Readme & contribution MD before pushing live.
- Improve rendering in .pdf in progress - works on mac. Willl send announcement to mail list as soon as pushed
GSoC Coordination
- Gary: online validation tools overlap concern, Kate clarified – only the titles are the same
- Uday: how will someone use a resource to get started?
- Gary - mirroring same AWS instance from OpenChain, and make it available for students to use. $35/month to host. Same account and create an instance. Work out accounting.
- Approval from OpenChain group to use their instance for additional work. Set up right credentials and access. Elastic beanstalk. Push from development to production cleanly.
- Need a redirect subdomain mapping for AWS. Do this during bonding period. Will start creating github repositories - github.com/spdx/
- Gary will set up repositories in SPDX github account - just needs to know name of repository and github id. (Kate to send in for Krys).
Github cleanup
- Some of the repos were contributed by other companies. (airs, osip) - would like their permission to rename/relocate
- Some created by core team but should be removed. (gitolite admin, spdx-rdf-vocabulary)
- Thomas & Gary to research best practice for dealing with older repositories, pinning them, deprecated, other solution
Next SPDX Spec
- See https://docs.google.com/document/d/1vJqWGU02ynzrJ5CvmX1z2mBssOSpuBvuKene8jVJGNI/edit
- relationships in license
- Agree this is a good proposal
- Gary will take to legal for discussion
- Result an appendix
- Dependency version range
- A solution to the problem when licenses may not be determinable at build time due to version range rather than specific version
- Agree this is a good problem to solve
- Size of File optional
- Some concern on additional fields being added to the spec, but it is optional
- Agree this is OK to add
- Discussion on Limited information for some file contents of package, but not requiring all the files of the license
- Can we use filesAnalyzed=false?
- Doesn’t solve all the use cases
- Discussion on views as being a solution
- Discussion on whether this is a standard, tool, or best practices
- SPARQL can be provided for views
- Is this reducing the minimum to allow smaller documents
- Can we use filesAnalyzed=false?