Re: Sun Java available from non-free
Le jeudi 18 mai 2006 à 09:50 -0500, Anthony Towns a écrit : As a final note, did anyone from Debian who usually examines licences actually examine this one? Yes. At the election time, I hoped you could improve regarding communication skills, at least enough to become a project leader. This was obviously wrong. You haven't changed a bit, and such attitude may be a standard for a part of the ftp-master team, but it is not responsible behavior from the DPL. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Against DRM 2.0
This is very interesting: http://people.debian.org/~evan/ccsummary.html "You may not distribute, publicly display, publicly perform, or publicly digitally perform the Work with any technological measures that control access or use of the Work in a manner inconsistent with the terms of this License Agreement."There is not a clearly defined metric for determining if a measure is consistent with the terms of the license. See this license: http://www.freecreations.org/Against_DRM2.html "6. No DRM This license is incompatible with any technology, device or component that, in the normal course of its operation, is designed to prevent or restrict acts which are authorised or not authorised by licensor: this incompatibility causes the inapplicability of the license to the work.In particular: a. it is not possible to release validly under this license works or derivative works whose access control mechanism and/or copy control mechanism prevent or restrict quantitatively and/or qualitatively access to, fruition, copy, modification and/or sharing of them; b. in conformity with this license, it is not allowed to prevent or restrict quantitatively and/or qualitatively access to, fruition, copy, modification, and/or sharing of works or derivative works through an access control mechanism and/or a copy control mechanism; c. in conformity with this license, it is not allowed to prevent or restrict the exercise of a granted right through any digital, analog or physical method." Definitions: "Access control mechanism: a technological measure which, in the ordinary course of its operation, requires the application of information, or a process or a treatment, with the authority of the copyright owner or related rights owner, to gain access to the work." "Copy control mechanism: a technological measure which, in the ordinary course of its operation, prevents, restricts, or otherwise limits the exercise of a right of the copyright owner or related rights owner." "Acts authorised by licensor: acts concerning granted rights (in particular, act of access, act of copy, act of modification, act of sharing).""Acts not authorised by licensor: acts concerning copyright or possible moral rights." You say: "In the absence of any other information, technologies enabling private distribution of the work would seem to be forbidden. Along with obvious technological measures that control access, such as a firewall on a LAN or a virtual private network (VPN), distributing using encryption (such as Secure Sockets Layer (SSL)) would appear to be prohibited." Attention: License's area of applicability "This license concerns copyright and related rights: this license does not treat any other right. Nothing in this license is intended to prevent or restrict the exercise of rights not treated in this license, such as rights concerning privacy, private property, sale and other personal or private rights. Nothing in this license is intended to prevent or restrict the private use of any lawful technological measure".Real property, personal property, privacy, sale... : rights that the license does not treat.You keep all those rights. You can limit the access to your server. It's your right. You can use a firewall to defend your private property. It's your right. You can use encryption to defend your privacy or your private property. It's your right. You can also use privately any lawful technological measure.But, out of these cases, you cannot use encryption to prevent or restrict the exercise of a granted right. For example, you can sell a CD (only purchasers can access to the content of a CD for sale: it's clear! you can use also an alarm system :-D), but you cannot sell a CD with a copy control system or an access control system. But also the clause about related rights is very important: for example, If a phonogram-maker produces a CD with songs released under Against DRM 2.0, you can grab and share the CD! This is not allowed by any other license. I think that "Against DRM 2.0" is better than Creative Commons licenses. Max Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1/min.
Re: Sun Java available from non-free
Hi Anthony, On Thu, May 18, 2006 at 09:50:10AM -0500, Anthony Towns wrote: On Wed, May 17, 2006 at 11:09:30PM -0700, Don Armstrong wrote: As a final note, did anyone from Debian who usually examines licences actually examine this one? Yes. What did he/she think about the following clause? (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; All the best, Jochen -- http://seehuhn.de/ signature.asc Description: Digital signature
Re: Proposed licence for Debconf video recordings
Scripsit Francesco Poli [EMAIL PROTECTED] On Thu, 18 May 2006 19:56:21 +0100 Ben Hutchings wrote: The above copyright notice and this permission notice shall be -distributed with all copies and transcodings of the recording or +distributed with all copies, transformations and adaptations of the work or substantial portions thereof. I'm not sure if this phrasing tries to require that transformations and adaptations (a subset of derivative works) be licensed under the same license as the original work. I cannot see how this is different from how BSD licenses require that the BSD copyright blurb *itself* is retained with all derivates. Everybody seems to agree that this does not make the BSD license viral, and that a derivor is free to give fewer rights to his part of the copyright in the derived work than the original BSD author gave to his part. -- Henning MakholmI ... I have to return some videos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On Thu, May 18, 2006 at 09:50:10AM -0500, Anthony Towns wrote: On Wed, May 17, 2006 at 11:09:30PM -0700, Don Armstrong wrote: First off, I'm going to completely ignore the FAQ as the FAQ and the license both specifies that the FAQ does not have any legal validity. Repeating frequently asked questions that have already been answered isn't terribly useful. Using legally irrelevant answers for legal validation isn't terribly useful either, don't you think? As a final note, did anyone from Debian who usually examines licences actually examine this one? Yes. I take it you were too busy to elaborate on this when you wrote this email. So you will probably give us the name of this person later on, right? Or even better this person may stand up now and speak for himself and share his reasoning. 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: Sun Java available from non-free
Hi Michael, On Friday, 19 May 2006, you wrote: As a final note, did anyone from Debian who usually examines licences actually examine this one? Yes. I take it you were too busy to elaborate on this when you wrote this email. So you will probably give us the name of this person later on, right? Or even better this person may stand up now and speak for himself and share his reasoning. i hope it is just due to the lag of bandwidth, so AJ is just trying to use as little bandwidth as possible, to leave the rest for us, watching the videostream from outside. ;) Gruss Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Against DRM 2.0
On Fri, 2006-19-05 at 02:24 -0700, Max Brown wrote: This is very interesting: http://people.debian.org/~evan/ccsummary.html Yes it is. And thank you for proving the point I made earlier! You may not have noticed, but that summary and general opinion on debian-legal state that anti-DRM clauses inhibit more freedoms than they protect. I think that Against DRM 2.0 is better than Creative Commons licenses. That's an interesting opinion. Of course you know that the anti-DRM clause makes the license incompatible with the DFSG, right? There are many platforms that _require_ DRM -- notably Sony game consoles and some palmtop computers. The Against DRM license (which might win the contest for the license with the clumsiest name ever) would prevent me from porting any software to those platforms -- even if I made clear-text, modifiable and/or source versions available. Preventing me from making derivative works and porting them to different platforms, even if I take steps to ensure recipients' rights to use the works, is not DFSG-free. In the end, Against DRM is a single-issue license that's blunt and unnecessary. ~Evan P.S. The Creative Commons 3.0 licenses will allow parallel distribution -- both a DRM'd version and modifiable, clear-text version. They also make specific which kinds of technologies are covered. -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Against DRM 2.0
Very fine dissertation but... Evan, do you know that "Against DRM 2.0" does not treat software?? :-) ROFTL And why you don't speak about related rights? unnecessary license... :-) MaxEvan Prodromou [EMAIL PROTECTED] wrote:There are many platforms that _require_ DRM -- notably Sony gameconsoles and some palmtop computers. The "Against DRM" license (whichmight win the contest for the license with the clumsiest name ever)would prevent me from porting any software to those platforms -- even ifI made clear-text, modifiable and/or source versions available. How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates.
Re: Bacula license (was Re: Help Selecting License for Bacula Documentation
On Fri, May 19, 2006 at 08:00:25PM +0200, Kern Sibbald wrote: *trademark* unfairly and without permission. If I remember correctly, I pulled this clause from some existing license -- perhaps an IBM license. I am not a lawyer, but my understanding is that intellectual property right does not include copyright -- if it does, then In the USA, at least, it usually does. the clause does not do what I intended, because I have nothing against copyrights. It vaguely resembles this in the Postfix license: If Recipient institutes patent litigation against a Contributor with respect to a patent applicable to software (including a cross-claim or counterclaim in a lawsuit), then any patent licenses granted by that Contributor to such Recipient under this Agreement shall terminate as of the date such litigation is filed. In addition, If Recipient institutes patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Program itself (excluding combinations of the Program with other software or hardware) infringes such Recipient's patent(s), then such Recipient's rights granted under Section 2(b) shall terminate as of the date such litigation is filed. But this clause doesn't mention everybody globally. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula license (was Re: Help Selecting License for Bacula Documentation
On Fri, May 19, 2006 at 08:17:53PM +0200, Kern Sibbald wrote: John, could you or someone else summarize a bit where we are assuming the following? - I delete the anti-abuse paragraph from the LICENSE entitled: Termination for IP or Patent Action. - I change the manual license to be GPL v2. Specifically, what I would like to know is: are there any other problems with the licensing? I think that, to the best of my knowledge, those are the only problems. Has anyone else here read the IP rights section? A couple of minor nits: Near the end, change undert to under The address of the FSF has changed to: 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA Thanks, Kern, for being so open to discussing this with us. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula license (was Re: Help Selecting License for Bacula Documentation
I have just discovered that Bacula has a problematic clause in its license. From http://bacula.cvs.sourceforge.net/bacula/bacula/LICENSE?revision=1.6.2.2view=markup Termination for IP or Patent Action: In addition to the termination clause specified in the GPL, this license shall terminate automatically and you may no longer exercise any of the rights granted to you by this license as of the date you commence an action, including a cross-claim or counterclaim, against any licensor of GPL software alleging that the software infringes an intellectual property right or a patent. Special dispensation from or delay to the execution of this clause may be possible by applying directly to the license owner of this software. Such a dispensation or delay is valid only in writing and signed by the one or more of the license holders. This is an additional restriction beyond those in the GPL. Therefore this renders the license GPL-incompatible. Which is a major problem since other parts of Bacula are licensed under pure GPL. :-P Furthermore, it may not be DFSG-free. I don't think debian-legal has decided on this. The key point here is that this clause retaliates against someone who sues *any* licensor of *any* GPL software, not just the licensors of Bacula. The really disturbing part is that this isn't restricted to patents, put refers to an intellectual property right. This means that my license to use Bacula is revoked if I sue claiming that some GPL'ed work has included portions of my copyrighted code without permission, or claiming that some GPL'ed work has used my *trademark* unfairly and without permission. If I remember correctly, I pulled this clause from some existing license -- perhaps an IBM license. I am not a lawyer, but my understanding is that intellectual property right does not include copyright -- if it does, then the clause does not do what I intended, because I have nothing against copyrights. I suspect that this will not be considered a reasonable clause by most people on debian-legal. It effectively says As long as you use Bacula, you grant everyone in the world the right to use any or your copyrighted work in any GPLed program, and you grant eveyone in the world the right to use your trademark as a name or advertisement for any GPLed program. This can't be what was intended. Well, I cannot imagine how in the world the clause implies the above. It is an anti-abuse clause rather than one that gives permissions to use other people's software. I suggest to Kern that he just drop this clause. It doesn't operate as intended and it causes problems. Hopefully a satisfactory patent-retaliation clause will be avaialbe in a future version of the GPL. There is no need to respond to my remarks above other than to educate me on why the clause may say something totally unrelated to how I read it (your second point), because I have no problem dropping the clause. Kern PS: yes the comments from someone in another email on the terrible clause or whatever was written were probably not at the highest levels of diplomacy, but I didn't take offense, so no problem ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula license (was Re: Help Selecting License for Bacula Documentation
On Fri, May 19, 2006 at 08:00:25PM +0200, Kern Sibbald wrote: *trademark* unfairly and without permission. If I remember correctly, I pulled this clause from some existing license -- perhaps an IBM license. I am not a lawyer, but my understanding is that intellectual property right does not include copyright -- if it does, then In the USA, at least, it usually does. the clause does not do what I intended, because I have nothing against copyrights. It vaguely resembles this in the Postfix license: If Recipient institutes patent litigation against a Contributor with respect to a patent applicable to software (including a cross-claim or counterclaim in a lawsuit), then any patent licenses granted by that Contributor to such Recipient under this Agreement shall terminate as of the date such litigation is filed. In addition, If Recipient institutes patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Program itself (excluding combinations of the Program with other software or hardware) infringes such Recipient's patent(s), then such Recipient's rights granted under Section 2(b) shall terminate as of the date such litigation is filed. But this clause doesn't mention everybody globally. Hmmm. I don't think I have ever seen the Postfix license, but someone else has probably picked it up, and applying it more globally is almost surely something I have added. In any case, I have now deleted that clause from my current working copy. -- John Best regards, Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula license (was Re: Help Selecting License for Bacula Documentation
On Thu, May 18, 2006 at 08:10:30PM +0100, MJ Ray wrote: That's how I understand the clause too. Contaminates other software (DFSG 9). I'm amazed it got into main. Serious bug. How does that contaminate other software? I agree that there may be a problem, but only for users of Bacula. I would like to understand that as well, especially since I explicitly indicate in LICENSE that certain parts of the code not copyrighted by myself are licensed under the GPL with no modifications. John, could you or someone else summarize a bit where we are assuming the following? - I delete the anti-abuse paragraph from the LICENSE entitled: Termination for IP or Patent Action. - I change the manual license to be GPL v2. Specifically, what I would like to know is: are there any other problems with the licensing? Best regards, Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[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: Bacula license (was Re: Help Selecting License for Bacula Documentation
On Fri, May 19, 2006 at 08:17:53PM +0200, Kern Sibbald wrote: John, could you or someone else summarize a bit where we are assuming the following? - I delete the anti-abuse paragraph from the LICENSE entitled: Termination for IP or Patent Action. - I change the manual license to be GPL v2. Specifically, what I would like to know is: are there any other problems with the licensing? I think that, to the best of my knowledge, those are the only problems. Has anyone else here read the IP rights section? If you haven't already read it, then please don't bother. I have now removed that clause from my working source copy. A couple of minor nits: Near the end, change undert to under Thanks. It is now corrected. The address of the FSF has changed to: 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA Thanks, corrected. Thanks, Kern, for being so open to discussing this with us. Thanks for the thanks. That is the way I *try* to do everything :-) Best regards, Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
Jochen Voss [EMAIL PROTECTED] writes: What did he/she think about the following clause? Not that I'm that person (first I heard of any of this was the announcement), but this seems like as good of a place as any to make the point that to me is obvious but that no one else seems to be making. (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; The interpretation of that clause rests both on what conjunction means and on whether one believes the presence of a clearly stated interpretation in the accompanying FAQ, regardless of disclaimers on that FAQ, might still constitute estoppel. Given that Sun has stated that their interpretation of conjunction is basically what Debian would call a derivative work and has done so publicly in accompanying documentation, I'd be very interested in a legal opinion on whether they would be barred by estoppel from reneging on that interpretation and applying the more restrictive interpretations advanced here at some future date. The fact that the FAQ says that it's not the license terms and is not legally binding as such doesn't strike me as necessarily relevant; the question is not whether the FAQ is a legal document, but rather what interpretation Sun puts on the words used in the license. My (non-lawyer) understanding of estoppel is that public statements like the FAQ, even with disclaimers attached, are relevant. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Against DRM 2.0
Fine remark, but... Max, did you know that Debian requires *everything*, not just software, to be DFSG-free? Not that it's particularly relevant since there isn't a huge amount under the Against DRM license, but... On 5/20/06, Max Brown [EMAIL PROTECTED] wrote: Very fine dissertation but... Evan, do you know that Against DRM 2.0 does not treat software?? :-) ROFTL And why you don't speak about related rights? unnecessary license... :-) Max Evan Prodromou [EMAIL PROTECTED] wrote: There are many platforms that _require_ DRM -- notably Sony game consoles and some palmtop computers. The Against DRM license (which might win the contest for the license with the clumsiest name ever) would prevent me from porting any software to those platforms -- even if I made clear-text, modifiable and/or source versions available. How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call rates. -- Andrew Donnellan http://andrewdonnellan.com http://ajdlinux.blogspot.com Jabber - [EMAIL PROTECTED] --- Member of Linux Australia - http://linux.org.au Debian user - http://debian.org Get free rewards - http://ezyrewards.com/?id=23484 OpenNIC user - http://www.opennic.unrated.net
Sun responds to questions on the DLJ
All: Let me start by repeating the message that Simon and I gave to you at Debconf: there is every reason for us to be friends and working with you is very important for Sun. Please consider: - We consider the FAQ [2] to be an accurate representation of the intent of this license [1] and do not consider it to be irrelevant. - Ignoring the FAQ is not helpful as it answers many of their questions (it's a FAQ, after all). - The DLJ represents a very significant shift in Sun's approach to licensing by trusting that distributors will do the right thing (so that JDK works AND is integrated with the OS while adhering to OS standards and policies). - We think our intent is pretty clear - if it isn't, we're happy to clarify and incorporate those clarifications into updates to the FAQ. - The design of the license which refers to the README is like pointer to an object: the technical details in the README can change without having to revise the license. We are planning to revise the README to further clarify and give explicit permission to relocate or even modify certain files (e.g. font.properties) needed to make the system run properly. Let me try to clarify the following: + SECTION 2(a) Special care was taken in crafting the debian copyright file to adequately implement the direction given by: http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html http://www.us.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile Indeed I wrote a script (albeit an ugly hack) to craft the conforming debian/copyright file from a package preamble, the copyright notice for Debian packaging, the license for Debian packaging, the copyright notice for upstream, the license for upstream and any third party notices and licenses. + 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. + SECTION 2(d) A bug was fixed in debconf 1.5.1 so that a user with the Gnome (GUI) front end could Cancel the installation. Otherwise the package has been configured that if the debconf key for accepting the DLJ has not been pre-accepted that the installation will be canceled if the license cannot be presented. This is an excellent example of leveraging Debian infrastructure to comply with these DLJ terms. I am pleased to have worked with some of you on the first implementation of packaging under the DLJ. I was hoping just to get java in the PATH I'm very impressed that the result demonstrates: - Not just PATH integration and man page integration using Debian alternatives but indeed a new consensus based solution for marshaling several related alternatives (including plugin for many browsers) leveraging JPackage conventions. This builds on the 1-N features of alternatives (with slaves) to handle the M-N problem (M plugin providers, N web browsers). Pretty cool stuff -- and uniquely Debian. (see java-common for details). - Applets work correctly (including sound) - Java Web Start works correctly (this is really nice). - Desktop (Gnome) integration works. - The power of debconf is demonstrated in allowing the license to be presented in a character terminal, a GUI, or for large server installations pre-seeded for noninteractive installation. - The layout of the bits conforms to FHS and JPackage conventions while preserving the legacy JAVA_HOME directory tree approach. - The work with Debian has highlighted several bugs, RFE's and general opportunities for improvement in our upstream bundles... Most notably to reduce unnecessary duplication and better handle the architecture dependent and independent parts. Put together I am very pleased by the result: the level of integration and quality of feedback has surpassed anyone's expectations and highlighted that the step to loosen control and liberalize the license for Java will reap huge benefits from community involvement. 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. Respectfully, --Tom [1] DLJ http://download.java.net/dlj/DLJ-v1.1.txt [2] DLJ-FAQ http://download.java.net/dlj/DLJ-FAQ-v1.1.txt signature.asc Description: OpenPGP digital signature
Re: Sun responds to questions on the DLJ
Tom Marble schrieb am Freitag, den 19. Mai 2006: All: Let me start by repeating the message that Simon and I gave to you at Debconf: there is every reason for us to be friends and working with you is very important for Sun. Please consider: - We consider the FAQ [2] to be an accurate representation of the intent of this license [1] and do not consider it to be irrelevant. It has no legal relevance so it has to be ignored. - Ignoring the FAQ is not helpful as it answers many of their questions (it's a FAQ, after all). Its maybe not helpfull, but unfortunatly the only thing we have to consider is the license. Let me cite your own faq: Note: This FAQ is provided to help explain the Operating System Distributor License for Java; nothing in this FAQ is intended to amend the license, so please consult the license itself for the precise terms and conditions that actually apply. The license has to be changed, thats all I want to say Alex
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
Re: Sun Java available from non-free
David wrote: Even worse is how question 8 of the FAQ contradicts section 2c of the license since this has much graver consequences: 8. Does this license prevent me shipping any alternative technologies in my OS distribution? The DLJ does not restrict you from shipping any other technologies you choose to include in your distribution. (2c) 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; According to the FAQ, the JDK ``does not restrict [me] from shipping *any* other technologies'' (emphasis mine), but according to the license I cannot ``distribute the [JDK] to run in conjunction with any additional software that implements the same or similar functionality or APIs as the [JDK]''. This directly seems to rule out GNU Classpath, GCJ, or Apache XML Commons since they implement the exact same API's as the JDK. Trying to read Sun's words over again, it seems to me that what Sun is saying here is not that you can't distribute the other technologies, but that you can't distribute them to run *with* the Sun JDK. That's how I interpret the phrase to run in conjunction with. That is, they don't mind if Classpath, gcj, etc are distributed by Debian and installed on the system. They don't mind if we use them ourselves, either. What they're asking is that we do not reconfigure the Sun JDK to use, say, GNU Classpath instead of the Sun classpaths. They seem to be asking for the two implementations to be kept completely out of each other's way. So that would make it non-free, but not unsuitable for Debian's non-free repository. Drew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun responds to questions on the DLJ
On Fri, 19 May 2006, Tom Marble wrote: Let me start by repeating the message that Simon and I gave to you at Debconf: there is every reason for us to be friends and working with you is very important for Sun. Thanks for comming to Debconf; the discussions were interesting even if there were disagreements at times. Please consider: - We consider the FAQ [2] to be an accurate representation of the intent of this license [1] and do not consider it to be irrelevant. Is the FAQ legally binding on Sun? - Ignoring the FAQ is not helpful as it answers many of their questions (it's a FAQ, after all). The reason why I have ignored the FAQ is because the language in the FAQ and within the license explicitly claims that the FAQ is not legally binding and is meaningless. If, by this, you're telling us that it is binding on Sun, then I will cease ignoring it in future analyses of the license I make. - The design of the license which refers to the README is like pointer to an object: the technical details in the README can change without having to revise the license. We are planning to revise the README to further clarify and give explicit permission to relocate or even modify certain files (e.g. font.properties) needed to make the system run properly. It would be nice if the license would change section 14 to make this part explicit so it's obvious that the README has some legal ramifications upon 2a. Let me try to clarify the following: + SECTION 2(a) Special care was taken in crafting the debian copyright file to adequately implement the direction given by: http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html http://www.us.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile Indeed I wrote a script (albeit an ugly hack) to craft the conforming debian/copyright file from a package preamble, the copyright notice for Debian packaging, the license for Debian packaging, the copyright notice for upstream, the license for upstream and any third party notices and licenses. I guess I'm a bit lost here as to what this clarifies for the issues I've identified in 2a. + 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? + SECTION 2(d) A bug was fixed in debconf 1.5.1 so that a user with the Gnome (GUI) front end could Cancel the installation. Otherwise the package has been configured that if the debconf key for accepting the DLJ has not been pre-accepted that the installation will be canceled if the license cannot be presented. This is an excellent example of leveraging Debian infrastructure to comply with these DLJ terms. The point here was that it's possible in Debian to preseed the key that the package checks to see if it's presented the license or not so that the package never actually presents the license. This is extreemly trivial to do. Put together I am very pleased by the result: the level of integration and quality of feedback has surpassed anyone's expectations and highlighted that the step to loosen control and liberalize the license for Java will reap huge benefits from community involvement. 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. As a final note, I just wish that these issues with the DLJ were resolved before the license was presented a fait a compli; those of us who participate in debian-legal are here to make sure that all decisions that are taken in regards to works that are present in Debian are taken with a full accounting of all of the problems present in the licenses. We are not easy to satisfy, but because many people trust Debian to be very careful with what it distributes, it's a task that we and the ftpmasters who make the final decisions do not take lightly. In the future if there's a desire to keep some strategic move under wraps, it's always possible to bring a group of people who are active here into confidence to resolve issues with the license so that what should have been a PR coup for Sun doesn't cause such a problem in the community that Sun wants to be a part of. Don Armstrong -- Those who begin coercive elimination of
Re: Sun Java available from non-free
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Drew Parsons wrote: Trying to read Sun's words over again, it seems to me that what Sun is saying here is not that you can't distribute the other technologies, but that you can't distribute them to run *with* the Sun JDK. That's how I interpret the phrase to run in conjunction with. It says that you cannot combine, configure, or distribute certain software in conjunction with the Sun JDK. I outlined in my email previous to this one various ways in which a distribution might violate this straightaway (meaning, without even doing anything different from what the distribution already has been doing). You're right that the key word seems to be ``conjunction'', but nothing says, for example, that you are fine if the software in question is shipped in a separate package. Currently, I don't know of any distribution that has tried to replace Sun's rt.jar with GNU Classpath's rt.jar. In fact, you can't really do this right now as the two are incompatible. But there are some things that can be done right now. For example, ecj can be configured to replace Sun's javac, and the Apache XML API's may be configured to replace Sun's XML classes, or anything may be done via modification of the bootclasspath. So, if the distribution is configured in various ways (via alternatives, shell scripts, etc.) it may be violate this. - -- Sincerely, David Walluck [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFEboGtN5thZBYlTwkRAmdeAKCB2vzQwU90tqEa+FLWCQ8arSKamwCaAzsD Q/6E1Nm4FTY+n+bvky+CmXE= =qKEC -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun responds to questions on the DLJ
Don Armstrong wrote: On Fri, 19 May 2006, Tom Marble wrote: Thanks for comming to Debconf; the discussions were interesting even if there were disagreements at times. It was really great to be there... I enjoyed meeting you and many other Debian Developers. Perhaps the biggest thing for me to grok was that Debian isn't as much a technical organization as a social organization that happens to produce very interesting technical works. - The design of the license which refers to the README is like pointer to an object: the technical details in the README can change without having to revise the license. [...] It would be nice if the license would change section 14 to make this part explicit so it's obvious that the README has some legal ramifications upon 2a. It is my understanding that, due to the wording, the README actually has legal weight. Let me try to clarify the following: + SECTION 2(a) Special care was taken in crafting the debian copyright file to adequately implement the direction given by: [...] I guess I'm a bit lost here as to what this clarifies for the issues I've identified in 2a. There was a comment, This seems to cause a problem with actually packaging the software unless the Debian package counts as the Software and as Joerg gave specific recommendations on how to unambiguously specify which parts of the copyright refer to which parts of the bundle it was appropriate to leverage this convention to be completely explicit. + 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. + SECTION 2(d) A bug was fixed in debconf 1.5.1 so that a user with the Gnome (GUI) front end could Cancel the installation. Otherwise the package has been configured that if the debconf key for accepting the DLJ has not been pre-accepted that the installation will be canceled if the license cannot be presented. This is an excellent example of leveraging Debian infrastructure to comply with these DLJ terms. The point here was that it's possible in Debian to preseed the key that the package checks to see if it's presented the license or not so that the package never actually presents the license. This is extreemly trivial to do. Yes, and this is a feature, not a bug. One of the reasons that Debian is great is the ability to do fully automated installs and such. The point of presenting the license is that an individual, corporation, non-profit or other entity has had a chance to review and agree to the DLJ. If a user or administrator pre-seeds the key for DLJ acceptance on behalf of herself or her group then it is perfectly acceptable to install Sun Java on 1 or 10,000 nodes. 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 JRE and JDK each have been split into different Debian packages to best fit with Debian Policy. Partly this work is an innovative approach to reduce redundancy (e.g. have the JDK depend on the JRE), partly to refactor architecture independent and dependent components and partly to better integrate with Debian (e.g include the -font package giving defoma integration *only* if that font is not already on the system and managed by defoma). The numerous symlinks are intended to give backwards compatibility with the JAVA_HOME (one directory tree) approach that many users are used to (and certain executables depend upon for compatibility). 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. I am certain that we will need input here... your offer is appreciated. I recently started reading Benker's book based on the advice of Lessig [1] (whom I hold in high esteem). It's a captivating read [2]: If the transformation I describe as possible occurs, it will lead to substantial redistribution of power and money from the twentieth-century industrial producers of information, culture, and
