Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan,
--- Jan Schulz <jasc.usenet@gmx.de> 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
Reply to: