Re: First call for votes for the Lenny release GR
Matthew Johnson <mjj29@debian.org> writes:
> On Fri Dec 19 12:04, Russ Allbery wrote:
>> The only point of non-binding resolutions of the sense of the project
>> is to try to persuade people who might otherwise not think that's what
>> the project wants. They don't, in and of themselves, *do* anything.
> But... _how_ can it be the case that having the NVidia drivers in main
> (sorry to keep on with this example, but I want something where it's
> clear whether it meets the DFSG or not) is what the project wants when
> it's clearly going against our foundation documents. There's an
> inherent contradition. The SC says "we won't ship non-free stuff" and
> the GR says "actually we will ship non-free stuff (except we can't
> really because the SC says we can't)". It makes no sense.
There's nothing in the consititution that prohibits passing nonsensical
GRs or GRs that contradict foundation documents, as long as they don't
actually alter the foundation documents.
> Nvidia drivers are just a placeholder here. Insert firmware or anything
> else which might have support. I wanted an example that was clear I'm
> talking about definitely non-free stuff, not arguing whether binary
> vectors in header files are defacto source form.
Unfortunately, by simplifying, you're removing the factor that makes this
vote so problematic, namely the disagreement over whether what the GR says
is contradictory or not. One of the many sides in the current debate is
the position that putting source-less firmware into main does *not*
contradict the DFSG.
>> However, you can also override *individual decisions*, and that
>> requires only a simple majority. So it would be possible, under the
>> constitution, to get NVidia drivers into main with a set of 1:1
>> delegate overrides: you override the ftp-master's decision that it's
>> non-free, and then you override the release team's decision that it's
>> non-free, and so forth. Those overrides aren't binding on any future
>> developer decisions, only on those specific ones.
> See, I see no way to justify this position.
I'm justifying it by reading the text of the constitution, rather than by
trying to apply some sort of common-sense guidelines. :)
> 1:1 delegate/developer overrides are for two choices where either would
> meet the foundation documents.
The constitution doesn't say this. This would be a perfectly reasonable
governance process, but it's not the governance process we have right now.
The only limit written into the consititution on what a delegate override
can be used to decide is that it has to be a decision authorized by the
powers of the delegate, and determining the meaning and application of
foundation documents, since it's not called out anywhere in the
constitution, falls to the normal decision-making process and hence is a
decision authorized by the powers of delegates.
> Voting to allow us to ship non-free stuff is completely different. If we
> had those votes you suggest then I would immediately be filing a serious
> bug against the package because it is in violation of Debian policy.
And with a delegate override, the project with a 1:1 GR can force adding a
lenny-ignore tag to that bug.
You'd need a ton of delegate override GRs to do this sort of thing in
practice, which is yet another reason why it's not a real threat, since
there are many separate delegates who have the power to stop it from
happening. But I don't see anything in the consititution that would
prohibit the project, in theory, from passing all those overrides.
> NVidia drivers are just a placeholder to illustrate the point. You
> definitely _can't_ claim that they meet the DFSG (but you could change
> it to allow them anyway). However, you do raise something here which
> people may be confusing. A vote that said "we will assume that firmware
> is in source form" is very different to one which says "we don't care
> whether or not it is source form". The former says "we keep the DFSG as
> it is, but we are asserting that they comply unless we can prove
> otherwise" and the latter says "even if we can prove otherwise we will
> change the DFSG so that it is allowed" The former is 1:1 and the latter
> is 3:1.
I agree with this, since the latter says that you're going to change the
DFSG. But the firmware case doesn't necessarily say that. One of the
positions held about firmware is that it's not a program provided by
Debian in the sense used in the SC and DFSG. Holding that position
doesn't require changing the DFSG.
Furthermore, by my reading of the constitution, even if a delegate
override or a position statement clearly and obviously contradicted the
DFSG, as long as it doesn't actually change or set aside the DFSG, it's
still just a 1:1 majority. Success of the GR would overturn that
decision, even in a direction that contradicts the DFSG, because in
practice there's no higher authority in Debian to declare that the
decision contradicts the DFSG and a majority of developers just said, in
effect, that it doesn't.
This is the root of the argument, really, and is what I'm trying to get
across. Foundation documents do not have some sort of Platonic True
Meaning that exists outside of the governance process. The words mean
what people with the authority to make decisions decide they mean, and
those decisions have no special protection or role in the constitution.
Therefore, in a very real sense the DFSG and SC mean whatever a simple
majority of developers decide that they mean in each specific case where a
GR is applied.
If you want to have a formal framework for deciding the meaning of a
foundation document in a way that puts it above the normal GR process, you
have to actually create such a structure (such as the judicial branch in
many national legal systems). This is the reason why bodies such as the
US Supreme Court exist outside of the normal voting framework. Debian
does not have such a structure at present.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: