public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Richard Yao <ryao@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: licenses <licenses@gentoo.org>
Subject: Re: [gentoo-dev] [RFC] Adding 'GPL-2-only', 'GPL-3-only' etc. license variants for better auditing
Date: Sun, 22 Sep 2019 12:36:42 -0400	[thread overview]
Message-ID: <E5D5AC38-D626-489C-9608-7037B0F35EDC@gentoo.org> (raw)
In-Reply-To: <c8f0dbac2310d90456ea17ecc50d79acbe82d50e.camel@gentoo.org>


> On Sep 21, 2019, at 12:09 PM, Michał Górny <mgorny@gentoo.org> wrote:
> 
> Hi,
> 
> TL;DR: I'd like to replace 'GPL-2' with 'GPL-2-only' etc., having
> the former trigger QA warning asking the dev to double-check if it's
> 'GPL-2-only' or 'GPL-2+'.
> 
> 
> GNU Licenses currently don't carry an upgrade clause -- instead, authors
> are expected to decide whether they permit upgrade to newer versions of
> the license in question, or require users to stick with their version of
> choice.
> 
> Their decision is normally indicated in copyright notices on top
> of source files.  Those that permit upgrade usually state 'either
> version N of the License, or (at your option) any later version.', while
> others remove the 'or...' or even replace with 'only' (sometimes
> removing 'either', sometimes leaving it ;-)).
> 
> The truth is, many developers don't go that far to verify it.  Instead,
> they usually look at 'COPYING' or 'LICENSE', read the version there
> and put 'GPL-2', 'GPL-3' etc. in the ebuild.  It doesn't help that
> GitHub does the same and shows the result as easy-to-read note on top of
> repo.
> 
> 
> For some time I've been reviewing packages I'm (co-)maintaining, as well
> as proxy-maint submissions for this particular problem.  However,
> surprisingly many projects actually go the 'version N only' route, even
> in middle of environments that are 'N+' like Xfce.  As a result, I've
> ended up rechecking the same packages over and over again to the point
> of starting to add comments saying 'yes, this is GPL-2 only'.
> 
> I'd like to propose to employ a more systematic method of resolving this
> problem.  I would like to add additional explicit 'GPL-n-only' licenses,
> and discourage using short 'GPL-n' in favor of them.  The end result
> would be three licenses per every version/variant, e.g.:
> 
>  GPL-2-only -- version 2 only
>  GPL-2+     -- version 2 or newer
>  GPL-2      -- might be either, audit necessary
> 
> The main idea is that we'd be able to easily find 'non-audited' packages
> with GPL-2 entries, and replace them with either GPL-2+ or GPL-2-only
> after auditing.  While technically it would still be possible for people
> to wrongly set LICENSE to GPL-2-only, I think this explicit distinction
> will help people notice that there actually is a deeper difference,
> and it will still catch people who just type 'GPL-n' without looking
> into the license directory.
My read of this and the comments is that it boils down to getting people to do the right thing and ensuring that they did. If anyone does not already understand this, we need to have a talk with them about it.

Also, for things like the Linux kernel where some files lack the or later version clause, this is going to end up with us doing GPL-2-only and GPL-2+ at the same time. Is this really what we want to do there?
> 
> 
> For a start, I'd only go for adding the '-only' variants to the most
> common licenses, i.e. GPL-2, -3, LGPL-2, -2.1, -3, AGPL-3, maybe some
> FDL versions.  I don't think we need this for the long 'exception'
> variants -- I suspect that if someone did research enough to notice
> the exception, then most likely he would also notice the 'or newer'.
> 
> 
> WDYT?
> 
> -- 
> Best regards,
> Michał Górny
> 



      parent reply	other threads:[~2019-09-22 16:36 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-21 16:09 [gentoo-dev] [RFC] Adding 'GPL-2-only', 'GPL-3-only' etc. license variants for better auditing Michał Górny
2019-09-21 16:57 ` Matt Turner
2019-09-21 23:21   ` Matt Turner
2019-09-21 23:46     ` Ulrich Mueller
2019-09-22  0:03       ` Matt Turner
2019-09-24  3:45       ` Matt Turner
2019-09-24  7:13         ` Ulrich Mueller
2019-09-24 15:39           ` Matt Turner
2019-09-21 19:17 ` [gentoo-dev] " Ulrich Mueller
2019-09-21 19:26   ` William Hubbs
2019-09-21 19:57     ` Michał Górny
2019-09-21 22:45       ` William Hubbs
2019-09-22  6:12         ` Michał Górny
2019-09-24  1:42   ` Jason Zaman
2019-09-24  3:43     ` Matt Turner
2019-09-24  6:16     ` Ulrich Mueller
2019-09-21 19:56 ` [gentoo-dev] " Michael Orlitzky
2019-09-21 19:59   ` Michał Górny
2019-09-21 20:02     ` Michael Orlitzky
2019-09-21 20:58 ` [gentoo-dev] " Ulrich Mueller
2019-09-21 22:01   ` Matt Turner
2019-09-21 23:38     ` Ulrich Mueller
2019-09-22  9:16   ` Kent Fredric
2019-09-22 16:36 ` Richard Yao [this message]

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=E5D5AC38-D626-489C-9608-7037B0F35EDC@gentoo.org \
    --to=ryao@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=licenses@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