reopen 370295 thanks Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote: > 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 > 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.
Debian has configured libcommons-el-java (for example) to run with either gij-4.1 or sun-java5-jre via the virtual package java2-runtime. They should just work together. That is the whole point of dependencies. > 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. You do not have to override the existing implementation of those API's to get into trouble. The language in the DLJ is "same or similar", not just "same". > 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. The best way to do this is to have Sun's java not provide generic virtual packages like java2-runtime. > > > 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. The elaborate talks you had with Sun are not part of the license. I have asked Tom Marble more than once whether his comments are binding on Sun. He has declined to answer that question, so we can only go by what is in the license. <snip> > 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. apt-get install sun-java5-bin sun-java5-jre apt-get install libcommons-el-java libcommons-el-java is an implementation of the API in javax.servlet.jsp.el. This is really a simple bug to fix. Just take out the Provides: java2-runtime. Then the second apt-get line would pull in a free runtime. Cheers, Walter Landry [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
