Is inherited class a derivative work?

[Chris Gray]

Michael Beck wrote:

> > -----Original Message-----
> > From: chris.gray at acunia.com [mailto:chris.gray at acunia.com]
> > Sent: Friday, October 19, 2001 08:54
>
> > If I write a class which extends java.util.Dictionary, then
> > whose implementation
> > of java.util.Dictionary am I adapting:
> >   - GNU Classpath's?
> >   - Kaffe's?
> >   - Sun's?
> >   - our (ACUNIA's) own?
> >   - a student in (say) Teheran whose JVM project I haven't
> > even heard of yet?
>
> I don't do Java, so maybe someone can help me here.
>

Hm, unfortunately I don't `do' C++ ...

>
> My understanding is that since java.util.Dictionary is an abstract class, then
> any of the above listed implementations must first inherited from it, and then
> override the abstract methods.
>

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.
And in any class library the source file java/util/Dictionary.java will have to
contain a list of method declarations which necessarily bear a strong resemblance
to what you can read on Sun's website, or for that matter in O'Reilly's
_Java in a Nutshell_ or any number of such books.  For example one might
reasonably expect to encounter the statement
    abstract public Object get(Object key) throws NullPointerException;
or something very similar (one could vary the order of `abstract' and `public',
or change the name of the parameter).

So there are elements of java/util/Dictionary.java which can be traced back to
the original definition of java.util.Dictionary, but they are not necessarily
derived
from any particular java/util/Dictionary.java.  Rather, they are based on the
method names, parameters and result types defined in the API.  Is every version
of java/util/Dictionary.java a work derived from the publiched API?  I would
argue not.

Actually java.util.Dictionary is not a particuarly good example: it is more
interesting
to look at a class such as java.util.AbstractList, in which not all methods are
abstract.
E.g. in any version of java/util/AbstractList.java you will find something rather
like
      public boolean add(Object o) throws UnsupportedOperationException,
          ClassCastException, IllegalArgumentException {
        add(size(),o);
        return true;
      }
Here there are more degrees of freedom, because the body of the method could
really do anything it liked provided it had the effect of appending an element to
the AbstractList: the API simply specifies that this method exists and that it has
a
certain effect. The methods size() and add(int index, Object o) are abstract in
AbstractList, so when the above code is execute it will actually invoke code of
some subclass to do most of its work.

Now let us look at java.util.Vector, which extends java.util.AbstractList (because

the API says so).  Any version of java/util/Vector.java will necessarily contain
implementations of size() and add(int index, Object o), because Vector is not
abstract (according to the API) and hence the buck stops here.  So when we call
add(o) on a Vector, the code we quoted above will end up invoking size() and
add(index, o) from this particular version of Vector.

So we have a class Vector which is, in the oo sense, derived from AbstractList,
and these two classes are in fact interdependent: AbstractList contains references

to whatever class extends it and implements its abstract methods, while Vector
depends on AbstractList to supply the add(o) method which is part of its API.
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.


>
> So if you extends the original java.util.Dictionary, you are creating just
> another implementation of it, one that has nothing to do with the listed above
> other implementations. However, if you extend any of the above classes, you are
> creating a derivative work from it, and have to follow its respective license.

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.

Regards

Chris Gray
VM Architect, ACUNIA


--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3