| ============= |
| 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: |
| Documentation/process/license-rules.rst |
| |
| 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. |