Is inherited class a derivative work?

Michael Beck mbeck1 at compuserve.com
Mon Oct 22 01:13:05 UTC 2001


> -----Original Message-----
> From: david at usermode.org [mailto:david at usermode.org]
> Sent: Thursday, October 18, 2001 22:24

> Deriving a new class is equivalent to linking to an API. No
> question about
> it. Just examine the mechanism. If anything, inheritance creates an
> additional level of indirection which should make inheritance
> *less* likely to cause derivation.

Absolutely not. A Class is a blueprint for creating an object. By inheriting,
you create first a copy of the blueprint. By making changes to this copy, you
are creating a "derivative work".

It doesn't matter, what mechanism you have used. Your intent is clear, and the
result is also clear. Regarding mechanism, the Copyright is pretty clear that it
doesn't really care about it, by stating: "by any method now known or later
developed":

----------------
"Copies" are material objects, other than phonorecords, in which a work is fixed
by any method now known or later developed, and from which the work can be
perceived, reproduced, or otherwise communicated, either directly or with the
aid of a machine or device. The term "copies" includes the material object,
other than a phonorecord, in which the
work is first fixed.
----------------

Before the compilers were made smart enough to "understand" what you mean by
inheriting, you would have to copy & paste all the code. So the above paragraph
states for me that you "are" creating a copy of my class (as a blueprint for an
object), because with the help of a compiler my original class "can be
perceived, reproduced, or otherwise communicated".

> One does not inherit the implementation of the class, only
> its interface. And
> the interface is not modified. I cannot modify existing
> elements except by
> actually modifying the source code in the base class implementation.

You are modifying by making a copy (i.e. inheritance), and then changing/adding
elements. The blueprint has been changed, and the created object from this
blueprint is different from the one created from the original class. If this is
not a derivative work, then what is?

> The base class is in no way modified. All I have done is to
> create a *new*
> interface. Here is an example of inheritance:
>
> class Snafu : public Fubar {
> public:
>     int mogrify(int t);
> private:
>     int n;
> };
>
> Snafu in no manner modifies class Fubar. Snafu is a wholly
> new and distinct class. Fubar is unchanged.

This is the same as scanning a picture, make changes to it, and claiming that
since the original picture has not been changed, the new one is not a
"derivative work".

You have changed the "blueprint", and the resulting object created by Snafu is
different from the one created by Fubar. Please remember, I gave you the right
to "use" the Fubar "blueprint" as is, and I didn't give you any right to make
any changes to it. This is similar to "architectural design" or "chip design".

> > - you are adapting this class to be or do something
> > different than it was designed to be or do.
>
> True, but it has little bearing on the issue of derivation.

It has absolutely a bearing.

> Instead of using
> inheritance to adapt the class, I could create a wrapper
> class with no
> functional difference. The second version of Snafu above is a
> wrapper, but
> it does exactly the same thing as the first version.

While the end result is similar, in the "composition" case you are "using" the
original class, and the created object is the same as originally designed. In
inheritance, it's not the case.

Michael

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



More information about the License-discuss mailing list