Date   

SPDX Thurs General Meeting Reminder

Phil Odence
 

This month’s presentation will be one of the every popular reports on a Google Summer of Code project:

 

Project Title: NTIA Conformance Checker – Josh Lin

 

Project Abstract: This project implemented an NTIA Conformance Checker that checks whether a software bill of materials (SBOM) in SPDX format conforms to the NTIA’s Minimum elements guidance.

 

Project Overview: The minimum constituent parts of an overall Software Bill of Material (SBOM) – referred to as NTIA’s minimum elements – are three broad, interrelated areas (Data Fields, Automation Support, and Practices and Processes). These elements will enable an evolving approach to software transparency, capturing both the technology and the functional operation. The purpose of this project is to check if an SBOM document contains the minimum required data fields such as the supplier name, component name, component version, unique identifiers, dependency relationships, author of the SBOM, and timestamps.

 

About Josh:

I am a 2nd year computer science student at University British Columbia and I am currently on a co-op term. I participated in Google Summer of Code 2022 as an open source contributor and it was through this program that I built the NTIA Conformance Checker under the guidance of my mentors Jeff, Nisha, Gary, and Kate.  

 

 

GENERAL MEETING

 

Meeting Time: Thurs, Oct 3, 8am PT / 10 am CT / 11am ET / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html


Conf call dial-in:

Join the meeting:
https://meet.jit.si/SPDXGeneralMeeting

To join by phone instead, tap this: +1.512.647.1431,,1310118349#

Looking for a different dial-in number?
See meeting dial-in numbers: 
https://meet.jit.si/static/dialInInfo.html?room=SPDXGeneralMeeting


If also dialing-in through a room phone, join without connecting to audio: 
https://meet.jit.si/SPDXGeneralMeeting#config.startSilent=true

 

Etherpad for minutes:

https://spdx.swinslow.net/p/spdx-general-minutes

 

Administrative Agenda

Attendance

Minutes Approval: https://github.com/spdx/meetings/blob/main/general/2022-09-01.md

 

Steering Committee Update – Phil

 

GSOC Presentation  – Josh Lin

 

Technical Team Report – Gary/Others

  • Specification and Profiles
    • Overview
    • Core
    • Legal
    • Integrity
    • Defects
    • Usage and Other Emerging
  • Tooling

 

Legal Team Report – Jilayne/Paul/Steve

 

Outreach/Website Team Report – Sebastian/Alexios

 

 

 

 


General release of SAG-PM Version 1.2 with support for SPDX Version 2.3

Dick Brooks
 

REA is pleased to announce the general availability of SAG-PM Version 1.2 with support for SPDX V 2.3 and CycloneDX V 1.4.

This release satisfies the requirements outlined on OMB memo M-22-18 published on September 14.

 

https://www.linkedin.com/posts/richard-dick-brooks-8078241_reliable-energy-analytics-llc-activity-6980932569018081280-pjaC/?utm_source=share&utm_medium=member_desktop

 

Thanks,

 

Dick Brooks

 

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership

 

Never trust software, always verify and report!

http://www.reliableenergyanalytics.com

Email: dick@...

Tel: +1 978-696-1788

 

From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Dick Brooks
Sent: Wednesday, September 14, 2022 5:13 PM
To: 'SPDX Technical Mailing List' <spdx-tech@...>
Subject: [spdx-tech] FYI: New White House Memo issued today outlining SBOM implementation guidance for Executive Order 14028

 

Parties interested in actual SBOM implementation guidance should refer to this White House Memo, issued September 14, 2022:

https://www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf

 

 

Thanks,

 

Dick Brooks

 

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership

 

Never trust software, always verify and report!

http://www.reliableenergyanalytics.com

Email: dick@...

Tel: +1 978-696-1788

 


New Change Proposal process

J Lovejoy
 

Dear SPDX community,

As mentioned on a couple of the general calls some time ago, the Steering Committee has been working on a Change Proposal template and process to facilitate communication, prioritization, and decision-making as to what major changes the project will work on. 

As the community has grown, we want to ensure we have a way to discuss new ideas in a timely manner, decide on what will get implemented, and then follow-through on that plan. Many projects use a template for describing new ideas and proposals, which ensures everyone is clear on what is being proposed, why, and how it fits into the bigger picture. 

To this end a new GitHub repo has been created (https://github.com/spdx/change-proposal) with a description of the process and a Change Proposal template.  Having a separate repo will provide a place for new ideas to start and make it easier to manage notifications. The intention is that this process will be used for more significant changes - not day-to-day activities or things already in flight. As to what changes use this process or not, we will refine guidance on that as needed. 

We also thought it’d be good for a Steering Committee member to lead by example and submit the first Change Proposal. To that end, Alexios has volunteered to do so!

Thanks to Vicky Brasseur and Ria Schalnat for their excellent help in drafting this and the Steering Committee for bringing it to fruition. 

Jilayne
(on behalf of SPDX Steering Committee)




SPDX Thurs (today) General Meeting Reminder

Phil Odence
 

It’s September! Apologies for the late reminder. I just never hit send yesterday.

 

Note that the minutes from August meeting are at the bottome of this email.

 

This month, there will be no special presentation per se, however the Steering Committee update will be extended and will include Jilayne presenting a new process to facilitate expedient decision making around new ideas that have cross team impact or would represent a big change for the overall project.

 

Phil

 

L. Philip Odence

General Manager, Black Duck Audit Business

Synopsys Software Integrity Group, Burlington, MA

M (781) 258-9502 | phil.odence@...

https://www.synopsys.com/audits  

 

 

SIG-emailsig-2020

 

 

signature_2892046952   signature_4149161518   signature_715487372   signature_2597224942

 

 

 

GENERAL MEETING

 

Meeting Time: Thurs, Sept 1, 8am PT / 10 am CT / 11am ET / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html


Conf call dial-in:

Join the meeting:
https://meet.jit.si/SPDXGeneralMeeting

To join by phone instead, tap this: +1.512.647.1431,,1310118349#

Looking for a different dial-in number?
See meeting dial-in numbers: 
https://meet.jit.si/static/dialInInfo.html?room=SPDXGeneralMeeting


If also dialing-in through a room phone, join without connecting to audio: 
https://meet.jit.si/SPDXGeneralMeeting#config.startSilent=true

 

Etherpad for minutes:

https://spdx.swinslow.net/p/spdx-general-minutes

 

Administrative Agenda

Attendance

Minutes Approval: At the bottom of this email

 

Steering Committee Update - Phil

 

Technical Team Report – Kate/Gary/Others

  • Specification and Profiles
    • Overview
    • Core
    • Legal
    • Integrity
    • Defects
    • Usage and Other Emerging
  • Tooling

 

Legal Team Report – Jilayne/Paul/Steve

 

Outreach/Website Team Report – Jack/Sebastian/Alexios

 

 

 

SPDX General Meeting Minutes - Aug 4, 2022

Administrative

Attendance: 29

  • Lead by Phil Odence, Steve Winslow
  • Minutes from last meeting approved

Special Presentation, Matthew Crawford

  • A new era for SPDX at Arm, are we ready for change? - A New Era for SPDX at Arm: Are we ready for change? (recording available, insert link later)
  • Thanks to Jilayne, Sami Atabani and SPDX team
  • Old system (ulimately non-std BoM format)
  • Towards generating SPDX
  • New tooling "hot off the press"

Tech Team Report - Gary/Kate/WilliamB

Spec

  • SPDX 2.3 release window - 6 days left. If see any issues, raise in Github, or on tech team email list
    • RC1 window - no roadblocks raised yet.
    • Schema available and tool creators requested to experiment and raise issues.
    • Joshua - CVE reporting added, not clear how to use it. Gary: using external references to refer to CVEs, as well as other security types. Any way to indicate a specific CVE has been fixed? VEX document may be an option. Recommed going to defects working group.
    • Java tools have been implemented, will be publised after 2.3 release is out.
  • GSoC checkpoint - Alexios
    • just passed half-time mark, steady progress on both projects.
  • SPDX 3.0 Model
    • Good progress on identities, updated in repo. seee: SPDX v3 model diagram https://github.com/spdx/spdx-3-model/blob/main/model.png
    • AI BOM profile - discussed into 2 parts - AI App/Model & Data sets
    • Build Profile - making steady process
    • Defects - looking at what should be in 3.0 now, use-cases welcome
    • Usage -

Legal Team Report - Jilayne/Paul/Steve

Outreach Team Report - Sebastian / Jack / Alexios

  • GSoC - mentioned above
  • general activity, making improvements to outreach team Landscape with Wipro volunteer assistance (thanks Vicky and others!)
  • logos for SPDX's own tools - seeking folks with graphic design talents
    • can explore with LF marketing (Steve will help with LF interaction)
    • noted at OpenSSF - using AI image generators
    • Meeting time is changing to shorter weekly 30 minute meetings.

Attendees

  • Phil Odence, Synopsys/Black Duck Audits
  • Matthew Crawford (Arm)
  • Kate Stewart
  • Gary O'Neall
  • Jilayne Lovejoy (Red Hat)
  • Jari Koivisto
  • Sebastian Crane
  • Alexios Zavras
  • Steve Winslow
  • Ray Lutz (Citizensoversight.org)
  • Akbar (Arm)
  • Alex Rybak (Revenera)
  • Alfredo Espinosa
  • Andrew Jorgenson
  • Brad Goldring (GTC Law Group)
  • Bryan Cowan
  • Christopher Lusk
  • David Edelsohn
  • Jeff H.
  • Karsten Klein
  • Molly Menoni
  • Rich Steenwyk
  • Shailja Kumari
  • Joshua Watt
  • Ria Schalnat
  • Stephen Reeves
  • Janet
  • VM Brasseur
  • Jeff Schutt

 

 

 

 


Re: SPDX Merging #spdx

Ivana Atanasova
 

Hi,

 

Just made the sbom-composer tool public. It’s been only run with sboms that I generated, so would be very happy to hear your feedback and do any following updates if necessary.

 

Joe, it does the merge based on these guidelines. As an example these two sboms result in this composed.spdx. Shortly, it just appends the data without the document creation information, allows the latter to be configurable and updates the references. Would be happy to hear your feedback if any.

 

Best,

Ivana

 

---

Ivana Atanasova

Open Source Engineer

VMware Open Source Program Office

 

From: spdx@... <spdx@...> on behalf of Joe Bussell via lists.spdx.org <joe.bussell=microsoft.com@...>
Date: Tuesday, 9 August 2022, 20:09
To: spdx@... <spdx@...>
Subject: Re: [spdx] SPDX Merging #spdx

Shouldn’t this be done by creating a third SBOM that refers back to the subordinate SBOMs, including all three in the result chain?

 

From: spdx@... <spdx@...> On Behalf Of Gary O'Neall via lists.spdx.org
Sent: Monday, August 8, 2022 10:07 AM
To: spdx@...
Subject: [EXTERNAL] Re: [spdx] SPDX Merging #spdx

 

I’m not aware of a tool that currently supports merging.  There is an issue open on the SPDX Java tools – any java programmers out there who would like to volunteer a solution is welcome to create a pull request.

 

Regards,

Gary

 

From: spdx@... <spdx@...> On Behalf Of Patil, Sandeep via lists.spdx.org
Sent: Monday, August 8, 2022 4:07 AM
To:
spdx@...
Subject: [spdx] SPDX Merging #spdx

 

Hi All, 
Is there any tool to merge two spdx file ? 

Regards
Sandeep 

 



Re: SPDX Merging #spdx

Joe Bussell
 

Shouldn’t this be done by creating a third SBOM that refers back to the subordinate SBOMs, including all three in the result chain?

 

From: spdx@... <spdx@...> On Behalf Of Gary O'Neall via lists.spdx.org
Sent: Monday, August 8, 2022 10:07 AM
To: spdx@...
Subject: [EXTERNAL] Re: [spdx] SPDX Merging #spdx

 

I’m not aware of a tool that currently supports merging.  There is an issue open on the SPDX Java tools – any java programmers out there who would like to volunteer a solution is welcome to create a pull request.

 

Regards,

Gary

 

From: spdx@... <spdx@...> On Behalf Of Patil, Sandeep via lists.spdx.org
Sent: Monday, August 8, 2022 4:07 AM
To: spdx@...
Subject: [spdx] SPDX Merging #spdx

 

Hi All, 
Is there any tool to merge two spdx file ? 

Regards
Sandeep 


Re: SPDX Merging #spdx

Ivana Atanasova
 

Hi,

 

I’m currently working on a composer tool that supports merging. Shortly to be open-sourced.

 

Best,

Ivana

 

---

Ivana Atanasova

Open Source Engineer

VMware Open Source Program Office

 

From: spdx@... <spdx@...> on behalf of Gary O'Neall via lists.spdx.org <gary=sourceauditor.com@...>
Date: Monday, 8 August 2022, 20:07
To: spdx@... <spdx@...>
Subject: Re: [spdx] SPDX Merging #spdx

I’m not aware of a tool that currently supports merging.  There is an issue open on the SPDX Java tools – any java programmers out there who would like to volunteer a solution is welcome to create a pull request.

 

Regards,

Gary

 

From: spdx@... <spdx@...> On Behalf Of Patil, Sandeep via lists.spdx.org
Sent: Monday, August 8, 2022 4:07 AM
To: spdx@...
Subject: [spdx] SPDX Merging #spdx

 

Hi All, 
Is there any tool to merge two spdx file ? 

Regards
Sandeep 

 



Re: SPDX Merging #spdx

Gary O'Neall
 

I’m not aware of a tool that currently supports merging.  There is an issue open on the SPDX Java tools – any java programmers out there who would like to volunteer a solution is welcome to create a pull request.

 

Regards,

Gary

 

From: spdx@... <spdx@...> On Behalf Of Patil, Sandeep via lists.spdx.org
Sent: Monday, August 8, 2022 4:07 AM
To: spdx@...
Subject: [spdx] SPDX Merging #spdx

 

Hi All, 
Is there any tool to merge two spdx file ? 

Regards
Sandeep 


Re: SPDX Signing #spdx

Brandon Lum
 

Cosign also has a format for doing this: https://github.com/sigstore/cosign/blob/main/specs/SBOM_SPEC.md

(Different from the attestation i just sent)

On Mon, Aug 8, 2022 at 10:33 AM Brandon Lum via lists.spdx.org <lumb=google.com@...> wrote:
I've been signing and uploading them with sigstore as an intoto predicate, but not using the intoto specified spdx schema but instead pointing to a URI. Since sigstore has a limit on attestation size and this (point to a URI) also allows one to defer authorization of the blob to a storage server and point to a collection of documents.

Still in draft, but this is a approximation of what we're using

{
  "_type": "https://in-toto.io/Statement/v0.1",
  "predicateType": "http://google.com/sbom",
  "subject": [
    {
      "name": "binary-linux-amd64",
      "digest": {
        "sha256": "f2e59e0e82c6a1b2c18ceea1dcb739f680f50ad588759217fc564b6aa5234791"
      }
    }
  ],
  "predicate": {
    "sboms": [
      {
        "format": "SPDX",
        "digest": {
          "sha256": "02948ad50464ee57fe237b09054c45b1bff6c7d18729eea1eb740d89d9563209"
        },
        "uri": "https://github.com/lumjjb/sample-golang-prov/releases/download/v1.3/binary.spdx"
      }
    ],
    // BuildMetadata is optional, but is used for provenance verification in the event SLSA 
    // provenance is not available. Specific to github actions workflow.
    "build-metadata": {
      "artifact-source-repo": "https://github.com/lumjjb/sample-golang-prov",
      "artifact-source-repo-commit": "c8cb5f292c77064aeabb488ea4f5e483a5073076",
      "attestation-generator-repo": "https://github.com/lumjjb/slsa-github-generator-go",
      "attestation-generator-repo-commit": "6948f4c67f6bca55657fe1fb3630b55b1714ef2d"
    }
  }
}




On Mon, Aug 8, 2022 at 7:51 AM Steve Kilbane <stephen.kilbane@...> wrote:

May as well throw out a plug for https://openssf.org/, and for https://www.sigstore.dev/ in particular, here.

 

A recent* Open Source Summit session gave an example of signing SBOMs using sigstore, if I recall correctly, though I don’t recall the details.

 

steve

 

* I say “recent” – could have been SupplyChainSecurityCon back in October. My sense of Time is out of whack since the pandemic.

 

From: spdx@... <spdx@...> On Behalf Of Dick Brooks
Sent: 08 August 2022 12:42
To: spdx@...
Subject: Re: [spdx] SPDX Signing #spdx

 

[External]

 

Sandeep,

 

I’m not aware of any specific guidelines for signing SBOM’s (SPDX and CycloneDX).

 

REA’s signs SBOM’s using PGP as this seems to be the easiest method to sign stand-alone text files, including SBOM’s.

We simply have to make our public key available for verification of signed SBOM’s.

 

The IETF is working on a new supply chain integrity, transparency and trust initiative (SCITT) that aims to produce a method for signing and verifying attestations, including SBOM’s.

https://github.com/ietf-scitt

 

Thanks,

 

Dick Brooks

 

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership

 

Never trust software, always verify and report!

http://www.reliableenergyanalytics.com

Email: dick@...

Tel: +1 978-696-1788

 

From: spdx@... <spdx@...> On Behalf Of Patil, Sandeep via lists.spdx.org
Sent: Monday, August 8, 2022 7:08 AM
To: spdx@...
Subject: [spdx] SPDX Signing #spdx

 

Hi All,
Is there any guidelines to sign SPDX file ? 

Regards
Sandeep 


Re: SPDX Signing #spdx

Brandon Lum
 

I've been signing and uploading them with sigstore as an intoto predicate, but not using the intoto specified spdx schema but instead pointing to a URI. Since sigstore has a limit on attestation size and this (point to a URI) also allows one to defer authorization of the blob to a storage server and point to a collection of documents.

Still in draft, but this is a approximation of what we're using

{
  "_type": "https://in-toto.io/Statement/v0.1",
  "predicateType": "http://google.com/sbom",
  "subject": [
    {
      "name": "binary-linux-amd64",
      "digest": {
        "sha256": "f2e59e0e82c6a1b2c18ceea1dcb739f680f50ad588759217fc564b6aa5234791"
      }
    }
  ],
  "predicate": {
    "sboms": [
      {
        "format": "SPDX",
        "digest": {
          "sha256": "02948ad50464ee57fe237b09054c45b1bff6c7d18729eea1eb740d89d9563209"
        },
        "uri": "https://github.com/lumjjb/sample-golang-prov/releases/download/v1.3/binary.spdx"
      }
    ],
    // BuildMetadata is optional, but is used for provenance verification in the event SLSA 
    // provenance is not available. Specific to github actions workflow.
    "build-metadata": {
      "artifact-source-repo": "https://github.com/lumjjb/sample-golang-prov",
      "artifact-source-repo-commit": "c8cb5f292c77064aeabb488ea4f5e483a5073076",
      "attestation-generator-repo": "https://github.com/lumjjb/slsa-github-generator-go",
      "attestation-generator-repo-commit": "6948f4c67f6bca55657fe1fb3630b55b1714ef2d"
    }
  }
}




On Mon, Aug 8, 2022 at 7:51 AM Steve Kilbane <stephen.kilbane@...> wrote:

May as well throw out a plug for https://openssf.org/, and for https://www.sigstore.dev/ in particular, here.

 

A recent* Open Source Summit session gave an example of signing SBOMs using sigstore, if I recall correctly, though I don’t recall the details.

 

steve

 

* I say “recent” – could have been SupplyChainSecurityCon back in October. My sense of Time is out of whack since the pandemic.

 

From: spdx@... <spdx@...> On Behalf Of Dick Brooks
Sent: 08 August 2022 12:42
To: spdx@...
Subject: Re: [spdx] SPDX Signing #spdx

 

[External]

 

Sandeep,

 

I’m not aware of any specific guidelines for signing SBOM’s (SPDX and CycloneDX).

 

REA’s signs SBOM’s using PGP as this seems to be the easiest method to sign stand-alone text files, including SBOM’s.

We simply have to make our public key available for verification of signed SBOM’s.

 

The IETF is working on a new supply chain integrity, transparency and trust initiative (SCITT) that aims to produce a method for signing and verifying attestations, including SBOM’s.

https://github.com/ietf-scitt

 

Thanks,

 

Dick Brooks

 

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership

 

Never trust software, always verify and report!

http://www.reliableenergyanalytics.com

Email: dick@...

Tel: +1 978-696-1788

 

From: spdx@... <spdx@...> On Behalf Of Patil, Sandeep via lists.spdx.org
Sent: Monday, August 8, 2022 7:08 AM
To: spdx@...
Subject: [spdx] SPDX Signing #spdx

 

Hi All,
Is there any guidelines to sign SPDX file ? 

Regards
Sandeep 


Re: SPDX Signing #spdx

Steve Kilbane
 

May as well throw out a plug for https://openssf.org/, and for https://www.sigstore.dev/ in particular, here.

 

A recent* Open Source Summit session gave an example of signing SBOMs using sigstore, if I recall correctly, though I don’t recall the details.

 

steve

 

* I say “recent” – could have been SupplyChainSecurityCon back in October. My sense of Time is out of whack since the pandemic.

 

From: spdx@... <spdx@...> On Behalf Of Dick Brooks
Sent: 08 August 2022 12:42
To: spdx@...
Subject: Re: [spdx] SPDX Signing #spdx

 

[External]

 

Sandeep,

 

I’m not aware of any specific guidelines for signing SBOM’s (SPDX and CycloneDX).

 

REA’s signs SBOM’s using PGP as this seems to be the easiest method to sign stand-alone text files, including SBOM’s.

We simply have to make our public key available for verification of signed SBOM’s.

 

The IETF is working on a new supply chain integrity, transparency and trust initiative (SCITT) that aims to produce a method for signing and verifying attestations, including SBOM’s.

https://github.com/ietf-scitt

 

Thanks,

 

Dick Brooks

 

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership

 

Never trust software, always verify and report!

http://www.reliableenergyanalytics.com

Email: dick@...

Tel: +1 978-696-1788

 

From: spdx@... <spdx@...> On Behalf Of Patil, Sandeep via lists.spdx.org
Sent: Monday, August 8, 2022 7:08 AM
To: spdx@...
Subject: [spdx] SPDX Signing #spdx

 

Hi All,
Is there any guidelines to sign SPDX file ? 

Regards
Sandeep 


Re: SPDX Signing #spdx

hectorf@...
 

Sandeep,

I know it is not a guideline. But we generally use sigstore/cosign to sign SBOMs. In a near future, we might start injecting the SBOM as part of an in-toto attestation, so it is signed and potentially contains more metadata.

Hector


Re: SPDX Signing #spdx

Dick Brooks
 

Sandeep,

 

I’m not aware of any specific guidelines for signing SBOM’s (SPDX and CycloneDX).

 

REA’s signs SBOM’s using PGP as this seems to be the easiest method to sign stand-alone text files, including SBOM’s.

We simply have to make our public key available for verification of signed SBOM’s.

 

The IETF is working on a new supply chain integrity, transparency and trust initiative (SCITT) that aims to produce a method for signing and verifying attestations, including SBOM’s.

https://github.com/ietf-scitt

 

Thanks,

 

Dick Brooks

 

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership

 

Never trust software, always verify and report!

http://www.reliableenergyanalytics.com

Email: dick@...

Tel: +1 978-696-1788

 

From: spdx@... <spdx@...> On Behalf Of Patil, Sandeep via lists.spdx.org
Sent: Monday, August 8, 2022 7:08 AM
To: spdx@...
Subject: [spdx] SPDX Signing #spdx

 

Hi All,
Is there any guidelines to sign SPDX file ? 

Regards
Sandeep 


SPDX Signing #spdx

Patil, Sandeep
 

Hi All,
Is there any guidelines to sign SPDX file ? 

Regards
Sandeep 


SPDX Merging #spdx

Patil, Sandeep
 

Hi All, 
Is there any tool to merge two spdx file ? 

Regards
Sandeep 


SPDX Thurs General Meeting Reminder

Phil Odence
 

Special Presentation this month by Matthew Crawford from Arm:

Title

A new era for SPDX at Arm, are we ready for change?

 

Let me walk you through the journey of open source software compliance at Arm, from spreadsheets of doom to a platform that captures OSS approvals and produces SPDX files. There were numerous hurdles along the journey but with the help of the internal and external community (including members of this group) we have achieved something that is helpful for Arm and its partners. 

 

Bio

 

Matthew Crawford has been working at Arm since 2017 mainly focusing on the Third Party Intellectual Property strategy and process management. His professional accomplishments include working to make Arm OpenChain conformant in 2019; involvement in the Google Summer of Code as a mentor and working with the SPDX community. He has a strong passion for open source hardware and software governance, trust and security. Before 2017, Matthew worked in the pharmaceutical industry for GlaxoSmithKline and amongst other things worked on building trust in the software being used throughout the supply chain (as well as designing and synthesising medicines!).

 

 

GENERAL MEETING

 

Meeting Time: Thurs, Aug 4, 8am PT / 10 am CT / 11am ET / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html


Conf call dial-in:

Join the meeting:
https://meet.jit.si/SPDXGeneralMeeting

To join by phone instead, tap this: +1.512.647.1431,,1310118349#

Looking for a different dial-in number?
See meeting dial-in numbers: 
https://meet.jit.si/static/dialInInfo.html?room=SPDXGeneralMeeting


If also dialing-in through a room phone, join without connecting to audio: 
https://meet.jit.si/SPDXGeneralMeeting#config.startSilent=true

 

Etherpad for minutes:

https://spdx.swinslow.net/p/spdx-general-minutes

 

Administrative Agenda

Attendance

Minutes Approval: https://github.com/spdx/meetings/blob/main/general/2022-06-02.md

 

Presentation- Matthew

 

Steering Committee Update - Phil

 

Technical Team Report – Kate/Gary/Others

  • Specification and Profiles
    • Overview
    • Core
    • Legal
    • Integrity
    • Defects
    • Usage and Other Emerging
  • Tooling

 

Legal Team Report – Jilayne/Paul/Steve

 

Outreach/Website Team Report – Jack/Sebastian/Alexios


Re: [spdx-tech] Important changes to software license information in Fedora packages (SPDX and more!)

Neal Gompa
 

On Mon, Aug 1, 2022 at 4:20 AM Phil Odence via lists.spdx.org <phil.odence=synopsys.com@...> wrote:

Nice. This certainly makes it easy to map from Fedora to SPDX IDs!

 SPDX license identifiers have emerged as a standard

 

Woo hoo!

_,_._,_

I hope you are all ready for the upcoming pains in the next few years. Transitioning Fedora to SPDX is not going to be a happy time for a little while, since there's a huge impedance mismatch between Fedora and SPDX, as well as an incomplete identification of licenses on the SPDX side. I know I'm not looking forward to recategorizing all the MIT and BSD license variants. I expect we're going to see a lot of new license submissions over the coming years as all packages get re-audited in a future phase...

I wonder if we're going to regret this extra "precision" in the end?

On a personal note, I am still rather upset about some aspects of the expression syntax that I had been informed years ago would be fixed, but has apparently not been. In particular, the specification still does not allow lowercase "or"/"and"/"with" even though all the parsers accept it. Reading SPDX expressions with capital operands is very painful for humans (which is what these things are actually for). Any chance we can get this fixed soon?



--
真実はいつも一つ!/ Always, there's only one truth!


Re: [spdx-tech] Important changes to software license information in Fedora packages (SPDX and more!)

Phil Odence
 

Nice. This certainly makes it easy to map from Fedora to SPDX IDs!

 SPDX license identifiers have emerged as a standard

 

Woo hoo!

 

 

From: Spdx-legal@... <Spdx-legal@...> on behalf of Steve Winslow <swinslow@...>
Date: Saturday, July 30, 2022 at 12:06 PM
To: J Lovejoy <opensource@...>
Cc: SPDX-legal <Spdx-legal@...>, spdx@... <spdx@...>, Spdx-tech@... <Spdx-tech@...>, Spdx-outreach@... <Spdx-outreach@...>
Subject: Re: [spdx-tech] Important changes to software license information in Fedora packages (SPDX and more!)

Jilayne, this is awesome news -- thanks for passing it along!

 

Looking forward to us working with the Fedora community to support them adding SPDX license IDs across the distro.

 

Steve

 

On Fri, Jul 29, 2022 at 12:21 PM J Lovejoy <opensource@...> wrote:

Hot off the press!

Link to blog post of this here: https://communityblog.fedoraproject.org/important-changes-to-software-license-information-in-fedora-packages-spdx-and-more/

Thanks for the support on this from SPDX-legal. There is more work to come, for sure, but being able to use SPDX license identifiers in a full distro is a great challenge for our project to meet!

:)

Jilayne



-------- Forwarded Message --------

Subject:

[Fedora-legal-list] Important changes to software license information in Fedora packages (SPDX and more!)

Date:

Fri, 29 Jul 2022 11:19:48 -0400

From:

Matthew Miller <mattdm@...>

Reply-To:

legal@...

To:

devel-announce@...

CC:

packaging@..., legal@..., devel@...




On behalf of all of the folks working on Fedora licensing improvements,
I have a few things to announce!


New docs site for licensing and other legal topics
--------------------------------------------------

All documentation related to Fedora licensing has moved to a new
section in Fedora Docs, which you can find at:

https://docs.fedoraproject.org/en-US/legal/

Other legal documentation will follow. This follows the overall Fedora
goal of moving active user and contributor documentation away from the
wiki.


Fedora license information in a structured format
-------------------------------------------------

The “good” (allowed) and “bad” (not-allowed) licenses for Fedora are
now stored in a repository, using a simple structured file format for
each license (it’s TOML). You can find this at:
https://gitlab.com/fedora/legal/fedora-license-data

This data is then presented in easy tabular format in the
documentation, at:

https://docs.fedoraproject.org/en-US/legal/allowed-licenses/



New policy for the License field in packages — SPDX identifiers!
----------------------------------------------------------------

We’re changing the policy for the "License" field in package spec files
to use SPDX license identifiers. Historically, Fedora has represented
licenses using short abbreviations specific to Fedora. In the meantime,
SPDX license identifiers have emerged as a standard, and other
projects, vendors, and developers have started using them. Adopting
SPDX license identifiers provides greater accuracy as to what license
applies, and will make it easier for us to collaborate with other
projects.


Updated licensing policies and processes
----------------------------------------

Fedora licensing policies and processes have been updated to reflect
the above changes. In some cases, this forced deeper thought as to how
these things are decided and why, which led to various discussion on
Fedora mailing lists. In other cases, it prompted better articulation
of guidance that was implicitly understood but not necessarily
explicitly stated.


New guidance on “effective license” analysis
--------------------------------------------

Many software packages consist of code with different free and open
source licenses. Previous practice often involved “simplification” of
the package license field when the packager believed that one license
subsumed the other — for example, using just “GPL” when the source code
includes parts licensed under a BSD-style license as well. Going
forward, packagers and reviewers should not make this kind of analysis,
and rather use (for example) “GPL-2.0-or-later AND MIT”. This approach
is easier for packagers to apply in a consistent way.


When do these changes take effect?
----------------------------------

The resulting changes in practice will be applied to new packages and
licenses going forward. It is not necessary to revise existing packages
at this time, although we have provided some guidance for package
maintainers who want to get started. We’re in the process of planning a
path for updating existing packages at a larger scale — stay tuned for
more on that!


Thank you everyone!
-------------------

A huge thanks to some key people who have worked tirelessly to make
this happen: David Cantrell, Richard Fontana, Jilayne Lovejoy, Miroslav
Suchý. Behind the scenes support was also provided by David Levine,
Bryan Sutula, and Beatriz Couto. Thank you as well for the valuable
feedback from Fedora community members in various Fedora forums.

Please have a look at the updated information. If you have questions,
please post them to the Fedora Legal mailing list:

https://lists.fedoraproject.org/archives/list/legal@.../


-- 
Matthew Miller
<mattdm@...>
Fedora Project Leader
_______________________________________________
legal mailing list -- legal@...
To unsubscribe send an email to legal-leave@...
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/legal@...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure


Re: [spdx-tech] Important changes to software license information in Fedora packages (SPDX and more!)

Steve Winslow
 

Jilayne, this is awesome news -- thanks for passing it along!

Looking forward to us working with the Fedora community to support them adding SPDX license IDs across the distro.

Steve

On Fri, Jul 29, 2022 at 12:21 PM J Lovejoy <opensource@...> wrote:
Hot off the press!

Link to blog post of this here: https://communityblog.fedoraproject.org/important-changes-to-software-license-information-in-fedora-packages-spdx-and-more/

Thanks for the support on this from SPDX-legal. There is more work to come, for sure, but being able to use SPDX license identifiers in a full distro is a great challenge for our project to meet!

:)

Jilayne


-------- Forwarded Message --------
Subject: [Fedora-legal-list] Important changes to software license information in Fedora packages (SPDX and more!)
Date: Fri, 29 Jul 2022 11:19:48 -0400
From: Matthew Miller <mattdm@...>
Reply-To: legal@...
To: devel-announce@...
CC: packaging@..., legal@..., devel@...



On behalf of all of the folks working on Fedora licensing improvements,
I have a few things to announce!


New docs site for licensing and other legal topics
--------------------------------------------------

All documentation related to Fedora licensing has moved to a new
section in Fedora Docs, which you can find at:

https://docs.fedoraproject.org/en-US/legal/

Other legal documentation will follow. This follows the overall Fedora
goal of moving active user and contributor documentation away from the
wiki.


Fedora license information in a structured format
-------------------------------------------------

The “good” (allowed) and “bad” (not-allowed) licenses for Fedora are
now stored in a repository, using a simple structured file format for
each license (it’s TOML). You can find this at:
https://gitlab.com/fedora/legal/fedora-license-data

This data is then presented in easy tabular format in the
documentation, at:

https://docs.fedoraproject.org/en-US/legal/allowed-licenses/



New policy for the License field in packages — SPDX identifiers!
----------------------------------------------------------------

We’re changing the policy for the "License" field in package spec files
to use SPDX license identifiers. Historically, Fedora has represented
licenses using short abbreviations specific to Fedora. In the meantime,
SPDX license identifiers have emerged as a standard, and other
projects, vendors, and developers have started using them. Adopting
SPDX license identifiers provides greater accuracy as to what license
applies, and will make it easier for us to collaborate with other
projects.


Updated licensing policies and processes
----------------------------------------

Fedora licensing policies and processes have been updated to reflect
the above changes. In some cases, this forced deeper thought as to how
these things are decided and why, which led to various discussion on
Fedora mailing lists. In other cases, it prompted better articulation
of guidance that was implicitly understood but not necessarily
explicitly stated.


New guidance on “effective license” analysis
--------------------------------------------

Many software packages consist of code with different free and open
source licenses. Previous practice often involved “simplification” of
the package license field when the packager believed that one license
subsumed the other — for example, using just “GPL” when the source code
includes parts licensed under a BSD-style license as well. Going
forward, packagers and reviewers should not make this kind of analysis,
and rather use (for example) “GPL-2.0-or-later AND MIT”. This approach
is easier for packagers to apply in a consistent way.


When do these changes take effect?
----------------------------------

The resulting changes in practice will be applied to new packages and
licenses going forward. It is not necessary to revise existing packages
at this time, although we have provided some guidance for package
maintainers who want to get started. We’re in the process of planning a
path for updating existing packages at a larger scale — stay tuned for
more on that!


Thank you everyone!
-------------------

A huge thanks to some key people who have worked tirelessly to make
this happen: David Cantrell, Richard Fontana, Jilayne Lovejoy, Miroslav
Suchý. Behind the scenes support was also provided by David Levine,
Bryan Sutula, and Beatriz Couto. Thank you as well for the valuable
feedback from Fedora community members in various Fedora forums.

Please have a look at the updated information. If you have questions,
please post them to the Fedora Legal mailing list:

https://lists.fedoraproject.org/archives/list/legal@.../



-- 
Matthew Miller
<mattdm@...>
Fedora Project Leader
_______________________________________________
legal mailing list -- legal@...
To unsubscribe send an email to legal-leave@...
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/legal@...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure


Important changes to software license information in Fedora packages (SPDX and more!)

J Lovejoy
 

Hot off the press!

Link to blog post of this here: https://communityblog.fedoraproject.org/important-changes-to-software-license-information-in-fedora-packages-spdx-and-more/

Thanks for the support on this from SPDX-legal. There is more work to come, for sure, but being able to use SPDX license identifiers in a full distro is a great challenge for our project to meet!

:)

Jilayne


-------- Forwarded Message --------
Subject: [Fedora-legal-list] Important changes to software license information in Fedora packages (SPDX and more!)
Date: Fri, 29 Jul 2022 11:19:48 -0400
From: Matthew Miller <mattdm@...>
Reply-To: legal@...
To: devel-announce@...
CC: packaging@..., legal@..., devel@...



On behalf of all of the folks working on Fedora licensing improvements,
I have a few things to announce!


New docs site for licensing and other legal topics
--------------------------------------------------

All documentation related to Fedora licensing has moved to a new
section in Fedora Docs, which you can find at:

https://docs.fedoraproject.org/en-US/legal/

Other legal documentation will follow. This follows the overall Fedora
goal of moving active user and contributor documentation away from the
wiki.


Fedora license information in a structured format
-------------------------------------------------

The “good” (allowed) and “bad” (not-allowed) licenses for Fedora are
now stored in a repository, using a simple structured file format for
each license (it’s TOML). You can find this at:
https://gitlab.com/fedora/legal/fedora-license-data

This data is then presented in easy tabular format in the
documentation, at:

https://docs.fedoraproject.org/en-US/legal/allowed-licenses/



New policy for the License field in packages — SPDX identifiers!
----------------------------------------------------------------

We’re changing the policy for the "License" field in package spec files
to use SPDX license identifiers. Historically, Fedora has represented
licenses using short abbreviations specific to Fedora. In the meantime,
SPDX license identifiers have emerged as a standard, and other
projects, vendors, and developers have started using them. Adopting
SPDX license identifiers provides greater accuracy as to what license
applies, and will make it easier for us to collaborate with other
projects.


Updated licensing policies and processes
----------------------------------------

Fedora licensing policies and processes have been updated to reflect
the above changes. In some cases, this forced deeper thought as to how
these things are decided and why, which led to various discussion on
Fedora mailing lists. In other cases, it prompted better articulation
of guidance that was implicitly understood but not necessarily
explicitly stated.


New guidance on “effective license” analysis
--------------------------------------------

Many software packages consist of code with different free and open
source licenses. Previous practice often involved “simplification” of
the package license field when the packager believed that one license
subsumed the other — for example, using just “GPL” when the source code
includes parts licensed under a BSD-style license as well. Going
forward, packagers and reviewers should not make this kind of analysis,
and rather use (for example) “GPL-2.0-or-later AND MIT”. This approach
is easier for packagers to apply in a consistent way.


When do these changes take effect?
----------------------------------

The resulting changes in practice will be applied to new packages and
licenses going forward. It is not necessary to revise existing packages
at this time, although we have provided some guidance for package
maintainers who want to get started. We’re in the process of planning a
path for updating existing packages at a larger scale — stay tuned for
more on that!


Thank you everyone!
-------------------

A huge thanks to some key people who have worked tirelessly to make
this happen: David Cantrell, Richard Fontana, Jilayne Lovejoy, Miroslav
Suchý. Behind the scenes support was also provided by David Levine,
Bryan Sutula, and Beatriz Couto. Thank you as well for the valuable
feedback from Fedora community members in various Fedora forums.

Please have a look at the updated information. If you have questions,
please post them to the Fedora Legal mailing list:

https://lists.fedoraproject.org/archives/list/legal@.../



-- 
Matthew Miller
<mattdm@...>
Fedora Project Leader
_______________________________________________
legal mailing list -- legal@...
To unsubscribe send an email to legal-leave@...
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/legal@...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

1 - 20 of 1591