Re: Possible draft non-free firmware option with SC change
In reading your messages, I think I have the same position as you, but I'm confused by our different tentative rankings. On 9/12/22 15:13, Russ Allbery wrote: For full disclosure, my vote is likely E>B>C>A>NOTA>D.) I agree insofar as: E > B > C > NOTA > D I put A in a different spot: A > B > C. You have B > C > A. E is A plus the SC modification. With E as your first choice, why wouldn't you put A > B? -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Possible draft non-free firmware option with SC change
On 9/11/22 19:41, Steve McIntyre wrote: As far as many vendors are concerned, the firmware blobs are basically part of the hardware. They're just provided in a cheaper, more flexible way - loading things at runtime. To me, this is an important part of the situation we find ourselves in. It seems that there is a trend where "firmware" is moving away from "ROM" (generally writable flash) into RAM. That is, in years past, the firmware came preloaded on the device, but now the driver pushes it at boot. This has certainly drawn our attention to the non-free bits. But shipping the non-free blobs and loading them at run-time results in exactly the same free and non-free bits being executed as the old model. While I would very much prefer free firmware (and I applaud those making free replacements), my view is that moving non-free bits from "ROM" to installer media (and installed system) does not make the problem worse. In contrast, NOT putting the blobs on the installer media has the obvious downside of hardware not working. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Possible draft non-free firmware option with SC change
On 9/8/22 00:14, Russ Allbery wrote: With Steve's change and a few other tweaks to try to make this a bit more concise: 5. Works that do not meet our free software standards We acknowledge that some of our users require the use of works that do not conform to the Debian Free Software Guidelines. We have created areas in our archive for these works. The packages in these areas are not part of the Debian system, although they have been configured for use with Debian. We encourage distributors of Debian to read the licenses of the packages in these areas and determine if they can distribute the packages on their media. Thus, although non-free works are not a part of Debian, we support their use and provide infrastructure for non-free packages (such as our bug tracking system and mailing lists). The Debian official media may include firmware that is otherwise not part of the Debian system to enable use of Debian with hardware tha requires such firmware. nit: typo "tha" should be "that" I do think this sounds more up-to-date, and getting rid of "CDs" does feel like an overdue edit. Yes. This drops the "we support their use" statement which I think is a bit confusing; I believe the intention is that we, Debian Developers, support the non-free packages in the sense that we upload them and answer bug reports, but it could also be read as "we endorse their use," which we do not and don't really want to be saying. Yes. Either sounds good to me. I slightly prefer the latter, for the reason you said. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Possible draft non-free firmware option with SC change
I like the existence of such an option. Seconded. The Project Leader has extended the discussion period (at least the maximum, maybe it's ambiguous on an extension of the minimum, but that is likely moot) by 7 days. By my reading of the constitution, this only extends the possible maximum. To actually get that time, I believe we need a new option or an amendment of an existing one. And that needs to happen today. On 9/7/22 12:48, Russ Allbery wrote: Between one thing and another I've not been tracking the timeline of this vote and I'm worried we may be out of time for new ballot options and possibly extensions. (As promised in the previous vote for changing the timing of GRs, I've been watching the timing closely and the last couple have felt rushed. When there's a quiet period, I'm considering proposing a small constitutional amendment to relax the timelines a bit based on that experience. But we can discuss that separately.) If there is time left, though, I'm considering proposing the following option based on my earlier message, just so that there's something on the ballot that explicitly modifies the Social Contract to allow for non-free firmware, in case people want that for clarity. I should stress that I'm not involved in this part of Debian directly and am not a great choice for a proponent, so I'd be happy if someone else took that over, but it does feel to me like it would be good to have this explicitly on the ballot. Possible wording, which includes the existing option A verbatim: -- This ballot option supersedes the Debian Social Contract (a foundation document) under point 4.1.5 of the constitution and thus requires a 3:1 majority. The Debian Social Contract is replaced with a new version that is identical to the current version in all respects except that it adds the following sentence to the end of point 5: The Debian official media may include firmware that is otherwise not part of the Debian system to enable use of Debian with hardware that requires such firmware. The Debian Project also makes the following statement on an issue of the day: We will include non-free firmware packages from the "non-free-firmware" section of the Debian archive on our official media (installer images and live images). The included firmware binaries will normally be enabled by default where the system determines that they are required, but where possible we will include ways for users to disable this at boot (boot menu option, kernel command line etc.). When the installer/live system is running we will provide information to the user about what firmware has been loaded (both free and non-free), and we will also store that information on the target system such that users will be able to find it later. Where non-free firmware is found to be necessary, the target system will also be configured to use the non-free-firmware component by default in the apt sources.list file. Our users should receive security updates and important fixes to firmware binaries just like any other installed software. We will publish these images as official Debian media, replacing the current media sets that do not include non-free firmware packages. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: supermajority requirements and their inheritance (was: Re: Changing how we handle non-free firmware)
On 9/6/22 01:09, Ansgar wrote: You can argue that the developers making the installer and live images, and those maintaining the website can make those decisions. You can even say that they have made decisions. So those options could be seen as overriding a Developer, using the power of the Technical Committee. Assuming we actually went that way, 6.1.4 requires a 3:1 majority, but 4.1.4 only a 2:1 majority. I think we take the highest majority requirement in that case, so 3:1. I also disagree with the idea that a GR would require 3:1 to exercise a TC power. I'll try to illustrate that two different ways... Imagine that 6.1.4 said the TC was required to be unanimous to overrule a Developer. It would not make sense to say that the Developers collectively had to be unanimous to exercise that power. 4.1.4 is the one relevant for a GR. I think it is bad to transfer supermajority requirements among one group of voters (tech-ctte) to a very different group of voters (all DD). Agreed. Though I agree the constitution is not clear on this. I personally think it's clear. Here's how I would look at it: Overriding a Developer is a power of the TC. (6.1.4) The TC exercises that power by committee vote 3:1. (6.1.4) The Developers exercise that power by GR vote 2:1. (4.1.4) It might be better to just get rid of both supermajority requirements: if 50% of all DDs agree on some implementation detail, it's probably fine to do it that way. I happen to agree (at least in the case of removing the 2:1 from 4.1.4, less sure about the other), but that'd be a separate GR to change. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Changing how we handle non-free firmware
On 9/4/22 14:38, Kurt Roeckx wrote: I'm not sure that a GR should say what the interpretation of a document should be. I really prefer that the document is changed instead so that it's more clear on what it says. I agree with "prefer", but I can't bring myself to say "require [amendment]" or "prohibit interpretative GRs". I think it's reasonable, at least in some cases, for a GR to make an interpretation. While amending the Foundation Document to make it more clear is ideal in many situations, I'm not willing to say that _all_ situations require that. Let's say that we have an non-hypothetical question, "Is X allowed by Foundation Document Y?". By non-hypothetical, I mean this is a live issue for some people; the question needs an answer one way or another _and_ there is disagreement on the answer. I think we can safely assume these sort of interpretive questions do come up in real life. For example, ftpmaster interpreting the DFSG seems like a common case. (Of course, most of the time those would not lead to GRs.) Thus, a possible precursor to an interpretive GR is that some person/group (e.g. ftpmaster, Project Leader, TC, Secretary[1]) makes the interpretive decision. If someone can make the decision, then they can be overruled[2][3] by the Developers through a GR. I don't think a blanket prohibition on Foundation Document-interpreting GRs makes sense in that context. It doesn't seem correct that Developers somehow lose their power to overrule if the issue involves interpretation of a Foundation Document. One might argue that the Developers retain that power through an amending GR. But I argue that those are separate powers (from the explicit text of the constitution), with separate majority requirements, and for good reason. Amending a Foundation Document requires 3:1. It is thus possible for an amending GR to fail, even if it has ballot options to resolve the question each way. That is, if the issue is split and neither side is >= 3:1, "None of the Above" wins. This leaves the question undecided. The ambiguity still exists and the live issue still needs an answer. However, if we have an interpreting GR, then it can produce an answer (assuming it's a yes/no question and people on each side rank their answer above NOTA). The Developers' powers to overrule also come with the power to make the decision in the first instance. So while overruling is one scenario, it is not the only scenario. [1] I understand that your (the Secretary's) current position is that you do not have the power to interpret Foundation Documents. I contend that you implicitly do, at least insofar as such an interpretation is required to fulfill one of your explicit duties. If you do not, then it seems the Project Leader would, through a combination of 5.1.3 (requires urgent action) and/or 5.1.4 (noone else has responsibility). But, at least in the U.S., there is a general rule of constitution interpretation: if there is a (I'd say _reasonable_) way to interpret something that does not make it unconstitutional, then those interpretations should be preferred over interpretations that make it unconstitutional. https://www.britannica.com/topic/constitutional-doubt https://www.law.cornell.edu/wex/constitutional_avoidance https://constitution.congress.gov/browse/essay/artIII-S2-C1-9-7/ALDE_00013159/ This is why, while I would prefer that "where possible" be explicitly amended out by its Proposer, if that does not happen, I think it is better to interpret to implicitly strike that phrase rather than declaring the whole ballot option void. Though, to be clear, if there is _no_ reasonable interpretation that makes a ballot option constitutional, then I still contend that the Secretary has the power _and duty_ to declare it unconstitutionally void. [2] Overruling TC requires 2:1. [3] Things get more complicated if the Secretary is doing the interpreting. We can game out how that plays out if the Developers collectively disagree with the Secretary, but fundamentally, if the Developers collectively disagree enough, they have the power to enforce their will (and technically only need 1:1, though politically it is more complicated). -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Changing how we handle non-free firmware
On 9/4/22 14:38, Kurt Roeckx wrote: Please note that the current discussion period ends the 7th, the maximum discussion period is the 8th, which probably means I'll start the vote the 9th or the 10th, and I think we're not actually going to be ready to have all options like we want them by then. Under §A.1.1, the Project Leader can increase the maximum discussion period by 1 week. That would extend the 8th to the 15th. It sounds like that might be a good idea here. If an option is amended or a new option added, that would extend the 7th to one week past the amendment (or the 15th, whichever was earlier). -- Richard OpenPGP_signature Description: OpenPGP digital signature
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 OpenPGP_signature Description: OpenPGP digital signature
Re: Changing how we handle non-free firmware
On 8/29/22 16:02, Kurt Roeckx wrote: It's my current interpretation that all voting options, even if they might conflict with the DSC, will be on the ballot, and might not require a 3:1 majority. That is, I don't think the Secretary can decide not to include an option that might conflict, or put a 3:1 majority requirement on it because they think it conflicts. However, if an option that might conflict wins, the Secretary might have to decide if it conflicts or not, and if it conflicts void the GR. I'm having trouble reconciling the two positions of "[not] put a 3:1 majority requirement on it because...it conflicts" and "it conflicts void the GR". The only way I can see to reconcile your positions is if a GR is not allowed to supersede a Foundation Document by implication, but must do so explicitly. Is that your rationale? I think it's reasonable to take the position that GRs can only amend the constitution explicitly. The constitution is written in legalistic language and there is obvious value in having the rules written in one place. For the Foundation Documents, it seems less cut-and-dried. This is especially true if, for example, a GR could purport to override a Foundation Document temporarily (still by 3:1 majority). Whether permanently superseding part of the DSC by implication is constitutionally permissible is different from whether it is a good idea. The former is a question for the Secretary. The latter is a question for the Developers through the GR. 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. Since there's a good chance you have to make the determination either way, I think it's far better to make that determination before the vote than after. Making the determination now gives people the option to amend their GR options before we go through a vote. That saves time and energy. It also just doesn't look good for the Secretary to void the GR based on which option won. That makes it look like you're doing so because you disagree with the result. I'm not saying that is the case here. I'm saying the optics are worse with deciding after, so I think you should decide before. In my view, if the Secretary determines that a GR option is constitutionally defective (for whatever reason), it should not be on the ballot. I think you should (in this and all GRs) rule each GR option one of: - requires 1:1 - requires 2:1 - requires 3:1 - invalid https://www.debian.org/vote/2008/vote_003 is precedent for: - a GR option could supersede a Foundation Document implicitly, - a GR option could supersede a Foundation Document temporarily (not relevant here, but I made the point above), and - that such options require 3:1. https://www.debian.org/vote/2006/vote_007 is precedent for: - a GR option could supersede a Foundation Document permanently and explicitly but without amending its text, and - that such an option requires 3:1. https://www.debian.org/vote/2006/vote_001 is precedent for: - a GR option could supersede a Foundation Document permanently and implicitly (though curiously the vote statement says "DFSG article 3 would need to be changed, or at least clarified.") - that interpreting a Foundation Document needs only 1:1. https://www.debian.org/vote/2004/vote_004 is precedent for: - a GR option could supersede a Foundation Document temporarily (though this took a very different approach than 2008-003 did later). -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Question to all candidates: Ongoing/future legal projects
On 3/27/22 11:14, Jonathan Carter wrote: The only cases of waste I know of happens when people ask for sponsorship for DebConf and then hotel space is made for them (and possibly other expenses) and then they just don't show up without any heads-up. Even those are rare, but it's the only instances of really wasting any money that I can think of. Reimbursing people after the fact would avoid that. (If they didn't show up, they wouldn't get a reimbursement.) But I suppose in some/many/all cases where Debian is paying, it is because the person can't afford the cost. So they might not be able to float it even temporarily. If so, then I guess that might just be a risk we have to accept. Thankfully you're saying these things are rare. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Question to all candidates: Ongoing/future legal projects
On 3/24/22 19:18, Felix Lechner wrote: For example, I requested $217 for a one-time SSD & RAM upgrade to help operate lintian.d.o in November of 2021. My request was not granted. I didn't even receive a response from Jonathan (other than a request for more information, with which I complied) even though I followed up on my request. I would be interested to hear why that was not approved. On its face, that seems reasonable. As for your question about "huge wasteful spending," yes, I do worry about Debian's expenditures in light of Jonathan's comment that he is happy to "give a lawyer a lot of money." [3] I think you're taking that completely out of context. The comment was "I [w]as hoping we could just [pay] a lawyer...and they could deal with it." This follows "it turned out that the legal work around it was much hairier and involved than I had previously anticipated". So he was hoping this could be delegated to a lawyer, but it turned out that it still took a bunch of work from our side (him). You're focusing on the "..." bit of "a lot of money", which is just a reference to how lawyers are expensive. [3] https://lists.debian.org/debian-vote/2022/03/msg00137.html -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Question to all candidates: registering Debian as an organization
On 3/24/22 15:45, Sam Hartman wrote: "Richard" == Richard Laager writes: Richard> On 3/20/22 07:10, Felix Lechner wrote: >> If we accidentally formed a General Partnership, as has been >> suggested elsewhere Richard> Yes, that would be really dumb for a number of reasons. The problem is that at least in the US, you can accidentally default to a general partnership. Effectively, if you are doing things together, and it cannot be shown what you have instead, and mumble mumble I'm not a lawyer, a court may conclude you are a general partnership. So, it's more what steps have you taken to avoid being considered a general partnership? Unfortunately I cannot point to a lot of these steps for Debian. If that's true, and I cannot say intelligently either way as IANAL, then that feels like a very strong reason that we _need_ to incorporate. I have done a tax-exempt filing with the IRS. I'd be happy to discuss that with someone if that is helpful to anyone in the future. (At the moment, I'm not sure whether I'd feel comfortable volunteering to do such a filing for Debian.) -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Question to all candidates: registering Debian as an organization
On 3/20/22 07:10, Felix Lechner wrote: If we accidentally formed a General Partnership, as has been suggested elsewhere Yes, that would be really dumb for a number of reasons. I have friends who are or were high-ranking officials at the UN. With the project's permission, I might explore finding a home for Debian there. Would the UN be an appropriate potential home for our noble and selfless efforts? IMO, very much no. Subject to actual legal advice, I think the obvious answer is a U.S. 501(c)(3), which is what SPI is. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Question to all candidates: Ongoing/future legal projects
On 3/20/22 11:58, Felix Lechner wrote: I would not be comfortable granting financial requests, other than on an emergency basis, without some type of community review. The disbursements that I've heard about seem to be relatively "small potatoes" things. Is there some huge wasteful spending occurring that I've missed? One anti-pattern I've seen with spending money (not Debian, but elsewhere) is that a group will spend e.g. $10x worth of time debating $x expense. Sometimes that is appropriate, if you're confronting a new class of spending that will be repeated and you need to develop a policy to apply. But often, it's just a waste because people want to bikeshed. I might ask you, Richard, to serve on my Disbursements Committee together with someone I perceive as an equally strong person but otherwise different from you in some way. A small Appointments Committee could help me figure out who would be a good counterweight. This approach certainly plenty of merit. The devil is in the details, though. If the group is roughly evenly split, then having appointees evenly split to counterbalance each other is appropriate. If the wider group is 80:20, 90:10, or 99:1 on an issue, then picking one from each side unfairly weights the minority position. Maybe that's okay or even desirable (to protect the minority) at 80:20 and a minority position that's reasonable. But it's certainly not good at 99:1 where the 1% position is insane. (I'm not thinking of any particular issue here.) For contentious topics, the debate over disbursements would automatically be compartmentalized to your tiny committee without burdening the entire project. ... The moderating effect grows with the size of your committee. This seems naive. If this principle were true, then political strife in society would disappear because we've tasked our elected representatives with dealing with these issues. We all know that isn't the case, even with bodies the size of a state/national legislature. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Question to all candidates: Ongoing/future legal projects
On 3/18/22 10:23, Felix Lechner wrote: I hope instead to devolve the concentration of power from my office into an open and transparent system of boards and commissions This is a complex topic, but in broad strokes, the concept of having more people involved seems reasonable to me. But I fear that the idea and the reality may be different. How do you plan to find all the people to sit on these committees? Have you found some already? that enjoy broad community support. That is, of course, a great goal. Do you have any specifics to offer about how to achieve that? How would you handle contentious topics? -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: GR Ballot Option: Allow, but do not require, secret voting
On 3/4/22 18:28, Harlan Lieberman-Berg wrote: In practice, the way that I would like to see this work is that a ballot option is proposed with no content other than turning the ballot to a secret option. Then people can, regardless of their position on the issue, second that ballot option to avoid splitting the vote. If that's your intended application, why not just make that the explicit process, rather than requiring it be part of a ballot option? I suppose one reason might be so you don't have to duplicate a lot of procedural elements, by piggybacking on the rules for ballot options. Also, your change duplicates the idea that leadership elections are secret. That is, you add it as one of the ORed conditions, while not removing it (as Sam's option does) in the later text. Here is an alternative idea on how to implement this: Add as 4.2.5 and renumber the existing 4.2.5, 4.2.6, and 4.2.7, "If, during the discussion period, at least 4K Developers call for a secret ballot, then the votes are kept secret, even after the voting is finished." If it is your intention that making the ballot secret extends the discussion time (as adding a ballot option would), then also: Amend A.1.4. to read, "The addition of a ballot option, the change via an amendment of a ballot option, or a successful call for a secret ballot changes the end of the discussion period..." -- Richard
Re: Amendment: Keep e-mail while allowing other options in addition [Re: GR: Hide Identities of Developers Casting a Particular Vote]
On 2/25/22 09:06, Sam Hartman wrote: 2) In the General resolution system, in addition to the constitutional amendment, include a statement of the day asking the secretary to obtain sufficient project consensus before changing how voting works. This feels almost like a tautology of sorts... you're telling the Secretary to make good decisions. If (hypothetically at some point in the future) we don't trust the Secretary, we should do something about that. If the Secretary makes a bad decision, we have mechanisms to deal with that (and are actively improving those mechanisms here). This particular statement of the day doesn't seem to really be binding, and even if it is, "sufficient" is subjective. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: FYI, Secret Ballots Proposal is Likely to Die for Lack of Support
Your secret ballots proposal had some other procedural housekeeping bits in it, like dealing with overrides for the secretary. How do you feel about the consensus on that? -- Richard
Re: Informal Discussion: Identities of Voters Casting a Particular Ballot are No Longer Public
On 2/14/22 09:53, Sam Hartman wrote: Steve certainly found feedback he got to be harassment. I did as well. I received some harassment (not a lot, but some) over this too. My recollection is this was coming from non-DDs. Given the levels of harassment that others were talking about at the time, I did put serious thought into to what extent I needed to loop my employer in on this. That was the first time I've ever had to consider such action for volunteer work, Debian, FOSS, or otherwise. On Mon, Feb 14, 2022 at 5:56 AM Philip Hands wrote: If we are assuming that some DDs might start attacking people based on the way they voted, then I'd suggest that it's more important to eject such toxic people from Debian than it is to try to mitigate their toxicity using measures that have negative side-effects. I agree that we should expel toxic DDs. Nobody wants to work with jerks. But secret ballots may be useful for other reasons, not least of which is that the harassment may come from outsiders, for which expulsion is not an available remedy. And even expulsion doesn't prevent a then former-DD from harassing people in the future, which we've seen happen; though of course this is not limited to voted positions. Secret ballots are certainly not a panacea that solves all harassment, but they may be a risk reduction measure. On 2/14/22 15:36 (later than the email below), Felix Lechner wrote: [the above bit from Philip Hands quoted] > I see no way to expel people reliably based on what they might do. I don't see anything in there suggesting we should expel people based on what they _might_ do. On 2/14/22 12:42, Felix Lechner wrote: [the above bit from Philip Hands quoted] ... All of them were condemned by later generations: the Salem witch hunt; McCartyism; the cultural revolution in China; collectivisation under Pol Pot in Cambodia; and perhaps most infamously the many attempts over time to expel or eradicate the Jews from various territories. Expelling people (from a volunteer software project) who are acting in toxic ways is not remotely the same as any of those things, and even if you're against doing that, comparing it to the Holocaust is frankly disgusting. This is a perfect example of behavior where the action is a problem regardless of the cause/intention. Either you are so lacking in experience, perspective, and/or judgement that you cannot see why this comment is inappropriate, or you know exactly what you are doing and are intentionally choosing to (act in bad faith to) wind people up. If it's the former, then while your intentions may be good, you really need to understand that this is not okay, even if you don't/can't understand why. Stop posting such things. Moving forward, if you wish to participate in these discussions, maybe try having a friend privately review your email before posting publicly. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Do we want to Handle Secret Ballots in the same GR as Voting Changes
Your proposal seems fine at first glance. I would prefer to see this handled as a separate GR. If they don't conflict textually, you could run them in parallel, but honestly I'd prefer to see them run in series. A few more weeks of delay doesn't seem to be a problem for this topic. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Opposing strict time limits
On 10/24/21 2:01 PM, Wouter Verhelst wrote: 6. The project leader may, at any point in the process, set the discussion period to any length between 1 and 3 weeks, except that they may not do so in a way that causes the discussion period to end within 48 hours of when this change is made, unless that would require them to set a discussion time beyond three weeks. What is the purpose/intent of the "unless" here? If the discussion period is coming right up on (< 48 hours) 3 weeks, can the DPL truncate it using this? 10. When a time extension has received the required number of seconds, the discussion time is extended to end 72 hours from when the extension was first proposed. This wording might need some tweaking for clarity/anti-abuse. Specifically, if I ask for and receive an "extension" when there was more than 72 hours left already, what happens? -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Opposing strict time limits
On 10/23/21 1:49 PM, Sam Hartman wrote: I agree that if a sufficient part of the project wants to continue the discussion, we should be able to do that. I just don't see how to accomplish that in a way that is better than what Russ proposes without being open to abuse. I think a great next step would be to see a proposal from Wouter. Maybe there is some way. But we need something concrete to really discuss. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Opposing strict time limits
In general, I understand the reasoning for having an option for longer
discussions. However, I see risks too.
On 10/22/21 12:42 PM, Wouter Verhelst wrote:
a vote to recall the project leader.
This is an interesting corner case. I don't think it needs a special
case under the current situation or Russ's proposal, as the time is not
unbounded. But we should be careful not to make the time unbounded
except by DPL action ("only provide it to the DPL") as that would
effectively insulate the DPL from recall.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Re: Draft proposal for resolution process changes
First off, let me say I have no objections to your positions on this. Also, I'm honestly not trying to argue in circles. I'm specifically trying to confine my replies to only newly presented issues. On 10/10/21 1:41 PM, Russ Allbery wrote: This wouldn't change anything if the TC vote result is further discussion, since in that case there's no decision to override and, as you point out, the GR would stay at a 2:1 majority required if the developers wanted to exercise the powers of the TC. (In practice, most likely the GR would be phrased as a statement on issues of the day, which is technically nonbinding and only requires a simple majority but which everyone is likely to honor.) Your comment about the "statement on issues of the day" made me think a bit... if it's the case that GRs will use "statement on issues of the day" to make decisions anyway (as e.g. on systemd), is that a reason to eliminate the 2:1 supermajority to _make_ TC decisions? A related question... if a GR makes a decision, what's the situation with the TC overriding that at some point? In other words, if the developers make a decision in a GR, obviously the TC shouldn't immediately override it, but are we "stuck" with that GR decision forever even if facts change? I think the real-world answer to this is that if the facts change, the TC could change the position and if nobody objects, it's fine. If they do, then you get another GR. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Draft proposal for resolution process changes
On 10/5/21 11:04 PM, Russ Allbery wrote: One minor clarification: I was thinking about removing the 2:1 *override* requirement, but I don't think we should remove the 2:1 *make* requirement. Part of the discussion about the TC was that they might deadlock on _which_ option to choose, which then needs to go to a GR. If this happens, the TC did not make a decision, so the developers are using their power to _make_ a decision, not _override_ one. With what you have proposed above, the 2:1 supermajority would still apply. That may or may not be desirable. But was that your intended result? There's some weirdness here with maintainer overrides. I'm not sure if it should be possible to override a maintainer with a simple majority GR. (By that, I mean I'm literally not sure; I can see arguments either way.) Overriding a maintainer by a GR seems like a pretty serious thing. If nothing else, it's probably pretty embarrassing. I'd imagine those proposing, sponsoring, and voting in favor of such a resolution understand that. If we get a majority of developers voting to override, that seems sufficient to me (in the context where the 2:1 TC make supermajority is already being removed; I'm not necessarily suggesting this change standalone). -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Draft proposal for resolution process changes
One concern I have about eliminating the 2:1 majority for a GR to
make/override a TC decision is that it might encourage things to move to
a GR unnecessarily.
A second is that it might encourage things to move to a GR too soon.
Having the TC hear something and hash out options in a smaller group
setting seems useful, even if the issue ultimately ends up at a GR.
A way to split the difference might be to lift the 2:1 supermajority
requirement under some conditions. For example: GR _options_ put forward
by the TC do not have the 2:1 supermajority. So the TC could initiate a
GR and say: these are the two or three options we think are reasonable,
we should choose one of them, but we deadlocked on which one. As long as
the Developers are choosing between those options, the majority decides
(because getting _a_ decision is the goal). But if the developers choose
to exercise their right to add alternatives and (attempt to) overrule
the TC, then those alternatives must gain a supermajority of Developers.
Here is a specific textual proposal:
4. Make or override any decision authorised by the powers of the
Technical Committee, provided they agree with a 2:1 majority. If
such a resolution has ballot options proposed by the Technical
Committee, those options do not need a 2:1 majority.
I was originally going to also limit this to _resolutions_ proposed by
the TC, but that seems unnecessary at best and undesirable at worst (as
someone could then try to tactically race the TC to change the status of
the TC ballot options).
I suppose there's a wrinkle regarding the default option ("None of the
above"). It is also not subject to a supermajority, so it's possible
that it could win over all options proposed by the TC. I guess that's
the Developers saying to go back to the drawing board, and if that's
what we prefer over any TC option, then I guess that's a useful result.
I'm hesitant to make a TC tie automatically turn into a GR. If the
options are really similar, varying in some detail, that should not
trigger a GR. That's a waste of the Developers time and energy.
The Debian voting system is supposed to be cloneproof. We consider it
desirable to be able to propose similar options varying in some detail.
If that can lead to a GR, that could act as a disincentive to proposing
slightly different options and/or tactical voting to avoid the
undesirable GR.
Or potentially one person on the TC could force a GR by tactical voting
when they wouldn't otherwise be able to do that by themselves.
I think I'd leave it as the chair has a casting vote.
If we _really_ want to deal with the corner case of the TC chair having
a casting vote when they are being overruled (which as I think about it
is probably not that big of deal in practice), maybe this:
The Chair has a casting vote. When the Technical Committee votes
whether to override a Developer who also happens to be a member of
the Committee, that member may not vote. If that Developer is the
Chair, the Project Leader has the casting vote instead. If the
Project Leader is being overruled or there is no Project Leader, the
Project Secretary has the casting vote instead.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Re: Draft proposal for resolution process changes
Thank you for the clarifications. On 9/28/21 11:04 AM, Russ Allbery wrote: 3. Another TC member calls a vote, possibly immediately after making some last minute change to the ballot (which is allowed). If I understand correctly, the updated GR process handles this differently, by extending the clock on changes and prohibiting such changes at "the last minute" (the end of the maximum discussion period). That could be another option here, which would have the benefit of consistency. But the TC is a different situation than a GR, and they don't need to be exactly the same process. I don't have strong feelings on this detail either way. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Draft proposal for resolution process changes
First off, thank you for working on this! On 9/27/21 8:51 PM, Russ Allbery wrote: 6. If voting is started prior to two weeks after the original proposal via a call for a vote by a member of the Technical Committee, but another member of the Technical Committee objects more than two weeks after the original proposal but before the vote completes, the vote is still canceled. All members of the Technical Committee are then given 24 hours to add new ballot options or modify or withdraw the ballot options they have proposed. During this period no one may call for a vote. Following that 24 hour period, a new voting period automatically starts and cannot be canceled. Is this complexity necessary? If the vote was not called early, the vote would have started anyway on time and been uncancellable. And the objector did not object in time. (If the objector had objected prior to the normal starting time, we aren't in this scenario.) Why does someone get extra time to object in this case? 2. Details regarding voting. When the Technical Committee votes whether to override a Developer who also happens to be a member of the Committee, that member may not vote (unless they are the Chair, in which case they may use only their casting vote). I know this is how it is now. But it's always seemed weird. If TC members cannot vote on overruling themselves, why does the chair get to (but only in the event of a tie)? Is this even meaningful? Presumably they would vote against overruling themselves, if there are such options. But it seems that if they don't vote, the measure would fail anyway? Or is this more about them choosing between multiple options (possibly all of which overrule themselves)? 1. Options which do not have an explicit supermajority requirement have a 1:1 majority requirement. The default option must not have any supermajority requirements. "must not" or "does not"? 2. The votes are counted according to the rules in A.6. The default option is "None of the above," unless specified otherwise. This "None of the above" seems duplicative of the one above. Do we need both? When the vote counting mechanism of the Standard Resolution Procedure is to be used, the text which refers to it must specify who has a casting vote, the quorum, the default option, and any supermajority requirement. Maybe the "The default option must not have any supermajority requirements." should be moved here? -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Amendment to RMS/FSF GR: Option 4, assert the need to learn and grow from recent events
On 3/31/21 1:20 AM, Jonathan Wiltshire wrote: On Tue, Mar 30, 2021 at 08:13:59PM -0500, Richard Laager wrote: On 3/30/21 5:28 PM, Jonathan Wiltshire wrote: We urge Richard Stallman and the remaining members of the board which reinstated him, to consider their positions. Can you elaborate on the intended meaning here? Is "position" their position to reinstate RMS, or their position as a member of the board? Is this intentionally "consider" as opposed to "reconsider"? If so, is that intended to be a weaker form of reconsider? No, and no. "To consider one's position" in business and politics is a (probably rather English) euphemism; being invited to consider your position is a clear indication that you ought to be resigning over some matter. Thanks for clarifying. I'm an en-US speaker and I was not familiar with that (possibly en-GB) euphemism. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Amendment to RMS/FSF GR: Option 4, assert the need to learn and grow from recent events
On 3/30/21 5:28 PM, Jonathan Wiltshire wrote: CHOICE TEXT FOLLOWS: This is a position statement of the Debian Developers in accordance with our constitution, section 4.1.5. The Developers firmly believe that leaders in any prominent organisation are, and should be, held to the highest standards of accountability. We are disappointed that issues of transparency and accountability in the governance of the Free Software Foundation have led to unresolved and serious complaints of impropriety by its founder Richard Stallman over a number of years whilst in the position of president and as a member of the board. In particular, we are deeply concerned that the board saw fit to reinstate him without properly considering the effect of its actions on those complainants. The Developers acknowledge that people make mistakes but believe that where those people are in leadership positions, they must be held accountable for their mistakes. We believe that the most important part of making mistakes is learning from them and changing behaviour. We are most concerned that Richard and the board have not sufficiently acknowledged or learned from issues which have affected a large number of people and that Richard remains a significant influence on both the FSF board and the GNU project. We call upon the Free Software Foundation to further steps it has taken in March 2021 to overhaul governance of the organisation, and to work tirelessly to ensure its aim is fulfilled. We believe that only through properly accountable governance can members of an organisation ensure their voice is heard. The Free Software Foundation must do everything in its power to protect its staff and members, and the wider community, including a robust and transparent process for dealing with complaints. We urge Richard Stallman and the remaining members of the board which reinstated him, to consider their positions. The Developers are proud that contributors to free software come from all walks of life and that our diverse experience and opinions are a strength of software freedom. But we must never cease in our efforts to ensure that all contributors are treated with respect, and that they feel safe and secure in our communities - including when we meet in person. END CHOICE TEXT Seconded. Signed this time. Ugh! -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Amendment to RMS/FSF GR: Option 4, assert the need to learn and grow from recent events
On 3/30/21 5:28 PM, Jonathan Wiltshire wrote: CHOICE TEXT FOLLOWS: This is a position statement of the Debian Developers in accordance with our constitution, section 4.1.5. The Developers firmly believe that leaders in any prominent organisation are, and should be, held to the highest standards of accountability. We are disappointed that issues of transparency and accountability in the governance of the Free Software Foundation have led to unresolved and serious complaints of impropriety by its founder Richard Stallman over a number of years whilst in the position of president and as a member of the board. In particular, we are deeply concerned that the board saw fit to reinstate him without properly considering the effect of its actions on those complainants. The Developers acknowledge that people make mistakes but believe that where those people are in leadership positions, they must be held accountable for their mistakes. We believe that the most important part of making mistakes is learning from them and changing behaviour. We are most concerned that Richard and the board have not sufficiently acknowledged or learned from issues which have affected a large number of people and that Richard remains a significant influence on both the FSF board and the GNU project. We call upon the Free Software Foundation to further steps it has taken in March 2021 to overhaul governance of the organisation, and to work tirelessly to ensure its aim is fulfilled. We believe that only through properly accountable governance can members of an organisation ensure their voice is heard. The Free Software Foundation must do everything in its power to protect its staff and members, and the wider community, including a robust and transparent process for dealing with complaints. We urge Richard Stallman and the remaining members of the board which reinstated him, to consider their positions. The Developers are proud that contributors to free software come from all walks of life and that our diverse experience and opinions are a strength of software freedom. But we must never cease in our efforts to ensure that all contributors are treated with respect, and that they feel safe and secure in our communities - including when we meet in person. END CHOICE TEXT Seconded. -- Richard
Re: Amendment to RMS/FSF GR: Option 4, assert the need to learn and grow from recent events
On 3/30/21 5:28 PM, Jonathan Wiltshire wrote:
We urge Richard Stallman and the remaining members of the board which
reinstated him, to consider their positions.
Can you elaborate on the intended meaning here? Is "position" their
position to reinstate RMS, or their position as a member of the board?
Is this intentionally "consider" as opposed to "reconsider"? If so, is
that intended to be a weaker form of reconsider?
Looking at the text as a whole, while there is talk of accountability,
it's unclear to me what you actually want to happen. In contrast, I am
able to understand the other choices: Choice 1 says RMS and the FSF
board all need to go. Choice A/2 says we are taking no position as a
project. Choice B/3 says RMS needs to go, and FSF needs to fix whatever
allowed him to come back.
Is the general sense here that you would find it acceptable that RMS
stays on the board, as long as he/they acknowledge past
("mistakes"|"impropriety"), "learn from them[,] and change behavior"?
--
Richard
Re: General Resolution: Richard Stallman's readmission to the FSF board
On 3/26/21 7:09 PM, Roberto C. Sánchez wrote: Perhaps said another way, the only valid reason for directing a bunch of attention toward the FSF is if they are worth salvaging. Plenty of comments in the last few days seem to indicate that such might not be the case. Why not form a new organization, like "The Foundation for Free Software (FFS)"? Or some name that is better distinguished from that of the FSF. If nothing else, the FSF is the license steward of the GNU GPL. They are the only entity that can release new versions that automatically trigger the "or any later version" clause. Projects can obviously choose to switch licenses, but only with the consent of all copyright holders. If they weren't already doing copyright assignment, reaching all the copyright holders can be effectively impossible. -- Richard
Re: Amendment to GR on RMS rejoining FSF
On 3/26/21 1:47 PM, Sruthi Chandran wrote: On 26/03/21 10:45 pm, Sruthi Chandran wrote: Dear fellow DDs, Second the amendment text if acceptable to you :) Re-sending with fixed signature and replacing twitter link with gnusocial link. Begin text Under section 4.1.5 of the constitution, the Developers make the following statement: *Debian’s statement on Richard Stallman rejoining the FSF board* We at Debian are profoundly disappointed to hear of the re-election of Richard Stallman to a leadership position at the Free Software Foundation, after a series of serious accusations of misconduct led to his resignation as president and board member of the FSF in 2019. One crucial factor in making our community more inclusive is to recognise and reflect when other people are harmed by our own actions and consider this feedback in future actions. The way Richard Stallman announced his return to the board unfortunately lacks any acknowledgement of this kind of thought process. We are deeply disappointed that the FSF board elected him a board member again despite no discernible steps were taken by him to be accountable for, much less make amends for, his past actions or those who have been harmed by them. Finally, we are also disturbed by the secretive process of his re-election, and how it was belately conveyed [0] to FSF’s staff and supporters. We believe this step and how it was communicated sends wrong and hurtful message and harms the future of the Free Software movement. The goal of the software freedom movement is to empower all people to control technology and thereby create a better society for everyone. Free Software is meant to serve everyone regardless of their age, ability or disability, gender identity, sex, ethnicity, nationality, religion or sexual orientation. This requires an inclusive and diverse environment that welcomes all contributors equally. Debian realises that we ourselves and the Free Software movement still have to work hard to be in that place where everyone feels safe and respected to participate in it in order to fulfil the movement's mission. That is why, we call for his resignation from all FSF bodies. The FSF needs to seriously reflect on this decision as well as their decision-making process to prevent similar issues from happening again. Therefore, in the current situation we see ourselves unable to collaborate both with the FSF and any other organisation in which Richard Stallman has a leading position. Instead, we will continue to work with groups and individuals who foster diversity and equality in the Free Software movement in order to achieve our joint goal of empowering all users to control technology. [0] https://status.fsf.org/notice/3796703 Heavily based on: [1] https://fsfe.org/news/2021/news-20210324-01.html [2] https://www.eff.org/deeplinks/2021/03/statement-re-election-richard-stallman-fsf-board End of text Seconded. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Amendment to rms-open-letter GR
[Hopefully signed this time for the record. Sorry for the noise.] Seeking seconds: ===BEGIN Replace the entire text with: Under section 4.1.5 of the constitution, the Developers make the following statement: The Debian Project echoes and supports recent calls to remove Richard M. Stallman from positions of leadership within free software, for which we believe him to be inappropriate. We are disappointed by the actions of those responsible for restoring him to the Free Software Foundation's Board of Directors, and urge that that decision be reversed. ===END Seconded. This alternative was presented with good faith arguments that appear sufficient to merit its consideration. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: "rms-open-letter" choice 3: do not, as the project itself, sign any letter regarding rms
On 3/26/21 3:19 AM, Timo Weingärtner wrote: ---8<---8<---8<--- The Debian Project will not issue a public statement on whether Richard Stallman should be removed from leadership positions or not. Any individual (including Debian members) is free to issue such statements or (co-)sign any open letter. ---8<---8<---8<--- At the moment, there is only one option with enough seconds. How is voting FOR your proposal different from voting AGAINST the current proposal? Or, if more proposals gain enough seconds, how is voting FOR this option different from voting AGAINST all options that issue a statement one way or the other? I understand that mechanically they are different: this one issues a statement that we won't issue a statement either way. But, in your view, why is that desirable? Why should I vote FOR your proposal (or why should I second it)? -- Richard
Re: Amendment to rms-open-letter GR
Seeking seconds: ===BEGIN Replace the entire text with: Under section 4.1.5 of the constitution, the Developers make the following statement: The Debian Project echoes and supports recent calls to remove Richard M. Stallman from positions of leadership within free software, for which we believe him to be inappropriate. We are disappointed by the actions of those responsible for restoring him to the Free Software Foundation's Board of Directors, and urge that that decision be reversed. ===END Seconded. This alternative was presented with good faith arguments that appear sufficient to merit its consideration. -- Richard
