lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241115103842.585207-2-ukleinek@kernel.org>
Date: Fri, 15 Nov 2024 11:38:41 +0100
From: Uwe Kleine-König <ukleinek@...nel.org>
To: Jonathan Corbet <corbet@....net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Werner Sembach <wse@...edocomputers.com>,
	linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-spdx@...r.kernel.org,
	workflows@...r.kernel.org
Subject: [PATCH] docs/licensing: Clarify wording about "GPL" and "Proprietary"

There are currently some doubts about out-of-tree kernel modules licensed
under GPLv3 and if they are supposed to be able to use symbols exported
using EXPORT_SYMBOL_GPL.

Clarify that "Proprietary" means anything non-GPL2 even though the
license might be an open source license. Also disambiguate "GPL
compatible" to "GPLv2 compatible".

Signed-off-by: Uwe Kleine-König <ukleinek@...nel.org>
---
Hello,

these are the locations that I found by a quick grep. If you spot a
document that needs similar updating, please tell.

The change in license-rules.rst looks bigger than it actually is due to
changing where the line wrappings occur. With `git diff --word-diff` it
reduces to:

    "Proprietary"                 The module is under a proprietary license.
                                  {+"Proprietary" is to be understood only as+}
{+                                "The license is not compatible to GPLv2".+}
                                  This string is solely for [-proprietary-]{+non-GPL2 compatible+}
                                  third party modules and cannot be used for

Best regards
Uwe

 Documentation/kernel-hacking/hacking.rst |  2 +-
 Documentation/process/license-rules.rst  | 18 ++++++++++--------
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/Documentation/kernel-hacking/hacking.rst b/Documentation/kernel-hacking/hacking.rst
index 1717348a4404..0042776a9e17 100644
--- a/Documentation/kernel-hacking/hacking.rst
+++ b/Documentation/kernel-hacking/hacking.rst
@@ -587,7 +587,7 @@ Defined in ``include/linux/export.h``
 
 Similar to :c:func:`EXPORT_SYMBOL()` except that the symbols
 exported by :c:func:`EXPORT_SYMBOL_GPL()` can only be seen by
-modules with a :c:func:`MODULE_LICENSE()` that specifies a GPL
+modules with a :c:func:`MODULE_LICENSE()` that specifies a GPLv2
 compatible license. It implies that the function is considered an
 internal implementation issue, and not really an interface. Some
 maintainers and developers may however require EXPORT_SYMBOL_GPL()
diff --git a/Documentation/process/license-rules.rst b/Documentation/process/license-rules.rst
index 2ef44ada3f11..59a7832df7d0 100644
--- a/Documentation/process/license-rules.rst
+++ b/Documentation/process/license-rules.rst
@@ -471,14 +471,16 @@ _`MODULE_LICENSE`
 				  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().
+				  "Proprietary" is to be understood only as
+				  "The license is not compatible to GPLv2".
+                                  This string is solely for non-GPL2 compatible
+                                  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().
     ============================= =============================================
 
 

base-commit: 28955f4fa2823e39f1ecfb3a37a364563527afbc
-- 
2.45.2


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ