Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
