On 4/20/23 16:28, Ihar Hrachyshka wrote: > 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. >
Coming back to this, I reached out to some of our commercial counsel folks and the reply I got is: It could have implications for the little generated Python script, but I don't see how it could have any further implications. The GPL is not a "project-scoped" license. It applies to "Programs" and "works based on the Program" and explicitly does not cover "mere aggregation" of separate works. I think as traditionally interpreted, it is just the generated Python script importing scapy that could be seen as one "work based on [scapy]". The issue for the generated Python script is a license compatibility issue. scapy is apparently licensed as 'GPLv2 only'. The general license of OVN is Apache-2.0, so one might suppose that the Python script is also supposed to be Apache-2.0. The conventional view is that the Apache License 2.0 is not compatible with "GPLv2 only" and I think this is a justifiable interpretation of the two licenses. However if I'm understanding correctly, the Python script here is just what's embodied here: from scapy.all import *; \ + import binascii; \ + out = binascii.hexlify(raw($1)); \ + print(out) If so, it's hard to see how that is copyrightable at all and therefore licensable in any meaningful sense under the Apache License. For that reason I don't even think there is a license compatibility issue. So I think we're OK and we don't require additional changes to the code today. Regards, Dumitru > 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
