shadowdaoandClaude Sonnet 5
14fa00af3f
Cisco's own OpenH264 FAQ (openh264.org/faq.html) is explicit: they cover MPEG-LA/AVC patent-pool royalties only for their own prebuilt binary, downloaded at install time. Anyone who compiles OpenH264 from source and redistributes it inside their own binary takes on "all applicable license fees" themselves -- Cisco "will not be liable for any licensing fees incurred by other parties" in that case. LiveKit's client-sdk-cpp links Google libwebrtc via the webrtc-sdk org's fork, whose documented build args (rtc_use_h264=true, ffmpeg_branding="Chrome") are the standard Chromium/WebRTC recipe -- which links a from-source, statically-compiled copy of OpenH264 (from Google's mirror, not Cisco's runtime binary) into libwebrtc. That is exactly the shape of case Cisco's FAQ says voids their coverage. Not independently confirmed against LiveKit's actual pinned v1.10.1 build (their release archives ship only compiled output, no build manifest) -- this is webrtc-sdk/libwebrtc's documented default, not a verified fact about this specific artifact. This sharpens C1 into a concrete mechanism instead of a general open question. It does not resolve C1 -- if anything it strengthens the case for treating it as unresolved -- and none of this is a substitute for an actual legal opinion. Recorded in third_party/livekit/README.md (the full writeup), README.md's Status section, and the release-notes template in publish-release.sh so it reaches whoever opens a draft release next, not just this one. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE
76 lines
4.1 KiB
Markdown
76 lines
4.1 KiB
Markdown
# LiveKit client-sdk-cpp redistribution notices
|
|
|
|
This plugin links and **redistributes** prebuilt binaries from
|
|
[`livekit/client-sdk-cpp`](https://github.com/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.
|