> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > 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