On Tue, May 02, 2023 at 02:29:51PM +0200, Dumitru Ceara wrote: > 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.
Thanks Dumitru, I appreciate you getting advice on this. There are no further issues from my side. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
