From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev <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 07:35:28 -0400 [thread overview]
Message-ID: <CAGfcS_kF=QndWu0Hyh8Zup8TWSJfCidJwb84uJ2hmpk9jq2e1g@mail.gmail.com> (raw)
In-Reply-To: <1535282155.1066.27.camel@gentoo.org>
On Sun, Aug 26, 2018 at 7:15 AM Michał Górny <mgorny@gentoo.org> wrote:
>
> On Sun, 2018-08-26 at 13:09 +0200, Paweł Hajdan, Jr. wrote:
> > 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.
> >
>
> I'm not aware of any major implications. However, I think that if we
> provide for the distinction, the distinction should be used correctly.
>
IMO QA policy ought to be that the license is correct.
How much time/effort goes into policing the policy in the case of
2/3/2+/3+ is a different matter. If people want to do it, great, but
IMO it isn't adding tremendous value. I doubt we have any users
relying on license filtering to distinguish between GPL2/2+. If
somebody files a bug pointing out an incorrect license it should be
fixed as a matter of policy, but I'm not sure more than that is
necessary in this particular case. If we were talking about nonfree
licenses being missed that would be more critical.
--
Rich
next prev parent reply other threads:[~2018-08-26 11:35 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.
2018-08-26 11:15 ` Michał Górny
2018-08-26 11:33 ` Roy Bamford
2018-08-26 11:35 ` Rich Freeman [this message]
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='CAGfcS_kF=QndWu0Hyh8Zup8TWSJfCidJwb84uJ2hmpk9jq2e1g@mail.gmail.com' \
--to=rich0@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