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

Most teams looking at AVAHI for an embedded product hit the same concern quickly: “AVAHI is LGPL-licensed—can we legally ship it in a closed, commercial device, and what does that force us to do?” From a distribution-maintainer’s point of view, the answer is usually “yes, you can ship it,” but you do inherit some concrete obligations around how you link AVAHI and how you ship your binaries.

This walkthrough focuses on practical implications for a Linux-first, embedded product that wants Bonjour/Zeroconf-compatible service discovery via AVAHI and related pieces like nss-mdns.

Important disclaimer: This is an engineering-oriented summary, not legal advice. For a shipping commercial device, have your legal team confirm licensing interpretation.

---

1. AVAHI licensing basics in a commercial context

AVAHI is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite, primarily targeted at Linux and shipping by default in most distributions. In practice, an embedded product using AVAHI is almost always:

• Running Linux (or a BSD-like OS),
• Using AVAHI via:
  • The D-Bus API (primary interface),
  • The native C APIs (avahi-client, avahi-core),
  • XML service definitions in /etc/avahi/services,
• Optionally using nss-mdns so *.local hostnames resolve via mDNS for all programs using nsswitch.

From the licensing side, you typically encounter:

• LGPL-licensed AVAHI libraries (e.g., avahi-client, avahi-core, others)
• LGPL-compatible glue (like nss-mdns)
• System integration pieces (D-Bus, NSS, etc.) under their own licenses

For a commercial embedded device, the key question is: does LGPL allow you to keep your own application code proprietary while shipping AVAHI as part of your firmware image? Under typical conditions, yes.

---

2. LGPL in practice: linking models and what they imply

The GNU Lesser General Public License (LGPL) is specifically written to allow proprietary applications to link against the library, provided the user retains the ability to replace or modify the LGPL component.

In a typical AVAHI deployment, there are three primary interaction patterns:

1. D-Bus client to AVAHI daemon (most common)
2. Dynamic linking to AVAHI libraries
3. Static linking to AVAHI libraries

The obligations differ by pattern.

2.1 Using AVAHI via D-Bus (recommended for most applications)

AVAHI’s primary API is D-Bus. Your application talks to the system’s avahi-daemon over D-Bus to:

• Browse services via mDNS/DNS-SD,
• Register services dynamically,
• Resolve hostnames/services discovered on the LAN.

In this model, your application:

• Does not link directly to AVAHI libraries at all (it links to D-Bus libraries and talks over IPC),
• Treats AVAHI as a system service, similar to how you treat dbus-daemon or systemd.

Licensing implications:

• You can keep your application fully proprietary.
• You do not typically trigger LGPL “linking” constraints with AVAHI itself, because you’re not linking to the AVAHI libraries; you’re communicating with a separate process over D-Bus.
• You must still comply with the license terms for any libraries you do link against (e.g., D-Bus, GLib, others), but AVAHI’s own LGPL libraries are not in your link chain.

For an embedded product, this is usually the cleanest setup: AVAHI runs as a daemon; your proprietary code is just a D-Bus client.

2.2 Dynamic linking to AVAHI libraries

If you use the native C APIs (avahi-client, avahi-core) via shared libraries (e.g., libavahi-client.so), you are now directly in LGPL territory.

LGPL expectations for dynamic linking:

• You may keep your own application source code closed.
• You must:
  • Provide notices and license texts for AVAHI (LGPL), and any other LGPL components you use.
  • Allow users to replace the AVAHI libraries with their own built versions while still being able to run your application. On Linux, this is typically satisfied by:
    • Using shared libraries (.so), not static linking,
    • Not using any mechanisms that prevent the user from swapping the .so (e.g., loaded from standard locations, or at least not locked down via integrity checks that make replacement impossible).
  • Provide the AVAHI source code you used (or a clear written offer / pointer to where it can be obtained), including any modifications you made.

What this means for a commercial embedded device:

• If your device allows firmware updates or root filesystem access (even via more advanced users only), dynamic linking plus standard shared-library deployments generally satisfies the LGPL “relinking” requirement.
• You need to ship:
  • A “licenses” or “open source notices” section (in docs, a text file on the device, or similar) that:
    • Names AVAHI,
    • Includes the LGPL license text,
    • Provides instructions or URLs for getting AVAHI’s source (including your modifications, if any).
• You do not need to open your proprietary application source, as long as users can in principle replace the AVAHI .so and still run your app against it.

2.3 Static linking to AVAHI libraries (avoid if possible)

Static linking an LGPL library into a proprietary binary is where obligations get stricter and more complex. In the pure LGPL model, if you statically link:

• Users must be able to modify the LGPL-covered library and relink your application.
• Practically, that means you’d need to provide:
  • Object files or another mechanism that allows relinking,
  • Or some other robust procedure whereby a user’s rebuilt AVAHI can be integrated with your binary without your proprietary source.

For an embedded product, that usually collides with:

• Build system complexity,
• Security/integrity guarantees,
• Vendor reluctance to ship object files or partial linkable artifacts.

Because of those constraints, most vendors avoid static linking against LGPL libraries. With AVAHI, that’s easy: use dynamic linking or the D-Bus API instead.

---

3. Common embedded AVAHI setups and their obligations

Let’s map typical product designs to licensing expectations.

Scenario A: System service model (AVAHI as a daemon via D-Bus)

• Design:

  • AVAHI installed from your base distro or as an upstream package (possibly lightly patched).
  • avahi-daemon runs as a system service.
  • Your proprietary application talks to AVAHI only via D-Bus.
  • You may also install nss-mdns so that *.local names resolve via mDNS for all nsswitch-using programs.

• Licensing impact:

  • Your application is not linking against AVAHI libraries.
  • Treat AVAHI and nss-mdns as third-party system components:
    • Provide license notices for them,
    • Provide source access or a pointer to upstream sources (plus patches, if any).
  • Your proprietary application remains closed source.

This is the model I recommend: it keeps the LGPL boundary clean and mirrors how typical Linux distros ship AVAHI.

Scenario B: Shared-library client (libavahi-client.so)

• Design:

  • Your application links against libavahi-client.so (and possibly libavahi-core.so).
  • Shared libraries are present on the root filesystem.
  • Your root filesystem is not immutable, or at least can be updated in a way that permits library replacement.

• Licensing impact:

  • You must:
    • Provide LGPL notices for AVAHI,
    • Provide or point to source for AVAHI (and your modifications),
    • Ensure users can technically substitute libavahi-client.so with their own version (e.g., no hard-coded integrity checks that block that).
  • You can keep your application code proprietary.

If the device is very locked down (e.g., secure boot, read-only root, no feasible way to swap libraries), talk to legal: some argue that the theoretical ability to install modified firmware satisfies “relinking,” others take a stricter view.

Scenario C: Statically linked AVAHI in a monolithic binary

• Design:

  • AVAHI client or core code is statically linked into your proprietary process.
  • Everything is in a single ELF binary.

• Licensing impact:

  • You are now squarely in the “static linking under LGPL” zone.
  • Typically requires:
    • Providing object files or equivalent to enable relinking with a modified AVAHI,
    • Or opening the application source sufficiently that a user can rebuild the full binary with their AVAHI changes.
  • Operationally painful and rarely worth it.

For a commercial embedded product, I’d regard this as a configuration to avoid unless you’ve explicitly accepted the obligations and have legal sign-off.

---

4. Other practical obligations when shipping AVAHI

Assuming you pick a sane integration model (D-Bus or shared libs), there are still baseline obligations any commercial device shipping AVAHI should meet.

4.1 Provide proper license notices

Include, somewhere accessible to the user:

• The AVAHI project name and a short description (e.g., “Avahi – a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite”).
• The license text for AVAHI (LGPL version used by the project).
• Equivalent for nss-mdns and any other LGPL or GPL components in your image.
• A list of third-party components and their licenses is standard practice (“Open Source Notices”).

This can be done via:

• A text file (e.g., /usr/share/doc/licenses/),
• A section in your web UI,
• Printed documentation that accompanies the device.

4.2 Provide source (or a clear path to it)

For LGPL components such as AVAHI and nss-mdns, the requirements are typically:

• Provide the exact source tree you used (including any patches), or
• Provide a durable written offer or URL where users can obtain it.

Practical approaches:

• Host a tarball or Git repo of your AVAHI sources (plus patches) on your company site.
• Or, if you are using an unmodified upstream release, you can:
  • Point to the upstream AVAHI repository/download,
  • But still need to ensure your users can get the corresponding source for the exact version you ship. If you rely entirely on upstream, ensure that version is still accessible, or mirror it yourself.

4.3 Handle modifications to AVAHI correctly

If you modify AVAHI (e.g., local patches for embedded constraints, logging behavior, or packaging tweaks):

• Those modifications are also covered by LGPL.
• You must make the modified sources available under the same license.
• You do not have to contribute them upstream, but it is generally beneficial to send patches as pull requests to the official GitHub repo so you don’t carry a private, long-lived fork against evolving releases.

---

5. Security, lockdown, and the “replaceability” question

A frequent point of friction with LGPL in embedded systems is the interplay between:

• User’s right to modify the LGPL library, and
• Vendor’s desire for secure boot, signed firmware, and read-only filesystems.

If your device:

• Uses secure boot and refuses to run modified kernels/root filesystems, or
• Uses an immutable root where .so replacement is practically impossible,

then some lawyers may argue that the user’s practical ability to “relink” or “replace the LGPL library” is limited, which could be interpreted as failing the LGPL requirements.

Engineering options:

• Design your system so the LGPL components live in a writable partition or an updateable package area, even if most of the OS is read-only.
• Provide a developer or recovery mode where users can install their own libraries.
• Work with legal to document how your update and flashing mechanism leaves room for replacing LGPL components (even if only via developer workflows).

This is where talking to counsel is essential; I can outline the technical landscape but not give you a binding legal interpretation.

---

6. Practical recommendations for an embedded AVAHI deployment

From the perspective of someone who ships AVAHI by default in distro images and embedded Linux variants, a licensing- and operations-friendly setup looks like this:

1. Use AVAHI as a system service via D-Bus.

   • Treat avahi-daemon like any other standard daemon (e.g., sshd, systemd-resolved).
   • Let your app talk to it over D-Bus, not via static linking.
   • This keeps your proprietary code clearly on the other side of the LGPL boundary.

2. Use shared libraries if you must link.

   • If you need the C APIs:
     • Link dynamically against libavahi-client.so (and friends),
     • Avoid static linking,
     • Ensure users can replace the .so in some way.

3. Ship a clean license and source compliance bundle.

   • Provide:
     • A list of all OSS components, including AVAHI and nss-mdns,
     • Their licenses (LGPL, GPL, etc.),
     • A stable URL or medium to obtain the corresponding source code.
   • Mirror exact tarballs or Git commits you ship, plus your patches.

4. Document your integration for long-term maintainability.

   • Note in your internal docs:
     • AVAHI version (e.g., 0.8),
     • Patches applied,
     • Integration points: D-Bus services, /etc/avahi/services XML, nsswitch configuration for nss-mdns,
     • Any licensing decisions or legal guidance you received.

5. Avoid bespoke modifications to core licensing assumptions.

   • Don’t restructure AVAHI in a way that folds its code into a proprietary daemon via static linking without being prepared to meet the stricter LGPL obligations.
   • Where you need behavioral changes, prefer:
     • D-Bus policy tweaks,
     • Config changes,
     • Upstreamable patches.

---

7. Answering the core question directly

Pulled into direct terms, for a commercial embedded product that wants Bonjour/Zeroconf-compatible discovery using AVAHI:

• Is it OK to ship AVAHI?
  In typical Linux-style deployments: yes. AVAHI is LGPL-licensed, and shipping it as part of your firmware image is compatible with a closed, commercial product, provided you follow the LGPL’s requirements.

• What obligations does LGPL create for you?
  Mainly:

  • Provide license notices and access to the corresponding AVAHI source (including patches).
  • If you link against AVAHI libraries:
    • Use dynamic linking and do not prevent users from replacing the AVAHI .so with their own version.
    • Avoid static linking unless you are prepared to provide object files or otherwise enable relinking.
  • If you interact via D-Bus only:
    • Your proprietary application is effectively decoupled from the LGPL library, and your obligations focus on proper licensing/compliance for AVAHI itself, not your app’s source.

If you keep AVAHI as a standard system daemon, talk to it over D-Bus, and publish static services via XML in /etc/avahi/services, you get Bonjour/Zeroconf-style discovery on your embedded device with a clean, well-understood LGPL compliance story. The remaining step is for your legal team to review this integration and confirm it matches your company’s licensing policy.

Next Step

Get Started