public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Cc: licenses <licenses@gentoo.org>
Subject: [gentoo-dev] [RFC] Adding 'GPL-2-only', 'GPL-3-only' etc. license variants for better auditing
Date: Sat, 21 Sep 2019 18:09:20 +0200	[thread overview]
Message-ID: <c8f0dbac2310d90456ea17ecc50d79acbe82d50e.camel@gentoo.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 2705 bytes --]

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.

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

             reply	other threads:[~2019-09-21 16:09 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-21 16:09 Michał Górny [this message]
2019-09-21 16:57 ` [gentoo-dev] [RFC] Adding 'GPL-2-only', 'GPL-3-only' etc. license variants for better auditing 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 ` [gentoo-dev] " Richard Yao

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=c8f0dbac2310d90456ea17ecc50d79acbe82d50e.camel@gentoo.org \
    --to=mgorny@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