Re: Scapy licensing issue in FD.io projects [Was: TRex distribution and licensing of external libraries]
From: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) [mailto:vrpolak@...]
Sent: Friday 11 October 2019 17:20
To: Kinsella, Ray <ray.kinsella@...>; Maciek Konstantynowicz (mkonstan) <mkonstan@...>; tsc@...; Ed Warnicke (eaw) <eaw@...>
Subject: RE: [tsc] Scapy licensing issue in FD.io projects [Was: TRex distribution and licensing of external libraries]
> How is scapy invoked, is it a separate process or is it directly like with VPP/TRex?
The setup details differ. The C projects (VPP and the main part of TRex server)
are usually separate processes, being accessed by official interfaces.
But each setup contains (at least) one process
which is running Python interpreter running mixed code.
[rk] Ok, the principle of separation is important here.
[rk] As anything that ‘links’ directly with Scapy is affected.
[rk] You _can_ still talk to Scapy via an interface that achieves separation; stdin/stdout, network, socket etc.
By mixed code I mean the upper layers are coming from FD.io repositories
(thus Apache license 2.0 applies), but the virtualenv contains scapy installation.
[rk] Containing a Scapy installation does not automatically effect anything else.
[rk] You are, however obliged to ensure the source code of the version of scapy you used was ‘available on request’.
The upper layers are importing scapy modules and classes,
instantiating scapy objects and calling scapy methods.
This would be permitted if scapy was LGPL, but not for GPL.
[rk] Agreed anything that ‘link’s with Scapy in this way, would have to be GPL’ed I imagine.
[rk] For TRex/VPP
[rk] We need an IP diagram with the modules/processes involved, how there are linked and their licensing.
[rk] It doesn’t need to be exhaustive, but it needs to show the main actors.
[rk] Ed – is there a LF process to resolve these kinds of issues?
How is the data (packets) scapy creates consumed by VPP/TRex,
[rk] This is safe, I would think.
I am not entirely sure how vpp "make test" sends packets to VPP.
[rk] I thought it was veth network interface or similar, can you check?
Scapy does not send packets to TRex, scapy objects are only used
as a "template" for TRex to create packets (in C) from.
[rk] Ok – but we need detail here, how does TRex – ‘get’ the template?
In VPP and CSIT tests, scapy is mainly used
to parse packets received (via an official interface) from VPP.
> how TRex & VPP “talk” to scapy
Simplified from the above:
TRex and VPP (almost) do not talk to scapy on their own.
But most verify jobs are running fd.io python programs
which depend on scapy as a library.
From: Kinsella, Ray <ray.kinsella@...>
So there is a lot of information thanks for putting this together.
What is of primary importance to understand is how TRex & VPP “talk” to scapy.
Scapy is GPL, any modifications made to Scapy are therefore clearly covered by the GPL.
On Behalf Of Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io
Adding some technical details with quick links.
Scapy license  is GLP, not LGPL.
In python, using "import" statement amounts to linking,
which creates  a combined program, instead of
a mere aggregation of different programs.
FD.io projects apply Apache 2.0 license,
TRex , VPP  and CSIT .
The scapy code is imported, and the internal data structures
are used by TRex , VPP  and CSIT python code
(source code is in C), and the packaged Python code
is not related to scapy as far as I know.
which run the code containing (modified) scapy parts
and original VPP python parts linked together,
From: Maciek Konstantynowicz (mkonstan) <mkonstan@...>
Resending from Cisco email account as it’s back and cleared for sending emails to tsc mailer.
Adding Miroslav, Hanoh and Vratko who has been also involved here (Miroslav brought up the issue).
Per our discussion on FD.io TSC call few mins ago, pls advise on the next steps.
Specifically, how to articulate this case in a crisp and succinct manner for LF(N) legal advisor?