"Derivative Work" for Software Defined

[Don Jarrell]

Since I am new, I would normally lurk for a while,
but I am familiar with this issue in some historical,
practical arguments.  By way of introduction, I should
clarify that I am neither hands-on programmer (now) nor
attorney, but I have done a lot of licensing,
development, etc in the past. And, I am now consulting
software companies on licensing/SEP, especially on the
OS-proprietary boundary.

The issue of an API in the context of a derivative
work has been argued successfully along the lines of
a non-digital analogy.  While those often break down,
I believe this one may be apt.  Consider taking a
cast of a three-dimensional object.  One does not
have an identical-looking thing, but more like a
mirror image, which still duplicates the "curves",
or interface of the original and the cast.  Applied
to the API context, an API which "fits" a GPL-licensed
interface is arguable derived from the expression of
that interface.  From this basis, I still advise
clients to use the abstraction layer approach.

Cheers.     dj


> -----Original Message-----
> From: David Johnson [mailto:david at usermode.org]
> Sent: Tuesday, January 07, 2003 2:21 AM
> To: license-discuss at opensource.org
> Subject: Re: "Derivative Work" for Software Defined
>
>
> 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

--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3