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

.gitea/workflows/build.yml

@@ -15,19 +15,10 @@ name: Build
 # .gitea/workflows/release.yml, so the two workflows can't drift apart --
 # edit the scripts, not either workflow, to change how a platform builds.
 #
-# RELEASE GATE: this workflow only builds, tests, and uploads CI-internal
-# workflow artifacts (actions/upload-artifact, below) -- it does not create a
-# Gitea Release, push a tag-triggered publish, or otherwise distribute
-# binaries publicly, and it must not start doing so without explicit owner
-# sign-off on the WebRTC/OpenH264 attribution question tracked in
-# third_party/livekit/README.md and the README's top-level Status section.
-# (The separate GPLv2/Apache-2.0 license-compatibility question is resolved:
-# this project's own code is Apache-2.0.) If a real release/publish step is
-# ever added here, it must carry that same gate.
-#
-# (.gitea/workflows/release.yml is that publish step, gated on a pushed
-# version tag rather than on every push -- see the gate reminder baked into
-# its generated release notes.)
+# This workflow only builds, tests, and uploads CI-internal workflow
+# artifacts (actions/upload-artifact, below) -- it does not create a Gitea
+# Release. .gitea/workflows/release.yml is that publish step, gated on a
+# pushed version tag rather than on every push.
 
 on:
   push:

.gitea/workflows/release.yml

@@ -4,24 +4,11 @@ name: Release
 # a (draft) Gitea Release for it, so the project owner and other directors
 # can grab a ready-to-use build instead of compiling from source.
 #
-# RELEASE GATE -- READ BEFORE TAGGING
-# ------------------------------------------------------------------
-# This workflow runs ONLY on a pushed version tag (see `on.push.tags` below)
-# -- it never runs on an ordinary push or PR, unlike build.yml. Pushing a
-# tag is therefore the one deliberate human act that starts it, and the
-# release it creates is a DRAFT: it stays invisible to anyone without write
-# access until a human explicitly opens it and clicks Publish. That is a
-# second deliberate act past the tag push.
-#
-# Both of those are process, not a legal opinion. The actual open question --
-# whether this plugin's bundled WebRTC/OpenH264 code (via LiveKit) can be
-# redistributed as a public download at all -- is tracked as "C1" in the
-# README's `## Status` section and in third_party/livekit/README.md, and it
-# is NOT resolved. Nothing here resolves it; the generated release notes put
-# a reminder of that fact at the top of every release this workflow creates,
-# specifically so nobody publishes a draft without seeing it again first.
-# (The separate GPLv2/Apache-2.0 question, "C2", *is* resolved -- see
-# README.)
+# Runs only on a pushed version tag (see `on.push.tags` below) -- never on an
+# ordinary push or PR, unlike build.yml. The release it creates is a DRAFT:
+# it stays invisible to anyone without write access until a human explicitly
+# opens it and clicks Publish, since nobody has run this plugin in the OBS
+# GUI on any platform yet.
 #
 # The actual per-platform build commands live in .gitea/scripts/ and are the
 # same scripts .gitea/workflows/build.yml uses, so this workflow can't drift