Is inherited class a derivative work?

[Lawrence E. Rosen]

I've been watching the exchange on this topic with interest.  

The mere statement from the FSF that "inheritance is considered
modifying the library, so subclasses of library classes must be released
under the LGPL" is of little legal significance or value.  I, for one,
don't think it is at all obvious that "inheritance" falls under the
legal definition of a derivative work:

   A "derivative work" is a work based upon one or more preexisting
work,
   such as a translation, musical arrangment, dramatization,
fictionalization,
   motion picture version, sound recording, art reproduction,
abridgment,
   condensation, or any other form in which a work may be recast,
   transformed, or adapted.  A work consisting of editorial revisions,
   annotations, elaborations, or other modifications which, as a whole,
   represent an original work of authorship, is a "derivative work."
   17 USC § 101.  

While the FSF *may* be correct, I would expect a more thorough analysis
of the situation from them before I accept their conclusion.  In
particular, how does inheritance differ in a substantive and legally
significant way from traditional subroutine linkage which, as many of us
believe, does *not* create a derivative work at least the context of
dynamic linking?

The person who submitted the question should direct it to his/her own
attorney if he/she wants to make sure that LGPL license conditions are
met.  

/Larry Rosen

> -----Original Message-----
> From: mbeck1 at compuserve.com [mailto:mbeck1 at compuserve.com] 
> Sent: Tuesday, October 16, 2001 3:23 PM
> To: license-discuss at opensource.org
> Subject: RE: Is inherited class a derivative work?
> 
> 
> > -----Original Message-----
> > From: david at usermode.org [mailto:david at usermode.org]
> > Sent: Tuesday, October 16, 2001 00:19
> > To: mbeck1 at compuserve.com; license-discuss at opensource.org
> > Subject: Re: Is inherited class a derivative work?
> >
> 
> > That said, inherited classes are not derivative of the base
> > classes. There is
> > a dependency, but it is a dependency upon the *interface* and
> > not the actual
> > code. For example, you could subclass iostream, but
> > then how can you
> > tell whose C++ Standard Library it was derived from? You can't.
> 
> OK, but what if you know exactly from which library you have 
> subclassed the
> particular class, and it's your conscious decision to do so? 
> The issue is that
> when I release something under OpenSource, I want to make 
> sure that it will be
> "used as is", and if there is any derivative work, it will benefit the
> community, i.e. it will be published. The user, by using the 
> library, agrees to
> the governing license, and thus should be obligated to publish all
> changes/modifications. Creating a wrapper, or using the class 
> in a composite
> class would be considered as "use" and not as "derivative 
> work". I would also
> see overriding abstract methods as "use", because the author, 
> by defining them
> abstract, left the implementation to the user. But making any other
> changes/adaptation to "library classes", direct via code 
> changes or indirect via
> inheritance, should be considered as derivative work and 
> published back to the
> community.
> 
> > (Remember that the FSF's interpretation of the GPL considers
> > dynamic linkage
> > to be derivation, so pay attention if you subclass anything
> > under the GPL)
> 
> I just got a response from FSF lawyers stating that 
> "inheritance is considered
> modifying the library" (see below). My question was related 
> to releasing code
> under LGPL and wanted to make sure that I've interpreted correctly the
> difference between "work based on a library" and "work using 
> a library", and
> according to FSF, inheritance falls under "work based on a 
> library" and as such
> should be released under LGPL.
> 
> Currently we have MPL, but some of our code donors were 
> concerned that it covers
> only modifications done "direct changes to the code", but 
> provides no copyright
> protection for OOP code, as it doesn't cover inheritance. It 
> seems that LGPL is
> better suited for this purpose.
> 
> Michael
> 
> 
> > -----Original Message-----
> > From: novalis at kafka.i-site.com [mailto:novalis at kafka.i-site.com]
> > On Behalf Of Free Software Foundation
> > Sent: Tuesday, October 16, 2001 15:31
> > To: Michael Beck
> > Cc: Free Software Foundation
> > Subject: RE: LGPL and inheritance
> 
> > Yes, inheritance is considered modifying the library, so
> > subclasses of library classes
> > must be released under the LGPL.  This is exactly what you want.
> >
> >
> > --
> > -David "Novalis" Turner,
> > Licensing Question Volunteer,
> > Free Software Foundation
> 
> --
> 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