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 <https://github.com/CommunitySpecification/1.0/blob/master/1._Community_Specification_License-v1.md> 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 <https://www.finos.org/newsletter/friday-update-newsletter-4-june-21> 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 <[email protected]> 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 > <[email protected]> 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 | [email protected] > 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 [email protected] -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1414): https://lists.spdx.org/g/spdx/message/1414 Mute This Topic: https://lists.spdx.org/mt/83308273/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/spdx/leave/2655439/21656/1698928721/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
