classpath
[Top][All Lists]
Advanced

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

Re: Java tools


From: Per Bothner
Subject: Re: Java tools
Date: 10 Jul 2001 09:35:03 -0700
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor)

"Nic Ferrier" <address@hidden> writes:

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

It is convenient if related/dependent projects can share a
cvs repository.  They could still be separate "projects",
but each project does add its own overhead.

>    I'd prefer to see us simply expand the mandate of, say, 
>    Classpath and then just put more things in it.
> 
> I'd be happy with that too, perhaps Classpath would need a seperate
> CVS module for each tool but I don't see a major organizational
> problem either way.
> 
> The only trouble with Classpath is that it requires (c) assignment
> and the 'exception' licence. 
> 
> A large part of this problem could be obviated if the Classpath
> administrators choose to accept tools under non-exception licences,
> eg: plain GPL or LGPL.

GCC and related projects has traditionally distinguished "host tools"
vs "target libraries".  The latter may run on embedded systems, and
may be linked in with user (customer) applications, and so need the
exception.  The host tools are not linked with application code, and
they don't run on embedded systems, so traditionally have been GPL.
Sometimes code falls into both categories.  The libiberty library
is an example.  A regex library or getopt are other possible examples.
The GCC project emcompasses both kinds of code; classpath focuses on
"target libraries".
-- 
        --Per Bothner
address@hidden   http://www.bothner.com/per/



reply via email to

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