scapy is GPL but PTF is not about ptf HOT 18 CLOSED

Adding @jnfoster. I think from a p4.org usage perspective, changing the ptf license to a GPL-compatible one is fine, since ptf is used as a binary. But it may go against the p4.org charter / philosophy to produce software under a GPL license.

from ptf.

Thanks. I'll look into it with the TST.

from ptf.

How painful would it be to detangle Scapy from PTF? (not proposing that, but just want to understand the tradeoffs for the TST discussion...)

from ptf.

If there is an alternative Python package we can use to craft network packets, it should not be too painful (we may have to redefine some custom headers, such as INT). But after a quick search I couldn't find one, so writing such a library from scratch is likely to mean much more work.

from ptf.

I think it might make sense to ask some lawyers to take a (second) look, since PTF is simply importing Scapy modules. I might be wrong, but I doubt that Scapy license is really so restrictive.

from ptf.

Python's import is equivalent to linking in C/C++. This would be fine if scapy were LGPL, but it's GPL, alas.

from ptf.

I am not a lawyer, but they do not seem to be equivalent. Linking in C/C++ is done with the binary code (and that's precisely the reason for LGPL), where as in case of Python we are importing modules in source code.

Where does it say that linking the binary library and importing Python modules are?

from ptf.

To be more precise, Python's import is equivalent to #include in C/C++, which usually induces linking. These are mechanisms that create a more intimate connection with the imported/included/linked component (e.g., sharing an address space and data structures) than what is typically available via the command-line or IPC mechanisms if the component were a self-contained program. For GNU's take, see https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation.

As an aside, one could conceivably create a GPL server wrapper around a GPL library and make requests to the server from non-GPL code. AGPL was created to close this loophole.

from ptf.

I think we should take a look at how Scapy is used in PTF. For example, the functions like simple_tcp_packet() are very convenient, but not essential to the framework. The other place is the Mask module, but, again, it is essential for the tests more than for the framework.

In other words, I wonder whether it might be possible to separate Scapy in such a way, that people can write tests with it if they have it (and if they feel comfortable importing and using it in their own tests), but the framework doesn't have to rely on it.

It might not be easy, since legally speaking tests are imported into PTF :), but I think it makes sense to at least ask.

from ptf.

How are we using Scapy in PTF? If we're just using it as a Python library for parsing/deparsing and representing common packet formats, I wonder if we could switch to another open-source library without much pain.

For example, it's been a long time, but I really liked how POX represented packets...
https://github.com/noxrepo/pox/tree/eel/pox/lib/packet
And it's Apache2-licensed.

Someone would have to do the work to port, but is swapping out Scapy for POX a possible path forward?

from ptf.

I do not think that POX is a good replacement for Scapy, so it would be nice to modularize PTF so that people can have a choice, rather than replace a good package with not-so-good one.

from ptf.

Creating a packet interface for PTF sounds good.

Just curious: what do you not like about POX?

from ptf.

Try to code the basic stuff, like quickly creating a packet from scratch of parsing it in POX and I think it will be pretty clear. It is also designed more for scripting rather than interactive work.

from ptf.

Fair enough. I had a pleasant experience but that was building SDN controllers a loooong time ago and not in the settings you're using it.

from ptf.

having skimmed only https://github.com/p4lang/ptf/blob/master/src/ptf/packet.py and ignorant of any other current or planned feature usage of scapy -- I believe the BSD licensed dpkt is a possible alternative.

from ptf.

Hi all,
Reopening discussion, as we have a proposal for making PTF more independent from Scapy: #147
This is the initial proposal and we are open for the discussion on how to improve it to meet your needs in this topic.

To summarize, our proposal is to make packet module pluggable. Thus, one can develop his/her own packet manipulation framework and then, create a 'packet module implementation' which utilizes this framework. By default, it will be Scapy (current packet.py contents are moved to packet-scapy.py).

from ptf.

My proposed solution (#147) has been approved by some ppl and I need to have a review from one of the maintainers. Who is able to check it out? This will enable pipeline with tests to be run.

from ptf.

Addressed by #147

from ptf.