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

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

[Alexei Starovoitov]

From: Alexei Starovoitov <ast@kernel.org>

Document and clarify BPF licensing.

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

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
+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

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

[Stephen Hemminger]

On Wed, 15 Sep 2021 20:21:04 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:

> From: Alexei Starovoitov <ast@kernel.org>
> 
> Document and clarify BPF licensing.
> 
> 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>

Looks good, this helps other projects.

Acked-by: Stephen Hemminger <stephen@networkplumber.org>

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

[Simon Horman]

On Wed, Sep 15, 2021 at 08:21:04PM -0700, Alexei Starovoitov wrote:
> From: Alexei Starovoitov <ast@kernel.org>
> 
> Document and clarify BPF licensing.
> 
> 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>

Reviewed-by: Simon Horman <simon.horman@corigine.com>

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

[Jesper Dangaard Brouer]

On 16/09/2021 05.21, Alexei Starovoitov wrote:
> From: Alexei Starovoitov<ast@kernel.org>
>
> Document and clarify BPF licensing.
>
> 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


Thanks for working on this, it is good this gets clarified.


Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>

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

[Jakub Kicinski]

On Wed, 15 Sep 2021 20:21:04 -0700 Alexei Starovoitov wrote:
> +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.

That seems like a step back, nfp parts are all BSD licensed:

https://github.com/Netronome/nic-firmware/blob/master/firmware/apps/nic/ebpf.uc

> +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.

Interesting. BTW is there a definition of what "executable process" is?

But feel free to ignore, I appreciate that polishing legalese is not
what you want to spend you time doing. Much less bike shedding about
it. Mostly wanted to mention the nfp part :)

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

[Alexei Starovoitov]

On Thu, Sep 16, 2021 at 7:06 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Wed, 15 Sep 2021 20:21:04 -0700 Alexei Starovoitov wrote:
> > +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.
>
> That seems like a step back, nfp parts are all BSD licensed:

Yeah. netronome is a great example of how firmware should be developed.

> > +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.
>
> Interesting. BTW is there a definition of what "executable process" is?

That's how lawyers put it.
BPF in many ways is unique, so traditional computer science words and meanings
don't apply 100%. Like, bpf programs are analogous to kernel modules,
but they're very different at the same time as well.
The analogies are used to explain things.
Is bpf program an "executable process" on its own? Hard to say.
Is there a task_struct allocated for each bpf prog? Of course, not.
But it is certainly not executing in ring 3.
In the future we might have kthread or even user thread completely
occupied by bpf progs.

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

[Jonathan Corbet]

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

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

[Alexei Starovoitov]

On Thu, Sep 16, 2021 at 9:05 AM Jonathan Corbet <corbet@lwn.net> wrote:
>
> 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.

ok.

> > +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.

Good point. Will fix.

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

[KP Singh]

On Thu, Sep 16, 2021 at 10:49 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Thu, Sep 16, 2021 at 9:05 AM Jonathan Corbet <corbet@lwn.net> wrote:
> >
> > 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>

Thanks for writing this up!

Acked-by: KP Singh <kpsingh@kernel.org>