From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) by sourceware.org (Postfix) with ESMTPS id BCA3D3858D1E for ; Sat, 15 Oct 2022 19:27:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BCA3D3858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=systematicsw.ab.ca Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTP id jgMBoE353S8Wrjmouoz6iG; Sat, 15 Oct 2022 19:27:40 +0000 Received: from [10.0.0.5] ([184.64.124.72]) by cmsmtp with ESMTP id jmotoUPIskTFZjmouohqnB; Sat, 15 Oct 2022 19:27:40 +0000 X-Authority-Analysis: v=2.4 cv=D8dUl9dj c=1 sm=1 tr=0 ts=634b09ac a=oHm12aVswOWz6TMtn9zYKg==:117 a=oHm12aVswOWz6TMtn9zYKg==:17 a=IkcTkHD0fZMA:10 a=wECf3xPYAAAA:8 a=NEAV23lmAAAA:8 a=24AZYWMyAAAA:8 a=Rk2VAlHxvFwTwRjEG_oA:9 a=7Zwj6sZBwVKJAoWSPKxL6X1jA+E=:19 a=QEXdDO2ut3YA:10 a=ccNonjl4-tybilS9-zgM:22 a=bG88sKzkDEFeXWNnvthB:22 Message-ID: <9d129eb6-2a6b-f976-0f66-35159a433219@SystematicSw.ab.ca> Date: Sat, 15 Oct 2022 13:27:39 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 From: Brian Inglis Subject: Re: LICENSE values for non-standard OSS licenses Reply-To: cygwin-apps@cygwin.com To: cygwin-apps@cygwin.com References: <20221013103208.qcb2cpwqcjhnvqh4@lucy.dinwoodie.org> Content-Language: en-CA Organization: Systematic Software In-Reply-To: <20221013103208.qcb2cpwqcjhnvqh4@lucy.dinwoodie.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfDBubcwALPZEV/P3POg0Mc8xDSr/itFRKT6MdXToUqMQK/jD5tEx7oGTLO3wgEHCVpOnPfscRENN3QCSHeAcUWvN0IP3lDVLV4P/g/zdaKgH7TVdqpYZ PohkiM9pnWtMyhFfpoubql9eMG5r7vzlCBfsAZezwcRFxhpTEtY0KeghVaigBm+2nZVK+2omLVHcdaLxl/v6tqPgUrlHq80nHb8= X-Spam-Status: No, score=-1165.6 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, 13 Oct 2022 11:32:08 +0100, Adam Dinwoodie wrote: > On Wed, Oct 12, 2022 at 04:28:36PM -0600, Brian Inglis wrote: >> On 2022-10-12 18:59 UTC, Adam Dinwoodie wrote: >> > On Wed, Oct 12, 2022 at 07:58:56PM +0200, Achim Gratz wrote: >> > > Adam Dinwoodie writes: >> > > > ERROR: invalid hints git-filter-repo-2.38.0-1-src.hint >> > > > ERROR: package 'git-filter-repo': errors in license expression: ['Unknown license key(s): LicenseRef-inherit-git, LicenseRef-inherit-libgit2, LicenseRef-inherit-libgit2-examples'] >> > > > ERROR: errors while parsing hints for package 'git-filter-repo' >> > > > ERROR: error parsing /sourceware/cygwin-staging/home/Adam Dinwoodie/noarch/release/git-filter-repo/git-filter-repo-2.38.0-1-src.hint >> > > > ERROR: error while reading uploaded arch noarch packages from maintainer Adam Dinwoodie >> > > > SUMMARY: 5 ERROR(s) >> > > > ``` >> > > > So it looks like the issue is the way I've encoded the non-standard >> > > > licensing options. "LicenseRef-"(idstring) seems to be the way to >> > > > encode this sort scenario, per [1] and [2], but that doesn't seem to be >> > > > acceptable to calm. >> > > > [1]: https://spdx.github.io/spdx-spec/v2.3/other-licensing-information-detected/ >> > > > [2]: https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/ >> >> > > As it should, since "inherit-git" or any of the other variations doesn't >> > > seem to be a valid license expression per the above. >> >> > I'm trying to use "LicenseRef-inherit-git" and similar, not just >> > "inherit-git", to be clear. >> > From https://spdx.github.io/spdx-spec/v2.3/other-licensing-information-detected/ >> ... >> > From https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/ >> ... >> > >> > Both of these seem to say that "LicenseRef-inherit-git" and similar is >> > exactly the way to describe a license that isn't covered by the SPDX >> > License List, at least unless I'm grossly misunderstanding how >> > license-ref is defined in the ABNF and/or what the LICENSE value in the >> > cygport file is supposed to store. >> >> > > > Are there any suggestions about how to resolve this? I don't think I >> > > > can just use the standard license strings: even if we used GPL-2.0-only >> > > > in place of LicenseRef-inherit-git -- incorrect as that's the license >> > > > *currently* used by Git, but the license for git-filter-repo explicitly >> > > > incorporates any future OSS license Git might use -- that still leaves >> > > > the problem of LicenseRef-inherit-libgit2, which is currently GPL 2.0 >> > > > with an exception that's not covered by any of the SPDX standard >> > > > exceptions. >> >> > > Well I think you can, the license explicitely says you can chose any of >> > > them as you see fit, so you can pick one today and another tomorrow if >> > > you are so inclined. >> >> > Yes, that's true. I'm not a fan of making decisions for sub-licensees >> > that I don't need to make, though; under the same logic, there would be >> > no need for the "OR" syntax in SPDX at all... >> >> AFAICS git uses BSD-3-Clause-Clear, BSL-1.0, GPL-2.0-or-later, >> LGPL-2.0-or-later, and MIT, where are the exception and inherit-git/libgit2 >> from? >> >> Does your inherit-git/libgit2 refer to "...under the terms of the 'git' >> package..." statements, and is that kind of reference really required, >> rather than just taking the reference to be the explicit licences? > > Yes, exactly. Specifically, the "whatever open source licecense that > git.git or libgit2 use now or in future" part. That "now or in future" > is a significant bit of license flexibility, IMO, in the same way that > "GPLv3" and "GPLv3 or later" are significantly different license terms, > even if right now they're effectively identical. See discussion and resolution about libgit2: https://github.com/spdx/license-list-XML/issues/1585 there may be other similar exceptions or discussions that apply. > As I said before, I can just take Achim's suggestion of exercising my > right as a licensee to pick specific licenses from the selection > available. But I'd rather not set things up such that folk getting > their code via me do so under more restrictive license terms than if > they'd obtained the source and/or binaries directly, at least unless > there's an overwhelmingly good reason for that. Agreed that, like SPDX, we don't want to be judging or choosing licences, just documenting what applies: apparently why they want consistent licence texts. >> For custom exceptions, and from SPDX discussion, I think you could use WITH >> LicenseRef-cygwin-exception-... or similar wording, whatever is currently >> preferred. > > That's not my reading of the spec. Looking at the ABNF at [0], a > license-expression using a "WITH" statement has to be of the form > `simple-expression "WITH" license-exception-id`, and > `license-exception-id` can only be an SPDX-defined license identifier. > The `"LicenseRef-"(idstring)` style is only valid as a > `simple-expression`, i.e. with no "WITH" or before a "WITH". > > [0]: https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/ > > From that same document: > >> If the applicable exception is not found on the SPDX License Exception >> List, then use a single to represent the entire license >> terms (including the exception). > > That is, where a license has an exception that isn't on SPDX's exception > list, the solution is to use a single user-defined license to cover the > entire license agreement, exception and all. > > (Plus, AIUI, LicenseRef-cygwin-exception-... would still be rejected by > calm, for the same reason that LicenseRef-inherit-git is rejected by > calm.) https://github.com/spdx/license-list-XML/issues/1022 https://github.com/spdx/spdx-spec/issues/153 https://github.com/spdx/spdx-spec/issues/386 Discussions about proposal to add ExceptionRef-... decided that rules should allow LicenseRef-exception-... or with namespace LicenseRef-cygwin-exception-... but because both AboutCode/scancode and Fedora are mass submitting GitHub Issues about all their licences not in the SPDX list, other issues requiring more discussion like PD, exceptions, etc. may not be officially addressed soon. They are now trying to fast-path issues that should not require discussion effectively by acclaim, getting signoff from 2 lawyers and a non-lawyer, to add to the list, reducing the volume for discussion on the list. For those interested, issues are generated on: https://github.com/spdx/license-list-XML/issues which are discussed on: https://lists.spdx.org/g/Spdx-legal https://lists.spdx.org/g/Spdx-legal/rss and successes archived on: https://tools.spdx.org/app/ published in quarterly releases on: https://github.com/spdx/license-list-XML -- La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry