Re: Results for Debian's Position on the GFDL
Anthony DeRobertis writes: I believe there are essentially two reconciliations we can have for each problem listed in the position statement [2]: Either that does not make things non-free or that is not the intended reading of the license, stop nit-picking so much. For the DRM restriction, I think that that is not the intended reading of the license applies. The FSF clearly did not intend to keep people from using chmod on a GFDL document, and did not intend other problems pointed out. The sloppy wording is not a danger, as no one is going to take legal action over such issues, and if they did, courts tend to interpret these things using reasonable standards, not like robots. It still would be advisable for the FSF to make the language clear. For the Transparent and Opaque Copies provision, I think Anthony is right on the FTP server question, and the other issues brought up in this section give reasons why the GFDL is sometimes a PITA, but just because the PITA provisions differ from those in the GPL don't necessarily put the provisions over the line; it's a judgment call, and the Debian developers have evidently made the judgment that the issue is tolerable. Remember, the words This is a compromise appear in the DFSG, despite the fact that the denizens of debian-legal resist compromise. That is, the necessity to make a written offer good for three years is sometimes painful, as is the necessity to keep a transparent copy available for one year. I did not understand why debian-legal found the latter provision a DFSG violation. I can understand why people don't like it, but evidently the Debian developers don't think it's worth throwing away most of the documentation over. PITA = pain in the ass, BTW -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
On Sat, Mar 11, 2006 at 11:01:19PM -0500, Anthony DeRobertis wrote: However, Option 1 was the consensus of this list, and thus we've been overridden[0]. I feel that we now need to figure out why the project as a whole has rejected the draft position statement [2] and render our The GFDL has more serious problems than most licenses, and Debian has stuck its rubber stamp on them; we're stuck with them, probably for good. I'm sure any pretense from the FSF of trying to fix these problems will be dropped entirely now, since Debian has said they're OK. The project has asserted that onerous practical problems are acceptable. Message-Id: [EMAIL PROTECTED] lists some other problems found on a quick reading, not all mentioned in the old position statement. Also, any other problems found in the license can no longer be considered DFSG- unfree, no matter how bad they are; this GR forces any such problems to be contrived as free. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute has been mis-read. I don't think there is any way the Project would consider you must make all your files a+r, etc. a free license. I propose that the Project is telling us that something along the following is the true reading: You may not use technical measures to obstruct or control the reading or further copying [by the intended recipient] of [all] the copies you make or distribute [to him] The Project can't say what the true reading is. Only the license and the copyright holder can determine that. The Project has no power, by GR or otherwise, to define the interpretation of someone else's license. This GR also did not say the GFDL is free, as long as this and that interpretation of the license are held; it makes no such qualification. The Project is telling us that it's Free to prohibit encrypting a document, since that's what a straightforward reading of the GFDL does. Even if the FSF has clarified that it's not *their* intention, that's only partially waiving the clause for only the FSF's works. I can put a document under the GFDL, and say the 'technical measures' clause is, in fact, intended to prohibit encrypting the document. That's not bending or twisting the license; it's merely confirming a straightforward interpretation. This GR says that it's free to prohibit you from sending the document over https, or to attach it to a message GPG-encrypted. (The silly thing is just how worthless this clause really is. Merely requiring source be available--you know, the preferred form for modification--prevents any effective DRM. This ill-conceived clause didn't even need to be there, and now Debian has to consider it free.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
* Don Armstrong: In any case, we've been working with the FSF to resolve these issues as well, so hopefully a new version of the GFDL will no longer posess them. Does this mean that there will be a new version of the GFDL, finally, or just a different FSF-endorsed documentation license (which would require relicensing and all the hassles that involves)? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
On Sun, 12 Mar 2006, Florian Weimer wrote: * Don Armstrong: In any case, we've been working with the FSF to resolve these issues as well, so hopefully a new version of the GFDL will no longer posess them. Does this mean that there will be a new version of the GFDL, finally, or just a different FSF-endorsed documentation license (which would require relicensing and all the hassles that involves)? I hope the former will happen, but the later may be more likely. Eben has publicly said that there will be a new draft of the GFDL proposed during the v3 process, but I don't know whether that will superceed the current version, or be a fork of it. That's really up to the FSF. Don Armstrong -- Build a fire for a man, an he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -- Jules Bean http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Free documents using non-free fonts - can they be in main?
Francesco Poli [EMAIL PROTECTED] wrote: On 05 Mar 2006 12:03:00 +0100 Claus Färber wrote: Frank Küster [EMAIL PROTECTED] schrieb/wrote: The reason for this is that building (La)TeX documentation * depends on the right number and order of commands to be executed, which one has to find by trial and error (it's very rare that authors upload Makefiles, since usually they aren't needed much) * depends on settings in local configuration files, which may differ from package author to package author and from version to version. In other words, there is no _complete_ source code for the compiled version of the documentation, which violates DFSG #2 (even without the font issue). Well, it seems so... Sorry, how do you two come to that conclusion? There's on automated build system. Whether the upstream author writes \OnlyDescription in the dtx file or in his ltxdoc.cfg does not change whether source code is available. Whether he used teTeX 2.0.2 or 3.0 doesn't, either. If it is really so difficult to figure out how to rebuild, even for knowledgeable people, then, yes, something is missing. Come on, having a comfortable, or even a sane build system isn't a prerequisite for being free. Typsetting just isn't as automatable as compiling executables with autotools. Especially if you made changes to the sources, there's no alternative to actually looking at the resulting document with your eyes and your subjective aesthetic judgement. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: better licence for fosdem, debconf, .., videos...
Francesco Poli [EMAIL PROTECTED] On Fri, 10 Mar 2006 01:16:13 + MJ Ray wrote: Removing credit when requested to do so is not an issue outlined in Evan Prodromou's summary. The problem was having to remove *all* references to the author (thereby creating a possible termination clause, significantly restricting modification of some works and so on), rather than credits. In my view, Removing credit when requested to do so is an improved-but-not-really-solved version of the Removing references issue. This is what I meant. I see it as significantly different. If it was all references, you could be effectively stopped from using their work in a biography of the author or a project history, for example. It also combined awkwardly with other requirements, IIRC. For a Derivative Work, I'm pretty sure that the law about false attribution allows the original author to demand they not be credited with it. This requirement seems like a no-op included to make the attribution clause consistent with the law. Could you please provide a pointer to the relevant articles of the copyright (or author's right) law you're referring to? I wasn't able to find such a right from a quick review of the Italian Author's Right Law (I mainly searched among moral rights...). Are you thinking about UK Copyright Law, perhaps? Or US Copyright Law? UK Law, as this licence is for the law of Scotland. I think http://www.jenkins-ip.com/patlaw/cdpa1.htm#s84 is the legislation and a credit is attribution. Now I'm puzzled: in the pornographic image example, does This image is based on the desk image created by Bob qualify as crediting Bob? I think it does, and at the same time corresponds to claiming that the derived image is based on the original image (which is true and should be allowed to be said, I think). I think it depends where and how based on the desk image created by Bob is stated. Your porno image may have other problems: I can't remember if that is derogatory treatment. The other problem is absent, so it's a fairly small lawyerbomb, rather than a clear failure to follow any guideline. It could be interpreted in various ways, some of which are non-free. We've always said we must be conservative and assume the worst interpretation: that's what I did and it resulted in considering this clause a violation of the DFSG... I don't recall ever agreeing that. I think I usually note the lawyerbomb and advise checking each work in such cases. Of course, I'd agree works under such a licence don't necessarily follow the DFSG, but I think we have other licences like that, especially ones with optional freedom-breakers. Hope that explains, -- 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: Results for Debian's Position on the GFDL
Scripsit Andrew Donnellan [EMAIL PROTECTED] Option 2 says GFDL works without invariant sections are free. Does this include GFDL manuals where the *only* invariant section is the GFDL itself? I am be inclined to think that such works would be free following the GR; the restrictions for invariant sections are ones that we traditionally do accept for license texts. -- Henning Makholm It will be useful even at this early stage to review briefly the main features of the universe as they are known today. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
Scripsit Anthony DeRobertis [EMAIL PROTECTED] You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute has been mis-read. I don't think there is any way the Project would consider you must make all your files a+r, etc. a free license. I propose that the Project is telling us that something along the following is the true reading: You may not use technical measures to obstruct or control the reading or further copying [by the intended recipient] of [all] the copies you make or distribute [to him] But how can we explain away make or? -- Henning Makholm Den nyttige hjemmedatamat er og forbliver en myte. Generelt kan der ikke peges på databehandlingsopgaver af en sådan størrelsesorden og af en karaktér, som berettiger forestillingerne om den nye hjemme- og husholdningsteknologi. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
Anthony DeRobertis wrote: However, Option 1 was the consensus of this list, and thus we've been overridden[0]. I feel that we now need to figure out why the project as a whole has rejected the draft position statement [2] -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 25a628e9-d88e-40x7-8e1c-888cff421ea5 [ ] Choice 1: pi = 3.141592653589793238462643383279502884197169399375105820 [ ] Choice 2: pi = 3.14 [ ] Choice 3: pi = 3 [needs legislature of Indiana approval] [ ] Choice 4: further discussion -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- Attempts to legislate pi are always questionable, and when you ask a majority of uninformed voters[3] to choose between items, it's natural for the compromise to win, and not unheard of for it to end up 3. -- see shy jo [3] ie, people such as myself who might have appeared to read every message on every thread on this list, but IANAL and didn't have time/energy to follow each argument in depth signature.asc Description: Digital signature
(OT) Re: Results for Debian's Position on the GFDL
[ ] Choice 3: pi = 3 [needs legislature of Indiana approval] Attempts to legislate pi are always questionable, and when you ask a majority of uninformed voters[3] to choose between items, it's natural for the compromise to win, and not unheard of for it to end up 3. Funny thing is that pi=3 was the official value taught in Japanese schools in the last few years when pupils were introduced to the value, since it was considered that decimal numbers were too complex... This has been reverted last year if I remember well. Jean-Christophe Helary -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
Anthony DeRobertis [EMAIL PROTECTED] wrote: I believe there are essentially two reconciliations we can have for each problem listed in the position statement [2]: Either that does not make things non-free or that is not the intended reading of the license, stop nit-picking so much. Or that the GR changed the DFSG, and the proponents managed to browbeat the secretary into not requiring a 3:1 majority. Cheers, Walter Landry [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
Glenn Maynard [EMAIL PROTECTED] wrote: On Sat, Mar 11, 2006 at 11:01:19PM -0500, Anthony DeRobertis wrote: However, Option 1 was the consensus of this list, and thus we've been overridden[0]. I feel that we now need to figure out why the project as a whole has rejected the draft position statement [2] and render our The GFDL has more serious problems than most licenses, and Debian has stuck its rubber stamp on them; we're stuck with them, probably for good. I'm sure any pretense from the FSF of trying to fix these problems will be dropped entirely now, since Debian has said they're OK. The project has asserted that onerous practical problems are acceptable. An interesting practical effect of this vote is that only FSF documents are excluded from main. Cheers, Walter Landry [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Free documents using non-free fonts - can they be in main?
Frank Küster [EMAIL PROTECTED] wrote: Francesco Poli [EMAIL PROTECTED] wrote: On 05 Mar 2006 12:03:00 +0100 Claus Färber wrote: Frank Küster [EMAIL PROTECTED] schrieb/wrote: The reason for this is that building (La)TeX documentation * depends on the right number and order of commands to be executed, which one has to find by trial and error (it's very rare that authors upload Makefiles, since usually they aren't needed much) * depends on settings in local configuration files, which may differ from package author to package author and from version to version. In other words, there is no _complete_ source code for the compiled version of the documentation, which violates DFSG #2 (even without the font issue). Well, it seems so... Sorry, how do you two come to that conclusion? There's on automated build system. Sorry, that should have been: There's *no* automated build system. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Results for Debian's Position on the GFDL
Walter Landry [EMAIL PROTECTED] writes: Or that the GR changed the DFSG, and the proponents managed to browbeat the secretary into not requiring a 3:1 majority. Well, fortunately 1) the winning option did have a 3:1 majority and 2) the option requiring a 3:1 majority did not reach even a simple majority. You can of course argue that the voters might vote differently based on the majority requirement. I personally doubt that and would like any such arguments to include some sort of proof. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
Joe Buck [EMAIL PROTECTED] For the DRM restriction, I think that that is not the intended reading of the license applies. The FSF clearly did not intend to keep people from using chmod on a GFDL document, and did not intend other problems pointed out. [...] What do you base that clear intention on? I thought RMS ultimately refused to discuss the implications of the anti-DRM with us when asked. -- http://lists.debian.org/debian-legal/2003/09/msg00825.html For the Transparent and Opaque Copies provision, [...] I did not understand why debian-legal found the latter provision a DFSG violation. [...] I wasn't aware that we had, outside of limited situations where no Transparent Copy of the work exists. What do you mean? Mostly, that clause is a PITA and a practical problem for the archive network AIUI. Remember, the words This is a compromise appear in the DFSG, despite the fact that the denizens of debian-legal resist compromise. That is your opinion or interpretation, not a fact. Many posters spend a lot of time searching for everyone wins compromises. For the FDL, I feel the best everyone wins is a new version. Hoping for answers, -- 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]
no longer a bug.
from the documentation in question: Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Sections being ``GNU General Public License'' and ``GNU Free Documentation License'', with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled ``GNU Free Documentation License''. The only things the documentation license holds as invariant are the GPL and the GFDL themselves, and Debian already accepts those as being invariant, this documentation should no longer be considered non-free in light of GR-2006-01. But becuase of this, I'm copying debian-legal. -stew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
Anthony DeRobertis [EMAIL PROTECTED] [...] I feel that we now need to figure out why the project as a whole has rejected the draft position statement [2] and render our future --- and possibly re-render our past --- interpretations of the DFSG in accordance. It is unfortunate that no thorough, point-by-point rebuttal of the position statement was given on -vote or -legal (to the best of my knowledge; I'd love to be wrong). [...] More than unfortunate, it makes that ambition impossible without telepathy or further surveying, as far as I can see. There seems little point just guessing what motives produced a pi=3 statement. It should be noted that even though the Standard Resolution Procedure resolved the disagreement, a 211:145 (roughly 3:2) split when comparing the first two options is hardly a great consensus. There remains a deep division over whether FDL'd works follow DFSG. Personally, I find it disappointing that so many people ranked opposite views high, then FD below them. I think the no, no matter what description of FD in the ballot is unhelpful and deters compromise attempts. I don't think we've insincere voting patterns, but strange ones:- ; grep -c 'V: 12..' vote_001_tally.txt 67 ; grep -c 'V: 11..' vote_001_tally.txt 5 ; grep -c 'V: 21..' vote_001_tally.txt 59 Looks to me like voting for a resolution, no matter what it says, rather than making two opposing views seek compromise. Hope that explains, -- 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: Results for Debian's Position on the GFDL
Kalle Kivimaa [EMAIL PROTECTED] wrote: Walter Landry [EMAIL PROTECTED] writes: Or that the GR changed the DFSG, and the proponents managed to browbeat the secretary into not requiring a 3:1 majority. Well, fortunately 1) the winning option did have a 3:1 majority You're right. I did not notice that. That makes the analysis much simpler. The developers, in their wisdom, essentially changed DFSG #10 to add the GFDL without invariant sections. I still don't see how Debian can comply with keeping the source to every version for a year, or with the DRM requirements. But that is for the ftp-masters to figure out. Cheers, Walter Landry [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: no longer a bug.
Mike O'Connor [EMAIL PROTECTED] wrote: from the documentation in question: Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Sections being ``GNU General Public License'' and ``GNU Free Documentation License'', with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled ``GNU Free Documentation License''. The only things the documentation license holds as invariant are the GPL and the GFDL themselves, and Debian already accepts those as being invariant, this documentation should no longer be considered non-free in light of GR-2006-01. But becuase of this, I'm copying debian-legal. Unfortunately, no. The GFDL already requires that the license be included in the document, so putting it in an invariant section does not change anything. However, that is not true for the text of the GPL. If someone wants to reuse the documentation for a BSD-licensed work, the GPL would be completely off topic. Cheers, Walter Landry [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (OT) Re: Results for Debian's Position on the GFDL
On Mon, Mar 13, 2006 at 12:24:12AM +0900, JC Helary [EMAIL PROTECTED] wrote: [ ] Choice 3: pi = 3 [needs legislature of Indiana approval] Attempts to legislate pi are always questionable, and when you ask a majority of uninformed voters[3] to choose between items, it's natural for the compromise to win, and not unheard of for it to end up 3. Funny thing is that pi=3 was the official value taught in Japanese schools in the last few years when pupils were introduced to the value, since it was considered that decimal numbers were too complex... This has been reverted last year if I remember well. You'll have to come up with much better than words for people to believe in that. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#323099: no longer a bug.
Mike O'Connor [EMAIL PROTECTED] The only things the documentation license holds as invariant are the GPL and the GFDL themselves, and Debian already accepts those as being invariant, this documentation should no longer be considered non-free in light of GR-2006-01. But becuase of this, I'm copying debian-legal. As the 3:2 split between the original and amended texts shows, there is still no consensus that works under the FDL follow the DFSG. Too soon to say how GR-2006-01 influences these bugs, in my opinion. Unfortunately, the FDL also appears to have practical problems, including either needing source in the binary package, or a long-life URL. Again, I'm not sure what the effect of that is. Finally, the GPL is not invariant: IIRC, you can edit it if you delete the preamble [see http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL ]. Debian contains the version we received, though. On debian systems, the GPL is in /usr/share/common-licenses and packages should refer to it rather than include another copy. 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]
Re: Results for Debian's Position on the GFDL
Henning Makholm wrote: You may not use technical measures to obstruct or control the reading or further copying [by the intended recipient] of [all] the copies you make or distribute [to him] But how can we explain away make or? I'm pretty sure I carefuly did so --- if you make a copy and do not distribute it, then the intended recipient is either you or no one. The 'no one' possibility is tautology: Obstructing or controlling the reading, etc. of no one is not in violating of the clause. The 'you' possibility is a tad bit less so, but should be covered by the 'all' I inserted. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
Joey Hess wrote: Attempts to legislate pi are always questionable, and when you ask a majority of uninformed voters[3] to choose between items, it's natural for the compromise to win, and not unheard of for it to end up 3. I agree wholeheartedly, but I'm not exactly sure how else to proceed. I don't think /anyone/ who is part of the consensus here is too happy with the outcome of this GR. Alas, now that pi != 4*atan(1), how shall we proceed? Interpreting licenses and the DFSG is nowhere near as clear as mathematics and, unfortunately, just ignoring the GR would, I think, make us look like sore losers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
Walter Landry wrote: You're right. I did not notice that. That makes the analysis much simpler. The developers, in their wisdom, essentially changed DFSG #10 to add the GFDL without invariant sections. Unfortunately, DFSG 10 reads: * **Example Licenses* The *GPL http://www.gnu.org/copyleft/gpl.html*, *BSD http://www.debian.org/misc/bsd.license*, and *Artistic http://www.perl.com/pub/a/language/misc/Artistic.html* licenses are examples of licenses that we consider free//. and not *Special Exceptions* As a special exception, we consider he GPL, BSD, and Artistic licenses free. So that leads us right back to my point of trying to figure out what the Project is telling us about interpreting licenses and the DFSG. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
MJ Ray wrote: More than unfortunate, it makes that ambition impossible without telepathy or further surveying, as far as I can see. There seems little point just guessing what motives produced a pi=3 statement. It isn't quite as bad as pi = 3, as there is certainly some abiguity in both the DFSG and the GFDL. However, maybe once we come up with a way to reconcile the Project's decision with the text of the DFSG and GFDL, we should ask the project to approve it (assumably via GR). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
Glenn Maynard wrote: On Sat, Mar 11, 2006 at 11:01:19PM -0500, Anthony DeRobertis wrote: I propose that the Project is telling us that something along the following is the true reading: You may not use technical measures to obstruct or control the reading or further copying [by the intended recipient] of [all] the copies you make or distribute [to him] The Project can't say what the true reading is. Only the license and the copyright holder can determine that. The Project has no power, by GR or otherwise, to define the interpretation of someone else's license. I phrased that quite wrong; the Project certainly can't, as you state, decide up the true reading. The Project may, however, decide how /it/ reads the license. If the copyright holder were to inform us that our reading is wrong, we'd use the copyright holder's reading, no matter how silly (just like we did for Pine). Of course, the final authority on the meaning of a license would be the Supreme Court (at least in the US). This GR also did not say the GFDL is free, as long as this and that interpretation of the license are held; it makes no such qualification. The GR just says: At the same time, we also consider that works licensed under the GNU Free Documentation License that include no invariant sections do fully meet the requirements of the Debian Free Software Guidelines. It does not say whether the interpretation of the DFSG or the interpretation of the license is wrong; I suggest that means we are free to pick, on a problem-by-problem basis, which one is wrong. I can put a document under the GFDL, and say the 'technical measures' clause is, in fact, intended to prohibit encrypting the document. That's not bending or twisting the license; it's merely confirming a straightforward interpretation. Sure. And we could decide that if you do that, we'll treat you just like UW with respect to Pine. [And yes, it is silly. But you're preaching to the choir, and unless you plan to get the GR reversed, it really doesn't matter.] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
Joe Buck wrote: That is, the necessity to make a written offer good for three years is sometimes painful, as is the necessity to keep a transparent copy available for one year. I did not understand why debian-legal found the latter provision a DFSG violation. We found both of them to be DFSG violations. In the GPL, however, you are allowed to just make a copy available from the same location (subclause A, if I remember correctly), so you need not make use of the 3-year offer. If the same can be done for GFDL works, then the 1-year requirement doesn't matter, either. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
On Sun, 12 Mar 2006 01:11:45 -0700 Joe Buck wrote: That is, the necessity to make a written offer good for three years is sometimes painful, There's no such necessity in the GNU GPL v2. GPLv2, section 3 offers three alternative paths, only one of which requires that you make a written offer, valid for at least three years (see clause 3b). If you accompany the compiled form with the complete corresponding machine-readable source code (see clause 3a), you have no other future obligations. Clause 3b is the non-free option. Clause 3a is the free one. as is the necessity to keep a transparent copy available for one year. The GFDL (v1.2) puts different requirements. If you distribute more than 100 Opaque copies of the document, you have two options: * you /include/ (not accompany!) a machine-readable Transparent copy along with each Opaque copy * you provide a URL that must stay alive for at least one year after the ditribution of the last Opaque copy The second option is non-free. The first one forces users to download the Transparent copy, even if they don't want it. My opinion is that this is non-free too. I do not yet fully understand what conclusions can be drawn from GR-2006-001 results, but it seems that the Debian Project majority disagrees with me... :-( -- :-( 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 pgpXYgWehMTwW.pgp Description: PGP signature
Re: Results for Debian's Position on the GFDL
On 2006-03-12, Walter Landry [EMAIL PROTECTED] wrote: I still don't see how Debian can comply with keeping the source to every version for a year In kde-related packages (and probably also in gnome-related) have the help files distributed in some docbook format - and the help thingie is a docbook-viewer. Then it is only source in whatever modified form distributed, which should be okay from this perspective. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
On Sun, 12 Mar 2006 17:23:32 -0500 Anthony DeRobertis wrote: [...] However, maybe once we come up with a way to reconcile the Project's decision with the text of the DFSG and GFDL, we should ask the project to approve it (assumably via GR). I'm not sure I understand what you mean... Could you please elaborate? -- :-( 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 pgpKBLHgz5R9H.pgp Description: PGP signature
Re: Results for Debian's Position on the GFDL
On Sun, 12 Mar 2006 17:15:40 -0500 Anthony DeRobertis wrote: Joey Hess wrote: Attempts to legislate pi are always questionable, and when you ask a majority of uninformed voters[3] to choose between items, it's natural for the compromise to win, and not unheard of for it to end up 3. I agree wholeheartedly, So do I... but I'm not exactly sure how else to proceed. I don't think /anyone/ who is part of the consensus here is too happy with the outcome of this GR. I'm definitely not happy: on the contrary, I'm really depressed... :-((( Alas, now that pi != 4*atan(1), how shall we proceed? I really do not know... Interpreting licenses and the DFSG is nowhere near as clear as mathematics and, unfortunately, just ignoring the GR would, I think, make us look like sore losers. It'a pain anyway: even if the DFSG are not as clear as maths, I cannot figure out a way to consistently interpret them, with the constraints that: * GFDL'd works (with no unmodifiable unremovable parts) must be considered free, as required by GR-2006-001 * at the same time, we do not open the floodgates and accept almost every kind of restriction in main At this point, I really do not know how to act... :-| -- :-( 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 pgpAmSd8TM9fM.pgp Description: PGP signature
Re: Results for Debian's Position on the GFDL
Anthony DeRobertis [EMAIL PROTECTED] Joe Buck wrote: That is, the necessity to make a written offer good for three years is sometimes painful, as is the necessity to keep a transparent copy available for one year. I did not understand why debian-legal found the latter provision a DFSG violation. We found both of them to be DFSG violations. [...] Please provide references. From my recollection and Manoj Srivastava's draft PS, it was far from the consensus in the general case for the latter. -- 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]
Antique RC bugs (many about licensing)
I went through the RC bugs which apply to etch and are older than one year. This is a rather disturbing list, as you would expect from the age of the bugs. In most cases I don't think you can expect the maintainers to deal with these bugs on their own. What are the release managers planning to do about these? First the easy bugs: --- Package: libuclibc0 (optional; David Schleef) [uclibc/0.9.27-1 ; =] [add/edit comment] 261725 [ ] libuclibc0 - violates FHS This deserves a long-term exception because the FHS has no reasonable alternative placement, and tools expect the placement used here. Package: libmpeg2-4 (optional; Loic Minier et al.) [mpeg2dec/0.4.0b-4 ; =] [add/edit comment] 14-Aug-2005: Andi: is sarge-ignore; discussion about permanent exception 268603 [ ] libmpeg2-4: Non-PIC shared library This almost certainly should have a permanent exception. Now the remaining non-licensing bugs: - Package: evolution (optional; Debian Evolution Maintainers et al.) [evolution/2.4.2.1-1 ; =] [add/edit comment] 295270 [ ] Messages cannot be deleted and index file gets corrupted when there isn't enough disk space Not solved yet, but an upstream dataloss bug. Package: harbour (optional; Luis Mayoral) [harbour/0.44-1 ; =] [add/edit comment] 276962 [ ] harbour: FTBFS on amd64: harbour hangs on run. Maintainer appears MIA. Suggest forced orphaning and removal from etch. Bug appears to be fixed upstream in a new version. Package: libparted1.6-13 (optional; RFHed) [parted/1.6.25.1-2 ; =] [add/edit comment] 294520 [ + ] libparted1.6-13: Incorrect handling of extended partitions Shouldn't be marked as patch; it's not solved yet. Package: mozilla-calendar (optional; Takuo KITAME) [mozilla/2:1.7.12-1.1 ; =] [add/edit comment] 293962 [ ] mozilla-calendar: mozilla segfaults on AMD64 when using a remote ICS calendar Unsolved. Package: nvidia-glx (optional; non-free; Randall Donald) [nvidia-graphics-drivers/1.0.8178-2 ; =] [add/edit comment] 208198 [ ] nvidia-glx: dangling symlink libGL.so left from xlibmesa-gl-dev without nvidia-glx-dev installed This problem seems to be exceptionally hard to solve. Package: xdelta (optional; LaMont Jones) [xdelta/1.1.3-6.1 ; =] [add/edit comment] 147187 [ ] xdelta: Deltas generated on i386 fail to apply on alpha This package should be forcibly orphaned and removed from etch; there are very few packages which depend on it anyway. Potentially ignorable licensing bugs: Package: alcovebook-sgml-doc (optional; Yann Dirson) [alcovebook-sgml/0.1.2-7 ; =] [add/edit comment] 266407 [ ] [NONFREE-DOC:GFDL] reference manual is licensed under GFDL 321771 [ ] [NONFREE-DOC:OPL] alcovebook-intro is licensed under OPL 1.0 These may actually be invalid; the license situation on this is confused. They may further be rendered invalid by the recent GR? I haven't checked. Package: xserver-xorg (optional; Debian X Strike Force et al.) [xorg-x11/6.9.0.dfsg.1-4 ; =] [add/edit comment] 211765 [ ] xfree86: material under GLX Public License and SGI Free Software License B is not DFSG-free As far as I can tell, the philosophy of the most recent GR is that Debian should look for the spirit of the license -- and assume that licensors don't really mean what they say when they say things which contradict the spirit. While I think this is legally stupid, it is exactly what Adeoato said when he said that he didn't believe that the GFDL actually contained the restrictions on encryption etc. which it contains if read literally. Following the same philosophy, Debian might conclude that the authors of these licenses don't really mean what they said, so this bug may be invalid. I don't really know. Package: libnss-ldap (extra; Stephen Frost) [libnss-ldap/238-1.1 ; =] [add/edit comment] 199810 [ ] [NONFREE-DOC:RFC] Includes non-free documentation (RFC2307) More unmodifiable material. The do what I mean not what I say philosophy promoted by the recent GR may mean that this should not be considered unmodifiable, however. I'm not sure. Now the remaining licensing bugs: - Package: cpp (standard; Debian GCC Maintainers et al.) [gcc-defaults/1.30 ; =] [add/edit comment] 23 [ ] [NONFREE-DOC:UNMODIFIABLE] cpp: contains non-free manpages Package: cpp-4.0-doc (required; Debian GCC Maintainers et al.) [gcc-4.0/4.0.2-9 ; 4.0.2-10] [add/edit comment] 321781 [ ] [NONFREE-DOC:GFDL1.1ol] contains non-free documentation Package: gnat-4.0-doc (required; Debian GCC Maintainers et al.) [gcc-4.0/4.0.2-9 ; 4.0.2-10] [add/edit comment] 321782 [ ] [NONFREE-DOC:GFDL1.2olfc] contains non-free documentation Package: libstdc++6-4.0-doc (required; Debian GCC Maintainers et al.) [gcc-4.0/4.0.2-9 ; 4.0.2-10] [add/edit comment]
Re: better licence for fosdem, debconf, .., videos...
On Sun, 12 Mar 2006 11:47:56 + MJ Ray wrote: Francesco Poli [EMAIL PROTECTED] On Fri, 10 Mar 2006 01:16:13 + MJ Ray wrote: [...] For a Derivative Work, I'm pretty sure that the law about false attribution allows the original author to demand they not be credited with it. This requirement seems like a no-op included to make the attribution clause consistent with the law. Could you please provide a pointer to the relevant articles of the copyright (or author's right) law you're referring to? I wasn't able to find such a right from a quick review of the Italian Author's Right Law (I mainly searched among moral rights...). Are you thinking about UK Copyright Law, perhaps? Or US Copyright Law? UK Law, as this licence is for the law of Scotland. I think http://www.jenkins-ip.com/patlaw/cdpa1.htm#s84 is the legislation and a credit is attribution. The closest thing I could find there is the following: | This section applies where, contrary to the fact- | | (a) a literary, dramatic or musical work is falsely represented as | being an adaptation of the work of a person, or | | (b) a copy of an artistic work is falsely represented as being a copy | made by the author of the artistic work, | | as it applies where the work is falsely attributed to a person as | author. It speaks about false attribution: I cannot imagine how stating This image is based on the desk image created by Bob could be considered as false attribution... -- :-( 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 pgpEPh0Wpq1yX.pgp Description: PGP signature
Re: Bug#323099: no longer a bug.
On Sun, 2006-03-12 at 20:13 +, MJ Ray wrote: Mike O'Connor [EMAIL PROTECTED] Finally, the GPL is not invariant: IIRC, you can edit it if you delete the preamble [see http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL ]. Debian contains the version we received, though. On debian systems, the GPL is in /usr/share/common-licenses and packages should refer to it rather than include another copy. That URL says that you can modify the GPL to create your own license, then release your software under that license, just don't call it GPL anymore. It doesn't say, you can take some work that someone has released under the GPL and modify the license, the release it under this modified license. What the author has done in this case is say, you can use this software under these licenses, you can modify the software, but you cannot modify the licenses. Debian does have the requirement that you can modify the licenses that software is released under, right? stew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better licence for fosdem, debconf, .., videos...
Francesco Poli [EMAIL PROTECTED] [...] It speaks about false attribution: I cannot imagine how stating This image is based on the desk image created by Bob could be considered as false attribution... I repeat: I think it depends where and how based on the desk image created by Bob is stated. Further: a lot of emphasis is put on whether you are trying to credit Bob with a hand in your work. That is, whether it is a credit. See http://www.bailii.org/ew/cases/EWHC/Patents/1998/345.html if you want more explanation of both legislation and case law. I think it's fair that you can't credit upstream with your derivative or collective if they don't want you to. Hope that explains, -- 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: Results for Debian's Position on the GFDL
Francesco Poli wrote: I'm definitely not happy: on the contrary, I'm really depressed... :-((( Well, I must say I'm not depressed about it --- that'd be if Amendment B passed. Or even got majority. I can understand how the average developer can yell nitpicking! at a lot of our objections to the GFDL, and essentially say 3.14 is damn well close enough [Omitting response to the rest of the message because I plan to cover it elsewhere in this thread.] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
MJ Ray wrote: Personally, I find it disappointing that so many people ranked opposite views high, then FD below them. I think the no, no matter what description of FD in the ballot is unhelpful and deters compromise attempts. I also tend to think that the presence of the absurd free in all cases (including invariant sections) option contributed to the belief that the free without invariant sections option was the compromise position, rather than the opposing view. Furthermore, I suspect that outside of debian-legal many people had long believed that invariant sections were the only issue with the GFDL, and that the call for a vote was thus the first exposure to the idea that the GFDL had other serious problems. Finally, I agree entirely with the suggestions that both of the GFDL is free options should have had a 3:1 requirement. Then only a handful of voters would need to have voted it below Further Discussion for it to have failed, which doesn't seem at all unlikely in the face of the above two points. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Results for Debian's Position on the GFDL
Francesco Poli wrote: On Sun, 12 Mar 2006 17:23:32 -0500 Anthony DeRobertis wrote: [...] However, maybe once we come up with a way to reconcile the Project's decision with the text of the DFSG and GFDL, we should ask the project to approve it (assumably via GR). I'm not sure I understand what you mean... Could you please elaborate? [Note: When I say the Project below, I of course realize that many DD's disagree with the result of 2006-01. However, GR's are the official method to make decisions on behalf of the entire Debian Project, and a decision has been made.] The Project essentially told us our conclusion — the GFDL is not free — is wrong in the case where there are no invariant sections. The Project did not tell us why. There are several ways we can take this: 1. The Project intends this to be a one-time thing, applying only to the GFDL: No effect on future judgements of licenses is intended. I don't believe this is a valid interpretation of the GR as that'd require a 3:1 supermajority to achieve (just like Amendment B), and the ballot option did not require that. 2. The Project intends us to change how we interpret licences as they believe we have come to an incorrect conclusion. I believe this is the correct way to understand and act on the GR. 3. Completely ignore the GR, decide the Project has gone mad. I think this would be a horrible approach. If we go with (2), we need to figure out where we (according to the Project) have erred in our judgement, interpretation, etc. I believe we should: 1. Find new ways to interpret the GFDL and (if necissary) the DFSG to bring the GFDL w/o invariant sections into compliance with the DFSG. Note that I *strongly* prefer that we change our interpretation of the GFDL as opposed to give up freedoms in the DFSG. I think it is reasonable to believe the Project thinks that many of our objections are nitpicking and silly — at least far more reasonable to believe that than to think they believe free software can demand chmod -R a+rX $HOME 2. Once we have come up with a list of how we intend to reconcile the GFDL and DFSG (as above), present this as a GR for the Project to approve. Now, if the Project approves the GR, fine. We will then have an extremely clear idea of where we stand. If the Project rejects the GR, well, we'll worry about that then. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Antique RC bugs (many about licensing)
Nathanael Nerode wrote: Package: xserver-xorg (optional; Debian X Strike Force et al.) [xorg-x11/6.9.0.dfsg.1-4 ; =] [add/edit comment] 211765 [ ] xfree86: material under GLX Public License and SGI Free Software License B is not DFSG-free As far as I can tell, the philosophy of the most recent GR is that Debian should look for the spirit of the license -- and assume that licensors don't really mean what they say when they say things which contradict the spirit. While I think this is legally stupid, it is exactly what Adeoato said when he said that he didn't believe that the GFDL actually contained the restrictions on encryption etc. which it contains if read literally. As far as I can tell, the most recent GR states no more and no less than the idea that the GFDL should be considered DFSG-free without unmodifiable parts. Let's not compound the insanity by attempting to extrapolate these results to other licenses. Package: libnss-ldap (extra; Stephen Frost) [libnss-ldap/238-1.1 ; =] [add/edit comment] 199810 [ ] [NONFREE-DOC:RFC] Includes non-free documentation (RFC2307) More unmodifiable material. The do what I mean not what I say philosophy promoted by the recent GR may mean that this should not be considered unmodifiable, however. I'm not sure. See above, and also note that the GR specifically proscribed unmodifiable material. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Results for Debian's Position on the GFDL
Anthony DeRobertis wrote: The Project essentially told us our conclusion — the GFDL is not free — is wrong in the case where there are no invariant sections. The Project did not tell us why. There are several ways we can take this: 1. The Project intends this to be a one-time thing, applying only to the GFDL: No effect on future judgements of licenses is intended. I don't believe this is a valid interpretation of the GR as that'd require a 3:1 supermajority to achieve (just like Amendment B), and the ballot option did not require that. I believe this is a perfectly valid interpretation of the GR. The GR made no statement on the DFSG-freeness of any license other than the GFDL, and I see no good reason why we should extrapolate it. Let those who desire more permissive interpretations argue those interpretations and/or pass GRs; let's not play devil's advocate and argue their points for them. 2. The Project intends us to change how we interpret licences as they believe we have come to an incorrect conclusion. I believe this is the correct way to understand and act on the GR. I don't see how this can be read from the GR. A plurality of the Project has stated that the GFDL is DFSG-free. I don't believe we should take this as a reason to change our interpretations of other licenses as well, nor do I believe that we should attempt to guess the *intent* of the Project, particularly since such intent may vary greatly between various developers. To use the mathematical hyperbole: just because the project has legislated pi=3.14 doesn't mean we should start arguing e=2.72 and sqrt(2)=1.41 for them. - Josh Triplett signature.asc Description: OpenPGP digital signature
