[License Review Request] kong/blixt

[mrbobbytables]

Kong would like to donate the blixt project to Kubernetes. However, sections of it are licensed under GPL. These sections are eBPF related and linked to kernel code which are obligated to be GPL compatible.

Is this an acceptable use of GPL licensed code that can be accepted by the Kubernetes project? Semi-related, but with the rise in eBPF this might be an issue in general for other projects - is there a good path forward for them?

cc @shaneutt

[astoycos]

As an additional data point here...we're already actively using GPL in https://github.com/kubernetes-sigs/kpng specifically within the ebpf-backend POC, so there is some precedent.

[mrbobbytables]

That was not known to any of the admins. We do have a small subset of things that are GPL that have been approved, but that was not escalated for review (AFAIK)

[astoycos]

Yep you're right, at the time none of us (kpng maintainers) realized it was something which needed to be escalated for review, sorry about that :(

[BenTheElder]

RE: Allowed licenses, see: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/vendor.md#reviewing-and-approving-dependency-changes

Maybe we need something more discoverable, in the main kubernetes repo a small group aware of these rules review and approve vendor/ changes, but they should generally apply to the rest of the org as well, particularly the CNCF's license policy which isn't even Kubernetes specific ....

As a project we receive organization wide audit reports annually from the CNCF with compliance issues flagged for remediation

[jayunit100]

ouch , sorry folks, what should we do, short term about that?

• get approval ?
• temporary revert the GPL violations ?

[shaneutt]

* temporary revert the GPL violations ?

That would mean pulling the entire eBPF backend out wouldn't it?

[astoycos]

Yeah for sure... Unless I could figure out how to license it under BSD-2-Clause solely instead? Today the KPNG bpf-backend in KPNG is (LGPL-2.1 OR BSD-2-Clause) and BSD-2-Clause Is one of the listed "Approved Licenses"

[astoycos]

Some Additional notes here from my own understanding that I hope legal and others will take into consideration....

• Cilium is already a CNCF project and their licensing practices are in line with what we've done in KPNG and could do with Blixt... i.e bpf code is dual licensed as (GPL OR BSD-2) and all userspace code is Apache 2.0
• The BPF object code (even if GPL licensed) can be used in K8s since the GPL doesn’t pass on to any k8s components - for all licensing purposes the bpf part is considered a separate bundle

[dave-tucker]

To add some more references to Andrew's point above, see BPF Licensing

The important points are:

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.

Most BPF code is going to need access to GPL only helpers, which mandates the use of a GPL compatible license.

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.

The key point here is that the blob of BPF bytecode is a "separate executable process"

[richardfontana]

If the code in question here is dual licensed under GPLv2 OR the 2-clause BSD license, why does that fall afoul of the Kubernetes license allowlist policy? It would seem that it is "fully licenseable under . . . BSD-2-Clause" by definition. Just a thought, maybe "fully licenseable" is supposed to be interpreted differently.

[shaneutt]

If the code in question here is dual licensed under GPLv2 OR the 2-clause BSD license, why does that fall afoul of the Kubernetes license allowlist policy? It would seem that it is "fully licenseable under . . . BSD-2-Clause" by definition. Just a thought, maybe "fully licenseable" is supposed to be interpreted differently.

Presently for the project in question there's no OR it's only GPLv2.

[richardfontana]

Presently for the project in question there's no OR it's only GPLv2.

Oops, I didn't read the comments carefully and see that now. Sorry!

[shaneutt]

Presently for the project in question there's no OR it's only GPLv2.

Oops, I didn't read the comments carefully and see that now. Sorry!

No worries. If it would definitively be the case that switching to GPLv2 + BSD-2-Clause would mean we can resolve this and move forward with the repository migration, we would consider doing that.

[nikhita]

@joannalee333 -- can you help here?

[nikhita]

@caniszczyk can you please advise on how to proceed here?

[mrbobbytables]

FYI for folks, this is being looked into - just no status update yet.

[shaneutt]

We're getting close to a point where we'll make our first release. After which our hope would be to start integrating the tool with Gateway API for CI testing, which we obviously wont be doing while the licensing is in question. So just wondering if anyone can provide a rough time estimate here, as we will start being blocked by this soon? Thank you! :bow:

[ahrkrak]

ouch , sorry folks, what should we do, short term about that?

• get approval ?
• temporary revert the GPL violations ?

Just want to add for clarity, when @jayunit100 refers to "GPL violations" I read that as meaning violations of the CNCF policy regarding approval bring required for any GPL code included in CNCF projects, NOT that there is any violation of the GPL itself.

[astoycos]

Correct @ahrkrak there has not been any violation of the GPL itself :)

Aside from that are there any updates here? We officially cut our first pre-release and would like to keep moving right along.

As mentioned above here and here we're not the first ones doing ebpf in a CNCF project and it's been a bit surprising that this issue has labored on for so long.

Please let us know if we can help in any way!

[ahrkrak]

I agree. I think that the CNCF Governing Board should update its policies and state that for eBPF programs that will run in the kernel, it is accepted that GPL license is required and that is automatically OK for any project (with that limited scope) without requiring an exception process. Has this got the eyes of the appropriate people who can make that happen?

[shaneutt]

We're not really sure @ahrkrak, if that's something that you'd be able to help us with we would greatly appreciate it.

[nikhita]

Has this got the eyes of the appropriate people who can make that happen?

Yes, this is in the queue to be reviewed soon. 👍 cc @amye

[astoycos]

As even more extra information here :)

This issue https://github.com/cilium/cilium/issues/18823 documents when Cilium went through the exact same thing with the CNCF license review and ended up deciding to go with GPL-2.0-only OR BSD-2-Clause for their BPF code.

[shaneutt]

We (the Blixt maintainers) opted to convert to the known accepted dual-license of GPLv2 + BSD-2-Clause for our eBPF code (see https://github.com/kong/blixt/issues/78 and also https://github.com/kubernetes/org/issues/3875#issuecomment-1456514371). With that change to the already accepted license: is it the case that this request is no longer needed, should we consider it resolved?

[shaneutt]

This merged today, also appears relevant for precedence: https://github.com/cncf/sandbox/issues/7

[shaneutt]

@nikhita @amye, related to https://github.com/cncf/foundation/issues/474#issuecomment-1456516725 now that we've moved to GPLv2 + BSD-2-Clause to be in line with other accepted projects using eBPF, can we close this are we all set?

[shaneutt]

We're at a point with this project where we're ready to integrate it with Gateway API, and we're coming up on Kubecon and would like for the project to not be in this limbo as we'll be trying to recruit more contributors. Given that we made the move to the GPLv2 + BSD-2-Clause which appears to be the fully allowed license, can someone please confirm whether there's anything else that would need to be done to consider this resolved?

[joannalee333]

Hi everyone, just letting you know that this is in the queue. External counsel is reviewing this, then it will go to the Legal Committee, and finally to the Governing Board for approval per the CNCF charter. in the meantime, we may be coming back with questions about the GPL components to help the Legal Committee make an informed recommendation. Thank you for your patience as we work through a backlog of issues with a newly formed committee that is still developing its processes.

[astoycos]

Thanks @joannalee333!

Sorry to poke again, but I think we're just a bit confused on the need for a new legal review at all at this point. We're now following the exact same licensing as Cilium, which was already approved by the cncf (see https://github.com/cilium/cilium/issues/18823 and https://github.com/cncf/sandbox/issues/236). Furthermore our bpf code license GPL-2.0-only OR BSD-2-Clause is approved under the approved licenses for the CNCF allowlist license policy.

[amye]

Thanks for your patience as we have been looking into the licensing questions here. After discussing with LF's legal counsel, we have a few questions that we'd like the blixt maintainers to confirm, along with a couple of comments about the procedural steps.

1. The kernel's document on eBPF licensing at https://docs.kernel.org/bpf/bpf_licensing.html talks about a few different contexts for eBPF-related code. Are we correct in understanding that the blixt/dataplane directory contains just eBPF bytecode programs, and not any eBPF implementation / interpreter or runtime code?

2. Relatedly, based on the comments in this issue thread, are we correct that the blixt/dataplane code makes use of some "GPL only BPF helper functions"?

3. In what way does this blixt/dataplane code link to or interact with the rest of blixt? For example, is it statically linked or dynamically linked with blixt, or if it executes as a fully-separate executable process, how does it interact with blixt?

4. Finally, regarding the change from GPL-2.0-only to GPL-2.0-only OR BSD-2-Clause: is it documented anywhere that all contributors to the blixt/dataplane code have agreed to this relicensing? Since prior contributors would presumably have contributed under just GPL-2.0-only, can you confirm that all such contributors have OK'd the additional BSD-2-Clause option -- grateful if you can point to where this is documented?

Regarding the process: although the Allowlist policy does include BSD-2-Clause on its list of licenses, please note that the Allowlist policy is specifically about third-party components. In other words, it applies as an automatic approval for components that are upstream and separately-developed third-party dependencies, not CNCF code itself.

Because of this, under the CNCF charter, section 11(e), the Governing Board would need to approve code that would be maintained as a GPL-2.0-only OR BSD-2-Clause portion of a CNCF project:

(e) All projects evaluated for inclusion in the CNCF shall be completely licensed under an OSI-approved open source license. If the license for a project included in CNCF is not Apache License, Version 2.0, approval of the Governing Board shall be required.

Given that, we will be asking the Governing Board to consider whether to approve an exception to maintain this portion of blixt under GPL-2.0-only OR BSD-2-Clause. Your answers to the questions above will be very helpful in giving us the context to discuss this with the Governing Board and its Legal Committee.

[amye]

@mrbobbytables - checking in on this!

[mrbobbytables]

cc @shaneutt

[richardfontana]

Regarding the process: although the Allowlist policy does include BSD-2-Clause on its list of licenses, please note that the Allowlist policy is specifically about third-party components. In other words, it applies as an automatic approval for components that are upstream and separately-developed third-party dependencies, not CNCF code itself.

Because of this, under the CNCF charter, section 11(e), the Governing Board would need to approve code that would be maintained as a GPL-2.0-only OR BSD-2-Clause portion of a CNCF project:

(e) All projects evaluated for inclusion in the CNCF shall be completely licensed under an OSI-approved open source license. If the license for a project included in CNCF is not Apache License, Version 2.0, approval of the Governing Board shall be required.

Given that, we will be asking the Governing Board to consider whether to approve an exception to maintain this portion of blixt under GPL-2.0-only OR BSD-2-Clause. Your answers to the questions above will be very helpful in giving us the context to discuss this with the Governing Board and its Legal Committee.

Could they use GPL-2.0-only OR Apache-2.0? (I don't understand why you'd need a GPLv2-compatible license on one half of a dual license if the other half is GPLv2.)

[shaneutt]

@amye thank you so much for your response! Here are the answers to your questions:

The kernel's document on eBPF licensing at https://docs.kernel.org/bpf/bpf_licensing.html talks about a few different contexts for eBPF-related code. Are we correct in understanding that the blixt/dataplane directory contains just eBPF bytecode programs, and not any eBPF implementation / interpreter or runtime code?

The dataplane directory contains both eBPF bytecode programs and code that loads the eBPF bytecode as well as updates the BPF maps used by the bytecode programs.

Relatedly, based on the comments in this issue thread, are we correct that the blixt/dataplane code makes use of some "GPL only BPF helper functions"?

The dataplane code makes use of helper functions provided by the kernel such as bpf_redirect_neigh.

In what way does this blixt/dataplane code link to or interact with the rest of blixt? For example, is it statically linked or dynamically linked with blixt, or if it executes as a fully-separate executable process, how does it interact with blixt?

The dataplane code is discreet and isolated with fully-separate executables. The rest of the code communicates with it over a network.

Finally, regarding the change from GPL-2.0-only to GPL-2.0-only OR BSD-2-Clause: is it documented anywhere that all contributors to the blixt/dataplane code have agreed to this relicensing? Since prior contributors would presumably have contributed under just GPL-2.0-only, can you confirm that all such contributors have OK'd the additional BSD-2-Clause option -- grateful if you can point to where this is documented?

The change is documented in this Github pull request:

https://github.com/Kong/blixt/pull/79

In that pull request all contributors to the dataplane code have approved the licensing change (they have also all signed an Apache2 CLA).

---

As for some of your comments regarding the specific licensing choices I have some comments and questions:

We are completely fine with using Apache2 license instead of the BSD-2-Clause if that would work and be faster.

Is it actually necessary for the dataplane directory to be under GPLv2 based on our usage?

Again thank you, let us know if there are any additional questions and how we can continue to help with the process!

[amye]

Relatedly, based on the comments in this issue thread, are we correct that the blixt/dataplane code makes use of some "GPL only BPF helper functions"?

The dataplane code makes use of helper functions provided by the kernel such as bpf_redirect_neigh.

Following up on this, can you list the GPL-only BPF helper functions, or confirm there are none?

[shaneutt]

Following up on this, can you list the GPL-only BPF helper functions, or confirm there are none?

bpf_redirect_neigh as mentioned before, and also bpf_csum_diff.

[lizrice]

This comment doesn't directly affect this issue but more the general principle of licensing eBPF programs

FWIW using GPL-licensed helper functions isn't the only reason an eBPF program may need to have a GPL-compatible license; some BPF program types also require it.

Alexei Staravoitov (eBPF co-maintainer in the kernel) has also stated that "all meaningful bpf programs are GPL" because key helper functions bpf_perf_event_output, bpf_ktime_get_ns and bpf_trace_printk are all GPL-ed.

[amye]

This is currently in the queue for review for Legal Committee.

[lizrice]

With the goal of getting this reviewed by the Legal Committee in the 8 June meeting, I volunteered to write up a proposal for a license exception to consider for eBPF progams (across the CNCF), with an explanation of why. Here is a first draft - comments and feedback are welcome.

As I understand it, the legal committee are lawyers rather than technologists, though I think it is reasonable to assume they have some familiarity with licensing issues around Linux and thus understand terms like “user space”, “syscall interface” and “kernel”.

[richardfontana]

@lizrice thanks for writing this up - I am on the Legal Committee and will point the committee members to your document.

[lizrice]

Folks from several projects and organizations have read now through that licensing exception request so I believe it's now ready for the legal committee to review - but please do feel free to add comments / suggestions if necessary (it has comment-only access so that any changes will be visible)

[blixtra]

Thanks for the document, @lizrice. I think it explains the situation well. The Inspektor Gadget team is keeping an eye on this and is very interested in having some clarity on this subject.

[shaneutt]

Hey :wave:

Just checking in: where do we stand with this one, particularly where is the energy around making it OK to have GPLv2 projects at right now?

[richardfontana]

@shaneutt The CNCF legal committee is currently voting on a policy exception relating to eBPF programs to propose to the CNCF board.

[shaneutt]

Awesome, thanks for the update. :vulcan_salute:

[shaneutt]

Just checking in again: has the voting concluded? Do we have any expectation when it may be tallied? Is this voting a public thing that can be linked to so that we can subscribe/track it?

[richardfontana]

In this case, we conducted the vote by email because we didn't have quorum at the last meeting of the committee a month or so ago. The vote was supposed to have been concluded but I am not sure we succeeded in getting quorum for the vote, i.e. I am not sure enough committee members participated. I'll check up on this. Sorry about the continued delay!

[shaneutt]

Ok, thanks for the update!

[leogr]

Hi :wave:

Falco maintainer here. Unfortunately, I noticed this discussion a bit late, but I wanted to raise a crucial point regarding the ongoing licensing exception request.

Falco offers both an eBPF probe and a kernel module to its users (they are more or less interchangeable, and users can choose). These components of Falco were approved at the incubation stage, being dual licensed under GPLv2/MIT. So, we thought we were okay with this.

Now, I notice this discussion and, as I can see from @lizrice's licensing exception request, kernel modules were not mentioned.

Both eBPF probes and kernel modules are programs running in kernel space with the exact licensing requirements, as per the Linux kernel licensing rules. Kernel modules can be helpful since they are often deployed in environments where eBPF support is too limited or when higher efficiency is required. Granting such general exceptions for kernel modules as well would be beneficial for new and existing projects in the CNCF landscape that intend to employ kernel modules.

Now, since I couldn't find any information about the content of the proposal being voted on and its current status, I would like to ask a few questions (:thinking: not sure who to ask, @richardfontana?):

• Is the licensing exception request being voted exclusively targeting eBPF programs?
• Are we still in time to request the inclusion of kernel modules?

Thanks, Leo

cc @TheFoxAtWork @justincormack @amye

[lizrice]

I can see the logic of @leogr's comment, but since the request for eBPF already got discussed by the Legal Committee I'd say it would make sense to raise kernel module license exceptions as a separate issue for their next meeting