Re: New 'as' port: GPL requirements?

[DJ Delorie <dj at redhat dot com>]

> Note that the FSF position clearly states "makes function calls *to each 
> other*", and "... and share data structures". That's not the case here; 

Just because your program doesn't match one particular example doesn't
mean that the GPL doesn't apply.  It just means that example doesn't
apply.

> DJ's comment is that "the direction of the relationship is mostly
> irrelevant".

If you are producing an assembler that requires two components,
neither of which is part of the OS, and your assembler won't run with
either component missing, does it matter which component is which?

> 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 spirit here; there is only law.  If proprietary code is
derived from GPL'd code, it's a copyright violation.  Otherwise, it's
not.

In your case, you're creating a new work that (IMHO) is derived from
both GPL'd code (gas) and proprietary code (the inline assembler).  I
say "derived" because the whole doesn't function without its parts.
The fact that one of the parts functions independently is irrelevent;
the license is for the whole work; the parts already have individual
licenses.

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

There is symmetry.  No work derived from both GPL and proprietary
components may be legally distributed.  A proprietary application
which uses a GPL library is no different than a GPL application using
a proprietary library.

> The interface itself will be 'free': it's only the far end of the 
> interface that isn't 'free'.

Now you're past the GPL legalities and into the FSF's stewardships.
As a binutils maintainer, I would reject patches for any such
interface specifically designed to allow the use of proprietary code
where no free alternative exists.  The purpose of the GNU project is
to make free alternatives available, not to make it easier to use
proprietary software.

> I don't understand how this could be seen as a semantically tight
> coupling:

Right, and I could write a gcc backend that uses background daemons on
thousands of windows machines around the world to do optimizations,
but I didn't.  And you didn't write that kind of interface.  Until you
do, we can only discuss the interface changes you're proposing for
gas.  It is an interface specifically designed to integrate a
proprietary assembler into gas.

> >> Besides, you can't build a cross assembler that way ;-)
> 
> Well, that *is* worrying, or might be if I understood it... :)

Does your inline assembler run on an AMD linux box?  On an IRIX box?
How can I write programs for your machine using only my machine?  One
major benefit of binutils is that you can build an assembler that runs
on, say, i686-pc-linux-gnu yet produces code for sparc-sun-solaris2.8.

> My point was that, in any logical interpretation, someone who calls
> 'fopen' is not extending 'fopen',

The legal term is "derive" not "extend".  You *are* deriving your work
from the library.  That's why the GPL has explicit exceptions for
libraries that comes with the OS; otherwise you'd never be able to run
GPL'd applications on a non-GPL'd OS.

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

Until a judge decides, our opinions are all we have.

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

So rewrite it.  That's what everyone else does when they port gas to
their platforms.

> The FSF agrees that fork/exec counts as aggregation,

No, that's not what they said.  They said that normal fork/exec
between otherwise independent programs doesn't cause them to become
one work.  That doesn't preclude other reasons why the two may be
considered one work.  That's the "if the semantics..." part.

Read the "I'd like to incorporate GPL-covered software in my
proprietary system." section:

  "The substantive part is this: if the two programs are combined so
   that they become effectively two parts of one program, then you
   can't treat them as two separate programs."

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

In this case, the proper procedure is to teach gcc how to use those
assemblers directly, and not use gas at all.