obs-streamer-tools-plugin/third_party/livekit

LiveKit client-sdk-cpp redistribution notices

This plugin links and redistributes prebuilt binaries from livekit/client-sdk-cpp — the liblivekit / liblivekit_ffi shared libraries that ship next to the plugin module — so the SDK's licence and notice files ship with it.

LICENSE and NOTICE here are copied verbatim from the pinned release tag v1.10.1 (Apache License 2.0). They are staged into build/package/licenses/ by obs-adapter/CMakeLists.txt on every build, alongside this plugin's own Apache-2.0 LICENSE (this project's own first-party code was relicensed from GPL-2.0 to Apache-2.0 to match).

A correction to the design doc

The design doc's open questions say:

client-sdk-cpp's bundled LICENSE.md (~28 distinct third-party license blocks — Google WebRTC, OpenH264, etc.) must ship inside the plugin package

No such file exists at v1.10.1. Checked, on 2026-09-06:

• The five release archives for this tag (livekit-sdk-<triple>-1.10.1.tar.gz / .zip) contain only include/, lib/, bin/ and share/livekit/build-info.json. No licence file of any kind.
• The repository at tag v1.10.1 has LICENSE (Apache-2.0, 10142 bytes) and NOTICE (553 bytes) at its root. There is no LICENSE.md, no NOTICE.md, and no THIRD_PARTY_LICENSES file.

So what ships here is the Apache-2.0 licence and notice, which is what actually exists upstream. The aggregated third-party notice the design doc expected — covering the WebRTC/OpenH264/etc. code statically linked inside liblivekit_ffi.so — has not been located and is not being shipped. That is a real, open licensing question for whoever signs off on distributing release binaries, not something this packaging step has resolved. Worth raising upstream, or asking counsel whether the Apache-2.0 NOTICE alone suffices for a binary redistribution of that library.

The OpenH264/MPEG-LA royalty question specifically (2026-09-07)

This is narrower and more concrete than the paragraph above, and worth tracking separately because it changes the actual risk, not just the paperwork:

Cisco's own OpenH264 FAQ (https://www.openh264.org/faq.html) draws a sharp line: Cisco covers the MPEG-LA/AVC patent-pool royalties only for their own prebuilt OpenH264 binary module, downloaded at install time by the end user's machine. Anyone who compiles OpenH264 source themselves and redistributes the result inside their own binary takes on "all applicable license fees" themselves — Cisco is explicit that it "will not be liable for any licensing fees incurred by other parties" in that case.

LiveKit's client-sdk-cpp links Google's libwebrtc, built via the webrtc-sdk org's fork (github.com/webrtc-sdk/libwebrtc), whose documented build args include rtc_use_h264=true and ffmpeg_branding="Chrome" — the standard Chromium/WebRTC recipe, in which H.264 encode is provided by a from-source compile of OpenH264 (pulled from Google's own mirror of the Cisco source, not downloaded as Cisco's runtime binary) and statically linked into the resulting libwebrtc. That is the exact shape of the case Cisco's FAQ says voids their royalty coverage.

This has not been independently confirmed against LiveKit's actual pinned build (their v1.10.1 release archives ship only compiled lib//bin/ output, no build manifest showing which GN args actually produced them) — what's established is that this is webrtc-sdk/libwebrtc's documented default recipe, not a verified fact about LiveKit's specific artifact. But taking it at face value: liblivekit_ffi, which this plugin bundles and redistributes, likely contains a statically-linked copy of OpenH264 built in the way that shifts H.264 patent-royalty liability onto whoever redistributes it — i.e., onto a release of this plugin, not onto Cisco or LiveKit.

This is exactly what C1 (see the main README.md ## Status section) is tracking, now with a concrete mechanism attached instead of an open question mark. It does not resolve C1 — if anything it sharpens the case for treating it as unresolved — and it is not a substitute for an actual legal opinion.