linux-spdx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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