incubator-celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <>
Subject Re: [Report] Apache Celix Hackathon
Date Thu, 11 Jul 2013 14:59:46 GMT
Hi Daniel,

2013/7/11 dsh <>

> Hi,
> there might be a slight misconception between Bonjour and Avahi and what
> each of both is. Avahi implements Zeroconf. That is the standard. Bonjour
> is Apples implementation of Zeroconf and Avahi actually provides a Bonjour
> compatibility layer. That means programs linked against Bonjour could as
> well run with Avahi with the appropriate degree of luck.

We are aware of this, perhaps the wording is a bit of.

> Avahi is available on most if not all Linux distros and on BSD. Where
> Bonjour is more or less OSX specific. That means both are complementary in
> a way if you'd like to target Linux, Unix and OSX and thus your code base
> must address this. AFAIK you are using CMake which could provide the
> appropriate macros to allow building Celix against Avahi on Linux/Unix and
> against Bonjour on OSX.

We don't think compiling is a problem at all, indeed CMake can handle this
without a problem. But the actual problem has to do with licenses, the
Avahi implementation uses the LGPL license, see [1]. And following [2] we
can't link with Avahi. Since the Bonjour implementation uses the Apache
License we decided to (by default) link against Bonjour. Bonjour compiles
and works fine under Linux and also provides a Windows implementation (not
yet tested).
But we do understand that Avahi makes more sense under Linux, so we already
talked about some documentation about how to compile Celix/Remote Services
with Avahi instead of Bonjour. Since Avahi has the Bonjour compatibility
layer, we don't think this is a big/difficult problem. And as long as it is
the user who does it, and not the default way of Celix, it shouldn't be a
problem concerning licenses.

If we understood the licensing issues incorrect, I'd l like to see some
explanation as what [2] actual means when LGPL is stated as an excluded
license. See [3] for a previous discussion we had about including/using
LGPL licensed headers.


Met vriendelijke groet,

Alexander Broekhuis

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message