Add document describing the goals and plan of p4c software license tracking #5110
Conversation
…acking Signed-off-by: Andy Fingerhut <andy.fingerhut@gmail.com>
jafingerhut
requested review from
fruffy,
ChrisDodd,
kfcripps,
pkotikal,
thomascalvert-xlnx and
vgurevich
Signed-off-by: Andy Fingerhut <andy.fingerhut@gmail.com>
|
@Dscano Trying to ping you in a comment, since I could not find you in the list of suggested Github reviewers for this project. |
license-details/README.md
Outdated
|
|
||
| # Why is the top level LICENSE file insufficient? | ||
|
|
||
| One short answer is that not all files in this repository can legally |
There was a problem hiding this comment.
This model sounds questionable to me. This should be a big exception. Similar to the inbound-outbound model LLVM has: https://llvm.org/docs/DeveloperPolicy.html#copyright-license-and-patents
There was a problem hiding this comment.
This topic is on the agenda for the next P4 TST meeting on 2025-Feb-07, and seems worth discussing there. I am glad if this early draft gets better plans made, before we spend too much time on what it currently describes.
license-details/README.md
Outdated
| @@ -0,0 +1,138 @@ | |||
| # Introduction | |||
There was a problem hiding this comment.
I would not create a new folder for this, that seems like waste of space. Instead this should be part of docs.
There was a problem hiding this comment.
If we have any docs related to writing downstream backends, this might go near them, or at least be linked from them. I think putting it into docs makes sense.
There was a problem hiding this comment.
In commit 12 I moved all of the new files into the docs directory, with file names beginning with licenses
license-details/README.md
Outdated
|
|
||
| # Source files that cannot be released under the Apache 2.0 license | ||
|
|
||
| ## Python source files that import the Scapy library |
There was a problem hiding this comment.
We should probably get rid of scapy entirely if it causes such head aches. We practically only use it for a couple function calls.
There was a problem hiding this comment.
I think it is more than a couple. grep through the p4c repo for occurrences of scapy, and you can see that in the ebpf back end test code, it uses a fair number of functions, not just Ether.
Are you mainly hoping to eliminate the use of scapy in the p4c repo only? Or also the following p4lang repos?
- tutorials
- switch
- p4-dpdk-target
- behavioral-model
- p4app
- ptf
There was a problem hiding this comment.
Also I suspect that ptf Python code (most of the ptf code) probably needs to be GPL v2 because it imports scapy, and p4c imports ptf in several places, too.
There was a problem hiding this comment.
At least for eBPF I remember writing this code and it was mostly used for sniffing packets. There was new code added for uBPF however which we would need to take a look at.
PTF already has been changed to be independent of scapy with p4lang/ptf#147. We just need to add a module and switch the default. Could be a GSoC project :).
There was a problem hiding this comment.
It is also important that the compiler code itself has no GPL dependencies. Just the test scaffolding we use may involve GPL components.
There was a problem hiding this comment.
It is also important that the compiler code itself has no GPL dependencies. Just the test scaffolding we use may involve GPL components.
If the current PR does not make exactly this point very clear, please tell me how to make it more clear.
There was a problem hiding this comment.
If the current PR does not make exactly this point very clear, please tell me how to make it more clear.
For example, the section of line 44 gives the impression that these are compiler source files, when they are in fact test framework source files. There is no explicit mention that both scapy and eBPF dependencies are unrelated to compiler source code.
There was a problem hiding this comment.
In commit 4, I have added a new short first paragraph explicitly mentioning this to the section you mention. I also added a note to the beginning of the next section, but it will need updating after we confirm the result of a more careful job.
Note: Changes may take a few seconds to appear on GitHub Pages. Please refresh the page if you do not see the updates immediately. |
|
@AlexeyAliev You might want to look at this |
Signed-off-by: Andy Fingerhut <andy.fingerhut@gmail.com>
... making it very clear that we expect these files not to be used as part of a P4 compiler executable. Signed-off-by: Andy Fingerhut <andy.fingerhut@gmail.com>
Signed-off-by: Andy Fingerhut <andy.fingerhut@gmail.com>
license-details/README.md
Outdated
| executables are released, with no copyleft obligation for those | ||
| companies to release their back end source code. | ||
|
|
||
| This is allowed, because the `p4c` front source files are licensed |
There was a problem hiding this comment.
Did you mean "frontend source files" or did you mean "source code" or anything else?
There was a problem hiding this comment.
Would it be clearer to you if I replaced it with something like this?
"because p4c source files published in the https://github.com/p4lang/p4c repository are licensed ..."
There was a problem hiding this comment.
I went ahead and made that replacement in commit 7 of this PR. Feel free to suggest other wordings if that is not clear enough.
license-details/README.md
Outdated
| # Linux Foundation review of P4.org software licenses in published code | ||
|
|
||
| In early 2024 P4.org became part of The Linux Foundation. In November | ||
| 2024 the Linux Foundation appointed someone to do a quick review of |
There was a problem hiding this comment.
I do not know how formal this document is supposed to be but "someone" sounds a little too non-specific.
There was a problem hiding this comment.
I don't exactly feel comfortable putting their name in here without asking them. My intent is that this file will be around for as long as this repository will exist. Any alternate suggestions?
There was a problem hiding this comment.
I propose designating a licensing specialist instead of appointing someone.
There was a problem hiding this comment.
I made this change in commit 8.
license-details/README.md
Outdated
| `ptf` package imports `scapy`). | ||
| (b) files that indirectly import the Scapy package, by importing a | ||
| package that imports Scapy | ||
|
|
There was a problem hiding this comment.
The bigger problem here is the licensing of the PTF itself, isn't it?
There was a problem hiding this comment.
Regardless of whether the https://github.com/p4lang/ptf source files are licensed under Apache 2.0 or GPL v2, I don't think it changes things for the p4c source files very much. If we put all source files that import scapy or ptf (or both) under GPL v2, they are still all purely test programs that are not part of p4c executables.
There was a problem hiding this comment.
One wrinkle added to my previous statement: It appears perhaps not allowed to have a program A (e.g. a test program in this p4c repo) that is GPLv2 licensed, and import the ptf package, if ptf is released under Apache 2. It might be a solution to release ptf under a dual license, e.g. (Apache-2.0 or GPL-2.0-only) at the users choice. Ugh.
There was a problem hiding this comment.
I have added to this PR a separate short-ish article specifically on the question of compatibility of Apache-2.0 and GPL v2 licenses, named apache-and-gpl-v2-licenses.md
In short, it does NOT try to argue that they are compatible, or that they are not compatible. It tries to present a case that it is so unclear whether they are compatible, that without good legal advice, we should be cautious and avoid mixing them in P4 Consortium products, in the same program. (In different programs created from different sources files, there should be no problem, as long as we keep GPL v2 out of the p4c compiler executables.)
I have also added a short-ish article specifically on how this applies to the question of importing ptf and scapy packages in a Python program, named ptf-and-scapy.md
Please take a look at those and add your review comments, if you are interested.
license-details/README.md
Outdated
There was a problem hiding this comment.
I would add reference to this file into the LINCENSE file, below the actual license.
license-details/README.md
Outdated
| @@ -0,0 +1,138 @@ | |||
| # Introduction | |||
There was a problem hiding this comment.
If we have any docs related to writing downstream backends, this might go near them, or at least be linked from them. I think putting it into docs makes sense.
license-details/README.md
Outdated
| If any subtle questions arise as to whether any P4 compiler | ||
| executable, e.g. `p4c-ebpf`, must thus be released under GPL v2.0, we | ||
| will raise these questions to the P4 Technical Steering Team for their | ||
| advice. |
There was a problem hiding this comment.
Wouldn't this affect a particlar P4C executable, not any P4C executable? Of would it affect all if EBPF/TC/... targets are enabled? We should not cross-contaminate other targets with GPL files.
There was a problem hiding this comment.
My belief is that this could easily be constrained to affect only executables involving EBPF, if it even does affect back ends involving EBPF. I will try to change the wording to the following if that makes it clearer:
"If any subtle questions arise as to whether a particular P4 compiler back end, e.g. p4c-ebpf, must thus be released under GPL v2.0 ..."
license-details/README.md
Outdated
| TODO: We should summarize those, and their licenses, here, as advice | ||
| to those who wish to produce proprietary `p4c` executable binaries. |
There was a problem hiding this comment.
If you (or anyone reading this) would like to make a list of libraries that p4c executables use, that would be much appreciated.
To be thorough, it would be good to mention different options that various current build options provide. For example, I recall discussions of using dymamic linking with glibc, vs. musl, and maybe one or two other choices.
I also suspect different back ends might have different libraries that only they use.
license-details/README.md
Outdated
| Our plan is to release all of the following kinds of source files | ||
| under the GPL v2.0 license, the same as the Linux kernel: | ||
|
|
||
| (a) files that are intended to be compiled and loaded into the kernel | ||
| via EBPF. | ||
| (b) header files included from files in category (a). |
There was a problem hiding this comment.
Are these files directly using a GPL content? Or are they just intended to be used in GPL-licensed "product" and Apache is not compatible with that (in which case maybe we should dual-license them).
There was a problem hiding this comment.
Whether Apache 2.0 is or not compatible with GPL is an open debate, IANAL, but as far as I know, this was never tested in the court. One way to workaround it is to introduce an exception (like in LLVM).
There was a problem hiding this comment.
If you want to distribute source files intended to be compiled and loaded into a running Linux kernel, and you want to license it under anything but GPL v2.0, I'm pretty sure you need really good lawyers giving you really carefully thought out advice.
Is there any reason you'd like to avoid licensing such files as GPL v2.0?
Adding SPDX-License-Identifier lines to every source file is not current practice in p4lang projects, so that part is definitely new. Python programs importing scapy are not explicitly marked as GPL v2.0 anywhere in any p4lang repository, as far as I can see, so that is new. As my document tries to make clear, but help me make it clearer if it is not, a primary goal is to continue to allow p4c compiler executables be released without copyleft requirements of releasing its source code. That has never changed. |
Also add first draft of a document specifically about the situation of ptf and scapy packages. Signed-off-by: Andy Fingerhut <andy.fingerhut@gmail.com>
Signed-off-by: Andy Fingerhut <andy.fingerhut@gmail.com>
Signed-off-by: Andy Fingerhut <andy.fingerhut@gmail.com>
…ity question Signed-off-by: Andy Fingerhut <andy.fingerhut@gmail.com>
and use it instead of saying whether a choice is legal or illegal. Signed-off-by: Andy Fingerhut <andy.fingerhut@gmail.com>
Signed-off-by: Andy Fingerhut <andy.fingerhut@gmail.com>
|
@vlstill @vgurevich @fruffy @asl @ChrisDodd @AlexeyAliev Thanks for your review comments or other attention so far. Given the flurry of comments since yesterday, I have responded with a flurry of additional commits. As of writing this comment there are 11 commits on the latest version of this PR, attempting to address most of the comments. If you have time and interest, I welcome your next round of comments. A fairly significant change since the initial version is that instead of claiming that I know whether Apache 2 and GPL v2 licenses are compatible or not, I simply say that it is so unclear whether they are compatible, that mixing them would put The P4 Consortium onto "questionable legal ground", a phrase that I use repeatedly. Even if those two license do turn out to be compatible to combine together into the same executable program, settled by future case law, unless someone can legally advise us that this is a solid legal choice to make, we should avoid doing so. I believe it should be relatively easy for us to avoid doing so, certainly far easier than getting legal advice that supports other choices. |
…enses' Signed-off-by: Andy Fingerhut <andy.fingerhut@gmail.com>
|
For those who may be curious, I believe that for the I have not finished my analysis of files related to EBPF yet (help welcome there), but I believe at least most of the EBPF-related files in this repo are user-space programs that interact with the EBPF program loaded into the kernel. Since they are not loaded into the Linux kernel, their choice of license is not influenced by that. I would not be surprised if we ended up with 0, or a small handful, of source files that I would recommend the GPL v2 license for reasons of running in the kernel, perhaps only the C files output by the |
... intended to make things a little clearer. Signed-off-by: Andy Fingerhut <andy.fingerhut@gmail.com>
…d BSD licenses Signed-off-by: Andy Fingerhut <andy.fingerhut@gmail.com>
|
Thanks for looking at this Andy. Regarding the eBPF backend, there are at least a couple files I know of which are included by the generated programs for the kernel target: https://github.com/p4lang/p4c/blob/main/backends/ebpf/target.cpp#L38-L41 |
It seems possible that there are only 2 source files that we could release under a dual license of (GPL-2.0-only or Apache-2.0), that would enable EBPF files compiled into the kernel to include them and be GPL-2.0-only, or the same files could be included in an Apache-2.0-licensed user space program and be fine that way, too. See #5114 for the files. |
Signed-off-by: Andy Fingerhut <andy_fingerhut@alum.wustl.edu>
Related PRs:
Add SPDX-License-Identifier: GPL-2.0-only to Python source files using scapy #5111 I believe there are only 13 Python source files that import the scapy library directly, or indirectly through importing another package that imports scapy. They are all test programs used for testing P4 programs compiled for particular back ends, e.g. BMv2, EBPF, or UBPF. NONE of these Python source files are part of any p4c executable. This PR proposes making those 13 files released under a GPL-2.0-only license, because they import scapy.
Make ebpf_kernel.h released under GPL-2.0-only or Apache-2.0 licenses #5114 I believe the 2 files with proposed dual license (GPL-2.0-only or Apache-2.0) in this PR are the ONLY files that should have a GPL-2.0-only license because of EBPF. Those are the only files with source code that is compiled to a binary that is loaded and run in the Linux kernel. All other EBPF-related files are part of a p4c compiler back end, only executed in a user space process, or control plane EBPF programs run only as user space processes. All of the source code that is only executed in user space programs can be released under Apache-2.0.