Back to home page

OSCL-LXR

 
 

    


0001 =============
0002 BPF licensing
0003 =============
0004 
0005 Background
0006 ==========
0007 
0008 * Classic BPF was BSD licensed
0009 
0010 "BPF" was originally introduced as BSD Packet Filter in
0011 http://www.tcpdump.org/papers/bpf-usenix93.pdf. The corresponding instruction
0012 set and its implementation came from BSD with BSD license. That original
0013 instruction set is now known as "classic BPF".
0014 
0015 However an instruction set is a specification for machine-language interaction,
0016 similar to a programming language.  It is not a code. Therefore, the
0017 application of a BSD license may be misleading in a certain context, as the
0018 instruction set may enjoy no copyright protection.
0019 
0020 * eBPF (extended BPF) instruction set continues to be BSD
0021 
0022 In 2014, the classic BPF instruction set was significantly extended. We
0023 typically refer to this instruction set as eBPF to disambiguate it from cBPF.
0024 The eBPF instruction set is still BSD licensed.
0025 
0026 Implementations of eBPF
0027 =======================
0028 
0029 Using the eBPF instruction set requires implementing code in both kernel space
0030 and user space.
0031 
0032 In Linux Kernel
0033 ---------------
0034 
0035 The reference implementations of the eBPF interpreter and various just-in-time
0036 compilers are part of Linux and are GPLv2 licensed. The implementation of
0037 eBPF helper functions is also GPLv2 licensed. Interpreters, JITs, helpers,
0038 and verifiers are called eBPF runtime.
0039 
0040 In User Space
0041 -------------
0042 
0043 There are also implementations of eBPF runtime (interpreter, JITs, helper
0044 functions) under
0045 Apache2 (https://github.com/iovisor/ubpf),
0046 MIT (https://github.com/qmonnet/rbpf), and
0047 BSD (https://github.com/DPDK/dpdk/blob/main/lib/librte_bpf).
0048 
0049 In HW
0050 -----
0051 
0052 The HW can choose to execute eBPF instruction natively and provide eBPF runtime
0053 in HW or via the use of implementing firmware with a proprietary license.
0054 
0055 In other operating systems
0056 --------------------------
0057 
0058 Other kernels or user space implementations of eBPF instruction set and runtime
0059 can have proprietary licenses.
0060 
0061 Using BPF programs in the Linux kernel
0062 ======================================
0063 
0064 Linux Kernel (while being GPLv2) allows linking of proprietary kernel modules
0065 under these rules:
0066 Documentation/process/license-rules.rst
0067 
0068 When a kernel module is loaded, the linux kernel checks which functions it
0069 intends to use. If any function is marked as "GPL only," the corresponding
0070 module or program has to have GPL compatible license.
0071 
0072 Loading BPF program into the Linux kernel is similar to loading a kernel
0073 module. BPF is loaded at run time and not statically linked to the Linux
0074 kernel. BPF program loading follows the same license checking rules as kernel
0075 modules. BPF programs can be proprietary if they don't use "GPL only" BPF
0076 helper functions.
0077 
0078 Further, some BPF program types - Linux Security Modules (LSM) and TCP
0079 Congestion Control (struct_ops), as of Aug 2021 - are required to be GPL
0080 compatible even if they don't use "GPL only" helper functions directly. The
0081 registration step of LSM and TCP congestion control modules of the Linux
0082 kernel is done through EXPORT_SYMBOL_GPL kernel functions. In that sense LSM
0083 and struct_ops BPF programs are implicitly calling "GPL only" functions.
0084 The same restriction applies to BPF programs that call kernel functions
0085 directly via unstable interface also known as "kfunc".
0086 
0087 Packaging BPF programs with user space applications
0088 ====================================================
0089 
0090 Generally, proprietary-licensed applications and GPL licensed BPF programs
0091 written for the Linux kernel in the same package can co-exist because they are
0092 separate executable processes. This applies to both cBPF and eBPF programs.