Is inherited class a derivative work?

[Michael Beck]

> -----Original Message-----
> From: lrosen at rosenlaw.com [mailto:lrosen at rosenlaw.com]
> Sent: Tuesday, October 16, 2001 19:05

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

Great, finally a lawyer here!

> While the FSF *may* be correct, I would expect a more
> thorough analysis
> of the situation from them before I accept their conclusion.

Hopefully, they will provide one.

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

I let FSF speak for themselves, but for me the flaw in this kind of comparison
is that you compare individual "traditional subroutines" to a class, which is an
entity "containing" such subroutines.

A correct comparison would be between a traditional library of subroutines and a
class.

Let's assume, I create a "Library X2", with an exact interface as "Library X"
(i.e. containing exact definition of all subroutines from "Library X"), copy the
implementation of each of them to "Library X2", provide new implementation for
two of those subroutines, and add two new subroutines.

What is then the "Library X2"? Is this a "derivative work", or is it a totally
new independent work? Can I claim copyright to the "Library X2" as my
independent work, or is this new "Library X2" a "derivative work" of "Library
X"?

IMHO, "Library X2" is nothing else than adaptation of "Library X", and as such,
a derivative work. If this is true, than a subclass is also a derivative work.

Just because OOP technology (via inheritance) made "copy & paste" of source code
of class methods irrelevant, it doesn't mean, IMHO, that you can ignore the fact
that by creating an inherited class your "intent" was to change/modify the base
class, and not using it "as is".

Michael

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