Re: [PATCH bpf-next] bpf: Document BPF licensing.

[Jonathan Corbet <corbet@lwn.net>]

Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:

> From: Alexei Starovoitov <ast@kernel.org>
>
> Document and clarify BPF licensing.

Two trivial things that have nothing to do with the actual content...

> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Joe Stringer <joe@cilium.io>
> Acked-by: Lorenz Bauer <lmb@cloudflare.com>
> Acked-by: Dave Thaler <dthaler@microsoft.com>
> ---
>  Documentation/bpf/bpf_licensing.rst | 91 +++++++++++++++++++++++++++++
>  1 file changed, 91 insertions(+)
>  create mode 100644 Documentation/bpf/bpf_licensing.rst

When you add a new file you need to put it into index.rst as well so it
gets pulled into the docs build.

> diff --git a/Documentation/bpf/bpf_licensing.rst b/Documentation/bpf/bpf_licensing.rst
> new file mode 100644
> index 000000000000..62391923af07
> --- /dev/null
> +++ b/Documentation/bpf/bpf_licensing.rst
> @@ -0,0 +1,91 @@
> +=============
> +BPF licensing
> +=============
> +
> +Background
> +==========
> +
> +* Classic BPF was BSD licensed
> +
> +"BPF" was originally introduced as BSD Packet Filter in
> +http://www.tcpdump.org/papers/bpf-usenix93.pdf. The corresponding instruction
> +set and its implementation came from BSD with BSD license. That original
> +instruction set is now known as "classic BPF".
> +
> +However an instruction set is a specification for machine-language interaction,
> +similar to a programming language.  It is not a code. Therefore, the
> +application of a BSD license may be misleading in a certain context, as the
> +instruction set may enjoy no copyright protection.
> +
> +* eBPF (extended BPF) instruction set continues to be BSD
> +
> +In 2014, the classic BPF instruction set was significantly extended. We
> +typically refer to this instruction set as eBPF to disambiguate it from cBPF.
> +The eBPF instruction set is still BSD licensed.
> +
> +Implementations of eBPF
> +=======================
> +
> +Using the eBPF instruction set requires implementing code in both kernel space
> +and user space.
> +
> +In Linux Kernel
> +---------------
> +
> +The reference implementations of the eBPF interpreter and various just-in-time
> +compilers are part of Linux and are GPLv2 licensed. The implementation of
> +eBPF helper functions is also GPLv2 licensed. Interpreters, JITs, helpers,
> +and verifiers are called eBPF runtime.
> +
> +In User Space
> +-------------
> +
> +There are also implementations of eBPF runtime (interpreter, JITs, helper
> +functions) under
> +Apache2 (https://github.com/iovisor/ubpf),
> +MIT (https://github.com/qmonnet/rbpf), and
> +BSD (https://github.com/DPDK/dpdk/blob/main/lib/librte_bpf).
> +
> +In HW
> +-----
> +
> +The HW can choose to execute eBPF instruction natively and provide eBPF runtime
> +in HW or via the use of implementing firmware with a proprietary license.
> +
> +In other operating systems
> +--------------------------
> +
> +Other kernels or user space implementations of eBPF instruction set and runtime
> +can have proprietary licenses.
> +
> +Using BPF programs in the Linux kernel
> +======================================
> +
> +Linux Kernel (while being GPLv2) allows linking of proprietary kernel modules
> +under these rules:
> +https://www.kernel.org/doc/html/latest/process/license-rules.html#id1

I would just write this as Documentation/process/license-rules.rst.  The
HTML docs build will link it automatically, and readers of the plain-text
file will know where to go.

> +When a kernel module is loaded, the linux kernel checks which functions it
> +intends to use. If any function is marked as "GPL only," the corresponding
> +module or program has to have GPL compatible license.
> +
> +Loading BPF program into the Linux kernel is similar to loading a kernel
> +module. BPF is loaded at run time and not statically linked to the Linux
> +kernel. BPF program loading follows the same license checking rules as kernel
> +modules. BPF programs can be proprietary if they don't use "GPL only" BPF
> +helper functions.
> +
> +Further, some BPF program types - Linux Security Modules (LSM) and TCP
> +Congestion Control (struct_ops), as of Aug 2021 - are required to be GPL
> +compatible even if they don't use "GPL only" helper functions directly. The
> +registration step of LSM and TCP congestion control modules of the Linux
> +kernel is done through EXPORT_SYMBOL_GPL kernel functions. In that sense LSM
> +and struct_ops BPF programs are implicitly calling "GPL only" functions.
> +The same restriction applies to BPF programs that call kernel functions
> +directly via unstable interface also known as "kfunc".
> +
> +Packaging BPF programs with user space applications
> +====================================================
> +
> +Generally, proprietary-licensed applications and GPL licensed BPF programs
> +written for the Linux kernel in the same package can co-exist because they are
> +separate executable processes. This applies to both cBPF and eBPF programs.
> -- 
> 2.30.2

Thanks,

jon