Difference between revisions of "General Meeting/Minutes/2021-03-04"

From SPDX Wiki
Jump to: navigation, search
(added links to presentation materials)
Line 8: Line 8:
== SPDX BOM for CMake Project ==
== SPDX BOM for CMake Project ==
* Materials:
** Slides: https://github.com/swinslow/slides/blob/main/2021-02-fosdem/2021-02-07-FOSDEM-2021-SPDX-CMake.pdf
** POC repo: https://github.com/swinslow/cmake-spdx
* Background
* Background
Line 49: Line 53:
** Kate: agreed, let’s get a working group together on this
** Kate: agreed, let’s get a working group together on this
== Legal Team Report - Jilayne/Paul/Steve ==
== Legal Team Report - Jilayne/Paul/Steve ==

Latest revision as of 12:57, 1 April 2021

  • Attendance: 18
  • Lead by Phil Odence
  • Minutes of Feb meeting Approved
  • Housekeeping
    • Zoom - Will be migrating to Zoom for these meetings; working with LF
    • Phil will need to cut out early; Steve will take over notes

SPDX BOM for CMake Project

  • Background
    • Presented previously at FOSDEM
    • Used Zephyr, lightweight RTOS
    • Goal in parallel with CMake build generate an SPDX file
      • including relationships
      • fully automated
      • not pull from external sources (license data for example)
      • make is Zephyr-agnostic, so could be reusable
  • POC
    • On GHub
    • Used File-based API on CMake
      • to tell CMake to dump JSON meta-data files for each artifact
      • and then build
    • Created SPDX
      • Pull from
        • Sources directory
        • Artifacts directory
        • Pull SPDX short form license names from files
        • Create relationships
      • Output is two files
        • Sources
        • Build artifacts
        • w links between
  • Findings
    • Some limitations to the CMake API data, missing some info that CMake seems to “know”
    • Some invalid IDs
    • Graphiz was helpful in visualize the relationships represented in JSON files
  • Next Steps
    • Takeaways: the concept basically works; start small and can be improved
    • Working w Zephyr community
      • may have made it overly agnostic
      • could tailor to Z build system
      • but generalized version is a great starting point
    • Michael Herzog: developed TraceCode as a tool to similarly look at details during the build process; more generalized, but extremely hard to use for anything sizeable b/c creates so much data
    • Also looked at Yocto as a way to gather this information
    • Kate: Richard Purdie interested in this also from the Yocto side – perhaps get together a working group focused on this. Yocto also doing work around reproducible builds, and has been adopting SPDX identifiers.


    • Kay: thoughts on a “Build” profile for SPDX 3.0 to incorporate build-time data about e.g. the call used to start the compilation, the environment / compilation settings, etc. We should get various compiler people talking about how to align practices for this
    • Kate: agreed, let’s get a working group together on this


Legal Team Report - Jilayne/Paul/Steve


  • Gary and William got the license list CI system moved from Travis to GitHub Actions – thank you!
  • 3.12 – aiming to release this weekend; will tie up remaining issues in call after this meeting
  • Jilayne and Steve looking at getting some bigger projects going
  • Invite to all to jump into the conversations in issue threads - https://github.com/spdx/license-list-XML/issues


Tech Team Report - Kate/Gary/Others


  • Model and Process update – Gary
    • William leading discussions on Base profile model – reconciling feedback
    • Template for how to draft and write the profile specifications
  • Google Summer of Code – Gary
    • Should be hearing back shortly whether SPDX was accepted for 2021


  • Spec – Kate
    • Defects / Security – Thomas
      • currently revising what was discussed on prior meetings
      • worked with William on expressing vulnerabilities
      • also looking at: whether / how to express mitigation measures
    • Linking – Nisha
      • Sounds like people do want a Linking / Linkage profile
      • Currently described in the spec as an “External Map” from 3T discussions, but not sure what this means – looking for more details
    • Integrity – Kay
      • Working on creating POC for taking an SBOM, serializing it to binary, signing it using the COSI (?) standard
      • could be signed in other ways, but using this for POC b/c small format and usable for small devices
      • expect to have this the week after next
      • spec for document integrity – “here’s how you sign SBOMs” – after having that as an example, plan to start reviewing with broader group
      • may be a month before ready to discuss on a tech team call
    • Usage – Yoshiyuki Ito
      • discussing what info to include in usage profile
      • looking at using external map to refer to external information sources
    • Pedigree / Build / Creation – Kate
      • can start those meetings happening, flesh out ideas
      • reach out to in-toto folks to align with them


  • SPDX 2.2.1 – Kate:
    • ISO balloting has finished on the specification, via JDF
    • Approved from balloting, so should be getting an ISO number in the next few months
    • May have some tweaks to the 2.2.1 repo coming in, based on comments from ISO reviewers


Outreach Team Report


  • No Report


  • Phil Odence, Black Duck/Synopsys
  • Steve Winslow, LF
  • Michael Herzog- nexB
  • Gary O’Neall, SourceAuditor
  • David Edelsohn
  • Jeff Schutt
  • Rose Judge, VMware
  • Nisha Kumar, VMware
  • Jilayne Lovejoy, Red Hat
  • Kate Stewart, Linux Foundation
  • Emmanuel Tournier, Black Duck/Synopsys
  • Jorge Rodriguez-Moreno
  • Alfredo Espinosa
  • Kay Williams, Microsoft
  • Paul Madick, Jenzabar
  • William Cox, Synopsys
  • Bob Martin, Mitre
  • Thomas Steenbergen, HERE