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