On Fri Dec 19 12:04, Russ Allbery wrote: > Here's the way I see it, which I think is similar to how Steve is seeing > it: > > 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. 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. > 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. 1:1 delegate/developer overrides are for two choices where either would meet the foundation documents. Including wordpress in etch, for example (which went to the TC rather than GR), declassifying debian-private, overriding Joerg's membership proposal. In all these cases either course of action meets the foundation documents. 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. > I agree wholeheartedly with Raphael: I don't see this as any real threat. > Even people who think we should ship NVidia drivers in main aren't going > to vote in sufficient numbers for a GR that says they meet the DFSG. (And > if they did, we have other problems that voting rules aren't going to fix, > no matter what rules we're trying to apply.) 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. It may be a subtle difference, but it's an important one, because it sets precedent for future issues where the difference is not so subtle. Matt -- Matthew Johnson
Attachment:
signature.asc
Description: Digital signature