Re: Sun Java available from non-free
Executive Summary: There are serious issues with clause 2a, 2b, 2c, 2f, and 4; and lesser issues with other bits of this license. As much as some of our users would like to see us distributing this JDK in non-free, I'm really not sure that it can be distributed while complying with the license or without incurring unreasonable burdens upon our mirror operators and Debian. I'd recommend that ftp-masters consider pulling this package from non-free until these issues are resolved (or at least understood.) 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. I'm also going to rip out the bits of the license which I don't feel are particularly useful; this doesn't mean that they don't have problems, only that I haven't seen them in a rapid pass through of the license.[0] As a final note, did anyone from Debian who usually examines licences actually examine this one? [At any time if you're unsure of a license, but don't want to disclose the new terms publicly you should be contacting someone who routinely does this kind of examination so this sort of problem doesn't occur. I'm always willing to help clarify the issues facing Debian in regards to both free and non-free licenses; I assume other contributors to -legal are willing to as well.] 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.) (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. (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.) (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... (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] 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. 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. A yeah! Now everyone gets to suffer! 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
Re: Help Selecting License for Bacula Documentation
Kern Sibbald [EMAIL PROTECTED] I suppose this is a possibility, but with the current license, this shouldn't be possible, though I admit I hadn't thought about it. I doubt, however, if this is a real possibility, since who has the means to publish paper copies and give them away free? Two examples come to mind: 1. people using them as marketing material: magazines, journals... 2. people with grudges, seeking to destroy competitors. In any case I wouldn't want to work with any hacker company -- rather publishing a company like O'Reilly, with possibly an independent editor, who knows Bacula well, as has been discussed on our list. To be clear, by hacker company, I meant companies run by hackers, such as www.network-theory.co.uk, rather than companies run by an ex-proprietary software company director that arbitrarily blacklists projects and sells things off to DMCA-happy companies. -- MJR/slef Laux nur mia opinio: vidu http://people.debian.org/~mjr/ Bv sekvu http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On Wed, May 17, 2006 at 10:21:27PM +0200, Francesco Poli wrote: I'm really disappointed: what's the use of spending time on debian-legal, when the Project seems to ignore us? As far as I can tell the packages were accepted from NEW in a very short time frame (~ 5hours). Maybe the admin who accepted the packages could tell us why he did and why he did in such a timely fashion. I am certainly interested in his reasoning. Michael P.S.: CCing ftpmaster so this admin definitely gets this email and can identify himself. -- 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: [JPackage-discuss] Sun Java available from non-free
Hi David, Roughly, the way that I read the new license, you must distribute the Sun JDK ``alone'' (as per section (2c)). Moreover, you must not develop any applications with this JDK---you may only use it to build packages that will be shipped with your Operating System (as per section (2b)). From the DLJ FAQ: 4. What does the DLJ allow me to do? You can: * Use the JDK on your OS to design, develop, test, and run Java programs (...) 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [JPackage-discuss] Sun Java available from non-free
[EMAIL PROTECTED] schrieb am Donnerstag, den 18. Mai 2006: Hi David, Roughly, the way that I read the new license, you must distribute the Sun JDK ``alone'' (as per section (2c)). Moreover, you must not develop any applications with this JDK---you may only use it to build packages that will be shipped with your Operating System (as per section (2b)). From the DLJ FAQ: 4. What does the DLJ allow me to do? You can: * Use the JDK on your OS to design, develop, test, and run Java programs (...) 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. You accept the licence, not the FAQ. If it comes to court its irelevant. Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OpenSAML
[EMAIL PROTECTED] wrote: sufficient legal existence to sign such an agreement. My intuition is that, unless we have fairly firm knowledge that this patent is invalid (and I haven't seen any sign of that), this means that OpenSAML is not distributable by Debian (even in non-free). No. The policy of Debian is to ignore patents unless we know that they are being actively enforced. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The FAQ and the license directly contradict one another. In such cases, the license must prevail. Question 4 of the FAQ directly contradicts section 2b of the license: 4. What does the DLJ allow me to do? You can: - Use the JDK on your OS to design, develop, test, and run Java programs. (2b) [You can use the JDK] 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 According to the FAQ I ``can develop [any] Java program'' I want, but according to the license I can ``solely ... develop ... [p]rograms to be run under the control of [my] [o]perating [s]ystem''. 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. In addition, the language ``any additional software that implements the same or similar functionality as the [JDK]'' can effectively be used to rule out *anything*, specifically other languages like C, C++, PHP, etc. - -- 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 iD8DBQFEbESTN5thZBYlTwkRArlDAJ45vid/X3IXkTuwplZ2/t3znchrJwCgjMWx OqUAnv5b4XkIHC1rL+xp4jk= =ownx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License of wget.texi: suggest removal of invariant sections
Don Armstrong [EMAIL PROTECTED] writes: Summary: The issue with wget.texi is that the GNU GPL is an Invariant Section; since the GNU GPL cannot be modified anyway, this just forces gpl.texi to always be distributed with wget.texi, even when you're just distributing the manual. The GPL text is an integral part of the manual, so just distributing the manual, at least in its current form, implies distributing the GPL in some form. Note that gpl.texi can always be merged into the manual -- in fact, previous revisions of the manual had the GPL text inline. But that (whether the GPL is in a separate file or in wgettexi) is surely just a technical detail. If the point you're making is that someone might want to remove the GPL text from the manual, for example to make it shorter, I guess that's a valid concern. The reason why this poses a problem for Debian is because it requires the GNU GPL to always be included with wget.texi, even when nothing which is actually GPLed is being distributed along with wget.texi. Debian requires that everything that we distribute in main to be modifiable; that is, so modified that it can actually be deleted. I don't understand this objection. Including the text of the GPL in Wget's manual serves the purpose of explaining Wget's copying terms to the user. As such, it seems pertinent regardless of whether Wget is actually distributed along with the manual. If I am misunderstanding your objection, please let me know. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#365408: [POLICY-PROPOSAL] Drop java*-runtime/compiler, create classpath-jre/jdk and java-jre/jdk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cc'ing to debian-legal: summary: The major question is about replacing java1-runtime, java1-compiler, java2-runtime and java2-compiler virtual packages by classpath-jre, classpath-jdk for free java implementation and java-jre and java-jdk for non-free implementations. More informations on the bug report #365408. Thanks to Cc to the bug report. Charles Fry a écrit : [...] But I strongly disagree with using classpath-* for free versions, and saving java for non-free implementations. That encourages the use of the non-free implementations. No because java programs that work with free implementations will depend on classpath-jre. How about java-* for both free and non-free, and then if some package explicitely requires non-free they can depend on sun-java5-jre. I think we have to ask on debian-legal about this but I'm sure we cannot use the java word if it's not something that has been approved by Sun. Cheers, - -- .''`. : :' :rnaud `. `' `- Java Trap: http://www.gnu.org/philosophy/java-trap.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEbE0i4vzFZu62tMIRAnAvAJ9TtTttz+a46PRaC3yb8nPxGKAgTACfQdfq GMUyaRnDFDjt/or3Og+Dg6o= =vHE4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#365408: [POLICY-PROPOSAL] Drop java*-runtime/compiler, create classpath-jre/jdk and java-jre/jdk
Arnaud Vandyck [EMAIL PROTECTED] The major question is about replacing java1-runtime, java1-compiler, java2-runtime and java2-compiler virtual packages by classpath-jre, classpath-jdk for free java implementation and java-jre and java-jdk for non-free implementations. More informations on the bug report #365408. Thanks to Cc to the bug report. The java* virtual package names should not direct people to non-free implementations when there are free implementations available. This is a project-y opinion rather than a legal-y one. Charles Fry a Âcrit : [...] But I strongly disagree with using classpath-* for free versions, and saving java for non-free implementations. That encourages the use of the non-free implementations. No because java programs that work with free implementations will depend on classpath-jre. I think enough users will ask for Java in particular to cause problems. How about java-* for both free and non-free, and then if some package explicitely requires non-free they can depend on sun-java5-jre. I think we have to ask on debian-legal about this but I'm sure we cannot use the java word if it's not something that has been approved by Sun. A virtual package name is a functional label, not a product name. Java is the name of an island and a natural language too. I'm surprised if Sun can prevent use of a word in this way. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Question
Hello, I sent this message to debian-nonprofit list and got very quick response from Jonas. Many thanks. He advised me to write my question on this list as more suitable. So here it is My name is Marcin Giedz. Together with my two colleagues we have founded AltVision Group company. Our goals are: 1) produce cross-platform software - document workflow, ERP etc... based on QT 2) bring some new hardware dedicated for Linux 3) start sophisticated trainings for Linux administrators 4) make Debian be more attractive not only for servers but also for Desktops. As we all have grown up on Debian distribution we would like be bring this environment as the main basis for our mission. To be sure that we are not another training facility in Poland we have done some researches. The results were far enough and quite predictable: people want certificates to prove their knowledge. H. how the hell can we provide them such papers related to Debian exams??? And this is my question. We now that Debian is Open Community. So from commercial point of view there is no organization which we can make an agreement to become Debian certificated training center. But there are people responsible for releases, maintaining and some top team about Debian project anyway. IS there any way to contact with someone from this head? I tried to find some emails but with no success. That's why I thought about mailing list. Do you know any emails that I can make further step? Thank you VERY much. Best regards, Marcin Giedz begin:vcard fn:Marcin Giedz n:Giedz;Marcin org:AltVision Group;Network New Technologies adr;dom:;;Polna 11;Warszawa;;00-633 email;internet:[EMAIL PROTECTED] title:Application Engeener tel;work:+48 0 22 825 85 08 tel;cell:+48 502 537 157 url:http://www.altvision.pl version:2.1 end:vcard
Re: Help Selecting License for Bacula Documentation
Kern Sibbald [EMAIL PROTECTED] I suppose this is a possibility, but with the current license, this shouldn't be possible, though I admit I hadn't thought about it. I doubt, however, if this is a real possibility, since who has the means to publish paper copies and give them away free? Two examples come to mind: 1. people using them as marketing material: magazines, journals... I explicitly permit the above. 2. people with grudges, seeking to destroy competitors. Yea, well, in this case, can you hear my little tiny violin playing in sympathy with them :-) In any case I wouldn't want to work with any hacker company -- rather publishing a company like O'Reilly, with possibly an independent editor, who knows Bacula well, as has been discussed on our list. To be clear, by hacker company, I meant companies run by hackers, such as www.network-theory.co.uk, rather than companies run by an ex-proprietary software company director that arbitrarily blacklists projects and sells things off to DMCA-happy companies. If by hacker you mean in the sense of the word as I originally learned it, OK, I have no problem. I was thinking of hacker in the somewhat unfortunate current sense of a smart bad guy. -- MJR/slef Laux nur mia opinio: vidu http://people.debian.org/~mjr/ Bv sekvu http://www.uk.debian.org/MailingLists/#codeofconduct Best regards, Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help Selecting License for Bacula Documentation
Benjamin Seidenberg wrote: Kern Sibbald wrote: John Goerzen wrote: I'm forwarding, with permission, parts of a message from Kern Sibbald, author of Bacula and its manual. The current manual, which has a license listed at http://www.bacula.org/rel-manual/index.html, is not DFSG-free. However, Kern has indicated a willingness to consider other license arrangements. Kern's main concern (correct me if I'm wrong, Kern) is that he doesn't want someone to be able to publish and sell paper versions of the manual. Yes, this is correct, but with the nuance, that I would be very happy to see the manual published in physical form provided there is an agreement for a reasonable financial contribution to the project, which should take into account normal royalties and how much work the publisher (or whoever transforms it) has to do to get it in a publishable form. In my other email, I attempt to explain my reasoning behind this. While this is an understandable viewpoint, and one that I can sympathize with, any license that would provide protection such as you describe would most definitely be in violation of the DFSG, and as such, not distributable by debian, at least in the main section (though possibly in non-free). On the other hand, note that the GPL requires that distributors notify recipients about the Free Software status of the work, which would allow people to know hey, I could get this for free online; this might achieve a similar effect to what you desire. Furthermore, I don't know for sure, but a carefully worded license *might* manage to require a specific notice as to the unofficial, non-endorsed status of the manual, while still remaining DFSG-free. You could then specifically grant distributors the rights to call themselves an official and/or endorsed manual in exchange for whatever auxiliary licensing terms you want. Hmmm. Possibly having an invariant section (or whatever it is called) stating the unofficial, non-endorsed status of any commercially printed version of the manual would do what you suggest. I'm going to try to come up with some such wording over the next week, but if you or someone else could suggest such a carefully worded license for the Bacula manual that would be acceptable to Debian, it would for me be a good solution, and I would very likely accept it -- obviously, I would like to see the wording before making a firm commitment ... Best regards, Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License of wget.texi: suggest removal of invariant sections
On Thu, 18 May 2006, Hrvoje Niksic wrote: If the point you're making is that someone might want to remove the GPL text from the manual, for example to make it shorter, I guess that's a valid concern. Yes, that's the issue. Including the text of the GPL in Wget's manual serves the purpose of explaining Wget's copying terms to the user. As such, it seems pertinent regardless of whether Wget is actually distributed along with the manual. To reiterate what you said above, our problem is that the GPL can't be removed at all,[1] even when it's no longer applicable, not that it's being included by wget.texi in the first place. [Whether the GPL is pertinent or not is really up to each distributor of the package, but it stops being necessary once the package no longer contains any GPLed code.] Sorry for the confusion there. Don Armstrong 1: This is really the only practical change that making the GPL an Invariant Section causes; it really should be called in this case an Unremovable Section. -- A people living under the perpetual menace of war and invasion is very easy to govern. It demands no social reforms. It does not haggle over expenditures on armaments and military equipment. It pays without discussion, it ruins itself, and that is an excellent thing for the syndicates of financiers and manufacturers for whom patriotic terrors are an abundant source of gain. -- Anatole France http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Help Selecting License for Bacula Documentation
Kern Sibbald wrote: Benjamin Seidenberg wrote: Kern Sibbald wrote: John Goerzen wrote: I'm forwarding, with permission, parts of a message from Kern Sibbald, author of Bacula and its manual. The current manual, which has a license listed at http://www.bacula.org/rel-manual/index.html, is not DFSG-free. However, Kern has indicated a willingness to consider other license arrangements. Kern's main concern (correct me if I'm wrong, Kern) is that he doesn't want someone to be able to publish and sell paper versions of the manual. Yes, this is correct, but with the nuance, that I would be very happy to see the manual published in physical form provided there is an agreement for a reasonable financial contribution to the project, which should take into account normal royalties and how much work the publisher (or whoever transforms it) has to do to get it in a publishable form. In my other email, I attempt to explain my reasoning behind this. While this is an understandable viewpoint, and one that I can sympathize with, any license that would provide protection such as you describe would most definitely be in violation of the DFSG, and as such, not distributable by debian, at least in the main section (though possibly in non-free). On the other hand, note that the GPL requires that distributors notify recipients about the Free Software status of the work, which would allow people to know hey, I could get this for free online; this might achieve a similar effect to what you desire. Furthermore, I don't know for sure, but a carefully worded license *might* manage to require a specific notice as to the unofficial, non-endorsed status of the manual, while still remaining DFSG-free. You could then specifically grant distributors the rights to call themselves an official and/or endorsed manual in exchange for whatever auxiliary licensing terms you want. Hmmm. Possibly having an invariant section (or whatever it is called) stating the unofficial, non-endorsed status of any commercially printed version of the manual would do what you suggest. Well, Debian doesn't allow invariant sections, but I would think that requiring a prominent notice on any derived work stating it is an unofficial and endorsed work would be ok. I'm going to try to come up with some such wording over the next week, but if you or someone else could suggest such a carefully worded license for the Bacula manual that would be acceptable to Debian, it would for me be a good solution, and I would very likely accept it Sadly, that's really not my forte - could someone who spends more time on -legal help Kern out? -- obviously, I would like to see the wording before making a firm commitment ... Of course. Best regards, Kern Cheers! Benjamin signature.asc Description: OpenPGP digital signature
Re: Question
Marcin Giedz [EMAIL PROTECTED] And this is my question. We now that Debian is Open Community. So from commercial point of view there is no organization which we can make an agreement to become Debian certificated training center. But there are people responsible for releases, maintaining and some top team about Debian project anyway. IS there any way to contact with someone from this head? I tried to find some emails but with no success. That's why I thought about mailing list. Do you know any emails that I can make further step? I am not sure what you are wanting to obtain. Licence to use the debian trademark is currently issued/revoked as directed by the DPL [EMAIL PROTECTED] on a case-by-case basis, as there is still no free trademark licence nor useful debian policy on it. General commercial questions may be best on debian-consultants General debian-related training questions may be best on debian-mentors Hope that helps, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Creative Commons 3.0 Licenses
I wanted to draw the attention of the debian-legal list to the upcoming release of the public draft of the Creative Commons 3.0 licence suite: http://lists.ibiblio.org/pipermail/cc-licenses/2006-May/003557.html The main changes to these licenses has been to bring them in line with the DFSG and make at least the Attribution and Attribution-ShareAlike 3.0 licenses compatible with the DFSG and acceptable for Debian. For those of you who haven't seen it, there is a debian-legal summary of the 2.0 licenses here: http://people.debian.org/~evan/ccsummary Once the public draft is available, I'm going to try to coordinate a response from the Debian Creative Commons Workgroup, but I'd also love to see some open discussion on debian-legal. I think everyone's goal is to have these licenses work with Debian, and if we fumble it in this last phase, it'd be a real shame. After the licenses are released, I'd like to put up a summary of the 3.0 licenses similar to the 2.0 summary. If it's decided that (some) licenses are compatible with the DFSG, I'd like to make that public. ~Evan -- 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: License of wget.texi: suggest removal of invariant sections
Don Armstrong [EMAIL PROTECTED] writes: On Thu, 18 May 2006, Hrvoje Niksic wrote: If the point you're making is that someone might want to remove the GPL text from the manual, for example to make it shorter, I guess that's a valid concern. Yes, that's the issue. I see. But that's still quite different than the issue you describe below, which is about the GPL no longer applying to Wget (as opposed to the issue of the GPL text making the manual too long). Including the text of the GPL in Wget's manual serves the purpose of explaining Wget's copying terms to the user. As such, it seems pertinent regardless of whether Wget is actually distributed along with the manual. To reiterate what you said above, our problem is that the GPL can't be removed at all,[1] even when it's no longer applicable, not that it's being included by wget.texi in the first place. What I don't understand is how the GPL can be no longer applicable, given that it's not possible to change Wget's license. If the copyright holder (in this case the FSF) decided to change the license, surely they could also remove the invariant section? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License of wget.texi: suggest removal of invariant sections
On Thu, 18 May 2006, Hrvoje Niksic wrote: Don Armstrong [EMAIL PROTECTED] writes: On Thu, 18 May 2006, Hrvoje Niksic wrote: If the point you're making is that someone might want to remove the GPL text from the manual, for example to make it shorter, I guess that's a valid concern. Yes, that's the issue. I see. But that's still quite different than the issue you describe below, which is about the GPL no longer applying to Wget (as opposed to the issue of the GPL text making the manual too long). I mean that the issue is the same (inability to remove the GPL from the manual), even though there are different reasons why you may want to do that. Including the text of the GPL in Wget's manual serves the purpose of explaining Wget's copying terms to the user. As such, it seems pertinent regardless of whether Wget is actually distributed along with the manual. To reiterate what you said above, our problem is that the GPL can't be removed at all,[1] even when it's no longer applicable, not that it's being included by wget.texi in the first place. What I don't understand is how the GPL can be no longer applicable, given that it's not possible to change Wget's license. If I just distribute wget.texi (and gfdl.texi and gpl.texi) by themselves, the GPL no longer applies because there is nothing there which is GPLed. [The GPL and GFDL are inherently incompatible, so the manual can't be both GPLed and GFDLed, so it has to be licensed under one or the other.] Don Armstrong -- EQUAL RIGHTS FOR WOMEN Don't be teased or humiliated. See their look of surprise when you step right up to a urinal and use it with a smile. Get Dr. Mary Evers' EQUAL-NOW Adapter (pat. appld. for) -- purse size, fool proof, sanitary -- comes in nine lovely, feminine, psychadelic patterns -- requires no fitting, no prescriptions. -- Robert A Heinlein _I Will Fear No Evil_ p470. http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: UC license and debian
Bill Allombert [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Notes: (1)Insert the first year the software was made available to the public as well as any subsequent years in which a modified version is made available. The last two paragraphs must be in capital letters to comply with the Uniform Commercial Code. Ah finally a bit of fun: a claim that warranty disclaimers must be in capital letters. Eben Moglen disagree... Eben Moglen is correct. UCC 2A-124.2: Subject to subsection (3), to exclude or modify the implied warranty of merchantability or any part of it the language must mention merchantability, be by a writing, and be conspicuous. Subject to subsection (3), to exclude or modify any implied warranty of fitness the exclusion must be by a writing and be conspicuous. Language to exclude all implied warranties of fitness is sufficient if it is in writing, is conspicuous and states, for example, There is no warranty that the goods will be fit for a particular purpose. Quite simply the disclamer must be in writing and be conspicuous. Conspicuous is the key word there. It was propably intended to mean that it cannot be hidden in fine print. Regardless, an all caps header preceding it saying something like WARRANTY DISCLAMER: certainly would make the notice conspicuous. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help Selecting License for Bacula Documentation
John Goerzen wrote: I'm forwarding, with permission, parts of a message from Kern Sibbald, author of Bacula and its manual. The current manual, which has a license listed at http://www.bacula.org/rel-manual/index.html, is not DFSG-free. However, Kern has indicated a willingness to consider other license arrangements. I always say: use the same license as you used for the program. This is the best thing to do 90% of the time or more. You are mostly using the GPL, with extra permissions and disclaimers. This is a fine license for documentation. Kern's main concern (correct me if I'm wrong, Kern) is that he doesn't want someone to be able to publish and sell paper versions of the manual. With a GPL-licensed manual, it would be a pain in the neck for anyone to publish and sell paper versions of the manual, as they would have to include the source code to the manual on CD (or equivalent) with the manual. I have argued that they would also have to include the source code for such details as the fonts, the cover art, the binding, and so forth. While this is certainly possible, it is extremely unlikely that any publisher would go to the trouble to do that, and even more unlikely that they'd do so without getting permission from Kern. Is it possible to get a license that would be both DFSG-free and meet Kern's requirements? Would the FDL work in some fashion (given our recent GR on the subject?) No. The FDL is specifically designed *for* paper copies to be made and sold. -- Nathanael Nerode [EMAIL PROTECTED] Read it and weep. http://rawstory.com/news/2005/Text_of_Gore_speech_0116.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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. 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. 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. -- Nathanael Nerode [EMAIL PROTECTED] This space intentionally left blank. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Debconf-video] Re: Proposed licence for Debconf video recordings
Francesco Poli wrote: On Mon, 15 May 2006 03:34:12 +0100 Ben Hutchings wrote: This is a proposed licence text for the Debconf video recordings (and potentially other audio and video recordings), based on the MIT/X licence: Here's the text: Copyright (c) year copyright holders Permission is hereby granted, free of charge, to any person obtaining a copy of this recording, to deal in the recording without [...] Does this appear free and reasonably applicable to such recordings? It seems to make the recordings to comply with the DFSG. However, I would prefer not seeing the term recording in the license. A more general term such as work would be better suited, IMHO. Yes, I see your point. I also reemembered after posting that we would want the licence to be applicable to DVDs which also include some still images and text. snip The lack of a clear distinction between source and binary for video means that the licence is much more like copyleft than the originali (but without any mention of a preferred form). I don't think that this license could in any way be seen as a copyleft. It does permit me to create a proprietary derivative work, so it's definitely a non-copyleft license. Not an issue, though: I pointed this out just to make things clearer... The licence is contingent upon distributing its own text with any copy of the work or (at least some forms of) derivative work. I thought that that implied the author of the derivative work would grant the same permissions. But perhaps it could be distributed simply as information about the original work. The MIT/X licence doesn't place the same requirement on distributed binaries, AIUI. Ben. -- Ben Hutchings All extremists should be taken out and shot. signature.asc Description: Digital signature
Re: Bacula license (was Re: Help Selecting License for Bacula Documentation
On Thu, May 18, 2006 at 01:54:46PM -0400, Nathanael Nerode wrote: I have just discovered that Bacula has a problematic clause in its license. Thanks for mentioning this, Nathanael. I had read the license, but had assumed (incorrectly, I guess) that Jose had already evaluated it here before uploading the package. [ snip ] 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 Does the permission to link with OpenSSL also make it GPL-incompatible? How about the Windows clauses, which of course don't apply to us? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Debconf-video] Re: Proposed licence for Debconf video recordings
[Sorry for the dupe, Don. I meant to reply only to these lists.] Don Armstrong wrote: On Mon, 15 May 2006, Ben Hutchings wrote: snip Thanks for the diff. This is pretty much is just the XFree86 license; I don't think there's any problem with works under this licence being considered DFSG Free. Does this appear free and reasonably applicable to such recordings? I seem to remember that there are some specific legal terms relating to copyright of audio recordings. Is there a legal term that would cover transcoding? There are probably a couple, but I'm not quite sure what you're asking for here. snip Transcoding is a technical term that might not be understood in law. There is a term mechanical translation but I'm not sure whether that refers to machine translation of human language or also to format conversion. Ben. -- Ben Hutchings All extremists should be taken out and shot. signature.asc Description: Digital signature
Re: Help Selecting License for Bacula Documentation
Kern Sibbald wrote: Benjamin Seidenberg wrote: Kern Sibbald wrote: John Goerzen wrote: I'm forwarding, with permission, parts of a message from Kern Sibbald, author of Bacula and its manual. The current manual, which has a license listed at http://www.bacula.org/rel-manual/index.html, is not DFSG-free. However, Kern has indicated a willingness to consider other license arrangements. Kern's main concern (correct me if I'm wrong, Kern) is that he doesn't want someone to be able to publish and sell paper versions of the manual. Yes, this is correct, but with the nuance, that I would be very happy to see the manual published in physical form provided there is an agreement for a reasonable financial contribution to the project, which should take into account normal royalties and how much work the publisher (or whoever transforms it) has to do to get it in a publishable form. In my other email, I attempt to explain my reasoning behind this. While this is an understandable viewpoint, and one that I can sympathize with, any license that would provide protection such as you describe would most definitely be in violation of the DFSG, and as such, not distributable by debian, at least in the main section (though possibly in non-free). On the other hand, note that the GPL requires that distributors notify recipients about the Free Software status of the work, which would allow people to know hey, I could get this for free online; this might achieve a similar effect to what you desire. Furthermore, I don't know for sure, but a carefully worded license *might* manage to require a specific notice as to the unofficial, non-endorsed status of the manual, while still remaining DFSG-free. You could then specifically grant distributors the rights to call themselves an official and/or endorsed manual in exchange for whatever auxiliary licensing terms you want. Hmmm. Possibly having an invariant section (or whatever it is called) stating the unofficial, non-endorsed status of any commercially printed version of the manual would do what you suggest. I didn't mean to suggest an invariant section; DFSG-free works can't have invariant sections. I simply meant requiring some form of notice, much like the GPL requires that you include appropriate copyright and license notice. I'm going to try to come up with some such wording over the next week, but if you or someone else could suggest such a carefully worded license for the Bacula manual that would be acceptable to Debian, it would for me be a good solution, and I would very likely accept it -- obviously, I would like to see the wording before making a firm commitment ... How about something vaguely along the lines of this: If you publish this work in paper form, you must conspicuously and appropriately publish on each copy a notice of the unofficial, non-endorsed status of the work. Notice the intentional lack of specific wording or placement required for such a notice. I modelled this after the GPL's clause 1. Note, though, that any such clause will likely make your documentation GPL-incompatible, which will likely cause problems down the road given that Bacula uses the GPL. I personally would suggest just using the GPL on the manual, and relying on the fact that the GPL requires a conspicuous and appropriate notice as to the GPL status of the work; and furthermore, that any distributor would need to either include the full source to the manual or an offer for such. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: License of wget.texi: suggest removal of invariant sections
Hrvoje Niksic wrote: Don Armstrong [EMAIL PROTECTED] writes: On Thu, 18 May 2006, Hrvoje Niksic wrote: Including the text of the GPL in Wget's manual serves the purpose of explaining Wget's copying terms to the user. As such, it seems pertinent regardless of whether Wget is actually distributed along with the manual. To reiterate what you said above, our problem is that the GPL can't be removed at all,[1] even when it's no longer applicable, not that it's being included by wget.texi in the first place. What I don't understand is how the GPL can be no longer applicable, given that it's not possible to change Wget's license. If the copyright holder (in this case the FSF) decided to change the license, surely they could also remove the invariant section? Don't just think in terms of the software the current manual describes (namely Wget), which of course remains GPLed. First, you could distribute the Wget manual without distributing Wget, in which case the GPL itself no longer obligates you to include it since you don't distribute GPLed software, but the Wget manual license notice requires you to continue distributing it. Second, you might modify the manual to make a smaller form, such as a manual page, and want to avoid including more extra text than you need to. Third, someone might want to adapt some part of the Wget manual for their own documentation, which might document an LGPLed library, or a MIT-licensed work, and thus shouldn't have to include a potentially confusing third license. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Sun Java available from non-free
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. As a final note, did anyone from Debian who usually examines licences actually examine this one? Yes. Cheers, aj signature.asc Description: Digital signature
Re: Proposed licence for Debconf video recordings
Here's a new draft. I've changed recording to work throughout and replaced transcode with transform and adapt, based on the terminology CC uses. --- debconf-video-licence.draft12006-05-14 21:18:51.0 -0500 +++ debconf-video-licence.draft22006-05-18 13:48:51.226221352 -0500 @@ -1,20 +1,20 @@ Copyright (c) year copyright holders Permission is hereby granted, free of charge, to any person obtaining -a copy of this recording, to deal in the recording without +a copy of this work, to deal in the work without restriction, including without limitation the rights to use, copy, -transcode, modify, merge, publish, distribute, sublicense, and/or sell -copies of the recording, and to permit persons to whom the recording +transform, adapt, modify, merge, publish, distribute, sublicense, and/or sell +copies of the work, and to permit persons to whom the work is furnished to do so, subject to the following conditions: 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. -THE RECORDING IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, +THE WORK IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION -WITH THE RECORDING OR THE USE OR OTHER DEALINGS IN THE RECORDING. +WITH THE WORK OR THE USE OR OTHER DEALINGS IN THE WORK. -- Ben Hutchings All extremists should be taken out and shot. signature.asc Description: Digital signature
Re: UC license and debian
Joe Smith [EMAIL PROTECTED] UCC 2A-124.2: [...] for example, There is no warranty that the goods will be fit for a particular purpose. Quite simply the disclamer must be in writing and be conspicuous. Conspicuous is the key word there. Even better, the example is not WRITTEN AS A PARAGRAPH OF CAPS. It was propably intended to mean that it cannot be hidden in fine print. Regardless, an all caps header preceding it saying something like WARRANTY DISCLAMER: certainly would make the notice conspicuous. Could putting the disclaimer in the middle of a paragraph of caps - making it hard to read - make it inconspicuous? I hope so. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- 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
Nathanael Nerode [EMAIL PROTECTED] 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. That's how I understand the clause too. Contaminates other software (DFSG 9). I'm amazed it got into main. Serious bug. Who wrote that horror and could they please not write licences again until they fix that one? -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On 5/18/06, Anthony Towns aj@azure.humbug.org.au 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. But I guess the question should be answered by the license, not by the FAQ. As a final note, did anyone from Debian who usually examines licences actually examine this one? Yes. Who?
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. Who wrote that horror and could they please not write licences again until they fix that one? Probably Kern Sibbald, author of Bacula, whom you CC'd. You could have been a little more polite, I think. -- 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 Thu, May 18, 2006 at 01:27:55PM -0500, John Goerzen wrote: On Thu, May 18, 2006 at 01:54:46PM -0400, Nathanael Nerode wrote: 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 Does the permission to link with OpenSSL also make it GPL-incompatible? No, because it's an additional permission, not an additional restriction. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On Thu, 18 May 2006, 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. Unfortunatly, in this case the FAQ claims that the license says something which the license doesn't actually say. The licence specifies that you're indemnifying Sun for problems in Debian, or problems that result from the interaction or use of Debian with the covered code. Obvioiusly, without using Debian, it would not be possible for someone to use the JDK with Debian. Thus, the clause applies (the FAQ's holding to the contrary notwithstanding) even when the problem is actually an issue or assumption present in Sun's code. This is why ignoring the FAQ is almost always the only conservative method of reading the license. Don Armstrong -- It has always been Debian's philosophy in the past to stick to what makes sense, regardless of what crack the rest of the universe is smoking. -- Andrew Suffield in [EMAIL PROTECTED] http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Proposed licence for Debconf video recordings
On Thu, 18 May 2006 19:56:21 +0100 Ben Hutchings wrote: Here's a new draft. This is an improvement. [...] 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. [...] Does this change try to create a (very) weak copyleft? 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. Can anyone share her/his thoughts? -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp1gbUPaLGqT.pgp Description: PGP signature
Re: [Debconf-video] Re: Proposed licence for Debconf video recordings
On Thu, 18 May 2006 19:15:20 +0100 Ben Hutchings wrote: Francesco Poli wrote: On Mon, 15 May 2006 03:34:12 +0100 Ben Hutchings wrote: [...] The lack of a clear distinction between source and binary for video means that the licence is much more like copyleft than the originali (but without any mention of a preferred form). I don't think that this license could in any way be seen as a copyleft. It does permit me to create a proprietary derivative work, so it's definitely a non-copyleft license. Not an issue, though: I pointed this out just to make things clearer... The licence is contingent upon distributing its own text with any copy of the work or (at least some forms of) derivative work. I thought that that implied the author of the derivative work would grant the same permissions. But perhaps it could be distributed simply as information about the original work. It must accompany the derivative work as the license for the parts that come from the original work. The license states: | distributed with all copies and transcodings of the recording or | substantial portions thereof I don't think that a transcoding is a derivative work (assuming that I correctly understand what you mean by transcoding): it's a mechanical (i.e. non creative) transformation. Hence, the license text must accompany *copies* and *substantial portions* of the original work. Not a derivative work as itself: only the substantial portions of the original work that may be included in the derivative work. Every creative contribution that is added (in order to obtain the derivative work) may be under a different license. If a proprietary license is chosen, the derivative work is effectively proprietary (until you manage to reextract the parts under the permissive license, if at all possible). Hope this clears things up. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgppzqWVawpMM.pgp Description: PGP signature
Re: Bacula license (was Re: Help Selecting License for Bacula Documentation
On Thu, 18 May 2006 13:54:46 -0400 Nathanael Nerode wrote: I have just discovered that Bacula has a problematic clause in its license. Thanks for pointing this terrific clause out. From http://bacula.cvs.sourceforge.net/bacula/bacula/LICENSE?revision=1.6.2.2view=markup Termination for IP or Patent Action: [...] 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 Indeed a major problem (and possibly a copyright violation, if those pure-GPL'd parts are copyrighted by other people that didn't agree with this hyper-retaliation clause). Furthermore, it may not be DFSG-free. I don't think debian-legal has decided on this. My vote is this does not comply with the DFSG. 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. Overly broad restriction: unacceptable. I suspect that this will not be considered a reasonable clause by most people on debian-legal. Indeed. 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. I suggest to Kern that he just drop this clause. It doesn't operate as intended and it causes problems. Dropping the clause is the best resolution, no doubt about it. Hopefully a satisfactory patent-retaliation clause will be avaialbe in a future version of the GPL. I don't know: I don't even know whether future versions of the GPL will comply with the DFSG... :-( -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpOlk9hcNVYb.pgp Description: PGP signature
Re: Sun Java available from non-free
Hi *DPL*, Anthony Towns aj@azure.humbug.org.au writes: 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. The problem is that the FAQ itself says that it *has* no legal value, so we can simply ignore it when checking the license. As a final note, did anyone from Debian who usually examines licences actually examine this one? Yes. Could the person responsible for checking the license please come out and explain why the concerns several people have raised are not a problem for the distribution of the sun java package? I mean, I'd love if we would be able to distribute Sun's Java, but not under these circumstances. And, BTW, I'm not at all impressed by your way of dealing with concerns of other DDs. Marc -- BOFH #199: the curls in your keyboard cord are losing electricity. pgpc9GMdGT2ep.pgp Description: PGP signature
Re: Sun Java available from non-free
On Wed, 17 May 2006 23:09:30 -0700 Don Armstrong wrote: Executive Summary: [...] I'd recommend that ftp-masters consider pulling this package from non-free until these issues are resolved (or at least understood.) Agreed. [...] 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.) You're right: this is another major issue. (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. Right! I hadn't noticed this point before. I hereby retract my statement about 2(b) not being violated by Debian. It seems that the Debian Project is indeed violating this clause too. (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.) Exactly. (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... And that's another problem, thanks for catching it up. (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] Maybe... 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. [...] As I already said, we are in chains... -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpWhPSvnLWjT.pgp Description: PGP signature
Re: Sun Java available from non-free
Anthony Towns schrieb am Donnerstag, den 18. Mai 2006: 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. This is not the way a DPL should answer, we were asking important questions and its our right to get sane answers. As a final note, did anyone from Debian who usually examines licences actually examine this one? Yes. I give nothing about an analysis I haven't seen from somebody I dont know. Uploading such a package with such a license without any discussion is a shame for Debian. Some not mentioned ftp-master waved the package (as the only package) through after a few hours, beside that this ftp-master didn't processed NEW for a long time. This all really smells strong and after reading the license carefully and talked with several other people I came to the conclusion that I have to do anything that I can to get this out of debian again. This is not the freedom I'm standing for. And after all thats not the way I wanted a project I'm working in to act, I see this way of acting as a personal affront to me and my Debian work... This really went wrong and I want to have some _good_ explanations or we will have to bear the consequences. Alex signature.asc Description: Digital signature
Re: OpenSAML
(Please cc me on replies, as I'm not subscribed to debian-legal. Let me know if I need to subscribe for this discussion.) Brian M Carlson [EMAIL PROTECTED] writes: You are correct. I didn't even give more than a cursory glance to the license, because whether or not it's free is moot. I will quote from Policy 2.3: We reserve the right to restrict files from being included anywhere in our archives if * their use or distribution would break a law, * there is an ethical conflict in their distribution or use, * we would have to sign a license for them, or * their distribution would conflict with other project policies. I'm not going to start on the ethics of patents because this license violates point 3. In other words, even if the license is DFSG-free, if it requires a signature, it's unacceptable for the archive as a whole. Good point. That's even more obvious than the line of reasoning I was using. However, I also just got good news. Apparently at the same time that I was investigating this, extended efforts towards getting RSA to relicense their patents paid off. RSA has now licensed the patents under the following statement: In the interest of encouraging deployment of SAML-based technologies, RSA hereby covenants, free of any royalty, that it will not assert any claims in the RSA Patents which may be essential to the SAML standard v1.0, 1.1 and 2.0 (hereinafter NECESSARY CLAIMS) against any other entity with respect to any implementation conforming to the SAML standard v1.0, 1.1 and/or 2.0. This covenant shall become null and void with respect to any entity that asserts, either directly or indirectly (e.g. through an affiliate), any patent claims or threatens or initiates any patent infringement suit against RSA and/or its subsidiaries or affiliates. The revocation of the covenant shall extend to all prior use by the entity asserting the claim. I'd appreciate a second set of eyes from the debian-legal perspective, but I believe this is sufficient for Debian's purposes, is similar to the patent clauses on other software in the archive, and will remove the last obstacle preventing OpenSAML from being considered DFSG-free. Please note that this is not the *license* (the license for the package is the same Apache 2.0 license used for Apache itself), and hence the comment about patent claims against RSA doesn't invalidate the software *license*, only the guarantee by RSA that it won't enforce its patents. The full statement of patent grants related to SAML is posted at: http://www.oasis-open.org/committees/security/ipr.php Note that this page is somewhat confusing in that the grants at the top of the page supersede grants farther down on the page from the same entities. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
