GPL Compatibility

[dgasmith]

• I read the conda-forge documentation and could not find the solution for my problem there.

Issue:

Is there an official stance of mixing GPL and non-GPL dependancies together by conda-forge? The libimagequant issue outlined here (python-pillow/Pillow#6019) seems a bit precarious as it makes entire conda-forge package lineages difficult to use in many scenarios. GPL-based code on Conda-forge seems quite few and far between in general; however, pushing those packages this deep in the stack is rough to work around.

[swails]

Sharing address space (linking the library) renders a project a "derivative work" and extends the GPL coverage to the parent project.

The inclusion of a GPL dependency here ends up rendering the conda-forge pillow distribution to be covered under the GPL in its entirety (which is incorrectly specified in this recipe). I wonder if multiple variants can be released, optionally installing a Pillow[libimagequant] if GPL is acceptable?

[zklaus]

Sharing address space (linking the library) renders a project a "derivative work" and extends the GPL coverage to the parent project.

[citation needed]

[h-vetinari]

Seeing that many people seem to be running into this (environments that have hard bans on any GPL software being present?), I think it should be fixed. See this comment for where things stand.

[h-vetinari]

Is there an official stance of mixing GPL and non-GPL dependancies together by conda-forge?

I don't think there is, but you could ask by raising an issue under https://github.com/conda-forge/conda-forge.github.io/

[dgasmith]

Sharing address space (linking the library) renders a project a "derivative work" and extends the GPL coverage to the parent project.

[citation needed]

This is relatively well known concept: https://en.wikipedia.org/wiki/Viral_license

@h-vetinari Thank you for your hard work here, I try to maintain a suite of conda-forge projects to share the load.

[swails]

Sharing address space (linking the library) renders a project a "derivative work" and extends the GPL coverage to the parent project.

[citation needed]

This part of the GPL FAQ is the direct citation for my statement. Here is the relevant quote (emphasis mine):

Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

While the FAQ here makes an admission that it is up to a judge to decide whether this particular case would violate the GPL (that is using Pillow with libimagequant under conditions of just the BSD license) it is the express opinion and intent of the GPL authors that this would constitute a derivative work and is something they would actively defend in court. Any company or individual wishing to avoid being bound by the GPL would do well to abide by the guidelines set forth in this FAQ, regardless of their personal (and likely legally-underinformed) opinions on the matter.

[zklaus]

So it seems we agree that the legal question of whether

Sharing address space (linking the library) renders a project a "derivative work" and extends the GPL coverage to the parent project.

is, perhaps regrettably, open at this point. I think it should therefore not be stated as fact, lest we muddle the water.
Viral licensing is indeed well known. However, the posted link doesn't seem to add much to the question at hand, that is whether dynamic linking constitutes derivation, except for where it adds Eric S. Raymond's opinion that in a court of law it likely won't.

I certainly agree that it is the right and decent thing to honor the intent of the licensor when it is known. The intent of the authors of the license is less important in my mind. Normally, the authors of the license, in so far as they don't also happen to be the licensor, are not the ones defending a license in court.

Any company or individual wishing to avoid being bound by the GPL would do well to abide by the guidelines set forth in this FAQ, regardless of their personal (and likely legally-underinformed) opinions on the matter.

A prominent voice to the contrary is Lawrence Rosen who, during his tenure as general counsel for the Open Source Initiative (OSI, https://opensource.org/) wrote in an article for the Linux Journal:

Does merely linking to a program without any change to the original source code create a derivative work of that program? Almost every program links to library routines. Surely, one doesn't create a derivative work of a library simply by calling a sqrt function in the library. Why should it be any different when you link to something as complex as an enterprise server or database engine?

I sure hope he was legally informed.

This is not the place to engage in lengthy pseudo-legal debates, so I will probably refrain from engaging further here. I think the intentions and wishes of the authors of the library matter (more than those of the authors of the license), so asking them is often a good way to approach such questions. I also think these things should be taken very seriously and part of that is not overstating the case in an attempt to coerce behavior, but rather to engage with all involved to reach an amicable solution and ideally clarification of unclear aspects.

Have a nice weekend!

[dgasmith]

@zklaus As you point out, debating the "correct" interpretation isn't helpful and will either not be decided decisively or decided by a series of very large lawsuits. However, the effect on the ground is that no lawyer I have ever met, either open-source focused or corporate, views violating the points laid out in the GPL FAQ as safe from a legal standpoint. As lawyers are entrusted to inform the rules at organizations, incorporating GPL code into this library cuts off large portions of users (and therefore maintainers) for all downstream packages.

[h-vetinari]

#112 is going to remove the GPL bindings for now, pending further discussion in #109 resp. conda-forge/conda-forge.github.io#1608. In the meantime, I'll consider this issue closed, but feel free to let us know if there's something else, or just open a new issue.