macOS ARM64 wheel 5.0.0.93 bundles GPL-configured FFmpeg (libx264/libx265) — conflicts with README LGPLv2.1 statement

Summary

The README states:

All wheels ship with FFmpeg licensed under the LGPLv2.1.

On the current macOS ARM64 wheel for opencv-python 5.0.0.93, the bundled FFmpeg appears to be configured with --enable-gpl, --enable-libx264 and --enable-libx265, and libavcodec links libx264/libx265 directly. That looks inconsistent with the LGPLv2.1 statement above, so I wanted to report it with binary-level detail and ask whether it is intentional.

I'm not making any legal claim here — just reporting what the artifact contains and asking whether the documentation or the macOS build configuration is the thing that should change.

Related existing issues

I searched open and closed issues first:

• #682 — "Clarification on H264 support of included ffmpeg" (closed) raised this same LGPL/H264 discrepancy from the behavioural side (H264 decoding working despite the LGPL statement). This report is the binary-level counterpart, on a current release.
• #142 — "OSX FFmpeg can no longer be built without GPL libs" (closed, 2018) predicted exactly this for macOS, noting Homebrew's ffmpeg could no longer be built without x264/x265.
• #349 — "Inconsistency in FFmpeg license statements" (closed).
• #615 — "LGPL Compliance for Wheels" (open) concerns LGPL source-availability, which is a separate question.
• #353 — "Provide wheel without FFmpeg (non-LGPL wheel)" (open), a related feature request.

This report differs in that it covers the current 5.0.0.93 macOS ARM64 wheel and includes reproducible binary evidence rather than inferred behaviour.

Environment

Package	opencv-python 5.0.0.93
Wheel	opencv_python-5.0.0.93-cp37-abi3-macosx_13_0_arm64.whl
SHA-256	198a75138241810206a17c829dbcc40a7cb1841cda538ca86cbbfc6c7d95f898
Platform	macOS 26.5.1, arm64 (Apple Silicon), Python 3.12

The SHA-256 matches the digest published on PyPI for that file, and was verified by downloading directly from files.pythonhosted.org.

Reproduction

Installed into a clean virtual environment, binary-only so no source build can occur:

uv venv --python 3.12 venv
uv pip install --python venv/bin/python --only-binary=:all: --no-deps --no-cache opencv-python==5.0.0.93

This produced 99 bundled dylibs in cv2/.dylibs, and the resulting tree was byte-identical to a separately installed copy (only __pycache__ differed). Matching SHA-256 for the key binaries:

cv2.abi3.so                88fe237e2a314bc56dcd495d8ab93d65251d00205f6312d8724ecb3c276f0536
.dylibs/libavcodec.61.19.101.dylib  20825ad7fa755087b533595d24ebb7d5424114bef428032b233537c4e7f1e09f
.dylibs/libx264.164.dylib  7f02ead8b5987d7441c56521a80a3e894b44fa5f49a57f8dd515ac3b3f733564
.dylibs/libx265.215.dylib  860a3c77010264c498e781b599980f6bb8cdaab989b05ea1522844bab961bbac

Evidence

1. Relevant contents of cv2/.dylibs (of 99 total):

libavcodec.61.19.101.dylib   libavformat.61.7.100.dylib
libavutil.59.39.100.dylib    libpostproc.58.3.100.dylib
libx264.164.dylib            libx265.215.dylib
librubberband.3.dylib        libvidstab.1.2.dylib
libbluray.2.dylib

2. libx264/libx265 are genuinely linked, not merely co-located:

$ otool -L cv2/.dylibs/libavcodec.61.19.101.dylib | grep -E 'x264|x265'
	@loader_path/libx264.164.dylib (compatibility version 0.0.0, current version 0.0.0)
	@loader_path/libx265.215.dylib (compatibility version 215.0.0, current version 215.0.0)

And the extension module links FFmpeg:

$ otool -L cv2/cv2.abi3.so | grep -E 'avcodec|avformat|avutil|swscale'
	@loader_path/.dylibs/libavformat.61.7.100.dylib
	@loader_path/.dylibs/libavcodec.61.19.101.dylib
	@loader_path/.dylibs/libswscale.8.3.100.dylib
	@loader_path/.dylibs/libavutil.59.39.100.dylib

cv2.getBuildInformation() reports FFMPEG: YES.

3. FFmpeg build configuration embedded in the shipped libavcodec:

$ strings -a cv2/.dylibs/libavcodec.61.19.101.dylib | grep -m1 -- '--prefix='
--prefix=/opt/homebrew/Cellar/ffmpeg/7.1.1_3 ... --enable-version3 --enable-gpl
--enable-libx264 --enable-libx265 --enable-librubberband --enable-libvidstab
--enable-libbluray --enable-libtesseract --enable-libzmq ...

The /opt/homebrew/Cellar/ffmpeg/7.1.1_3 prefix suggests the macOS wheel vendors a Homebrew-built FFmpeg, which would match the situation described in #142. That also seems to explain the unusually large bundled payload (e.g. libtesseract, libleptonica, libzmq, libSDL2).

Questions

1. Is bundling a GPL-configured FFmpeg in the macOS wheels intentional?
2. If so, should the README's "All wheels ship with FFmpeg licensed under the LGPLv2.1" be qualified per platform?
3. If not, should the macOS build configuration be changed to an LGPL-only FFmpeg (no --enable-gpl, no x264/x265)?
4. Do the Linux manylinux and Windows wheels differ here? I only audited macOS ARM64, so I can't say whether this is macOS-specific.

Happy to run further checks on the macOS wheels or test a candidate build if that would help. Thanks for maintaining these packages — the fact that LICENSE-3RD-PARTY.txt is shipped inside the wheel made this much easier to investigate.