Repository navigation
FreeType license is applied incorrectly #8880
Description
Activity
Thank you @ulfllorenz ! Are you able to submit a PR for the fix ?
#7507 added both the FreeType and GPL license text to https://github.com/python-pillow/Pillow/blob/main/wheels/dependency_licenses/FREETYPE2.txt. So I'll ping @stefan6419846 in case he has any thoughts.
I've created #8884
This is indeed a tricky question and I am not sure whether there is any public guidance available for this, but I see some issue with the proposal and current approach:
- If Pillow exercises a choice, this must be documented clearly. The current state with just removing the GPL license text is not enough.
- When we read we see that Pillow would disallow users to use it in any project which uses the GPL-2.0 (and maybe the corresponding LGPL). This is a breaking change if we do not already have a conflict with the GPL-2.0 in another dependency (which I am not aware of directly, but have not checked explicitly this time).
Pillow/wheels/dependency_licenses/FREETYPE2.txt
Lines 17 to 18 in 0490948
As far as I am aware, leaving this choice open to the actual distributor of the final software which includes the Pillow and FreeType dependency is completely fine and allows for the greatest compatibility.
Disclaimer: IANAL.
I would be surprised if it wasn't necessary for Pillow to choose, as while Pillow would be a dependency of some other software most of the time, it is also potentially 'final software'.
I've created https://gitlab.freedesktop.org/freetype/freetype/-/issues/1324 to see what the FreeType community thinks.
@stefan6419846 : That would, however, mean that Pillow itself needs to be distributed under a dual license (GPL + current one). The Freetype library copyleft covers the using code (in the end: pillow), and requires that to also be distributed under GPL. Not my preferred outcome (now I have to choose :)), but seems like the end result.
As it is rather common with FOSS licensing, we only really know how each country treats this once there are comparable court rulings. There are many questions which are relevant for cases like this where binary (manylinux) wheels (including native components) are distributed. The essential part is to at least provide the original licenses and a way to determine which package versions are included.
When can we consider the different components to be linked? When do we create derivative works? Linking might be the case only during runtime, maybe only due to header files being considered to not have the necessary threshold of originality to fall under copyright in some cases.
As always, you will find yourself (or the final distributor, usually a company, you are working for) doing a risk assessment with all the available facts - there is no clear "correct" or "incorrect" as far as I am aware. In the end, it is up to you to review all facts/details provided by Pillow about its dependencies yourself anyway and ultimately choose which licensing terms to propagate to your customers. This does not really depend on whether Pillow chose a license for FreeType or not due to disclaiming all liabilities in its license (to the extent possible by local laws).
This being said, for me it would not really be an issue to drop the GPL-2.0-only terms for FreeType for Pillow due to further license incompatibilities of GPL-2.0-only when it is documented properly (which the PR did not), but I want to avoid Pillow unexpectedly breaking compatibility with all users relying on the GPL-2.0-only compatibility. I personally do not really expect a definitive answer in a timely manner in the upstream issue from my experience with similar aspects regarding cairo.
Reacted by Ulf LorenzReacted by Jeffrey 'Alex' ClarkJust to make my point clear: I think this whole issue is such a minor point it might not even register in a risk assessment, and it does not block me professionally in any way. I only noticed because I have come across the same FreeType dual license issue recently and wanted to personally give something back. I am not sure if you can construct a realistic scenario, but GPL-2.0-only compatibility would be a valid concern that I was not aware of.
I guess we wait for some response to Andrew Murray's cross-ticket, then.
Reacted by Jeffrey 'Alex' ClarkINAL.
-
Pillow is not going to be GPL v anything. IF we consider relicensing, which is such a gigantic can of worms that's never going to happen, I'd push for the Python license. However, since we've got our own trove classifier now and we've determined that we're basically the Python license in effect with a different name, not gonna happen.
-
GPL is a distribution license, not a use license. We distribute Pillow under the Pillow license, and that gives developers the ability to use it in closed source applications. We link to (L)GPL libraries (raqm/harfbuzz) but (at least at one time) did not distribute them. If you wanted that feature, you had to provide the library. This is similar to how applications deal with libreadline.
-
Nothing we do for distribution licenses affects what users of our software do when they package and distribute Pillow within their code. They can choose which FreeType license to apply at that point, as they are the ones distributing the software.
I think if we leave both licenses in, and state somewhere that for the purposes of Pillow binary distribution, we choose the FreeType license, then we're fine. We're following the spirit of the licence, we're indicating a choice for the distribution that we're making, we're not constraining our user's options, and we're informing those that are paying attention that there's a choice to be made.
Reacted by Jeffrey 'Alex' Clark-
I reeived a response via e-mail from FreeType
AFAICS, Pillow is a library and thus not an end product. I think for such cases it is easiest to simply provide all licenses that
sub-packages like FreeType use. Of course, all these licenses must harmonize – if you use in Pillow, say, unconditionally some software that is GPL2 only, you can omit GPL3 since it is incompatible a priori.Maybe the FSF has already an answer to that question, which probably arises quite frequently in other projects.
Werner
Reacted by Jeffrey 'Alex' Clark- changed the title
[-]Freetype license is applied incorrectly[/-][+]FreeType license is applied incorrectly[/+]on Nov 15, 2025 Coming to this fresh after the quiet period, I looked at what the published wheels actually contain, and it turns out to differ by platform. Posting the measurements in case they are useful.
What the 12.3.0 wheels contain
Downloaded from PyPI, reading
*.dist-info/licenses/LICENSEin each:Windows wheels Linux / macOS / iOS wheels FreeType's "you must choose one of the two licenses" paragraph present present Full GPLv2 text present absent Where the FreeType section comes from (build time) upstream FreeType files selected in winbuild/build_prepare.pyrepository file wheels/dependency_licenses/FREETYPE2.txtThe two build paths collect FreeType's license from different places.
winbuild/build_prepare.py:255lists["LICENSE.TXT", r"docs\FTL.TXT", r"docs\GPLv2.TXT"]and reads them from the upstream FreeType tarball, so the WindowsLICENSEcarries both texts under a===== freetype-2.14.3 =====heading. The other platforms concatenatewheels/dependency_licenses/*intoLICENSEvia.github/workflows/wheels-dependencies.sh:431, and that is the file #8884 edited.The current difference dates to that change: #8884 removed the GPLv2 body from the repository-side file used by non-Windows builds, without changing the older Windows collection path. In the artifacts: 11.1.0 (January 2025) shipped the full GPLv2 text in both the Windows and the macOS wheel; 11.2.1, published about ten hours after #8884 merged, still shipped it on Windows but no longer on macOS.
Why that may matter here
The situation described at the top of this issue — the reader is told to choose between two licenses and can see both — is still the case on Windows. On the other platforms the reader is told to choose between two licenses, is pointed at
docs/GPLv2.TXT, and only one of them is included.One thing that postdates the discussion
Pillow now generates a CycloneDX SBOM (#9550, April 2026) and embeds it into wheels (#9679, June 2026), so 12.3.0 and later carry one under
.dist-info/sboms/per PEP 770. Its FreeType component recordsFTL.Two caveats on reading too much into that: the generated SBOM is identical across platforms and lists optional components — libimagequant is in it with
GPL-3.0-or-lateralthough the official wheels do not link it — so it is not an exact inventory of any one wheel, and I do not know whetherFTLthere was meant as an election or simply as the dependency's primary identifier. Earlier wheels do not carry this Pillow-generated entry, though Linux wheels may contain a separate auditwheel-generated SBOM.What I am not saying
I have no view on which license Pillow should choose, or on the legal effect of either option, and I am not in a position to have one. Everything above is textual: which files are present in which artifacts, and what strings they contain.
Offer
If maintainers decide what the FreeType section and the SBOM entry should say, I would be glad to prepare the PR and add an artifact-level check covering both the Windows and the non-Windows wheel paths, since there is currently nothing that would catch the two drifting apart again.
Hi,
I have recently gone through our dependencies and their licenses, and noted that you apply the Freetype license incorrectly. Freetype is licensed under either the GPL or the Freetype license. Given the obvious downstream problems with the GPL, you probably want to use the Freetype license.
I assume as a non-lawyer that you can probably just remove the GPL text or write in the third-party license document something like "We choose the Freetype license for distribution".
I would consider this a minor problem, but then the fix is also small, so I thought I'd raise that.