spdx@lists.spdx.org

Home Messages Hashtags Subgroups

Export Group Data

Between

and

Re: SPDX Governance Next Steps Richard Purdie #1427 On Wed, 2021-08-25 at 20:09 +0000, Phil Odence via lists.spdx.org wrote: SPDX Community, As previewed in the June General Meeting, the Core Team has submitted a proposal for changing the governance of SPDX. The reasoning for the change and substance are the same as what we discussed in that meeting. However, we have simplified the implementation considerably. Importantly, the project will continue to operate day to day as we have for over a decade but with better defined governance. Attached is a document that summarizes the proposal and provide links to the details. In the second half of next Thursday’s General Meeting we will try to reach consensus on the proposal. In the meantime, once you have studied the matter, provide feedback or raise any questions on this thread. (Note, the many of the details are housed in a GitHub repo but again comments/questions go here.) If we do not reach consensus on Thursday, we may hold the discussion over to the following meeting. FWIW I've been wondering how we could show a relationship between Yocto Project and SPDX as we are a strong support of it so this looks timely in that regard assuming we'd be eligible as an associate member? Cheers, Richard
More All Messages By This Member
SPDX Governance Next Steps Phil Odence #1426 SPDX Community, As previewed in the June General Meeting, the Core Team has submitted a proposal for changing the governance of SPDX. The reasoning for the change and substance are the same as what we discussed in that meeting. However, we have simplified the implementation considerably. Importantly, the project will continue to operate day to day as we have for over a decade but with better defined governance. Attached is a document that summarizes the proposal and provide links to the details. In the second half of next Thursday’s General Meeting we will try to reach consensus on the proposal. In the meantime, once you have studied the matter, provide feedback or raise any questions on this thread. (Note, the many of the details are housed in a GitHub repo but again comments/questions go here.) If we do not reach consensus on Thursday, we may hold the discussion over to the following meeting. Best regards, 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 PDF 2021-08 SPDX Governance Change Proposal.pdf
More All Messages By This Member
SPDX DocFest - Sept 16, 2021 - Call for Participation Gary O'Neall #1425 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)
More All Messages By This Member
Thursday's SPDX General Meeting/ Google Summer of Code Presentations Phil Odence #1424 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
More All Messages By This Member
[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 Shane Coughlan #1423 We are covering SBOMs today, so perhaps of interest :) Begin forwarded message: From: "Shane Coughlan via lists.openchainproject.org" <scoughlan=linuxfoundation.org@...> 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
More All Messages By This Member
Re: Question on two MIT-derivatives Christian Ehrhardt #1422 On Fri, Jul 9, 2021 at 11:07 AM Philippe Ombredanne <pombredanne@...> wrote: Hi Christian: On Thu, Jul 8, 2021 at 11:27 PM Christian Ehrhardt <christian.ehrhardt@...> 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@... 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
More All Messages By This Member
Re: Question on two MIT-derivatives Alexios Zavras #1421 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@.... 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 toggle quoted messageShow quoted text -----Original Message----- From: spdx@... <spdx@...> On Behalf Of Christian Ehrhardt Sent: Wednesday, 7 July, 2021 09:48 To: spdx@... 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
More All Messages By This Member
Re: Question on two MIT-derivatives Philippe Ombredanne #1420 Hi Christian: On Thu, Jul 8, 2021 at 11:27 PM Christian Ehrhardt <christian.ehrhardt@...> 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@... 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
More All Messages By This Member
Question on two MIT-derivatives Christian Ehrhardt #1419 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
More All Messages By This Member
July Meeting Minutes Phil Odence #1418 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] 1 SPDX Governance - Phil 2 Outreach Team Report - Sebastian/Jack 3 Legal Team Report - Jilayne/Paul/Steve 4 Tech Team Report - Kate/Gary/Others 5 Other Topics 6 Attendees 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
More All Messages By This Member
July Meeting Minutes Phil Odence #1417
More All Messages By This Member
Thursday's SPDX General Meeting reminder Phil Odence #1416 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
More All Messages By This Member
Re: [spdx-tech] Should SPDX endorse SCA tools? Kate Stewart #1415 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 toggle quoted messageShow quoted text 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
More All Messages By This Member
Re: SPDX June General Meeting Minutes Steve Winslow #1414 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 toggle quoted messageShow quoted text 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 swinslow@...
More All Messages By This Member
The SPDX chatroom is now on Libera.Chat; please feel free to join! Sebastian Crane #1413 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
More All Messages By This Member
Re: SPDX June General Meeting Minutes Philippe Ombredanne #1412 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
More All Messages By This Member
SPDX June General Meeting Minutes Phil Odence #1411 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] 1 SPDX Governance Review - Phil 2 Tech Team Report - Kate/Gary/Others 3 Legal Team Report - Jilayne/Paul/Steve 4 Outreach Team Report - Kate 5 Other Topics 6 Attendees 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 · · · · · · · ·
More All Messages By This Member
SPDX General Meeting Phil Odence #1410 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 Calendar
More All Messages By This Member
Canceled: SPDX General Meeting Phil Odence #1409 I will be sending out a replacement invite in a few hours. Please clear your calendar. Thanks, Phil Calendar
More All Messages By This Member
Thursday's SPDX General Meeting reminder Phil Odence #1408 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
More All Messages By This Member