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!