Is inherited class a derivative work?

Michael Beck mbeck1 at
Wed Oct 24 09:54:43 UTC 2001

> -----Original Message-----
> From: Chris Gray
> Sent: Monday, October 22, 2001 05:21

Chris, thanks for your email. That was a very good reading.

> Yes, java.util.Dictionary is abstract (and contains only
> abstract methods), so
> any non-abstract class derived from it will need to override
> all its methods.
> So there are elements of java/util/ which can
> be traced back to
> the original definition of java.util.Dictionary, but they are
> not necessarily
> derived
> from any particular java/util/  Rather, they
> are based on the
> method names, parameters and result types defined in the API.
>  Is every version
> of java/util/ a work derived from the
> publiched API?  I would argue not.

Since java.util.Dictionary is an abstract class, and you override abstract
methods, I agree with you. By having abstract methods in a class, IMHO the
author gives the user implicitly the right to create a subclass and override the
abstract methods.

> Now the interesting thing is: if I were to replace the
> AbstractList in our class
> libraries with the one from Classpath or Kaffe or our
> hypothetical unpublished
> work, it should work just fine.  It should work because we
> all adhered to the same
> specification, not because something of ours is derived (in a
> copyright sense)
> from something of theirs or vice versa.

If I understood you correctly, I would see two issues here:

a) the fact of creating the implementation for  "AbstractList" according to its
class interface
b) the fact of using (or linking to) an "AbstractList"  as the base class for
your java.util.Vector

Ad. a) My understanding is (and please correct me if I am wrong) that Kaffe or
ClassPath projects are creating a "cleanroom" implementations of
java.util.AbstractList. Because they only "use" the API, but provide their
independent implementation, their java.util.AbstractList is OK.

Ad. b) My guess would be that you could use any class that gives you the right
to derive classes from it. If Kaffe or ClassPath give you the right, then you
can use anyone of them as the base class for java.util.Vector.

> I don't think I need to refer to the `original'
> java.util.Dictionary, wherever
> that may
> be found.  I just need a list of the methods which
> java.util.Dictionary must
> export  to the outside world.

If you are "using" it  only, I agree with you. This is only issue of "end user"
using a "compatible class implementation" in a class.
The open issue is if the inherited class is a derivative work. If yes, then
probably you could substitute the original class only with those concrete
classes that allow you to create derived classes. Of course, IANAL...


license-discuss archive is at

More information about the License-discuss mailing list