Someone has brought to my attention a scenario that may help to illustrate what I've been talking about. So, I'm going to try few more letters of the alphabet.
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.) 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. Subtleties abound. So, I may very well be missing something. If so, I'm hoping that someone on this list can set me straight. -- Scott ______________________________ Scott K. Peterson Corporate Counsel Hewlett-Packard Company One Cambridge Center Cambridge, MA 02142 [EMAIL PROTECTED] -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
