Pillow 12.3.0 Windows wheel: vendored fribidi-shim licence and notice clarification

[Prosanta87]

Hello Pillow maintainers,

We are reviewing third-party notices for 609 Blaze Business and would appreciate clarification specifically about the vendored fribidi-shim in Pillow 12.3.0 Windows wheels.

Our authenticated reference artifact is:

• Wheel: pillow-12.3.0-cp312-cp312-win_amd64.whl
• SHA-256: a2b55dd6b2a4c4b7d87ffa56bdb33fdc5fdb9a462173861a7bc097f17d91cb09
• Reviewed Pillow revision: bb1d8e8ab8d29048624d96e3ee53cecf7c13d13d

Five native extensions in our historical package match this official wheel byte-for-byte.

At that revision, pyproject.toml selects raqm=enable raqm=vendor fribidi=vendor imagequant=disable.

The build source selects fribidi-shim, which dynamically loads FriBiDi. The Windows workflow treats the full FriBiDi library as a separate artifact.

The inspected shim files do not contain a dedicated licence header. The wheel's build SBOM identifies the shim as LGPL-2.1-or-later, but we have not established its complete copyright and notice treatment.

Could you please clarify:

1. What is the authoritative licence for this vendored shim?
2. Which copyright holders and notices apply?
3. Is it covered by FriBiDi's licence, raqm's licence, Pillow's licence, or separate terms?
4. Which licence, copyright and notice texts should accompany an application distributing the affected Pillow Windows wheel, including where the application does not distribute the separate FriBiDi DLL?
5. Which authoritative source file or licence document should we cite?

The vendored raqm 0.10.5 source/licence association is already verified. We also retain the supplier-supported exclusion of libimagequant; neither question is being reopened here.

This is a documentation/provenance clarification request, not a request for legal advice or redistribution approval. A pointer to existing authoritative documentation would be sufficient.

Thank you,

Prosanta Kumar Roy
609 Blaze Business
support@609blaze.com

[aclark4life]

Sorry about that, fixed here: #10194