Is inherited class a derivative work?
david at usermode.org
Mon Oct 22 07:10:01 UTC 2001
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
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
> > 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
> > 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.
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
More information about the License-discuss