lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200222023147.3cc31b90@orivej.orivej.org>
Date:   Sat, 22 Feb 2020 03:37:09 +0000
From:   Orivej Desh <c@...vej.org>
To:     linux-kernel@...r.kernel.org
Cc:     linux-spdx@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Confusing Usage-Guide in LICENSES/exceptions/Linux-syscall-note

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!

[1] https://lore.kernel.org/patchwork/patch/851955/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bf02d491237eea10290bd379bf7fc8c37ac6c3b4
[3] http://lkml.iu.edu/hypermail/linux/kernel/0301.1/0362.html
[4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/process/license-rules.rst?id=aa19a176df95d6e49295d6ff77f7967224c71761
[5] https://spdx.org/licenses/Linux-syscall-note.html

--

This is my second attempt to reach @vger, as my message from @gmx.fr seems to
have been dropped.

Please CC me in response.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ