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.
As of 5.0-rc2 2873 out of 9200 instances of MODULE_LICENSE() strings are
conflicting with the actual license in the source code (either SPDX or
license boilerplate/reference). A comparison between the scan of the
history tree and a scan of current Linus tree shows to the extent that the
git rename detection over Linus tree grafted with the history tree is
halfways complete that almost none of the files which got broken in 2003
have been cleaned up vs. the MODULE_LICENSE string. So subtracting those
480 known instances from the conflicting 2800 of today more than 25% of the
module authors got it wrong and it's a high propability that a large
portion of the rest just got it right by chance.
There is no value for the module loader to convey the detailed license
information as the only decision to be made is whether the module is free
software or not.
The "and additional rights", "BSD" and "MPL" strings are not conclusive
license information either. So there is no point in trying to make the GPL
part conclusive and exact. As shown above it's already non conclusive for
dual licensing and incoherent with a large portion of the module source.
As an unintended side effect this distinction causes a major headache for
license compliance, license scanners and the ongoing effort to clean up the
license mess of the kernel.
Therefore remove the well meant, but ill defined, distinction between "GPL"
and "GPL v2" and document that:
- "GPL" and "GPL v2" both express that the module is licensed under GPLv2
(without a distinction of 'only' and 'or later') and is therefore kernel
license compliant.
- None of the MODULE_LICENSE strings can be used for expressing or
determining the exact license
- Their sole purpose is to decide whether the module is free software or
not.
Add a MODULE_LICENSE subsection to the license rule documentation as well.
Signed-off-by: Thomas Gleixner <[email protected]>
---
Documentation/process/license-rules.rst | 62 ++++++++++++++++++++++++++++++++
include/linux/module.h | 18 ++++++++-
2 files changed, 79 insertions(+), 1 deletion(-)
--- a/Documentation/process/license-rules.rst
+++ b/Documentation/process/license-rules.rst
@@ -372,3 +372,65 @@ in the LICENSE subdirectories. This is r
verification (e.g. checkpatch.pl) and to have the licenses ready to read
and extract right from the source, which is recommended by various FOSS
organizations, e.g. the `FSFE REUSE initiative <https://reuse.software/>`_.
+
+_`MODULE_LICENSE`
+-----------------
+
+ Loadable kernel modules also require a MODULE_LICENSE() tag. This tag is
+ neither a replacement for proper source code license information
+ (SPDX-License-Identifier) nor in any way relevant for expressing or
+ determining the exact license under which the source code of the module
+ is provided.
+
+ The sole purpose of this tag is to provide sufficient information
+ whether the module is free software or proprietary for the kernel
+ module loader and for user space tools.
+
+ The valid license strings for MODULE_LICENSE() are:
+
+ ============================= =============================================
+ "GPL" Module is licensed under GPL version 2. This
+ does not express any distinction between
+ GPL-2.0-only or GPL-2.0-or-later. The exact
+ license information can only be determined
+ via the license information in the
+ corresponding source files.
+
+ "GPL v2" Same as "GPL v2". It exists for historic
+ reasons.
+
+ "GPL and additional rights" Historical variant of expressing that the
+ module source is dual licensed under a
+ GPL v2 variant and MIT license. Please do
+ not use in new code.
+
+ "Dual MIT/GPL" The correct way of expressing that the
+ module is dual licensed under a GPL v2
+ variant or MIT license choice.
+
+ "Dual BSD/GPL" The module is dual licensed under a GPL v2
+ variant or BSD license choice. The exact
+ variant of the BSD license can only be
+ determined via the license information
+ in the corresponding source files.
+
+ "Dual MPL/GPL" The module is dual licensed under a GPL v2
+ variant or Mozilla Public License (MPL)
+ choice. The exact variant of the MPL
+ license can only be determined via the
+ license information in the corresponding
+ source files.
+
+ "Proprietary" The module is under a proprietary license.
+ This string is soleley for proprietary third
+ party modules and cannot be used for modules
+ which have their source code in the kernel
+ tree. Modules tagged that way are tainting
+ the kernel with the 'P' flag when loaded and
+ the kernel module loader refuses to link such
+ modules against symbols which are exported
+ with EXPORT_SYMBOL_GPL().
+ ============================= =============================================
+
+
+
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -172,7 +172,7 @@ extern void cleanup_module(void);
* The following license idents are currently accepted as indicating free
* software modules
*
- * "GPL" [GNU Public License v2 or later]
+ * "GPL" [GNU Public License v2]
* "GPL v2" [GNU Public License v2]
* "GPL and additional rights" [GNU Public License v2 rights and more]
* "Dual BSD/GPL" [GNU Public License v2
@@ -186,6 +186,22 @@ extern void cleanup_module(void);
*
* "Proprietary" [Non free products]
*
+ * Both "GPL v2" and "GPL" (the latter also in dual licensed strings) are
+ * merily stating that the module is licensed under the GPL v2, but are not
+ * telling whether "GPL v2 only" or "GPL v2 or later". The reason why there
+ * are two variants is a historic and failed attempt to convey more
+ * information in the MODULE_LICENSE string. For module loading the
+ * "only/or later" distinction is completely irrelevant and does neither
+ * replace the proper license identifiers in the corresponding source file
+ * nor amends them in any way. The sole purpose is to make the
+ * 'Proprietary' flagging work and to refuse to bind symbols which are
+ * exported with EXPORT_SYMBOL_GPL when a non free module is loaded.
+ *
+ * In the same way "BSD" is not a clear license information. It merily
+ * states, that the module is licensed under one of the compatible BSD
+ * license variants. The detailed and correct license information is again
+ * to be found in the corresponding source files.
+ *
* There are dual licensed components, but when running with Linux it is the
* GPL that is relevant so this is a non issue. Similarly LGPL linked with GPL
* is a GPL combined work.
On Mon, 2019-01-28 at 23:38 +0100, Thomas Gleixner wrote:
> Therefore remove the well meant, but ill defined, distinction between "GPL"
> and "GPL v2" and document that:
>
> - "GPL" and "GPL v2" both express that the module is licensed under GPLv2
> (without a distinction of 'only' and 'or later') and is therefore kernel
> license compliant.
>
> - None of the MODULE_LICENSE strings can be used for expressing or
> determining the exact license
>
> - Their sole purpose is to decide whether the module is free software or
> not.
Thanks Thomas.
Acked-by: Joe Perches <[email protected]>
if you want that.
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 <[email protected]>
+++ Thomas Gleixner [28/01/19 23:38 +0100]:
>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.
>
>As of 5.0-rc2 2873 out of 9200 instances of MODULE_LICENSE() strings are
>conflicting with the actual license in the source code (either SPDX or
>license boilerplate/reference). A comparison between the scan of the
>history tree and a scan of current Linus tree shows to the extent that the
>git rename detection over Linus tree grafted with the history tree is
>halfways complete that almost none of the files which got broken in 2003
>have been cleaned up vs. the MODULE_LICENSE string. So subtracting those
>480 known instances from the conflicting 2800 of today more than 25% of the
>module authors got it wrong and it's a high propability that a large
>portion of the rest just got it right by chance.
>
>There is no value for the module loader to convey the detailed license
>information as the only decision to be made is whether the module is free
>software or not.
>
>The "and additional rights", "BSD" and "MPL" strings are not conclusive
>license information either. So there is no point in trying to make the GPL
>part conclusive and exact. As shown above it's already non conclusive for
>dual licensing and incoherent with a large portion of the module source.
>
>As an unintended side effect this distinction causes a major headache for
>license compliance, license scanners and the ongoing effort to clean up the
>license mess of the kernel.
>
>Therefore remove the well meant, but ill defined, distinction between "GPL"
>and "GPL v2" and document that:
>
> - "GPL" and "GPL v2" both express that the module is licensed under GPLv2
> (without a distinction of 'only' and 'or later') and is therefore kernel
> license compliant.
>
> - None of the MODULE_LICENSE strings can be used for expressing or
> determining the exact license
>
> - Their sole purpose is to decide whether the module is free software or
> not.
>
>Add a MODULE_LICENSE subsection to the license rule documentation as well.
>
>Signed-off-by: Thomas Gleixner <[email protected]>
>---
> Documentation/process/license-rules.rst | 62 ++++++++++++++++++++++++++++++++
> include/linux/module.h | 18 ++++++++-
> 2 files changed, 79 insertions(+), 1 deletion(-)
>--- a/Documentation/process/license-rules.rst
>+++ b/Documentation/process/license-rules.rst
>@@ -372,3 +372,65 @@ in the LICENSE subdirectories. This is r
> verification (e.g. checkpatch.pl) and to have the licenses ready to read
> and extract right from the source, which is recommended by various FOSS
> organizations, e.g. the `FSFE REUSE initiative <https://reuse.software/>`_.
>+
>+_`MODULE_LICENSE`
>+-----------------
>+
>+ Loadable kernel modules also require a MODULE_LICENSE() tag. This tag is
>+ neither a replacement for proper source code license information
>+ (SPDX-License-Identifier) nor in any way relevant for expressing or
>+ determining the exact license under which the source code of the module
>+ is provided.
>+
>+ The sole purpose of this tag is to provide sufficient information
>+ whether the module is free software or proprietary for the kernel
>+ module loader and for user space tools.
>+
>+ The valid license strings for MODULE_LICENSE() are:
>+
>+ ============================= =============================================
>+ "GPL" Module is licensed under GPL version 2. This
>+ does not express any distinction between
>+ GPL-2.0-only or GPL-2.0-or-later. The exact
>+ license information can only be determined
>+ via the license information in the
>+ corresponding source files.
>+
>+ "GPL v2" Same as "GPL v2". It exists for historic
>+ reasons.
Did you mean to say 'Same as "GPL"' here? (as in, "GPL v2" conveys the same
information as the "GPL" module license string)
>+
>+ "GPL and additional rights" Historical variant of expressing that the
>+ module source is dual licensed under a
>+ GPL v2 variant and MIT license. Please do
>+ not use in new code.
>+
>+ "Dual MIT/GPL" The correct way of expressing that the
>+ module is dual licensed under a GPL v2
>+ variant or MIT license choice.
>+
>+ "Dual BSD/GPL" The module is dual licensed under a GPL v2
>+ variant or BSD license choice. The exact
>+ variant of the BSD license can only be
>+ determined via the license information
>+ in the corresponding source files.
>+
>+ "Dual MPL/GPL" The module is dual licensed under a GPL v2
>+ variant or Mozilla Public License (MPL)
>+ choice. The exact variant of the MPL
>+ license can only be determined via the
>+ license information in the corresponding
>+ source files.
>+
>+ "Proprietary" The module is under a proprietary license.
>+ This string is soleley for proprietary third
s/soleley/solely/
Otherwise looks good. Thanks for clearing this all up.
Jessica
>+ party modules and cannot be used for modules
>+ which have their source code in the kernel
>+ tree. Modules tagged that way are tainting
>+ the kernel with the 'P' flag when loaded and
>+ the kernel module loader refuses to link such
>+ modules against symbols which are exported
>+ with EXPORT_SYMBOL_GPL().
>+ ============================= =============================================
>+
>+
>+
>--- a/include/linux/module.h
>+++ b/include/linux/module.h
>@@ -172,7 +172,7 @@ extern void cleanup_module(void);
> * The following license idents are currently accepted as indicating free
> * software modules
> *
>- * "GPL" [GNU Public License v2 or later]
>+ * "GPL" [GNU Public License v2]
> * "GPL v2" [GNU Public License v2]
> * "GPL and additional rights" [GNU Public License v2 rights and more]
> * "Dual BSD/GPL" [GNU Public License v2
>@@ -186,6 +186,22 @@ extern void cleanup_module(void);
> *
> * "Proprietary" [Non free products]
> *
>+ * Both "GPL v2" and "GPL" (the latter also in dual licensed strings) are
>+ * merily stating that the module is licensed under the GPL v2, but are not
>+ * telling whether "GPL v2 only" or "GPL v2 or later". The reason why there
>+ * are two variants is a historic and failed attempt to convey more
>+ * information in the MODULE_LICENSE string. For module loading the
>+ * "only/or later" distinction is completely irrelevant and does neither
>+ * replace the proper license identifiers in the corresponding source file
>+ * nor amends them in any way. The sole purpose is to make the
>+ * 'Proprietary' flagging work and to refuse to bind symbols which are
>+ * exported with EXPORT_SYMBOL_GPL when a non free module is loaded.
>+ *
>+ * In te same way "BSD" is not a clear license information. It merily
>+ * states, that the module is licensed under one of the compatible BSD
>+ * license variants. The detailed and correct license information is again
>+ * to be found in the corresponding source files.
>+ *
> * There are dual licensed components, but when running with Linux it is the
> * GPL that is relevant so this is a non issue. Similarly LGPL linked with GPL
> * is a GPL combined work.
On Tue, 29 Jan 2019, Jessica Yu wrote:
> +++ Thomas Gleixner [28/01/19 23:38 +0100]:
> > + "GPL" Module is licensed under GPL version 2. This
> > + does not express any distinction between
> > + GPL-2.0-only or GPL-2.0-or-later. The exact
> > + license information can only be determined
> > + via the license information in the
> > + corresponding source files.
> > +
> > + "GPL v2" Same as "GPL v2". It exists for historic
> > + reasons.
>
> Did you mean to say 'Same as "GPL"' here? (as in, "GPL v2" conveys the same
> information as the "GPL" module license string)
Of course. After staring at all this for too long I confused myself and did
not spot it even if I read through the whole thing several times.
> > +
> > + "GPL and additional rights" Historical variant of expressing that the
> > + module source is dual licensed under a
> > + GPL v2 variant and MIT license. Please do
> > + not use in new code.
> > +
> > + "Dual MIT/GPL" The correct way of expressing that the
> > + module is dual licensed under a GPL v2
> > + variant or MIT license choice.
> > +
> > + "Dual BSD/GPL" The module is dual licensed under a GPL v2
> > + variant or BSD license choice. The exact
> > + variant of the BSD license can only be
> > + determined via the license information
> > + in the corresponding source files.
> > +
> > + "Dual MPL/GPL" The module is dual licensed under a GPL v2
> > + variant or Mozilla Public License (MPL)
> > + choice. The exact variant of the MPL
> > + license can only be determined via the
> > + license information in the corresponding
> > + source files.
> > +
> > + "Proprietary" The module is under a proprietary license.
> > + This string is soleley for proprietary third
>
> s/soleley/solely/
>
> Otherwise looks good. Thanks for clearing this all up.
Thanks for having a sharp look!
tglx
Thanks taking on such a thankless task Thomas,
Might have been overzealous in assuming a verionless GPL string meant
"or later" (I'm happy for that for my own code, FWIW). My memory is
fuzzy, but I don't think anyone cared at the time.
Frankly, this should be autogenerated rather than "fixed" if we want
this done properly.
Cheers,
Rusty.
Thomas Gleixner <[email protected]> writes:
> 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.
>
> As of 5.0-rc2 2873 out of 9200 instances of MODULE_LICENSE() strings are
> conflicting with the actual license in the source code (either SPDX or
> license boilerplate/reference). A comparison between the scan of the
> history tree and a scan of current Linus tree shows to the extent that the
> git rename detection over Linus tree grafted with the history tree is
> halfways complete that almost none of the files which got broken in 2003
> have been cleaned up vs. the MODULE_LICENSE string. So subtracting those
> 480 known instances from the conflicting 2800 of today more than 25% of the
> module authors got it wrong and it's a high propability that a large
> portion of the rest just got it right by chance.
>
> There is no value for the module loader to convey the detailed license
> information as the only decision to be made is whether the module is free
> software or not.
>
> The "and additional rights", "BSD" and "MPL" strings are not conclusive
> license information either. So there is no point in trying to make the GPL
> part conclusive and exact. As shown above it's already non conclusive for
> dual licensing and incoherent with a large portion of the module source.
>
> As an unintended side effect this distinction causes a major headache for
> license compliance, license scanners and the ongoing effort to clean up the
> license mess of the kernel.
>
> Therefore remove the well meant, but ill defined, distinction between "GPL"
> and "GPL v2" and document that:
>
> - "GPL" and "GPL v2" both express that the module is licensed under GPLv2
> (without a distinction of 'only' and 'or later') and is therefore kernel
> license compliant.
>
> - None of the MODULE_LICENSE strings can be used for expressing or
> determining the exact license
>
> - Their sole purpose is to decide whether the module is free software or
> not.
>
> Add a MODULE_LICENSE subsection to the license rule documentation as well.
>
> Signed-off-by: Thomas Gleixner <[email protected]>
> ---
> Documentation/process/license-rules.rst | 62 ++++++++++++++++++++++++++++++++
> include/linux/module.h | 18 ++++++++-
> 2 files changed, 79 insertions(+), 1 deletion(-)
> --- a/Documentation/process/license-rules.rst
> +++ b/Documentation/process/license-rules.rst
> @@ -372,3 +372,65 @@ in the LICENSE subdirectories. This is r
> verification (e.g. checkpatch.pl) and to have the licenses ready to read
> and extract right from the source, which is recommended by various FOSS
> organizations, e.g. the `FSFE REUSE initiative <https://reuse.software/>`_.
> +
> +_`MODULE_LICENSE`
> +-----------------
> +
> + Loadable kernel modules also require a MODULE_LICENSE() tag. This tag is
> + neither a replacement for proper source code license information
> + (SPDX-License-Identifier) nor in any way relevant for expressing or
> + determining the exact license under which the source code of the module
> + is provided.
> +
> + The sole purpose of this tag is to provide sufficient information
> + whether the module is free software or proprietary for the kernel
> + module loader and for user space tools.
> +
> + The valid license strings for MODULE_LICENSE() are:
> +
> + ============================= =============================================
> + "GPL" Module is licensed under GPL version 2. This
> + does not express any distinction between
> + GPL-2.0-only or GPL-2.0-or-later. The exact
> + license information can only be determined
> + via the license information in the
> + corresponding source files.
> +
> + "GPL v2" Same as "GPL v2". It exists for historic
> + reasons.
> +
> + "GPL and additional rights" Historical variant of expressing that the
> + module source is dual licensed under a
> + GPL v2 variant and MIT license. Please do
> + not use in new code.
> +
> + "Dual MIT/GPL" The correct way of expressing that the
> + module is dual licensed under a GPL v2
> + variant or MIT license choice.
> +
> + "Dual BSD/GPL" The module is dual licensed under a GPL v2
> + variant or BSD license choice. The exact
> + variant of the BSD license can only be
> + determined via the license information
> + in the corresponding source files.
> +
> + "Dual MPL/GPL" The module is dual licensed under a GPL v2
> + variant or Mozilla Public License (MPL)
> + choice. The exact variant of the MPL
> + license can only be determined via the
> + license information in the corresponding
> + source files.
> +
> + "Proprietary" The module is under a proprietary license.
> + This string is soleley for proprietary third
> + party modules and cannot be used for modules
> + which have their source code in the kernel
> + tree. Modules tagged that way are tainting
> + the kernel with the 'P' flag when loaded and
> + the kernel module loader refuses to link such
> + modules against symbols which are exported
> + with EXPORT_SYMBOL_GPL().
> + ============================= =============================================
> +
> +
> +
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -172,7 +172,7 @@ extern void cleanup_module(void);
> * The following license idents are currently accepted as indicating free
> * software modules
> *
> - * "GPL" [GNU Public License v2 or later]
> + * "GPL" [GNU Public License v2]
> * "GPL v2" [GNU Public License v2]
> * "GPL and additional rights" [GNU Public License v2 rights and more]
> * "Dual BSD/GPL" [GNU Public License v2
> @@ -186,6 +186,22 @@ extern void cleanup_module(void);
> *
> * "Proprietary" [Non free products]
> *
> + * Both "GPL v2" and "GPL" (the latter also in dual licensed strings) are
> + * merily stating that the module is licensed under the GPL v2, but are not
> + * telling whether "GPL v2 only" or "GPL v2 or later". The reason why there
> + * are two variants is a historic and failed attempt to convey more
> + * information in the MODULE_LICENSE string. For module loading the
> + * "only/or later" distinction is completely irrelevant and does neither
> + * replace the proper license identifiers in the corresponding source file
> + * nor amends them in any way. The sole purpose is to make the
> + * 'Proprietary' flagging work and to refuse to bind symbols which are
> + * exported with EXPORT_SYMBOL_GPL when a non free module is loaded.
> + *
> + * In the same way "BSD" is not a clear license information. It merily
> + * states, that the module is licensed under one of the compatible BSD
> + * license variants. The detailed and correct license information is again
> + * to be found in the corresponding source files.
> + *
> * There are dual licensed components, but when running with Linux it is the
> * GPL that is relevant so this is a non issue. Similarly LGPL linked with GPL
> * is a GPL combined work.
On Wed, 30 Jan 2019, Rusty Russell wrote:
> Thanks taking on such a thankless task Thomas,
>
> Might have been overzealous in assuming a verionless GPL string meant
> "or later" (I'm happy for that for my own code, FWIW). My memory is
> fuzzy, but I don't think anyone cared at the time.
>
> Frankly, this should be autogenerated rather than "fixed" if we want
> this done properly.
Yes, but for that we need to have the SPDX-Identifiers in place and the
whole licensing mess of the kernel cleaned up. We're working on that, but
that's a herculanean task.
Btw, this was the third thing on that day which made me curse a certain
Rusty dude. Guess what the other presents were which that guy
left.... hotplug and futexes.
Somehow that all that stuff sticks to me now and because that dude left
into buzzword land I can't make him fix it anymore :)
Thanks,
tglx
> > > + "GPL and additional rights" Historical variant of expressing that the
> > > + module source is dual licensed under a
> > > + GPL v2 variant and MIT license. Please do
> > > + not use in new code.
Actually it was a historic fix for the fact that some slimeballs were
going to use a proposed "BSD" tag and just ship binaries only whilst
claiming that they were totally compliant with the BSD licence.
Alan
On Wed, 30 Jan 2019 15:31:20 +1030
Rusty Russell <[email protected]> wrote:
> Thanks taking on such a thankless task Thomas,
>
> Might have been overzealous in assuming a verionless GPL string meant
> "or later" (I'm happy for that for my own code, FWIW). My memory is
> fuzzy, but I don't think anyone cared at the time.
Versionless always meant 'or later' outside of the tags. It's the default
version of the licence. (Whether v2 only has any meaning beyond intent is
another debate that I guess some year a lawyer will have to figure out).
I think the description change makes sense given the ambiguity and the
fact we now have SPDX headers. (IANAL etc)
> > 2) The dual licensed strings became ill defined as well because following
> > the "GPL" vs. "GPL v2" distinction all dual licensed (or additional
The dual ones were IMHO a mistake. They should just have used GPL and
additional rights. Either you have GPL rights (and it's ok to use in the
kernel) or you don't (and it's proprietary and the rest is down to
derivative works).
We don't actually care whether its dual licensed BSD, or whether it
merely grants you an additional right to cheap pizza.
> > As of 5.0-rc2 2873 out of 9200 instances of MODULE_LICENSE() strings are
> > conflicting with the actual license in the source code (either SPDX or
> > license boilerplate/reference). A comparison between the scan of the
The SPDX tag isn't correctly capable of expressing the licence anyway. If
you have functions in a file and two of them are GPL v2+ and someone
added a GPLv2 only one and updated the header there isn't a valid SPDX tag
for it because I can still use the GPLv2+ bits with GPLv3.
This is nothing new - the headers on the files provided no more data on
that and took up lots more space 8) We've simply never tracked licence
data by line.
Alan
On Wed, 30 Jan 2019, Alan Cox wrote:
> > > > + "GPL and additional rights" Historical variant of expressing that the
> > > > + module source is dual licensed under a
> > > > + GPL v2 variant and MIT license. Please do
> > > > + not use in new code.
>
> Actually it was a historic fix for the fact that some slimeballs were
> going to use a proposed "BSD" tag and just ship binaries only whilst
> claiming that they were totally compliant with the BSD licence.
Ah, that is valuable information. I spent quite some time NOT to find it :)
Thanks,
tglx
On Wed, 30 Jan 2019, Alan Cox wrote:
> On Wed, 30 Jan 2019 15:31:20 +1030
> Rusty Russell <[email protected]> wrote:
>
> > Thanks taking on such a thankless task Thomas,
> >
> > Might have been overzealous in assuming a verionless GPL string meant
> > "or later" (I'm happy for that for my own code, FWIW). My memory is
> > fuzzy, but I don't think anyone cared at the time.
>
> Versionless always meant 'or later' outside of the tags. It's the default
> version of the licence. (Whether v2 only has any meaning beyond intent is
> another debate that I guess some year a lawyer will have to figure out).
>
> I think the description change makes sense given the ambiguity and the
> fact we now have SPDX headers. (IANAL etc)
>
> > > 2) The dual licensed strings became ill defined as well because following
> > > the "GPL" vs. "GPL v2" distinction all dual licensed (or additional
>
> The dual ones were IMHO a mistake. They should just have used GPL and
> additional rights. Either you have GPL rights (and it's ok to use in the
> kernel) or you don't (and it's proprietary and the rest is down to
> derivative works).
>
> We don't actually care whether its dual licensed BSD, or whether it
> merely grants you an additional right to cheap pizza.
Actually for the purpose of module loading the only relevant information is
whether there are GPL rights or not. Whether there are additional rights is
irrelevant for the binary blob. That only matters vs. the source code
itself.
> > > As of 5.0-rc2 2873 out of 9200 instances of MODULE_LICENSE() strings are
> > > conflicting with the actual license in the source code (either SPDX or
> > > license boilerplate/reference). A comparison between the scan of the
>
> The SPDX tag isn't correctly capable of expressing the licence anyway. If
> you have functions in a file and two of them are GPL v2+ and someone
> added a GPLv2 only one and updated the header there isn't a valid SPDX tag
> for it because I can still use the GPLv2+ bits with GPLv3.
>
> This is nothing new - the headers on the files provided no more data on
> that and took up lots more space 8) We've simply never tracked licence
> data by line.
Correct, there are files which have both a v2 only and a v2 or later
boilerplate and there is no way to figure out what that actually means for
the affected source file.
I found a recent patch adding the v2 or later boilerplate right next to the
v2 only and the patch content is mostly fiddling with the existing code.
Most people simply do not care and I'd say most do not understand what
licensing means in the first place. But at the same time a lot of people do
not care at all what they are doing.
Thanks,
tglx
Thomas:
On Mon, Jan 28, 2019 at 11:39 PM Thomas Gleixner <[email protected]> wrote:
[...]
> As an unintended side effect this distinction causes a major headache for
> license compliance, license scanners and the ongoing effort to clean up the
> license mess of the kernel.
Glad to be of service and sorry for having helped a bit surface these!
>
> Therefore remove the well meant, but ill defined, distinction between "GPL"
> and "GPL v2" and document that:
>
> - "GPL" and "GPL v2" both express that the module is licensed under GPLv2
> (without a distinction of 'only' and 'or later') and is therefore kernel
> license compliant.
>
> - None of the MODULE_LICENSE strings can be used for expressing or
> determining the exact license
>
> - Their sole purpose is to decide whether the module is free software or
> not.
>
> Add a MODULE_LICENSE subsection to the license rule documentation as well.
>
> Signed-off-by: Thomas Gleixner <[email protected]>
Thank you ++ for documenting all this : this is a small change but a big
step towards licensing clarity! Great that you found the commit that
introduced this too.
Feel free to add this if you want:
Acked-by: Philippe Ombredanne <[email protected]>
--
Cordially
Philippe Ombredanne
On Tue, 29 Jan 2019 15:11:40 +0100 (CET)
Thomas Gleixner <[email protected]> wrote:
> On Tue, 29 Jan 2019, Jessica Yu wrote:
> > +++ Thomas Gleixner [28/01/19 23:38 +0100]:
> > > + "GPL" Module is licensed under GPL version 2. This
> > > + does not express any distinction between
> > > + GPL-2.0-only or GPL-2.0-or-later. The exact
> > > + license information can only be determined
> > > + via the license information in the
> > > + corresponding source files.
> > > +
> > > + "GPL v2" Same as "GPL v2". It exists for historic
> > > + reasons.
> >
> > Did you mean to say 'Same as "GPL"' here? (as in, "GPL v2" conveys the same
> > information as the "GPL" module license string)
>
> Of course. After staring at all this for too long I confused myself and did
> not spot it even if I read through the whole thing several times.
Were you thinking of sending a new version with tweaks? I can happy apply
this version with this fix if you prefer, let me know...
Thanks,
jon
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.
As of 5.0-rc2 2873 out of 9200 instances of MODULE_LICENSE() strings are
conflicting with the actual license in the source code (either SPDX or
license boilerplate/reference). A comparison between the scan of the
history tree and a scan of current Linus tree shows to the extent that the
git rename detection over Linus tree grafted with the history tree is
halfways complete that almost none of the files which got broken in 2003
have been cleaned up vs. the MODULE_LICENSE string. So subtracting those
480 known instances from the conflicting 2800 of today more than 25% of the
module authors got it wrong and it's a high propability that a large
portion of the rest just got it right by chance.
There is no value for the module loader to convey the detailed license
information as the only decision to be made is whether the module is free
software or not.
The "and additional rights", "BSD" and "MPL" strings are not conclusive
license information either. So there is no point in trying to make the GPL
part conclusive and exact. As shown above it's already non conclusive for
dual licensing and incoherent with a large portion of the module source.
As an unintended side effect this distinction causes a major headache for
license compliance, license scanners and the ongoing effort to clean up the
license mess of the kernel.
Therefore remove the well meant, but ill defined, distinction between "GPL"
and "GPL v2" and document that:
- "GPL" and "GPL v2" both express that the module is licensed under GPLv2
(without a distinction of 'only' and 'or later') and is therefore kernel
license compliant.
- None of the MODULE_LICENSE strings can be used for expressing or
determining the exact license
- Their sole purpose is to decide whether the module is free software or
not.
Add a MODULE_LICENSE subsection to the license rule documentation as well.
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Philippe Ombredanne <[email protected]>
Acked-by: Joe Perches <[email protected]>
---
V2: Fixed the "GPL v2" hickup and the typo spotted by Jessica.
Documentation/process/license-rules.rst | 62 ++++++++++++++++++++++++++++++++
include/linux/module.h | 18 ++++++++-
2 files changed, 79 insertions(+), 1 deletion(-)
--- a/Documentation/process/license-rules.rst
+++ b/Documentation/process/license-rules.rst
@@ -372,3 +372,65 @@ in the LICENSE subdirectories. This is r
verification (e.g. checkpatch.pl) and to have the licenses ready to read
and extract right from the source, which is recommended by various FOSS
organizations, e.g. the `FSFE REUSE initiative <https://reuse.software/>`_.
+
+_`MODULE_LICENSE`
+-----------------
+
+ Loadable kernel modules also require a MODULE_LICENSE() tag. This tag is
+ neither a replacement for proper source code license information
+ (SPDX-License-Identifier) nor in any way relevant for expressing or
+ determining the exact license under which the source code of the module
+ is provided.
+
+ The sole purpose of this tag is to provide sufficient information
+ whether the module is free software or proprietary for the kernel
+ module loader and for user space tools.
+
+ The valid license strings for MODULE_LICENSE() are:
+
+ ============================= =============================================
+ "GPL" Module is licensed under GPL version 2. This
+ does not express any distinction between
+ GPL-2.0-only or GPL-2.0-or-later. The exact
+ license information can only be determined
+ via the license information in the
+ corresponding source files.
+
+ "GPL v2" Same as "GPL". It exists for historic
+ reasons.
+
+ "GPL and additional rights" Historical variant of expressing that the
+ module source is dual licensed under a
+ GPL v2 variant and MIT license. Please do
+ not use in new code.
+
+ "Dual MIT/GPL" The correct way of expressing that the
+ module is dual licensed under a GPL v2
+ variant or MIT license choice.
+
+ "Dual BSD/GPL" The module is dual licensed under a GPL v2
+ variant or BSD license choice. The exact
+ variant of the BSD license can only be
+ determined via the license information
+ in the corresponding source files.
+
+ "Dual MPL/GPL" The module is dual licensed under a GPL v2
+ variant or Mozilla Public License (MPL)
+ choice. The exact variant of the MPL
+ license can only be determined via the
+ license information in the corresponding
+ source files.
+
+ "Proprietary" The module is under a proprietary license.
+ This string is solely for proprietary third
+ party modules and cannot be used for modules
+ which have their source code in the kernel
+ tree. Modules tagged that way are tainting
+ the kernel with the 'P' flag when loaded and
+ the kernel module loader refuses to link such
+ modules against symbols which are exported
+ with EXPORT_SYMBOL_GPL().
+ ============================= =============================================
+
+
+
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -172,7 +172,7 @@ extern void cleanup_module(void);
* The following license idents are currently accepted as indicating free
* software modules
*
- * "GPL" [GNU Public License v2 or later]
+ * "GPL" [GNU Public License v2]
* "GPL v2" [GNU Public License v2]
* "GPL and additional rights" [GNU Public License v2 rights and more]
* "Dual BSD/GPL" [GNU Public License v2
@@ -186,6 +186,22 @@ extern void cleanup_module(void);
*
* "Proprietary" [Non free products]
*
+ * Both "GPL v2" and "GPL" (the latter also in dual licensed strings) are
+ * merily stating that the module is licensed under the GPL v2, but are not
+ * telling whether "GPL v2 only" or "GPL v2 or later". The reason why there
+ * are two variants is a historic and failed attempt to convey more
+ * information in the MODULE_LICENSE string. For module loading the
+ * "only/or later" distinction is completely irrelevant and does neither
+ * replace the proper license identifiers in the corresponding source file
+ * nor amends them in any way. The sole purpose is to make the
+ * 'Proprietary' flagging work and to refuse to bind symbols which are
+ * exported with EXPORT_SYMBOL_GPL when a non free module is loaded.
+ *
+ * In the same way "BSD" is not a clear license information. It merily
+ * states, that the module is licensed under one of the compatible BSD
+ * license variants. The detailed and correct license information is again
+ * to be found in the corresponding source files.
+ *
* There are dual licensed components, but when running with Linux it is the
* GPL that is relevant so this is a non issue. Similarly LGPL linked with GPL
* is a GPL combined work.
Hi Thomas:
On Fri, Feb 8, 2019 at 5:03 PM Thomas Gleixner <[email protected]> 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.
>
> As of 5.0-rc2 2873 out of 9200 instances of MODULE_LICENSE() strings are
> conflicting with the actual license in the source code (either SPDX or
> license boilerplate/reference). A comparison between the scan of the
> history tree and a scan of current Linus tree shows to the extent that the
> git rename detection over Linus tree grafted with the history tree is
> halfways complete that almost none of the files which got broken in 2003
> have been cleaned up vs. the MODULE_LICENSE string. So subtracting those
> 480 known instances from the conflicting 2800 of today more than 25% of the
> module authors got it wrong and it's a high propability that a large
> portion of the rest just got it right by chance.
>
> There is no value for the module loader to convey the detailed license
> information as the only decision to be made is whether the module is free
> software or not.
>
> The "and additional rights", "BSD" and "MPL" strings are not conclusive
> license information either. So there is no point in trying to make the GPL
> part conclusive and exact. As shown above it's already non conclusive for
> dual licensing and incoherent with a large portion of the module source.
>
> As an unintended side effect this distinction causes a major headache for
> license compliance, license scanners and the ongoing effort to clean up the
> license mess of the kernel.
>
> Therefore remove the well meant, but ill defined, distinction between "GPL"
> and "GPL v2" and document that:
>
> - "GPL" and "GPL v2" both express that the module is licensed under GPLv2
> (without a distinction of 'only' and 'or later') and is therefore kernel
> license compliant.
>
> - None of the MODULE_LICENSE strings can be used for expressing or
> determining the exact license
>
> - Their sole purpose is to decide whether the module is free software or
> not.
>
> Add a MODULE_LICENSE subsection to the license rule documentation as well.
>
> Signed-off-by: Thomas Gleixner <[email protected]>
> Reviewed-by: Greg Kroah-Hartman <[email protected]>
> Acked-by: Philippe Ombredanne <[email protected]>
> Acked-by: Joe Perches <[email protected]>
>
> ---
>
> V2: Fixed the "GPL v2" hickup and the typo spotted by Jessica.
>
> Documentation/process/license-rules.rst | 62 ++++++++++++++++++++++++++++++++
> include/linux/module.h | 18 ++++++++-
> 2 files changed, 79 insertions(+), 1 deletion(-)
>
> --- a/Documentation/process/license-rules.rst
> +++ b/Documentation/process/license-rules.rst
> @@ -372,3 +372,65 @@ in the LICENSE subdirectories. This is r
> verification (e.g. checkpatch.pl) and to have the licenses ready to read
> and extract right from the source, which is recommended by various FOSS
> organizations, e.g. the `FSFE REUSE initiative <https://reuse.software/>`_.
> +
> +_`MODULE_LICENSE`
> +-----------------
> +
> + Loadable kernel modules also require a MODULE_LICENSE() tag. This tag is
> + neither a replacement for proper source code license information
> + (SPDX-License-Identifier) nor in any way relevant for expressing or
> + determining the exact license under which the source code of the module
> + is provided.
> +
> + The sole purpose of this tag is to provide sufficient information
> + whether the module is free software or proprietary for the kernel
> + module loader and for user space tools.
> +
> + The valid license strings for MODULE_LICENSE() are:
> +
> + ============================= =============================================
> + "GPL" Module is licensed under GPL version 2. This
> + does not express any distinction between
> + GPL-2.0-only or GPL-2.0-or-later. The exact
> + license information can only be determined
> + via the license information in the
> + corresponding source files.
> +
> + "GPL v2" Same as "GPL". It exists for historic
> + reasons.
> +
> + "GPL and additional rights" Historical variant of expressing that the
> + module source is dual licensed under a
> + GPL v2 variant and MIT license. Please do
> + not use in new code.
> +
> + "Dual MIT/GPL" The correct way of expressing that the
> + module is dual licensed under a GPL v2
> + variant or MIT license choice.
> +
> + "Dual BSD/GPL" The module is dual licensed under a GPL v2
> + variant or BSD license choice. The exact
> + variant of the BSD license can only be
> + determined via the license information
> + in the corresponding source files.
> +
> + "Dual MPL/GPL" The module is dual licensed under a GPL v2
> + variant or Mozilla Public License (MPL)
> + choice. The exact variant of the MPL
> + license can only be determined via the
> + license information in the corresponding
> + source files.
> +
> + "Proprietary" The module is under a proprietary license.
> + This string is solely for proprietary third
> + party modules and cannot be used for modules
> + which have their source code in the kernel
> + tree. Modules tagged that way are tainting
> + the kernel with the 'P' flag when loaded and
> + the kernel module loader refuses to link such
> + modules against symbols which are exported
> + with EXPORT_SYMBOL_GPL().
> + ============================= =============================================
> +
> +
> +
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -172,7 +172,7 @@ extern void cleanup_module(void);
> * The following license idents are currently accepted as indicating free
> * software modules
> *
> - * "GPL" [GNU Public License v2 or later]
> + * "GPL" [GNU Public License v2]
> * "GPL v2" [GNU Public License v2]
> * "GPL and additional rights" [GNU Public License v2 rights and more]
> * "Dual BSD/GPL" [GNU Public License v2
> @@ -186,6 +186,22 @@ extern void cleanup_module(void);
> *
> * "Proprietary" [Non free products]
> *
> + * Both "GPL v2" and "GPL" (the latter also in dual licensed strings) are
> + * merily stating that the module is licensed under the GPL v2, but are not
Nit: did you mean merely (as mere/just) ? or merily/merrily (as in
cheerfully/happily) ? :D
> + * telling whether "GPL v2 only" or "GPL v2 or later". The reason why there
> + * are two variants is a historic and failed attempt to convey more
> + * information in the MODULE_LICENSE string. For module loading the
> + * "only/or later" distinction is completely irrelevant and does neither
> + * replace the proper license identifiers in the corresponding source file
> + * nor amends them in any way. The sole purpose is to make the
> + * 'Proprietary' flagging work and to refuse to bind symbols which are
> + * exported with EXPORT_SYMBOL_GPL when a non free module is loaded.
> + *
> + * In the same way "BSD" is not a clear license information. It merily
Nit: merily. same as above
> + * states, that the module is licensed under one of the compatible BSD
> + * license variants. The detailed and correct license information is again
> + * to be found in the corresponding source files.
> + *
> * There are dual licensed components, but when running with Linux it is the
> * GPL that is relevant so this is a non issue. Similarly LGPL linked with GPL
> * is a GPL combined work.
Just to add to your points, I have seen a few times folks create
out-of-tree modules and use a MODULE_LICENSE "Proprietary" with a
proper GPL license notice at the top just to ensure that the code
would not be able to link with and use symbols exported with
EXPORT_SYMBOL_GPL().
This further reinforces the relevance of your argument as
MODULE_LICENSE can be used also as a pure technical solution that is
not making any licensing statement. So much so that a rewrite could
instead use something akin to EXPORT_SYMBOL_PRIVATE/INTERNAL/NON_API (
as 0 or 1) and MODULE_CAN_USE_PRIVATE/INTERNAL/NON_API_SYMBOLS ( as 0
or 1) and not deal with anything license-related? After all this is
mostly a binary flag.
--
Cordially
Philippe Ombredanne
On Sat, Feb 09, 2019 at 10:37:17AM +0100, Philippe Ombredanne wrote:
> > + * states, that the module is licensed under one of the compatible BSD
> > + * license variants. The detailed and correct license information is again
> > + * to be found in the corresponding source files.
> > + *
> > * There are dual licensed components, but when running with Linux it is the
> > * GPL that is relevant so this is a non issue. Similarly LGPL linked with GPL
> > * is a GPL combined work.
>
> Just to add to your points, I have seen a few times folks create
> out-of-tree modules and use a MODULE_LICENSE "Proprietary" with a
> proper GPL license notice at the top just to ensure that the code
> would not be able to link with and use symbols exported with
> EXPORT_SYMBOL_GPL().
That's very odd, but oh well, people do strange things :)
> This further reinforces the relevance of your argument as
> MODULE_LICENSE can be used also as a pure technical solution that is
> not making any licensing statement. So much so that a rewrite could
> instead use something akin to EXPORT_SYMBOL_PRIVATE/INTERNAL/NON_API (
> as 0 or 1) and MODULE_CAN_USE_PRIVATE/INTERNAL/NON_API_SYMBOLS ( as 0
> or 1) and not deal with anything license-related? After all this is
> mostly a binary flag.
No, let's leave the export symbol stuff as-is for now please. Let's
just focus on cleaning up this odd string mess so that we can move on to
the larger goal of getting everything in-tree properly classified.
thanks,
greg k-h
On Sat, 9 Feb 2019, Philippe Ombredanne wrote:
> > + * Both "GPL v2" and "GPL" (the latter also in dual licensed strings) are
> > + * merily stating that the module is licensed under the GPL v2, but are not
>
> Nit: did you mean merely (as mere/just) ? or merily/merrily (as in
> cheerfully/happily) ? :D
Bah. merely of course.
Jon, want me to resend?
Thanks,
tglx
+++ Thomas Gleixner [08/02/19 17:02 +0100]:
>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.
>
>As of 5.0-rc2 2873 out of 9200 instances of MODULE_LICENSE() strings are
>conflicting with the actual license in the source code (either SPDX or
>license boilerplate/reference). A comparison between the scan of the
>history tree and a scan of current Linus tree shows to the extent that the
>git rename detection over Linus tree grafted with the history tree is
>halfways complete that almost none of the files which got broken in 2003
>have been cleaned up vs. the MODULE_LICENSE string. So subtracting those
>480 known instances from the conflicting 2800 of today more than 25% of the
>module authors got it wrong and it's a high propability that a large
>portion of the rest just got it right by chance.
>
>There is no value for the module loader to convey the detailed license
>information as the only decision to be made is whether the module is free
>software or not.
>
>The "and additional rights", "BSD" and "MPL" strings are not conclusive
>license information either. So there is no point in trying to make the GPL
>part conclusive and exact. As shown above it's already non conclusive for
>dual licensing and incoherent with a large portion of the module source.
>
>As an unintended side effect this distinction causes a major headache for
>license compliance, license scanners and the ongoing effort to clean up the
>license mess of the kernel.
>
>Therefore remove the well meant, but ill defined, distinction between "GPL"
>and "GPL v2" and document that:
>
> - "GPL" and "GPL v2" both express that the module is licensed under GPLv2
> (without a distinction of 'only' and 'or later') and is therefore kernel
> license compliant.
>
> - None of the MODULE_LICENSE strings can be used for expressing or
> determining the exact license
>
> - Their sole purpose is to decide whether the module is free software or
> not.
>
>Add a MODULE_LICENSE subsection to the license rule documentation as well.
>
>Signed-off-by: Thomas Gleixner <[email protected]>
>Reviewed-by: Greg Kroah-Hartman <[email protected]>
>Acked-by: Philippe Ombredanne <[email protected]>
>Acked-by: Joe Perches <[email protected]>
Acked-by: Jessica Yu <[email protected]>
Thanks!
>---
>
>V2: Fixed the "GPL v2" hickup and the typo spotted by Jessica.
>
> Documentation/process/license-rules.rst | 62 ++++++++++++++++++++++++++++++++
> include/linux/module.h | 18 ++++++++-
> 2 files changed, 79 insertions(+), 1 deletion(-)
>
>--- a/Documentation/process/license-rules.rst
>+++ b/Documentation/process/license-rules.rst
>@@ -372,3 +372,65 @@ in the LICENSE subdirectories. This is r
> verification (e.g. checkpatch.pl) and to have the licenses ready to read
> and extract right from the source, which is recommended by various FOSS
> organizations, e.g. the `FSFE REUSE initiative <https://reuse.software/>`_.
>+
>+_`MODULE_LICENSE`
>+-----------------
>+
>+ Loadable kernel modules also require a MODULE_LICENSE() tag. This tag is
>+ neither a replacement for proper source code license information
>+ (SPDX-License-Identifier) nor in any way relevant for expressing or
>+ determining the exact license under which the source code of the module
>+ is provided.
>+
>+ The sole purpose of this tag is to provide sufficient information
>+ whether the module is free software or proprietary for the kernel
>+ module loader and for user space tools.
>+
>+ The valid license strings for MODULE_LICENSE() are:
>+
>+ ============================= =============================================
>+ "GPL" Module is licensed under GPL version 2. This
>+ does not express any distinction between
>+ GPL-2.0-only or GPL-2.0-or-later. The exact
>+ license information can only be determined
>+ via the license information in the
>+ corresponding source files.
>+
>+ "GPL v2" Same as "GPL". It exists for historic
>+ reasons.
>+
>+ "GPL and additional rights" Historical variant of expressing that the
>+ module source is dual licensed under a
>+ GPL v2 variant and MIT license. Please do
>+ not use in new code.
>+
>+ "Dual MIT/GPL" The correct way of expressing that the
>+ module is dual licensed under a GPL v2
>+ variant or MIT license choice.
>+
>+ "Dual BSD/GPL" The module is dual licensed under a GPL v2
>+ variant or BSD license choice. The exact
>+ variant of the BSD license can only be
>+ determined via the license information
>+ in the corresponding source files.
>+
>+ "Dual MPL/GPL" The module is dual licensed under a GPL v2
>+ variant or Mozilla Public License (MPL)
>+ choice. The exact variant of the MPL
>+ license can only be determined via the
>+ license information in the corresponding
>+ source files.
>+
>+ "Proprietary" The module is under a proprietary license.
>+ This string is solely for proprietary third
>+ party modules and cannot be used for modules
>+ which have their source code in the kernel
>+ tree. Modules tagged that way are tainting
>+ the kernel with the 'P' flag when loaded and
>+ the kernel module loader refuses to link such
>+ modules against symbols which are exported
>+ with EXPORT_SYMBOL_GPL().
>+ ============================= =============================================
>+
>+
>+
>--- a/include/linux/module.h
>+++ b/include/linux/module.h
>@@ -172,7 +172,7 @@ extern void cleanup_module(void);
> * The following license idents are currently accepted as indicating free
> * software modules
> *
>- * "GPL" [GNU Public License v2 or later]
>+ * "GPL" [GNU Public License v2]
> * "GPL v2" [GNU Public License v2]
> * "GPL and additional rights" [GNU Public License v2 rights and more]
> * "Dual BSD/GPL" [GNU Public License v2
>@@ -186,6 +186,22 @@ extern void cleanup_module(void);
> *
> * "Proprietary" [Non free products]
> *
>+ * Both "GPL v2" and "GPL" (the latter also in dual licensed strings) are
>+ * merily stating that the module is licensed under the GPL v2, but are not
>+ * telling whether "GPL v2 only" or "GPL v2 or later". The reason why there
>+ * are two variants is a historic and failed attempt to convey more
>+ * information in the MODULE_LICENSE string. For module loading the
>+ * "only/or later" distinction is completely irrelevant and does neither
>+ * replace the proper license identifiers in the corresponding source file
>+ * nor amends them in any way. The sole purpose is to make the
>+ * 'Proprietary' flagging work and to refuse to bind symbols which are
>+ * exported with EXPORT_SYMBOL_GPL when a non free module is loaded.
>+ *
>+ * In the same way "BSD" is not a clear license information. It merily
>+ * states, that the module is licensed under one of the compatible BSD
>+ * license variants. The detailed and correct license information is again
>+ * to be found in the corresponding source files.
>+ *
> * There are dual licensed components, but when running with Linux it is the
> * GPL that is relevant so this is a non issue. Similarly LGPL linked with GPL
> * is a GPL combined work.
On Sun, 10 Feb 2019 19:58:11 +0100 (CET)
Thomas Gleixner <[email protected]> wrote:
> On Sat, 9 Feb 2019, Philippe Ombredanne wrote:
> > > + * Both "GPL v2" and "GPL" (the latter also in dual licensed strings) are
> > > + * merily stating that the module is licensed under the GPL v2, but are not
> >
> > Nit: did you mean merely (as mere/just) ? or merily/merrily (as in
> > cheerfully/happily) ? :D
>
> Bah. merely of course.
>
> Jon, want me to resend?
Nah...I merily made the tweak while adding Jessica's ack.
Thanks,
jon