Let me reply to at least some of the points raised here right now. By the way, one of the Sun engineers was involved in packaging, and actually wrote (with help from others) part of the license agreement code etc. using debconf. I don't think that has any legal value (but I'm not a legal expert), but it does mean that Sun was and is aware even before the upload how this was packaged and where and how it'd end up on our mirrors. There was a signifcant level of cooperation here.
Note that my answers below are my opinion only, speaking as one of those people who have carefully read the license before it was uploaded to Debian. On Wed, May 17, 2006 at 11:09:30PM -0700, Don Armstrong wrote: > > 2. License Grant. Subject to the terms and conditions of this > > Agreement, [...] provided that: (a) the Software and any > > proprietary legends or notices are complete and unmodified; > > This seems to cause a problem with actually packaging the software > unless the Debian package counts as the Software... this seems to mean > that any time that the package should be changed the maintainers need > Sun to actually distribute the software to them (or otherwise grant > them the ability to modify the software.) The software as distributed is complete, it has all the files in the .deb packages, and the dependencies ensure that on the user's system the software layout is like Sun requires, with the optional bits indeed being optional. The license doesn't impose any restriction on the way it is actually distributed, that's intentionally left to the distributions to do it the way that best suits the distribution in question. > > (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. > > (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. Our own policy even prevents us from doing so unless we move the aforementioned stuff to contrib. There is no blanket restriction on distributing things alongside Sun Java. As to eclipse, if you're going to run eclipse with Sun Java (something we do not support in Debian anyway), you're going to use eclipse as an application run by Sun Java (to run eclipse itself), and Sun Java as an application started by eclipse (Sun javac and java etc as a compiler and executer of Java code written in Eclipse). Neither of those uses are restricted by this clause. 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. > > (d) you do not remove or modify any included license agreement > > or impede or prevent it from displaying and requiring > > acceptance; > > We may need to modify debconf preseeding to make sure that the user > can't prevent the agreement from being shown... Actually, the ability to preseed the license question is a feature, to allow FAI (Fully Automated Installation) etc. on large scale deployments. Sun wants that every legal entity using the software agrees to its license, but doesn't want to, and doesn't require, the license to be explicitely affirmed manually on each computer. As a distribution, we do not impede or prevent the license from displaying, but for in house deployments, one can definitely accept the license by using debconf preseeding. For legal purposes, one can consider writing the preseed value and getting that whole thing to work as an elaborate way to click 'accept'. Of course, doing so means that the software cannot be redistributed with this modification, but that does not prohibit in-house distribution within one legal entity. > > (f) you agree to defend and indemnify Sun and its licensors from > > and against any damages, costs, liabilities, settlement amounts > > and/or expenses (including attorneys' fees) incurred in > > connection with any claim, lawsuit or action by any third party > > that arises or results from (i) the use or distribution of your > > Operating System, or any part thereof, in any manner, or (ii) > > your use or distribution of the Software in violation of the > > terms of this Agreement or applicable law. > > I'm really not entirely sure what this clause is getting at, but it > seems that the intention is that Debian needs to indemnify Sun for any > litigation resulting by users of the package of Sun's JDK which Debian > has distributed, even if Sun is grossly negligent.[2] I'm not an expert at all on indemnification, that's to the best of my knowledge quite US-centric. Pass on this one. > > 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. We'll definitely not let us be "blackmailed" into doing changes to Debian that we do not want to make -- I'm happy that we can provide these packages as a service to our users, but not all at the cost of being forced into making other changes against our will. 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. > > 14. MISCELLANEOUS. Any action related to this Agreement will be > > governed by California law and controlling U.S. federal law. No > > choice of law rules of any jurisdiction will apply. > > Awwww yeah! Now everyone gets to suffer! The infamous choice of venue type clause. As I understand it of doubtful legal applicability and consequences, but I don't know much about it, so pass. > > It supersedes all prior or contemporaneous oral or written > > communications, proposals, representations and warranties and > > prevails over any conflicting or additional terms of any quote, > > order, acknowledgment, or other communication between the > > parties relating to its subject matter during the term of this > > Agreement. > > Just in case you had any questions about the total uselessness of the > license FAQ, the above clause should put that to rest. I'm not familiar with US law, but I think this one is very hard if not impossible to hold up in court. Anyway, this clause is not relevant indeed if you look at the license on its own merits. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
