public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Paweł Hajdan, Jr." <phajdan.jr@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]
Date: Sun, 26 Aug 2018 13:09:41 +0200	[thread overview]
Message-ID: <5bf34233-8740-44e2-e4d5-2f647a703584@gentoo.org> (raw)
In-Reply-To: <1535280838.4490.16.camel@gentoo.org>


[-- Attachment #1.1: Type: text/plain, Size: 1103 bytes --]

On 26/08/2018 12:53, Mart Raudsepp wrote:
> The common issue here is that upstream COPYING files really do only
> talk about one of the versions. And then you get to validate or source
> files to be sure that they do have a "or later" clause in them. And
> then on each bump you ideally should validate it again, etc, that no
> sources without "or later" allowance are in there...

Yup, precise tracking of license metadata can be a pain.

I'm not really sure if that level of it is worth for us as a distro. For
_importing_ other project's source code directly into one's project
precise license compatibility matters a lot. That's not the scenario
we're in. I see LICENSES as mostly a mechanism for end users to accept
or reject EULAs etc, and I'm curious what are other common scenarios.

Michał, could you elaborate on why not distinguishing more precisely
between these GPL variants in LICENSES is a _problem_ ? I can certainly
see the information is not always accurate, but it's not obvious to me
how severe is the downside, what are the consequences in practice.

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

  reply	other threads:[~2018-08-26 11:09 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-26 10:39 [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23] Michał Górny
2018-08-26 10:53 ` Mart Raudsepp
2018-08-26 11:09   ` Paweł Hajdan, Jr. [this message]
2018-08-26 11:15     ` Michał Górny
2018-08-26 11:33       ` Roy Bamford
2018-08-26 11:35       ` Rich Freeman
2018-08-26 17:03       ` Paweł Hajdan, Jr.
2018-08-27 22:46     ` Michael Mol
2018-08-31 22:31       ` Rich Freeman
2018-09-01  7:44       ` Paweł Hajdan, Jr.
2018-08-26 15:50 ` Ulrich Mueller
2018-08-26 17:14   ` Michał Górny
2018-08-26 18:14     ` Mart Raudsepp
2018-08-26 19:43       ` M. J. Everitt
2018-08-26 19:45       ` Francesco Riosa
2018-08-26 19:50         ` Francesco Riosa
2018-08-26 22:40   ` Jonas Stein
     [not found]   ` <3116195.kUm3yr6LE6@hermes>
2018-08-26 22:41     ` Robin H. Johnson
2018-08-27  2:55       ` Ulrich Mueller
     [not found]         ` <3623085.8soZgasqjt@hermes>
2018-08-27  7:35           ` Ulrich Mueller
2018-08-27  2:37     ` Ulrich Mueller

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=5bf34233-8740-44e2-e4d5-2f647a703584@gentoo.org \
    --to=phajdan.jr@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /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