License exception for GPL-2.0 WITH Linux-syscall-note file in containerd/btrfs

[AkihiroSuda]

EDIT (March 28, 2023): See #174 (comment) for the current situation

---

(Original post on Aug 2021)

We containerd maintainers would like to include a file that is machine-translated from a GPL-2.0 WITH Linux-syscall-note file, for the sake of calling btrfs-related ioctl syscalls.

https://github.com/torvalds/linux/blob/v5.13/LICENSES/exceptions/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".
 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

We interpret that containerd/btrfs is a user programs that use kernel services by normal system calls mentioned in the Linux-syscall-note, and does not fall under the heading of "derived work" of the GPL-2.0 code.

• Original C source, with GPL-2.0 WITH Linux-syscall-note: https://github.com/torvalds/linux/blob/v5.13/include/uapi/linux/btrfs_tree.h
• Translated Go source, to be included in https://github.com/containerd/btrfs : https://github.com/AkihiroSuda/go-btrfs/blob/btrfs-v2.20210701/btrfs_tree_hc.go
• Translator, to be included in https://github.com/containerd/btrfs : https://github.com/AkihiroSuda/go-btrfs/blob/btrfs-v2.20210701/headers.go

[dims]

cc @swinslow @caniszczyk

[AkihiroSuda]

@swinslow @caniszczyk @amye Could you take a look?

[AkihiroSuda]

@stevvooe Do we still need to keep this open, or do you find a way to avoid cgo without importing GPL-2.0 WITH Linux-syscall-note header?

[amye]

@AkihiroSuda - connecting back in here, I'm getting a process set up for our next board meeting.

For all license exception requests, we need the following information in order to help make a decision to grant an exception.

• What is the alternative license?
• If this is newly created code, why can't it be under Apache-2.0?
• Is this an existing 3rd party open source project?
• How does this code integrate with or interact with, if at all, other components of CNCF?
• How will the code be maintained? Who is responsible?
• How will the code be kept up to date with security patches?

[AkihiroSuda]

The current version of containerd/btrfs (v2.0.0) does not contain GPL-2.0 WITH Linux-syscall-note files in the repo, so the situation is different from the original issue, but the current version still includes GPL-2.0 WITH Linux-syscall-note kernel headers with #include <linux/...>:
https://github.com/containerd/btrfs/blob/v2.0.0/btrfs.h#L17-L22

• https://github.com/torvalds/linux/blob/master/include/uapi/linux/btrfs.h
• https://github.com/torvalds/linux/blob/master/include/uapi/linux/btrfs_tree.h

So it would be still nice get explicit approval for using GPL-2.0 WITH Linux-syscall-note.
I assume that would be helpful for other CNCF projects too.

---

What is the alternative license?

None

If this is newly created code, why can't it be under Apache-2.0?

Not newly created code. They are from the Linux kernel (include/uapi/linux).

Is this an existing 3rd party open source project?

Yes, but maybe s/3rd/1st/ , as the CNCF belongs to the Linux Foundation.

How does this code integrate with or interact with, if at all, other components of CNCF?

The files are included as kernel uapi headers (#include <linux/...>) in containerd/btrfs, which is a Go (CGO) library consumed by containerd.

How will the code be maintained? Who is responsible?

The kernel maintainers maintain the kernel uapi headers.

How will the code be kept up to date with security patches?

The kernel maintainers keep the kernel uapi headers up to date with security patches.

[amye]

This is currently scheduled for review in the June 8th meeting of the Legal Committee.

[amye]

Legal Committee met today to review this, one question came up: Please confirm that there are no inlines in the headers?

[AkihiroSuda]

Legal Committee met today to review this, one question came up: Please confirm that there are no inlines in the headers?

There are, but very subtle
https://github.com/torvalds/linux/blob/master/include/uapi/linux/btrfs_tree.h

[amye]

Regarding the inline functions in btrfs_tree.h:

1. Does the containerd code call any of these inline functions?
2. Does compiling the containerd code, with btrfs_tree.h included, result in any of these inline functions being included in the compiled object code?

[AkihiroSuda]

Looks like we do not use inline functions from btrfs headers.

We use a KERNEL_VERSION() macro from <linux/version.h> but it is not compiled in
https://github.com/containerd/btrfs/blob/v2.0.0/btrfs.h#L17-L20

#include <linux/version.h>
#if LINUX_VERSION_CODE < KERNEL_VERSION(4,12,0)
#error "Headers from kernel >= 4.12 are required on compilation time (not on run time)"
#endif