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 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
Re: RFC: General resolution: Clarify the status of the social contract
Manoj Srivastava wrote: > Given that, I suggest we have a series of proposals and > amendments, each in a separate email, sponsored and seconded > independently, that could look something like this below: > > ,[ The Social contract is a binding contract ] > | The developers, via a general resolution, determine that the social > | contract should apply to everything Debian does, now and in the future; > | _AND_ the social contract should stop us from including anything that > | doesn't comply with the DFSG in main > ` Sorry for stepping in so late - I simply don't have time to read all those mails. What you seem to have forgotten an option like ,[ The Social contract is a binding contract ] | The developers, via a general resolution, determine that the social | contract should apply to everything Debian does, now and in the future; | _AND_ the social contract should stop us from including anything that | doesn't comply with the DFSG in main , _AND_ the social contract should stop us from releasing anything that doesn't comply with the needs of our users ` Which makes it clear that this is a bogus discussion: As long as our priorities are our users AND free software, we cannot let only one of both make the single criterion for our actions. Even an option like this: > ,[ The social contract is a goal, not a binding contract ] > | This amends the proposal above, and replaces the text of the proposal > | with: The developers, via a general resolution, determine that the > | social contract is an aspirational document: while we aim to achieve as > | much of it as feasible at all times, we don't expect to get it > | completely right for some time yet. This includes DFSG-freeness of all > | firmware > ` is still focussed on free software only, and also feeds the illusion that in some time point in the future we would have sorted out all issues with software freeness (and will only then start to tackle this other thing, users?) > I think we need this clarification, so people no longer accuse > other people of malfeasance based on a flawed understanding on the > correct status of foundation documents. I am sure this wouldn't help at all, except if we'd vote for the first option, which I believe would mean forking: Orthodox Debian which never releases, and a derived or related distribution which would be comparable to Debian as it is. Regards, Frank -- Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- 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 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
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. -- oOoOo"A 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
Thomas Bushnell BSG 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 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-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 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 t
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
