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-devel-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-devel-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-devel-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
* 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-devel-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-devel-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
* 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-devel-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-devel-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 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-devel-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
(Resending a previous private answer to Theodore since I believe it is relevant to the discussion..) Le Monday 29 December 2008 15:11:01 Theodore Tso, vous avez écrit : 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 read your post. It is interesting and well argued. However, I have the impression that it somehow draws the picture of a seperation between productive pragmatic guys and idealist unproductive ones. For instance, you could also mention all the great work the the GNU and Stallman pioneered at there time. After all, if the pragmatic guy, Linus, decided to go for the GPL as it was GCC's licence, it was because the idealist one had prepared this for more than 10 years before. Yes, pragmatism is a need when something has to happen sooner rather than later. I, too, believe that in the case of lenny, this was an issue. But when it comes to more general purpose, I really support the central place of idealism. That is only this way that you can prepare and build a great change such as the GNU fondation did. To me, the social contract is a very good compromise. It states first an idealist acheivement, but moderates it by some pragmatism concerning the users. unproductive discussions fall into the same category, when they do not end as flames or trolls. That is mainly why I am against the notion of Code of Conduct. Eventually, that is also the same vision that drives me in politics: an ideal goal moderated by pragmatism. Not the converse. Romain -- To UNSUBSCRIBE, email to debian-devel-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-v...@lists.debian.org, debian-devel@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 04:38:25PM +0100, Romain Beauxis wrote: To me, the social contract is a very good compromise. It states first an idealist acheivement, but moderates it by some pragmatism concerning the users. unproductive discussions fall into the same category, when they do not end as flames or trolls. It's a claim which has never been true. Debian shall _remain_ 100% free? Remain implies that at one stage Debian had reached such a state of Nirvana. That has never been the case! The disputes that we have had, at each stable release since the 1.1 revision to the Social Contract, have been precisely because some large, and vocal, set of developers have not been willing to be pragmatic, but who have instead argued for a very literalistic reading of the Social Contract. That is mainly why I am against the notion of Code of Conduct. I don't see the connection which leads you to be against a Code of Conduct, but I will note that Ubuntu CoC does not use any absolute words. It merely asks participants to: * Be considerate * Be respectful * Be collaborative * When you disagree, consult others * When you are unsure, ask for help * Step down considerately These are idealistic goals --- by your own argument, what's wrong with having them? We need to moderate them by an understanding that human nature being what it is, we will occasionally fail at this ideal; and then ecourage and remind each other to try to strive for this as an ideal --- not throw people out of the project when they fail to live up to such a goal. Maybe you don't like the name Code of Conduct, because it implies a certain amount of inflexibility? If so, maybe a different name would make you more comfortable? Eventually, that is also the same vision that drives me in politics: an ideal goal moderated by pragmatism. Not the converse. That's my vision as well; we might disagree about how far our pragmatism might take us, but our ideals tell us which direction to go, even if we are far from it at the moment. The question is how much patience do we have, and should we have? I do feel quite strongly, that aspirational goals, if they are going to be in Foundation Documents, must be clearly *labelled* as aspirational goals, and not as inflexible mandates that _MUST_ be kept. In politics, can have aspirational ideals such as a chicken in every pot and two cars in every garage which get used in campaign slogans, but you don't put such things as a MUST in a country's constitution. - Ted -- To UNSUBSCRIBE, email to debian-devel-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
Le Monday 29 December 2008 17:21:16 Theodore Tso, vous avez écrit : I do feel quite strongly, that aspirational goals, if they are going to be in Foundation Documents, must be clearly *labelled* as aspirational goals, and not as inflexible mandates that _MUST_ be kept. In politics, can have aspirational ideals such as a chicken in every pot and two cars in every garage which get used in campaign slogans, but you don't put such things as a MUST in a country's constitution. Freedom of speech is a constitutional disposition, and I don't think it is something that could be acheive. It really is a constitutional act. It is also why I am against the Code of Conduct. Freedom of speech is an utopism that I support for Debian, and a Code of Conduct, or whatever you call it, is a way to shut those who do abid to the politically-correctness way of expressing oneself. As Orwell noticed it 50 years ago, restricting expressiveness is also restricting though. When someone shocks you with a broomstick, a Teletubies or a ironic picture, it breaks the lines and helps to reconsider you thoughs too. More generally, the Human Rights is also a list of idealistic acheivements. However, it is a fundamental document at the United Nations for instance. From time to time, people complain about the unrealistic consequences of them, such as our foreign minister here, but still they remain central in every place. To transpose the discussion, how would you argue in the same debate, but about utopism generated by the Human Rights ? That Guantanamo was a pragmatic need to the USA to protect themselves ? That torturing people in Algeria was a pragmatic need for the french people ? (*) Yes, I am exagerating, but adding bit of utopism is more then only stating its good will to someday probably perhaps do something about that. Romain (*) Please note that I am not insinuating that you are pro-guantanamo :) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [s...@powerlinux.fr: Re: Results for General Resolution: Lenny and resolving DFSG violations]
I think the problem is not really the social contract, what it currently says is just fine, and we all agree with it. ACK. 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 also agree in parts with you. There was already somewhere a discussion about, my opinion is, that it would be good to have e.g. an additional non-free netinstaller medium, which includes non-free parts like bnx2 firmwares, some non-free drivers which are necessary to run this machine and to get a connectivity (so on also WLAN blobs). e.g. we have some servers with those bnx2 (aka brotcom netextreme II) cards, with the netinstaller we can not get a connectivity to the network, remote installations are so on for the a... :) 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. The point is (except from some realy crazy licenses) that the most ppl in Debian (I am counting myself to this group) do not want to support non-free stuff, which is also an enforcement for the vendor/programmer to switch to a free solution. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi E-Mail: patrick.matth...@web.de Comment: Always if we think we are right, we were maybe wrong. */ -- To UNSUBSCRIBE, email to debian-devel-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-devel-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-devel-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
Romain Beauxis to...@rastageeks.org writes: Le Monday 29 December 2008 17:21:16 Theodore Tso, vous avez écrit : I do feel quite strongly, that aspirational goals, if they are going to be in Foundation Documents, must be clearly *labelled* as aspirational goals, and not as inflexible mandates that _MUST_ be kept. In politics, can have aspirational ideals such as a chicken in every pot and two cars in every garage which get used in campaign slogans, but you don't put such things as a MUST in a country's constitution. Freedom of speech is a constitutional disposition, and I don't think it is something that could be acheive. It really is a constitutional act. Which constitution? I don't see any reference to it in Debian's constitution, and the constitution of the country in which I live doesn't guarantee anything at all about someone's ability to use project mailing lists. It only constrains the actions of the *government*, not private projects and their use of their own resources. I've stopped working on other projects in the past because this idea that anyone can and should be able to say anything that enters their head at any time, no matter how uncomfortable or miserable they made it for other people working on the same project, became so prevelant that the atmosphere became so hostile that it became impossible to have a reasonable conversation about any even mildly controversial topic. Debian isn't there now, and maybe it's not in imminent danger of degrading to that point, but I've watched it happen and know that it *can* happen. It's not a theoretical scenario. People like to advocate the merits of personal filtering as if it solves all of these problems. I used to do that myself before I lived through one of those collapses of good will. Personal filtering is not a bad answer to individual people who are widely ignored. It does nothing when the tone of conversation degrades to the point where polite conversation is drowned out by multiple people yelling at each other. It's also rather hard to just ignore people when they start calling you things like pedophile out of the blue (yes, this actually happened). I'm not, at present, wholly convinced that a Code of Conduct would help or how it would work. But this dedication to free speech inside a working project is, in my opinion, a nasty bit of blindness. I've seen that ideal rip people to shreds and tear apart previously working communities. I think one can possibly make an argument that Debian is unlikely to be susceptible to that, but I think that argument has to be made. The problem can't be casually dismissed -- it's happened elsewhere. It is also why I am against the Code of Conduct. Freedom of speech is an utopism that I support for Debian, and a Code of Conduct, or whatever you call it, is a way to shut those who do abid to the politically-correctness way of expressing oneself. As Orwell noticed it 50 years ago, restricting expressiveness is also restricting though. I'm in the middle of a study of Orwell's fiction and non-fiction writing and therefore can say with quite a bit of confidence that Orwell would not have supported the position that you're taking. Political correctness is apparently what people now call basic human politeness when they want to ridicule it. *There's* your Orwellian Newspeak. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-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-devel-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-devel-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-devel-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 17:45:56 +0100, Romain Beauxis wrote:
Freedom of speech is a constitutional disposition, and I don't think it is
something that could be acheive. It really is a constitutional act.
It is also why I am against the Code of Conduct. Freedom of speech is an
utopism that I support for Debian, and a Code of Conduct, or whatever you
call it, is a way to shut those who do abid to the politically-correctness
way of expressing oneself.
TTBOMK there's no unrestricted Freedom of Speech in any constitution.
The constitutional Freedom of Speech does not cover what someone is
allowed to do in my living room, does not allow to shout aloud at 4
a.m. in front of my sleeping room and makes libellous public
statements prosecutable. (And I'm ignoring here more local
restrictions like political campaigning on election days or denial of
the Holocaust etc.)
If Debian adopts a CoC (which probably is nothing more than writing
down patterns of obvious behaviour among civilized grown-ups) that
would not be an infringement of Freedom of Speech -- it would just
set rules for specific fora and it would not hinder anyone from
expressing there thoughts in their preferred way in other media.
I also agree with Russ' statement that guarantees about Freedom of
Speech (and against censorship) only constrain[s] the actions of the
*government*. Or more bluntly: Debian simply cannot censor anyone,
and an inflationary use of censorship just blurs and weakens
this term.
On a more personal note: I still don't understand why the expressed
wish of several people please treat your fellows with respect can
cause such a stir.
Cheers,
gregor
--
.''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/
`. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
`-NP: Tina Turner: The Best
signature.asc
Description: Digital signature
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
* 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-devel-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
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, 28 Dec 2008 14:57:37 +0100 Toni Mueller t...@debian.org wrote: 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? Let it stand and release Lenny? After all, the only option that would have delayed Lenny further was Option 1 that didn't get close to winning under any reading of the votes. 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. True, but the reason for the GR has been comprehensively defeated - Lenny should not be delayed whilst every byte of every blob is removed (Option 1). Can't we just follow the result and release Lenny on a best-effort process? The two problems at hand are, from my perspective: 1 What do we want to do about the release of Lenny? Go ahead and do it, IMHO. 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.) This GR was all about Lenny - there has been no change to the DFSG (due to the majority determinations made for this GR) so the whole thing needs to be redone before Squeeze - but I don't see that anything needs to be done *NOW*, other than to implement the result on a best-effort basis and get Lenny released. 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). Personally, I think the vote should stand, despite the flaws. It only applies to Lenny - get Lenny out and sort out the underlying problems for Squeeze. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgppL9l1gM50o.pgp Description: PGP 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 Mon, Dec 29, 2008 at 02:45:29AM +1000, 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 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... Sure, either way the conclusion is undoubtedly release Lenny. I wonder how many DDs were ashamed to vote the titled Reaffirm the social contract lower than the choices that chose to release. Simon. -- oOoOoA mess, eh? - Morgan Feels like home... - MulderoOoOo oOoOo(Piper Maru)oOoOo oOoOo oOoOo htag.pl 0.0.24 ::: http://www.earth.li/~huggie/ signature.asc Description: Digital signature
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, Dec 29, 2008 at 01:07:33AM +, Clint Adams wrote: 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. The ftpmasters and DDs in general are the arbiters of what goes in main. The release team switch a symlink amongst other things (like doing a hell of a lot of work to make sure we have fewer RC bugs than we did at the start of the freeze and policing transitions etc). -- --( I'm gonna eat you, little fishy! - The Cat )-- --( )-- Simon ( ) Nomis Htag.pl 0.0.24 -- To UNSUBSCRIBE, email to debian-devel-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-devel-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-devel-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-devel-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 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. 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. 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: 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. 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. 3. We will build a universal operating system We will accept the use of our operating system by all users, for all purposes, without discrimination. We will support our users to the best of our ability in all the choices they make, no matter what our opinion of those choices may be. 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. 5. We will respect the community We will ensure that members of the community can easily and effectively contribute their skills and views to the project. We will respect the membership of the community, and ensure that our treatment of their contributions reflects that respect. 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. 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. 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. 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. 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. One other thing the above does is, unlike the current SC, is use the word Debian to refer solely to the project -- so it
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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Results for General Resolution: Lenny and resolving DFSG violations
Greetings,
This message is an automated, unofficial publication of vote results.
Official results shall follow, sent in by the vote taker, namely
Debian Project Secretary
This email is just a convenience for the impatient.
I remain, gentle folks,
Your humble servant,
Devotee (on behalf of Debian Project Secretary)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Starting results calculation at Sun Dec 28 00:03:02 2008
Option 1 Reaffirm the Social Contract
Option 2 Allow Lenny to release with proprietary firmware [3:1]
Option 3 Allow Lenny to release with DFSG violations [3:1]
Option 4 Empower the release team to decide about allowing DFSG violations
[3:1]
Option 5 Assume blobs comply with GPL unless proven otherwise
Option 6 Exclude source requirements for firmware (defined) [3:1]
Option 7 Further Discussion
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
Looking at row 2, column 1, Allow Lenny to release with proprietary firmware
[3:1]
received 281 votes over Reaffirm the Social Contract
Looking at row 1, column 2, Reaffirm the Social Contract
received 46 votes over Allow Lenny to release with proprietary firmware [3:1].
Option 1 Reached quorum: 117 47.8591684006314
Option 2 Reached quorum: 224 47.8591684006314
Option 3 Reached quorum: 204 47.8591684006314
Option 4 Reached quorum: 194 47.8591684006314
Option 5 Reached quorum: 191 47.8591684006314
Option 6 Reached quorum: 180 47.8591684006314
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
Option 5 defeats Option 7 by ( 191 - 160) = 31 votes.
The Schwartz Set contains:
Option 5 Assume blobs comply with GPL unless proven otherwise
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The winners are:
Option 5 Assume blobs comply with GPL unless proven otherwise
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--
The voters have spoken, the bastards... --unknown
DEbian VOTe EnginE
digraph Results {
ranksep=0.25;
Reaffirm the Social Contract\n0.52 [ style=filled , color=pink,
shape=octagon, fontname=Helvetica, fontsize=10 ];
Further Discussion - Reaffirm the Social Contract\n0.52 [ label=109 ];
Allow Lenny to release with proprietary firmware [3:1]\nMajority=1.74 -
Reaffirm the Social Contract\n0.52 [ label=235, style=dotted,
color=pink ];
Empower the release team to decide about allowing DFSG violations
[3:1]\nMajority=1.27 - Reaffirm the Social Contract\n0.52 [ label=181,
style=dotted, color=pink ];
Allow Lenny to release with DFSG violations [3:1]\nMajority=1.41 -
Reaffirm the Social Contract\n0.52 [ label=195, style=dotted,
color=pink ];
Exclude source requirements for firmware (defined) [3:1]\nMajority=1.07 -
Reaffirm the Social Contract\n0.52 [ label=131, style=dotted,
color=pink ];
Allow Lenny to release with proprietary firmware [3:1]\n1.74 [
style=filled , color=pink, shape=octagon, fontname=Helvetica, fontsize=10
];
Further Discussion - Allow Lenny to release with proprietary firmware
[3:1]\n1.74 [ label=-95 ];
Allow Lenny to release with DFSG violations [3:1]\n1.41 [ style=filled ,
color=pink, shape=octagon, fontname=Helvetica, fontsize=10 ];
Further Discussion - Allow Lenny to release with DFSG violations
[3:1]\n1.41 [ label=-59 ];
Allow Lenny to release with proprietary firmware [3:1]\nMajority=1.74 -
Allow Lenny to release with DFSG violations [3:1]\n1.41 [ label=99,
style=dotted, color=pink ];
Empower the release team to decide about allowing DFSG violations
[3:1]\nMajority=1.27 - Allow Lenny to release with DFSG violations
[3:1]\n1.41 [ label=21, style=dotted, color=pink ];
Empower the release team to decide about allowing DFSG violations
[3:1]\n1.27 [ style=filled , color=pink,
