public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Adam Dinwoodie <adam@dinwoodie.org>
To: cygwin-apps@cygwin.com
Subject: Re: LICENSE values for non-standard OSS licenses
Date: Wed, 12 Oct 2022 10:00:11 +0100	[thread overview]
Message-ID: <20221012090011.jpba5xxajs7foijb@lucy.dinwoodie.org> (raw)
In-Reply-To: <d0ab5486-3662-d4ef-3a5f-da00fa7a368e@SystematicSw.ab.ca>

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

  parent reply	other threads:[~2022-10-12  9:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-11  8:37 Adam Dinwoodie
2022-10-11 20:13 ` Brian Inglis
2022-10-12  8:36   ` Thomas Wolff
2022-10-12  9:51     ` Adam Dinwoodie
2022-10-12  9:00   ` Adam Dinwoodie [this message]
2022-10-12 15:45     ` Brian Inglis
2022-10-12 20:14       ` Adam Dinwoodie
2022-10-12 17:58 ` Achim Gratz
2022-10-12 18:59   ` Adam Dinwoodie
2022-10-12 22:28     ` Brian Inglis
2022-10-13 10:32       ` Adam Dinwoodie
2022-10-15 19:27         ` Brian Inglis
2022-10-16  8:42     ` ASSI
2022-10-14 16:28 ` Jon Turney
2022-10-15 12:58   ` Adam Dinwoodie
2022-10-30 13:15     ` Jon Turney
2022-10-30 17:19     ` Brian Inglis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221012090011.jpba5xxajs7foijb@lucy.dinwoodie.org \
    --to=adam@dinwoodie.org \
    --cc=cygwin-apps@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).