"Derivative Work" for Software Defined

[David Johnson]

On Monday 06 January 2003 11:05 pm, Ian Lance Taylor wrote:

> It seems to me that you are drawing a distinct line between things
> which are technically very similar.  You may well be right to do so.
> But I'm not sure why you are so confident.

I see three broad "classes" of dynamic and runtime linkage.

The first is an ordinary application linking to an ordinary library. In the 
absence of non-trivial macros and inlines, the application is not a 
derivative work IMO.

The second is the case of a kernel module, plugin, or similar. Regardless of 
the existance of an "official" API, derivation is doubtful if the underlying 
kernel, application or library is used in it's normal and customary manner. 
There's a bit more gray here though.

The third is a module or plugin that requires a derivation in order to work. 
Such a derivation could be a wrapper, embedded hooks in the application, etc. 
The non-GPL module would then be calling a GPL derivation, pretending it's 
really case one or two above. This is not allowed, IMO, as it is doing an 
end-run around the licensing.

And then you have the whole issue of intent and the stickiness it brings. I 
would be in much firmer ground if I created a driver for some new hardware 
than if I created a module to bypass a major subsystem.

> For example, with a very small modification to gcc (say, ten lines of
> code), I could make it support loadable compiler passes.  I am clearly
> permitted to publish that modification under the terms of the GPL.
> Following your argument, I could then distribute binary compiler
> passes for gcc.  Those compiler passes would no more be derivative
> works of gcc than loadable modules are derivative works of Linux.

This would be case three above. Not allowed (or at least in a very dark grey 
area). This was the case with NeXT's Objective C compiler, I believe. In 
order to get such a scheme to work, gcc has to be modified to support it.

> My point is that if you are correct that binary loadable modules are
> clearly not derivative works, then it is clearly OK to produce binary
> only pieces of a wide variety of GPL programs.

Mere linkage by itself is not demonstrative of derivation. I think this was an 
underlying assumption that Larry was making. This is in contrast to the 
widely held belief among GPL advocates that dynamic linkage always causes 
derivations.

> For what it's worth, I'm pretty sure the FSF does not think the line
> is there--I'm pretty sure they think a binary gcc compiler pass would
> count as a derivative work.

Their opinion has great bearing on their behavior with regards to the law, but 
little bearing on the law itself. Yes, they have more lawyers on their side 
than there are on mine. But somehow I suspect those lawyers are slightly 
biased ;-)

In the case of binary compiler passes, they are probably correct. But in the 
case of dynamic linkage itself I believe they are incorrect. In my 
non-Harvard and layman opinion...

-- 
David Johnson
___________________
http://www.usermode.org
pgp public key on website
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3