Jeroen van Wolffelaar wrote: > On Wed, May 17, 2006 at 11:09:30PM -0700, Don Armstrong wrote: >>> (b) the Software is distributed with your Operating System, and >>> such distribution is solely for the purposes of running Programs >>> under the control of your Operating System and designing, >>> developing and testing Programs to be run under the control of >>> your Operating System; >> non-free is not part of Debian so we definetly don't distribute it as >> part of the Operating system. > > Note that the license says "... is distributed *with* your Operating > System", and not "is part of". I don't know where you read the "part of" > bit? Anyway, we definitely do distribute non-free *with* our OS, it's in > debian/pool/non-free on all our mirrors alongside debian/pool/main, and > distributing it in the same directory hierarchy is definitity "with" in > my book. Does that imply, though, that one cannot mirror non-free separately from Debian, or put it on a separate CD which one can purchase or distribute separately? For example, such a clause would prevent Debian from distributing non-free on a separate server, as proposed a while back. >>> (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; >> This means that we can't distribute eclispse or anything else which >> implements part of the Java API (or if you're going to read this >> clause as broadly as possible,[1] things like perl which implement >> similar functionality in that perl is an implementation of a cross >> platform language Perl.) > > The license says "distribute [...] to run in conjunction with". We do > distribute eclipse, kaffe, gcj, and various others tools and > applications, but not "to run in conjunction" with the Sun Java. As I mentioned elsewhere in this thread, the alternatives system means that any Java library in Debian could fall under "configure [...] to run in conjunction with". Thus, what about software like SWT, which provides "similar functionality", or SwingWT, which provides the Swing API on top of SWT? Does this clause prevent us from shipping those? > What this clause seeks to prevent is using Sun's JVM with the Classpath > java library, or to use the Java library code together with Kaffe. So, for example, Debian would need to stop shipping the jikes-sun package <http://packages.debian.org/jikes-sun> which uses the Jikes compiler to compile against the Sun Java library? >>> 4. COMPATIBILITY. If you exercise the license in Section 2, and Sun >>> or a licensee of the Software (under section 4(b)) notifies you >>> that there are compatibility issues [...] caused by the >>> interaction of the Software with your Operating System, then >>> within ninety (90) days you must either: (a) modify the >>> Operating System in a way that resolves the compatibility issue >>> (as determined by Sun) and make a patch or replacement version >>> available [...] >> Oh, right... so if the Sun JDK is buggy, we have to modify our >> operating system to make it unbuggy in some way that makes Sun happy. >> Makes sense to me. > > Or option (b), remove the Sun packages. If we were to face this > situation, there's always this option if there isn't a better one. And if a problem comes up with the Sun Java package shipped in stable, or oldstable? > Speaking realistically, such a move of Sun would be spectacularly bad PR > for them esp. considering their statements about future Java licensing > efforts they have committed to. I agree. However, that doesn't prevent them from doing it, once. - Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature