General Meeting/Minutes/2019-01-03¶
Archived page
Read-only copy of the SPDX wiki. The wiki is no longer active; its content has moved to https://github.com/spdx. Last edited 2019-01-03 by Podence.
- Attendance: 15
- Lead by Phil Odence
- Minutes of Dec meeting approved
Guest Presentation, JC Herz¶
- Background
- Years of working with companies and DOD in open source
- The Issues/concerns
- License issues- SPDX handles well
- Concerns about security close on the heels
- Compliance is an additional step- Jumping through the hoops to document
- SEVA Software Evidence Archive
- Elements
- Serves S-BOM function
- Augments with content that needs to travel with software
- Therefore allowing compliance work to be automated
- Freeing up valuable resources to do what they are supposed to do
- Can apply to a single component or a full application, so SEVA doesn’t distinguish
- Format Issue
- Customers required XML, beyond SEVA JSON
- To be useable by a highly secure facility, data has to be hardened for which XML is better suited
- Can be constrained and format can be verified (and extended)
- SPDX and SEVA Overlap
- License Info
- For the most part SPDX handles beautifully
- Government also needs to distinguish government open source
- A little more information about state of software (e.g. pre-release)
- Security extra needs
- Some concern about spurious vulnerabilities
- Answer is to extend a BoM to include patch info, etc
- End of life indicator
- They take SPDX familiar thing and provide some extensibility
- How to name “supplier”?
- Working with Kate
- OSS organization for example
- A bank’s black list
- Vulnerabilities
- Key requirement for vulnerabilities info in SBOM, although just a link might make more sense
- Reason is “audit” function. What you knew when. So needs a time stamp.
- Bureaucratic are not going to change in favor of something that makes more sense for developers
- Concerns that this will get worse over time
- Other Side - Logistics
- Moving and shipping of SW/chain of custody- Where did it come from exactly
- Not something OSS community has had to worry about
- Bad mirror issue, for example.
- Signed? Timestamp? Delivery date and time for software.
- Something like FedEx analogy
- Package URL helps identify
- Q&A
- What can SPDX group do?
- JC thinks that they should open source SEVA
- Could contribute to LinuxF perhaps
- Understand and need to balance needs of OSS consumers and dev communities
- Don’t want to burden them
- Automate
- Challenge- How to distinguish enterprise quality OSS vs. pet projects
Tech Team Report - Kate/Gary¶
- Tools
- Starting to plan for GSoC submissions with Gary/Kate
- Steve has been trained on releasing License list, so Gary now has backup
- Steve has been working on some new tools for summarizing the SPDX_license_ids based on a new SPDX go library - currently its just supporting TV, but he hopes to add in the other formats
- Specification
- Gary & James have been working through SeVA XML and working through how it can be added.
Legal Team Report - Jilayne¶
- License List
- V3.4 out before Christmas
- Big success to not have to scramble through holidays
- Release notes in the GitHub repo
- Instructions for requesting now live in Repo as well
- Leverage GSOC work has been automated.
- New frontier- Getting open hardware licenses on list
- Expanding definition of what goes on the list
Outreach Team Report¶
- None this month
Attendees¶
- Phil Odence, Black Duck/Synopsys
- Kate Stewart, Linux Foundation
- Jilayne Lovejoy
- Steve Winslow, LF
- Alexios Zavras, Intel
- Luis Villa, Tidelift
- Jams Neushal, Neushul Solutions
- Matthew Crawford, ARM
- Kevin Nelson, Optim Tech UHG
- Dennis Clark, NexB
- Thomas Steenbergen, HERE
- Bradlee Edmondson, Harvard
- Gary O’Neall, SourceAuditor
- Nicholas Toussaint, Orange
- JC Herz, Ionchannel