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@kernel.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

Hi,

Am 15.11.24 um 11:38 schrieb Uwe Kleine-König:
> 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@kernel.org>

Thanks for adding this clarification.

Kind regards,

Werner Sembach