Question: how is the bundled `ffmpeg-static` build (appears to be GPLv3) intended to sit alongside Kap's MIT license?

[UNILESS]

Hi — thanks for the work on Kap. I'm doing some academic research on how open-source licenses interact with bundled binaries, and while looking through the v3.6.0 release I came across something I wasn't sure how to interpret. I figured it's better to ask than to assume.

What I noticed

The macOS release (Kap-3.6.0-x64.dmg) contains an ffmpeg static build at:

Kap.app/Contents/Resources/app.asar.unpacked/node_modules/ffmpeg-static/ffmpeg

SHA-256: 71f3114e2382d13c4b28adc957979274294380f193e2d0cb7397619fd23b47d3
Size: 78,445,520 bytes (Mach-O x86_64, static)

The binary's self-reported build configuration (from strings <ffmpeg> | grep configuration):

--cc=/usr/bin/clang --prefix=/opt/ffmpeg --extra-version=tessus
--enable-avisynth --enable-fontconfig --enable-gpl --enable-libaom --enable-libass
--enable-libbluray --enable-libdav1d --enable-libfreetype --enable-libgsm
--enable-libmodplug --enable-libmp3lame --enable-libmysofa --enable-libopencore-amrnb
--enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopus
--enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr
--enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab
--enable-libvmaf --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx
--enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid
--enable-libzimg --enable-libzmq --enable-libzvbi --enable-version3
--pkg-config-flags=--static --disable-ffplay

The --enable-gpl + --enable-version3 combination is what ffmpeg upstream treats as their GPLv3 build. This is a ffmpeg-static npm dep pointing at tessus's macOS builds from evermeet.cx, so this isn't a choice Kap made directly — it just comes with the package.

The thing I was wondering about

I wasn't sure how the MIT license on Kap and the GPLv3 on this ffmpeg build are meant to fit together inside the same .dmg. GPL has a "mere aggregation" idea (GPLv3 §5) that covers independent things that just happen to share a distribution medium, and I thought that might already be the intended reading here — a separate ffmpeg binary in node_modules/ isn't obviously part of Kap itself. But I couldn't find a note about it in the release, so I wasn't sure if that interpretation is actually the project's position or if it's just how ffmpeg-static happens to be shipped upstream.

I'm not a lawyer and don't mean to suggest anything is definitely wrong — just asking because the licensing picture isn't obvious from the outside, and a clarification (either in the README or here) would help downstream users and redistributors.

Some thoughts if any of this is useful

• A one-liner in the release notes or a small LICENSE-ffmpeg.txt alongside the binary would make the aggregation reading explicit, if that's the intended framing.
• If there's ever appetite to move to an LGPL-only ffmpeg build (--disable-gpl --disable-libx264 --disable-libx265 --disable-libxvid --disable-libvidstab), Kap already uses VideoToolbox for H.264 hardware encoding on macOS, and openh264 (BSD-2-Clause) can serve as a software fallback. This would probably need ffmpeg-static to offer an LGPL variant, or Kap to pick a different provider — so it's not a trivial change.
• Another path would be asking users to brew install ffmpeg and skipping the bundle entirely — simpler licensing-wise but definitely a UX hit.

No pressure to act on any of these — I'd genuinely like to know if I'm reading the situation wrong. Thanks for reading through, and thanks again for Kap.

Reproduction (just in case)

curl -L -O https://github.com/wulkano/Kap/releases/download/v3.6.0/Kap-3.6.0-x64.dmg
7z x Kap-3.6.0-x64.dmg
sha256sum "Kap 3.6.0/Kap.app/Contents/Resources/app.asar.unpacked/node_modules/ffmpeg-static/ffmpeg"
strings "Kap 3.6.0/Kap.app/Contents/Resources/app.asar.unpacked/node_modules/ffmpeg-static/ffmpeg" | grep configuration