|
SPDX Sept General Meeting Minutes & Announcement
Phil Odence
SPDX Community,
Minutes: https://wiki.spdx.org/view/General_Meeting/Minutes/2021-09-02
As you are aware, in last week’s meeting we discussed a proposal to change the SPDX workgroup’s governance framework. The discussion was a good one and resulted in consensus. As things were rushed a bit at the end of the meeting and wanting to ensure no one was uncomfortable, we left the door open for concerns to be voiced “within a day or so” on this list. Subsequently there was a brief exchange on the list in support of the proposal as presented. And so, from this point forward, the SPDX is operating under the new framework.
For anyone who may have missed, a summary is attached. Additionally, here are links to the website that now specifies the newly adopted framework and a link directly to the repo that contains the details of the governance framework: · website: https://spdx.dev/about/governance/ · GitHub repo: https://github.com/spdx/governance/
Thanks to all who participated in the smooth transition to the new framework.
Best regards, Phil Chair, SPDX Steering Committee
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
General Meeting/Minutes/2021-09-02< General Meeting | Minutes · Attendance: 26 · Lead by Phil Odence · GSoC Presentation was postponed SPDX Governance - Phil[edit]· Intro -Phil · · GOAL of today: Consensus · · Background · About 8 years ago, we put in place a governance structure for SPDX. · Factors · ISO standardization- near to announcing · Executive Order · More participation from comm members with standards body experience · Working with other standards, i.e. SWID and CycloneDX · · Goal of Change - retain spirit and ways of working · more accurately reflect the current reality and future direction of the project · establishing a mechanism for official company membership in the project · using contribution processes and a license for the spec that ensure explicit patent license commitments from contributors · improving clarity around decision-making processes and establishing an appeals process · adopting a code of conduct · · Solution - Steve to explain further · Legal Entity creation- switched from JDF to a much simpler · Retained Community Specification model · Review of pdf Summary - Steave · Legal Entity · Membership Agreement · Community Specs process and license · Q&A/Discussion · Various clarifications · Code of Conduct · Agreed that under new structure it could, if need be, be modified in the future · Possibility of Dual-licensing Spec · Agreed to not address at this time · Resolution · Consensus reached · ...unless significant concerns were raised on the General Mailing List within a day of so of the meeting's close Attendees[edit]· Phil Odence, Black Duck/Synopsys · Sebastian Crane · Joshua Marpet, RM-ISAO · Mike Nemmers · William Cox, Synopsys · Andrew Jorgenson, AWS · Bob Martin, Mitre · Philippe Emmanuel Douziech, CAST · Alexios Zavras, Intel · Marc Etienne Vargenau, Nokia · Jilayne Lovejoy, Red Hat · Steve Winslow, LF · Mike Dolan, LF · Mark Atwood, Amazon · Gary O’Neall, SourceAuditor · Paul Madick, Jenzabar · Jeff Schutt, Cisco · Vicky Brasseur, Wipro · Warner Losh, FreeBSD · Zach Hill, Anchore · Pierre Tardy · David Edelsohn, IBM · Maximilian Huber, TNG · Bill Jaeger · Michael Mehlberg, Dark Sky Technology · Henk Birkholz, Fraunhofe
|
|
|
|
Re: SPDX Thursday General Meeting Reminder - SPECIAL MEETING
Phil Odence
Thanks, Sebastian for your thoughts, support and understanding.
Regarding licensing, my sense was that your desire to make the spec easy to publish is covered by the proposed licensing scheme. Perhaps you and Steve could discuss to resolve.
Regarding the Code of Conduct. I think we’ve forked it from the upstream with which you are concerned and, in any case, the option to improve upon in the future exists.
Best, Phil
From:
spdx@... <spdx@...> on behalf of Sebastian Crane <seabass-labrax@...> Dear all, |
|
|
|
Re: SPDX Thursday General Meeting Reminder - SPECIAL MEETING
Dear all,
During today's General Meeting, in which the Core Team presented a proposal to improve the governance of SPDX, I brought up a few suggestions to the current proposal. Going into the meeting I did not fully grasp that, under the current governance model, the proposal would have to be accepted by the working group as a whole - thus consensus would need to be reached before additional suggestions. Thank you to Steve and Phil for explaining this! I think it would be good to have a discussion at some point on the Code of Conduct and of the licensing of the SPDX specification, to maybe iterate further on the already excellent proposal. For the record, and the reason for sending this email, I wanted to state that I'm very much in support of the proposal as it is now, and would not consider my concerns blockers here! Thanks again to the members of the Core Team who've put the time and effort into creating the proposal. Best wishes, Sebastian |
|
|
|
SPDX Thursday General Meeting Reminder - SPECIAL MEETING
Phil Odence
We will deviate from our usual standing agenda for this special meeting. We will start with a presentation from a Google Summer of Code student (see topic below) and then will pick up the discussion of the SPDX Governance change with the aim of reaching consensus and moving forward.
I encourage you to read through the attached. Steve will give a very quick overview and can answer questions, but we will assume participants of read the pdf of not all the details referenced. And as a reminder, here’s the context I provided last week: 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
GSoC Presentation
Title- Support for spdx Go lang tools by Ujjwal Agarwal
I will talk about the possible approaches that we could have adopted for the project and the approach I choose to go ahead with .The challenges I faced throughout the GSoC coding phase while coding the project and furthermore what are the future implementations that we can expect .
I am a B.tech student at Thapar Institute of Engineering and Technology India . Skilled in Go lang, DevOps, Leadership, Cryptocurrency, and web development. Strong information technology student with a keen interest in open source development .
See you Thursday, 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
|
|
|
|
Re: SPDX Governance Next Steps
Steve Winslow
Thanks Richard and Jilayne! Yes, in other cases we've seen one LF project become a member of another, for purposes of showing support and furthering collaboration between the projects' communities. In other LF projects there are often multiple tiers of membership, including an "associate" membership as you mentioned. For this proposal for SPDX we've kept it simple with just a single "General" membership tier, so that's what Yocto would fall into as well. Best, Steve On Thu, Aug 26, 2021 at 5:40 PM J Lovejoy <opensource@...> wrote:
|
|
|
|
Re: SPDX Governance Next Steps
J Lovejoy
Hi Richard,
toggle quoted message
Show quoted text
I love your forward thinking! First we have to have the review and acceptance of the proposal. Assuming that goes through and as to whether the Yocto Project could be an SPDX member - that is probably a question for the LF, as I'm not sure how one LF project being a member of another LF project works when you have the same "parent". In any case, I'd think we can figure out something to show the strong support and relationship! Cheers, Jilayne On 8/25/21 2:28 PM, Richard Purdie
wrote:
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 |
|
|
|
Re: SPDX Governance Next Steps
Richard Purdie
On Wed, 2021-08-25 at 20:09 +0000, Phil Odence via lists.spdx.org wrote:
SPDX Community,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 |
|
|
|
SPDX Governance Next Steps
Phil Odence
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
|
|
|
|
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.
|
|
|
|
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. 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
Join the meeting:
Administrative Agenda Attendance Minutes Approval https://wiki.spdx.org/view/General_Meeting/Minutes/2021-07-01
Technical Team Report – Kate/Gary/Others
Technical Team Report – Kate/Gary/Others
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 :)
|
|
|
|
Re: Question on two MIT-derivatives
Christian Ehrhardt
On Fri, Jul 9, 2021 at 11:07 AM Philippe Ombredanne
<pombredanne@...> wrote: 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 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd |
|
|
|
Re: Question on two MIT-derivatives
Alexios Zavras
Hi Christian,
toggle quoted message
Show quoted text
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 -----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 |
|
|
|
Re: Question on two MIT-derivatives
Philippe Ombredanne
Hi Christian:
On Thu, Jul 8, 2021 at 11:27 PM Christian Ehrhardt <christian.ehrhardt@...> wrote:
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 |
|
|
|
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
Join the meeting:
Administrative Agenda Attendance Minutes Approval https://wiki.spdx.org/view/General_Meeting/Minutes/2021-06-03
Technical Team Report – Kate/Gary/Others
Technical Team Report – Kate/Gary/Others
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:
|
|
|
|
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: |
|
|
