LICENSE values for non-standard OSS licenses

[Adam Dinwoodie]

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.