Re: Confusing Usage-Guide in LICENSES/exceptions/Linux-syscall-note

From: Greg KH
Date: Sun Feb 23 2020 - 10:45:28 EST

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.


greg k-h