Re: Java tools

[Tom Tromey]

>>>>> "Nic" == Nic Ferrier <address@hidden> writes:

>>>> Tom Tromey <address@hidden> 10-Jul-01 4:29:31 PM >>>
Tom>    I don't have a real objection.  But I think that adding 
Tom>    a new project every time does make things more difficult.

Nic> In what way?

A new project means new mailing lists to track, a new cvs repository
to remember, etc.  It also means that if I want to build everything
the build is more complex.  Keeping it all in sync is harder -- a
unified tree is easier to keep working, as every developer can build
it frequently.

Nic> The only trouble with Classpath is that it requires (c)
Nic> assignment and the 'exception' licence.

Actually only the core parts of Classpath require the odd license.
For host tools like javadoc, I'm sure any license is acceptable.

The goal for libgcj is that it be usable on embedded systems (which is
actually a pretty big range; don't necessarily think "small").  This
means that we would like the libraries and such to have the special
GPL+exception license.  This ensures that embedded developers can
continue to use gcj and libgcj.

For a host-side tool like javadoc, something like the GPL is great.
For instance, gcj is GPL.

Now, should javax.* be GPL+exception?  Or new libraries?  Well,
obviously we would prefer that.  The possibility exists that, if we
need one of these libraries, then we would have to rewrite it if the
license is different.  And we've decided in the past to exclude other
libraries (AWT) from libgcj on this basis.

Obviously the licensing and potential for duplication of effort is our
problem.  If we have to do it, then we have to do it.  It would be
less efficient, and of course we'd rather share efforts, but whether
we can also depends on your goals and requirements.  Classpath already
has two licenses in it, and I personally don't want to be in the
position of saying "let's reject java.foo from Classpath because it is
LGPL and not GPL+exception".  For one thing RMS would reject this.

Tom