Make ebpf_kernel.h released under GPL-2.0-only or Apache-2.0 licenses #5114
Conversation
Signed-off-by: Andy Fingerhut <[email protected]>
Signed-off-by: Andy Fingerhut <[email protected]>
| Licensed under the Apache License, Version 2.0 (the "License"); | ||
| you may not use this file except in compliance with the License. | ||
| You may obtain a copy of the License at | ||
| This file is dual-license, so that when it is included from a source |
There was a problem hiding this comment.
What makes this file GPL? Because of Linux types.h include?
There was a problem hiding this comment.
The comments try to explain, but let me know if a different explanation in the file's comments would make it clearer.
This file is currently #include'd by the C programs output by the p4c-ebpf back end, which in turn after they are compiled are intended to be loaded into the kernel as EBPF binaries, and executed within the kernel.
The easiest way to be clean on licenses for code run within the kernel is to release its source as GPL v2. Anything else and you want to get lawyers involved, I think.
There was a problem hiding this comment.
Based on this article: https://ebpf.io/blog/ebpf-licensing-guide/
The license can be non-GPL but you would need to set it. Afaik we set it to GPL so that comment applies:
p4c/backends/ebpf/ebpfProgram.h
Line 60 in 2776b19
There was a problem hiding this comment.
Note that if you read that licensing guide, they advise that most EBPF programs running within the kernel must be GPL 2.0.
They also advise: it is common practice for the EBPF code loaded into the kernel to be released under GPL 2.0, but for user-space applications that are their control plane programs, e.g. that add/modify/delete table entries in the running EBPF program, they can be licensed with the same choices available that any user-space application running on Linux has, i.e. they can be proprietary, Apache 2.0, GPL v*, etc. as the application developer wishes, subject to following the license of any libraries you use or other source code you depend upon.
This is why I think it is a reasonable choice for p4c to find those handful of files that are loaded into the Linux kernel and license them as GPL-2.0-only, or dual-licensed as (GPL-2.0-only or Apache-2.0), because some of the header files are included both from in-kernel EBPF programs, and from user-space programs. Fortunately, this appears like it might be only 2 files in the entire repo. Most of the EBPF-related source files in the p4c repo are either part of the p4c-ebpf executable, or some test program that runs in user space only.
There was a problem hiding this comment.
I have added a link to this article, and a couple of paragraphs of text summarizing how it applies to p4c source code, in commit 6 of my other PR documenting a proposed plan for licensing files in the p4c repo: 906fcf1
| @@ -1,17 +1,14 @@ | |||
| /* | |||
| Copyright 2018 VMware, Inc. | |||
| SPDX-License-Identifier: (GPL-2.0-only or Apache-2.0) | |||
There was a problem hiding this comment.
Technically we use libbpf to build the binaries for the kernel, which also has a complicated but more permissive license:
https://github.com/libbpf/libbpf?tab=readme-ov-file#license
I do not know whether that has any implications, quite the headache.
There was a problem hiding this comment.
The license there appears to be the user's choice of BSD-2-Clause or LGPL-2.1. That is compatible with using it from a GPL-2.0-only program, or from an Apache-2.0 program, which are all we ever care about (and rarely if ever the GPL-2.0-only choice, but nice to know it is covered.)
The good news for the headache is that we can document it once, and the set of files involved should change extremely rarely, so we can automate simple license checks that these files continue to have the licenses we think are safe and defensible, and then the headache is past :-)
Note: Changes may take a few seconds to appear on GitHub Pages. Please refresh the page if you do not see the updates immediately. |
No description provided.