Hi Reinhard, First, I dont want this to become a tackle :) I just intended to point out Luca that this kind of change could affect a possible revenue for its project either pfring itself, or its libraries or whatever.
I'm not suggesting wither that the price for this is way out. As you say, there are other alternatives that could be compelling instead of paying thousands of dollars: specialized cards, using NPUs like Octeon or Raza instead of x86, etc etc At the same time, I believe this is precisely the kind of "actors" that could help fund a bit of the development. Including a specialized card is great, and in some cases the only way to solve this for extreme performance, but means extra cost (per box), unavailable formats (like blades) or even that for lower market you can use the same technology. NPUs are even a more difficult ball game, you have to purchase SDKs, long time for development adapting your existing software, MOQ, etc. Of course existing software works, but doesnt do it fast, that were pf-ring and companions excel. IMHO, many companies could be interested in this as an intermediate solution between current software based technology and specialized hardware. That our case too :) !!! Current Luca's model is a bit thin in that side as the reality is you can use all of it just by a download price and in many cases not even that. This particular points (dual licensing) is precisely one of the few its work is really protected from "vampires" :))) Something in the lines of say 3K$ for a LGPL version and say 12K$ for a BSD one, is attractive for the company purchasing it and helps funding the project. Hey, thats the price just for the card :) Regards El vie, 31-07-2009 a las 11:02 +0200, Pfau, Reinhard escribió: > Hi, > > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of > > Jaime Nebrera > > Sent: Friday, July 31, 2009 9:01 AM > > To: [email protected] > > Subject: Re: [Ntop-misc] PF_RING: licensing issues with libpcap? > > > [...] > > > > > As the thread started, the company was evaluating using it > > but had a licensing conflict. This would mean they would have > > to develop such software themselves. > > Not really. > We have an existing software which is based on libpcap and only expects > a shared lib with pcap interface. > The software itself works without PF_RING, too. > > But it was used together with an older version of PF_RING together with the > libpcap-ring which was available at the time when the software was made. > At this time PF_RING cames with a patched version of libpcap. The patch > didn't change the license of libpcap; it was still BSD, so it could be used > in closed-source (CS) software. (And was used) > > Later (Dezember 2005,January 2006) the libpfring was made and the libpcap-ring > Started to use that lib. > Here the licensing problem was introduced: libpcap (BSD) based on libpfring > (GPL). > This combination of BSD and GPL is at least harmful, more likely it's just > illegal in general since these licences are not compatible in general. > > This problem only affects the userland side; the PF_RING kernel part must > be GPLed, and that's not a problem. > > > > > > Now with my idea the company (all companies that play this kind of > > game) has two choices: > > > > 1) Develop in house something as powerful as pf_ring > > (increased time to market, salaries, etc) as with GPL they > > cant use it. > > Well, not really. PF_RING in the kernel could still be used under GPL > (and as a kernel module it must be GPL). > One alternative for us was to take the latest libpcap-ring version without > libpfring; and update it to talk with the current PF_RING kernel module. > The result would still be BSD licensed and could be used in CS. > > Another alternative was to use special ethernet-capture-cards which are > deliverd > together with their own version of libpcap. > (In fact: our test lab is evaluating such cards...) > > > > > 2) Pay to get rid of the GPL clause, either for LGPL (they > > dont plan to add value to pf_ring itself) or BSD (they plan > > to add value to pf_ring itself and want it to stay private) > > As said: the special combination of BSDed libpcap-ring and GPLed libpfring > we have/had here has a questionable legal state... > Independant of the use in open or proprietary products... > > > > > Those are precisely the only ones that could be interested > > in paying for this. > > > > I can put our case, in a different realm. We needed a > > database for our app and of course we thought on MySQL. At > > that time the library was LGPL. When they changed to GPL we > > had 2 choices, either pay MySQL or find an alternative. We > > decided to go for PostgreSQL (BSD). This involved loosing > > some job already done for MySQL (thanks God was early in the > > dev cycle). > > Yeah, PostgreSQL support in many products became better since > the MySQL client lib moved from LGPL to GPL license :-) > > > > > Here things are quite different. pf_ring has no real > > competitor. Its the best. If you want to play this game > > "closed source" pay for it. > > As said above: specialized ethernet-capture cards with their own > (usually prorietary) drivers are an alternative. > But of course these have the drawback that "standard" network > cards are not supported. > But we are talking about special use cases; using specialized > (and more expensive) hardware is acceptible. > > > > > IMHO, the problem with pf_ring right now is that most people > > use it at a very basic level and from open source apps. Very > > few are really using it at its full (except you with nprobe). > > Sadly most companies just put more iron in the equation. But > > with 10GE surging this could for sure change quite a bit (I > > assure you, with "standard" technology most of them use you > > cant get a crap of performance and they are being beaten by > > NPU based platforms. If they want to stay in the market they > > have to find a solution that is cheaper than the NPU way but > > gives them that level of > > performance) > > > Since I started the thread: for the stuff at our company I'm working > on we just need the network traffic to analyse it. > It doesn't matter how the traffic is fed into the software it only > matters that it is fed into the software. > So using PF_RING/libpcap-ring is one of our options; using special NPUs > (capture cards) is another. > > > Just my 2ct. > > > Greetings, > Reinhard. > _______________________________________________ > Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc -- Jaime Nebrera - [email protected] Consultor TI - ENEO Tecnologia SL Pol. PISA - C/ Manufactura 6, P1, 3B Mairena del Aljarafe - 41927 - Sevilla Telf.- 955 60 11 60 / 619 04 55 18 _______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
