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
