public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: ASSI <Stromeko@nexgo.de>
To: cygwin-apps@cygwin.com
Subject: Re: LICENSE values for non-standard OSS licenses
Date: Sun, 16 Oct 2022 10:42:57 +0200	[thread overview]
Message-ID: <87edv817n2.fsf@Otto.invalid> (raw)
In-Reply-To: <20221012185943.kucwn4xij7ray7d4@lucy.dinwoodie.org> (Adam Dinwoodie's message of "Wed, 12 Oct 2022 19:59:43 +0100")

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

  parent reply	other threads:[~2022-10-16  8:43 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 [this message]
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=87edv817n2.fsf@Otto.invalid \
    --to=stromeko@nexgo.de \
    --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).