search

conda-forge / pillow-feedstock

A conda-smithy repository for pillow.
BSD 3-Clause "New" or "Revised" License
2 stars 30 forks source link

Attributed licenses citing GPL in License.txt for version 10.0.0 as installed by miniconda #144

Closed buildqa closed 11 months ago

buildqa commented 1 year ago

Solution to issue cannot be found in the documentation.

Issue

The Pillow LICENSE.txt file installed by miniconda (for ver 10.0.0 for MacOS Monterey on M1 Macs) combines the citations for many different software licenses. The freetype 2 license cited provides the choice of a non-GPL or GPL option. However, the libzlma license cited mentions GPL in 2 places: (1) xz, xzdec, and lzmadec command line tools are in the public domain unless GNU getopt_long had to be compiled and linked in from the lib directory. The getopt_long code is under GNU LGPLv2.1+; (2) The build system contains public domain files, and files that are under GNU GPLv2+ or GNU GPLv3+. None of these files end up in the binaries being built.

Wondering if there is a way to verify for (1) above that getopt_long has in fact not been built info the 10.0.0 version of Pillow as installed by miniconda for darwin_arm64. I assume that (2) above is not an issue that would otherwise GPL encumber distributing a darwin_arm64 miniconda image with Pillow installed.

Installed packages

miniconda for darwin_arm64 then install Pillow

Environment info

n/a
h-vetinari commented 1 year ago

CC @conda-forge/core because GPL questions are always a fun riddle

hmaarrfk commented 1 year ago

not a lawyer, not giving legal advice. my understanding is somewhere along the lines of

Citing both GPL and non GPL is fine. the end user can choose their chosen license. we are just giving the maximum choice. and also, maximum confusion as to which license applies to which parts of the end executable/library. ultimately, different binaries in the same package will require different licenses to be included. we have included them.

library makers typically do this dual license thing, where the shared library is LGPL and the command line tools, typically considered end executable's by the GPL, are licensed under the GPL. This helps you use the library in your own application, while helping improve the provided stock frontend.

(1) command line tools are GPL, the library is not. this is fine. the GPL allows for non GPL code to use GPL command line tools too. GPL requires that you make the GPL text available in the end distribution. it is.

(2) The build files are not actually distributed to the end user. or at least, they are used in the parts of the code that end up in the library (non GPL).

to verify this kind of stuff is basically a pretty deep effort. verifying a negative is really hard. search for the function you are concerned with and see where it shows up in the source.

good luck.

note that other build systems have taken it upon themselves to list every single file that is licensed under a different license. this is what Debian does in the copyright file they have. I have unfortunately not found somebody that really lists how things are combined. I think that. companies like black duck code review help you get down to that answer https://www.synopsys.com/software-integrity/security-testing/software-composition-analysis.html aggain, Goodluck.