[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Changing how we handle non-free firmware



On 8/30/22 12:00, Kurt Roeckx wrote:
On Tue, Aug 30, 2022 at 03:27:46AM -0500, Richard Laager wrote:
Regardless of that, and probably more importantly, I object to the idea that
a GR option winning could result in the whole GR being voided. Our voting
system is explicitly designed to take into account supermajority
requirements. A GR option failing a supermajority requirement should fail by
itself, not take down the whole GR with it.

I'm not sure it's a good idea to reinterpret the results with that
option removed.

I agree with that statement 100%.

If we find ourselves in that position, I agree we should not try to reinterpret a GR.

But my point was to avoid getting into that situation in the first place, by either declaring options invalid or requiring 3:1 (whichever is appropriate). Then the result of the GR, whatever it is, is valid.

I think if an option wins and is later determine not
to be valid, the GR should just be done again.

Right.

I'm not sure how fast I will be to make such determinations.

Fair enough. But there does come a point where additional time will not add additional clarity and a decision has to be made.

I like to discussion about anything related to this, so that I can at
least get an idea what the consensus is.

DSC 1 and DSC 5 have some implications about "the Debian system" vis-a-vis non-free, but the plan here is to keep the firmware in a separate non-free-firmware analogous to non-free. That seems fine to me.

DSC 1 says we will never "require the use of a non-free component". To me, this is the major relevant issue.

Proposals B and C offer users the explicit choice of media. That feels clearly compatible with the DSC, as users are not required to use non-free bits.

Proposal A will use non-free-firmware by default, but "where possible...will include ways for users to disable this". Without the "where possible", I think this opt-out is compatible with the DSC. However, if it is not possible to disable the non-free-firmware, then it feels like the system is, in fact, requiring it. Thus this option, as worded, feels potentially incompatible with the DSC.

Note that Proposal B, while sharing the same wording for this portion, does NOT have the same DSC conflict. This is because Proposal B retains the free images as an option.

Possible remedies (ordered from best to worst, in my view):

a. The proposer amends it to explicitly remove the words "where
   possible" (and no sponsors object).
b. We take the position that, if Proposal A wins, implementors are bound
   by it and the DSC. The only ways to fulfill both are:
   b1) provide options to disable the non-free-firmware; in other words,
      "where possible" is rendered inoperative, or
   b2) retain free images (as in Proposal B).
c. The Secretary declares the option is amending the DSC by implication
   and requires 3:1.
d. The Secretary declares the option invalid and strikes it from the GR.
   This feels heavy handed given that other remedies are available,
   most notably (b), which is available even after (and if) A wins.
e. If Proposal A wins, the entire GR is declared invalid. This is the
   thing I'm objecting to.

Under (b2), Proposal A becomes equal to Proposal B and Proposal A should just be withdrawn. The fact that both A & B already exists suggests Proposal B and thus (b2) is objectionable to Proposal A's Proposer & Sponsors.

If the consensus among Proposal A's Proposer and Sponsors is (b1), then they should just make it explicit with (a).

If they object to (a), then I'd be very curious for their rationale; if they are trying to amend the DSC by implication, then (c) seems like the right answer.

--
Richard

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


Reply to: