Indeed, the spirit of the initial work was to publish source code, compiled BPF bytecode, and Makefile for re-generating the latter. I have no clue regarding licensing, I'll trust you guys on that.
On 30/11/2017 18:39, Thomas Monjalon wrote: > 30/11/2017 18:20, Stephen Hemminger: >> On Thu, 30 Nov 2017 18:05:22 +0100 >> Thomas Monjalon <tho...@monjalon.net> wrote: >> >>> 30/11/2017 17:54, Stephen Hemminger: >>>> Loading BPF is a could solution to doing dynamic flow matching. >>>> It needs to be done differently to be accepted. >>>> >>>> Putting raw machine instructions in source code is as bad as binary >>>> blobs. You need to provide original source of program and then have >>>> build instructions to create any needed code. >>> The source program is provided in this patch: tap_bpf_program.c >>> It is pre-compiled to avoid requiring too many dependencies when building >>> DPDK. >> But the "freedom to modify" comes into play here. If a *evil* vendor builds >> an application based on DPDK and does not provide source. Then user still >> deserves >> the right to modify the eBPF program that it loads as GPL. The best solution >> is to make the TAP PMD loader routine load the program from a file. >> Although I am certainly not a FSF legal scholar, putting GPL'd object code in >> TAP PMD risks accusations of being a derived or combined work. > Good point. > The compiled BPF may be provided as a plugin file. > So we would be free to not package this GPL file.
