Is inherited class a derivative work?
mbeck1 at compuserve.com
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/Dictionary.java which can
> be traced back to
> the original definition of java.util.Dictionary, but they are
> not necessarily
> 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.
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
> 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
b) the fact of using (or linking to) an "AbstractList" as the base class for
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 http://crynwr.com/cgi-bin/ezmlm-cgi?3
More information about the License-discuss