This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: javax.naming work (Classpath vs ClasspathX)
- To: java at gcc dot gnu dot org
- Subject: Re: javax.naming work (Classpath vs ClasspathX)
- From: Nic Ferrier <nferrier at tf1 dot tapsellferrier dot co dot uk>
- Date: Sat, 20 Oct 2001 00:12:45 +0100
Tom (?) said:
> For one thing dealing with ClasspathX means another licensing
> discussion. I'm really burned out on those.
Mark said:
>There is some communication between the projects. And the ClasspathX
>people seem to agree that using the Classpath/libgcj
>GPL+linking-exception license is OK.
I am the maintanier of ClasspathX. I've talked with the gcj people
before about them handing the jndi stuff to ClasspathX (where it would
seem to make the most sense).
We do NOT have an issue with licencing gpl+exception. In fact, we'd
like to see that as the default licence for java code (we think it
makes more sense for OO languages).
>But I know what you are talking about. It is to bad that
>there is not a clear GNU standpoint that can be shared by all the GNU
>projects working on java stuff. And the copyright of the ClasspathX
>project is not assigned to one party so getting to change it later
>will be a pain.
Why is (c) an issue? The FSF has (c) assigned to it to allow the FSF
to fight legal battles.
You can submit code to ClasspathX and assign (c) if you want (we
already have a (c) assigned servlet API). On the other hand, we don't
REQUIRE that you assign (c) if you don't want to.
If you work on code where we believe (c) needs to be assigned, then
you must assign (c).
Therefore if the gcj project wished to submit the JNDI stuff it could
be done by under ClasspathX and (c) assigned to the FSF and licenced
under the GPL+exception.
Nic Ferrier