Re: Saving packets with libpcap in PCAPNG format

[Guy Harris <guy () alum mit edu>]

On Dec 6, 2016, at 11:05 AM, Martin Dubuc <martind1111 () gmail com> wrote:

> Has there been any discussions with folks from Apple that worked on the PCAPNG API to donate there code to tcpdump 
> project? I am sure many (including Apple) would benefit from single source for this code as far as maintenance is 
> concerned.

This was brought up on tcpdump-worker with somebody from Apple back in 2014:

        http://seclists.org/tcpdump/2014/q3/4

        http://seclists.org/tcpdump/2014/q3/7

        http://seclists.org/tcpdump/2014/q3/40

but nothing happened after that.

Vincent?  If you're still there, has anything happened about releasing Apple's libpcap changes under the BSD license 
rather than under the APSL?

> Martin
>
> On Tue, Dec 6, 2016 at 1:32 PM, Guy Harris <guy () alum mit edu> wrote:
> On Dec 6, 2016, at 10:15 AM, Martin Dubuc <martind1111 () gmail com> wrote:
>
> > I am working on an application that requires to store packets in PCAPNG
> > format. My understanding is that there isn't support for saving packets in
> > PCAPNG format in the current code base. I have noticed that Apple has
> > created an API in its custom version of libpcap (latest version can be
> > viewed at https://opensource.apple.com/source/libpcap/libpcap-67/libpcap/
> > and is based on libpcap-1.7.4), and the extension seems to be open source.
>
> Open source *but* licensed under the Apple Public Source License Version 2.0:
>
>         https://opensource.apple.com/apsl
>
> which says:
>
>         1.1      "Applicable Patent Rights" mean:  (a) in the case where Apple is the grantor of rights, (i) claims 
> of patents that are now or hereafter acquired, owned by or assigned to Apple and (ii) that cover subject matter 
> contained in the Original Code, but only to the extent necessary to use, reproduce and/or distribute the Original 
> Code without infringement; and (b) in the case where You are the grantor of rights, (i) claims of patents that are 
> now or hereafter acquired, owned by or assigned to You and (ii) that cover subject matter in Your Modifications, 
> taken alone or in combination with Original Code.
>
>         ...
>
>         2.      Permitted Uses; Conditions & Restrictions.   Subject to the terms and conditions of this License, 
> Apple hereby grants You, effective on the date You accept this License and download the Original Code, a world-wide, 
> royalty-free, non-exclusive license, to the extent of Apple's Applicable Patent Rights and copyrights covering the 
> Original Code, to do the following:
>
>         ...
>
>         2.4     Third Party Rights.  You expressly acknowledge and agree that although Apple and each Contributor 
> grants the licenses to their respective portions of the Covered Code set forth herein, no assurances are provided by 
> Apple or any Contributor that the Covered Code does not infringe the patent or other intellectual property rights of 
> any other entity. Apple and each Contributor disclaim any liability to You for claims brought by any other entity 
> based on infringement of intellectual property rights or otherwise. As a condition to exercising the rights and 
> licenses granted hereunder, You hereby assume sole responsibility to secure any other intellectual property rights 
> needed, if any. For example, if a third party patent license is required to allow You to distribute the Covered Code, 
> it is Your responsibility to acquire that license before distributing the Covered Code.
>
>         3.      Your Grants.  In consideration of, and as a condition to, the licenses granted to You under this 
> License, You hereby grant to any person or entity receiving or distributing Covered Code under this License a 
> non-exclusive, royalty-free, perpetual, irrevocable license, under Your Applicable Patent Rights and other 
> intellectual property rights (other than patent) owned or controlled by You, to use, reproduce, display, perform, 
> modify, sublicense, distribute and Externally Deploy Your Modifications of the same scope and extent as Apple's 
> licenses under Sections 2.1 and 2.2 above.
>
>         ...
>
>         5.      Limitations on Patent License.   Except as expressly stated in Section 2, no other patent rights, 
> express or implied, are granted by Apple herein.  Modifications and/or Larger Works may require additional patent 
> licenses from Apple which Apple may grant in its sole discretion.
>
>         ...
>
>         12.     Termination.
>
>         12.1    Termination.  This License and the rights granted hereunder will terminate:
>
>         (a)     automatically without notice from Apple if You fail to comply with any term(s) of this License and 
> fail to cure such breach within 30 days of becoming aware of such breach;
>         (b)     immediately in the event of the circumstances described in Section 13.5(b); or
>         (c)     automatically without notice from Apple if You, at any time during the term of this License, commence 
> an action for patent infringement against Apple; provided that Apple did not first commence an action for patent 
> infringement against You in that instance.
>
> I'm not sure whether the patent-related clauses - especially the "Termination" clause - would cause any vendors or 
> distributors who currently include libpcap under its patent-clause-free BSD license not to want to include it if it 
> includes patent clauses of that sort.
>
> > Is there a plan to merge this to the libpcap at some point? Or is there
> > plan to implement something else?
>
> My inclination was to implement *some* APIs for reading files (pcapng or pcap, using the same API, so programs can 
> transparently *read* either file type), with the full capabilities of pcapng supported, and for writing pcapng files, 
> with a separate implementation.
>
> If we can get away with implementing Apple's API independently, under the same BSD license as is used for the rest of 
> libpcap, and that API can be used to read either pcap or pcapng files, and it supports the full capabilities of 
> pcapng and allows support for future pcapng capabilities (as well as vendor extensions), that would probably be the 
> right choice; otherwise, we'll implement a separate API, but try to do so in a way that allows Apple to continue to 
> provide their API.  (They don't document the API in any man page other than the pcapng man page in the source, so 
> they might consider it a private interface and be willing to use a different one, especially if, as I expect we'll 
> do, we provide a version of tcpdump that supports the new API if available.

_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers