Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> wrote: > Hallo Dalibor, > > * Dalibor Topic wrote: > >> 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. > > So suns VM is breaking licenses?
No, as long as they don't link to GPLd code. But if debian distributed Sun's VM linked to a GPLd libc, *debian* *could* be breaking the GPL. I don't know about the implications of the GPL when all the offending code is doing is using some 'standard' API. Anyway, it doesn't matter in the context of our discussion. > >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. > > Would you mind writing up such questions and sending them to > debian-legal. I simple don't have the mind to deal with b******t. sorry, but the legal stuff has always been important to debian. It's your policy proposal, and you need to make sure it holds water, especially in the legal sense. If it 'just works', but due to lack of legal review puts Sun in a position to pull an SCO on debian users because of your bootclasspath update hack, then we all have a massive problem on our hands. It's better to be safe then sorry, even if it takes a little longer to flesh out the policy. > >Yes. But as I don't think that you need bootclasspath, I don't think you > need > >to go there if you drop it ;) > > I think it will be a problem with the XML Parsers. They have bugs and > as 1.4 becomes older, we will see programm depending on newer XML > pasers. Same will happen with otehr versions (think java 1.5 and so on) Hey, even the rest of Sun's java 1.4 (or any other free or non-free java implementation) is full of bugs. ;) So what? If people depend on some specific functionality (like bugfixes) then there is a perfectly sane way to do it in java, without modifying the VM or the class library. It's called user defined class loaders. Each class loader defines its own 'set' of classes, and *can* delegate to its parent if it needs to. So your XML parser problem could be solved by using a special XML-Parser-ClassLoader to load the updated version instead of the original one. That's much better than fiddling with bootclasspath. Nevermind that your XML parser problem mihgt also be solveable using XML parser selection techniques as defined in the API, see XMLReaderFactory for more information. 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]
