Re: [Wireshark-dev] Registering protocol details

[Paul Offord]

Thanks Pascal,

I think you are right.  I’ll rethink my code.

Best regards…Paul

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Pascal Quantin
Sent: 07 August 2016 20:52
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Registering protocol details

Hi Paul,

2016-08-07 18:42 GMT+02:00 Paul Offord 
mailto:paul.off...@advance7.com>>:
Hi Anders,

Ah – I understand.  I had asked Gerald about that at SF16 and he mentioned the 
ability to use other pcap-ng block types.  I’d like to do that in the future, 
but I don’t want to tackle it yet.  This wouldn’t overcome the problem I have 
anyway.

So going back to the original question, can I call function calls like 
proto_register_add_subtree and proto_register_add_item from with the 
dissect_foo function or do I have to make them from proto_register_foo?

As far as I know you need to register fields before dissection starts. It can 
be done dynamically based on some file selected in preferences, but I don't 
think it can be done on the fly during dissection.
That said when looking at the proto_register_field_array() code, I do not see 
any assertion related to this, but I would not be surprised if things like 
filtering do not work as expected if you add new fields as dissection goes. And 
as far as I can tell, no dissector is doing something as you suggest yet.
I will let another developer correct my assumptions if I'm wrong.
Regards,
Pascal.

__

This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system.

Any views or opinions expressed are solely those of the author and do not 
necessarily represent those of Advance Seven Ltd. E-mail transmission cannot be 
guaranteed to be secure or error-free as information could be intercepted, 
corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of e-mail transmission.

Advance Seven Ltd. Registered in England & Wales numbered 2373877 at Endeavour 
House, Coopers End Lane, Stansted, Essex CM24 1SJ

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Current Lua test failures on the buildbot

[Peter Wu]

On Sat, Aug 06, 2016 at 08:34:10PM -0700, Guy Harris wrote:
> 
> > On Aug 6, 2016, at 8:22 PM, Guy Harris  wrote:
> > 
> > On Aug 6, 2016, at 7:47 PM, Guy Harris  wrote:
> > 
> >> It also fails on an Ubuntu 14.10 system; the TShark build information is:
> >> 
> >>TShark (Wireshark) 2.3.0 (v2.3.0rc0-230-ge32890a from master)
> >> 
> >>Copyright 1998-2016 Gerald Combs  and 
> >> contributors.
> >>License GPLv2+: GNU GPL version 2 or later 
> >> 
> >>This is free software; see the source for copying conditions. There is 
> >> NO
> >>warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
> >> PURPOSE.
> >> 
> >>Compiled (64-bit) with libpcap, without POSIX capabilities, with libnl 
> >> 3, with
> >>GLib 2.42.1, with zlib 1.2.8, without SMI, without c-ares, with Lua 
> >> 5.2, without
> >>GnuTLS, without Gcrypt, without Kerberos, without GeoIP.
> >> 
> >>Running on Linux 3.16.0-44-generic, with locale en_US.UTF-8, with 
> >> libpcap
> >>version 1.6.2, with zlib 1.2.8.
> >>Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (with SSE4.2)
> >> 
> >>Built using gcc 4.9.1.
> > 
> > Succeeds on Ubuntu 12.10; the TShark build information is:
> > 
> > TShark (Wireshark) 2.3.0 (v2.3.0rc0-231-g66711eb from master)
> > 
> > Copyright 1998-2016 Gerald Combs  and 
> > contributors.
> > License GPLv2+: GNU GPL version 2 or later 
> > 
> > This is free software; see the source for copying conditions. There is 
> > NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
> > PURPOSE.
> > 
> > Compiled (64-bit) with libpcap, without POSIX capabilities, with libnl 
> > 2, with
> > GLib 2.32.4, with zlib 1.2.3.4, without SMI, without c-ares, with Lua 
> > 5.1, without
> > GnuTLS, without Gcrypt, without Kerberos, without GeoIP.
> > 
> > Running on Linux 3.2.0-101-generic, with locale en_US.UTF-8, with 
> > libpcap
> > version 1.1.1, with zlib 1.2.3.4.
> > Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (with SSE4.2)
> > 
> > Built using gcc 4.6.3.
> > 
> > Older GLib *and* older Lua; I'll see if I can try it with Lua 5.2.
> 
> Succeeds with Lua 5.2 as well; the TShark build information is:
> 
>   TShark (Wireshark) 2.3.0 (v2.3.0rc0-231-g66711eb from master)
> 
>   Copyright 1998-2016 Gerald Combs  and 
> contributors.
>   License GPLv2+: GNU GPL version 2 or later 
> 
>   This is free software; see the source for copying conditions. There is 
> NO
>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
> PURPOSE.
> 
>   Compiled (64-bit) with libpcap, without POSIX capabilities, with libnl 
> 2, with
>   GLib 2.32.4, with zlib 1.2.3.4, without SMI, without c-ares, with Lua 
> 5.2,
>   without GnuTLS, without Gcrypt, without Kerberos, without GeoIP.
> 
>   Running on Linux 3.2.0-101-generic, with locale en_US.UTF-8, with 
> libpcap
>   version 1.1.1, with zlib 1.2.3.4.
>   Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (with SSE4.2)
> 
>   Built using gcc 4.6.3.
> 
> So it looks as if something changed between GLib 2.32.4 and GLib 2.42.1.

Could be a bug/missing feature introduced with PCRE 8.34, see
https://bugzilla.gnome.org/show_bug.cgi?id=725072

Related WIP patch (that depends on glib work):
https://code.wireshark.org/review/10741
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checklicenses.py

[João Valverde]

On 08/05/2016 10:31 PM, Guy Harris wrote:

On Aug 5, 2016, at 12:17 PM, João Valverde  
wrote:


The Debian licensecheck.pl version prior to the Smedegaard take over was 
standalone. I think we should import that to tools.


We might still want to look over the list of files currently being complained 
about (and make sure that the files we end up fixing are still checked):

'test/run_and_catch_crashes' has non-whitelisted license 'UNKNOWN'
'macosx-support-lib-patches/qt-fix-pc-files' has non-whitelisted 
license 'UNKNOWN'
'macosx-support-lib-patches/qt-fix-pc-file' has non-whitelisted license 
'UNKNOWN'

They were missing copyright notices.  I added some.

'.tx/config' has non-whitelisted license 'UNKNOWN'
'tools/vg-suppressions' has non-whitelisted license 'UNKNOWN'
'tools/cppcheck/includes' has non-whitelisted license 'UNKNOWN'
'tools/cppcheck/suppressions' has non-whitelisted license 'UNKNOWN'
'Vagrantfile' has non-whitelisted license 'UNKNOWN'

Are config files worthy of a license, or should we just add these to an ignore 
list (even if they're Ruby programs, like Vagrantfile)?

'epan/enterprise-numbers' has non-whitelisted license 'UNKNOWN'
'dfilters' has non-whitelisted license 'UNKNOWN'
'smi_modules' has non-whitelisted license 'UNKNOWN'
'cfilters' has non-whitelisted license 'UNKNOWN'
'services' has non-whitelisted license 'UNKNOWN'

Are data files for Wireshark worthy of a license, or should we just add these 
to an ignore list?

'tools/asn2deb' has non-whitelisted license 'GPL (v2 or later) GPL (v2 
or later) (with incorrect FSF address)'
'tools/idl2deb' has non-whitelisted license 'GPL (v2 or later) GPL (v2 
or later) (with incorrect FSF address)'

Address fixed, hopefully that'll make it happy.

'tools/pre-commit' has non-whitelisted license 'UNKNOWN'
'tools/update-tx' has non-whitelisted license 'UNKNOWN'

Alexis, do you want to add a license to these?

'debian/rules' has non-whitelisted license 'UNKNOWN'
'debian/copyright' has non-whitelisted license 'LGPL (v2 or later) GPL 
(v2 or later) LGPL (v2 or later)'
'debian/compat' has non-whitelisted license 'UNKNOWN'
'debian/geoip_db_paths' has non-whitelisted license 'UNKNOWN'
'debian/dirs' has non-whitelisted license 'UNKNOWN'
'debian/control' has non-whitelisted license 'UNKNOWN'
'debian/changelog' has non-whitelisted license 'UNKNOWN'
'debian/patches/series' has non-whitelisted license 'UNKNOWN'
'debian/templates' has non-whitelisted license 'UNKNOWN'
'debian/postinst' has non-whitelisted license 'UNKNOWN'
'debian/license-text-about-dialog' has non-whitelisted license 'UNKNOWN'
'debian/source/format' has non-whitelisted license 'UNKNOWN'

Balint?  What does Debian do about licenses on these sorts of files?

'epan/dissectors/packet-dtn.c' has non-whitelisted license 'GPL (v2 or 
later) GPL (v2 or later)'

I don't see any real problem with the license; it might just be written in a 
way that confuses the checker.

'epan/dissectors/dcerpc/drsuapi/Makefile' has non-whitelisted license 
'UNKNOWN'
'epan/dissectors/dcerpc/butc/Makefile' has non-whitelisted license 
'UNKNOWN'
'epan/dissectors/dcerpc/budb/Makefile' has non-whitelisted license 
'UNKNOWN'

Is there some reason why these are treated differently from other 
generated-from-PIDL dissectors?

'epan/dissectors/packet-ppi.c' has non-whitelisted license 'BSD (3 
clause) GPL (v2)'
'epan/crypt/airpdcap_ccmp.c' has non-whitelisted license 'BSD (3 
clause) GPL (v2)'
'epan/crypt/airpdcap_interop.h' has non-whitelisted license 'BSD (3 
clause) GPL (v2)'
'epan/crypt/airpdcap_tkip.c' has non-whitelisted license 'BSD (3 
clause) GPL (v2)'
'epan/crypt/airpdcap.c' has non-whitelisted license 'BSD (3 clause) GPL 
(v2)'
'epan/crypt/wep-wpadefs.h' has non-whitelisted license 'BSD (3 clause) 
GPL (v2)'
'epan/crypt/airpdcap_system.h' has non-whitelisted license 'BSD (3 
clause) GPL (v2)'
'epan/crypt/airpdcap_int.h' has non-whitelisted license 'BSD (3 clause) 
GPL (v2)'
'epan/crypt/airpdcap_debug.h' has non-whitelisted license 'BSD (3 
clause) GPL (v2)'
'epan/crypt/airpdcap_user.h' has non-whitelisted license 'BSD (3 
clause) GPL (v2)'
'epan/crypt/airpdcap_ws.h' has non-whitelisted license 'BSD (3 clause) 
GPL (v2)'
'wsutil/airpdcap_wep.c' has non-whitelisted license 'BSD (3 clause) GPL 
(v2)'

Is there some reason not to treat "you can license this under the BSD license or 
under the GPL" as an acceptable license?


Please review https://code.wireshark.org/review/#/c/16957/.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubsc

[Wireshark-dev] Lua 5.3

[João Valverde]

Is moving to Lua 5.3 something we should look into?

The 64 bit integer support seems really promising.

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Lua 5.3

[Pascal Quantin]

Hi João,

2016-08-08 18:52 GMT+02:00 João Valverde :

> Is moving to Lua 5.3 something we should look into?
>
> The 64 bit integer support seems really promising.
>

Hariel explained us that Lua 5.3 was a completely different language (a bit
like what you have between Python 2.X and 3.X). You can find much more info
(from people knowing what they are taling about - so not me ;)) in bug
10881.

Pascal.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checklicenses.py

[Guy Harris]

On Aug 8, 2016, at 9:00 AM, João Valverde  
wrote:

>> Is there some reason not to treat "you can license this under the BSD 
>> license or under the GPL" as an acceptable license?
> 
> Please review https://code.wireshark.org/review/#/c/16957/.

That's still special-casing the dual-licensed files; any reason not to just 
treat it as an acceptable license by adding "BSD (3 clause) GPL (v2)" to 
WHITELISTED_LICENSES?

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checklicenses.py

[João Valverde]

On 08/08/2016 06:42 PM, Guy Harris wrote:

On Aug 8, 2016, at 9:00 AM, João Valverde  
wrote:


Is there some reason not to treat "you can license this under the BSD license or 
under the GPL" as an acceptable license?


Please review https://code.wireshark.org/review/#/c/16957/.


That's still special-casing the dual-licensed files; any reason not to just treat it as 
an acceptable license by adding "BSD (3 clause) GPL (v2)" to 
WHITELISTED_LICENSES?


Repeating what I said in the Gerrit change (this is just my 
understanding of course):


There's a difference between "choose license A or B" and "this code is 
license A and that addition is license B".


We don't want to whitelist BSD + GPLv2, i.e, a BSD licensed file with a 
GPLv2 contribution, because it would be incompatible with GPLv3 code.

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checklicenses.py

[Guy Harris]

> On Aug 8, 2016, at 11:00 AM, João Valverde  
> wrote:
> 
> 
> 
> On 08/08/2016 06:42 PM, Guy Harris wrote:
>> On Aug 8, 2016, at 9:00 AM, João Valverde  
>> wrote:
>> 
 Is there some reason not to treat "you can license this under the BSD 
 license or under the GPL" as an acceptable license?
>>> 
>>> Please review https://code.wireshark.org/review/#/c/16957/.
>> 
>> That's still special-casing the dual-licensed files; any reason not to just 
>> treat it as an acceptable license by adding "BSD (3 clause) GPL (v2)" to 
>> WHITELISTED_LICENSES?
> 
> Repeating what I said in the Gerrit change (this is just my understanding of 
> course):
> 
> There's a difference between "choose license A or B" and "this code is 
> license A and that addition is license B".

Then perhaps licensecheck.pl should distinguish between them:

diff --git a/tools/licensecheck.pl b/tools/licensecheck.pl
index ae2a92e..03adb35 100755
--- a/tools/licensecheck.pl
+++ b/tools/licensecheck.pl
@@ -800,6 +800,10 @@ sub parselicense {
 $license = "WTFPL $license";
 }
 
+if ($licensetext =~ /Alternatively, this software may be distributed under 
the terms of/i) {
+$license = "Multiply-licensed: $license";
+}
+
 $license = "UNKNOWN" if (!length($license));
 
 # Remove trailing spaces.

and the list of whitelisted licenses modified to include a number of

'Multiply-licensed: XXX YYY"

entries for cases where we accept dual-licensed code:

diff --git a/tools/checklicenses.py b/tools/checklicenses.py
index 8ee64f7..dd6ec6a 100755
--- a/tools/checklicenses.py
+++ b/tools/checklicenses.py
@@ -121,6 +121,11 @@ WHITELISTED_LICENSES = [
 'zlib/libpng GPL (v2 or later)',
 'SGI Free Software License B',
 'University of Illinois/NCSA Open Source License (BSD like)',
+
+# Multiply-licensed code, allowed to be released under license
+# A or, alternatively, under license B.
+'Multiply-licensed: BSD (3 clause) GPL (v2)',
+'Multiply-licensed: ISC GPL (v2)',
 ]
 
 

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checklicenses.py

[João Valverde]

On 08/08/2016 07:38 PM, Guy Harris wrote:



On Aug 8, 2016, at 11:00 AM, João Valverde  
wrote:



On 08/08/2016 06:42 PM, Guy Harris wrote:

On Aug 8, 2016, at 9:00 AM, João Valverde  
wrote:


Is there some reason not to treat "you can license this under the BSD license or 
under the GPL" as an acceptable license?


Please review https://code.wireshark.org/review/#/c/16957/.


That's still special-casing the dual-licensed files; any reason not to just treat it as 
an acceptable license by adding "BSD (3 clause) GPL (v2)" to 
WHITELISTED_LICENSES?


Repeating what I said in the Gerrit change (this is just my understanding of 
course):

There's a difference between "choose license A or B" and "this code is license A and 
that addition is license B".


Then perhaps licensecheck.pl should distinguish between them:


[ snipped code sample]

Perhaps... I think that distinction only matters to the copyright 
holder, CACE Technologies, now Riverbed I believe.


For the distributor, the Wireshark project, the code is licensed under 
BSD, because it cannot be used with GPLv2+.

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checklicenses.py

[João Valverde]

On 08/08/2016 08:12 PM, João Valverde wrote:



On 08/08/2016 07:38 PM, Guy Harris wrote:



On Aug 8, 2016, at 11:00 AM, João Valverde
 wrote:



On 08/08/2016 06:42 PM, Guy Harris wrote:

On Aug 8, 2016, at 9:00 AM, João Valverde
 wrote:


Is there some reason not to treat "you can license this under the
BSD license or under the GPL" as an acceptable license?


Please review https://code.wireshark.org/review/#/c/16957/.


That's still special-casing the dual-licensed files; any reason not
to just treat it as an acceptable license by adding "BSD (3 clause)
GPL (v2)" to WHITELISTED_LICENSES?


Repeating what I said in the Gerrit change (this is just my
understanding of course):

There's a difference between "choose license A or B" and "this code
is license A and that addition is license B".


Then perhaps licensecheck.pl should distinguish between them:


[ snipped code sample]

Perhaps... I think that distinction only matters to the copyright
holder, CACE Technologies, now Riverbed I believe.

For the distributor, the Wireshark project, the code is licensed under
BSD, because it cannot be used with GPLv2+.


I meant to say cannot be used with GPLv2+ *otherwise*. More accurately 
that accepting GPLv2 only code would mean we can't use GPLv3(+).


Sorry for the confusion.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Lua 5.3

[João Valverde]

On 08/08/2016 05:58 PM, Pascal Quantin wrote:

Hi João,

2016-08-08 18:52 GMT+02:00 João Valverde
mailto:joao.valve...@tecnico.ulisboa.pt>>:

Is moving to Lua 5.3 something we should look into?

The 64 bit integer support seems really promising.


Hariel explained us that Lua 5.3 was a completely different language (a
bit like what you have between Python 2.X and 3.X). You can find much
more info (from people knowing what they are taling about - so not me
;)) in bug 10881.

Pascal.



Thanks for that Pascal. The only sane way to approach the issue IMHO is 
to accept that this may and probably will break backward compatibility 
(not even think about supporting 5.1 or 5.2) and just consider whether 
that break is justified (hint: it is).


Not that I have the skills to do the port, just the time and 
stubbornness to attempt it. :-)

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Documentation error in README.dissector?

[Jaap Keuter]

Hi,

Yes, you could raise a bug. Or try to submit a change rewording this text.

Thanks,
Jaap


On 06-08-16 12:16, Paul Offord wrote:
> Hi,
> 
>  
> 
> README.dissector describes two accessor functions that access null terminated
> strings and return the string length.  The document says:
> 
>  
> 
> -
> 
> gint tvb_get_nstringz(tvbuff_t *tvb, const gint offset, const guint bufsize,
> guint8* buffer);
> 
> gint tvb_get_nstringz0(tvbuff_t *tvb, const gint offset, const guint bufsize,
> guint8* buffer);
> 
>  
> 
> Returns a null-terminated buffer containing data from the specified tvbuff,
> 
> starting at the specified offset, and containing all characters from the
> 
> tvbuff up to and including a terminating null character in the tvbuff.
> 
> "*lengthp" will be set to the length of the string, including the terminating
> 
> null.
> 
> -
> 
>  
> 
> I think these notes have been incorrectly copied and pasted from similar
> functions above this point in the doc.  Three particular points:
> 
>  
> 
> 1.   We pass the address of the buffer we want to use as a parameter
> 
> 2.  The value returned in the string length
> 
> 3.  The length returned doesn’t include the  null terminator
> 
>  
> 
> Am I right?  Should I raise a bug?
> 
>  
> 
> Thanks and regards…Paul
> 

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checklicenses.py

[Guy Harris]

On Aug 8, 2016, at 12:12 PM, João Valverde  
wrote:

> On 08/08/2016 07:38 PM, Guy Harris wrote:
>> 
>>> On Aug 8, 2016, at 11:00 AM, João Valverde 
>>>  wrote:
>>> 
>>> There's a difference between "choose license A or B" and "this code is 
>>> license A and that addition is license B".
>> 
>> Then perhaps licensecheck.pl should distinguish between them:
> 
> [ snipped code sample]
> 
> Perhaps... I think that distinction only matters to the copyright holder, 
> CACE Technologies, now Riverbed I believe.
> 
> For the distributor, the Wireshark project, the code is licensed under BSD, 
> because it cannot be used with GPLv2+.

The license checking process has two parts:

identifying the license(s) for the file;

distinguishing between acceptable and unacceptable licenses.

The first part is what licensecheck.pl does; it doesn't and shouldn't care why 
the license types are interesting, it should just try to determine how the file 
is licensed.  "This file has a mixture of code licensed under license X and 
code licensed under license Y" and "the code in this file, in its entirety, 
could be licensed under either license X or license Y" are two different forms 
of license, so it makes sense to me that the script should report them 
differently.

The second part is what checklicenses.py does.  It's not reporting what license 
the Wireshark Foundation chooses to use for a given file, it's just determining 
whether the license is acceptable for Wireshark or not.

"This file has a mixture of BSD and GPLv2-only code" isn't acceptable, I guess, 
if we have to worry about linking with GPLv3 code outside of Wireshark; we'd 
have to replace all the GPLv2-only code with code licensed under a license 
compatible with the GPLv3 (or get the licensor to change the license to 
GPLv2-or-later).

"This file can, in its entirety, be licensed under the BSD license or the GPLv2 
license, but not any later licenses" is acceptable, as we can choose to license 
it under the BSD license.

So the distinction between those two *does* matter to the Wireshark project - 
we can't choose the BSD license for a file with a mix of BSD and GPLv2-only 
code, but we can do so for dual BSD/GPLv2-only code.

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checklicenses.py

[João Valverde]

On 08/08/2016 10:59 PM, Guy Harris wrote:

On Aug 8, 2016, at 12:12 PM, João Valverde  
wrote:


On 08/08/2016 07:38 PM, Guy Harris wrote:



On Aug 8, 2016, at 11:00 AM, João Valverde  
wrote:

There's a difference between "choose license A or B" and "this code is license A and 
that addition is license B".


Then perhaps licensecheck.pl should distinguish between them:


[ snipped code sample]

Perhaps... I think that distinction only matters to the copyright holder, CACE 
Technologies, now Riverbed I believe.

For the distributor, the Wireshark project, the code is licensed under BSD, 
because it cannot be used with GPLv2+.


The license checking process has two parts:

identifying the license(s) for the file;

distinguishing between acceptable and unacceptable licenses.

The first part is what licensecheck.pl does; it doesn't and shouldn't care why the license types 
are interesting, it should just try to determine how the file is licensed.  "This file has a 
mixture of code licensed under license X and code licensed under license Y" and "the code 
in this file, in its entirety, could be licensed under either license X or license Y" are two 
different forms of license, so it makes sense to me that the script should report them differently.

The second part is what checklicenses.py does.  It's not reporting what license 
the Wireshark Foundation chooses to use for a given file, it's just determining 
whether the license is acceptable for Wireshark or not.

"This file has a mixture of BSD and GPLv2-only code" isn't acceptable, I guess, 
if we have to worry about linking with GPLv3 code outside of Wireshark; we'd have to 
replace all the GPLv2-only code with code licensed under a license compatible with the 
GPLv3 (or get the licensor to change the license to GPLv2-or-later).

"This file can, in its entirety, be licensed under the BSD license or the GPLv2 
license, but not any later licenses" is acceptable, as we can choose to license it 
under the BSD license.

So the distinction between those two *does* matter to the Wireshark project - 
we can't choose the BSD license for a file with a mix of BSD and GPLv2-only 
code, but we can do so for dual BSD/GPLv2-only code.


That's true. The point is that 'BSD + GPL' is different from 'BSD or GPL'.

Mainly what I was trying to say is that this dual licensing distinction 
can already be handled with path-specific exceptions so I guess I'm 
indifferent to adding more code for this.

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checklicenses.py

[Guy Harris]

On Aug 8, 2016, at 3:10 PM, João Valverde  
wrote:

> Mainly what I was trying to say is that this dual licensing distinction can 
> already be handled with path-specific exceptions so I guess I'm indifferent 
> to adding more code for this.

I view path-specific exceptions as workarounds for deficiencies in 
licensecheck, and would prefer to have as few path-specific exceptions as 
possible.  Ideally, the only places where path-specific exceptions would be 
used would be places where licensecheck would need AI rather than pattern 
matching to identify the license. :-)

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checklicenses.py

[João Valverde]

On 08/08/2016 11:15 PM, Guy Harris wrote:

On Aug 8, 2016, at 3:10 PM, João Valverde  
wrote:


Mainly what I was trying to say is that this dual licensing distinction can 
already be handled with path-specific exceptions so I guess I'm indifferent to 
adding more code for this.


I view path-specific exceptions as workarounds for deficiencies in 
licensecheck, and would prefer to have as few path-specific exceptions as 
possible.  Ideally, the only places where path-specific exceptions would be 
used would be places where licensecheck would need AI rather than pattern 
matching to identify the license. :-)



A very reasonable point of view IMO. :-)

To summarize the issue addressed by change 16957, licensecheck.pl 
conflates "BSD and GPLv2" to be the same as "BSD or GPLv2", with its 
simple regex based logic.


We are OK with "BSD or GPLv2" but not "BSD and GPLv2", so whitelisting 
"BSD GPLv2", as licensecheck reports both cases, would be wrong.


We can either add a path-specific exception for this saying "BSD GPLv2 
is really just BSD for these files" or fix licensecheck.pl to be smarter 
about it.

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checklicenses.py

[Guy Harris]

On Aug 8, 2016, at 3:46 PM, João Valverde  
wrote:

> We can either add a path-specific exception for this saying "BSD GPLv2 is 
> really just BSD for these files" or fix licensecheck.pl to be smarter about 
> it.

I vote, as you might expect, for the second choice:

https://code.wireshark.org/review/#/c/16967/

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checklicenses.py

[João Valverde]

On 08/05/2016 10:31 PM, Guy Harris wrote:

On Aug 5, 2016, at 12:17 PM, João Valverde  
wrote:


The Debian licensecheck.pl version prior to the Smedegaard take over was 
standalone. I think we should import that to tools.


We might still want to look over the list of files currently being complained 
about (and make sure that the files we end up fixing are still checked):

'doc/extcap.pod' has non-whitelisted license 'UNKNOWN'
'doc/tshark.pod' has non-whitelisted license 'UNKNOWN'
'doc/randpktdump.pod' has non-whitelisted license 'UNKNOWN'
'doc/sshdump.pod' has non-whitelisted license 'UNKNOWN'
'doc/androiddump.pod' has non-whitelisted license 'UNKNOWN'
'doc/dumpcap.pod' has non-whitelisted license 'UNKNOWN'
'doc/editcap.pod' has non-whitelisted license 'UNKNOWN'
'doc/reordercap.pod' has non-whitelisted license 'UNKNOWN'
'doc/rawshark.pod' has non-whitelisted license 'UNKNOWN'
'doc/mergecap.pod' has non-whitelisted license 'UNKNOWN'
'doc/dftest.pod' has non-whitelisted license 'UNKNOWN'
'doc/ciscodump.pod' has non-whitelisted license 'UNKNOWN'
'doc/randpkt.pod' has non-whitelisted license 'UNKNOWN'
'doc/idl2deb.pod' has non-whitelisted license 'UNKNOWN'
'doc/captype.pod' has non-whitelisted license 'UNKNOWN'
'doc/wireshark-filter.pod' has non-whitelisted license 'UNKNOWN'

What license, if any, should we put on our man pages?


I think we can just use the standard Wireshark GPLv2+ header here, with 
copyright to Gerald and contributors.


Any objections?
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checklicenses.py

[Guy Harris]

On Aug 8, 2016, at 6:30 PM, João Valverde  
wrote:

>> What license, if any, should we put on our man pages?
> 
> I think we can just use the standard Wireshark GPLv2+ header here, with 
> copyright to Gerald and contributors.

Is the GPL an appropriate license for documentation, or would the GFDL be more 
appropriate?

https://www.gnu.org/licenses/licenses.html#FDL

For what it's worth, the Bison man page on my machine has no license on it.  I 
don't know whether any other GNU software that comes with a man page puts a 
license on the man page; perhaps they don't care enough about man pages, as 
opposed to Texinfo documents, to bother with a license.  bison.texinfo is 
licensed under the GFDL:

https://opensource.apple.com/source/bison/bison-14/doc/bison.texinfo
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checklicenses.py

[João Valverde]

On 08/09/2016 02:52 AM, Guy Harris wrote:

On Aug 8, 2016, at 6:30 PM, João Valverde  
wrote:


What license, if any, should we put on our man pages?


I think we can just use the standard Wireshark GPLv2+ header here, with 
copyright to Gerald and contributors.


Is the GPL an appropriate license for documentation, or would the GFDL be more 
appropriate?

https://www.gnu.org/licenses/licenses.html#FDL

For what it's worth, the Bison man page on my machine has no license on it.  I 
don't know whether any other GNU software that comes with a man page puts a 
license on the man page; perhaps they don't care enough about man pages, as 
opposed to Texinfo documents, to bother with a license.  bison.texinfo is 
licensed under the GFDL:

https://opensource.apple.com/source/bison/bison-14/doc/bison.texinfo


The reasonable assumption is that past contributions were made under the 
same licensing terms as the rest of Wireshark. I'm not sure we can just 
slap any license on it without some effort to ask people who made 
significant contributions (IANAL).


See this for a practical concern about the GDFL:

https://www.debian.org/vote/2006/vote_001
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checklicenses.py

[Guy Harris]

On Aug 8, 2016, at 7:04 PM, João Valverde  
wrote:

> See this for a practical concern about the GDFL:
> 
> https://www.debian.org/vote/2006/vote_001

If Debian concluded that "GFDL-licensed works without unmodifiable sections are 
free", then the GFDL would be OK only if we make sure there are no 
"unmodifiable sections".

I'm not sure how much effort it would be to do that.  Given that we've already 
released the User's and Developer's guide under GPLv2-or-later, we might as 
well use GPLv2-or-later for the man pages, saving ourselves that effort (and 
the effort of finding out how much effort it would be...), however much that 
effort might be.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe