New 'as' port: GPL requirements?
John Moran
jmoran-binutils@cyconix.com
Mon Nov 7 17:54:00 GMT 2005
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
More information about the Binutils
mailing list