Re: [draft] Re: Sun Java available from non-free
On Fri, May 19, 2006 at 10:59:33PM +0200, Jeroen van Wolffelaar wrote: (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. So I assume that one of the other two who had a look at it know more about this and will share their insights later on. ... 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. That's true. But why did they release this license and used no other wording? You essantially say, why worry about a license if it's bad PR too sue the licensees. I doubt it really works that way. After all you could, at some point somehow, get into a situation where Sun doesn't care about the PR effect. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [draft] Re: Sun Java available from non-free
On 5/19/06, Jeroen van Wolffelaar [EMAIL PROTECTED] 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. Could you paste your answer to the pp question below[0] ? - What is Debian's (current) approach to non-free software? Why? Is non-free part of the Debian System? [0] = Mini-HOWTO for Debian New Maintainers Application Managers / APPENDIX 3: SAMPLE QUESTIONS ON PHILOSOPHY URL: http://people.linux.org.tw/~chihchun/cddp/www/devel/join/nm-amhowto (...) Thanks in advance, -- stratus
Re: [draft] Re: Sun Java available from non-free
Michael wrote: 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. That's true. But why did they release this license and used no other wording? You essantially say, why worry about a license if it's bad PR too sue the licensees. I doubt it really works that way. After all you could, at some point somehow, get into a situation where Sun doesn't care about the PR effect. True. We only have to look at the once-noble company called Santa Cruz Operations for a real-life example. Drew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [draft] Re: Sun Java available from non-free
On 5/19/06, Jeroen van Wolffelaar [EMAIL PROTECTED] wrote: [snip] 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. [snip] 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, ... [snip] 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. [snip] 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. [snip] I think at the very least we can say the licence is terribly worded. The word with has at least 27 meanings, the word software is not adequately defined. Conjunction also has several possible meanings. Thing like estoppel don't apply the same way everywhere, so you can't rely on things like that. Maybe someone should come back with a More Carefully Worded New Sun Java Licence -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: [draft] Re: Sun Java available from non-free
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 signature.asc Description: OpenPGP digital signature
Re: [draft] Re: Sun Java available from non-free
On Sat, May 20, 2006 at 02:18:57PM -0700, Josh Triplett wrote: 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. It may imply this, but this is not a barrier to Debian's inclusion of the packages under the current non-free regime. The only real requirement for a package's inclusion in non-free is: can we distribute it? We don't make any guarantees that other people can also distribute it outside of a Debian mirror, or on CDs, or anything else. There have definitely been non-free packages in the past that could *not* be distributed separately from the Debian mirrors or that could not be distributed on CDs. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: [draft] Re: Sun Java available from non-free
Steve Langasek wrote: On Sat, May 20, 2006 at 02:18:57PM -0700, Josh Triplett wrote: 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. It may imply this, but this is not a barrier to Debian's inclusion of the packages under the current non-free regime. The only real requirement for a package's inclusion in non-free is: can we distribute it? We don't make any guarantees that other people can also distribute it outside of a Debian mirror, or on CDs, or anything else. There have definitely been non-free packages in the past that could *not* be distributed separately from the Debian mirrors or that could not be distributed on CDs. I certainly didn't mean to suggest otherwise. Just raising a point for discussion. Even non-free licenses could stand improvement towards becoming less non-free. - Josh Triplett signature.asc Description: OpenPGP digital signature
[draft] Re: Sun Java available from non-free
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,
Re: [draft] Re: Sun Java available from non-free
Let me first preface this with a caveat and an apology: after the fact it was pointed out that the mail I sent was needlesly inflamatory; that was not my intention and for that I apologize. I also appreciate the desire of Sun to work with Debian in order to create a license that distributions can distribute; I hope that they continue down this path and eventually end up at a license for Sun Java that is trivially DFSG Free. By commenting on this license, I'm trying to make sure that all of the possible avenues of attack of a litigous licensor against Debian are made manifest and the harsh light of flames shown upon them.[0] I really wish that in the future these sorts of issues could be resolved publicly, or at least the relevant information from the parties involved be shared at the instant that such a package begins to become under consideration for NEW. It seems that more emphasis was placed on the validity of the FAQ as binding on the intentions of Sun than someone outside the process of vetting this license could see. On Fri, 19 May 2006, Jeroen van Wolffelaar wrote: 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 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. We're currently splitting the package into pieces; and presumably the software is unpacked or otherwise modified from the form that Sun has actually distributed to us. I don't know whether Sun has approved this or not, but if they haven't, this seems to pose a problem. The license doesn't impose any restriction on the way it is actually distributed, Sure, but we're creating some sort of derivative work before we actually distribute it. (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 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? It's the vagueness of the word with; do they mean within, alongside or all of the above? [And are they willing to legally bind themselves with that interpretation?] I personally don't buy the non-free is Debian too argument, but then again, I'm one of the people for whome non-free basically doesn't exist. (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. No, so long as they're capable of working with things in main but optionally working with Sun Java they can go in main. 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). It's not entirely clear that these are not restricted by these clause, unless there is no overlaping functionality between any application that can use Sun Java. [As a further note, we do appear to support this, as eclipse-ecj (FE) Depends: on java2-runtime, which sun-java5-jre Provides:.] 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. The resultant thing couldn't be distributed anyway because of clause 2a; seeing a redundant clause like this that seems to also make things that we probably do in Debian against the license when a previous clause already does what the licensor is telling you that they want to do scares me.[1] 14. MISCELLANEOUS. Any action related to this Agreement will be governed
