Re: Purpose of the Constitution and the Foundation Documents
Ean Schuessler <email@example.com> writes:
> What you are avoiding is that the FTP masters or the Technical Committee
> *is* option D in your scheme. They are the final arbitrators of DFSG
I see nothing in the constitution that empowers the TC to rule on
licensing issues except when they're explicitly delegated to the TC.
Licensing issues are clearly (at least in my view) not technical; they're
legal. Likewise, interpreting the DFSG is clearly not a technical action
I therefore also don't believe the TC could overrule the ftp-masters on
licensing calls. It would need to be done via GR.
I do agree that to some extent the ftp-masters currently are the final
arbitrators of DFSG compliance, but they're not constitutionally empowered
to be that. They're doing that in the course of their work on Debian.
This is relevant because it means that they have no particular power to
overrule the release team and hence aren't entirely final arbitrators in
the sense of settling a question for the entire project. They can do that
negatively (by refusing to accept something into the archive) but not
positively (saying that it's definitely free).
> As we've seen, that scheme has led to friction during the last few
> release cycles.
I don't believe the scheme is the cause of the friction.
I think the cause of the friction is aptly illustrated by the outcome of
every vote that we've had on this topic: we have an approximate majority
in favor of kicking the can down the road for each release, but we do not
have a project consensus on the correct action and we do not have a 3:1
majority in either direction.
In other words, the project is split. So we have friction. I doubt there
are procedural changes that will remove the friction as long as the
project remains split. The most that we can do is control the effects of
the tension and not have it explode in ways that make Debian less fun for
everyone, such as the huge fight over the last firmware vote.
> At the same time, you yourself note your disatisfaction with the
> firmware decision. I am suggesting that we must lower the pain
> threshhold on marking software non-free so that we can correctly
> classify bytes we are distributing without it becoming an all out war.
Which requires someone go actually do work. I'm all in favor of people
doing work. :)
I personally don't have time to work on this given all the other stuff I'm
currently doing for Debian, and I expect that's the case for a lot of
people in this discussion. Saying "we should improve our technical
capabilities here" is, while almost certainly true, not horribly helpful
unless you're also able to go do that.
In this case, this seems to be happening over time. Hopefully eventually
the people who have time to do work will make these discussions thankfully
However, I will note...
> If there is *any* serious doubt about the compliance of a piece of
> software then we must be able to mark it non-free without it being the
> end of the world.
...that this really seems contrary to the social contract to me. non-free
is intended to *not be Debian*, and this is realistically going to have
consequences. It *should* have consequences, or otherwise why are we
saying non-free isn't part of Debian?
In other words, if non-free is just another archive section, why do we
have this whole distinction? And while we're maintaining this
distinction, I think it's clear that moving something into non-free is
never going to be an action people are willing to take lightly. Since,
after all, that means, in the words of the social contract, the software
is being removed from Debian.
> Please, acknowledge that what you are suggesting by "option B" would be
> more clearly labeled as "FTP masters and/or Technical Committee are the
> final authority for DFSG compliance" with a corrollary that "it is
> acceptable to leave non-free binaries in main on an ongoing basis if
> authorized by TC/FTP".
As above, I don't believe that's what option B means.
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>