Results for General Resolution: Lenny and resolving DFSG violations
dev...@vote.debian.org
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 46 60 72 73 89 117
Option 2 281 160 160 171 177 224
Option 3 255 61 125 137 151 204
Option 4 253 121 146 160 166 194
Option 5 234 105 128 135 136 191
Option 6 220 118 134 125 134 180
Option 7 226 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
Andreas Barth
> 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-vo...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Anthony Towns
> 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 46 60 72 73 89 117
> Option 2 281 160 160 171 177 224
> Option 3 255 61 125 137 151 204
> Option 4 253 121 146 160 166 194
> Option 5 234 105 128 135 136 191
> Option 6 220 118 134 125 134 180
> Option 7 226 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
Andreas Barth
> [ 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.
Toni Mueller
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++
Antti-Juhani Kaijanaho
> > 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/
Anthony Towns
> 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: 6353227 etobi 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: 11----1 amaya Amaya Rodrigo Sastre
V: 1----12 bartm 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 pape@d.o, listed above):
V: 145-2-3 adejong Arthur de Jong
V: 1-----2 bahner Lars Bahner
V: 1356472 ballombe Bill Allombert
V: 1333332 bas Bas Zoetekouw
V: 1-----2 bayle 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: 1345362 igloo 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: 1777777 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: 23----1 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: 2222221 ana Ana Beatriz Guerrero L??pez
V: 2222221 anibal Anibal Monsalve Salazar
V: ------1 arjan Arjan Oosting
V: 2222221 bureado Jose Parrella
V: 7777771 costela Leo Costela
V: ------1 dajobe Dave Beckett
V: 2222221 filippo Filippo Giunchedi
V: ------1 florian Florian Ernst
V: 2222221 francois Francois Marier
V: ------1 helen Helen Faulkner
V: ------1 jluebbe Jan L??bbe
V: ------1 jordi Jordi Mallach
V: ------1 lange Thomas Lange
V: 7777771 mace Miah Gregory
V: ------1 mhy Mark Hymers
V: ------1 sto Sergio Talens-Oliag
V: 2222221 vince Vincent Sanders
And there were an additional 22 voters who just didn't distinguish between
the various "let lenny release" options (8 in the "Reaffirm SC camp,
14 in the "release lenny as is" camp):
V: 1-----2 bahner Lars Bahner
V: 1333332 bas Bas Zoetekouw
V: 1-----2 bayle Christian Bayle
V: 1-----2 godisch Martin Godisch
V: 1------ lbrenta Ludovic Brenta
V: 2------ pape Gerrit Pape
V: 1------ paulwaite Paul Waite
V: 1777777 roktas Recai Oktas
V: 3222221 adeodato Adeodato Sim??
V: 7222221 des Dami??n Viano
V: 3111112 edd Dirk Eddelbuettel
V: 7111116 jak Julian Klode
V: -222221 jcristau Julien Cristau
V: 3222221 joss Josselin Mouette
V: 3222221 kibi Cyril Brulebois
V: 3111112 kmccarty Kevin McCarty
V: -222221 madcoder Pierre Habouzit
V: 3111112 maks Maximilian Attems
V: 3222221 marga Margarita Manterola
V: 3111112 nduboc Nicolas Duboc
V: 3111111 sdt Stuart Teasdale
V: 3222221 vela Matej Vela
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"...
Cheers,
aj
Thomas Bushnell BSG
> 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
Andreas Barth
> 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
Simon Huggins
> 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..." - Mulder oOoOo
oOoOo (Piper Maru) oOoOo
oOoOo oOoOo
htag.pl 0.0.24 ::::::: http://www.earth.li/~huggie/
Ben Finney
> 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
Clint Adams
> 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.
Simon Huggins
> On Mon, Dec 29, 2008 at 12:48:24AM +0000, 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
Theodore Tso
>
> 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
Faidon Liambotis
> 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"...
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
Thomas Bushnell BSG
> On Mon, Dec 29, 2008 at 12:48:24AM +0000, 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
Thomas Bushnell BSG
> 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
Anthony Towns
> On Mon, Dec 29, 2008 at 12:48:24AM +0000, 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 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.
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%.
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.
Cheers,
aj
[0] http://lists.debian.org/debian-vote/2008/03/msg00025.html
Thomas Bushnell BSG
> 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
Raphael Hertzog
> 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-dev...@lists.debian.org
Joerg Jaspert
>> I thought FD was also a vote for "release Lenny" given it didn't change
>> the status quo and before the GR the release team were quite happy to
>> release...
> If you believe that the release team had the authority to release lenny
> with an arbitrary amount of non-free software, then yes, that would
> seem accurate.
For someone that is in Debian for so long its pretty bad how one can
misjudge it...
The release team has the authority to release Lenny. At whatever point
they wish and feel good with it. They provide a list of what criteria
need to be met for that. For the package contents of that release, they
take whatever we, all the maintainers uploading packages, and what we,
the ftpmasters, put into the archive.
Now, if one dislikes a decision of a delegate, one can run a GR
against it. Somehow we just had one, and the outcome does say they can
release with the kernel that is currently in Lenny. Like it or not, but
thats the option that won, no matter how fucked up the ballot may have
been. Dislike this outcome? Do Debian a bad service and run yet another
GR against Lenny. Or, to have something new, do such things right
*after* a release, not right before one.[1]
[1] But that wouldn't be half as fun complaining, wouldnt hurt Debian
as much, eh?
--
bye, Joerg
<lamont> is there a tag for "won't be fixed until sarge+1"?
<sam> depends whether the BTS is year 2037 compliant
Adeodato Simó
> 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.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: La Buena Vida - No lo esperaba de mí
Osamu Aoki
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 +0000, 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" vs. "user".
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.
> 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.
...
> [0] http://lists.debian.org/debian-vote/2008/03/msg00025.html
This is "Technical committee resolution". I am not very clear about
what Anthony is talking here.
Osamu
PS: Current process to set 3:1 majority requirement by the secretary is
understandable one since we have no supreme court to struck down a GR
when it conflicts with valid current SC. We may wish to change this
decision of 3:1 requirement to be made by elected person such as DPL.
But that is orthogonal and mere procedural issue which needs to be
cleared in some future independently.
Marco d'Itri
>I would prefer this. But I am afraid of it, and so I would vote against
>it. I am afraid that there are folks in the project who really don't
>care if Debian is 100% free--even as a goal. I think that Ted Tso is
>even one of them.
Count me in as well then, since I completely share his opinion.
>I wish we could have in the world of GNU/Linux one, just one,
>please--just one--distribution which really took free software as of
>cardinal importance. Debian has promised to be that, while living up to
What about you spend your time hacking on gnewsense then, and let us
create on an OS which will also be useful?
--
ciao,
Marco
Marco d'Itri
>On Sun, 2008-12-28 at 20:45 -0500, Theodore Tso wrote:
>> I'm not ashamed at all; I joined before the 1.1 revision to the Debian
>> Social Contract, which I objected to them, and I still object to now.
>> If there was a GR which chainged the Debian Social contract which
>> relaxed the first clause to only include __software__ running on the
>> Host CPU, I would enthusiastically vote for such a measure.
<aol>Me too.</aol>
>Can you please define "host CPU" for us?
What about the same one which is executing the OS kernel?
--
ciao,
Marco
Anthony Towns
> On Mon, 2008-12-29 at 15:02 +1000, Anthony Towns wrote:
> > I would personally prefer
> > for the project to have the freedom to decide those sorts of things
> I would prefer this. But I am afraid of it, and so I would vote against
> it. I am afraid that there are folks in the project who really don't
> care if Debian is 100% free--even as a goal. I think that Ted Tso is
> even one of them.
Whatever his motives, I think Ted's demonstrably done more to further the
cause of free software than most developers, both by making Linux more
and more usable for over 15 years now, and for helping other developers
work together better, such as by organising the kernel summit.
I'm all for having a 100% free system, and then some, but if it comes
down to a choice between supporting absolute freeness without exception,
and working with folks like Ted, I'm more interested in the latter.
> In my opinion, developers who are unwilling to abide by the Social
> Contract in their Debian work should resign. But they don't, and this
> is what has me afraid.
Of course, the other side of that ist that we've never worried about
DDs who aren't willing to support non-free, which is also part of the
social contract.
Anyway, I'm already getting namechecked for discussing this too much
[0], so, well, whatever. See y'all again when squeeze gets held up.
Peace out,
aj
Stephen Gran
> On Mon, Dec 29, 2008 at 12:48:24AM +0000, Simon Huggins wrote:
> > I thought FD was also a vote for "release Lenny" given it didn't change
> > the status quo and before the GR the release team were quite happy to
> > release...
>
> If you believe that the release team had the authority to release lenny
> with an arbitrary amount of non-free software, then yes, that would
> seem accurate.
If you don't want them to release glibc as is, why didn't you upload a
more suitable version?
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sg...@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
Florian Weimer
> 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).
Florian Weimer
> 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).
Mike Hommey
>
> > 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
Theodore Tso
>
> 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 46 60 72 73 89 117
Option 2 281 160 160 171 177 224
Option 3 255 61 125 137 151 204
Option 4 253 121 146 160 166 194
Option 5 234 105 128 135 136 191
Option 6 220 118 134 125 134 180
Option 7 226 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
Theodore Tso
> 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 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. Hopefully people will agree that having this discussion
over and over again is not productive, so we don't have to replay this
divisive set of arguments every two years....
- Ted
Mike Hommey
> 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
Wouter Verhelst
> 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
Clint Adams
> For someone that is in Debian for so long its pretty bad how one can
> misjudge it...
That's great.
> If you don't want them to release glibc as is, why didn't you upload a
> more suitable version?
I'm happy to delay the release indefinitely until all the sourceless
firmware is removed from the glibc source.
Daniel Moerner
> 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 <dmoe...@gmail.com>
Gerfried Fuchs
> * 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?
Mark Brown
> 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-dev...@lists.debian.org
Thomas Bushnell BSG
> Whatever his motives, I think Ted's demonstrably done more to further the
> cause of free software than most developers, both by making Linux more
> and more usable for over 15 years now, and for helping other developers
> work together better, such as by organising the kernel summit.
>
> I'm all for having a 100% free system, and then some, but if it comes
> down to a choice between supporting absolute freeness without exception,
> and working with folks like Ted, I'm more interested in the latter.
I'm not against working with Ted. I completely second your remarks
above. I simply don't think that people should have a vote in Debian if
they are not committed to following Debian's foundation documents in
their Debian work. I do not know if Ted is such a person or not, but I
do know that he doesn't share the goal expressed in the Social Contract;
he's said as much. If he's willing to put that aside in his Debian
work, then that's sufficient for me, and AFAICT, that's exactly what he
does.
My concern is that not everyone is like Ted. They may share his views
about the Social Contract, but rather than put them aside and abide by
it in their Debian work, they just ignore the bits they don't like.
Thomas
Florian Weimer
>> 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.)
Mike Hommey
Forget my message, I was reading "Java blobs" and thought you were
talking about the openjdk plugin.
Mike
Anthony Towns
> 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:
> 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
Anthony Towns
> 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 committee resolution". I am not very clear about
> what Anthony is talking here.
Knowingly changing traditions within Debian is hard and requires hard
decisions; much as I'd like to be proven wrong, I don't think it's
particularly likely there'll actually be any changes made as a result
of these discussions.
Cheers,
aj
Bastian Blank
> 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