Re: Splitting out Choice #1 from vote_004
On Mon, 25 Sep 2006, Frans Pop wrote:
> I strongly object to separating this proposal out and calling for a
> vote without any alternative proposals or amendments, for the
> foolowing reasons:
> 1) The proposal on its own adds nothing to the status quo: the SC is
> currently widely understood to prohibit sourceless firmware in main,
> which is the main reason why Steve's original proposal was
> submitted. There is absolutely no need to reaffirm something that is
> basically uncontested.
That Steve's GR was originally proposed indicated to me that this was
contested; resolving it seems appropriate.
> 2) Without any alternatives, a vote on this proposal will be based
> purely on theory and ideals, without any discussion on the practical
> implications, for example on the usability of the Debian
> installation system for users with hardware that depends on
> sourceless firmware.
If it is indeed a reaffirmation of the status quo as you posit in #1,
the practical implications are no different from what we are facing
today. The GRs which propose to allow an exception to the DFSG for
sourceless works are the best place to address the practical
implications, as they will override whatever the DFSG (and this
clarifying proposal) say.
I agree that there are practical implications, and that something
should be done about them, but I think that they're out of scope for a
resolution whose purpose is to clarify how DFSG #2 should be
> 3) If the proposal is voted on on it's own, it is my belief that the
> vote will be heavily biassed towards accepting it. The reason for
> this is that for developers who have not followed the discussion on
> d-vote, this proposal will seem fairly innocent and the ideals it
> promotes are noble.
I hope that voters who have also followed this discussion will accept
it as well, even if they intend to allow the RMs power override it for
specific classes of works.
> If this proposal is separated out, IMO this should be announced
> broadly and a new period to allow for amendmends and counter
> proposals should be opened, followed by the normal discussion
The door for amendments to the proposal I have proposed is open, and
remains open, until the someone calls for a vote.
1: That's one of the reasons I would like to proceed to a vote, so
that this proposal is resolved and can be overridden by the exceptions
for firmware in etch if the project desires.
Dropping non-free would set us back at least, what, 300 packages? It'd
take MONTHS to make up the difference, and meanwhile Debian users will
be fleeing to SLACKWARE.
And what about SHAREHOLDER VALUE?
-- Matt Zimmerman in <gYuD3D.A.ayC.nGB39@murphy>