"Derivative Work" for Software Defined

[PETERSON,SCOTT K (HP-USA,ex1)]

Ian --

"But it's clear that G+H is covered by the GPL regardless of the status of
H."

This is exactly what I've been getting at.


"The only issue is whether G+H is a derived work of G, and that seems
obvious."

I think there is an additional issue, and one for which the resolution is
not necessarily obvious: to what sort of combinations of G and H does the
condition in section 2 of the GPL extend? In other words, what sorts of
things are G+Hs rather than just G aggregated with H?

-- Scott
______________________________
Scott K. Peterson
Corporate Counsel
Hewlett-Packard Company
One Cambridge Center
Cambridge, MA 02142
phone: 617-551-7612
mobile: 978-764-8615
scott.k.peterson at hp.com


-----Original Message-----
From: Ian Lance Taylor [mailto:ian at airs.com]
Sent: Wednesday, January 15, 2003 12:54 PM
To: PETERSON,SCOTT K (HP-USA,ex1)
Cc: license-discuss at opensource.org
Subject: Re: "Derivative Work" for Software Defined


"PETERSON,SCOTT K \(HP-USA,ex1\)" <scott.k.peterson at hp.com> writes:

> Assume that there is a standard API defined in a spec.
> One author writes an application G that conforms to that spec (using the
> API; I think of this as sitting on top of the API) and offers this under
the
> GPL. 
> A second author writes a library H that conforms to that spec
(implementing
> the API; I think of this as sitting under the API) and offers this under a
> GPL-incompatible license. 
> Assume that G and H were wholly unaware of each other's work. Thus, G is
not
> a derivative work of H and H is not a derivative work of G.
> Assume that someone statically links object modules compiled from G and
> object modules compiled from H into a single executable file (call this
> executable file G+H).
> 
> I believe that there is wide agreement that the GPL is interpreted such
that
> the author of G has not given permission for distribution of that single
> executable file. (I also believe there is less widespread agreement on the
> alternative where the linking occurs at runtime.)

Well, more precisely, distribution of the executable generated from
G+H must be accompanied by the source code of G and H, or by an offer
to provide that source code to any caller.

> H is not a derivative work of G. So, how does one get to this widely
agreed
> result? I believe that that interpretation assumes that G+H is a "work
based
> on the Program". So, it looks to me like it is generally agreed that the
GPL
> does indeed concern itself with whether G and H are parts of something
> larger (not necessarily every larger thing, but at least some sorts of
> larger things). Thus, it seems that stopping analysis at the point of
> determining that H is not a derivative of G is failing to complete the
> analysis needed to judge compliance with the GPL. 

The GPL covers G+H because G is under the GPL, and G+H is a derived
work of G.

I see no issue here of whether G and H are parts of something larger.
I see no issue of whether H is a derived work of G.  The only issue is
whether G+H is a derived work of G, and that seems obvious.

You don't even have to think about the legal status of H to determine
that G+H is covered by the GPL.  Thinking about the legal status of H
may cause you to believe that G+H may not be covered by the GPL--e.g.,
H may be under a proprietary license of some sort--which would imply
that distribution of G+H is forbidden.  But it's clear that G+H is
covered by the GPL regardless of the status of H.

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