[Evan Huus <eapache@xxxxxxxxx>]

I have posted a change for review at [1] that cleans up a number of
the listed errors. I have also emailed Graeme and Ulf (at the most
recent addresses I could find) to try and get permission to add the
license header to their files.

If all of the above is successful then the only remaining problems
will be the reedsolomon decoding. Still looking for ideas on that
one...

Evan

[1] https://code.wireshark.org/review/#/c/145/

On Wed, Feb 5, 2014 at 4:03 PM, ronnie sahlberg
<ronniesahlberg@xxxxxxxxx> wrote:
> On Wed, Feb 5, 2014 at 12:54 PM, Evan Huus <eapache@xxxxxxxxx> wrote:
>> The buildbot is down to reporting only 13 files with license header
>> problems. Let's get them cleaned up and finally have that step pass :)
>>
>> ---
>>
>> 'diameter/dictionary.dtd'
>> 'wimaxasncp/dictionary.dtd'
>>
>> These two DTD files both appear to be extracted from C code at some
>> point in the past. We already have an 'ignore' rule set up for the
>> whole "dtds/" directory, so I'm happy ignoring these as well unless
>> there is some way we should be embedding license information in them?
>>
>> 'epan/dissectors/pidl/mapi/request.cnf.c'
>> 'epan/dissectors/pidl/mapi/response.cnf.c'
>>
>> These two appear to be Ronnie's. They're not entirely C code so I'm
>> not sure if embedding a license header is possible. Ronnie, I assume
>> we're safe to add an exception for these as well?
>
> Thank you for doing this work.
> Yes, please add an exception.
> Or, since the files do contain some code fragments, you can add a GPL header.
>
>
>>
>> 'epan/reedsolomon.h'
>> 'epan/reedsolomon.c'
>>
>> These two simply say "May be used under the terms of the GNU public
>> license" which presumably means GPLv1. I have not been able to find
>> specific information on compatibility, but it appears that the GPLv1
>> does not have an "or later" clause. This means we need to
>> remove/replace/relicense it. I found another reed-solomon C library
>> (http://sourceforge.net/projects/rscode/) but it's only available
>> under the GPLv3+ which we also can't use. *sigh*. Anyone have any
>> ideas?
>>
>> 'epan/dtd_grammar.h'
>> 'epan/dfilter/grammar.h'
>>
>> These two are generated by lemon, so we can just add an ignore rule for them.
>>
>> 'doc/make-authors-short.pl'
>> 'docbook/custom_layer_pdf.xsl'
>>
>> This two appear to have been written by Ulf Lamping. The latter is
>> XML, not C, so (as with the DTD files above) I'm not sure what that
>> means for its status.
>>
>> 'doc/make-authors-format.pl'
>> 'doc/perlnoutf.pl'
>>
>> These two appear to have been written by Graeme Hewson.
>>
>> 'autogen.sh'
>>
>> The very first version was written by Gilbert Ramirez according to
>> git, but it's undergone so many changes since then I'm not sure how we
>> should attribute it...
>>
>> ---
>>
>> So it looks like the only potentially problematic one is going to be
>> the reedsolomon code. The rest involve either tracking down the
>> original author, or agreeing (eg for autogen.sh) that we should just
>> add a GPLv2+ header and be done with it.
>>
>> Thoughts?
>>
>> Evan
>> ___________________________________________________________________________
>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe