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
next 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