Re: New 'as' port: GPL requirements?

[John Moran <jmoran-binutils at cyconix dot com>]

I know GPL-legalese is possibly the dullest thing on the planet, but I 
can't start on this port without a definitive answer, so I'd  appreciate 
some feedback on this...

Summary: I want to modify an existing GPL-ed program (gas) such that it 
makes calls to proprietary library 'A'. I'm not the copyright holder of 
'A', and there is no chance that the copyright holder will allow 'A' to 
be GPL'ed. 'A' is linked dynamically at runtime. Question: does the GPL 
allow me to do this (or, to be precise, does it allow me to distribute 
the modified 'gas')?

This is covered in the GPL FAQ 
(http://www.gnu.org/licenses/gpl-faq.html), but not definitively. The 
two relevant sections are:

1) "What is the difference between 'mere aggregation' and 'combining two 
modules into one program'" 
(http://www.gnu.org/licenses/gpl-faq.html#MereAggregation), and

2) "If a program released under the GPL uses plug-ins, what are the 
requirements for the licenses of a plug-in" 
(http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins).

The "Mere aggregation" section states:

> What constitutes combining two parts into one program? 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.

So, for a dynamic call to library A, this points to combination rather 
than aggregation. However, 'linked together in a shared address space' 
is not well-defined, and 'almost surely' is not helpful.

The "Plug-in" section states:

> If the program uses fork and exec to invoke plug-ins, then the
> plug-ins are separate programs, so the license for the main program
> makes no requirements for them. So you can use the GPL for a plug-in,
> and there are no special requirements.
>
> If the program dynamically links plug-ins, and they make function
> calls to each other and share data structures, we believe they form a
> single program, which must be treated as an extension of both the
> main program and the plug-ins. This means that combination of the
> GPL-covered plug-in with the non-free main program would violate the
> GPL. However, you can resolve that legal problem by adding an
> exception to your plug-in's license, giving permission to link it
> with the non-free main program.

This is more interesting. In this case, two-way communication is 
impossible, since I can't modify library 'A'. gas makes function calls 
to 'A', and not vice-versa. There are no shared data structures. In 
fact, the only reason for using direct library calls rather than a pipe 
or socket is performance, and the use of a pipe or socket points to 
aggregation anyway. In fact, the idea that making a call from a GPL'ed 
program into a library somehow converts the library into an extension of 
the GPL'ed program seems, to me anyway, to be utterly bizarre. The 
library is an independent entity that is unrelated to the calling 
program. We've all written code that calls, for example, 'fopen' - does 
that mean that we've all extended 'fopen'?

Any opinions? Any chance that any of the 'gas' copyright holders could 
also give an opinion?

Thanks -

John