4 Commits

Include renames

Author	SHA1	Message	Date
shadowdaoandClaude Sonnet 5	104326d05a	docs/release: drop the C1 licensing gate, simplify install instructions ... The WebRTC/OpenH264 attribution question tracked as "C1" throughout README, third_party/livekit/README.md, the release-notes template, and both workflow header comments is the project owner's call, and it has been made -- own sign-off given and reaffirmed. Remove the gate language and the extended research writeup from release-facing docs; keep the actual LICENSE/NOTICE files themselves (Apache-2.0 requires shipping those regardless of any of this). Also simplify the release notes' install instructions per owner request: point at each platform's default OBS plugins folder rather than walking through verbose per-platform copy/extract instructions -- the archives already extract straight into place (prior commit), so a short pointer is all that's needed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-07 09:40:49 -07:00
shadowdaoandClaude Sonnet 5	43a501c06c	release: package archives as direct drop-ins to OBS plugin dirs ... Previously each release zip mirrored build/package/ verbatim (bin/ + data/ at the archive root), which needed a manual mkdir + cp -r into the right OBS plugin subdirectory per the install instructions. Wrap Linux and Windows archives in a top-level streamer-tools-camera/ directory instead -- matching AddExtraModulePaths()'s expected <config>/obs-studio/plugins/<name>/bin/64bit + data layout -- so `unzip -d ~/.config/obs-studio/plugins/` (or Expand-Archive to %APPDATA%\obs-studio\plugins\ on Windows) is the entire install step. macOS already produced the right shape (the .plugin bundle itself at the archive's top level, since OBS wants the whole bundle directly under plugins/, not nested under a named subdirectory) -- no packaging change needed there, just an install-instructions rewrite plus making that text properly conditional on MACOS_BUNDLE_FOUND like MACOS_NOTE already was, since the old hard-coded "not yet that bundle shape" text was stale once the macOS bundle packaging fix landed. Verified locally: staged a fake build/package/ tree, ran the new packaging logic, and confirmed extracting the resulting zip into a plugins directory produces <name>/bin/64bit/... and <name>/data/... directly. Also dry-ran publish-release.sh's notes generation for both MACOS_BUNDLE_FOUND values to confirm the conditional install text renders correctly. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-07 08:41:44 -07:00
shadowdaoandClaude Sonnet 5	14fa00af3f	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	2026-09-07 07:45:36 -07:00
shadowdaoandClaude Sonnet 5	2b216d3d75	ci: add tag-triggered release packaging workflow ... Adds .gitea/workflows/release.yml, triggered only on a pushed v* tag, which builds all three platforms (reusing the exact same configure/build/test commands as build.yml, now factored out into .gitea/scripts/ so the two workflows can't drift), zips each platform's build/package/ output, and creates a draft Gitea Release with the archives attached. This is packaging automation only -- it does not resolve or bypass the C1 WebRTC/OpenH264 release gate documented in README.md's Status section. Nothing publishes until a human deliberately pushes a version tag (which should not happen before owner sign-off) and then explicitly publishes the resulting draft. The generated release notes lead with a restatement of the open C1 question specifically so that second step can't be taken by accident. build.yml is refactored (not rewritten) to call the same shared scripts; its job/step behavior is otherwise unchanged. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-07 05:06:25 -07:00