AES67: The Foundation of Interoperable Audio-Over-IP

The Audio Engineering Society’s AES67 standard provides a common ground for high-performance audio streaming over IP networks. It specifies sample rates, clocking, packet timing, and transport mechanisms that allow devices from different manufacturers to exchange audio without proprietary bridges. While the standard document itself is available for purchase and its core technology is royalty-free to implement, the legal landscape surrounding AES67 deployments is far from simple. The open nature of the standard does not exempt users from the licensing terms, patent claims, and regulatory obligations that attach to the products and software that implement it.

Understanding this distinction is the first step toward legal compliance. Treating AES67 as a “free” technology can lead to overlooked contractual obligations, unintended patent infringement, or regulatory exposure. This article expands on the key legal and licensing considerations that organizations must evaluate before rolling out AES67-based audio systems in production environments.

Open Standard vs. Vendor Implementation Licenses

AES67 itself carries no royalty or licensing fee for implementation. However, nearly every practical deployment relies on hardware or software from specific vendors. Those vendors incorporate their own intellectual property—patented algorithms for clock recovery, proprietary redundancy mechanisms, or optimized network discovery protocols—into their AES67 implementations. As a result, the legal agreement that governs the use of a Dante, Ravenna, or Livewire+ product is the binding document, not the abstract standard.

Organizations must review these implementation licenses carefully. Common pitfalls include:

  • Per-unit channel counts: Some licenses restrict the number of simultaneous audio streams without an additional fee.
  • Software maintenance terms: Support for AES67 compliance may expire if maintenance renewals lapse.
  • Use-case restrictions: Licenses may prohibit use in safety-critical or life-safety applications unless explicitly approved.

Vendor Licensing in Practice

Each major AoIP ecosystem approaches licensing differently:

  • Audinate (Dante): Every Dante device, whether chip-based or software-based, requires a license. Dante Domain Manager can enable AES67 mode, but that does not change the underlying proprietary licensing. Users must account for license costs per node, often paid to the device manufacturer.
  • Merging Technologies (Ravenna/AES67): Ravenna’s core IP is available under an open-source license, but commercial use may require a separate agreement for support, advanced features, or distribution. Organizations integrating Ravenna into their own products must verify the specific license terms—typically the Merging Technologies Community License.
  • Wheatstone (Livewire+): Livewire+ includes AES67 support as part of the hardware. The license is embedded in the product cost, but any software that processes Livewire+ streams (e.g., console mix engines) carries an end-user license agreement that restricts reverse engineering and redistribution.
  • QSC (Q-SYS): Q-SYS platforms support AES67 alongside proprietary networking. The Q-SYS software license allows AES67 usage but may require additional extensions for third-party device integration.
  • Open-source stacks: Projects like the ALSA or PipeWire communities provide AES67 implementations under GPL or LGPL. While free of per-unit fees, these licenses impose obligations to distribute source code and maintain copyright notices. Using open-source AES67 code in a commercial product requires strict compliance with the chosen license.

Before purchasing, request the full license agreement from the vendor. Look for clauses about channel limits, stream count caps, and restrictions on competing interoperability development.

Intellectual Property and Patent Landscapes

AES67 was carefully designed to avoid known patent encumbrances, but the standard cannot guarantee that every implementation is free of third-party patent claims. For example, the Precision Time Protocol (IEEE 1588) used for clock synchronization may have its own patent claims, and audio codecs like MPEG-2 or AAC employed alongside AES67 often require separate royalties.

Patent Pools and Codec Licensing

When AES67 carries compressed audio (e.g., for contribution feeds), the relevant codec patent pool may demand per-stream or per-decoder fees. Organizations should:

  • Identify any compression layers applied before AES67 encapsulation.
  • Check whether the vendor has already paid those royalties (many include them in the product cost).
  • If using open-source codecs like Opus, confirm the implementation does not infringe on patents outside the codec’s own grant.

For patent risk mitigation, request a patent indemnification clause in procurement contracts. Some vendors limit indemnification to “direct” infringement caused by their own product; clarify whether your combination of components could void that protection.

Patent Grants in Open Source Licenses

Open-source AES67 implementations often include express patent grants. For instance, code licensed under Apache 2.0 grants rights to patents necessary for the implementation. However, the grant typically terminates if you initiate a patent lawsuit against a contributor. Review the license to understand your patent exposure when integrating open-source stacks.

Regulatory Compliance Across Industries

AES67 systems deployed in regulated environments face additional legal requirements that vary by sector and jurisdiction. Compliance with the audio standard alone does not satisfy safety, privacy, or broadcast rules.

Broadcasting and FCC Rules

In the United States, the FCC governs electromagnetic compatibility, emergency alert integration, and closed captioning. AES67-enabled broadcast equipment must bear FCC markings; using non-compliant devices can result in fines or network shutdown. Additionally, broadcasters migrating to IP-based production often adopt SMPTE ST 2110-30 (AES67 audio within the ST 2110 suite). While AES67 compliance helps, the system must still meet the FCC’s technical specifications for the intended frequency bands.

Healthcare and HIPAA Compliance

Audio streams in nurse call, paging, or intercom systems may contain protected health information. AES67 does not natively provide encryption; many vendors add it via IPsec or TLS. The Health Insurance Portability and Accountability Act (HIPAA) requires covered entities to sign Business Associate Agreements (BAAs) with any vendor handling PHI. Ensure the BAA covers the AES67 implementation. Also verify that the license agreement does not disclaim liability for security breaches—some standard EULAs exclude security guarantees.

Transportation and Life Safety Systems

Public address and voice alarm systems in airports, rail stations, and emergency control centers often use AES67 for scalability. However, local building codes may mandate that such systems maintain operation during power loss or network congestion. Many vendor licenses explicitly state that the software is not certified for life-safety use. Using AES67 in these roles without contractual assurances of reliability could expose the operator to liability in an incident. Consider requiring the vendor to document compliance with relevant safety standards (e.g., EN 54 in Europe).

Contractual and Procurement Best Practices

Treat AES67 hardware and software procurement like any other technology contract. The license agreement defines your rights, obligations, and limitations.

EULA and SDK Licensing Traps

Many AES67 implementations ship with software development kits (SDKs) or firmware that impose restrictions:

  • Number of authorized client applications.
  • Prohibition on competitive benchmarking or interoperability testing.
  • Automatic license termination upon breach without notice.

If you plan to build custom integrations, negotiate a separate developer agreement that explicitly allows access to APIs necessary for AES67 stream creation or consumption. Some vendors charge additional fees for development licenses.

Warranties and Indemnification

Ensure the warranty covers AES67 functionality. Some products advertise compliance but ship with bugs that break interoperability. A warranty clause that obligates the vendor to fix non-compliance within a reasonable period is essential. Additionally, negotiate patent indemnification—at minimum covering “essential claims” needed to implement AES67. Understand that indemnity often excludes claims arising from combination with non-vendor components.

Operational Compliance and Documentation

Even after deployment, legal exposure continues. Licensing agreements often require that only authorized personnel perform firmware updates, network reconfigurations, or stream configuration changes. Training staff on these restrictions prevents accidental violations.

Maintain a central repository for all license agreements, certificates of compliance (e.g., FCC, UL), and audit logs. This becomes critical during compliance audits such as SOC 2, HIPAA, or ISO 27001. Document which specific AES67 implementations are in use—by vendor, version, and license ID—and reference them in your security policies as approved transport standards.

Legal obligations differ significantly across borders. Consider:

  • Export controls: AES67 equipment with strong encryption may fall under U.S. Export Administration Regulations (EAR) or similar regimes in other countries. Verify whether your implementation qualifies for an encryption exemption.
  • GDPR: If the system captures or stores voice data that can identify individuals (e.g., recorded phone calls or intercom logs), the EU General Data Protection Regulation applies. This affects how audio streams are processed, stored, and deleted.
  • Local procurement laws: Some governments prohibit equipment containing certain foreign-manufactured chips or software. For example, China’s cybersecurity law may impose restrictions on closed-source AES67 implementations, while the U.S. federal market may require adherence to the Trade Agreements Act.

Engage local legal counsel to review licensing agreements for regional validity, especially when deploying across multiple countries.

A structured audit before rollout helps identify issues early. Include the following steps:

  1. License inventory: List every software library, driver, firmware, and hardware module that touches AES67 streams. For each, note the license type (proprietary, open-source, evaluation) and any usage restrictions.
  2. Open-source compliance: If using open-source AES67 code, confirm you have met attribution, source code provision, or copy-left requirements. Tools like FOSSA can help.
  3. Patent clearance: Request patent clearance letters from vendors covering their AES67 implementation. For open-source components, review the project’s patent grant policy.
  4. SLA review: Verify that the service level agreement covers AES67 interoperability and provides access to updates for the license duration.
  5. Third-party dependencies: Identify dependencies like PTP stacks, codec libraries, or cybersecurity modules. Ensure their licenses are compatible with your intended use.

Conclusion

Deploying AES67-based audio systems delivers the promise of seamless interoperability, but only when legal and licensing details are managed proactively. By thoroughly evaluating vendor licenses, securing patent indemnity, meeting regulatory requirements across industries and jurisdictions, and auditing compliance before go-live, organizations can avoid costly disputes and operational disruptions. Work closely with legal professionals experienced in technology licensing, document every agreement, and embed license awareness into your engineering culture. With careful preparation, AES67 can support robust, legally compliant audio networks that scale for years.

For further reference, consult the AES67-2018 standard document and the Audinate AES67 licensing FAQ. For a broader overview of audio-over-IP legal risks, see this white paper on AoIP intellectual property. Additional context on patent issues in open-source AoIP is available from the Ravenna Licensing Overview.