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:[EMAIL PROTECTED]] > Sent: Tuesday, January 07, 2003 2:21 AM > To: [EMAIL PROTECTED] > 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
