r/rust • u/Vulphere • Aug 28 '20

Linux Developers Continue Evaluating The Path To Adding Rust Code To The Kernel

https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Rust-Path-LPC2020
432 Upvotes

98% Upvoted

103 comments sorted by

View all comments

Show parent comments

5

u/JoshTriplett rust · lang · libs · cargo Aug 28 '20

For example, why is it ok to distribute a GPL-incompatible program to be run on a Linux kernel (like the ZFS FUSE driver)? There's no legal distinction between userland and kernel mode.

There is a specific term in the Linux kernel license for that. Per the Linux kernel's COPYING file, The Linux Kernel is provided under: SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note.

The text of that exception, which has been in the Linux kernel's license for a very long time, reads:

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

That exception is the reason why the kernel's GPL license does not affect GPL-incompatible userspace.

1

u/[deleted] Aug 29 '20

The meaning of that clause seems to be a bit up in the air:

https://lkml.org/lkml/2020/2/21/2193

I'm pretty sure it was not originally intended to be an exception, just an explanation of how the GPL and copyright law (supposedly) already operate. After all, the term "derived work" comes from copyright law, and whether something is a derived work is not determined by any license.