From: Greg KH <gregkh@linuxfoundation.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Jonathan Corbet <corbet@lwn.net>, Jessica Yu <jeyu@kernel.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Rusty Russell <rusty@rustcorp.com.au>,
Christoph Hellwig <hch@lst.de>,
Kate Stewart <kstewart@linuxfoundation.org>,
Philippe Ombredanne <pombredanne@nexb.com>
Subject: Re: [PATCH][RFC] module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity
Date: Tue, 29 Jan 2019 06:27:03 +0100 [thread overview]
Message-ID: <20190129052703.GA9753@kroah.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1901282105450.1669@nanos.tec.linutronix.de>
On Mon, Jan 28, 2019 at 11:38:42PM +0100, Thomas Gleixner wrote:
> The original MODULE_LICENSE string for kernel modules licensed under the
> GPL v2 (only / or later) was simply "GPL", which was - and still is -
> completely sufficient for the purpose of module loading and checking
> whether the module is free software or proprietary.
>
> In January 2003 this was changed with commit 3344ea3ad4b7 ("[PATCH]
> MODULE_LICENSE and EXPORT_SYMBOL_GPL support"). This commit can be found in
> the history git repository which holds the 1:1 import of Linus' bitkeeper
> repository:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=3344ea3ad4b7c302c846a680dbaeedf96ed45c02
>
> The main intention of the patch was to refuse linking proprietary modules
> against symbols exported with EXPORT_SYMBOL_GPL() at module load time.
>
> As a completely undocumented side effect it also introduced the distinction
> between "GPL" and "GPL v2" MODULE_LICENSE() strings:
>
> * "GPL" [GNU Public License v2 or later]
> * "GPL v2" [GNU Public License v2]
> * "GPL and additional rights" [GNU Public License v2 rights and more]
> * "Dual BSD/GPL" [GNU Public License v2
> * or BSD license choice]
> * "Dual MPL/GPL" [GNU Public License v2
> * or Mozilla license choice]
>
> This distinction was and still is wrong in several aspects:
>
> 1) It broke all modules which were using the "GPL" string in the
> MODULE_LICENSE() already and were licensed under GPL v2 only.
>
> A quick license scan over the tree at that time shows that at least 480
> out of 1484 modules have been affected by this change back then. The
> number is probably way higher as this was just a quick check for
> clearly identifiable license information.
>
> There was exactly ONE instance of a "GPL v2" module license string in
> the kernel back then - drivers/net/tulip/xircom_tulip_cb.c which
> otherwise had no license information at all. There is no indication
> that the change above is any way related to this driver. The change
> happend with the 2.4.11 release which was on Oct. 9 2001 - so quite
> some time before the above commit. Unfortunately there is no trace on
> the intertubes to any discussion of this.
>
> 2) The dual licensed strings became ill defined as well because following
> the "GPL" vs. "GPL v2" distinction all dual licensed (or additional
> rights) MODULE_LICENSE strings would either require those dual licensed
> modules to be licensed under GPL v2 or later or just be unspecified for
> the dual licensing case. Neither choice is coherent with the GPL
> distinction.
>
> Due to the lack of a proper changelog and no real discussion on the patch
> submission other than a few implementation details, it's completely unclear
> why this distinction was introduced at all. Other than the comment in the
> module header file exists no documentation for this at all.
>
> From a license compliance and license scanning POV this distinction is a
> total nightmare.
Many thanks for digging through all of this, it should help out a lot:
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
next prev parent reply other threads:[~2019-01-29 5:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-28 22:38 [PATCH][RFC] module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity Thomas Gleixner
2019-01-29 1:32 ` Joe Perches
2019-01-29 5:27 ` Greg KH [this message]
2019-01-29 13:06 ` Jessica Yu
2019-01-29 14:11 ` Thomas Gleixner
2019-01-30 20:48 ` Alan Cox
2019-01-30 21:47 ` Thomas Gleixner
2019-02-07 0:21 ` Jonathan Corbet
2019-02-08 16:02 ` [PATCH v2] " Thomas Gleixner
2019-02-09 9:37 ` Philippe Ombredanne
2019-02-09 12:11 ` Greg KH
2019-02-10 18:58 ` Thomas Gleixner
2019-02-11 15:19 ` Jonathan Corbet
2019-02-11 8:44 ` Jessica Yu
2019-01-30 5:01 ` [PATCH][RFC] " Rusty Russell
2019-01-30 18:21 ` Thomas Gleixner
2019-01-30 20:45 ` Alan Cox
2019-01-30 22:00 ` Thomas Gleixner
2019-01-31 15:18 ` Philippe Ombredanne
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=20190129052703.GA9753@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=corbet@lwn.net \
--cc=hch@lst.de \
--cc=jeyu@kernel.org \
--cc=kstewart@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pombredanne@nexb.com \
--cc=rusty@rustcorp.com.au \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.