I don't see how this is any better. Instead of calling to python that imports GPL libraries, we now call to scapy that calls to python that imports GPL libraries. In both cases we communicate through shell pipes and the only "copyright"-able piece here is scapy API. (There are arguments about whether APIs are copyrightable.)
I'd suggest the team doesn't indulge in attempts to fix something that no one here (I think) can confirm is an issue (or that if so, that it can be resolved by calling to scapy instead of python). I'd suggest that the team asks for advice from a lawyer. I think Red Hat engineers should have access to one internally if needed. I am of course not the one to block such a patch, nor I think it's that important to block it, since I'm not concerned about any license infringement either way. Ihar On Thu, Apr 20, 2023 at 9:54 AM Simon Horman <[email protected]> wrote: > > On Thu, Apr 20, 2023 at 03:13:20PM +0200, Dumitru Ceara wrote: > > Hi Ihar, Simon, > > > > This is not very pretty but would it improve the situation (not even > > importing scapy anymore)? > > IANAL, but I would be more comfortable with this approach. > > > > > fmt_pkt() { > > echo "import binascii; \ > > out = binascii.hexlify(raw($1)); \ > > out.decode()" | scapy -H 2> /dev/null | awk '{print $4}' | > > cut -f 2 -d "'" > > } > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
