AVAHI licensing: is it OK to ship AVAHI in a commercial embedded product, and what obligations does LGPL create?

Using Avahi in a commercial embedded product is usually acceptable, but you do need to understand how the LGPL applies, how you link it, and what you must provide to your users so you stay compliant.

This overview is written from the perspective of shipping Avahi as a system component in Linux-based products (routers, appliances, industrial controllers, etc.), where you want Bonjour/Zeroconf-compatible service discovery via mDNS/DNS-SD without exposing more of your stack than required.

This is an informational, engineering-focused summary based on how LGPL’d components are commonly shipped in Linux systems. It is not legal advice. If your business depends on a specific interpretation, have your legal counsel review your exact use case.

1. How Avahi is typically licensed

Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. It’s primarily targeted at Linux systems and ships by default in most distributions. It provides:

System daemons (e.g., avahi-daemon)
Client libraries (libavahi-client, libavahi-core, etc.)
Tools and utilities
Related components like nss-mdns (for *.local hostname lookup via nsswitch)

In mainstream Linux distributions, the Avahi codebase is licensed under the GNU Lesser General Public License (LGPL), version 2.1 or later, sometimes with individual files under GPL-compatible licenses. In practice, for embedded product decisions, you treat Avahi as an LGPL’d component.

The important practical consequence: LGPL is explicitly designed to allow use of the library in proprietary / closed-source applications, provided you respect certain conditions around linking and user freedom to modify/replace the LGPL’d part.

2. Core question: is it OK to ship Avahi in a commercial embedded product?

Yes, it is generally OK to ship Avahi in a commercial, closed-source embedded product, assuming:

Avahi remains a separate library/binary (you’re not copying its code into your own and relicensing it).
You comply with LGPL obligations, mainly:
- Providing the Avahi (and nss-mdns, if included) source or a clear written offer for it.
- Allowing users to replace or modify the LGPL components (e.g., by relinking or swapping packages) on the device.
- Preserving license notices and attribution.

For most Linux-based embedded products that ship Avahi more or less as the distribution does (as a system daemon and shared libraries), compliance is straightforward and very similar to how you treat other LGPL libraries like glibc, libstdc++, or openssl.

3. Why LGPL is more “embedded-friendly” than GPL

To reason about obligations, it helps to contrast LGPL with GPL:

GPL (full copyleft):
- If you link GPL code into your program, the combined work generally must be distributed under the GPL.
- This is usually incompatible with proprietary applications.
LGPL (library-specific copyleft):
- Lets you link proprietary applications against the LGPL library without forcing your code to become GPL/LGPL.
- The copyleft is focused on the library itself and the user’s ability to modify and relink that library.

Avahi being under the LGPL means:

You can keep your application code closed.
You must treat Avahi (and any other LGPL components) so that users can:
- Obtain the corresponding source for Avahi.
- Replace or relink Avahi with a modified version if they wish.

In an embedded environment, that usually translates to documented source availability plus a reasonably open stack (e.g., standard package manager, or a documented way to rebuild and reflash images).

4. Dynamic vs static linking: why it matters for Avahi

The LGPL’s practical impact depends heavily on how you link to Avahi’s libraries.

4.1 Dynamic linking (preferred, and what most distros do)

Dynamic linking (e.g., libavahi-client.so loaded at runtime) is the usual way to consume Avahi:

Your proprietary binaries link against Avahi’s shared libraries at runtime.
The LGPL explicitly anticipates this usage and allows it provided:
- Users can replace the Avahi library with a modified version.
- You don’t block that substitution via signature checks or other technical measures.

For embedded products, that means:

If your system uses a standard dynamic linker and shared libraries (like a normal Linux distribution), and
You do not prevent users from updating those libraries (e.g., can install an updated libavahi-client.so or reflash an image),

then dynamic linking is typically the cleanest, lowest-friction way to stay compliant.

4.2 Static linking

Static linking (libavahi-*.a compiled directly into your binary) is more constrained:

LGPL allows static linking but tightens obligations:
- Users should be able to modify the LGPL’ed library and relink it with your application.
- In practice, that usually means:
  - Provide object files or linkable form of your proprietary application, or
  - Provide a build environment that lets end users re-link against a modified Avahi.

Embedded vendors often avoid static linking to LGPL libraries precisely to avoid this extra complexity. If you are planning static linking of libavahi-client into a closed application, you should have your legal team review the exact LGPL version and ensure your distribution approach covers the “relinking” requirement.

4.3 IPC-only use (D-Bus without linking)

With Avahi, there’s a third mode that actually maps well to the architecture:

Avahi’s primary API is D-Bus, and for most of Avahi, D-Bus is required.
You can design your application so it only talks to Avahi over D-Bus and does not link against libavahi-client at all.

In that case, your application is communicating with a separate process (the Avahi daemon) over an IPC channel (D-Bus). This is generally treated as two distinct programs talking over a protocol, not a single combined work:

You ship Avahi as a system daemon (LGPL obligations apply to Avahi itself).
Your application uses D-Bus introspection / method calls; it does not link against Avahi libraries.
This often simplifies the licensing story further, because there is no linking relationship at all.

Most real-world deployments still install the standard Avahi packages, which contain both the daemon and libraries. But from a licensing perspective, a pure D-Bus consumer application is structurally “safer” than static linking.

5. Key LGPL obligations when shipping Avahi

Assuming you are shipping Avahi in a commercial embedded product, here’s what the LGPL typically requires in practice. The list is written from the point of view of a Linux-first device that includes Avahi as a system component.

5.1 Provide access to the Avahi source (or a written offer)

You need to ensure users can obtain the source code for the exact Avahi version you ship, including any local modifications you have made.

Common approaches:

Ship a “sources” tarball on your website or support portal, containing:
- The full source for Avahi (and nss-mdns if you ship it).
- Build scripts/patches you use.
Or include a written offer in your product documentation that explains:
- How users can request the source (postal address/email).
- The time period for which the offer is valid (often at least three years).

Many embedded vendors mirror exactly the source trees from the Linux distribution they’re based on plus their patches. This satisfies not only LGPL but also the GPL obligations for other components.

5.2 Preserve license text and notices

You must:

Keep Avahi’s license text (LGPL) and copyright notices intact.
Provide a copy of the relevant license(s) with the device:
- Often in /usr/share/doc, /licenses, or in a “Legal Notices” document or web UI.
Avoid removing or obscuring authorship and license headers from the source.

This is usually straightforward: carry the distribution’s LICENSE, COPYING, and related files, and ensure they’re present in whatever “open source notices” you ship.

5.3 Allow users to replace or modify Avahi

This is the less trivial part and where embedded design decisions can either cooperate with LGPL or fight it.

The LGPL’s core intent is that users must be able to modify the LGPL library and use that modified version with your software. In the Avahi context, that usually means:

If you dynamically link to libavahi-client:
- Do not implement mechanisms that prevent users from replacing libavahi-client.so or avahi-daemon with a modified version.
- Don’t use cryptographic verification of system libraries that would block such replacement.
If your system uses a package manager (opkg, rpm, dpkg):
- Don’t artificially block installation of newer/custom builds of avahi packages.
If you deliver a monolithic firmware image:
- Provide a way (or at least do not block a way) to build a modified image with updated Avahi.
- Some vendors publish a full “SDK + sources” so users can rebuild the firmware with modifications to LGPL components.

If the hardware is locked down such that users cannot run modified binaries at all, consult legal counsel; some interpretations see this as conflicting with the spirit of LGPL even if technically you shipped the source.

5.4 Clearly separate proprietary code from Avahi

You don’t have to open your proprietary application code as long as:

You keep your code in separate binaries/libraries.
You link to Avahi dynamically (or treat it as an IPC peer).
You don’t copy Avahi source into your own code and then distribute that merged work under a more restrictive license.

A clean layout looks like:

/usr/sbin/avahi-daemon (LGPL, from upstream or distro)
/usr/lib/libavahi-client.so.* (LGPL)
/usr/bin/your-app (proprietary, closed source)
/etc/avahi/services/*.service (XML definitions for services your app wants to publish)

Your app uses the D-Bus API or a dynamic library, but is clearly not part of the Avahi codebase.

6. What about nss-mdns and *.local hostname lookup?

The nss-mdns project allows hostname lookup of *.local hostnames via mDNS in all system programs using nsswitch. It’s maintained alongside Avahi on GitHub and typically used to make hostname.local resolve in tools like ssh, ping, and so on.

Licensing-wise, you should treat nss-mdns the same way you treat Avahi:

It is also under an LGPL-style license (check your exact version and distro patches).
The same obligations apply:
- Provide or offer the source.
- Preserve license texts.
- Allow users to modify and replace the library.

In embedded devices, adding nss-mdns is often what makes the product “feel” Bonjour-compatible for standard CLI tools and scripts. From a licensing standpoint, it is just another LGPL library in your stack.

7. Practical shipping patterns that work well

Here are patterns I’ve repeatedly seen in commercial products that want Bonjour/Zeroconf-style service discovery via Avahi, while keeping their application proprietary.

7.1 Use stock distro Avahi and nss-mdns packages

Base your firmware on a mainstream distribution (or a Yocto / Buildroot config) where:
- avahi-daemon and libraries are stock packages.
- nss-mdns is available.
Don’t significantly modify the Avahi sources.
Publish:
- The distro’s Avahi and nss-mdns source plus your configuration/patches.
Document that the device runs Linux and includes Avahi under the LGPL, with a link to your source mirror.

Licensing impact: Minimal extra work beyond what you already do for GPL components like the kernel and BusyBox.

7.2 Integrate using D-Bus or XML service definitions, not static linking

Use Avahi’s documented interfaces:

For dynamic service publication:
- Use the D-Bus API from your application.
For static/always-on services:
- Drop XML service definition files into /etc/avahi/services (e.g., _http._tcp or _ssh._tcp).
For hostname resolution and peer discovery:
- Enable nss-mdns via nsswitch.conf so *.local works across all system programs.

Avoid static linking against libavahi-client where possible. Dynamic linking plus D-Bus usage keeps your licensing obligations focused and predictable.

7.3 Provide a consistent “open source notices” package

Include:

A “Third-Party Software” document listing Avahi and nss-mdns, their versions, authors, and licenses.
A URL (or QR code on packaging) pointing to your source code downloads.
In firmware, a /licenses directory with:
- COPYING.LGPL or equivalent.
- Any additional license texts from Avahi’s source tree.

This satisfies both your compliance obligations and the expectations of downstream integrators who may extend or audit your product.

8. Red flags to avoid with Avahi + LGPL in embedded products

These patterns are risky from an LGPL perspective and warrant review:

Static linking to Avahi without relinking support:
- Shipping a single monolithic binary statically linked against libavahi-* and not providing object files or a rebuild path.
Locked-down hardware where users cannot run modified images at all:
- “Tivoization”-style designs are particularly sensitive under some interpretations of copyleft.
Stripping or hiding license notices:
- Removing authorship and license text from documentation and source.
Treating Avahi code as your own proprietary code:
- Copy-pasting significant portions of Avahi into your proprietary application and distributing it under a closed license.

If your product design is heading in any of these directions, adjust early or involve legal.

9. Summary: mapping LGPL obligations to a real deployment

To directly answer the question “is it OK to ship Avahi in a commercial embedded product, and what obligations does LGPL create?”:

Yes, it is generally OK to ship Avahi in a commercial, closed-source embedded product.
The LGPL allows proprietary applications to use the library, especially when dynamically linked or communicating over D-Bus.
Your main obligations are to:
1. Provide Avahi’s source code (and nss-mdns if used) or a valid, documented written offer for it.
2. Preserve licenses and attributions in documentation and source.
3. Allow users to modify and replace the Avahi components you ship (usually by not blocking updates to shared libraries or rebuilt firmware).
4. Avoid static linking unless you’re prepared to meet the more involved “relinking” requirements.

If you structure Avahi as a standard system component (daemon + shared libs) in a Linux-based product, consume its D-Bus API or XML service definitions, and follow the same open-source compliance practices you already apply for the kernel and other LGPL libraries, you can safely deliver Bonjour/Zeroconf-style discovery in a commercial device without opening your own application code.

Next Step

Get Started