Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan,
--- Jan Schulz <jasc.usenet@gmx.de> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >> So when I write
> >> kaffe -bootclasspath xerces.jar .. -cp ... Main
> >> I can't do it, because its against the GPL/whetever License?
> >I'm not sure. Technically of course you can do it, but I don't think you can
> >distribute the resulting work. So when your bootclasspath script modifies
> the
> >boot class path, it effectively changes what classes link to each other. The
> >FSF has a very strong position on it: GPL propagates through class usage.
> See
> >the thread starting at
> >http://www.kaffe.org/pipermail/kaffe/2002-August/040251.html for some
>
> I've read that thread and as far as I understood it (my brain shuts
> down on this things... whoever made licenses viral should be sued for
> the braindamage in my head.), I haven't found such a thing.
>
> http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL states
> that such things happen when you use JNI with GPL code. Anyway, I'm
> neither a laywer, nor in any way experienced enough with such a
> question.
The ugly point is that almost every VM contains some native code that's being
linked to. You couldn't otherwise implement java.lang.Process, for example,
except on pure java operating systems.
> *IF* thats the case, then we have to treat kaffe almost completely
> apart from every other javaVM. As there are a lot of unfree libraries
> which can be pulled in via such nice things as Class.forName()
> (eclipse plugins, ant tasks for example), I'm not sure, if that is
> even controlable in any case.
I don't think you can or should prevent your users from using Class.forName
with kaffe. But as a distributor, you need to be careful what your shipped
binaries link to.
> If we have kaffe, ant can be run with it and the users then installs a
> non-free ant task and uses it. Who will be sued?
I am not a lawyer ;) But I doubt anyone can be sued, if the user doesn't
distribute the derived work, which she can't without violating the GPL, so it's
not your business ;) In any case, you can't control how your users violate the
licenses.
> How can the API be actually differently licensed than the sun
> one?
That's exactly the question that I think is a crucial argument against FSF's
argument: if you don't know you're linking to a GPLd implementation, you can't
be bound to it. But again, I think you need to consul debian-legal for answers
to those questions.
> >information on different interpretations. As I said, it's up to
> >debian-legal to figure out whether your bootclasspath scripts don;t
> >violate licenses, IANAL.
>
> If this whole is true, than we should fork this thread to debian-legal
> and ask there...
Yes. But as I don't think that you need bootclasspath, I don't think you need
to go there if you drop it ;)
> BTW, why is bootclasspath any different from classpath? As far as I
> understood it, the only difference is the position, where the libs are
> included (bootclasspath, internal, bootclasspath) and so which version
> is found when a app wants to get a instance of a class.
Bootclasspath is where the VM finds its runtime classes, ie. the crucial stuff
it needs to work. You break it, you break any application automatically.
Runtime classes sometimes don't use the published APIs, since it would be
impossible to implement all of java's class library with just the published
APIs. If you mix and match classes in there, you should know your VM inside out
or you will break things. I don't think such lowlevel hackery belongs into the
policy.
It's basically as if debian tried specifying a kernel module API for kernels
debian should run on. In order to be able to exchange binary modules between
kernel revisions and versions, with the goal to run the linux nvidia drivers on
windows.
> Other options?
Drop the bootclasspath proposal altogether. It creates problems for VMs that
don't support java 1.3 class loading features. There is a lot of good code that
doesn't need bootclasspath modifications to work. The nly good use of
bootclasspath is when you are implementing a java API and want to try some
updated code without regenerating the whole rt.jar.
If eclipse needs remixing the bootclasspath in order to work, then eclipse is
the exception, and its misbehaviour shouln't be endorsed by debian java
policies. You can't just assume that you can stuff xerces into the
BOOTCLASSPATH and all will be well.
Kaffe for example uses GNU JAXP, which doesn't use xerces, but uses Aelfred2
and libxml2 to do the work. So stuffing an updated xerces.jar into kaffe's
bootclasspath shouldn't have the effect you'd expect. Actually, GNU Classpath
now also uses GNU JAXP by default, so all Classpath based VMs will not depend
on xerces modifications in the long run, hopefully exposing the uglyness of
such 'clever' hacks.
cheers,
dalibor topic
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Reply to: