archive mirror
 help / color / mirror / Atom feed
From: Greg KH <>
To: Orivej Desh <>
	Thomas Gleixner <>
Subject: Re: Confusing Usage-Guide in LICENSES/exceptions/Linux-syscall-note
Date: Sun, 23 Feb 2020 16:45:22 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

      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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* 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).