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

 

·          

·          

·          

·          

·          

·          

·          

·          

 


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


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