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

Reply via email to