Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
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?
Would you mind doing a some nicely written up mail to be send to
debian-legal?
>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 I get into trouble with my proposed 'getclasspath' (will probably
named java-config or so in the end), I wont package it and I will stop
proposing any changes in to teh java policy. I will also make a test
for any gpl'ed JVM in the eclipse startscript and will not use them.
>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.
And can I be sued, if I build a startscript, which will result in
certain cases in a GPL'ed JVM being used with GPL incompatible code?
>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.
>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)
>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.
I wouldn't use this argument with rt.jar and such like, only with the
JCP APIs (XML and so on).
>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.
Yes, and thats the case with XMP apis and implementations. I don'z
mean to use it to replace the rt.jar.
Anyway, I will be happy if i have one point less in the policy...
Getting the framework updated for such a thing will be a lot easier
than getting to use the framework...
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: