Re: New 'as' port: GPL requirements?

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

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