Hallo Dalibor,
Just a short reply. I'm running out of time... :) And BTW: no need to
CC me. I hope I have set the required headers...
* Dalibor Topic wrote:
>In any case, you'd end up doing a lot of work, with little practical value.
>Just like many jakarta apps come with tons of differently versioned binary jars
>in their libraries directories, free VMs come with different, and adapted
>versions of GNU Classpath that suit their needs best.
This is debian :) AFAIK, debian-OOo are the only guy, which are trying
to disbale the use of a intrenal freetype version (among other libs,
which comes with the official tar.gz).
>Uh, I don't think it's an elegant approach. It encourages people to
>regularly flame each other on debian-java whether package java.x.y is
>important enough to be a requirement for letting a VM provide
>java2-runtime-1.z, or their VM would be blocked from being a
>'debian-blessed' java2 runtime.
So again, this is a no-no. I just thought, that it's always this tree.
I get more and more the impression, that the only way is to
* interface to unfree VMs (wqhich should be ~100% sun compatible
* test all free java versions.
* interface to ant, so that the build time testing is as easy as
possible.
>> Jan, never much bothered about lizensing...
>you should. it's very rewarding and fun ;)
I can see that :) I just saw a bit from the GFDL discussuion on
debian-legal. That's even better that the de-admin.news.groups
discusions...
>your 'mix-and-match' bootclasspath has some serious licensing
>implications. For example, if I take a LGPL-d javax.something
>implementation, and add in a GPL+linking exception licensed
>javax.something.else to my bootclasspath, the resulting application
>needs to be licensed under the GPL, as the lowest common license,
>AFAIK. It works for kaffe, since kaffe is GPL and we make sure that we
>only merge in GPL-compatible code,
BTW, wasn't there something, that SUN considers API information also
under their lizense? Makeing CLASPATH basicly illegal? Hm, I'm too
lazy to google...
>but an ad hoc 'let me quickly add
>this missing package to my bootclasspath for some application'
>approach could cause some trouble.
Not even, when you do that in a wrapper script via --bootclasspath? Or
in the wrapper script of the app?
Jan
--
Jan Schulz [EMAIL PROTECTED]
"Wer nicht fragt, bleibt dumm."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
