Freetype license is applied incorrectly

[ulfllorenz]

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.

[aclark4life]

Thank you @ulfllorenz ! Are you able to submit a PR for the fix ?

[radarhere]

#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

[stefan6419846]

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

  Pillow/wheels/dependency_licenses/FREETYPE2.txt

  Lines 17 to 18 in 0490948

  	Note that this license is compatible to the GNU General Public
  	License version 3, but not version 2.

  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).

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.

[radarhere]

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.

[ulfllorenz]

@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.

[stefan6419846]

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.

[ulfllorenz]

Just 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.

[wiredfool]

INAL.

1. 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.

2. 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.

3. 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.

[radarhere]

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