THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx

Technical Team/Minutes/2017-05-23

From SPDX Wiki
< Technical Team‎ | Minutes
Revision as of 18:12, 23 May 2017 by Goneall (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

May 23, 2017

Attendees

  • Gary O’Neall
  • Sai Uday Shankar
  • Thomas Steenberg
  • Kate Stewart
  • Anna Buhman
  • Yev Bronshteyn
  • Alexios Zavras
  • Bill Schineller

License consideration for Github integration project

  • Preferred license for SPDX project is Apache 2.0
  • Some of the scanners Anna would like to use in the git integration project use GPL and LGPL licenses
  • GPL 2 may conflict with Apache 2.0
    • Gary and/or Anna will confirm the that the license is GPL 2.0 or later
    • If GPL 2.0 or later, we can use GPL 3 which will not conflict with the APache license
  • One goal is to have Github pickup some of the open source code
    • GPL may limit usage by Github
    • Agree to try and structure the code so that the Github extensions would just use Apache
    • A separate project could be created which combines the scanners with the library. This project would use the GPL license.

SPDX specification to github

  • Thomas is pushing the last changes now – should be available soon
  • Agreed to maintain changes in the master branch and use tagging for most recent
  • Thomas can create branches for 2.1 and 2.2 to allow for changes concurrent with more radical changes
  • Alexios would like to avoid branches, using tags instead
  • Need to create a contributing doc that describes the branches
  • Thomas will publish a proposed contributing doc
  • Will discuss in 2 weeks

Next SPDX Spec

  • See https://docs.google.com/document/d/1vJqWGU02ynzrJ5CvmX1z2mBssOSpuBvuKene8jVJGNI/edit
  • Question: Single format or multiple formats supported?
    • Multiple formats would benefit adoption since it appeals to different communities
    • Websites could support different formats and use context negotiation to view different formats
    • Tools could be used to translate
    • Would need to support the computer language of choice
    • Agree that supporting multiple formats supports higher adoption
  • Discussion on format needing to supported linked data/graphs
    • Complexity could be an inhibitor for adopting linked data
    • Data may need to be linked to be useful
    • Thomas – Proposal for incremental support, non-linked data would have less mandatory fields
  • Proposal to make RDF/Turtle preferred RDF representation
    • Next revision, replace RDF/XML with RDF/Turtle
    • Action: Update the github spec with RDF/Turtle examples (replace the RDF/XML)
  • We will revisit JSON and YAML once we have Philippe present
    • General agreement using standard parsers such as JSON and YAML would be positive for adoption