Re: LICENSE values for non-standard OSS licenses

2022-10-12 Thread 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 à retirerbut when there is no more to cut
-- Antoine de Saint-Exupéry

Re: LICENSE values for non-standard OSS licenses

2022-10-12 Thread 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
> _LICENSE... variables for the different subpackages, which may not be
> currently checked, but simplifies using SPDX terms e.g. 
> 

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

Re: LICENSE values for non-standard OSS licenses

2022-10-12 Thread 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 = 
>
> license-exception-id =  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

Re: LICENSE values for non-standard OSS licenses

2022-10-12 Thread 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

2022-10-12 Thread 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 
_LICENSE... variables for the different subpackages, which may not be 
currently checked, but simplifies using SPDX terms e.g. 




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,

Commands are hanging on Windows 2019

2022-10-12 Thread Derek Pagel via Cygwin 
We're seeing a bunch of commands (mv, which, rm) that are hanging or take a 
long time to complete on Windows 2019. It does not happen consistently but 
intermittently about once a week. The issue doesn't happen when running the cmd 
on the cmd line but when the cmd is called from another program. We can't 
replicate the issue from the command line. Is anyone familiar with this issue?

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

[no subject]

2022-10-12 Thread adam 
>From cygwin-announce-git-filter-repo-2.38.0-1 Tue Oct 11 14:01:56 2022
From: a...@dinwoodie.org
Reply-To: cyg...@cygwin.com
To: cygwin-announce@cygwin.com
Date: Tue, 11 Oct 2022 14:01:56 +0100
Message-Id: <20221011140156.1679-1-a...@dinwoodie.org>
Subject: git-filter-repo 2.38.0-1

The following packages have been uploaded to the Cygwin distribution:

* git-filter-repo-2.38.0-1

git filter-repo is a versatile tool for rewriting history, which includes
capabilities not found anywhere else. It roughly falls into the same space of
tool as git filter-branch but without the capitulation-inducing poor
performance, with far more capabilities, and with a design that scales
usability-wise beyond trivial rewriting cases.

When only rsync will do .. or maybe not

2022-10-12 Thread Fergus Daly 
Requirement: to move some selected files and folders under /folder1/ to 
/folder2/, preserving full pathnames.

Using cp with the switch --parents (taking care over syntax and importantly 
location $PWD) it is possible to _copy_ the
Required content across from /folder1/ to /folder2/ but there does not seem to 
be a matching switch for mv that would
achieve the same purpose.

One solution would be (i) to copy the required content to /folder2/ and then 
(ii) delete the identical content under /folder1/;
but this is expensive (one might not even have the disk space to do it) and it 
seems seriously unsatisfactory and not without risk
to have to copy folders and files (possibly huge) when all one wants to do is 
to change the {pathname} to them.

Question 1
Would the command (or something like it, again with care over syntax and $PWD)
$ rsync -axuv --progress {pathto}/folder1/{content} {pathto}/folder2/   
do the trick? Or is the very existence of the switch
$ rsync -axuv --remove-source-files --progress {pathto}/folder1/{content} 
{pathto}/folder2/
indicative that here too the "move" is achieved through a two-stage 
"copy-then-delete" operation?

Question 2
If rsync can provide a genuine "move" capability then is installing the rsync 
package adequate to the purpose;
or would librsync-devel and/or librsync2 packages need to be installed also?

Question 3
If not rsync, is there any operation for which "move" can be achieved without 
involving "copy-then-delete"? 

Thank you for any assistance.


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: LICENSE values for non-standard OSS licenses

2022-10-12 Thread 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

2022-10-12 Thread 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

2022-10-12 Thread 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.