[netsa-tools-discuss] SiLK check-struct and license issues

[B Galliart]

I am trying to do real-time detection of DDoS attack where using SiLK in
the standard way is too costly given the amount of traffic I processing.  I
found replacing the readerWriteRecord function in flowcap.c seem to get me
the performance I am looking for but also means I'm linking directly into
flowcap itself.

In terms of the license, by being "GPLv2," linking in any GPLv3 works is
prohibited.  I was just hoping to leave my options open such that if SiLK
could be made available as "GPLv2 or higher" which would be compatible with
GPLv3.  It might be possible this would be a better discussion for the
licensing terms for the upcoming SiLK v4 project rather than SiLK v3?

Thanks


On Mon, May 18, 2015 at 1:15 PM, Chris Inacio <inacio at cert.org> wrote:

>
> > On May 16, 2015, at 12:34 AM, B Galliart <bgallia at gmail.com> wrote:
> >
> > It looks like at some point the ski_extrwrec_t template in
> libflowsource/skipfix.c was extended to include flowStartNanoseconds and
> flowEndNanoseconds.  However, skiCheckDataStructure() does not seem to have
> been updated accordingly.  The result is that all entries past
> flowEndMicroseconds report as "hole" when running check-struct.  Adding the
> two entries after flowEndMicroseconds for the check data structure function
> seems to address this.
> >
> > Is it safe to assume that the holes stated in an unmodified SiLK v3.10.1
> check-struct can be ignored?  Also, can the alignment errors for mplsLabels
> and pad also be ignored?
> >
> > There also seems to be a couple issues with the LICENSE.txt which states
> SiLK is dual licensed:
> >
> > (1) Licensed under "Gnu Public License (GPL)" which is problematic since
> GPL is actually "General Public License" and not a Gnu Public License.  If
> I could get a reply from a member of the SiLK team that SiLK is intended to
> be under the "GNU General Public License v2," that would be helpful.
> >
> > (2) This is not critical, but is something I find confusing.  The
> secondary license is stated to be DFARS 252.227.7013 of which the text of
> the license does not seem to be provided in the doc directory. Based on
> what I can find, DFARS 252.227-7013 [1] was written to be applied to
> licensing of data instead of software.  Shouldn't this be licensed under
> DFARS 252.227-7014 [2] instead?
> >
> > [1]
> http://farsite.hill.af.mil/reghtml/regs/far2afmcfars/fardfars/dfars/Dfars252_227.htm#P296_15657
> > [2]
> http://farsite.hill.af.mil/reghtml/regs/far2afmcfars/fardfars/dfars/Dfars252_227.htm#P684_47378
> >
> > Lastly, also while not critical, I wondered if it is possible to open a
> discussion of relicensing SiLK under "GNU General Public License (GPL) v2
> or later" instead of strictly GPL v2?  Likewise of relicensing libfixbuf
> under "GNU Lessor General Public License (LGPL) v2.1 or later" instead of
> strictly LGPL v2.1?
> >
> > To put it another way, is there any plans to allow derived works to be
> licensed under or combined with GPLv3 works?
> >
> > Thanks
> >
>
> Mr. Galliart,
>
> I’ll comment on the licensing, but not in the SiLK code - I’m sure one of
> the actual SiLK developers will be much better suited to that.
>
> (1) The code is (as you have astutely pointed out,) currently licensed
> under GNU General Public License v2.  We will update that mistake in our
> text for all our future releases.  I would like to understand more as to
> what you would like to do with the SiLK code and about the possibilities of
> GPL v3 licensing.  As it currently stands, I do not have permission from
> Carnegie Mellon University legal counsel to license our software under GPL
> v3.  The patent release included in GPL v3 is very complicated for the
> University.  Are there other alternatives that might work?  From my reading
> of the license FAQ, the biggest hangup seems to be the requirement for
> Installation Instructions on GPL v3.
>
> I’m interested in supporting wider uses of SiLK, but some type of
> compromise is likely needed.
>
>
> (2) Again, sadly, I will defer to my legal counsel, but I will raise this
> comment with them.  The government rights language was not particularly
> written by the software developers, but by our lawyers, and we’re not able
> to change or edit that text without their review.  I appreciate your
> reading of all the language though.  If you are a government user, you
> should email me off-list and discuss other potential options.
>
> (P.S. to (2) - we don’t plan on including all the DFARS language in the
> SiLK distribution, only enterprising souls such as yourself want to dig
> into the DFARS to read its licensing terms.)
>
>
> Regards,
> --
> Christopher Inacio
> Technical Manager, Development and Operations
> CERT/CC, Software Engineering Institute
> Carnegie Mellon University
> inacio at cert.org
>
>
>
>
-------------- next part --------------
HTML attachment scrubbed and removed