This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: New 'as' port: GPL requirements?
Some comments on the various replies below; I've rolled them all into
one to save multiple threads. Apologies if I've missed out anything
important.
First, it is of course dangerous to interpret a licence simply in terms
of the licence's FAQ, but in this case that seems to be necessary.
I think the crux of this issue is this statement in the FAQ:
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).
This clearly states that the issue of aggregation and combination is
open to interpretation, and there is no clear-cut answer. The position
of the FSF is given more clearly in the later statement (my square
brackets):
If the [GPL'ed] program dynamically links [proprietary] 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.
Note that the FSF position clearly states "makes function calls *to each
other*", and "... and share data structures". That's not the case here;
the GPL'ed code calls the proprietary code. DJ's comment is that "the
direction of the relationship is mostly irrelevant". I can't agree with
this: proprietary code that 'uses' GPL'ed code is clearly getting a free
ride that is outside the spirit of a 'free' licence; there is no such
free ride when GPL'ed code uses proprietary code. This may or may not
invalidate the licence, but my point is that there is no symmetry
between the two cases, so the direction must be relevant.
I think Simon additionally makes the point (though I can't find it now)
that even a library call implies a shared data structure, namely the
data that is passed backwards and forwards. However, again, I can't
agree with this; this is not the normal way to view the operation of a
simple library call. In any event, I can't modify the proprietary
library, so it is impossible to hack in shared data structures; all
communication must be via the existing API.
DJ Delorie wrote:
I think the key thing is this:
But if the semantics of the communication are intimate enough,
If you've modified the assembler so that it cannot function without
the proprietary code, you've created a proprietary assembler. In this
case, you're using a proprietary interface for which there is no free
replacement implementation, so IMHO the semantically tight coupling
between gas and this library is more significant than the mechanism of
the coupling wrt whether it's a derived work or a mere aggregate.
The interface itself will be 'free': it's only the far end of the
interface that isn't 'free'. It should be possible to build gas in such
a way that a specific architecture choice uses this interface or the
existing interface. You may argue that the specific names of the library
routines will make the interface non-generic and proprietary; in this
case, a simple 'free' abstraction layer could be added. I don't
understand how this could be seen as a semantically tight coupling: it
seems to me to be very loosely coupled; gas might request, for example,
the 16-bit data corresponding to "mov r1, r2".
Besides, you can't build a cross assembler that way ;-)
Well, that *is* worrying, or might be if I understood it... :)
On the issue of my 'fopen' example, I was aware of the system library
exception, so perhaps this was a bad choice. My point was that, in any
logical interpretation, someone who calls 'fopen' is not extending
'fopen', but is merely using its services (and this is precisely the
sort of argument that any court would look at when determining the issue
of aggregation vs. combination; note that the FSF believes that "this is
a legal question, which ultimately judges will decide"). So, in my
interpretation at least, GPL'ed code that dynamically uses the services
of a proprietary library does not constitute "a single program, which
must be treated as an extension of both the main program and the plug-ins."
Simon's point is:
Most likely you have created an extended version of fopen() that is
able to open a specific type of file and provides higher-level
functions to access the data contained within the file in a
structured manner.
Well, no, not in this case. I don't have any choice; I am calling
someone else's proprietary library which I cannot modify, short of
rewriting it.
One final point on the issue of aggregation vs. combination. The FSF
states that this interpretation will depend on the mechanism and the
semantics of the communication:
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).
The FSF agrees that fork/exec counts as aggregation, and believes that
dynamic linking counts as combination. The statement above presuambly
implies that pipes and RPCs fall between these two cases. However, in
the current case, simply calling a third-party proprietary library is
exactly equivalent to using a pipe or an RPC. I could even fork/exec for
each call to the underlying assembler. The only criteria for selecting
between these cases is performance; it has nothing to do with semantics.
Having said all this, I won't be using gas if there is any significant
(and justified) feeling that the resulting binary would not be GPL
compliant; I'll ask the FSF (is there any point doing this? am I likely
to get an answer any time soon, or at all? or should I try
gnu.misc.discuss?), and simply start with another assembler if I get a
negative answer. Luckily, there's no shortage of them... :)
One final point: you may be wondering why I'm bothering, and not porting
from scratch. The reason is that this processor is actually a family of
processors, which have arbitrary user-defined instructions. It would be
impossible to do a low level port for each variation. However, the HDL
development environment creates a raw assembler, which I'm hoping to use.
Thanks -
John