Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes: > From: Alexei Starovoitov <ast@xxxxxxxxxx> > > Document and clarify BPF licensing. Two trivial things that have nothing to do with the actual content... > Signed-off-by: Alexei Starovoitov <ast@xxxxxxxxxx> > Acked-by: Toke Høiland-Jørgensen <toke@xxxxxxxxxx> > Acked-by: Daniel Borkmann <daniel@xxxxxxxxxxxxx> > Acked-by: Joe Stringer <joe@xxxxxxxxx> > Acked-by: Lorenz Bauer <lmb@xxxxxxxxxxxxxx> > Acked-by: Dave Thaler <dthaler@xxxxxxxxxxxxx> > --- > 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
