Repository navigation
macOS ARM64 wheel 5.0.0.93 bundles GPL-configured FFmpeg (libx264/libx265) — conflicts with README LGPLv2.1 statement #1260
Description
Summary
The README states:
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:
- Clarification on H264 support of included ffmpeg #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.
- OSX FFmpeg can no longer be built without GPL libs #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.
- Inconsistency in FFmpeg license statements #349 — "Inconsistency in FFmpeg license statements" (closed).
- LGPL Compliance for Wheels #615 — "LGPL Compliance for Wheels" (open) concerns LGPL source-availability, which is a separate question.
- Provide wheel without FFmpeg (non-LGPL wheel) #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
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.93This 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.dylibcv2.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
- Is bundling a GPL-configured FFmpeg in the macOS wheels intentional?
- If so, should the README's "All wheels ship with FFmpeg licensed under the LGPLv2.1" be qualified per platform?
- If not, should the macOS build configuration be changed to an LGPL-only FFmpeg (no
--enable-gpl, no x264/x265)? - Do the Linux
manylinuxand 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.
Activity
asmorkalov commentedon Aug 14, 2026
No, it's side effect of the brew packages.
We will try to fix it on our side.
Yes.
Yes. We build FFmpeg wrapper for Windows separatelly and it does not contail GPL code. Linux version should be built without GPL code too. I'll revise it during Mac OS fix.
dzzz08 commentedon Aug 14, 2026
feat(cli): add --licenses flag and correct third-party notices (#698)
build(macos): compile OpenCV without FFmpeg to make the DMG GPL-free (#…
MineAGLX commentedon Oct 10, 2026
Thank you for the explanation above. Our retained static inspection records indicate that the headless macOS ARM64 sibling is affected too:
opencv_python_headless-5.0.0.93-cp37-abi3-macosx_13_0_arm64.whl030ca5e0837a2963ab36ef896baa9767eb8d2b83353fb28af5a521e40dd8756fThree bundled binary hashes match those reported in this issue:
The recorded load chain includes
cv2 → libavcodec → libx264/libx265; avfilter/avdevice also link bundled rubberband and vidstab. The wheel's LICENSE and LICENSE-3RD-PARTY texts match tag 93. We have not installed or imported this artifact.Could you point us to:
This is an artifact-identification and notice-consistency question, not a legal allegation or a request for blanket commercial-use certification. If the historical build records are unavailable, that clarification would also help. Thank you.