Re: Results for General Resolution: Lenny and resolving DFSG violations
On Sun, Dec 28, 2008 at 08:45:16PM -0500, Theodore Tso wrote: If there was a GR which chainged the Debian Social contract which relaxed the first clause to only include __software__ running on the Host CPU, I would enthusiastically vote for such a measure. I doubt that this a usable definition. Do you think that the provision that a program is pushed into another generic purpose cpu should always make them free? An imaginal system can include several CPU types: - Host CPU (lets say the Power cores of a Cell processor) - Slave CPU (the SPUs of a Cell processor, different instruction set and ABI then the host) - GPU (current NVidia and ATI chips can be filled with rather generic programs to do vector operations) - device driving CPU (e.g. the MIPS cores of a broadcom network chip) Only the last ones are usualy filed by the OS with a firmware and then started. Bastian -- Yes, it is written. Good shall always destroy evil. -- Sirah the Yang, The Omega Glory, stardate unknown -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, 29 Dec 2008, Anthony Towns wrote: Anyway, given the last proposal I made [0] went nowhere, unless people want to come up with their own proposals, or want to second the above as a draft proposal to be improved and voted on, I suspect nothing much will change, and we'll have this discussion again in a few years when squeeze is looking like releasing. I think it would be worth it to take some time to draft an updated social contract given the difficulties we've seen in the debate. I like most of what I've seen in your proposal (except the wording on the point about publishing any private stuff). I would suggest you to let vacation time pass, and then try submitting it again in a new thread (or maybe post-lenny, up to you). Whatever you choose, I'll try to share my comments/participate in the discussion anyway. I'm not sure the whole rewrite is necessary, it might be easier to modify less and give separate rationale for each change. But honestly I haven't looked enough into it yet to comment more than that. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
I thought FD was also a vote for release Lenny given it didn't change the status quo and before the GR the release team were quite happy to release... If you believe that the release team had the authority to release lenny with an arbitrary amount of non-free software, then yes, that would seem accurate. For someone that is in Debian for so long its pretty bad how one can misjudge it... The release team has the authority to release Lenny. At whatever point they wish and feel good with it. They provide a list of what criteria need to be met for that. For the package contents of that release, they take whatever we, all the maintainers uploading packages, and what we, the ftpmasters, put into the archive. Now, if one dislikes a decision of a delegate, one can run a GR against it. Somehow we just had one, and the outcome does say they can release with the kernel that is currently in Lenny. Like it or not, but thats the option that won, no matter how fucked up the ballot may have been. Dislike this outcome? Do Debian a bad service and run yet another GR against Lenny. Or, to have something new, do such things right *after* a release, not right before one.[1] [1] But that wouldn't be half as fun complaining, wouldnt hurt Debian as much, eh? -- bye, Joerg lamont is there a tag for won't be fixed until sarge+1? sam depends whether the BTS is year 2037 compliant -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
* Thomas Bushnell BSG [Sun, 28 Dec 2008 21:55:36 -0800]: I wish we could have in the world of GNU/Linux one, just one, please--just one--distribution which really took free software as of cardinal importance. I don't like the wording of your sentence, but I'll point out that gNewSense already exists, and that then, even Stephen Fry (let alone Richard Stallman) would endorse you. http://www.gnewsense.org/ -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: La Buena Vida - No lo esperaba de mí -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
Hi, On Mon, Dec 29, 2008 at 03:02:41PM +1000, Anthony Towns wrote: On Sun, Dec 28, 2008 at 08:45:16PM -0500, Theodore Tso wrote: On Mon, Dec 29, 2008 at 12:48:24AM +, Simon Huggins wrote: I wonder how many DDs were ashamed to vote the titled Reaffirm the social contract lower than the choices that chose to release. I'm not ashamed at all; I joined before the 1.1 revision to the Debian Social Contract, which I objected to them, and I still object to now. If there was a GR which chainged the Debian Social contract which relaxed the first clause to only include __software__ running on the Host CPU, I would enthusiastically vote for such a measure. So what would such a SC look like? I am impressed by your well thought proposal. Thanks! Here are my comments to it. We previously had a vote to revert the SC to 1.0, and while it defeated reaffirming the current SC, it lost to the option of simply postponing it. Maybe with nearly four years of experience since then, that's changed though. I hope people have learned from this :-) Using the word software as the basis for the divide might be too much: we've already done a lot of work restricting main to DFSG-free docs, and I think it makes sense to keep that. Having main be a functioning bunch of free stuff with a minimal and decreasing amount of random non-free stuff we still need to support it works well, it seems to me. Yes. Back in the day, I tried writing a version of the SC that felt both inspiring and within the bounds of what we could actually meet. It looked like: ... 4. We will be open about our activities We will conduct our affairs in public and allow anyone to follow our discussions. Where public disclosure is not immediately feasible we will make any private discussions publically available at the earliest opportunity. ... It doesn't try to say how these goals are met, leaving that up to the DPL, ftpmaster, debian-policy, individual maintainers and future resolutions by the project. I think that makes sense by and large, but having the project state that explicitly might be necessary to avoid continuing ambiguity and arguments. ... It drops the 100% free phrasing we've had in the past, because fundamentally what we have isn't 100% free. It might be three-nines edging onto four-nines, but we don't even have an accurate measurement. Calling main as it stands today an integrated system of free software seems the best compromise between staying focussed on freedom, not claiming to be completely free until we are, and not devolving into impenetrable jargon that I could come up with. You mean like many contracts which use best effort clause ... For example, we will use and promote FREE softwares to the extent possible. It redoes the we will not hide problems phrasing in a way that, I think, reflects the intent better than the current wording, which seems to support just about everything but the BTS to be done in secret. Unfortunately that's some way off current practice wrt conducting project activities on restricted machines, private IRC channels, unlogged IRC channels, in personal emails, and on private lists. But the way you wrote in 4 as we will make any private discussions publically available at the earliest opportunity. is problematic since it is 100% disclosure pledge. I suggest something along we will make any private discussions publically available at the earliest opportunity to the extent appropriate for this objective. I am using this objective as to allow anyone to follow our discussions. I hope someone can rephrase this better. ... One other thing the above does is, unlike the current SC, is use the word Debian to refer solely to the project -- so it doesn't suffer from the confusion that when the current SC says Debian will remain 100% free you don't have to mentally substitute in The main component of ... releases in order to reconcile it with the later mentions of non-free stuff. Yes, I like this. Since it's worded as a pledge, it might make sense that if it (or something like it) is ever adopted, that existing developers membership being dependent on them agreeing to the pledge. That didn't happen with the previous SC change, but it seems strange to claim to have a social contract when a significant number of members don't actually support it 100%. I am not sure about the last part. If you said when a significant number of members don't actually abide by it 100%., I can agree. As much as we are discussing SC change now, we should allow us to discuss changing it as long as we abide by the current SC during its valid term. I mean people with view to have stricter FREE requirement should not be forced to leave project via this pledge process. To me, none of us made action which does not abide to the valid current SC. We only overruled a part of SC when it conflicted with another one in SC via GR. I.e. 100% free
Re: Results for General Resolution: Lenny and resolving DFSG ?violations
In linux.debian.vote Thomas Bushnell BSG t...@becket.net wrote: I would prefer this. But I am afraid of it, and so I would vote against it. I am afraid that there are folks in the project who really don't care if Debian is 100% free--even as a goal. I think that Ted Tso is even one of them. Count me in as well then, since I completely share his opinion. I wish we could have in the world of GNU/Linux one, just one, please--just one--distribution which really took free software as of cardinal importance. Debian has promised to be that, while living up to What about you spend your time hacking on gnewsense then, and let us create on an OS which will also be useful? -- ciao, Marco -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG ?violations
In linux.debian.vote Thomas Bushnell BSG t...@becket.net wrote: On Sun, 2008-12-28 at 20:45 -0500, Theodore Tso wrote: I'm not ashamed at all; I joined before the 1.1 revision to the Debian Social Contract, which I objected to them, and I still object to now. If there was a GR which chainged the Debian Social contract which relaxed the first clause to only include __software__ running on the Host CPU, I would enthusiastically vote for such a measure. aolMe too./aol Can you please define host CPU for us? What about the same one which is executing the OS kernel? -- ciao, Marco -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Sun, Dec 28, 2008 at 09:55:36PM -0800, Thomas Bushnell BSG wrote: On Mon, 2008-12-29 at 15:02 +1000, Anthony Towns wrote: I would personally prefer for the project to have the freedom to decide those sorts of things on a day-to-day basis through regular decision making [...] I would prefer this. But I am afraid of it, and so I would vote against it. I am afraid that there are folks in the project who really don't care if Debian is 100% free--even as a goal. I think that Ted Tso is even one of them. Whatever his motives, I think Ted's demonstrably done more to further the cause of free software than most developers, both by making Linux more and more usable for over 15 years now, and for helping other developers work together better, such as by organising the kernel summit. I'm all for having a 100% free system, and then some, but if it comes down to a choice between supporting absolute freeness without exception, and working with folks like Ted, I'm more interested in the latter. In my opinion, developers who are unwilling to abide by the Social Contract in their Debian work should resign. But they don't, and this is what has me afraid. Of course, the other side of that ist that we've never worried about DDs who aren't willing to support non-free, which is also part of the social contract. Anyway, I'm already getting namechecked for discussing this too much [0], so, well, whatever. See y'all again when squeeze gets held up. Peace out, aj [0] http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/148-When-firmware-is-not-software.html -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
* Theodore Tso: I'm not ashamed at all; I joined before the 1.1 revision to the Debian Social Contract, which I objected to them, and I still object to now. If there was a GR which chainged the Debian Social contract which relaxed the first clause to only include __software__ running on the Host CPU, I would enthusiastically vote for such a measure. I think it's not that simple anymore. For instance, while I have no particular opinion on firmware, I object to packages in main which, when run on a web browser, execute proprietary Javascript blobs (either by shipping them in the package, or by linking them in some way). -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
This one time, at band camp, Clint Adams said: On Mon, Dec 29, 2008 at 12:48:24AM +, Simon Huggins wrote: I thought FD was also a vote for release Lenny given it didn't change the status quo and before the GR the release team were quite happy to release... If you believe that the release team had the authority to release lenny with an arbitrary amount of non-free software, then yes, that would seem accurate. If you don't want them to release glibc as is, why didn't you upload a more suitable version? -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Results for General Resolution: Lenny and resolving DFSG violations
* Mike Hommey: On Mon, Dec 29, 2008 at 03:01:19PM +0100, Florian Weimer f...@deneb.enyo.de wrote: * Theodore Tso: I'm not ashamed at all; I joined before the 1.1 revision to the Debian Social Contract, which I objected to them, and I still object to now. If there was a GR which chainged the Debian Social contract which relaxed the first clause to only include __software__ running on the Host CPU, I would enthusiastically vote for such a measure. I think it's not that simple anymore. For instance, while I have no particular opinion on firmware, I object to packages in main which, when run on a web browser, execute proprietary Javascript blobs (either by shipping them in the package, or by linking them in some way). Following the same logic, you should be opposing to packages such as the kernel, that allows to run proprietary ELF blobs. This is ridiculous. If the kernel automatically downloaded some binary from the network and executed it, I would consider that unacceptable for a default configuration, too. It's not the mere possibility that counts. I'm against doing this by default (or requiring it for almost any use of a package). -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, Dec 29, 2008 at 03:01:19PM +0100, Florian Weimer f...@deneb.enyo.de wrote: * Theodore Tso: I'm not ashamed at all; I joined before the 1.1 revision to the Debian Social Contract, which I objected to them, and I still object to now. If there was a GR which chainged the Debian Social contract which relaxed the first clause to only include __software__ running on the Host CPU, I would enthusiastically vote for such a measure. I think it's not that simple anymore. For instance, while I have no particular opinion on firmware, I object to packages in main which, when run on a web browser, execute proprietary Javascript blobs (either by shipping them in the package, or by linking them in some way). Following the same logic, you should be opposing to packages such as the kernel, that allows to run proprietary ELF blobs. This is ridiculous. Mike -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Sun, Dec 28, 2008 at 09:55:36PM -0800, Thomas Bushnell BSG wrote: I would prefer this. But I am afraid of it, and so I would vote against it. I am afraid that there are folks in the project who really don't care if Debian is 100% free--even as a goal. I think that Ted Tso is even one of them. Fear is a terrible thing to use as the basis of decisions and of votes; consider it was fear that drove many people to vote for Proposition 8 in California As I said in my recent blog entry[1], I believe that 100% free is a wonderful aspirational goal --- other things being equal. However, I don't believe it to be something that should be Debian's Object of Ultimate Concern; there are other things that need to be taken into consideration --- for example, allowing various machines owned by Debian to be able to use their network cards might be a nice touch. [1] http://thunk.org/tytso/blog/2008/12/28/debian-philosophy-and-people/ In other words, I believe in 100% Free as a goal; but I'm not a fundamentalist nor a fanatic about it. I wish we could have in the world of GNU/Linux one, just one, please--just one--distribution which really took free software as of cardinal importance. As others have pointed out, there is such a distribution, gNewSense; in fact, if you look at [2], you will find that there are five others, Ututu (the first fully free GNU/Linux distribution recognized by the FSF), Dynebolic, Musix GNU+Linux, BLAG, and Trisquel. So not only is there one such distribution that takes free software of cardinal importance, there are six in the world already. Does Debian really need to be the seventh such distribution? [2] http://www.gnu.org/links/links.html#FreeGNULinuxDistributions In my opinion, developers who are unwilling to abide by the Social Contract in their Debian work should resign. But they don't, and this is what has me afraid. That would be like saying that people who don't agree with Proposition Eight's amendment to the California constitution should leave the state, as opposed to working to change it. I prefer to stay within Debian in the hopes that I can help it change to something which I think is better; at the very release, reverting the 1.1 version of the Social Contract, and perhaps, clarifying it. I will note that Option 1, Reaffirm the Social Contract came in *dead* *last*: Option 1 2 3 4 5 6 7 === === === === === === === Option 1 4660727389 117 Option 2281 160 160 171 177 224 Option 325561 125 137 151 204 Option 4253 121 146 160 166 194 Option 5234 105 128 135 136 191 Option 6220 118 134 125 134 180 Option 7226 129 145 153 160 169 It was beaten by options 2 (281 - 46 = 235), 3 (255 - 60 = 195), 4 (253 - 72 = 181), 5 (234 - 73 = 161), 6 (220 - 89 = 131) and 7/FD (226 - 117 = 109). Put another way, _very_ few people are willing to take a fundamentalist interpretation of the Social contract (by AJ's calculation, 9.3%) ahead of delaying Lenny. I don't think encouraging 90% of the Debian Developers to resign would be a particularly constructive suggestion. Fixing the Social Contract so it reflects our common understanding of what's best for the Debian Community, both users and developers, is IMHO a better choice than striving to become the Seventh Fundamentalist Linux Distribution on the FSF's approved list. Best regards, - Ted -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, Dec 29, 2008 at 03:02:41PM +1000, Anthony Towns wrote: Using the word software as the basis for the divide might be too much: we've already done a lot of work restricting main to DFSG-free docs, and I think it makes sense to keep that. Having main be a functioning bunch of free stuff with a minimal and decreasing amount of random non-free stuff we still need to support it works well, it seems to me. I'm not convinced that leaving important parts of Debian undocumented over doctrinal disputes over licensing terms is actually in the best interests of users, but I recognize that's a position that people of good will can (and have) disagreed upon. If it were up to me, I would have Debian work towards a system where packages could be tagged to allow enable common user preferences (we won't be able to make everyone happy) be enforced by what packages they can see/install. Some users are OK with GFDL documentation, others are not; some users are OK with non-free firmware, other are not. So why can't we tag packages appropriately, so that this can be reflected in a configuration file so that people who are passionate about some particular issue can decide what tradeoffs they are willing to make with respect to usability and/or documentation based on how Fundamentalistic they want to be with regards to the 100% Free goal/requirement? Separating packages into separate sections to support these sorts of policy preferences is a hack, and with appropriate tagging, in the long run we can allow users to be much more fined-grained about expressing their preferences --- which would be in line with our goal of being a Universal OS, I think. Back in the day, I tried writing a version of the SC that felt both inspiring and within the bounds of what we could actually meet. It looked like: I like this a lot. However, I do have a few nits... We, the members of the Debian project, make the following pledge: 1. We will build a free operating system We will create and provide an integrated system of free software that anyone can use. We will make all our work publically available as free software. Given how literalistic some members of our community can be about interpreting Foundation Documents, the second sentence is a little worrying. I can easily imagine a Free Software Fanatic using the second sentance as an argument that we must stop distributing the non-free section, since non-free is, by definition, not Free Software. And it could easily be argued that the work that Debian Developers to package non-free packages, which is after all distributed on the Debian FTP servers and via Debian Mirrors, would fall under the scope of All our work. I'm not sure what you were trying to state by the second sentence above; one approach might be to simply strike it from the draft. Or were you trying to add the constraint that any work authored by DD's on behalf of the Debian Project should be made available under a free software license, even if in combination with other software being packaged, the result is non-free? 2. We will build a superior operating system We will collect and distribute the best software available, and strive to continually improve it by making use of the best tools and techniques available. I'm worried about the first clause, because of the absolutist word best in best software available. Again, some literally minded DD's could view this as meaning that the best is the enemy of the good, and use this as bludgeon to say that since we have package X, we should not have packages Y or Z, because, X is the *best*. Again, I'm not sure what you intended to add by the first clause, so my first reaction would be to strike it and make it shorter/simpler: We will strive to continually improve the software we collect and distribute by making use of the best tools and techniques available. I don't think the community clause is terribly well worded, but that's what you get when you make stuff up out of whole cloth rather than building on previous attempts. It's not bad. The one thing that I noted was community wasn't terribly well defined. Do we mean the user community? The developer community? Upstream developers? All of the above? Adding an initial phrase or sentence that affirmed that everyone who touches Debian in some way (users, developers, upstream) are considered part of the community --- and then follow it with your formulation pledging that we will work to ensure that members of the community shall be treated with respect --- would be the way I would go. Anyway, given the last proposal I made [0] went nowhere, unless people want to come up with their own proposals, or want to second the above as a draft proposal to be improved and voted on, I suspect nothing much will change, and we'll have this discussion again in a few years when squeeze is looking like releasing. I would
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, Dec 29, 2008 at 09:11:01AM -0500, Theodore Tso ty...@mit.edu wrote: As others have pointed out, there is such a distribution, gNewSense; in fact, if you look at [2], you will find that there are five others, Ututu (the first fully free GNU/Linux distribution recognized by the FSF), Dynebolic, Musix GNU+Linux, BLAG, and Trisquel. So not only is there one such distribution that takes free software of cardinal importance, there are six in the world already. Does Debian really need to be the seventh such distribution? Except that none of these distros existed when Debian set the 100% free goal. Should it drop this goal now there are others such distros ? I don't think so. Should it make it less important than in the past ? I don't think either. Mike -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Sun, Dec 28, 2008 at 09:55:36PM -0800, Thomas Bushnell BSG wrote: I wish we could have in the world of GNU/Linux one, just one, please--just one--distribution which really took free software as of cardinal importance. Debian has promised to be that, while living up to the promise only in fits and starts. That's ok with me. But I'm afraid that if we stopped the promise, and simply decided it would be our goal, the folks who are against the promise will be against the goal, and will see this as permission to simply *never* work toward the goal, and to obstruct others who do. I do not believe for a second that there is anyone in the Debian project who would *oppose* working toward a goal of free software. However, I also believe that pragmatism is a necessary requirement for a project as large as Debian. I am not in the camp of those who think that getting Debian to be completely and utterly free software should be our one and only goal, and that all the rest is unimportant; therefore, I did also vote for a pragmatist option during this vote. But I will now solemny pledge that if you can ever convince me (by pointing to BTS logs, or mailinglist threads, or some such) that one of our developers is actively *obstructing* the replacement of non-free software by free software, I will immediately second a vote to expel them from the project. Freedom may not be the primary goal for this project in my personal opinion, it still is a goal that I find extremely important, and those who oppose it have no place in the Project, ever. Personally, I think that aj's proposed text actually makes it much more clear that the social contract is not a statement of fact, but rather is a promise and a goal. I do not think we should forget about the goal; but I do think that if currently there is an idea for a perfect option (which as of yet is vapourware) and an imperfect option that already exists, we should go with imperfection. [...] In my opinion, developers who are unwilling to abide by the Social Contract in their Debian work should resign. But they don't, and this is what has me afraid. I agree with you on that one, and I think you'll find that many developers do. I also think you'll find that it would be easy to get such developers kicked from the project. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 signature.asc Description: Digital signature
[s...@powerlinux.fr: Re: Results for General Resolution: Lenny and resolving DFSG violations]
Hi, Sven asked me to forward this message to the list. Since it does not contain any of the vitriol for which he was expelled from the project, and since it does contain some valid points on the discussion in question, I decided to comply with his request. I'd like to say, though, that this does not mean I necessarily agree with his PoV. - Forwarded message from Sven Luther s...@powerlinux.fr - X-Spam-Checker-Version: SpamAssassin 3.1.7-deb3 (2006-10-05) on samba.grep.be X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=AWL,BAYES_00, UNPARSEABLE_RELAY autolearn=ham version=3.1.7-deb3 Date: Mon, 29 Dec 2008 11:39:25 +0100 To: Anthony Towns a...@azure.humbug.org.au, lea...@debian.org, da-mana...@debian.org, listmas...@debian.org, s...@powerlinux.fr Cc: debian-vote@lists.debian.org, debian-de...@lists.debian.org, Theodore Tso ty...@mit.edu Subject: Re: Results for General Resolution: Lenny and resolving DFSG violations Message-ID: 20081229103925.ga22...@powerlinux.fr In-Reply-To: 20081229050241.gd11...@blae.erisian.com.au User-Agent: Mutt/1.5.13 (2006-08-11) From: Sven Luther s...@powerlinux.fr On Mon, Dec 29, 2008 at 03:02:41PM +1000, Anthony Towns wrote: On Sun, Dec 28, 2008 at 08:45:16PM -0500, Theodore Tso wrote: On Mon, Dec 29, 2008 at 12:48:24AM +, Simon Huggins wrote: I wonder how many DDs were ashamed to vote the titled Reaffirm the social contract lower than the choices that chose to release. I'm not ashamed at all; I joined before the 1.1 revision to the Debian Social Contract, which I objected to them, and I still object to now. If there was a GR which chainged the Debian Social contract which relaxed the first clause to only include __software__ running on the Host CPU, I would enthusiastically vote for such a measure. So what would such a SC look like? We previously had a vote to revert the SC to 1.0, and while it defeated reaffirming the current SC, it lost to the option of simply postponing it. Maybe with nearly four years of experience since then, that's changed though. I think the problem is not really the social contract, what it currently says is just fine, and we all agree with it. We have free stuff, which is in main, and non-free stuff of diverse variety, which is in non-free (plus the hybrid contrib). My own guess is that all those clamoring to have non-free firmware and non-free documentation or images or whatever in main, would be just as satisfied if we decided to support non-free more (and maybe put choice non-free stuff on our CD medias). I believe this will satisfy everyeone, there will be no loss of freeness over what we have now (we distribute this non-free stuff from our ftp/http servers, which is just another distribution media compared to CDs), while it allows for transparent installation of those non-free drivers, and thus those wanting to be able to install on non-free-firmware needing hardware should be happy too. So, what is really needed is that we take the time to make the non-free firmware support upto par to what we promised in our social contract : We acknowledge that some of our users require the use of works that do not conform to the Debian Free Software Guidelines. We have created contrib and non-free areas in our archive for these works. The packages in these areas are not part of the Debian system, although they have been configured for use with Debian So, in this case, configured for use with Debian, means that the non-free firmware is well integrated with both d-i and our kernel. So, basically, there is nothing to do here, nothing which will cause a ideological schism, or which makes some of us forget our vows to support the social contract when we joined debian (independent of what you consider software or not). We simply say : - non-free firmware and other stuff, are supported through the non-free area of debian (which we may subclasify or something such, but we need no social-contract change for that). - the stuff in non-free should be well integrated in debian, and we will distribute the non-free stuff on our CD or other installation media, that are needed for installing on modern hardware, provided we are legally able to do so. Then the question that remains is simple : - will we hold lenny until all remaining non-free stuff is moved to non-free, and support for well integrated non-free is added into debian where needed. or - will we release lenny as is, knowing that serious effort has been made to make this separation easier, that non-free firmware has been moved into non-free modules, and d-i support it to a degree, but more work is needed for it ? I guess that if asked such, there will be load of support for the second option, since it is the most reasonable one, and none can deny that there has been progress made on this front since our last release. That will also allow us to put all
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, Dec 29, 2008 at 11:12:01AM +0100, Joerg Jaspert wrote: For someone that is in Debian for so long its pretty bad how one can misjudge it... That's great. If you don't want them to release glibc as is, why didn't you upload a more suitable version? I'm happy to delay the release indefinitely until all the sourceless firmware is removed from the glibc source. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, Dec 29, 2008 at 7:54 AM, Wouter Verhelst wou...@debian.org wrote: On Sun, Dec 28, 2008 at 09:55:36PM -0800, Thomas Bushnell BSG wrote: I wish we could have in the world of GNU/Linux one, just one, please--just one--distribution which really took free software as of cardinal importance. Debian has promised to be that, while living up to the promise only in fits and starts. That's ok with me. But I'm afraid that if we stopped the promise, and simply decided it would be our goal, the folks who are against the promise will be against the goal, and will see this as permission to simply *never* work toward the goal, and to obstruct others who do. I do not believe for a second that there is anyone in the Debian project who would *oppose* working toward a goal of free software. However, I also believe that pragmatism is a necessary requirement for a project as large as Debian. I agree. But I think the gap in understanding here is that there are different interpretations of obstruct in play. I think that the hardcore idealists (excuse this extreme term, but it's the most descriptive at hand) believe that the Social Contract produces some sort of positive obligation to work as hard as possible to make Debian as free as possible. Under this interpretation of the Social Contract, anything which is not in the name of promoting free software would count as obstruction. In contrast, it seems like the pragmatists (again, I think Romain makes an excellent post--I will only use this terminology because it seems common in the thread) see the Social Contract as promoting a sort of dualism. [0] That is to say, the Social Contract says that we should distribute free software and that we should serve our users. It creates negative obligations not to promote non-free and not to harm our users, but not a particular positive obligation in terms of favoring one or the other. At times when these goals are incommensurate, we must decide between them, instead of always defaulting in favor of one or the other. In other words, you only obstruct free software if you actively work to include it in Debian--and I don't think anyone is advocating this (no one wants to fork the kernel to avoid upstream's decision to split out non-free blobs!) Ted Tso seems to point out the problem with second perspective--the Social Contract seems to, in its present wording, deny us access to this dualism. It has very strong rhetoric in favor of free software, with more pliant rhetoric in favor of our users. I think that it is preferable if the Social Contract were revised to be less absolutist. Debian needs such flexibility, in my opinion. Since I'm not a developer, I don't feel qualified to really speak to such a change. Daniel [0] http://en.wikipedia.org/wiki/Dualism -- Daniel Moerner dmoer...@gmail.com -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
* Florian Weimer f...@deneb.enyo.de [2008-12-29 15:01:19 CET]: * Theodore Tso: I'm not ashamed at all; I joined before the 1.1 revision to the Debian Social Contract, which I objected to them, and I still object to now. If there was a GR which chainged the Debian Social contract which relaxed the first clause to only include __software__ running on the Host CPU, I would enthusiastically vote for such a measure. I think it's not that simple anymore. For instance, while I have no particular opinion on firmware, I object to packages in main which, when run on a web browser, execute proprietary Javascript blobs (either by shipping them in the package, or by linking them in some way). But it is. The web browser does run on the Host CPU, thus the javascript engine does run on the Host CPU, too. Problem solved. :) Rhonda P.S.: Was there a MF'up2 anywhere? Not sure if this should/has to continue on both lists? P.P.S.: Weren't the Results usually mailed to d-d-a, too? Was this a mistake here, or is my memory flawed? -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, Dec 29, 2008 at 04:20:28PM +0100, Mike Hommey wrote: On Mon, Dec 29, 2008 at 09:11:01AM -0500, Theodore Tso ty...@mit.edu wrote: FSF), Dynebolic, Musix GNU+Linux, BLAG, and Trisquel. So not only is there one such distribution that takes free software of cardinal importance, there are six in the world already. Does Debian really need to be the seventh such distribution? Except that none of these distros existed when Debian set the 100% free goal. Should it drop this goal now there are others such distros ? I don't think so. Should it make it less important than in the past ? I don't think either. Debian has always had a more relaxed view on these matters than the free software purists would like - things like providing contrib and non-free aren't entirely acceptable to them and are one of the reasons why people go to these other distributions with their stronger political focus. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, 2008-12-29 at 23:27 +1000, Anthony Towns wrote: Whatever his motives, I think Ted's demonstrably done more to further the cause of free software than most developers, both by making Linux more and more usable for over 15 years now, and for helping other developers work together better, such as by organising the kernel summit. I'm all for having a 100% free system, and then some, but if it comes down to a choice between supporting absolute freeness without exception, and working with folks like Ted, I'm more interested in the latter. I'm not against working with Ted. I completely second your remarks above. I simply don't think that people should have a vote in Debian if they are not committed to following Debian's foundation documents in their Debian work. I do not know if Ted is such a person or not, but I do know that he doesn't share the goal expressed in the Social Contract; he's said as much. If he's willing to put that aside in his Debian work, then that's sufficient for me, and AFAICT, that's exactly what he does. My concern is that not everyone is like Ted. They may share his views about the Social Contract, but rather than put them aside and abide by it in their Debian work, they just ignore the bits they don't like. Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
* Gerfried Fuchs: For instance, while I have no particular opinion on firmware, I object to packages in main which, when run on a web browser, execute proprietary Javascript blobs (either by shipping them in the package, or by linking them in some way). But it is. The web browser does run on the Host CPU, thus the javascript engine does run on the Host CPU, too. Problem solved. :) The counterargument is that for a server application, the Javascript blob isn't intended to run on the host CPU, but on the client. 8-/ (Conversely, firmware shouldn't doesn't non-free material only because you can run it using qemu because it happens to be a supported architecture.) -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, Dec 29, 2008 at 03:16:05PM +0100, Florian Weimer wrote: * Mike Hommey: On Mon, Dec 29, 2008 at 03:01:19PM +0100, Florian Weimer f...@deneb.enyo.de wrote: * Theodore Tso: I'm not ashamed at all; I joined before the 1.1 revision to the Debian Social Contract, which I objected to them, and I still object to now. If there was a GR which chainged the Debian Social contract which relaxed the first clause to only include __software__ running on the Host CPU, I would enthusiastically vote for such a measure. I think it's not that simple anymore. For instance, while I have no particular opinion on firmware, I object to packages in main which, when run on a web browser, execute proprietary Javascript blobs (either by shipping them in the package, or by linking them in some way). Following the same logic, you should be opposing to packages such as the kernel, that allows to run proprietary ELF blobs. This is ridiculous. If the kernel automatically downloaded some binary from the network and executed it, I would consider that unacceptable for a default configuration, too. It's not the mere possibility that counts. I'm against doing this by default (or requiring it for almost any use of a package). Forget my message, I was reading Java blobs and thought you were talking about the openjdk plugin. Mike -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, Dec 29, 2008 at 10:03:20AM -0500, Theodore Tso wrote: On Mon, Dec 29, 2008 at 03:02:41PM +1000, Anthony Towns wrote: Using the word software as the basis for the divide might be too much: I'm not convinced that leaving important parts of Debian undocumented over doctrinal disputes over licensing terms is actually in the best interests of users, but I recognize that's a position that people of good will can (and have) disagreed upon. If it were up to me, I would have Debian work towards a system where packages could be tagged to allow enable common user preferences (we won't be able to make everyone happy) be enforced by what packages they can see/install. Sure, I agree, and have supported similar proposals in the past. [0] [0] http://lists.debian.org/debian-project/2005/04/msg00074.html Separating packages into separate sections to support these sorts of policy preferences is a hack, Not entirely. The pool/main (and dists/*/main) separation makes it easy for mirrors to only get DFSG-free stuff (ie, they can just use rsync, rather than needing to parse Debian-specific policy files). Otherwise, though, yes, definitely agree. I like this a lot. However, I do have a few nits... We, the members of the Debian project, make the following pledge: 1. We will build a free operating system We will create and provide an integrated system of free software that anyone can use. We will make all our work publically available as free software. Given how literalistic some members of our community can be about interpreting Foundation Documents, the second sentence is a little worrying. I can easily imagine a Free Software Fanatic using the second sentance as an argument that we must stop distributing the non-free section, since non-free is, by definition, not Free Software. The non-free stuff in non-free isn't our work though -- it's stuff other people have made that we redistribute. our work is things like debbugs, dak, debhelper, *.diff.gz, etc. Maybe some DDs write non-free software that gets packaged, but that can at least be differentiated by Joe Random j...@example.com versus using a d.o address. And it could easily be argued that the work that Debian Developers to package non-free packages, which is after all distributed on the Debian FTP servers and via Debian Mirrors, would fall under the scope of All our work. I think any packaging code, even for non-free stuff, should be DFSG-free. That might require dual-licensing, but that's okay. I'm not sure what you were trying to state by the second sentence above; one approach might be to simply strike it from the draft. Or were you trying to add the constraint that any work authored by DD's on behalf of the Debian Project should be made available under a free software license, even if in combination with other software being packaged, the result is non-free? Pretty much, yeah. 2. We will build a superior operating system We will collect and distribute the best software available, and strive to continually improve it by making use of the best tools and techniques available. I'm worried about the first clause, because of the absolutist word best in best software available. Again, some literally minded DD's could view this as meaning that the best is the enemy of the good, and use this as bludgeon to say that since we have package X, we should not have packages Y or Z, because, X is the *best*. There's nothing there that says we won't also distribute the worst software available, though. If you're worried about the best being exclusionary, though, the same applies to tools/techniques. If bugzilla is the best tool for bug tracking, we must immediately stop using debbugs, eg. Ditto wiki software, list software, etc. I would certainly be willing to second and support such a proposal, should you decide that you are willing to make it as a formal proposal for a GR. So that's one, but at least four more would be needed... Here's a wiki page for people who think this is a reasonable or desirable sort of thing to do: http://wiki.debian.org/SocialContractRevision . I've only added my caveats, not ones that other people have already brought up. Cheers, aj signature.asc Description: Digital signature
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, Dec 29, 2008 at 10:10:24PM +0900, Osamu Aoki wrote: But the way you wrote in 4 as we will make any private discussions publically available at the earliest opportunity. is problematic since it is 100% disclosure pledge. I suggest something along we will make any private discussions publically available at the earliest opportunity to the extent appropriate for this objective. I am using this objective as to allow anyone to follow our discussions. I hope someone can rephrase this better. IMO, discussion that leads to technical changes, is really part of the source, much like in-code comments, READMEs, and version control logs. If you've got access to the reasoning that led up to a decision, you can have a much better understanding of what's going on, just as if you have access to criticisms being made, and what people propose to do about them, you've got a much better idea of what the code's capabilities are. There's nothing wrong with having a closed discussion with some friends about how to improve your packages, but it's much better if after the fact you make that discussion available to everyone who might be interested. The same thing applies to discussions about the direction of Debian -- when it might release, how decisions get made, what exciting new things we might consider doing. These are important bits of information that users, upstream, and developers of other distros should have access to. That doesn't mean *every* private discussion DDs have -- gosh, wasn't the football exciting last night? isn't very interesting to Debian, eg. But equally, it's not especially on-topic for most Debian areas, either. If there's a casual environment -- like debconf, or a pub, or an IRC channel; there's no need for complete logs or video records for everyone to be able to pore over, but summaries of the technical bits would be a win. Since it's worded as a pledge, it might make sense that if it (or something like it) is ever adopted, that existing developers membership being dependent on them agreeing to the pledge. That didn't happen with the previous SC change, but it seems strange to claim to have a social contract when a significant number of members don't actually support it 100%. I am not sure about the last part. If you said when a significant number of members don't actually abide by it 100%., I can agree. As much as we are discussing SC change now, we should allow us to discuss changing it as long as we abide by the current SC during its valid term. I mean people with view to have stricter FREE requirement should not be forced to leave project via this pledge process. I don't think the text I wrote puts any limits on how much you can support free stuff; it only puts limits on how much you can ignore other people's opinions and how poorly you can treat other people. If you only want to license your work under the MIT license, and never the GPL because you think that is too restrictive, eg, you can perfectly well make that pledge. To me, none of us made action which does not abide to the valid current SC. We only overruled a part of SC when it conflicted with another one in SC via GR. I.e. 100% free vs. user. I'm not saying the project doesn't support the SC as it stands, just that some DDs don't. That applies to both the remain 100% free claim (it's silly to do that now, because it wouldn't be a functioanl OS or we've never been 100% free up 'til now, how can we `remain' that way?) or the we support [non-free works'] use and provide infrastructure for non-free packages (but Debian will remain 100% free, I certainly won't, non-free should be dropped). It makes sense that day-to-day decisions that flow from the social contract might result in disagreements (eg, is the GFDL ever free?, should non-free be released as part of stable, or kept separately?, should packages in non-free ever delay packages in main getting released into testing or stable?), but when the social contract *itself* is the cause of disagreement within the project, I find that troubling. Although I did not agree to the current SC vote, I have been abiding to the current SC. Thus we casted our vote for this GR for lenny. Yeah, you can abide by a document you don't support, but if it's possible to get a document that 95% of the project as it stands actually *supports*, I think it makes sense to consider whether keeping the remaining 5% who have principled disagreements with some part or other is going to be a good way of running the project. My draft was written with the aim of being something that who simply want complete (software) freedom above all else could readily agree with, and sign their name to, as can people who don't much care about the politics or philosophy of free software and just want to keep some non-free packages well maintained. Maybe it doesn't succeed at that, I don't know. Anyway, given the last proposal I made [0] went nowhere, [...] This is Technical
Re: Results for General Resolution: Lenny and resolving DFSG violations
* devo...@vote.debian.org (devo...@vote.debian.org) [081228 00:47]: Dropping Option 1 because of Majority. (0.5176991150442477876106194690265486725664) 0.518 (117/226) 1 Dropping Option 2 because of Majority. (1.736434108527131782945736434108527131783) 1.736 (224/129) 3 Dropping Option 3 because of Majority. (1.406896551724137931034482758620689655172) 1.407 (204/145) 3 Dropping Option 4 because of Majority. (1.267973856209150326797385620915032679739) 1.268 (194/153) 3 Option 5 passes Majority. 1.194 (191/160) = 1 Dropping Option 6 because of Majority. (1.065088757396449704142011834319526627219) 1.065 (180/169) 3 Seeing these numbers, it seems to me that any of Options 2-6 passed about with the same majority (with preference for the lower numbers), and the only reason why Option 5 won was because of the majority requirements as set by the secretary. What this voting seems to show is that clearly a majority doesn't want to stop the release of Lenny. What it also shows however is that the mixing up of the other options on this ballot and the way the supermajority requirements were set is problematic, and probably supporters of any other option than 1 (and perhaps also except 6) can claim that they would've won if the majority requirements were set in a way they consider more appropriate. Cheers, Andi -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Sun, Dec 28, 2008 at 12:04:43AM +, devo...@vote.debian.org wrote: In the following table, tally[row x][col y] represents the votes that option x received over option y. Option 1 2 3 4 5 6 7 === === === === === === === Option 1 4660727389 117 Option 2281 160 160 171 177 224 Option 325561 125 137 151 204 Option 4253 121 146 160 166 194 Option 5234 105 128 135 136 191 Option 6220 118 134 125 134 180 Option 7226 129 145 153 160 169 Dropping Option 1 because of Majority. [...] Dropping Option 2 because of Majority. [...] Dropping Option 3 because of Majority. [...] Dropping Option 4 because of Majority. [...] Dropping Option 6 because of Majority. [...] The Schwartz Set contains: Option 5 Assume blobs comply with GPL unless proven otherwise If you consider the same results, without the supermajority requirements for options 2, 3, 4 and 6, you get: Winner: Option 2: Allow Lenny to release with proprietary firmware It beats the second choice by 39 votes (160 versus 121), which is: Second: Option 4: Empower the release team to decide ... They beat the third choice by 99 votes (160 versus 61) and 11 votes (146 versus 125) respectively, which is: Third: Option 3: Allow Lenny to release with DFSG violations They in turn beat the fourth choice (which was the winning option, choice 5) by, respectively, 66 votes (171 versus 105), 25 votes (160 versus 135), and 9 votes (137 versus 128). Fourth: Option 5: Assume blobs comply with GPL unless proven otherwise (winner as per listed supermajority requirements and devotee's mail) Option 5 beat option 6 by only two votes (136 versus 134), while the others beat option 6 by, respectively, 59 votes (177 v 118), and 41 votes (166 v 125), 17 votes (151 v 134). Fifth: Option 6: Exclude source requirements for firmware (defined) Further discussion came sixth, beaten by between 95 votes (option 2), and 11 votes (option 6), with Reaffirm the social contract last, defeated by further discussion by 109 votes. The only differences between the text of options 2 and 5 seems to be that option 2 says: Option 2: Allow Lenny to release with proprietary firmware 4. We give priority to the timely release of Lenny over sorting every bit out; for this reason, we will treat removal of sourceless firmware as a best-effort process, and deliver firmware as part of Debian Lenny as long as we are legally allowed to do so. whereas option 5 has an additional subclause: Option 5: Assume blobs comply with GPL unless proven otherwise 4. [same text as above, with the addition of:] and the firmware is distributed upstream under a license that complies with the DFSG. It's possible that has no practical difference, in which case all the furour over the running of the vote has no practical effect. If there are actual cases where the difference is important (firmware still included in the kernel or other packages that's explicitly licensed as non-free, rather than being licensed under the GPL or other free license, but not including something that looks like source code), then I guess it's a question of whether the immediate past secretary's ruling on the supermajority requirements for the vote are going to be considered binding. The voters have spoken, the bastards... --unknown Cheers, aj signature.asc Description: Digital signature
Re: Results for General Resolution: Lenny and resolving DFSG violations
* Anthony Towns (a...@azure.humbug.org.au) [081228 11:51]: [ difference between options 2 and 5] It's possible that has no practical difference, in which case all the furour over the running of the vote has no practical effect. Actually, if one reads the consitution the way I do (and where nobody has said anything against yet, except I don't like the outcome, which isn't really a constitutional reasoning), both options (as well as 4) are not really different to further discussion, except that we now have a stick to beat people with. Cheers, Andi -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
Hi, On Sun, 28.12.2008 at 21:08:04 +1000, Anthony Towns a...@azure.humbug.org.au wrote: If you consider the same results, without the supermajority requirements for options 2, 3, 4 and 6, you get: Winner: Option 2: Allow Lenny to release with proprietary firmware considering all the problems around this particular GR, what's the best way to just undo this GR and go back to square one instead? Methinks that this ballot was conducted in quite a wrong way, and that this outcome is simply ridiculous. Andi and Anthony have expressed this in softer words already, if I read their messages correctly. The two problems at hand are, from my perspective: 1 What do we want to do about the release of Lenny? 2 How do we want to treat the lingering problem of having blobs? (Because many people seem to feel that making a release-exception year after year is not the right thing to do. I generally agree with this.) Imho, Adeato's suggestion to split the vote was the right thing to do, so I'd say roll back this GR, and conduct two independent GRs with different questions instead, which I consider a better option than going with the current outcome where even Manoj admitted that he has conducted the GR the wrong way (I'd like to grab the opportunity to express the pain I felt when I saw him stepping down). Kind regards, --Toni++ signature.asc Description: Digital signature
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Sun, Dec 28, 2008 at 02:57:37PM +0100, Toni Mueller wrote: Winner: Option 2: Allow Lenny to release with proprietary firmware considering all the problems around this particular GR, what's the best way to just undo this GR and go back to square one instead? It seems to me the simplest way is to just start making GR proposals for a new vote. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Sun, Dec 28, 2008 at 09:08:04PM +1000, Anthony Towns wrote: Further discussion came sixth, beaten by between 95 votes (option 2), and 11 votes (option 6), with Reaffirm the social contract last, defeated by further discussion by 109 votes. Oh, a further thought came to mind. One way to simplify the vote is to look at who ranked option 1 (reaffirm the SC/delay lenny) first. There were a few interesting votes, that didn't rank any option first, namely: V: 6353227etobi Tobias Grimm V: -77---7 msameer Mohammed Sameer V: 2-- pape Gerrit Pape (There's nothing special about those votes from a constitutional POV, but they're an interesting way of communicating none of these options are my first choice, imho) Aside from those, everyone indicated some choice as #1. Five people ranked Option 1 as #1 _in addition to_ some other option, namely: V: 111amaya Amaya Rodrigo Sastre V: 112bartm Bart Martens V: 1---1-2 guus Guus Sliepen V: 1231--- reg Gregory Colpart V: 1132457 tale Tapio Lehtonen Additionally, 27 voters ranked option #1 above all other options (not counting p...@d.o, listed above): V: 145-2-3 adejong Arthur de Jong V: 1-2 bahner Lars Bahner V: 1356472 ballombe Bill Allombert V: 132 bas Bas Zoetekouw V: 1-2bayle Christian Bayle V: 1546372 brlink Bernhard Link V: 1465732 cmb Chris Boyle V: 1667273 daniel Daniel Baumann V: 1---3-2 dmn Damyan Ivanov V: 1267225 edelhard Edelhard Becker V: 1-2 godisch Martin Godisch V: 1456273 guillem Guillem Jover V: 1345362igloo Ian Lynagh V: 1237465 jaqque John Robinson V: 1546372 js Jonas Smedegaard V: 1-- lbrenta Ludovic Brenta V: 1345672 mmagallo Marcelo Magallon V: 1346562 pabs Paul Wise V: 1--paulwaite Paul Waite V: 1346275 peters Peter Samuelson V: 1236254 rmh Robert Millan V: 177 roktas Recai Oktas V: 1256473 schizo Clint Adams V: 1564372 stew Mike O'Connor V: 1456273 tb Thomas Bushnell V: 1--22-- timo Timo Jyrinki V: 1345672 vlm Vince Mulhollon Additionally, of the voters who ranked FD first, there was only one voter who then ranked option #1 above all the other options: V: 231 toni Toni Mueller By my count, that's a total of 29 developers in favour of a fairly strict interpretation of the social contract compared to the other options available, along with another 5 who consider that equally with some (but not all) of the other options, out of the 367 developers counted in the tally. That compares (somewhat loosely) with 42 developers (out of 323) voting FD above Release etch even with kernel firmware issues in the 2006 vote [0], or the 38 developers (out of 396) who voted for the Reaffirm changes option in the 2004 vote [1]. [0] http://www.debian.org/vote/2006/vote_007 [1] http://www.debian.org/vote/2004/vote_004 As percentages, that's 9.6% in 2004, 13% in 2006, and 9.3% in 2008 -- though the comparison is particularly weak since unlike the 2004 and 2008 ballots, the 2006 ballot doesn't distinguish between voters trying to say I don't want to vote on this and I don't want to see etch release with non-DFSG-free firmware. Those seem like lower numbers than I might have expected. YMMV. Also somewhat interesting: there were 17 developers who didn't express any preference amongst the options on offer (all simply voted in favour of further discussion): V: 221 ana Ana Beatriz Guerrero L??pez V: 221 anibal Anibal Monsalve Salazar V: --1arjan Arjan Oosting V: 221 bureado Jose Parrella V: 771 costela Leo Costela V: --1 dajobe Dave Beckett V: 221 filippo Filippo Giunchedi V: --1 florian Florian Ernst V: 221 francois Francois Marier V: --1helen Helen Faulkner V: --1 jluebbe Jan L??bbe V: --1jordi Jordi Mallach V: --1lange Thomas Lange V: 771 mace Miah Gregory V: --1 mhy Mark Hymers V: --1 sto Sergio Talens-Oliag V: 221vince Vincent Sanders And there were an additional 22 voters who just didn't distinguish between the various let lenny release options (8 in
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Sun, 2008-12-28 at 09:05 +0100, Andreas Barth wrote: What this voting seems to show is that clearly a majority doesn't want to stop the release of Lenny. What it also shows however is that the mixing up of the other options on this ballot and the way the supermajority requirements were set is problematic, and probably supporters of any other option than 1 (and perhaps also except 6) can claim that they would've won if the majority requirements were set in a way they consider more appropriate. It is problematic? Are you saying that the 2/3 requirement for changes to the foundation documents should not apply if a majority thinks otherwise? Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
* Thomas Bushnell BSG (t...@becket.net) [081228 23:56]: On Sun, 2008-12-28 at 09:05 +0100, Andreas Barth wrote: What this voting seems to show is that clearly a majority doesn't want to stop the release of Lenny. What it also shows however is that the mixing up of the other options on this ballot and the way the supermajority requirements were set is problematic, and probably supporters of any other option than 1 (and perhaps also except 6) can claim that they would've won if the majority requirements were set in a way they consider more appropriate. It is problematic? Are you saying that the 2/3 requirement for changes to the foundation documents should not apply if a majority thinks otherwise? I'm not convinced why e.g. resolution 4 needs a 3:1-majority requirement, even though I cannot really see a difference between further discussion and that variant. But we already had all of that prior and during the vote, no need to repeat it. Cheers, Andi -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
Thomas Bushnell BSG t...@becket.net writes: On Sun, 2008-12-28 at 09:05 +0100, Andreas Barth wrote: What this voting seems to show is that […] the mixing up of the other options on this ballot and the way the supermajority requirements were set is problematic, and probably supporters of any other option than 1 (and perhaps also except 6) can claim that they would've won if the majority requirements were set in a way they consider more appropriate. It is problematic? Are you saying that the 2/3 requirement for changes to the foundation documents should not apply if a majority thinks otherwise? Several points here: A 3:1 supermajority is ¾, not ⅔. Some members do not agree with the actual supermajority requirements as assigned to the options on the ballot, which is not a comment on how those people think we should change foundation documents. Some members do not agree that the supermajority-required ballot options actually required changes to the foundation documents, which is not a comment on how those people think supermajority requirements should be assigned. I can only conclude that we really do need to see a vote (as proposed earlier) on how the SC and DFSG should affect the Debian project. The outcome of that vote would help me, at least, to understand what the project thinks the relationship is between our actions and the foundation documents. -- \ “I love and treasure individuals as I meet them, I loathe and | `\ despise the groups they identify with and belong to.” —George | _o__) Carlin, 2007 | Ben Finney -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, Dec 29, 2008 at 12:48:24AM +, Simon Huggins wrote: I thought FD was also a vote for release Lenny given it didn't change the status quo and before the GR the release team were quite happy to release... If you believe that the release team had the authority to release lenny with an arbitrary amount of non-free software, then yes, that would seem accurate. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, Dec 29, 2008 at 12:48:24AM +, Simon Huggins wrote: I wonder how many DDs were ashamed to vote the titled Reaffirm the social contract lower than the choices that chose to release. I'm not ashamed at all; I joined before the 1.1 revision to the Debian Social Contract, which I objected to them, and I still object to now. If there was a GR which chainged the Debian Social contract which relaxed the first clause to only include __software__ running on the Host CPU, I would enthusiastically vote for such a measure. Also see: http://thunk.org/tytso/blog/2008/12/28/debian-philosophy-and-people - Ted -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
Anthony Towns wrote: Anyway, despite something kinda close to advocacy for the FD option in the second call for votes on d-d-a, FD lost convincingly to most of the options on offer. So of any conclusions you might draw, the simplest, safest and most easily justified seems to be stop discussing this and release lenny... I've heard this before and I'm not sure I understand it. Lenny is _not_ in a releaseable state. We have enough RC bugs that it will take a while to be able to release. How's the discussion hurting the release at the moment? Unless you are suggesting that people discuss _instead of_ fixing RC bugs, to which I'm not sure I agree. Personally, I'm fine with the in depth discussion and with the voting as long as it's not a blocker for the release. That's not to say that I'm not getting tired of discussing the same thing again and again; I firmly believe that we should have one or more sane and clear GR(s), with no for this release/time period only options and end this matter once and for all. Regards, Faidon -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, 2008-12-29 at 11:54 +1100, Ben Finney wrote: Some members do not agree that the supermajority-required ballot options actually required changes to the foundation documents, which is not a comment on how those people think supermajority requirements should be assigned. I can only conclude that we really do need to see a vote (as proposed earlier) on how the SC and DFSG should affect the Debian project. The outcome of that vote would help me, at least, to understand what the project thinks the relationship is between our actions and the foundation documents. Well, the only way your first paragraph can make sense is if the second is almost right. If people think that the foundation documents can be sidestepped by a mere majority vote, then they think that they simply don't *really* apply, and so a decision not to follow them is not tantamount to an amendment of them. But I disagree that we need a vote. We already have the foundation documents, and they already apply. If people want to amend them into mere suggestions (perhaps the way the Bush administration regarded US law), they are welcome to suggest that vote. Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Sun, 2008-12-28 at 20:45 -0500, Theodore Tso wrote: On Mon, Dec 29, 2008 at 12:48:24AM +, Simon Huggins wrote: I wonder how many DDs were ashamed to vote the titled Reaffirm the social contract lower than the choices that chose to release. I'm not ashamed at all; I joined before the 1.1 revision to the Debian Social Contract, which I objected to them, and I still object to now. If there was a GR which chainged the Debian Social contract which relaxed the first clause to only include __software__ running on the Host CPU, I would enthusiastically vote for such a measure. Can you please define host CPU for us? Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, 2008-12-29 at 15:02 +1000, Anthony Towns wrote: For example, having non-free in the archive and the BTS (and potentially buildds and elsewhere) is implied by point (3) (ie, supporting Debian users who choose to use non-free software to the best of our ability), and potentially using non-free software ourselves (such as qmail or pgp in the past) may be implied by point (2) (using the best available tools and techniques to do the best job we can). I would personally prefer for the project to have the freedom to decide those sorts of things on a day-to-day basis through regular decision making (maintainers, list debate, DPL, ftpmaster, RM, tech-ctte, simple majority vote), but I don't know if the rest of the project will buy that these days. I'm fairly sure some people won't, at any rate. I would prefer this. But I am afraid of it, and so I would vote against it. I am afraid that there are folks in the project who really don't care if Debian is 100% free--even as a goal. I think that Ted Tso is even one of them. My fear is that if we say, It is a goal that Debian be 100% free, and leave it up to the ordinary process of people doing their work, then people who oppose that goal, who think it is a foolish goal, or an unworthy one, will simply obstruct it. It is this which bothered me about the release team's methodology vis-a-vis this issue this time around. Not that I thought they were deliberately obstructing our goals--I have no reason to think they were doing anything but making a pragmatic decision as best as they could at the time--but because I can't know for sure. And, then when the controversy erupted, there were people expressing views that I *do* think are simply contrary to our goals, lauding the release team for ostensibly obstructing the social contract's absolutism. I wish we could have in the world of GNU/Linux one, just one, please--just one--distribution which really took free software as of cardinal importance. Debian has promised to be that, while living up to the promise only in fits and starts. That's ok with me. But I'm afraid that if we stopped the promise, and simply decided it would be our goal, the folks who are against the promise will be against the goal, and will see this as permission to simply *never* work toward the goal, and to obstruct others who do. Since it's worded as a pledge, it might make sense that if it (or something like it) is ever adopted, that existing developers membership being dependent on them agreeing to the pledge. That didn't happen with the previous SC change, but it seems strange to claim to have a social contract when a significant number of members don't actually support it 100%. In my opinion, developers who are unwilling to abide by the Social Contract in their Debian work should resign. But they don't, and this is what has me afraid. Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org