Josh Triplett wrote: > Tom Marble wrote: >> Don Armstrong wrote: >>> On Fri, 19 May 2006, Tom Marble wrote: >>>> + SECTION 2(c) >>>> >>>> There have been a series of speculations about this, despite the >>>> clarifications of FAQ #8. The term "alternate technologies" refers >>>> to projects such as kaffe, gcj, classpath, harmony and the like. >>>> We want Debian users that include "non-free" to be able to have a >>>> choice which includes Sun Java. We don't want to put wacky >>>> restrictions on every programming language. >>> Right, but from what I can tell the 2a does this as well... what >>> additional restrictions does Sun gain by adding 2c in addition to 2a? >> 2c is the please "don't mix and match with 'alternate technologies' " >> provision. > > Right. So, what precisely does this intend to ban? The clause reads: >> (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; > > Since the Sun Java packages use the alternatives system (which they > clearly should do), we could reasonably consider any Java software > shipped by Debian as configured to run in conjunction with Sun Java. > Thus, this clause prevents Debian from shipping any Java software which > "implements the same or similar functionality or APIs as" Sun Java. For > example, this could prevent Debian from shipping SWT, which provides > similar functionality to Swing, or even more clearly SwingWT, which > provides the Swing API on top of SWT. From FAQ #8, "there is nothing in the DLJ intended to prevent you from shipping alternative technologies with your OS distribution." When I say mix and match I mean please don't take bits from the alternate technologies (see above) and put them into use with the Java platform (e.g. replace rt.jar which is part of the platform with an alternate rt.jar). In a similar way please don't take bits from the Java platform and use them as part of or to complete alternate technologies (e.g. plugin.jar). So you can distribute alternate technologies or SWT on your OS and still ship Sun Java. If this is still unclear please let me know. > Furthermore, the alternatives system allows a user to choose between > programs based on priority, on a program-by-program basis. Suppose we > shipped packages in main with alternative priorities set such that if a > user installed certain of those packages along with Sun Java, they'd end > up with parts of the JDK pointing to Sun Java and others pointing to > software in main. For example, with "java" pointing to Sun's Java but > "javadoc" pointing to gjdoc, and gjdoc in turn running with whatever > java pointed to, namely Sun Java. Since Sun Java also ships a javadoc > implementation, that sounds very clearly like configuration or > distribution to run in conjunction with additional software that > implements the same functionality. Yes this is a potential problem that was raised this week. AFAIK a fix is in progress with a complete set of "noop" alternatives so the update-java-alternatives script (in java-common) will not accidentally mix Java with alternate technologies. > I can understand why Sun currently wants a clause like this: they want > to know that when a user gets "Sun Java", they don't have any non-Sun > implementations of portions of Java that Sun wants to guarantee the > functionality of, for the benefit of software certified in some way to > run on Sun Java. However, that sounds like an issue better solved by a > trademark license, [...] That might be an approach in the Java platform's libre future. You have captured the essence of the goal of compatibility as expressed in the DLJ. >>>> And, as I am sure you know, Rich Green has announced a very >>>> interesting Open Source future for Java. Simon, I (and many others) >>>> are going to work very hard on that internally so that soon you will >>>> be able consider Java for "main". >>> For that, I applaud you; let me know if there is anything that I can >>> do to help speed that process (which is infinetly more interesting to >>> me than dealing with EULAs) along. > > Fully seconded; I would gladly help with this as well. I notice that you are part of freedesktop.org. I think this is the year for the Linux desktop to thrive and really want to see that happen. Among other things I'm really tired of being the sys admin for various people who constantly have Windows annoyances. Ironically the Debian apt-get system solves software deployment and updating problems that Windows does not. One benefit that desktop users inherit from an infrastructure that supports fresh, up-to-date bits is that developers don't have to turn to AJAX by rationalizing that the user has an implementation of JavaScript in a web browser that can never, ever change. Java can offer a rich client platform [1] which far surpasses the goofy client side caching appeal of AJAX. Regards, --Tom [1] http://platform.netbeans.org/
Attachment:
signature.asc
Description: OpenPGP digital signature