"Derivative Work" for Software Defined

[Ian Lance Taylor]

"Lawrence E. Rosen" <lrosen at rosenlaw.com> writes:

> So what if "most of the Linux kernel is loadable modules?"  Probably
> Linux is not a derivative work of those loadable modules, but instead a
> compilation or collective work.  The GPL doesn't require you to publish
> the source code of either of those types of work.
> 
> But there are other reasons to conclude that there is nothing improper
> about reading the Linux source code to determine how to make programs
> work with Linux.  At least until the DMCA muddied the waters, the courts
> held that it was fair use to reverse engineer software to determine how
> it works ("in order to gain an understanding of the unprotected
> functional elements of the program").  Sega v. Accolade (9th Cir. 1992)
> 997 F.2d 1510.  Why should looking at *published* source code for that
> same purpose be any different?  There is no copyright infringement if
> one doesn't copy or create derivative works of the protected expressive
> elements of a program. 
> 
> So what if the Linux APIs change constantly?  That only means that
> relying on the source code rather than a published API is a risky
> endeavor.  
> 
> Once again, I will argue, one doesn't create a derivative work merely by
> figuring out how to make two independently-written programs work
> together.  If you're trying to convince people that creating a loadable
> module for Linux is creating a derivative work, you should come up with
> a better justification for that opinion than what's been proffered here
> so far.  
> 
> That's about as clear an answer as I have, subject to anyone citing a
> clearer statement on the subject by a federal court.

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.

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 could similarly be done for many other GPL programs, such as
Emacs or the GIMP.

In fact, this has actually been done in the Linux distribution of the
binutils, to support demangler libraries distributed only in binary
form.  When last I checked, the patches required had not been accepted
into the main GNU distribution.  When I was the binutils maintainer, I
didn't think it was worth fighting over (the binary demangler library
was for a proprietary compiler which was disappearing anyhow).  But
it's a real example of somebody who actually did what I suggest above.

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.

My feeling is that the issue is muddier than you are suggesting.
Presumably there is a line somewhere between what is and what is not a
derivative work.  But I don't see any obvious reason that the line is
at loadable modules.

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.


Obviously, none of this is meant to suggest that binary modules are
not OK for Linux.  They are OK, because Linus has made it clear that
they are OK.  But it's not clear to me that they would be OK if Linus
had not made that statement.

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