* LICENSE values for non-standard OSS licenses @ 2022-10-11 8:37 Adam Dinwoodie 2022-10-11 20:13 ` Brian Inglis ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Adam Dinwoodie @ 2022-10-11 8:37 UTC (permalink / raw) To: cygwin-apps Hullo, I'm trying to upload a new version of git-filter-repo, and took the opportunity to set the LICENSE value in the cygport file. The new value looks valid according to my reading of the SPDX specification, but is being rejected by calm. The license for git-filter-repo is a bit complicated, because different parts have different licenses, and several of them aren't "normal" licenses. The license is described at [0] and files referenced / linked from there. [0]: https://github.com/newren/git-filter-repo/blob/main/COPYING I've encoded this as the somewhat verbose LICENSE='(MIT OR LicenseRef-inherit-git OR LicenseRef-inherit-libgit2) AND (MIT OR LicenseRef-inherit-git OR LicenseRef-inherit-libgit2 OR LicenseRef-inherit-libgit2-examples) AND GPL-2.0-only' The error I'm getting from calm is as follows: ``` 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/ 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. For now I can just remove the LICENSE values to get the build released, but that seems like a temporary approach at best... ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: LICENSE values for non-standard OSS licenses 2022-10-11 8:37 LICENSE values for non-standard OSS licenses Adam Dinwoodie @ 2022-10-11 20:13 ` Brian Inglis 2022-10-12 8:36 ` Thomas Wolff 2022-10-12 9:00 ` Adam Dinwoodie 2022-10-12 17:58 ` Achim Gratz 2022-10-14 16:28 ` Jon Turney 2 siblings, 2 replies; 17+ messages in thread From: Brian Inglis @ 2022-10-11 20:13 UTC (permalink / raw) To: cygwin-apps On Tue, 11 Oct 2022 09:37:23 +0100, Adam Dinwoodie wrote: > I'm trying to upload a new version of git-filter-repo, and took the > opportunity to set the LICENSE value in the cygport file. The new value > looks valid according to my reading of the SPDX specification, but is > being rejected by calm. > The license for git-filter-repo is a bit complicated, because different > parts have different licenses, and several of them aren't "normal" > licenses. The license is described at [0] and files referenced / linked > from there. > [0]: https://github.com/newren/git-filter-repo/blob/main/COPYING > I've encoded this as the somewhat verbose > LICENSE='(MIT OR LicenseRef-inherit-git OR LicenseRef-inherit-libgit2) AND (MIT OR LicenseRef-inherit-git OR LicenseRef-inherit-libgit2 OR LicenseRef-inherit-libgit2-examples) AND GPL-2.0-only' > The error I'm getting from calm is as follows: > ``` > 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/ > 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. > For now I can just remove the LICENSE values to get the build released, > but that seems like a temporary approach at best... To a similar issue of mine in another thread here (search license) Jon replied calm uses: https://github.com/nexB/license-expression produced by the same project/dev as scancode (which scans a codebase to identify licences as part of project AboutCode), which has registered an SPDX namespace for its own LicenceRefs available at: https://scancode-licensedb.aboutcode.org/ which makes me believe Cygwin should use LicenseRef-scancode-public-domain or as referenced there LicenseRef-PublicDomain, and license-expression should be able to use the scancode list. -- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: LICENSE values for non-standard OSS licenses 2022-10-11 20:13 ` Brian Inglis @ 2022-10-12 8:36 ` Thomas Wolff 2022-10-12 9:51 ` Adam Dinwoodie 2022-10-12 9:00 ` Adam Dinwoodie 1 sibling, 1 reply; 17+ messages in thread From: Thomas Wolff @ 2022-10-12 8:36 UTC (permalink / raw) To: cygwin-apps Am 11/10/2022 um 22:13 schrieb Brian Inglis: > On Tue, 11 Oct 2022 09:37:23 +0100, Adam Dinwoodie wrote: >> I'm trying to upload a new version of git-filter-repo, and took the >> opportunity to set the LICENSE value in the cygport file. The new value >> looks valid according to my reading of the SPDX specification, but is >> being rejected by calm. >> The license for git-filter-repo is a bit complicated, because different >> parts have different licenses, and several of them aren't "normal" >> licenses. The license is described at [0] and files referenced / linked >> from there. >> [0]: https://github.com/newren/git-filter-repo/blob/main/COPYING >> I've encoded this as the somewhat verbose >> LICENSE='(MIT OR LicenseRef-inherit-git OR >> LicenseRef-inherit-libgit2) AND (MIT OR LicenseRef-inherit-git OR >> LicenseRef-inherit-libgit2 OR LicenseRef-inherit-libgit2-examples) >> AND GPL-2.0-only' From a mere Boolean perspective, this looks redundant and should be simplified to LICENSE='(MIT OR LicenseRef-inherit-git OR LicenseRef-inherit-libgit2) AND GPL-2.0-only' >> The error I'm getting from calm is as follows: >> ``` >> 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/ >> 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. >> For now I can just remove the LICENSE values to get the build released, >> but that seems like a temporary approach at best... > > To a similar issue of mine in another thread here (search license) Jon > replied calm uses: > > https://github.com/nexB/license-expression > > produced by the same project/dev as scancode (which scans a codebase > to identify licences as part of project AboutCode), which has > registered an SPDX namespace for its own LicenceRefs available at: > > https://scancode-licensedb.aboutcode.org/ > > which makes me believe Cygwin should use > LicenseRef-scancode-public-domain or as referenced there > LicenseRef-PublicDomain, and license-expression should be able to use > the scancode list. > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: LICENSE values for non-standard OSS licenses 2022-10-12 8:36 ` Thomas Wolff @ 2022-10-12 9:51 ` Adam Dinwoodie 0 siblings, 0 replies; 17+ messages in thread From: Adam Dinwoodie @ 2022-10-12 9:51 UTC (permalink / raw) To: cygwin-apps On Wed, Oct 12, 2022 at 10:36:02AM +0200, Thomas Wolff wrote: > > > Am 11/10/2022 um 22:13 schrieb Brian Inglis: > > On Tue, 11 Oct 2022 09:37:23 +0100, Adam Dinwoodie wrote: > > > I'm trying to upload a new version of git-filter-repo, and took the > > > opportunity to set the LICENSE value in the cygport file. The new value > > > looks valid according to my reading of the SPDX specification, but is > > > being rejected by calm. > > > The license for git-filter-repo is a bit complicated, because different > > > parts have different licenses, and several of them aren't "normal" > > > licenses. The license is described at [0] and files referenced / linked > > > from there. > > > [0]: https://github.com/newren/git-filter-repo/blob/main/COPYING > > > I've encoded this as the somewhat verbose > > > LICENSE='(MIT OR LicenseRef-inherit-git OR > > > LicenseRef-inherit-libgit2) AND (MIT OR LicenseRef-inherit-git OR > > > LicenseRef-inherit-libgit2 OR LicenseRef-inherit-libgit2-examples) > > > AND GPL-2.0-only' > From a mere Boolean perspective, this looks redundant and should be > simplified to > LICENSE='(MIT OR LicenseRef-inherit-git OR LicenseRef-inherit-libgit2) > AND GPL-2.0-only' Hmm. You're obviously correct from a Boolean logic perspective, but my aim was to provide something more information-rich than a purely Boolean statement. Specifically, each file within the packages produced by this cygport script will be covered by one of the and-joined statements. Some files are GPLv2, some are MIT, "inherit-git" or "inherit-libgit2", and some are MIT, "inherit-git", "inherit-libgit2" or "inherit-libgit2-examples". Removing "inherit-libgit2-examples", as logically simplifying the statement would do, in my mind implies that license isn't at all relevant, even though it does apply to some parts of git-filter-repo. Which version is preferable probably comes down to the intent of the LICENSE value in the cygport file and in the various places that consume that information, either now or in future. If it's intended significantly for human consumption, having the information-rich version may be useful; if it's intended primarily for machine consumption, the simplified version would probably be preferable. From digging around the SPDX specifications and examples a bit, I think we're already some distance away from the intent of SPDX. If you look at [0], for example, you can see detail is given separately for the source and compiled code, and within each of those, the license information is specified separately for each file. Using a single license string for -- potentially -- multiple packages means we're much more likely to encounter this sort of problem, as it's much more likely that different packages produced by the same cygport file, or different files within each package, are going to be covered by different licenses. [0]: https://github.com/spdx/spdx-examples/tree/master/example4/spdx ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: LICENSE values for non-standard OSS licenses 2022-10-11 20:13 ` Brian Inglis 2022-10-12 8:36 ` Thomas Wolff @ 2022-10-12 9:00 ` Adam Dinwoodie 2022-10-12 15:45 ` Brian Inglis 1 sibling, 1 reply; 17+ messages in thread From: Adam Dinwoodie @ 2022-10-12 9:00 UTC (permalink / raw) To: cygwin-apps On Tue, Oct 11, 2022 at 02:13:00PM -0600, Brian Inglis wrote: > On Tue, 11 Oct 2022 09:37:23 +0100, Adam Dinwoodie wrote: > > I'm trying to upload a new version of git-filter-repo, and took the > > opportunity to set the LICENSE value in the cygport file. The new value > > looks valid according to my reading of the SPDX specification, but is > > being rejected by calm. > > The license for git-filter-repo is a bit complicated, because different > > parts have different licenses, and several of them aren't "normal" > > licenses. The license is described at [0] and files referenced / linked > > from there. > > [0]: https://github.com/newren/git-filter-repo/blob/main/COPYING > > I've encoded this as the somewhat verbose > > LICENSE='(MIT OR LicenseRef-inherit-git OR LicenseRef-inherit-libgit2) AND (MIT OR LicenseRef-inherit-git OR LicenseRef-inherit-libgit2 OR LicenseRef-inherit-libgit2-examples) AND GPL-2.0-only' > > The error I'm getting from calm is as follows: > > ``` > > 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/ > > 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. > > For now I can just remove the LICENSE values to get the build released, > > but that seems like a temporary approach at best... > > To a similar issue of mine in another thread here (search license) Jon > replied calm uses: > > https://github.com/nexB/license-expression > > produced by the same project/dev as scancode (which scans a codebase to > identify licences as part of project AboutCode), which has registered an > SPDX namespace for its own LicenceRefs available at: > > https://scancode-licensedb.aboutcode.org/ > > which makes me believe Cygwin should use LicenseRef-scancode-public-domain > or as referenced there LicenseRef-PublicDomain, and license-expression > should be able to use the scancode list. I'm not sure I understand your point. Neither LicenseRef-scancode-public-domain nor LicenseRef-PublicDomain look appropriate here, as none of the code has been placed in the public domain. I'm a bit confused about the "Cygwin should use" point, too: are you saying that Cygwin itself should be declared as having a public domain license? I think that's not true, too, per https://cygwin.com/licensing.html ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: LICENSE values for non-standard OSS licenses 2022-10-12 9:00 ` Adam Dinwoodie @ 2022-10-12 15:45 ` Brian Inglis 2022-10-12 20:14 ` Adam Dinwoodie 0 siblings, 1 reply; 17+ messages in thread From: Brian Inglis @ 2022-10-12 15:45 UTC (permalink / raw) To: cygwin-apps On 2022-10-12 9:00 UTC, Adam Dinwoodie wrote:> On Tue, Oct 11, 2022 at 02:13:00PM -0600, Brian Inglis wrote: >> On Tue, 11 Oct 2022 09:37:23 +0100, Adam Dinwoodie wrote: >> > I'm trying to upload a new version of git-filter-repo, and took the >> > opportunity to set the LICENSE value in the cygport file. The new value >> > looks valid according to my reading of the SPDX specification, but is >> > being rejected by calm. >> > The license for git-filter-repo is a bit complicated, because different >> > parts have different licenses, and several of them aren't "normal" >> > licenses. The license is described at [0] and files referenced / linked >> > from there. >> > [0]: https://github.com/newren/git-filter-repo/blob/main/COPYING >> > I've encoded this as the somewhat verbose >> > LICENSE='(MIT OR LicenseRef-inherit-git OR LicenseRef-inherit-libgit2) AND (MIT OR LicenseRef-inherit-git OR LicenseRef-inherit-libgit2 OR LicenseRef-inherit-libgit2-examples) AND GPL-2.0-only' >> > The error I'm getting from calm is as follows: >> > ``` >> > 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/ >> > 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. >> > For now I can just remove the LICENSE values to get the build released, >> > but that seems like a temporary approach at best... As well as SPDX standard script comments e.g "# SPDX-License-Identifier: ...", the same in a variable LICENSE_SPDX="SPDX-License-Identifier: ...", and LICENCE_URI="COPYING..." which documents the basis, I've started using <PKG>_LICENSE... variables for the different subpackages, which may not be currently checked, but simplifies using SPDX terms e.g. <https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/gsasl.git;a=blob;f=gsasl.cygport;hb=refs/heads/playground> >> To a similar issue of mine in another thread here (search license) Jon >> replied calm uses: >> https://github.com/nexB/license-expression >> produced by the same project/dev as scancode (which scans a codebase to >> identify licences as part of project AboutCode), which has registered an >> SPDX namespace for its own LicenceRefs available at: >> https://scancode-licensedb.aboutcode.org/ >> which makes me believe Cygwin should use LicenseRef-scancode-public-domain >> or as referenced there LicenseRef-PublicDomain, and license-expression >> should be able to use the scancode list. > I'm not sure I understand your point. Neither > LicenseRef-scancode-public-domain nor LicenseRef-PublicDomain look > appropriate here, as none of the code has been placed in the public > domain. That was a data point about the code used by Cygwin/calm, and an example about a non-standard exception licence name in the other thread, how it could be made non-exceptional, and the list extended for now, by using the scancode DB licences, while SPDX makes its way thru the scancode namespace licences, which have been submitted to them for consideration. SPDX keeps closing (e.g. PD) licence requests as they seem to be equating (e.g. PD) licenses to invariant licence texts, which are often simple and embedded in files, e.g. "This code is in the public domain", or "This code is a product of the US Government and in the public domain", sometimes with minor variations across a project, sometimes implicit, or not stated, just copyrights, sometimes without even disclaimers, rather than considering the licence intents of projects, e.g. US-PD, US-Gov-PD. With that bureaucratic attitude and hurdle, who knows how many projects will ever "officially qualify" for SPDX licences, if they don't already have clear licences, as many will not bother to spend precious time to standardize the statements across all files, or contact all known existing copyright holders to get agreement on relicensing, even if it were possible to contact them all and get a response. Of course, licence compliance is a nice "simple" (in theory, but you see the problems) bureaucratic exercise that orgs like to do, but doesn't actually address the main problems of libre software supply chain reliability, security, whether products are adequately maintained or even maintainable, or abandoned. -- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: LICENSE values for non-standard OSS licenses 2022-10-12 15:45 ` Brian Inglis @ 2022-10-12 20:14 ` Adam Dinwoodie 0 siblings, 0 replies; 17+ messages in thread From: Adam Dinwoodie @ 2022-10-12 20:14 UTC (permalink / raw) To: cygwin-apps On Wed, Oct 12, 2022 at 09:45:35AM -0600, Brian Inglis wrote: > On 2022-10-12 9:00 UTC, Adam Dinwoodie wrote:> On Tue, Oct 11, 2022 at > 02:13:00PM -0600, Brian Inglis wrote: > > > On Tue, 11 Oct 2022 09:37:23 +0100, Adam Dinwoodie wrote: > > > > I'm trying to upload a new version of git-filter-repo, and took the > > > > opportunity to set the LICENSE value in the cygport file. The new value > > > > looks valid according to my reading of the SPDX specification, but is > > > > being rejected by calm. > > > > The license for git-filter-repo is a bit complicated, because different > > > > parts have different licenses, and several of them aren't "normal" > > > > licenses. The license is described at [0] and files referenced / linked > > > > from there. > > > > [0]: https://github.com/newren/git-filter-repo/blob/main/COPYING > > > > I've encoded this as the somewhat verbose > > > > LICENSE='(MIT OR LicenseRef-inherit-git OR LicenseRef-inherit-libgit2) AND (MIT OR LicenseRef-inherit-git OR LicenseRef-inherit-libgit2 OR LicenseRef-inherit-libgit2-examples) AND GPL-2.0-only' > > > > The error I'm getting from calm is as follows: > > > > ``` > > > > 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/ > > > > 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. > > > > For now I can just remove the LICENSE values to get the build released, > > > > but that seems like a temporary approach at best... > > As well as SPDX standard script comments e.g "# SPDX-License-Identifier: > ...", the same in a variable LICENSE_SPDX="SPDX-License-Identifier: ...", > and LICENCE_URI="COPYING..." which documents the basis, I've started using > <PKG>_LICENSE... variables for the different subpackages, which may not be > currently checked, but simplifies using SPDX terms e.g. <https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/gsasl.git;a=blob;f=gsasl.cygport;hb=refs/heads/playground> I like the theory; I think I'm wary of doing this sort of thing without the blessing of the folk responsible for calm and/or cygport. I'm probably overthinking things, but I'm always worried that coming up with schemes that don't have that sort of official blessing will create another https://xkcd.com/927/ > > > To a similar issue of mine in another thread here (search license) Jon > > > replied calm uses: > > > https://github.com/nexB/license-expression > > > produced by the same project/dev as scancode (which scans a codebase to > > > identify licences as part of project AboutCode), which has registered an > > > SPDX namespace for its own LicenceRefs available at: > > > https://scancode-licensedb.aboutcode.org/ > > > which makes me believe Cygwin should use LicenseRef-scancode-public-domain > > > or as referenced there LicenseRef-PublicDomain, and license-expression > > > should be able to use the scancode list. > > > I'm not sure I understand your point. Neither > > LicenseRef-scancode-public-domain nor LicenseRef-PublicDomain look > > appropriate here, as none of the code has been placed in the public > > domain. > > That was a data point about the code used by Cygwin/calm, and an example > about a non-standard exception licence name in the other thread, how it > could be made non-exceptional, and the list extended for now, by using the > scancode DB licences, while SPDX makes its way thru the scancode namespace > licences, which have been submitted to them for consideration. Ah, I see! Because calm is using the scancode library, it's permitting the set of scancode-blessed license strings as well as the SPDX ones, just not permitting any LicenseRef- strings that don't have scancode's blessing. I'm not sure that helps here, though: the scancode set of licenses is much broader than the SPDX list, but it still doesn't incorporate the specific licenses / exceptions in use in git-filter-repo. Unless calm can be fixed to permit non-scancode LicenseRef- strings, it looks like my options are to (a) as Achim suggested, fix the licenses in use now, restricting what licenses Cygwin users get the software under, or (b) just don't use the LICENSE variable in the first place. > SPDX keeps closing (e.g. PD) licence requests as they seem to be equating > (e.g. PD) licenses to invariant licence texts, which are often simple and > embedded in files, e.g. "This code is in the public domain", or "This code > is a product of the US Government and in the public domain", sometimes with > minor variations across a project, sometimes implicit, or not stated, just > copyrights, sometimes without even disclaimers, rather than considering the > licence intents of projects, e.g. US-PD, US-Gov-PD. Honestly (and granted, we're veering off-topic here) I don't have an issue with grouping all public domain declarations into the same group; once something's in the public domain, it's in the public domain, and the reason why it's there doesn't matter from a licensing perspective. To my mind, this is the same as there being no reason to distinguish between projects using GPLv3 because they have strong ethical beliefs about FOSS versus using it because they thought the acronym sounded cool: the reason it has that license isn't relevant to what a licensee can do. > With that bureaucratic attitude and hurdle, who knows how many projects will > ever "officially qualify" for SPDX licences, if they don't already have > clear licences, as many will not bother to spend precious time to > standardize the statements across all files, or contact all known existing > copyright holders to get agreement on relicensing, even if it were possible > to contact them all and get a response. > > Of course, licence compliance is a nice "simple" (in theory, but you see the > problems) bureaucratic exercise that orgs like to do, but doesn't actually > address the main problems of libre software supply chain reliability, > security, whether products are adequately maintained or even maintainable, > or abandoned. Yeah, I definitely appreciate the ideals of what SPDX is trying to achieve, but -- as evidenced here -- trying to group things into a small number of rigid categories isn't easy. It being a difficult problem to solve doesn't mean it's not worth solving, but clearly we need to work out how to handle edge cases in ways that won't cause more problems than it's worth. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: LICENSE values for non-standard OSS licenses 2022-10-11 8:37 LICENSE values for non-standard OSS licenses Adam Dinwoodie 2022-10-11 20:13 ` Brian Inglis @ 2022-10-12 17:58 ` Achim Gratz 2022-10-12 18:59 ` Adam Dinwoodie 2022-10-14 16:28 ` Jon Turney 2 siblings, 1 reply; 17+ messages in thread From: Achim Gratz @ 2022-10-12 17:58 UTC (permalink / raw) To: cygwin-apps 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. > 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. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: LICENSE values for non-standard OSS licenses 2022-10-12 17:58 ` Achim Gratz @ 2022-10-12 18:59 ` Adam Dinwoodie 2022-10-12 22:28 ` Brian Inglis 2022-10-16 8:42 ` ASSI 0 siblings, 2 replies; 17+ messages in thread From: Adam Dinwoodie @ 2022-10-12 18:59 UTC (permalink / raw) To: cygwin-apps 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/ > 10 Other licensing information detected section > > 10.1 License identifier field > > 10.1.1 Description > > Provide a locally unique identifier to refer to licenses that are not > found on the SPDX License List. This unique identifier can then be > used in the packages, files and snippets sections of the SPDX document > (Clause 7, Clause 8 and Clause 9, respectively). The metadata for the > license identifier field is shown in Table 63. > > Table 63 — Metadata for the license identifier field > > Attribute | Value > --------------+-------- > Required | Conditional > Cardinality | 0..1 conditional (Mandatory, one) if license is not on > | SPDX License List. > Format | `"LicenseRef-"[idstring]` where `[idstring]` is a > | unique string containing letters, numbers, `.` and/or > | `-`. > > 10.1.2 Intent > > Create a human readable short form license identifier for a license > not on the SPDX License List. This identifier shall be unique within > the SPDX document. In previous versions of SPDX, the references were > required to be sequential numbers, but as of version 1.2, creators may > specify references that are easier for humans to remember and mentally > map. From https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/ > ... A license expression could be a single license identifier found on > the SPDX License List; a user defined license reference denoted by the > LicenseRef-[idString]; a license identifier combined with an SPDX > exception; or some combination of license identifiers, license > references and exceptions constructed using a small set of defined > operators (e.g., AND, OR, WITH and +). We provide the definition of > what constitutes a valid an SPDX License Expression in this section. > > The exact syntax of license expressions is described below in ABNF. > > idstring = 1*(ALPHA / DIGIT / "-" / "." ) > > license-id = <short form license identifier in Annex A.1> > > license-exception-id = <short form license exception identifier in Annex A.2> > > license-ref = ["DocumentRef-"(idstring)":"]"LicenseRef-"(idstring) > > simple-expression = license-id / license-id"+" / license-ref > > compound-expression = (simple-expression / > simple-expression "WITH" license-exception-id / > compound-expression "AND" compound-expression / > compound-expression "OR" compound-expression / > "(" compound-expression ")" ) > > license-expression = (simple-expression / compound-expression) 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... ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: LICENSE values for non-standard OSS licenses 2022-10-12 18:59 ` Adam Dinwoodie @ 2022-10-12 22:28 ` Brian Inglis 2022-10-13 10:32 ` Adam Dinwoodie 2022-10-16 8:42 ` ASSI 1 sibling, 1 reply; 17+ messages in thread From: Brian Inglis @ 2022-10-12 22:28 UTC (permalink / raw) To: cygwin-apps 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? For custom exceptions, and from SPDX discussion, I think you could use WITH LicenseRef-cygwin-exception-... or similar wording, whatever is currently preferred. -- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: LICENSE values for non-standard OSS licenses 2022-10-12 22:28 ` Brian Inglis @ 2022-10-13 10:32 ` Adam Dinwoodie 2022-10-15 19:27 ` Brian Inglis 0 siblings, 1 reply; 17+ messages in thread From: Adam Dinwoodie @ 2022-10-13 10:32 UTC (permalink / raw) To: cygwin-apps 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. 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. > 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 <license-ref> 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.) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: LICENSE values for non-standard OSS licenses 2022-10-13 10:32 ` Adam Dinwoodie @ 2022-10-15 19:27 ` Brian Inglis 0 siblings, 0 replies; 17+ messages in thread From: Brian Inglis @ 2022-10-15 19:27 UTC (permalink / raw) To: cygwin-apps 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 <license-ref> 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: LICENSE values for non-standard OSS licenses 2022-10-12 18:59 ` Adam Dinwoodie 2022-10-12 22:28 ` Brian Inglis @ 2022-10-16 8:42 ` ASSI 1 sibling, 0 replies; 17+ messages in thread From: ASSI @ 2022-10-16 8:42 UTC (permalink / raw) To: cygwin-apps Adam Dinwoodie writes: […] > 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. But then you either have to include the license "inherit-git" in full or explicitly link in the schema of this license, otherwise you're left with something that is syntactically valid, but meaningless. The whole purpose of the SPDX is to have an unambigous indication of the license, though. >> 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... My point was that any Cygwin package as complex as Git is already prone to include files licensed differently and as long as we don't provide a license for each and every file (I'm not saying we should), then we already need to chose from the set of permissible licenses that overlap among each other and Cygwin. I don't see that as a drawback, as anyone can already go and fetch the upstream sources from the same point that we got it from (or even from the source package in Cygwin) and has the full freedom to do whatever those might allow in addition of what we've selected. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: LICENSE values for non-standard OSS licenses 2022-10-11 8:37 LICENSE values for non-standard OSS licenses Adam Dinwoodie 2022-10-11 20:13 ` Brian Inglis 2022-10-12 17:58 ` Achim Gratz @ 2022-10-14 16:28 ` Jon Turney 2022-10-15 12:58 ` Adam Dinwoodie 2 siblings, 1 reply; 17+ messages in thread From: Jon Turney @ 2022-10-14 16:28 UTC (permalink / raw) To: Adam Dinwoodie, cygwin-apps On 11/10/2022 09:37, Adam Dinwoodie wrote: [... > ``` > 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) > ``` Sigh. Yeah, this isn't working well and is causing people problems, so I've changed this validation failure from an error to a warning, for the moment. I might remove it totally, or revise how it works in the future. > 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/ That says that anything starting "LicenseRef-" can be used to indicate a license not on the SPDX license list, but I'm not sure where "inherit" comes from? Does this just have a meaning defined in some other distro which uses SPDX license expressions? Since these expressions containing LicenseRef ids don't have a definite meaning, perhaps it would just as good for it to be undefined, which is what omitting it currently indicates. > 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. > > For now I can just remove the LICENSE values to get the build released, > but that seems like a temporary approach at best... Well, yes, but then "everything is temporary, anyway" :-) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: LICENSE values for non-standard OSS licenses 2022-10-14 16:28 ` Jon Turney @ 2022-10-15 12:58 ` Adam Dinwoodie 2022-10-30 13:15 ` Jon Turney 2022-10-30 17:19 ` Brian Inglis 0 siblings, 2 replies; 17+ messages in thread From: Adam Dinwoodie @ 2022-10-15 12:58 UTC (permalink / raw) To: cygwin-apps On Fri, 14 Oct 2022 at 17:28, Jon Turney wrote: > > On 11/10/2022 09:37, Adam Dinwoodie wrote: > [... > > ``` > > 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) > > ``` > > Sigh. Yeah, this isn't working well and is causing people problems, so > I've changed this validation failure from an error to a warning, for the > moment. > > I might remove it totally, or revise how it works in the future. I definitely appreciate the principle of declaring this sort of thing! The current mechanism might not be working, but I suspect that's mostly an issue of deciding what we're trying to achieve with it, and what options there are for achieving that… > > 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/ > > That says that anything starting "LicenseRef-" can be used to indicate a > license not on the SPDX license list, but I'm not sure where "inherit" > comes from? Does this just have a meaning defined in some other distro > which uses SPDX license expressions? > > Since these expressions containing LicenseRef ids don't have a definite > meaning, perhaps it would just as good for it to be undefined, which is > what omitting it currently indicates. LicenseRef- licenses are, as you say, anything not on the SPDX list; there's no specific definition beyond that. If we were following the full SPDX specifications, rather than just using a small part of them, the license name would – for non SPDX-list licenses – reference the actual license text, so the LicenseRef-whatever string would just be a reference for the user to look up the license text listed as LicenseRef-whatever. "LicenseRef-inherit-git" and the like are values I made up on that basis. If we were providing full SPDX documents, I'd be including a definition of what I meant by "LicenseRef-inherit-git", which would be the relevant extract from https://github.com/newren/git-filter-repo/blob/main/COPYING. I'm not aware of anywhere else using that syntax. > > 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. > > > > For now I can just remove the LICENSE values to get the build released, > > but that seems like a temporary approach at best... > > Well, yes, but then "everything is temporary, anyway" :-) Very true! ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: LICENSE values for non-standard OSS licenses 2022-10-15 12:58 ` Adam Dinwoodie @ 2022-10-30 13:15 ` Jon Turney 2022-10-30 17:19 ` Brian Inglis 1 sibling, 0 replies; 17+ messages in thread From: Jon Turney @ 2022-10-30 13:15 UTC (permalink / raw) To: cygwin-apps, Adam Dinwoodie On 15/10/2022 13:58, Adam Dinwoodie wrote: > On Fri, 14 Oct 2022 at 17:28, Jon Turney wrote: >> >> On 11/10/2022 09:37, Adam Dinwoodie wrote: >> [... >>> ``` >>> 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) >>> ``` >> >> Sigh. Yeah, this isn't working well and is causing people problems, so >> I've changed this validation failure from an error to a warning, for the >> moment. >> >> I might remove it totally, or revise how it works in the future. > > I definitely appreciate the principle of declaring this sort of thing! > The current mechanism might not be working, but I suspect that's > mostly an issue of deciding what we're trying to achieve with it, and > what options there are for achieving that… I think I misspoke here in saying "I". Since there seems to be lots of people with opinions on this topic, if someone else wants to take the initiative and define how this is going to work, that would be great :) (Not least because I am limited in how much time I can devote to this currently) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: LICENSE values for non-standard OSS licenses 2022-10-15 12:58 ` Adam Dinwoodie 2022-10-30 13:15 ` Jon Turney @ 2022-10-30 17:19 ` Brian Inglis 1 sibling, 0 replies; 17+ messages in thread From: Brian Inglis @ 2022-10-30 17:19 UTC (permalink / raw) To: cygwin-apps; +Cc: Brian.Inglis On Sun, 30 Oct 2022 13:15:19 +0000, Jon Turney wrote: > On 15/10/2022 13:58, Adam Dinwoodie wrote: >> On Fri, 14 Oct 2022 at 17:28, Jon Turney wrote: >>> On 11/10/2022 09:37, Adam Dinwoodie wrote: >>>> ``` >>>> 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) >>>> ``` >>> Sigh. Yeah, this isn't working well and is causing people problems, so >>> I've changed this validation failure from an error to a warning, for the >>> moment. >>> I might remove it totally, or revise how it works in the future. >> I definitely appreciate the principle of declaring this sort of thing! >> The current mechanism might not be working, but I suspect that's >> mostly an issue of deciding what we're trying to achieve with it, and >> what options there are for achieving that… > I think I misspoke here in saying "I". Since there seems to be lots of > people with opinions on this topic, if someone else wants to take the > initiative and define how this is going to work, that would be great :) > (Not least because I am limited in how much time I can devote to this > currently) It appears that, like us, SPDX uses volunteers (some may be part-timers from RH or other legal staff), so they are still getting up to speed, requiring two lawyers and a non-lawyer to agree for a licence definition signoff, discussing how they should be handling exceptions, conf calling only weekly, while projects like Scancode and Fedora are auto-submitting licence requests for new texts from packages they have scanned daily. I suggest we take it easy about licensing until SPDX gets more stable, complete, and better defined. I found searching some of my packages that there may be multiple instances of COPYING{,.LIB},{gpl,lgpl,fdl}.texi, and the like in different directories, some may be later versions than others, and there may or may not be a licensing definition of how they apply in package docs. I'd suggest that if we can't find a named SPDX (or Scancode, etc.) licence id, we create our own LicenseRef-Cygwin{,-exception}-... appending suitable terms, and/or the package, and/or copyright holder name(s). Then submit it to the SPDX GitHub project as an issue, with the required upstream and/or repo links and texts. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2022-10-30 17:19 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-10-11 8:37 LICENSE values for non-standard OSS licenses Adam Dinwoodie 2022-10-11 20:13 ` Brian Inglis 2022-10-12 8:36 ` Thomas Wolff 2022-10-12 9:51 ` Adam Dinwoodie 2022-10-12 9:00 ` Adam Dinwoodie 2022-10-12 15:45 ` Brian Inglis 2022-10-12 20:14 ` Adam Dinwoodie 2022-10-12 17:58 ` Achim Gratz 2022-10-12 18:59 ` Adam Dinwoodie 2022-10-12 22:28 ` Brian Inglis 2022-10-13 10:32 ` Adam Dinwoodie 2022-10-15 19:27 ` Brian Inglis 2022-10-16 8:42 ` ASSI 2022-10-14 16:28 ` Jon Turney 2022-10-15 12:58 ` Adam Dinwoodie 2022-10-30 13:15 ` Jon Turney 2022-10-30 17:19 ` Brian Inglis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).