From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
To: cygwin-apps@cygwin.com
Subject: Re: LICENSE values for non-standard OSS licenses
Date: Wed, 12 Oct 2022 16:28:36 -0600 [thread overview]
Message-ID: <c1de5173-f056-1f03-d98d-58810c63df5d@SystematicSw.ab.ca> (raw)
In-Reply-To: <20221012185943.kucwn4xij7ray7d4@lucy.dinwoodie.org>
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
next prev parent reply other threads:[~2022-10-12 22:28 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 [this message]
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=c1de5173-f056-1f03-d98d-58810c63df5d@SystematicSw.ab.ca \
--to=brian.inglis@systematicsw.ab.ca \
--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).