I am not a lawyer, but here are my two cents:
"This means that this eBPF module needs to be under GPL license."
Actually, the code needs to be GPL-compatible. This, from the point of view of the kernel, are the following strings in the module info:
- GPL: GNU Public License v2 or later.
- GPL v2: GNU Public License v2.
- GPL and additional rights: GNU Public License v2 rights and more.
- Dual BSD/GPL: GNU Public License v2 or BSD license choice.
- Dual MIT/GPL: GNU Public License v2 or MIT license choice.
- Dual MPL/GPL: GNU Public License v2 or Mozilla license choice.
"My actual question is does a user-space application that uses (but not redistributes or loads) that module also needs to be under GPL-license?"
This is tricky and I'm still struggling with it. The short answer is "it depends".
This is what the FSF says about aggregated programs:
Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
An eBPF program usually is developed as the kernel counterpart of a user-space program. The BCC tools and examples have both sources in the same file.
If you develop an eBPF program that is clearly a sub-component of a user-space application, and the "semantics of the communication" (data types for the perf buffers and maps) are "intimate enough" and clearly tailored for this application only, then probably the user-space program should be licensed under the GPL.
If your eBPF program has a very generic API, it could be used by non-GPL programs... If we assume that the shared memory used for maps and perf buffers doesn't count as a shared-memory application.
"And what if the application would distribute compiled EBPF code and will actually load it into the kernel?"
Nice try, but I don't think so. That would be similar to distributing the assembly code of a GPL program written in C. GPL v2 says:
For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.
GPL v3 says:
The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities.
This answer from the FSF FAQ on GPL pretty much settles the debate, in my opinion.
When is a program and its plug-ins considered a single combined program?
It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program. A main program that uses simple fork and exec to invoke plug-ins and does not establish intimate communication between them results in the plug-ins being a separate program.
If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program, which must be treated as an extension of both the main program and the plug-ins. If the main program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.
Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.
In my totally non-expert opinion, this description of a program/plugin is very similar to a Python/eBPF pair. It consists in two programs that communicate through shared memory using complex data structures. In most of the use cases I have seen the eBPF program is effectively a plugin of the Python program.
Using non-GPL eBPF helpers
I have seen that most of the eBPF helpers don't require GPL-compatibility. I think it is perfectly possible to load a non-GPL eBPF program as long as it doesn't use GPL-only helpers.
Examples of GPL-only helpers:
Examples of non-GPL helpers:
So I'd recommend looking for all the eBPF helpers that exist, and see if you can accomplish your task without needing GPL-only helpers. For instance, to read some bytes from a network packet, instead of:
ret = bpf_probe_read(data, ((u8)skb) + off, sizeof(data));
you can use the specialized, non-GPL helper:
ret = bpf_skb_load_bytes(skb, off, data, sizeof(data));