요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
=============
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.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Classic BPF와 eBPF instruction set
1-24Classic BPF는 BSD license였습니다. "BPF"는 `http://www.tcpdump.org/papers/bpf-usenix93.pdf`에서 BSD Packet Filter라는 이름으로 처음 도입됐습니다. 대응하는 instruction set과 구현은 BSD에서 BSD license로 들어왔으며, 이 원래 instruction set을 이제 "classic BPF"라고 부릅니다.
하지만 instruction set은 programming language와 비슷하게 machine-language interaction을 위한 specification이지 code가 아닙니다. 따라서 instruction set이 copyright protection을 받지 않을 수 있으므로 어떤 context에서는 BSD license 적용이 오해를 일으킬 수 있습니다.
eBPF, 즉 extended BPF instruction set도 계속 BSD입니다. 2014년에 classic BPF instruction set이 크게 확장됐습니다. cBPF와 구분하기 위해 보통 이 instruction set을 eBPF라고 부르며 eBPF instruction set도 여전히 BSD license입니다.
Linux kernel의 eBPF runtime
25-39eBPF instruction set을 사용하려면 kernel space와 userspace 양쪽에 code를 구현해야 합니다.
Linux에서 eBPF interpreter의 reference implementation과 여러 just-in-time compiler는 Linux의 일부이며 GPLv2 license입니다. eBPF helper function 구현도 GPLv2 license입니다.
interpreter, JIT, helper, verifier를 통틀어 eBPF runtime이라고 부릅니다.
Userspace·hardware·다른 OS 구현
40-60userspace에도 여러 license의 eBPF runtime, 즉 interpreter, JIT, helper function 구현이 있습니다. Apache2 구현은 `https://github.com/iovisor/ubpf`, MIT 구현은 `https://github.com/qmonnet/rbpf`, BSD 구현은 `https://github.com/DPDK/dpdk/blob/main/lib/librte_bpf`에서 찾을 수 있습니다.
hardware는 eBPF instruction을 native로 실행하고 hardware에서 eBPF runtime을 제공하거나 proprietary license firmware 구현을 사용할 수 있습니다.
다른 kernel 또는 userspace의 eBPF instruction set과 runtime 구현은 proprietary license를 가질 수 있습니다.
Linux의 BPF program license 검사
61-77GPLv2인 Linux kernel은 `Documentation/process/license-rules.rst`의 규칙에 따라 proprietary kernel module linking을 허용합니다.
kernel module을 load할 때 Linux kernel은 module이 사용하려는 function을 검사합니다. function 하나라도 "GPL only"로 표시돼 있으면 대응하는 module 또는 program은 GPL-compatible license를 가져야 합니다.
BPF program을 Linux kernel에 load하는 것은 kernel module을 load하는 것과 비슷합니다. BPF는 runtime에 load되며 Linux kernel에 statically linked되지 않습니다.
BPF program load에는 kernel module과 같은 license 검사 규칙이 적용됩니다. "GPL only" BPF helper functions를 사용하지 않는 BPF program은 proprietary일 수 있습니다.
LSM·struct_ops·kfunc의 GPL 호환 요건
78-862021년 8월 기준 일부 BPF program type, 즉 Linux Security Modules(LSM)와 TCP Congestion Control(`struct_ops`)은 "GPL only" helper function을 직접 사용하지 않더라도 GPL-compatible이어야 합니다.
Linux kernel의 LSM과 TCP congestion control module registration 단계가 `EXPORT_SYMBOL_GPL` kernel function을 통해 이루어지기 때문입니다. 이런 의미에서 LSM과 `struct_ops` BPF program은 "GPL only" function을 암묵적으로 호출합니다.
불안정한 interface인 `kfunc`를 통해 kernel function을 직접 호출하는 BPF program에도 같은 제한이 적용됩니다.
Userspace application과 함께 packaging
87-92일반적으로 proprietary license application과 Linux kernel용으로 작성된 GPL license BPF program은 separate executable processes이므로 같은 package 안에 공존할 수 있습니다.
이 원칙은 cBPF와 eBPF program 모두에 적용됩니다.
요약과 해설
bpf_licensing.rst:1-92classic BPF와 eBPF instruction set은 BSD 계열로 설명되지만 Linux kernel 안의 interpreter, JIT, helper, verifier 구현은 GPLv2입니다. 다른 userspace·hardware·운영체제 runtime은 Apache2, MIT, BSD 또는 proprietary license로 구현될 수 있습니다.
Linux에 load되는 BPF program은 kernel module과 같은 license 검사를 받습니다. GPL-only helper를 쓰지 않으면 proprietary program도 가능하지만 LSM, TCP congestion-control `struct_ops`, `kfunc` 직접 호출은 GPL-only kernel function과 연결되므로 GPL-compatible license가 필요합니다.
proprietary userspace application과 GPL BPF program은 별도 executable process이므로 일반적으로 같은 package에 함께 둘 수 있으며 이 원칙은 cBPF와 eBPF에 모두 적용됩니다.