x265 GPLv2 license analysis — already mitigated in CMake build

[tobias-weiss-ai-xr]

Summary

Investigated the x265 GPLv2 license concern (incompatible with the project's AGPLv3 license) in Common/3dParty/heif/.

Finding: Already Mitigated

The x265 GPLv2 license issue is already fully mitigated in the production build system:

CMake build (DocumentServer Docker) — No HEIF support

• The core/DesktopEditor/graphics/cmake/CMakeLists.txt does not reference heif, x265, or libde265 at all
• No CXIMAGE_SUPPORT_HEIF define is set in the CMake path
• This is the build system used by the DocumentServer Dockerfile — x265 is never fetched, compiled, or linked

qmake build (desktop apps) — Optional via compile-time toggle

• HEIF support is gated by CONFIG += support_heif in raster.pri (lines 287-295)
• Can be disabled with CONFIG -= support_heif
• All C++ code using HEIF is protected by #if CXIMAGE_SUPPORT_HEIF guards
• WASM builds explicitly set CXIMAGE_SUPPORT_HEIF 0

What x265 is used for

• HEIF/HEIC image format encoding/decoding in the desktop editor
• Static linking in qmake builds only (via --whole-archive on Linux)
• Not present in the repository (gitignored, cloned at build time)

Recommendation

No immediate action required. The CMake/Docker build path already excludes HEIF. For desktop qmake builds, HEIF can be disabled if desired by removing the !build_xp { CONFIG += support_heif } block from raster.pri.

References

• core/Common/3dParty/heif/heif.pri — build configuration
• core/DesktopEditor/graphics/pro/raster.pri lines 287-295 — CONFIG toggle
• core/DesktopEditor/graphics/cmake/CMakeLists.txt — no HEIF references
• core/DesktopEditor/cximage/CxImage/ximacfg.h lines 48-58 — compile-time guard

[juliusknorr]

FYI @rikled @Aiiaiiio

[juliusknorr]

Thanks for raising this, this needs some discussion then on how this can be handled with the desktop build.