classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I wish to help


From: Brian Jones
Subject: Re: I wish to help
Date: 31 Oct 2002 20:08:13 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Mark Wielaard <address@hidden> writes:

> On Wed, 2002-10-30 at 01:23, Brian Jones wrote:
> > Mark Wielaard <address@hidden> writes:
> > 
> > > Chris Gray said that they wanted to relicense it if needed but I
> > > don't know if they are actually going to donate it to the FSF for
> > > inclusion in the GNU Classpath project. Note however that Rudolph is
> > > not a peer based implementation.
> > 
> > I'm trying to get something definite from Chris right now.  
> 
> Thanks for following up on that! It would be very nice to work more
> closely with the Wonka people.
> 
> > Opinions?
> 
> With respect to licensing/copyright it would be best IMHO to get
> everything assigned to the FSF as we have done with all other
> contributors.

That is not a possibility at this time.  You can imagine that they
would like fixes assigned back to them so they can use them under any
license they choose which also won't sit well with some of our
contributors.

> Also take into account that Wonka contains only the java.awt, 
> java.awt.event and java.awt.image packages. We have that and
> java.awt.color, java.awt.datatransfer, java.awt.dnd, java.awt.dnd.peer,
> java.awt.font, java.awt.geom, java.awt.im, java.awt.im.spi,
> java.awt.image.renderable, java.awt.peer and java.awt.print. The
> important advantage that Rudolph has is of course that the code that
> they have actually works! I haven't checked on class level btw.
> (More info can be found on http://wonka.acunia.com/javadoc-0.9.3/)
> 
> A small thing, but important to me, is the fact that we have much better
> documentation (apidoc) then the Wonka implementation. I know that RMS
> finds it important to have good documentation for GNU programs so you
> might want to bring up this point (certainly because it is a complicated
> matter since the documentation is embedded into the source files).

So I'm pretty much of the opinion that Classpath's AWT just needs a
little TLC from someone dedicated to it for a while to make it
useable.  Having JVMs without major threading issues will aid this
development.  This is why I would personally develop the peers against
Sun's VM, if I had the time to devote to it.

Acunia has almost officially made this offer, but because it would be
unlikely for me to get contributors to assign their copyright on
changes back to this corporation that may not be so benevolent in the
future (no guarantees) I'm inclined to believe we must continue
working on the current implementation.

It remains a possibility that if Acunia's current AWT is dual licensed
in the manner Chris described that parts of this work could be
integrated as an external library to provide optional functionality in
Classpath's AWT.  So inspection of their implementation would be
possible but no verbatim copying allowed into _our_ classes.  We could
create a separate directory to place their library with an appropriate
README indicating this is not part of Classpath and when we compile we
could link this library without trouble.  I hope this explains what is
meant by external library in reference to FSF projects.

Brian
-- 
Brian Jones <address@hidden>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]