This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New 'as' port: GPL requirements?


John Moran wrote:

> 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')?

I'd say no.

> 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.

Why is it not well-defined?  If a program has routines from a library
added or copied to its process space then they're dynamically linked and
the whole thing counts as one work.  When you use IPC or fork/exec the
library routines remain in their own separate process space.

> > 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. 

I think you're overemphasizing the phrase "they make function calls to
each other."  I think the above is simply saying that if a program opens
a dynamic module with dlopen(), calls a function in that module, and
optionally looks at the return value, then that library has been
dynamicly linked into the program's address space and thus counts as a
single combined / derivative work of both the program and the library. 
It doesn't seem relevant whether the main program calls functions in the
plugin or the plugin calls functions in the main program - "to each
other" means either/both as far as I see it.  The fact that they used
language that implies mutual cooperation just emphasises the fact that
both sides must have an agreed-upon ABI of how data is exchanged for
each function all.

And "sharing data structures" could simply mean that the caller pushes
data of a defined format (according to the ABI) onto the stack before
jumping to the callee.  I don't think it necessarily means that there
has to be an explicit shared memory region that both manipulate, or
anything like that.

According to the FAQ the only time this is not the case is when the main
program loads a plugin that is completely standalone, and makes a single
function call to start it running.  And even then they say that's
borderline.  But surely this is not relevant to your scenario because
you are talking about using the library as a real library, i.e. calling
multiple functions multiple times.

> There are no shared data structures.

So you are saying that every single function in the library returns void
and takes no arguments?  Because otherwise there *are* shared data
structures, in the form of the arguments and return values.

> 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.

But there is a big difference here - the difference between one process
and multiple processes.

> 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'?

No, you're not extending fopen(), but you are making a combined work
that is a derivative work of both your program and the library.  Anyway,
glibc is LGPL, which means that these kinds of derivative works that are
created by just calling the library's functions are allowed to remain
solely under the license of the program, regardless of the license of
the library.

However, if the library being called were GPL there would be no such
leeway and indeed just calling fopen() would require that the main
program be GPL or GPL-compatible.

I'd say at the end of the day it's pretty simple, if you combine A and B
in the same process or memory space, that's linking.  If you have A and
B execute as separate processes and communicate over IPC then that's not
linking.  In your case it looks like IPC or nothing, from a legal
standpoint.

Brian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]