Hi Daniel,
The Sun SDK is free both to use and to sell programs that have been
compiled with it. The problem with it is only in terms of the source
code for the SDK itself. Java developers are not free to review the
source and/or improve on it.
Hope this clear it up for
Ed Murray
On Tue
Hi all,
I am a little confused with the discussion about what is free and not free when
it comes to Java. Could someone tell me, if I use Sun's Java 1.4.x SDK on
Debian to byte-compile some .java files, will I have to pay Sun some royalty in
order to use the compiled program? I thought Sun is
Hi Daniel,
The Sun SDK is free both to use and to sell programs that have been
compiled with it. The problem with it is only in terms of the source
code for the SDK itself. Java developers are not free to review the
source and/or improve on it.
Hope this clear it up for
Ed Murray
On Tue
> So what? I just compiled kdelibs4, to get the -dev package working
> with experimental Xfree4.3 (xlibs-pic -> xlibs-static-pic). It took me
> half a day (yes, that was my first such compile problem...) to figure
> out, why it didn't configure on my newly installed unstable. Until I
> saw how the
> >I'm quite happy with this suggestion as well (must -> may for non-free
> >JVM dependencies). If at least one of the dependencies is satisfied
> >- even if this is selected from a list of only free JVMs - then the
> >app will presumably run successfully and so there's no problem if
> >non-free
Hallo Mark,
* Mark Wielaard wrote:
>I am afraid we are not communicating very constructively.
>We might have to start from scratch since somehow we keep missing each
>others points.
Seems so. To sum it up:
* I want to have the possibility to use unfree VMs with java packages
* you don't want to i
> >I beg to disagree. I want to be able to change my preferences at runtime,
> >instead of having to rely on a packager to get it right when he packages the
> >application.
>
> Somewhere else you said, that it is ok for you if the packagers only
> uses one dependency (which implys, that only one
Hi all,
I am a little confused with the discussion about what is free and not free when it
comes to Java. Could someone tell me, if I use Sun's Java 1.4.x SDK on Debian to
byte-compile some .java files, will I have to pay Sun some royalty in order to use the
compiled program? I thought Sun is
Hi,
I am afraid we are not communicating very constructively.
We might have to start from scratch since somehow we keep missing each
others points. Let me try one last time to point out what I find
important facts when deciding how to create a java policy for Debian.
On Mon, 2003-09-08 at 20:15,
> So what? I just compiled kdelibs4, to get the -dev package working
> with experimental Xfree4.3 (xlibs-pic -> xlibs-static-pic). It took me
> half a day (yes, that was my first such compile problem...) to figure
> out, why it didn't configure on my newly installed unstable. Until I
> saw how the
> >I'm quite happy with this suggestion as well (must -> may for non-free
> >JVM dependencies). If at least one of the dependencies is satisfied
> >- even if this is selected from a list of only free JVMs - then the
> >app will presumably run successfully and so there's no problem if
> >non-free
Hallo Mark,
* Mark Wielaard wrote:
>I am afraid we are not communicating very constructively.
>We might have to start from scratch since somehow we keep missing each
>others points.
Seems so. To sum it up:
* I want to have the possibility to use unfree VMs with java packages
* you don't want to i
> >I beg to disagree. I want to be able to change my preferences at runtime,
> >instead of having to rely on a packager to get it right when he packages the
> >application.
>
> Somewhere else you said, that it is ok for you if the packagers only
> uses one dependency (which implys, that only one
On Wed, Aug 27, 2003 at 02:48:42AM +0200, Jan Schulz wrote:
> Hallo Mark,
>
> * Mark Howard wrote:
> >Package: ibm-jdk1.1-installer (debian/contrib).
> >Maintainer: Yven Johannes Leist <[EMAIL PROTECTED]>
> > 167934 [] Please include /usr/lib/jni in default JNI search path
> > 195293 [
Hi,
I am afraid we are not communicating very constructively.
We might have to start from scratch since somehow we keep missing each
others points. Let me try one last time to point out what I find
important facts when deciding how to create a java policy for Debian.
On Mon, 2003-09-08 at 20:15,
Hallo Dalibor,
Ok, I'm also good at philosophical nitpicking :)
* Dalibor Topic wrote:
>--- Jan Schulz <[EMAIL PROTECTED]> wrote:
>> > [...working ant...]How do you define normally?
>> Just as it is now.
>so the status quo, with ant having what we agreed upon to be some very badly
>designed code,
Hallo Dalibor,
* Dalibor Topic wrote:
>> '/usr/bin/java'. If sablevm and kaffe are installed and I depend on
>> kaffe, but sablevm installs a higher priority, then I'm fd up.
>I think we both agree that this scheme is not a good solution for java
>on debian. It doesn't give users the necessary
Hallo Ben,
* Ben Burton wrote:
>> this 'let's make free software in debian depend on non-free software'
>> proposal is incompatible with debian's goal, afaik. turn that into a
>> 'may depend on the unfree interfaces ' and I'll be happier with it.
>I'm quite happy with this suggestion as well (must
Hallo Dalibor,
* Dalibor Topic wrote:
>> This is not the primary goal of the policy IMO. The policy is for
>> describing *how* a package should look like, a kind of ruleset, which
>> packages have to comply to. Nothing more, nothing less.
>Well, the current proposal for a debian java policy contai
Hallo Dalibor,
* Dalibor Topic wrote:
>> I don't do it. I just see the need, that some people will want to run
>> java apps on a unfree VM. This propsal makes this possible.
>But it is already possible, isn't it?
Yes, because the curent proposal makes nor difference between free and
unfree ones.
Hallo Dalibor,
* Dalibor Topic wrote:
[kdelibs4 problems]
>> all cases to '1', but the latest qt version in unstable is '2'. I don't
>> think that anyone bothers to test their packages, when one of the
>> dependencies changed.
>Whoever changed the dependency should have tested the packages that de
Hallo Mark,
* Mark Wielaard wrote:
>On Sun, 2003-09-07 at 13:31, Jan Schulz wrote:
>I would call it byte code interpreter then.
>Try to avoid the java name a bit since Sun claims a trademark on it.
>And it make it more clear that it is only one part of the environment
>that people might want. (The
On Wed, Aug 27, 2003 at 02:48:42AM +0200, Jan Schulz wrote:
> Hallo Mark,
>
> * Mark Howard wrote:
> >Package: ibm-jdk1.1-installer (debian/contrib).
> >Maintainer: Yven Johannes Leist <[EMAIL PROTECTED]>
> > 167934 [] Please include /usr/lib/jni in default JNI search path
> > 195293 [
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Ben,
>
> * Ben Burton wrote:
> >Yes, but in the old policy it's clear that we don't really know what
> >works and what doesn't. In the new proposal, we claim to specify
> >precisely which VMs work with which package, and so if we encou
Hallo Dalibor,
Ok, I'm also good at philosophical nitpicking :)
* Dalibor Topic wrote:
>--- Jan Schulz <[EMAIL PROTECTED]> wrote:
>> > [...working ant...]How do you define normally?
>> Just as it is now.
>so the status quo, with ant having what we agreed upon to be some very badly
>designed code,
Hallo Dalibor,
* Dalibor Topic wrote:
>> '/usr/bin/java'. If sablevm and kaffe are installed and I depend on
>> kaffe, but sablevm installs a higher priority, then I'm fd up.
>I think we both agree that this scheme is not a good solution for java
>on debian. It doesn't give users the necessary
Hallo Ben,
* Ben Burton wrote:
>> this 'let's make free software in debian depend on non-free software'
>> proposal is incompatible with debian's goal, afaik. turn that into a
>> 'may depend on the unfree interfaces ' and I'll be happier with it.
>I'm quite happy with this suggestion as well (must
Hallo Dalibor,
* Dalibor Topic wrote:
>> This is not the primary goal of the policy IMO. The policy is for
>> describing *how* a package should look like, a kind of ruleset, which
>> packages have to comply to. Nothing more, nothing less.
>Well, the current proposal for a debian java policy contai
Hallo Dalibor,
* Dalibor Topic wrote:
>> I don't do it. I just see the need, that some people will want to run
>> java apps on a unfree VM. This propsal makes this possible.
>But it is already possible, isn't it?
Yes, because the curent proposal makes nor difference between free and
unfree ones.
Hallo Dalibor,
* Dalibor Topic wrote:
[kdelibs4 problems]
>> all cases to '1', but the latest qt version in unstable is '2'. I don't
>> think that anyone bothers to test their packages, when one of the
>> dependencies changed.
>Whoever changed the dependency should have tested the packages that de
Hallo Mark,
* Mark Wielaard wrote:
>On Sun, 2003-09-07 at 13:31, Jan Schulz wrote:
>I would call it byte code interpreter then.
>Try to avoid the java name a bit since Sun claims a trademark on it.
>And it make it more clear that it is only one part of the environment
>that people might want. (The
Hallo Stefan,
* Stefan Gybas wrote:
>Your proposal is a complete rewrite of the Java Policy but I think this
>step is too big: You have changed a lot of requirements that have been
>discussed in the past but there has not been a consesus. For example,
>you have changed the naming of library JAR
Hallo Ben,
* Ben Burton wrote:
>> >I'm not really comfortable with the idea of "don't test, just assume it
>> >works until someone tells you otherwise". Yes, it happened with flex
>> >but that was a once-off. With this java proposal it will become
>> >institutionalised.
>> It is already instituti
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Ben,
>
> * Ben Burton wrote:
> >Yes, but in the old policy it's clear that we don't really know what
> >works and what doesn't. In the new proposal, we claim to specify
> >precisely which VMs work with which package, and so if we encou
Hi Jan,
On Sun, 2003-09-07 at 13:31, Jan Schulz wrote:
> Do you have a better name for 'programm, which runs java byte code'?
> for me 'java' stands for exactly this and I don't midn if it is
> actually called /usr/bin/kaffe or /usr/lib/sunjdk/bin/java
I would call it byte code interpreter then.
Hallo Stefan,
* Stefan Gybas wrote:
>Your proposal is a complete rewrite of the Java Policy but I think this
>step is too big: You have changed a lot of requirements that have been
>discussed in the past but there has not been a consesus. For example,
>you have changed the naming of library JAR
Hallo Ben,
* Ben Burton wrote:
>> >I'm not really comfortable with the idea of "don't test, just assume it
>> >works until someone tells you otherwise". Yes, it happened with flex
>> >but that was a once-off. With this java proposal it will become
>> >institutionalised.
>> It is already instituti
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Mark,
>
>
> * Mark Wielaard wrote:
> >On Sat, 2003-09-06 at 22:26, Jan Schulz wrote:
> >> The problem in debian is to find out this java.
> >> This should be adressed in this proposal.
> >Why this fixation on this one program name?
>
> Do you ha
Jan Schulz wrote:
This is a significant rewrite of my previous proposal. To make
discussion alittle easier, I've broken the subject line to tell, that
this is the third request for discussion.
Sorry, I've been away a couple of days when you have posted your
proposal so I still need to catch up. I'
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >The definition of what's to be expected as normal keeps changing all the
> time
> >in the java world, as I'm trying to make clear with my questions on your
> >interpretation of java's class loading semantics.
Hi Jan,
On Sun, 2003-09-07 at 13:31, Jan Schulz wrote:
> Do you have a better name for 'programm, which runs java byte code'?
> for me 'java' stands for exactly this and I don't midn if it is
> actually called /usr/bin/kaffe or /usr/lib/sunjdk/bin/java
I would call it byte code interpreter then.
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Mark,
>
>
> * Mark Wielaard wrote:
> >On Sat, 2003-09-06 at 22:26, Jan Schulz wrote:
> >> The problem in debian is to find out this java.
> >> This should be adressed in this proposal.
> >Why this fixation on this one program name?
>
> Do you ha
Jan Schulz wrote:
This is a significant rewrite of my previous proposal. To make
discussion alittle easier, I've broken the subject line to tell, that
this is the third request for discussion.
Sorry, I've been away a couple of days when you have posted your
proposal so I still need to catch up. I
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >The definition of what's to be expected as normal keeps changing all the
> time
> >in the java world, as I'm trying to make clear with my questions on your
> >interpretation of java's class loading semantics.
Accepted:
java-common_0.22.dsc
to pool/main/j/java-common/java-common_0.22.dsc
java-common_0.22.tar.gz
to pool/main/j/java-common/java-common_0.22.tar.gz
java-common_0.22_all.deb
to pool/main/j/java-common/java-common_0.22_all.deb
Announcing to debian-devel-changes@lists.debian.org
Closing b
On Sat, Sep 06, 2003 at 04:10:24PM +0200, Oliver Scorp wrote:
> there does exist 2 main-areas for proxy-configurations under java.
Hi,
I do know of these already. The point I was making is that I think
the values of these should be set when the jvm starts to the values of
the standard linux env
Accepted:
java-common_0.22.dsc
to pool/main/j/java-common/java-common_0.22.dsc
java-common_0.22.tar.gz
to pool/main/j/java-common/java-common_0.22.tar.gz
java-common_0.22_all.deb
to pool/main/j/java-common/java-common_0.22_all.deb
Announcing to [EMAIL PROTECTED]
Closing bugs: 201670
Thank
On Sat, Sep 06, 2003 at 04:10:24PM +0200, Oliver Scorp wrote:
> there does exist 2 main-areas for proxy-configurations under java.
Hi,
I do know of these already. The point I was making is that I think
the values of these should be set when the jvm starts to the values of
the standard linux env
48 matches
Mail list logo
