Re: LICENSE values for non-standard OSS licenses

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

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