[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! 🙇

[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 cilium/cilium#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 kubernetes-sigs/blixt#78 and also kubernetes/org#3875 (comment)). 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: cncf/sandbox#7

[shaneutt]

@nikhita @amye, related to #474 (comment) 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?

[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 👋

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

[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 👋

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

[leogr]

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

Hey @lizrice Thank you for the response! 🙏 How can we make this happen? Let me know if we can assist in some way.

I couldn't find clear information on the approval process for licensing exceptions. Do you know if it is documented somewhere? 🤔

[shaneutt]

I couldn't find clear information on the approval process for licensing exceptions. Do you know if it is documented somewhere? 🤔

I think I would start by creating an issue like this one, labeled [License Review Request] <org>/<project>?

Also while I'm here: hello everyone! anyone got any news here?

[amye]

Approved by Legal Committee and GB as of a vote for 8-31, minutes will be approved as of the next governing board meeting.

A blanket exception for in-kernel eBPF programs licensed under either of the following licenses, either on its own or dual licensed in combination with any license already on the CNCF Licensing Allowlist Approved Licenses list (e.g., MIT License):

• GPL 2.0
• GPL 2.0 or later

[blixtra]

This is great news!

[astoycos]

Thanks for all the efforts here everyone!! 🎆

[shaneutt]

Yes, thank you! 🖖