Request for clarification and documentation on applying licenses to packages that dynamically link against downstream GPL licensed dependencies

Some conda packages depend on dynamically linking to other conda packages that happen to be GPL licensed. Conda forge then distributes individual binaries for each package separately and the interrelated packages are then dynamically linked on a end user’s computer when all the packages are installed and loaded.

The concern/question I have is whether the license of the conda package that is upstream of a dynamically linked GPL package has to be licensed with the GPL or not. And secondly, if so, what should the license include (e.g. licenses for everything that is dynamically linked) and even whether the source code has to be distributed with the conda package somehow.

This question arose here originally:

https://github.com/conda-forge/pyshtools-feedstock/issues/3

where we decided to apply the GPL to the pyshtools package even those the pyshtools source code is BSD licensed. pyshtools dynamically links against FFTW which is licensed “GPL 2 or later”.

I then opened some issues on non-GPL licensed upstream dependencies of FFTW to warn those maintainers that they may need to re-license as GPL.

The maintainer of OpenMM, @peastman, responded with some careful explanations in which he argues that the binaries that Conda Forge distributes do not have to be GPL licensed but only GPL compatible.

See those explanations here:

https://github.com/conda-forge/openmm-feedstock/issues/24

My head has exploded trying to think about this, as it is quite confusing. Thus, I think it would be helpful to get a ruling on this and then add some documentation that clearly states the consequences of upstream packages dynamically linking to downstream GPL packages.

Summary of Research [WIP]

Note that this summary is a work in progress and it may be inaccurate.

TODO

• Add references to each claim.

There at least two main interpretations of how to handle things:

1. The GPL “infects” any software (source and binary) that is a derivative work of the GPL’d dependency. Using the API declared in the headers of a GPL’d library in your code constitutes a derivative work. The intent of the GPL authors [2] is that any software that links statically or dynamically to a GPL dependency, should have to be released under the GPL if distributed [c].

2. Dynamic linking only occurs on the computer that loads the conda binary into memory alongside the GPL dependencies. The act of linking constitutes copyright “infection”. Thus only if you distribute binaries together that are linked are you subject to the GPL. Since the conda binary does not include the GPL dependency when distributed, only references to the API, it can be licensed under licenses other than the GPL (the likely license being the one the primary binary’s source code is using).

Points 1 and 2 are complicated by the fact that APIs may or may not be copyrighable [1]. The current ruling is that APIs can be copyrighted, but the case is still being appealed and open. It is very common that two pieces of software implement the same API but the code that backs the API are either not derivatives of each other or they are but the authors of the derivative library have permission to relicense. We get things like FFTW (GPL) and Intel’s MKL which includes FFTW code (specially licensed to Intel and implements some of the FFTW API), making them drop in replacements of each other. If APIs are not copyrightable and you take the point 2 interpretation, then you are free to license your binary using any license you want to even though your binary may link to GPL’d binaries on someone else’s computer. If APIs are not copyrightable and you take the point 1 interpretation, the FSF still intends for GPL to infect because there is the intention to dynamically link. If APIs are copyrightable, then we are all in big trouble.

For Conda Forge, we specify the exact dependency in the meta.yaml file and thus know that when installed on a user’s computer the binary will most certainly link against the GPL’d dependency that conda installs alongside the primary binary. [a] In some sense, Anaconda.org is even distributing these software packages as a collection based on the dependency tree of any given package. So even though we are not distributing the GPL dependency alongside the primary binary in the same downloaded file, we do intend for the binaries to link.

Current conclusion

The legally safe approach is to license Conda binaries that dynamically link to GPL’d dependencies (optional or not) be distributed under the GPL as long as the license of the primary binary’s source code is GPL compatible. [b] This also means we should be releasing the source code for these packages alongside the binary re-licensed under the GPL.

The more dubious approach, that essentially relies on a loophole to the GPL wording about linking, is to license the conda binary as the associated package source code is licensed.

References

[1] https://en.wikipedia.org/wiki/Google_v._Oracle_America [2] https://opensource.stackexchange.com/a/2163/17049

Footnotes

[a] It is possible that a user’s conda install command pulls binaries from a variety of public and private conda channels, so we don’t know what exactly will be installed by the user, but our intent in designing the meta.yaml file is that a particularly binary in the conda forge channel is installed. [b] The reason the license has to be GPL compatible is because you are required to release the source code along with the binary per the GPL. Any GPL compatible license can be relicensed as GPL. [c] The conda forge build process links the primary binary to the GPL dependency binary in the build process, thus the primary binary is considered a “combined work” by the FSF: http://www.gnu.org/licenses/gpl-faq.en.html#GPLStaticVsDynamic

[beckermr]

For me, if I create the build recipe and initiate the action of building the software and distributing it, I want to have some personal confidence that I’m applying and including the licenses correctly in the binary I helped distribute, because I could be held liable for that action.

Agreed 100%. We worry too!

[beckermr]

That’s fine. I don’t think you’ll find anyone here willing to provide advice of this nature, whatever that nature is.