docs: OpenH264/MPEG-LA royalty finding sharpens C1 -- not resolved

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

.gitea/scripts/publish-release.sh

@@ -35,10 +35,16 @@ cat > "${NOTES_FILE}" <<EOF
 > **This build has not been cleared for redistribution.** The plugin
 > statically/dynamically pulls in Google WebRTC and OpenH264 code through the
 > LiveKit SDK, and whether that can be redistributed as a public download --
-> the "C1" attribution/patent question -- has not been resolved. See the
+> the "C1" attribution/patent question -- has not been resolved. Cisco's own
-> \`## Status\` section of \`README.md\` and \`third_party/livekit/README.md\`
+> OpenH264 FAQ says they cover MPEG-LA royalties only for their own
-> for the specifics. By publishing this release, you are personally taking on
+> runtime-downloaded binary, not for OpenH264 compiled from source into
-> that open question -- if C1 hasn't been signed off on, don't publish it.
+> someone else's redistributed binary -- which is the normal way LiveKit's
+> WebRTC build links it (unconfirmed against LiveKit's actual pinned build;
+> see \`third_party/livekit/README.md\`'s 2026-09-07 section for exactly
+> what is and isn't verified). See the \`## Status\` section of
+> \`README.md\` for the rest. By publishing this release, you are personally
+> taking on that open question -- if C1 hasn't been signed off on, don't
+> publish it.
 >
 > (The separate GPLv2/Apache-2.0 license-compatibility question, "C2", is
 > resolved: this project's own first-party code is Apache-2.0, matching the

README.md

@@ -14,7 +14,13 @@ through the LiveKit SDK — a real patent/royalty question (OpenH264/WebRTC)
 that only the project owner can decide. Nothing in this repo should be built
 into a package and handed out, posted, or attached to a public release until
 that sign-off happens. See `third_party/livekit/README.md` for the specifics
-of what is and is not currently known/shipped on the licensing side. (CI in
+of what is and is not currently known/shipped on the licensing side —
+including a 2026-09-07 finding, sourced from Cisco's own OpenH264 FAQ, that
+the way LiveKit's WebRTC build normally links OpenH264 (statically, from
+source, not Cisco's runtime-downloaded binary) is specifically the case Cisco
+says voids their MPEG-LA royalty coverage and shifts it to the redistributor.
+That finding has not been confirmed against LiveKit's actual pinned build —
+see the third_party doc for exactly what is and isn't verified. (CI in
 `.gitea/workflows/build.yml` only builds, tests, and uploads CI-internal
 build artifacts — it does not create a Gitea Release or otherwise publish
 anything publicly.

third_party/livekit/README.md

@@ -35,3 +35,41 @@ 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.