On Sun, Nov 21, 2010 at 4:26 PM, Graeme Gill <grae...@argyllcms.com> wrote:

>> If the program dynamically links plug-ins, but the communication
>> between them is limited to invoking the ‘main’ function of the plug-in
>> with some options and waiting for it to return, that is a borderline
>> case.
> But this is all irrelevant. The fact that the package contains
> GPL code, makes the package derived from the GPL code, even if
> the non-GPL contents of the package are un-connected with the GPL
> contents. The only "out" you have is if it is "mere aggregation".

The GPL applies to the GIMP and nothing more.  Distributing a binary
of the GIMP only requires the person shipping the binary to abide by
the rule of offering access to the GIMP source code.  Distributing
anything else along with this binary is aggregation.

The text you quoted says it's gray if the GIMP is opened as a shared
object - but the default case or calling it via fork()/exec() (or
flash's equivalent) is perfectly legitimate.  What is wrong is calling
GNU's FAQ for their GPL "irrelevant".

> [...] (and the non
> GPL code having functionality that is dependent on GPL code
> seems a pretty strong hint I think, that this is not mere aggregation),

The GNU project is very explicit that your interpretation does not match theirs:


What is the difference between an “aggregate” and other kinds of
“modified versions”?

An “aggregate” consists of a number of separate programs, distributed
together on the same CD-ROM or other media. The GPL permits you to
create and distribute an aggregate, even when the licenses of the
other software are non-free or GPL-incompatible. The only condition is
that you cannot release the aggregate under a license that prohibits
users from exercising rights that each program's individual license
would grant them.

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

AFAIK, GIMP doesn't allow "exchanging complex internal data
structures" via the command line, and even if it did, the GNU project
itself states only that if this were taken to court a lawyer would
argue the point.  And at that point, a judge would have to decide.

Gimp-developer mailing list

Reply via email to