On 4 Mar 2024, at 14:42, Kai Köhne via Development <development@qt-project.org> wrote:
Hi, I suggest extending our qt_attribution.json format to explicitly mark third-party components not part of the Qt sources, like https://doc.qt.io/qt-6/qtmultimedia-attribution-ffmpeg.html. QUIP-7 change: https://codereview.qt-project.org/c/meta/quips/+/545126?usp=search qtattributionsscanner change: https://codereview.qt-project.org/c/qt/qttools/+/545098 Let me know what you think. Regards Kai Commented on the review, but also here, slightly more prosaic: Being able to document 3rd party components that are included in Qt because we provision and package them as part of the pipeline is a good idea. Both from an SBOM perspective, and because there are advantages in having a standardized, descriptive, machine-readable documentation of all dependencies that any Qt module has. The question is whether the goal is for us to mark *all* 3rd party components that way. E.g. we provision, compile and link against, and then package the runtime libraries for FFmpeg or SQL client libraries. The provenance of those should clearly be documented in something less obscure than a (power)shell-script in qt5.git/coin/provisioning. But what about system libraries and SDKs where we don’t ship the runtime (either because we expect those to be available on the target, because of licensing, or because we can dynamically detect the presence of the runtime and fail gracefully). Those SDKs might have inline functions in their headers, generating executable code in a Qt artefact that we do deploy. Or the tools that come with those SDKs might generate code that ends up compiled into Qt. So strictly speaking, we should list those as well, even though our Qt package doesn’t include any artefacts from those? Volker
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
