Date   

SPDX DocFest - Sept 16, 2021 - Call for Participation

Gary O'Neall
 

As a follow-up to this morning SPDX general meeting, below is the information on the upcoming SPDX DocFest:

 

The SPDX project will be hosting an initial working "DocFest" to bring together the producers of SPDX documents and walk through the differences between tools for the same artifacts.   Artifacts included in the DocFest will include sources, build assembly, containers, and executable images that can be analyzed. 


The goals of this DocFest are to:
1) come to agreement on how the fields should be populated for a given artifact
2) identify instances where different use cases might lead to different choices for fields and structures of documents
3) assess how well the NTIA SBOM minimum elements are covered
4) create a set of reference SPDX SBOMs as part of the corpus for further tooling evaluation.

This event will require "sweat equity" - participants are expected to have generated at least one SPDX document from the target set (either source, built from source, built image or container equivalent). Those who have signed up and have submitted files by September 3, 2021, will receive a meeting invite to the DocFest.

To indicate interest to participate, please fill in the following form:
https://forms.gle/gEfBZfaNmPXUJ6Xg7

Further details on how to participate will be mailed to those that have filled in the form on August 6, 2021.

Thanks,
DocFest Organizers   (Rose, Gary, Kate)


Thursday's SPDX General Meeting/ Google Summer of Code Presentations

Phil Odence
 

This week’s meeting with feature two GSoC presentations. Note I have a conflict so Gary will host.

 

PLEASE: When you sign in, please include your name and company (or put them in the chat) to facilitate logging attendance. With relatively heavy attendance these days is the trickiest bit of running the meeting.

 

Presentations

 

                New License Matching Library

During my presentation, I will show a demo of a new license matching library, followed by a short talk on implementation summary. In the latter part, I would like to talk about the difficulties and issues I faced.Since my final goal is to deliver something we can call a reference implementation of SPDX license matching, I want to hear your feedback and improve the library from them!

I am Mikihito Matsuura (@m1kit), a master course student at the University of Tokyo.

I was looking for an interesting GSoC project this March. During project hunting, I saw an open-source organization looking for a good license matching library. Later I realized SPDX is also recruiting a GSoC student and contacted people here a few days before the deadline. I'm excited to be able to work with this community as a part of GSoC despite the late contact!

 

Validate and Generate multiple representations of specifications

This project is related to the tooling of SPDX specification, specification which is being collaboratively produced. The aim of this project is to build a program that can be used to validate and convert Structured input to the pretty markdowns for documentation purposes and also generate Specification Representation. The end goal of this project is to make it run as Github action for the SPDX specification.
Hey all, I am Nirmal Suthar, a final year undergraduate student, studying at IIT Kanpur, India. 

This is my second time participating in GSoC and working under open-source organization is always filled with a lot of learning.

 

 

GENERAL MEETING

 

Meeting Time: Thurs, Aug 5, 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

 

 

Administrative Agenda

Attendance

Minutes Approval https://wiki.spdx.org/view/General_Meeting/Minutes/2021-07-01

 

Technical Team Report – Kate/Gary/Others

  • Specification and Profiles

 

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 

  

 

 

 


[openchain] OpenChain Third Monday Webinar - 2021-06-21 - 14:00 UTC / 07:00 PST / 15:00 BST / 16:00 CEST / 19:30 IST / 22:00 CST / 23:00 KST / 23:00 JST: SBOM Challenges in Unstructured Projects + Case Study: Readiness Assessment for OpenChain ISO 5230

 

We are covering SBOMs today, so perhaps of interest :)

Begin forwarded message:

Subject: [openchain] OpenChain Third Monday Webinar - 2021-06-21 - 14:00 UTC / 07:00 PST / 15:00 BST / 16:00 CEST / 19:30 IST / 22:00 CST / 23:00 KST / 23:00 JST: SBOM Challenges in Unstructured Projects + Case Study: Readiness Assessment for OpenChain ISO 5230
Date: July 19, 2021 9:22:40 JST
To: OpenChain Main <main@...>
Cc: OpenChain Germany <germany-wg@...>, OpenChain UK <uk-wg@...>, OpenChain India <india-wg@...>, OpenChain Automotive <openchain-automotive-work-group@groups.io>, OpenChain Partners <partners@...>, OpenChain Tooling <oss-based-compliance-tooling@groups.io>
Reply-To: main@...

We have two featured speakers today.

SBOM Challenges in Unstructured Projects
Jan Thielscher from EACG

Case Study: Readiness Assessment for OpenChain ISO 5230
Marcel Scholze from PwC

All welcome. No registration.
https://zoom.us/j/4377592799

Meeting ID: 437 759 2799
One tap mobile
+13017158592,,4377592799# US (Washington DC)
+13126266799,,4377592799# US (Chicago)

Dial by your location
       +1 301 715 8592 US (Washington DC)
       +1 312 626 6799 US (Chicago)
       +1 346 248 7799 US (Houston)
       +1 646 558 8656 US (New York)
       +1 669 900 6833 US (San Jose)
       +1 253 215 8782 US (Tacoma)
       877 369 0926 US Toll-free
       855 880 1246 US Toll-free
       +1 438 809 7799 Canada
       +1 587 328 1099 Canada
       +1 647 374 4685 Canada
       +1 647 558 0588 Canada
       +1 778 907 2071 Canada
       +1 204 272 7920 Canada
       855 703 8985 Canada Toll-free
Meeting ID: 437 759 2799
Find your local number: https://zoom.us/u/awFnORNiA



Want to confirm your timezone?
2021-06-21 - 14:00 UTC / 07:00 PST / 15:00 BST / 16:00 CEST / 19:30 IST / 22:00 CST / 23:00 KST / 23:00 JST






Re: Question on two MIT-derivatives

Christian Ehrhardt
 

On Fri, Jul 9, 2021 at 11:07 AM Philippe Ombredanne
<pombredanne@nexb.com> wrote:

Hi Christian:

On Thu, Jul 8, 2021 at 11:27 PM Christian Ehrhardt
<christian.ehrhardt@canonical.com> wrote:

Hi SPDX,
I was refreshing the license info on a Debian package and found two
licenses that seemed to be MIT-variants that I wasn't sure about. The
reason I looked at it was mostly technical as the current way to
identify them was triggering a lintian warning, but as I said I
wondered what would be correct.

I was not finding the two derivatives in your license list at [1] nor
as an exception in [2].
There are already a bunch of MIT-* identifiers, but none matched the
two that I had.
So I had no "official identifiers" to use and just came up with two for now.

I changed the identifiers like
- MIT(*) -> MIT-ibm
- MIT(**) -> MIT-no-ad
and that satisfies Lintian at least.
The full text of those can be found at [3][4].

I'm full of questions:
- having a look at them, would you think they should be added to your
list and get assigned official identifiers?
- Are these even licenses on their own that deserve an ID?
- Would it need the project or License owner to do such a request?
- I'm neither of that and just looked at it by accident - If needed
I'd be ok to file an issue as outlined in [5] and discuss, but I'm not
sure I could do much more on it.

[1]:https://spdx.org/licenses/
[2]: https://spdx.org/licenses/exceptions-index.html
[3]: https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/lib/misc/base64.c#L4
[4]: https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/services/plugins/resolutionSet/libvmwarectrl.h#L4
[5]: https://github.com/spdx/license-list-XML/blob/master/DOCS/license-inclusion-principles.md

I ran scancode-toolkit and the license in base64.c [1] is identified
as an ISC alright. The only (IMHO not material) change is the sentence
"modify, and distribute" with a plain "and" instead of "modify, and/or
distribute" with "and/or". The relevant ISC variant that was detected
is at [2]. The author "INTERNET SOFTWARE CONSORTIUM" is different but
this is within matching guidelines and

Note that the second license in this file is not tracked by SPDX for
now and is detected as "ibm-dhcp" or SPDX LicenseRef-scancode-ibm-dhcp
[3]

In the file libvmwarectrl.h [4] scancode detects another license which
is not yet tracked by SPDX and that we call "xfree86-1.0" or SPDX
LicenseRef-scancode-xfree86-1.0 [5] which is the name used where we
found it [6]

/hth
You really did help, thanks for the pointers and license disambiguation!
I think with that in place there is no further need to fix (in
project) or track (SPDX) them in more detail.

Thanks!

[1]: https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/lib/misc/base64.c#L4
[2]: https://github.com/nexB/scancode-toolkit/blob/3f7da81d6b207ac2b1d384defb83a5f2c82216f4/src/licensedcode/data/rules/isc_9.RULE
[3]: https://scancode-licensedb.aboutcode.org/ibm-dhcp
[4]: https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/services/plugins/resolutionSet/libvmwarectrl.h#L4
[5]: https://scancode-licensedb.aboutcode.org/xfree86-1.0
[6]: http://www.xfree86.org/current/LICENSE5.html#18
[7]: https://github.com/nexB/scancode-toolkit/blob/develop/src/packagedcode/debian_copyright.py
--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombredanne@nexB.com
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com





--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd


Re: Question on two MIT-derivatives

Alexios Zavras
 

Hi Christian,

Thanks for reaching to the SPDX project!

As this has purely to do with licenses, it may be better addressed to the legal working group at spdx-legal@lists.spdx.org.

Alternatively, feel free to raise your questions as issues on the license list GitHub repo, if you prefer: https://github.com/spdx/license-list-XML

-- zvr

-----Original Message-----
From: spdx@lists.spdx.org <spdx@lists.spdx.org> On Behalf Of Christian Ehrhardt
Sent: Wednesday, 7 July, 2021 09:48
To: spdx@lists.spdx.org
Subject: [spdx] Question on two MIT-derivatives

Hi SPDX,
I was refreshing the license info on a Debian package and found two licenses that seemed to be MIT-variants that I wasn't sure about. The reason I looked at it was mostly technical as the current way to identify them was triggering a lintian warning, but as I said I wondered what would be correct.

I was not finding the two derivatives in your license list at [1] nor as an exception in [2].
There are already a bunch of MIT-* identifiers, but none matched the two that I had.
So I had no "official identifiers" to use and just came up with two for now.

I changed the identifiers like
- MIT(*) -> MIT-ibm
- MIT(**) -> MIT-no-ad
and that satisfies Lintian at least.
The full text of those can be found at [3][4].

I'm full of questions:
- having a look at them, would you think they should be added to your list and get assigned official identifiers?
- Are these even licenses on their own that deserve an ID?
- Would it need the project or License owner to do such a request?
- I'm neither of that and just looked at it by accident - If needed I'd be ok to file an issue as outlined in [5] and discuss, but I'm not sure I could do much more on it.

[1]:https://spdx.org/licenses/
[2]: https://spdx.org/licenses/exceptions-index.html
[3]: https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/lib/misc/base64.c#L4
[4]: https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/services/plugins/resolutionSet/libvmwarectrl.h#L4
[5]: https://github.com/spdx/license-list-XML/blob/master/DOCS/license-inclusion-principles.md

--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd





Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928


Re: Question on two MIT-derivatives

Philippe Ombredanne
 

Hi Christian:

On Thu, Jul 8, 2021 at 11:27 PM Christian Ehrhardt
<christian.ehrhardt@canonical.com> wrote:

Hi SPDX,
I was refreshing the license info on a Debian package and found two
licenses that seemed to be MIT-variants that I wasn't sure about. The
reason I looked at it was mostly technical as the current way to
identify them was triggering a lintian warning, but as I said I
wondered what would be correct.

I was not finding the two derivatives in your license list at [1] nor
as an exception in [2].
There are already a bunch of MIT-* identifiers, but none matched the
two that I had.
So I had no "official identifiers" to use and just came up with two for now.

I changed the identifiers like
- MIT(*) -> MIT-ibm
- MIT(**) -> MIT-no-ad
and that satisfies Lintian at least.
The full text of those can be found at [3][4].

I'm full of questions:
- having a look at them, would you think they should be added to your
list and get assigned official identifiers?
- Are these even licenses on their own that deserve an ID?
- Would it need the project or License owner to do such a request?
- I'm neither of that and just looked at it by accident - If needed
I'd be ok to file an issue as outlined in [5] and discuss, but I'm not
sure I could do much more on it.

[1]:https://spdx.org/licenses/
[2]: https://spdx.org/licenses/exceptions-index.html
[3]: https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/lib/misc/base64.c#L4
[4]: https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/services/plugins/resolutionSet/libvmwarectrl.h#L4
[5]: https://github.com/spdx/license-list-XML/blob/master/DOCS/license-inclusion-principles.md

I ran scancode-toolkit and the license in base64.c [1] is identified
as an ISC alright. The only (IMHO not material) change is the sentence
"modify, and distribute" with a plain "and" instead of "modify, and/or
distribute" with "and/or". The relevant ISC variant that was detected
is at [2]. The author "INTERNET SOFTWARE CONSORTIUM" is different but
this is within matching guidelines and

Note that the second license in this file is not tracked by SPDX for
now and is detected as "ibm-dhcp" or SPDX LicenseRef-scancode-ibm-dhcp
[3]

In the file libvmwarectrl.h [4] scancode detects another license which
is not yet tracked by SPDX and that we call "xfree86-1.0" or SPDX
LicenseRef-scancode-xfree86-1.0 [5] which is the name used where we
found it [6]

/hth

[1]: https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/lib/misc/base64.c#L4
[2]: https://github.com/nexB/scancode-toolkit/blob/3f7da81d6b207ac2b1d384defb83a5f2c82216f4/src/licensedcode/data/rules/isc_9.RULE
[3]: https://scancode-licensedb.aboutcode.org/ibm-dhcp
[4]: https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/services/plugins/resolutionSet/libvmwarectrl.h#L4
[5]: https://scancode-licensedb.aboutcode.org/xfree86-1.0
[6]: http://www.xfree86.org/current/LICENSE5.html#18
[7]: https://github.com/nexB/scancode-toolkit/blob/develop/src/packagedcode/debian_copyright.py
--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombredanne@nexB.com
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com


Question on two MIT-derivatives

Christian Ehrhardt
 

Hi SPDX,
I was refreshing the license info on a Debian package and found two
licenses that seemed to be MIT-variants that I wasn't sure about. The
reason I looked at it was mostly technical as the current way to
identify them was triggering a lintian warning, but as I said I
wondered what would be correct.

I was not finding the two derivatives in your license list at [1] nor
as an exception in [2].
There are already a bunch of MIT-* identifiers, but none matched the
two that I had.
So I had no "official identifiers" to use and just came up with two for now.

I changed the identifiers like
- MIT(*) -> MIT-ibm
- MIT(**) -> MIT-no-ad
and that satisfies Lintian at least.
The full text of those can be found at [3][4].

I'm full of questions:
- having a look at them, would you think they should be added to your
list and get assigned official identifiers?
- Are these even licenses on their own that deserve an ID?
- Would it need the project or License owner to do such a request?
- I'm neither of that and just looked at it by accident - If needed
I'd be ok to file an issue as outlined in [5] and discuss, but I'm not
sure I could do much more on it.

[1]:https://spdx.org/licenses/
[2]: https://spdx.org/licenses/exceptions-index.html
[3]: https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/lib/misc/base64.c#L4
[4]: https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/services/plugins/resolutionSet/libvmwarectrl.h#L4
[5]: https://github.com/spdx/license-list-XML/blob/master/DOCS/license-inclusion-principles.md

--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd


July Meeting Minutes

Phil Odence
 

Whoops!

https://wiki.spdx.org/view/General_Meeting/Minutes/2021-07-01

 

There were several attendees who’s organizations I don’t know. Please let me know and I will amend. Thanks.

 

Phil

 

General Meeting/Minutes/2021-07-01

General Meeting‎ | Minutes

·         Attendance: 22

·         Lead by Phil Odence

·         Minutes of June meeting Approved

 

Contents

 [hide

SPDX Governance - Phil[edit]

Status of governance changes

·         Still working through a using the prepackaged JDF docs with LF lawyers

·         Lots there due to general nature

·         It will have to go through the specified process for discussion and voting

·         Why?

·         More scrutiny

·         Standards requirement- Companies supporting, logos

·         OMG CISQ 3T joining SPDX

·         ISO direction – Need more

·         Executive Order

·         Working with other standards, i.e. SWID and CycloneDX

 * Specific concerns that came up

·          

·         Community Spec License vs. CCBY

·         Patent license to address concerns that have arisen from companies we want to support

·         Also, tangentially related SBOM gen tool showed up in repo

·         Need criteria for including

·         A question came up about discussion of governance on the Gen Mailing list

·         We try to limit traffic on the list so one can use to monitor activity without being overwhelmed

·         There will be a chance for discussion of a governance proposal once process goes in motion

·         Contact Phil with inputs

·         We’ll look into a separate list

Outreach Team Report - Sebastian/Jack[edit]

 

·         Rebooted

·         SPDX website rework - license for content CC-BY-4.0

·         Looking to rebuild website as static site.

·         Code and license - more flex over precise styling and functionality.

·         Prototype of site in next few weeks.

·         Technical slides - present about SPDX in own organizations.

·         Reviewed collateral,  audience focus for collateral that will meet audience needs.

·         More explanation of “why”.   Point to specification when get to details. 

·         IRC channel 

·         Sebastian set up #spdx on libera.chat

·         previous channels on OFTC, Freenode; hadn’t taken off

·         libera.chat has 11 people in it currently

·         “cloaking” - hides IP address in some cases, replaces with badge for organization you’re associated with; Sebastian can provide “SPDX cloak”

·         Matrix bridge - feature of libera.chat, enables joining via Matrix

·         Meeting date and time: 1500 UTC on Wednesdays will be new meeting time, on 14th of July

 

Legal Team Report - Jilayne/Paul/Steve[edit]

 

·         Several new folks participating

·         Ariel and Candice from ClearlyDefined have been digging into the Python stack of licenses

·         License List 3.14 release - targeting end of July

 

Tech Team Report - Kate/Gary/Others[edit]

 

·         Tools 

·         GSoC - JSON support in Golang; will seek to get GSoC student to present at a future General Meeting

·         New participants interacting with tools, and seeing pull requests.

·         NTIA Plugfest 

·         new tools emerging from communities 

·         SPDX was most common format in use

·         Can’t get down to SPDX field to field 

·         SPDX Plugfest?

·         Desire to have Japan SPDX Plugfest

·         One for north america   

·         Anchore has a tool supporting SPDX output if you need more 3.0 examples we can on it. (github.com/anchore/syft). We have 2.2 now but can fairly quickly iterate for some 3.0 support.

·         Specification

·         ISO/IEC PRF 5962 - Information Technology — SPDX® Specification V2.2.1- moved to PRF status Publication date : 2021-08

·         OCI registry overview and how SPDX could interact with containers. 

·         Specification 3.0 Work 

·         Looking for more 3.0 examples in serialization

·         Lacking critical mass for some decisions - vacations

·         Moving through punch list on core model.

·         Vulnerability - waiting for core.   Snyk put up a nice post.   

·         Feedback in progress.   

·         Serialization needs to become clearer.

·         More examples are needed. 

·         Follow up VEX and CSAF

·         Licensing profile - pretty similar to 2.2 already.

·         Once formatting for how template can be expressed.

 

Other Topics[edit]

·         Open Question - why spdx.dev vs. spdx.org;   license list dynamically generated spdx.org - Drupal → Wordpress.   How to keep License list still populate to website.

·         Keep license list URL stable. 

·         Wikipedia page on SPDX is pretty stale.    

·         Needs to be updated.    Outreach will take it. 

Attendees[edit]

·         Phil Odence, Black Duck/Synopsys

·         Philippe Emmanuel Douziech, CAST

·         Bob Martin, Mitre

·         Joshua Marpet, RM-ISAO

·         David Edelsohn, IBM

·         Sebastian Crane

·         Marc Etienne Vargenau, Nokia

·         Zach Hill, Anchore

·         Steve Winslow, LF

·         Kate Stewart, Linux Foundation

·         William Cox, Synopsys

·         Jack Manbeck, TI

·         Alexios Zavras, Intel

·         Warner Losh, FreeBSD

·         Alfredo Espinosa

·         Jilayne Lovejoy, Red Hat

·         Chris Lusk

·         Andrew Jorganson, AWS

·         Thomas Steenbergen, HERE

·         Ronda,

·         Brian Fox, Sonotype

·         Michael Herzog- nexB

 

 

 


July Meeting Minutes

Phil Odence
 

 

 

 


Thursday's SPDX General Meeting reminder

Phil Odence
 

You should by this time have a new recurring meeting invite on your calendar with the Jitsi.

 

PLEASE: When you sign in, please include your name and company (or put them in the chat) to facilitate logging attendance. With relatively heavy attendance these days is the trickiest bit of running the meeting.

 

 

GENERAL MEETING

 

Meeting Time: Thurs, July 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



 

Administrative Agenda

Attendance

Minutes Approval https://wiki.spdx.org/view/General_Meeting/Minutes/2021-06-03 

 

Technical Team Report – Kate/Gary/Others

  • Specification and Profiles

 

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 

  

 

 

 


Re: [spdx-tech] Should SPDX endorse SCA tools?

Kate Stewart
 

We've got a lot of historical cruft in our SPDX repo as well.  Coming up with some criteria for inclusion & removal is overdue.

After we settle the 3.0 template issue,  you up for dedicating part of a call to sketch out the repository inclusion criteria?  Then we'll do an assessment/clean up pass. 

Thanks, 
Kate


On Tue, Jun 29, 2021 at 1:29 PM Thomas Steenbergen <opensource@...> wrote:

Hi,

 

Continuing the discussion in today’s SPDX Tech call here on “Should SPDX endorse SCA tools?” - so other people in the SPDX community get the opportunity to share their opinion.

 

Following  Software Bill of Materials (SBOM) Industry Standard, Research, Training, and Tools to Improve Cybersecurity Practices announcement, I got the feedback form within my network asking me about the “official” SPDX SCA* tool (spdx-sbom-generator) – some project/technical question and remarks about the quality of the SBOM it produces.

 

I then realized that as spdx-sbom-generator is hosted on spdx GitHub org one can see it as an endorsement from SPDX. In OpenChain community, who also develops it specification, a deliberate choice was made to not endorse any tools as I was told a specification should be tooling neutral to facilitate broad adoption and healthy tooling ecosystem supporting the specification.

 

I think it may be a good idea for SPDX to do the same, as it’s possible to validate a SPDX SBOM per the specification but we cannot easily validate if SBOM is actually a good representation of reality.

Most build tools are meant to build code and do not to produce an SBOM.  As a result, SCA tools on the market generally do a best effort approach and thereby miss OSS or get OSS license or metadata wrong.

 

Let me know what you think.

 

* SCA = Software Composition Analysis

 

Regards,

 

Thomas Steenbergen

 

 

 

 

 

 

 


Re: SPDX June General Meeting Minutes

Steve Winslow
 

Hi Philippe,

Thanks for your comments and thoughts on this. I know this was a couple of weeks ago, but I had a few thoughts I wanted to share.

You're right that the Community Specification License is not an OSI-approved license, nor on the SPDX License List (though I'm expecting to submit it to the License List shortly). Whether or not SPDX adopts it for our project, I'm aware that several other collaborative specifications-development efforts are using or evaluating it.  E.g., FINOS (the Fintech Open Source Foundation) adopted it in April for all their new spec development efforts going forward, and I understand that other projects are currently considering it. So I don't think that proliferation is likely to be a concern here, as it is seeing uptake in any case.

I wouldn't expect OSI to consider or approve it for OSI approval, because it isn't a software license. It's particularly tailored to the unique issues around specifications. I'm not an author of the Community Specification License, but I think that it brings several advantages, primarily in the area of patent licenses.

For development of specifications, it's relevant to have not just copyright but also patent licenses. And, differently from software, for specifications the patent license that matters is one that covers implementations developed in accordance with the spec. Patent licenses in open source software licenses are naturally tied to that particular piece of software; but for specs, it would be important to have it extend to downstream implementations of the spec. That's why just switching to a FOSS software license with explicit patent commitments like Apache-2.0 wouldn't address this (whether with or without a DCO sign-off).

The Community Specification License includes an explicit patent license commitment for implementations of the spec. And, that patent license grant is for the spec as a whole -- not just what the contributor themself contributes. I won't get into all the specifics here, but I think this broad deactivation of patents among contributors within the spec's defined scope is a big benefit. It gives implementors of the spec greater comfort that they won't be subject to contributors' patent claims within that scope.

I'm putting together more detailed thoughts for the proposal that was described on the General Meeting, and expecting to share those with the community shortly. So I'll leave it there for now, but just wanted to share these thoughts as a preview. More to come soon.

Best,
Steve



On Fri, Jun 4, 2021 at 11:28 AM Philippe Ombredanne <pombredanne@...> wrote:
Dear Phil:
Thank you for these minutes! I want to comment on the spec license topic.

On Fri, Jun 4, 2021 at 3:16 PM Phil Odence via lists.spdx.org
<phil.odence=synopsys.com@...> wrote:

> The most significant change would be to change the license for the spec to the Community Specification License. This is a license purpose built for specifications. Like the existing CC license, it grants a broad copyright license to the spec itself. Additionally, requires contributors to grant licenses to any patents that might cover implementations of the spec. This would address user concerns about the possibility that an SPDX contributor seeking to enforce patents that they might hold that cover the spec.

The governance updates make change, but I cannot fathom the benefits
of switching the spec license to a reasonably new, unproven and
uncommon license that is neither OSI-approved, nor on the SPDX license
list and not even for consideration there at this stage.

If you have patents concerns, I would rather see these addressed by a
simple DCO signoff and an update of the project contribution policies.
This would put the omen to comply on contributors rather than putting
the burden on the users to have to deal with yet another license.

Additionally, it does not feel right if SPDX contributes to license
proliferation.

--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombredanne@...
DejaCode - What's in your code?! - http://www.dejacode.com
ScanCode - The S in SCA stands for ScanCode -
https://github.com/nexB/scancode-toolkit
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com







--
Steve Winslow
VP, Compliance and Legal
The Linux Foundation


The SPDX chatroom is now on Libera.Chat; please feel free to join!

Sebastian Crane
 

Dear all,

I bring good news: with the approval of the Libera.Chat staff, the #spdx
IRC channel is now registered! This should be a great place to help
introduce newcomers to the SPDX project, as well as to discuss Software
Bill of Materials-related topics with existing adopters and working
group members.

Philippe Ombredanne (pombreda) and I (seabass) are 'operators' of the
channel, thus able to change its settings if this is required.

If you are already familiar with IRC and have a client installed, you
can just join #spdx on irc.libera.chat.

As another option, you can join with Libera.Chat's web interface (no
need to enter a password) at: https://web.libera.chat/#spdx

Finally, you can join via your Matrix account. Our channel's Matrix
address is: #spdx:libera.chat

Of the three options above, only Matrix allows you to see chat history
from when you aren't connected, so this may be the best way to join if
you are already used to other instant messaging apps. However, you do
need to sign up for an account on a 'homeserver' - here's the flagship
homeserver: https://app.element.io/#/register

Please let me know if there's any trouble in joining the channel with
any of the methods above; I'll do my best to help you get connected :)
Looking forward to chatting with you on #spdx!

Best wishes,

Sebastian Crane


Re: SPDX June General Meeting Minutes

Philippe Ombredanne
 

Dear Phil:
Thank you for these minutes! I want to comment on the spec license topic.

On Fri, Jun 4, 2021 at 3:16 PM Phil Odence via lists.spdx.org
<phil.odence=synopsys.com@lists.spdx.org> wrote:

The most significant change would be to change the license for the spec to the Community Specification License. This is a license purpose built for specifications. Like the existing CC license, it grants a broad copyright license to the spec itself. Additionally, requires contributors to grant licenses to any patents that might cover implementations of the spec. This would address user concerns about the possibility that an SPDX contributor seeking to enforce patents that they might hold that cover the spec.
The governance updates make change, but I cannot fathom the benefits
of switching the spec license to a reasonably new, unproven and
uncommon license that is neither OSI-approved, nor on the SPDX license
list and not even for consideration there at this stage.

If you have patents concerns, I would rather see these addressed by a
simple DCO signoff and an update of the project contribution policies.
This would put the omen to comply on contributors rather than putting
the burden on the users to have to deal with yet another license.

Additionally, it does not feel right if SPDX contributes to license
proliferation.

--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombredanne@nexB.com
DejaCode - What's in your code?! - http://www.dejacode.com
ScanCode - The S in SCA stands for ScanCode -
https://github.com/nexB/scancode-toolkit
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com


SPDX June General Meeting Minutes

Phil Odence
 

We’ve had some new players joining. The minutes log names and companies. I didn’t get everyone’s company and there were a couple of phone numbers displayed; it wasn’t clear if those logged in as well or folks I missed. Please look the list (bottom of the page) over and add or correct. And for future meetings, if possible, log in with your name. THANKS.

 

https://wiki.spdx.org/view/General_Meeting/Minutes/2021-06-03

 

General Meeting/Minutes/2021-06-03

General Meeting‎ | Minutes

·         Attendance: 17

·         Lead by Phil Odence

·         Minutes of May meeting Approved

 

Contents

 [hide

SPDX Governance Review - Phil[edit]

·         Background: About 8 years ago, we put in place a governance structure for SPDX. It was a good effort at the time and has served us, but it’s never really been stressed. Factors are in play today that suggest the need for a legally tighter structure:

·         OMG CISQ 3T joining SPDX

·         ISO direction

·         Executive Order

·         Working with other standards, i.e. SWID and CycloneDX

·         The Linux Foundation has a pre-packaged governance solution for standards bodies, call the Joint Development Foundation, a “consortium in a box,” as they refer to it. It’s a free, fast way to set up a highly configurable legal entity and structure designed for specification development. With support LF attorneys who have been involved in a number of such projects for the LF, the Core Team is exploring this option and it looks like it will suit our needs.

·         There are many ways to configure, and we are going down the path of the simplest possible configuration. Essentially, we can tailor the documents so as to continue to operate as we have. The most significant change would be to change the license for the spec to the Community Specification License. This is a license purpose built for specifications. Like the existing CC license, it grants a broad copyright license to the spec itself. Additionally, requires contributors to grant licenses to any patents that might cover implementations of the spec. This would address user concerns about the possibility that an SPDX contributor seeking to enforce patents that they might hold that cover the spec.

·         This is really to give you a heads up of something coming in the future. The current governance mechanism defines a mechanism and timetable for such a change that involves a formal announcement and a general meeting to try to reach consensus. That clock is not starting now; just want you to be aware that it’s coming.

Tech Team Report - Kate/Gary/Others[edit]

 

·         Tools - Gary

·         Python project is progressing

·         Exec Order will bring with is some funding for cleaning up tooling gaps

·         New project

·         Generating SBOM to work with CI/CD pipelines

·         Written in Go

·         Yocto keen to use

·         NTIA slugfest is upcoming

·         Spec – Kate

·         Work

·         Core:

·         William Bartholomew and others working to show initial serializations, migration issues

·         rough format using Markdown as source of truth

·         GSoC project to translate into schemas

·         Vulnerabilities:

·         Thomas has given initial presentation, gathering feedback, meetings to be called to discuss

·         Usage - Moving forward

·         Licensing – Steve:

·         in process, expect to have updated draft by end of July

·         major open piece is documenting / specifying the license expression model classes

·         Linkage – Nisha experimenting, looking at re: e.g. containers

·         Build – Bob, David Edelsohn

 

·         Sebastian: Meeting times – out of date, time incorrect for General Meeting

·         Sync to a particular time – Eastern US or UTC?

·         and just list that time on the wiki, with link to a time/date converter

·         Steve to sync with Phil to confirm on regular invite time

Legal Team Report - Jilayne/Paul/Steve[edit]

 

·         3.13 released in May

·         issue with version numbers for tagged releases

·         thank you to Gary for helping address this while on vacation

·         3.14 in process now, to be released end of July

 

Outreach Team Report - Kate[edit]

 

·         Next meeting June 7

·         Calendar invite at https://lists.spdx.org/g/Spdx-tech/message/4059

·         use this and not old info on the wiki

Other Topics[edit]

 

·         IRC channel for SPDX – Sebastian / Philippe

·         One channel on Freenode, another on OFTC; libera.chat also existing

·         Switching to libera.chat

·         Sebastian to register and share with general list

·         GSoC students also tend to use gitter.im (also accessible via IRC / Matrix)

·         channel name to be #spdx

·         After registered and shared with general list, will also add to website

 

Attendees[edit]

·         Phil Odence, Black Duck/Synopsys

·         Sebastian Crane

·         Steve Winslow, LF

·         Kate Stewart, Linux Foundation

·         William Cox, Synopsys

·         Marc Etienne Vargenau, Nokia

·         Mikihito Matsuura, Tokyo University

·         Bob Martin, Mitre

·         Philippe Emmanuel Douziech, CAST

·         Joshua Marpet, MGM Growth

·         Tiberius Hefflin, Intel

·         Jilayne Lovejoy, Red Hat

·         Warner Lost,

·         Aveek Basu, NextMark Printers

·         Sharon Burke,

·         Gary O’Neall, SourceAuditor

 

·          

·          

·          

·          

·          

·          

·          

·          

 


SPDX General Meeting

Phil Odence
 

Please accept this recurring invitation

 

 “Dial In” info:

 

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

 

Standard Agenda:

 

Administrative Agenda

Attendance

Minutes Approval https://wiki.spdx.org/view/General_Meeting/Minutes/2021-05-06

 

SPDX Governance Evolution – Phil/Steve

 

Technical Team Report – Kate/Gary/Others

  Tooling Update  - Gary

  Specification and Profiles 

  • Core - William
  • Legal - Steve
  • Vulnerabilities - Thomas
  • LInkage - Nisha
  • Usage and Other Emerging Profiles - Kate

 

 

Legal Team Report – Jilayne/Paul/Steve

 

Outreach/Website Team Report – Jack 

 


Canceled: SPDX General Meeting

Phil Odence
 

I will be sending out a replacement invite in a few hours. Please clear your calendar. Thanks, Phil


Thursday's SPDX General Meeting reminder

Phil Odence
 

Because we are moving to Jitsi for video conferencing and try to avoid confusion, I will delete the old invite, wait a few hours and then send out a new one with the new information.

 

To start the meeting, Steve and I will share some early thoughts about evolving the group’s legal structure in the face of the rising importance of SBOMs in general and SPDX specifically to many organizations. Expect this to be a preview and evolutionary, not revolutionary.

 

 

GENERAL MEETING

 

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


Conf call dial-in:

New dial in number: 415-881-1586

No PIN needed

The weblink for screenshare is changing 

 

Administrative Agenda

Attendance

Minutes Approval https://wiki.spdx.org/view/General_Meeting/Minutes/2021-05-06

 

SPDX Governance Evolution – Phil/Steve

 

Technical Team Report – Kate/Gary/Others

  • Specification and Profiles

 

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 

  

 

 

 


Re: SBOM's going mainstream - Biden Cybersecurity EO

Phil Odence
 

I’m sure most of you are aware of the executive order by now. The draws attention to SPDX and the LF is keen to show the project in its best light. As such we are adding a page to the website to display logos of companies whose employees participate. Consider this a heads up; we’d love to get your company’s logo up. Instructions will be forthcoming on how to submit.

 

From: spdx@... <spdx@...> on behalf of Sebastian <seabass-labrax@...>
Date: Tuesday, May 18, 2021 at 1:57 PM
To: spdx@... <spdx@...>
Subject: Re: [spdx] SBOM's going mainstream - Biden Cybersecurity EO

Dear all,

During today's SPDX Technical Team meeting, the US Government's recent
Executive Order was a major point of discussion! Kate Stewart shared a
link to a blog post from the Linux Foundation regarding the news:

https://urldefense.com/v3/__https://linuxfoundation.org/en/blog/how-lf-communities-enable-security-measures-required-by-the-us-executive-order-on-cybersecurity/__;!!A4F2R9G_pg!P49KwL8ZQvN9ngQGdyp9LeHwUOLk_4PKkHwz_zn50tJpvNlsdEIH8qN-aSLELDgf6H8$

There is lots of useful background information and explanation in the
article which I imagine would be of interest to members of this list.

Best wishes,

Sebastian





Re: SBOM's going mainstream - Biden Cybersecurity EO

Sebastian Crane
 

Dear all,

During today's SPDX Technical Team meeting, the US Government's recent
Executive Order was a major point of discussion! Kate Stewart shared a
link to a blog post from the Linux Foundation regarding the news:

https://linuxfoundation.org/en/blog/how-lf-communities-enable-security-measures-required-by-the-us-executive-order-on-cybersecurity/

There is lots of useful background information and explanation in the
article which I imagine would be of interest to members of this list.

Best wishes,

Sebastian

61 - 80 of 1485