From: Greg KH <gregkh@linuxfoundation.org>
To: Orivej Desh <c@orivej.org>
Cc: linux-kernel@vger.kernel.org, linux-spdx@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: Confusing Usage-Guide in LICENSES/exceptions/Linux-syscall-note
Date: Sun, 23 Feb 2020 16:45:22 +0100 [thread overview]
Message-ID: <20200223154522.GA270051@kroah.com> (raw)
In-Reply-To: <20200222023147.3cc31b90@orivej.orivej.org>
On Sat, Feb 22, 2020 at 03:37:09AM +0000, Orivej Desh wrote:
> For the reference, here is the Linux syscall note:
>
> NOTE! This copyright does *not* cover user programs that use kernel
> services by normal system calls - this is merely considered normal use
> of the kernel, and does *not* fall under the heading of "derived work".
>
> When Linux-syscall-note was split from the COPYING file [1] [2], it
> added a Usage-Guide section that says that "This exception" marks
> "user space API (uapi) header files so they can be included into non
> GPL compliant user space application code". However, the License-Text
> extracted from the COPYING does not say anything about including
> headers; instead it says that programs that make system calls to the
> kernel are not considered derived from the kernel.
>
> I think that Linus shares the view expressed by Stallman [3]:
>
> Someone recently made the claim that including a header file
> always makes a derivative work.
>
> That's not the FSF's view. Our view is that just using structure
> definitions, typedefs, enumeration constants, macros with simple
> bodies, etc., is NOT enough to make a derivative work. It would
> take a substantial amount of code (coming from inline functions
> or macros with substantial bodies) to do that.
>
> and wrote the syscall note as something to be added on top of this
> view, while Thomas Gleixner took the note as a relaxation of GPL that
> allows the use of the headers in non-GPL programs when he wrote the
> Usage-Guide and Documentation/process/license-rules.rst that says:
>
> The User-space API (UAPI) header files, which describe the
> interface of user-space programs to the kernel are a special
> case. According to the note in the kernel COPYING file, the
> syscall interface is a clear boundary, which does not extend the
> GPL requirements to any software which uses it to communicate
> with the kernel. Because the UAPI headers must be includable into
> any source files which create an executable running on the Linux
> kernel, the exception must be documented by a special license
> expression.
>
> I think that the lawyers should review whether the syscall note grants
> anything not already granted by GPL-2.0. If it unambiguously does not
> than the note could be deleted, overwise the following mistakes should
> be corrected:
>
> 1. Since the note declares user programs to not be considered derived
> from the running kernel, it applies to the kernel as a whole. It
> does not make sense to restrict Linux-syscall-note to UAPI headers
> only (in their SPDX-License-Identifier) and not to apply it to the
> whole kernel. "WITH Linux-syscall-note" should be deleted from all
> sources; the link to the note from the root COPYING is enough.
>
> 2. Linux-syscall-note should be cleared from these parts of the old
> COPYING unrelated to the note:
>
> Also note that the GPL below is copyrighted by the Free Software
> Foundation, but the instance of code that it refers to (the Linux
> kernel) is copyrighted by me and others who actually wrote it.
>
> Also note that the only valid version of the GPL as far as the kernel
> is concerned is _this_ particular version of the license (ie v2, not
> v2.2 or v3.x or whatever), unless explicitly otherwise stated.
>
> Linus Torvalds
>
> Note that there is no GPL text below.
>
> 3. Linux-syscall-note Usage-Guide could be deleted (does a three line
> note need a guide?), or it may say something like this:
>
> This exception allows non-GPL programs to run on Linux.
>
> 4. Documentation/process/license-rules.rst should be updated
> accordingly. Something like the Stallman explanation of derived
> works would be useful.
>
> 5. SPDX license list maintainers should be notified to update [5]. Its
> current Note about the exception is unclear and mistaken:
>
> This note is used with the Linux kernel to clarify how user space
> API files should be treated.
>
> The people seem easily confused by the Usage-Guide: they believe that
> the syscall exception does what it does not (allowing uapi includes in
> user programs), and do not understand what it does (allowing making
> system calls). Please correct it!
Thanks for the report. A few of us have slowly been working on making
this all a lot more obvious as to what this means for things.
Give us some time, it's a low-priority issue at the moment, but it will
be taken care of eventually.
thanks,
greg k-h
prev parent reply other threads:[~2020-02-23 15:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-22 3:37 Confusing Usage-Guide in LICENSES/exceptions/Linux-syscall-note Orivej Desh
2020-02-23 15:45 ` Greg KH [this message]
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=20200223154522.GA270051@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=c@orivej.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spdx@vger.kernel.org \
--cc=tglx@linutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).