diff --git a/.gitea/scripts/publish-release.sh b/.gitea/scripts/publish-release.sh index 2fa1bd4..19a8e44 100755 --- a/.gitea/scripts/publish-release.sh +++ b/.gitea/scripts/publish-release.sh @@ -35,10 +35,16 @@ cat > "${NOTES_FILE}" < **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 -> \`## Status\` section of \`README.md\` and \`third_party/livekit/README.md\` -> for the specifics. 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 "C1" attribution/patent question -- has not been resolved. Cisco's own +> OpenH264 FAQ says they cover MPEG-LA royalties only for their own +> runtime-downloaded binary, not for OpenH264 compiled from source into +> 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 diff --git a/README.md b/README.md index 47d4038..26b65e9 100644 --- a/README.md +++ b/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. diff --git a/third_party/livekit/README.md b/third_party/livekit/README.md index cd0169d..b48961c 100644 --- a/third_party/livekit/README.md +++ b/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.