Re: Linux and GPLv2

[Glenn Maynard <glenn@zewt.org>]

On Wed, Mar 23, 2005 at 06:41:58PM +0100, Måns Rullgård wrote:
> > Inline functions are certainly being included in the machine code that
> > comes out of the compiler, at least if they are called by the rest of
> > the compilation unit.
> 
> Irrelevant.  If someone chooses to implement a particular interface
> using an inline function, that should not impact the derivedness of
> code using the interface.

Obviously it doesn't impact whether *source code* using that interface is
a derivative work, but it certainly affects whether *binary code* is.  The
resulting binary from compiling against a header containing inline code
can contain substantial pieces of that code--almost verbatim, if it's inline
assembly--and that obviously makes the binary connected to the source.
(Whether it's a "derived work" or a "combined work" or an "aggregate" work or
something else, I'm not sure--it's clearly not a creative transformation--but
the result is certainly affected by the license of that code.)

> >>   extern char **__err_msgs;
> >>   #define perror(s) (fprintf(stderr,"%d:%s:%s\n",errno,__err_msgs[errno]))
> >
> >> Is "myfile.c" a derivative work on "errno.h"? The answer is NO.
> >
> > Of course. But myfile.o might have been if perror() were complex
> > enough to leave any room for expressive choice.
> 
> Again, irrelevant.  If your implementation puts things in macros,
> that's your problem.

Uh, what?

If my implementation puts things in macros, and you distribute my implementation
as part of your binaries as a result, that's *your* problem.  I don't even know
what you're trying to say here--"you put your copyrighted code in a header and
I copied it into my object file--that's your problem, not mine!" doesn't make
any sense at all.

-- 
Glenn Maynard