Is inherited class a derivative work?

[David Johnson]

On Sunday 21 October 2001 06:13 pm, Michael Beck wrote:
> > -----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".

I am not creating a copy of any "blueprint". Furthermore, I am not creating 
any objects, I am creating classes. Objects are created at runtime during 
execution (at least in C++). I am inheriting the class interface, not the 
class implementation.

When I inherit from a class, I take none of its design. To inherit class B 
from class A, I don't need to know class A's Big O notation. I don't need to 
now any of its design patterns. I don't need to know what any of its private 
members are. I don't need to know if its sort() method uses a shell sort or a 
quicksort. I don't even need to know if it stores its data members on the 
stack, heap, in a database, or distributed across a network. The design is 
completely opaque to me.

When I inherit, I copy nothing, let alone make any changes to the copy. If a 
third class C is inherited from my class B, and wants access to class A's 
interface, it can't get it from my class B, but only directly from the class 
A header file.

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

If my user has my application, but does not have your library, then my user 
does NOT have any copies of your classes that they can perceive, reproduce or 
otherwise communicate with. Of course, my application would be pretty useless 
without your library, but that's dependency, not derivation. My library would 
be equally useless if it didn't inherit anything from your library, but only 
made direct function calls.

I'm not sure what you mean by "Before the compilers were made smart enough to 
"understand" what you mean by inheriting". I used to use the old AT&T 1.0 
cfront C++ compiler. I've also used Smalltalk, the grandaddy of all OO 
languages. In both cases I never needed to cut and paste anything in order to 
inherit.

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

I'm copying nothing! Lab work time. On my website I have a program named 
"qbrew", which contains a class called "FixedSpinBox", which was inherited 
from Trolltech's Qt class QSpinBox. I will gladly shut up and send you a case 
of beer if you can show me a copy of Trolltech's QSpinBox in any of my source 
code, any intermediate object files, or in a executable binary that wasn't 
statically linked. (names of functions do not count, as they are the 
interface).

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

When I scan a picture and modify it I have *copied* the picture. When I 
inherit a class I copy nothing. Repeat, I copy nothing. My application does 
not contain a copy of the base class. That still resides in the library. If I 
give someone a copy of my application they will not be able to use it until 
they obtain an unmodified copy of your library.

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

I have made no changes to Fubar. All copies of Fubar on my harddrive have not 
been altered in any way by me. 

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

In inheritance I am STILL using the original class. The mechanics of C++ 
demands it. Your created object/class is the same as originally designed. If 
you designed it to use quicksort it will still use quicksort. If you designed 
it to store all members on the heap it will still store all members on the 
heap. The only way I can get around this is to NOT USE your class. 

Somehow I don't think you're talking about C++. I have a strong suspicion 
you're not talking about Java, Smalltalk or Python either. Just what OO 
language is it that must make a copy of a class in order to inherit? Sounds 
pretty inefficient to me.

-- 
David Johnson
___________________
http://www.usermode.org
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3