Hi Volker!
> From: Volker Hilsheimer <volker.hilshei...@qt.io> > Sent: Tuesday, March 5, 2024 10:40 > To: Kai Köhne <kai.koe...@qt.io> > Cc: development@qt-project.org <development@qt-project.org> > Subject: Re: [Development] Extending qt_attribution.json files to mark > provisioned components > > > >> 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. > >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. Indeed. I still hope we can facilitate vcpkg as a more structured/easier to detect way than some provisioning script, but this is only making slow progress for a variety of reasons. Btw, we also have the option to put in the qt_attribution.json files inside qt5/coin by now, so that it is nearer the actual provisioning code. > 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. In general, I think we should be as transparent as reasonably possible. But that approach with manually maintained qt_attribution.json files obviously has it's limits. I think it's hopeless to document e.g. single copyrights of transitive Linux header dependencies this way ... We're actually also looking into build system tooling for SBOM's that could automate the process. For now, I'm seeing the qt_attribution.json files as a pragmatic approach for bigger items where the license actually mandates notifications and attributions, like the mentioned ffmpeg backend plugin. > 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? Should we work towards completeness? Yes. But let's not block ourselves by perfectionism. Even the relevant SBOM standards acknowledge that there will in practice always be a grey area, and allow indicating that there are 'known unknowns'. Kai -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
