"Derivative Work" for Software Defined

[Andre Hedrick]

Okay now let me really rock the boat!

	"contributory infringement"
	"indirect infringement"

	also the NeXT objective C release

Now add in a few cannonballs of the high board.

Using new FPGA compilers to bind and lock execution content into hardware
devices know as CAM or Content Addressable Memory.  Since there is a lock
to extract or install the execution/runtime operations, and this is
physical hardware (simple terms may be firmware).  If one installs an
original work, its associated API for the work into this media, and
provides an open source (GPL or whatever) licensed driver to function with
the original work, does this null the "Derivative Work" argument?

If it does ::

How is this different than using the same open source (GPL or whatever)
licensed driver calling, the API of the original work, and linking the two
objects to create a new "combination" binary work?

The effect I am driving towards is the difference between mapping/function
hooking the original work in the CAM, an copying it into executable
memory.

original_work+api | linking | api+GPL_driver_wrapper == binary module
	closed			open

original_work+api | CAM | api+GPL_driver_wrapper == binary module
	hardware		open

Obvious the both cases the GPL_driver_wrapper is open_sourced, but the sum
of the latter is/appears to be GPL clean.

The former has the GPL_driver_wrapper open_sourced, but the sum results in
a different effect and is labled GPL_Tainted/Grey_zoned.

The operation and functional they are identical.
Politically they are not.
Legally who knows.

I see CAM products as a means to follow the hardware + open_sourced driver
guidelines.

Others will see it as the intent to do bad things to GPL.

How is the determination made the firmware/content in the CAM is different
than the BIOS/FW of any other HBA's (host bus adaptors).

If CAM + driver is legal for GPL, and it must be.
What is different with object + driver ?

Cheers,

Andre Hedrick
LAD Storage Consulting Group

IANAL, but a Storage Technologist.

On 6 Jan 2003, Ian Lance Taylor wrote:

> "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