workflows.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <ukleinek@kernel.org>
To: Jonathan Corbet <corbet@lwn.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Werner Sembach <wse@tuxedocomputers.com>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-spdx@vger.kernel.org, workflows@vger.kernel.org
Subject: [PATCH] docs/licensing: Clarify wording about "GPL" and "Proprietary"
Date: Fri, 15 Nov 2024 11:38:41 +0100	[thread overview]
Message-ID: <20241115103842.585207-2-ukleinek@kernel.org> (raw)

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


             reply	other threads:[~2024-11-15 10:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-15 10:38 Uwe Kleine-König [this message]
2024-11-15 11:11 ` Werner Sembach
2024-11-22 17:45 ` Jonathan Corbet

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=20241115103842.585207-2-ukleinek@kernel.org \
    --to=ukleinek@kernel.org \
    --cc=corbet@lwn.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spdx@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=workflows@vger.kernel.org \
    --cc=wse@tuxedocomputers.com \
    /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