LICENSE values for non-standard OSS licenses

LICENSE values for non-standard OSS licenses

[Adam Dinwoodie]

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...

Re: LICENSE values for non-standard OSS licenses

[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'
> 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

Re: LICENSE values for non-standard OSS licenses

[Thomas Wolff]

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.
>

Re: LICENSE values for non-standard OSS licenses

[Adam Dinwoodie]

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

Re: LICENSE values for non-standard OSS licenses

[Adam Dinwoodie]

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

Re: LICENSE values for non-standard OSS licenses

[Brian Inglis]

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

Re: LICENSE values for non-standard OSS licenses

[Achim Gratz]

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

Re: LICENSE values for non-standard OSS licenses

[Adam Dinwoodie]

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...

Re: 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.

Re: LICENSE values for non-standard OSS licenses

[Brian Inglis]

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

Re: LICENSE values for non-standard OSS licenses

[Adam Dinwoodie]

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.)

Re: LICENSE values for non-standard OSS licenses

[Jon Turney]

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" :-)

Re: LICENSE values for non-standard OSS licenses

[Adam Dinwoodie]

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!

Re: LICENSE values for non-standard OSS licenses

[Brian Inglis]

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

Re: LICENSE values for non-standard OSS licenses

[ASSI]

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

Re: LICENSE values for non-standard OSS licenses

[Jon Turney]

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)

Re: LICENSE values for non-standard OSS licenses

[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