Is inherited class a derivative work?

Michael Beck mbeck1 at
Mon Oct 22 01:18:16 UTC 2001

> -----Original Message-----
> From: rdixon84 at [mailto:rdixon84 at]
> Sent: Wednesday, October 17, 2001 21:43
> The discussion on this topic has been very interesting. I am
> unsure who posted the comment about the lawyers at FSF, but
> if that person could obtain clearance to post the complete
> explanation on why FSF has taken the position that the use of
> inheritance constitutes the creation of a derivative work,
> this might be extremely helpful for our discussion.

It was me, and I will try to get a clearance.

> If this
> is a reliable legal position, it might discourage use of the
> GNU GPL. Hence, this is a rather important matter.

I assume, you meant GNU LGPL, correct?

> My thoughts on the matter are similar to what seems to be the
> majority view of the posts on this list, which is the FSF
> opinion seems oddly incorrect. I say odd because it seems
> inconsistent, as a matter of open source philosophy, to argue
> that the GPL permits a copyright holder to grab copyright
> interest in a modification that often times (if not, almost
> always) would not be within the scope of the Copyright Act
> (in the U.S.).

Can you be more specific on your position? Are there any cases suggesting just
this? If we agree that "class" is a design blueprint for an object, why should
it be any different that "architectural design" or "chip design"? Both are
within the scope of the Copyright Act (in the U.S.).

> First, I think it is important to be mindful of the fact that
> inheritance is intended to support the reusability of code,
> not thwart that effort.

As long as there is no infringement of the copyright. Otherwise one could
conclude that CD-ROM burners are here to make copies of copyrighted CD and sell

> If that principle is your starting
> point, one could argue that there is an implied license to
> create derived classes that contain objects inherited from
> another.

Inheritance mechanism is given to you by compiler vendors, not by the class
author, therefore such a conclusion would be very questionable. Otherwise,
people could argue that by releasing a software on CD-ROM, the vendor gives you
the right to make a copies of it, since you have a CD-burner on your PC.

> Consequently, one could not say that all inheritance
> (if any, for that matter) results in the creation of a
> derivative work.

Agreed. Exception would be an "abstract class", or overriding abstract methods
in a regular class, since the author leaves it explicitly to the user to create
implementation for the abstract methods.

> In addition, to implied license to access the inheritance
> feature of some programming languages, I think the Copyright
> Act's definition of "derivative work" as well as section
> 117(a) mitigate against a per se rule that the creation of a
> derived  class results in a derivative work subject to the
> GPL.  Larry and one other poster has already addressed the
> derivative work definition in the Copyright Act. As for
> section 117(a), my understanding is that to the extent that
> this issue of inheritance can be viewed similarly to the API
> issue, the resulting "modification" or "adaptation" would be
> outside the scope of copyright protection entirely since the
> Copyright act authorizes adaptations that are created as an
> essential step in the utilization of a computer program. As a
> practical matter, I suspect that section 117(a) applies to
> nearly all dynamic calls to API, and, depending upon the
> circumstances, would apply to some static linking and object
> inheritance.

I am surprised why people bring all the time the API linking as their argument.

Class is a design blueprint for an object, and IMHO should be treated as such,
i.e. as a "design entity", similarly to "architectural design" or "chip design".
When you derive a class, you are creating a copy of the original class. When you
make changes to the new class, you are creating a "derivative work", the same
way as you would do it by making changes to a copy of book, copy of a picture,
copy of a house design, or a copy of a chip design. You don't change the
original, but you still are creating a derivative work. How the mechanism works
to create a derived class should be really irrelevant to the discussion, because
Copyright Law states explicitly that it doesn't care about it in its definition
of copies: ""by any method now known or later developed". When you derive a
class (before making any modifications to it), you have created a "material
object", "from which the work can be perceived, reproduced, or otherwise
communicated, either directly or with the aid of a machine or device". In our
case, a compiler is the helping device.


license-discuss archive is at

More information about the License-discuss mailing list