From: Adam Dinwoodie <adam@dinwoodie.org>
To: "cygwin-apps@cygwin.com" <cygwin-apps@cygwin.com>
Subject: Re: LICENSE values for non-standard OSS licenses
Date: Sat, 15 Oct 2022 13:58:46 +0100 [thread overview]
Message-ID: <CA+kUOam1hZ74KmB68dpjZ3QCDd1iG-fhWwrsEgYwSWFT9r7D=A@mail.gmail.com> (raw)
In-Reply-To: <4c1cddd1-0ff8-39ed-0406-29e47db5aa73@dronecode.org.uk>
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!
next prev parent reply other threads:[~2022-10-15 12:59 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
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 [this message]
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='CA+kUOam1hZ74KmB68dpjZ3QCDd1iG-fhWwrsEgYwSWFT9r7D=A@mail.gmail.com' \
--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).