Your message dated Sat, 19 Aug 2006 15:46:57 +0200 with message-id <[EMAIL PROTECTED]> and subject line DLJ prevents running jython with sun-java has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database)
--- Begin Message ---Package: sun-java5-jre Version: 1.5.0-06-1 Severity: serious In the Distributor License for Java, there is the clause (c) you do not combine, configure or distribute the Software to run in conjunction with any additional software that implements the same or similar functionality or APIs as the Software; Debian distributes Jython, which can run with sun-java. However, Jython, being a reimplementation of Python, implements a great deal of similar functionality as sun-java. This can be fixed by making Jython conflict with sun-java, although I suspect that there may be other packages that also cause problems. Cheers, Walter Landry [EMAIL PROTECTED]
--- End Message ---
--- Begin Message ---On Mon, Jul 10, 2006 at 12:15:10AM -0700, Josh Triplett wrote: > Jeroen van Wolffelaar wrote: > > On Sun, Jun 04, 2006 at 02:37:45PM -0700, Josh Triplett wrote: > >> As more direct examples than Jython: > [...] > >> Any libfoo-java package in Debian will run with the current installed > >> JDK. Thus, any libfoo-java package in Debian which implements "the same > >> or similar functionality" as Sun Java causes Debian to violate the > >> license on Sun Java. Obvious examples include libswingwt-java (which > >> implements much of the Swing API), libcharva1-java, libcommons-*-java > >> ("similar functionality"), Java XML processing tools that implement the > >> standard APIs, libgnu-regexp-java (since, if I recall correctly, Sun > >> Java includes regular expression handling), liboro-java (same reason), > >> libregexp-java (same reason), libgetenv-java (specifically notes itself > >> as a replacement for java.lang.System.getenv), and probably others. > > > > I don't think any of these are a violation of the license, most clearly > > as per FAQ#14. If they are, it's a bug on the package itself, instead of > > on sun-java5 -- analog to it being a kernel module's bug if it's non-GPL > > and still using GPL-only symbols from the kernel, or it being a package > > bug if it uses OpenSSL being GPL itself, and not a bug in the OpenSSL > > package. > > I believe you have the dependency the wrong way around in your analogy, > possibly due to my pointing out jikes-sun (a dubious package from > contrib); the more important case occurs with all the Free Software in > main that runs with any JDK following Debian's Java policies. Multiple > implementations of the JDK exist, and these Free Software packages run > just fine on all the Free ones. The fact that the non-free > implementation prohibits distribution with compatible software > configured to run with it, while at the same time following the Debian > Java policy that lets it run with all of those packages of Java > software, does not mean those packages of Java software have done > anything even remotely wrong. > > To use your analogy, imagine multiple implementations of the kernel > existed, both capable of running modules X, Y, and Z. Imagine that the > license of "kernel B" banned the distribution of X and Y in a > configuration designed to run with "kernel B". The fact that "apt-get > install kernel-b x y z" will work out-of-the-box puts Debian in > violation of the license on "kernel B"; this doesn't constitute a bug in > x or y, and the x and y packages have no need to change to suit the > demands of the non-free kernel-b package, so the fault must lie with the > kernel-b package. I see... I think the main reason this is not a issue is the following: Everybody realizes that because of the configurability of Linux and Debian in particular, if someone wants to run and mix-and-match technologies on one's own system, one can do so. There is no way this can be technically prevented. This particular license statements intends to forbid shipping mix-and-matching code and applications, as once mentioned as example, a Sun's JVM combined with classpath. As per FAQ#14, Sun has an issue if parts of the JDK/JRE were used together with other non-Sun parts to create a Java implementation. Debian does ship Sun's JDK/JRE in such a way that it is configured to run completely as a single suite. Existance of other packages, even those implementing similar features to the same API, do not result in a Java implementation configured as such by Debian that's consisting of bits of Sun with bits of other things. It is still possible for extra packages that implement part of the Java class library API to be configured by the user to create a configuration that is in violation of the DLJ. However, Debian doesn't do so, and the user must have read the license while installing sun-java5 from non-free, and then realizes that this is not what Sun wants. Note that merely apt-get install'ing does *not* get you into this situation, in order to get additional libraries to supersede/augment the available classes, you need to modify classpath directives (similar to LD_LIBRARY_PATH for C): see libcharva1-java, libgnu-regexp-java and libgetenv-java's README.Debian for example. Once a newer Java policy makes it easier to just install and use such additional classes by managing the classpath better, we'll need to ensure that if Sun is used, this is not happening by default. It is my belief that as distribution we do comply with the license this way. > > As long as a package is not using the exact same namespace and > > interface, it's not a drop-in replacement, but rather a similar (but > > distinct) piece of software that you're perfectly fine of using with Sun > > Java. > > Neither the DLJ nor Sun's FAQ make any mention of namespaces, and > neither one deals only with exact matches or drop-in replacements. > Nothing in either document suggests that these packages can coexist with > Sun Java. Any Java package in Debian which follows the Debian Java > policies qualifies as "configured to run with" Sun Java, and thus any > such package which implements the same or similar interfaces will > constitute a license violation. I disagree with 'qualifies as "configured to run with" Sun Java', see above, and also, I don't share this reading of what qualifies "software that implements the same or similar API's", from elaborate talks with Sun, I believe we must interpret this as narrowly as I suggested above. Anyway, the latter point is not very relevant because of the former. > > If any of those packages do use the same namespace and are intended to > > be used as a direct replacement of part of the Sun Java suite, resulting > > in a hybrid environment, then that is a bug in that package, as it's not > > allowed to do without violating the license of Sun Java. Since this bug > > is already quite long and listing a lot of issues, please in this case > > file a new bug, one per issue, on the package in question. Of course you > > can ask opinion on it from me and other sun-java5 package maintainers in > > such case, or alternatively, ask Sun about it. > > Many of these packages *do* use the same namespaces and/or implement > identical interfaces, and this does *not* constitute a bug in those > packages. When used with a free JDK, they have every right to function > either as java.*, javax.*, or sun.* classes, or implement identical or > similar interfaces in an alternate namespace. These packages follow > Debian's Java policies, and thus work with any JDK that also follows > that policy. The packages of Sun's JDK appear to follow that policy, > and thus these packages will likely work with Sun's JDK, leading to a > license violation. What I intended to say is really specifically to packages to be used to replace part of Sun's JDK, and not all those that replace/supplement the general Java API. I wrote "direct replacement of part of the Sun Java suite". Jikes-sun is such package I intended to cover with it, as it's specifically intended to combine jikes with Sun's Java. I hope this addresses your issues. On Sat, Jul 22, 2006 at 12:40:12AM -0700, Walter Landry wrote: > In any case, it may well be that libgetenv-java is buggy. Fixing it > should not suddenly cause a license problem. There are still all of > the packages > > libcharva1-java > libcommons-*-java > libregexp-java > > which have dependencies that are fulfilled by java2-runtime. > liboro-java should probably depend on a java2-runtime as well. I believe the above also addresses your concerns. Therefore, I'm now closing this bug (again), if anyone still believes there is a problem, please specify a concrete working example of how to get a DLJ-incompatible situation with just using apt-get install. Thanks, and again sorry for the time it took to respond, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
--- End Message ---
