SPDX June General Meeting Minutes
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
·
·
·
·
·
·
·
·
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
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