Debianの投票方法とGeneral Resolutionの仕組み

Debian に何を含めるかを決めるのは誰か

Debian General Resolution (GR) はプロジェクト全体による投票です。特定のポリシーに関する問題を、1 人に任せず Debian として決定するために使われます。投票するのは Debian Developers で、およそ 1000 人です。投票用紙は順位付け方式で、提案者がいない選択肢として必ず「上記のいずれでもない」が含まれます。この選択肢が投票用紙上のすべての提案に勝つこともあります。その場合、プロジェクトは決定しないことを決定したことになります。

これは単なる言い伝えではありません。Debian Constitution には、誰が何を決定できるか、提案を投票にかける方法、投票の集計方法、単純過半数を超える賛成が必要な決定が定められています。サーバーのディストリビューションを選ぶ前に読む価値があります。ポリシー変更がどのように自分のマシンへ反映されるか、また、どの程度の事前通知を受けられるかが分かるためです。

憲章と、その憲章が解決する問題

Debian は 1998 年 12 月 2 日に憲章の version 1.0 を批准しました。現在有効な文書は version 1.9 で、2022 年 3 月 26 日に批准されています。文書の冒頭には、それ以前のすべての version が記載されています。憲章を変更する唯一の方法は、憲章自身が定める投票だからです。

ここでは 4 つの主体が重要です。Developers が共同で最終的な権限を持ちます。Debian Project Leader (DPL) は毎年選出されます。Technical Committee (TC) は、maintainer 間の技術的な紛争を裁定します。Project Secretary は投票を運営し、手続き上の判断を下します。

Section 4.1 には、Developers が団体として実行できる事項が列挙されています。

• Project Leader を任命または解任する。
• 3:1 の賛成多数で憲章を改正する。
• Project Leader または Delegate の権限によって認められた決定を行う、または覆す。
• 2:1 の賛成多数で、Technical Committee の権限によって認められた決定を行う、または覆す。
• 技術以外の方針文書および声明を発行、置換、撤回する。

この比率が設計の要点です。leader の決定を覆すには単純過半数で足ります。leader の決定は暫定的なものと想定されているためです。Technical Committee の決定を覆すには 2:1 が必要です。committee が理由に基づいて裁定する役割を担っているためです。憲章や Social Contract などの基本文書を変更するには 3:1 が必要です。覆すことが難しい決定ほど、成立させるための基準が高く設定されています。

誰が投票し、leader は実際に何ができるか

投票できるのは Debian Developers だけです。Debian の New Member process を通じて認められたプロジェクトメンバーが該当します。この中には、パッケージを保守していなくても、プロジェクトの別の作業を担っている人が含まれます。この手続きを経ていない contributor には投票権がなく、user にもありません。投票権は個々のメンバーに属するため、雇用主が議席や票の集団を持つことはありません。

DPL は毎年春に、同じ順位付け方式で選出されます。デフォルトの選択肢は "None of the above" で、任期は 1 年です。2026 election では、立候補受付が 7 から 13 March、選挙運動が 3 April まで、投票が 4 から 17 April 2026 まで行われました。Sruthi Chandran が唯一の候補者として立候補し、当選しました。集計では、候補者を None of the above より支持した票が 289 票、逆の票が 50 票でした。結果は 18 April 2026 に公開されました。

この役職の権限は、肩書きから受ける印象ほど強くありません。DPL は delegate を任命し、プロジェクトを代表して発言し、緊急対応が必要な事項を決定し、ほかに責任を負う人がいない事項を決定します。DPL は命令だけで technical policy を定めることはできません。section 4.1 により、Developers は leader が権限を持つあらゆる決定を覆せるためです。この覆しには単純過半数しか必要ありません。

Project Secretary は、ほかの仕組みを機能させる目立たない役職です。Secretary は投票用紙を公開し、投票を実施し、集計を行い、特定の選択肢にどの種類の過半数が必要かといった手続き上の問題を裁定します。

一般決議の提案と支持の方法

決議は公開メーリングリスト（実際には debian-vote@lists.debian.org）へのメールとして始まります。誰でも読むことができます。提案できるのは Developer だけです。

憲章では、決議または投票の選択肢は「いずれかの Developer が提案し、少なくとも K 人の別の Developer がスポンサーになることで導入される」と定めています。K はプロジェクトの規模から決まり、定足数も同様です。

2022 non-free firmware vote, published quorum 47.9765567751584

  developers on the roll      1023
  Q  = sqrt(1023) / 2       = 15.992
  K  = min(Q, 5)            = 5        sponsors needed to introduce an option
  3Q = quorum               = 47.977   votes an option must draw to survive

Q は現在の Developer 数の平方根の半分で、K は Q と 5 のうち小さい方です。Debian の Developer 数は数十年にわたり 100 人を大きく超えているため、実際には K は 5 です。提案を支持するには、別の 5 人の Developer がメーリングリストで返信する必要があります。この条件が低く設定されているのは意図的です。スポンサーになることは同意を意味しません。その問題を投票にかける価値があるという意思表示です。

その後、議論期間が始まります。最短は 2 週間、最長は 3 週間です。この期間中、ほかの Developer は、独自の 5 人のスポンサーを付けて、同じ投票に別の選択肢を追加できます。2022 年 1 月の投票で決議プロセスが改定されて以降、すべての選択肢は同等であり、最初の提案者がほかの提案者より特別な立場を持つことはありません。

そのため、Debian の投票が単純な賛成か反対かの質問になることはほとんどありません。通常、GR は議論期間中に異なる人々が作成した、競合する複数の提案の一覧として提示されます。

議論が終了すると、Project Secretary が投票用紙を公開して投票を呼びかけます。これは 7 日以内に行う必要があります。最近の投票期間は 2 週間でした。ファームウェア決議では 2022 年 9 月 18 日から 10 月 1 日まで、現在開かれている決議では 2026 年 8 月 15 日から 28 日までです。

投票用紙が順位付けされ、デフォルト選択肢が果たす役割

Debian は Condorcet 方式で投票を集計します。各投票者は、選択肢を希望順に順位付けします。集計では、選択肢を 2 つずつ比較します。選択肢 A と B について、A を B より上位にした投票数と、B を A より上位にした投票数を数えます。すべての一対一比較に勝った選択肢が勝者です。選好が循環して、そのような選択肢が存在しない場合、constitution は最も弱い敗北から順に除外します。その結果、Schwartz set から勝者が現れます。Schwartz set とは、グループ外のどの選択肢にも敗北しない選択肢のグループです。

順位付けにより、票の分散による問題を解消できます。大筋で一致する 4 つの提案が、互いに票を打ち消すことはありません。そのうち 1 つを支持する投票者は、反対する選択肢よりも上位に残り 3 つを順位付けできるためです。

すべての General Resolution の投票用紙は、デフォルト選択肢で終わります。constitution では、これを「提案者も sponsor も持たず、修正も撤回もできない」と定めています。現在の名称は「None of the above」です。2022 年 1 月に投票された手続き変更までは「Further Discussion」と呼ばれており、古い結果ページには現在もその名称が表示されます。

デフォルト選択肢は、提案を単独で失格にできる 2 つのルールの基準点です。

• Quorum: デフォルト以外の選択肢で、それをデフォルトより上位にした票が少なくとも 3Q 票に達しないものは、審議対象から除外されます。2022 年時点では約 48 票でした。
• Supermajority: 必要な比率でデフォルト選択肢に勝てないデフォルト以外の選択肢は、除外されます。3:1 の提案は、「None of the above」に 3 対 1 で勝つ必要があります。

2 つ目のルールは、誤って記憶されやすいため、もう一度確認してください。Debian の supermajority は、デフォルト選択肢との比較で測定します。対立する提案は、この判定には入りません。

デフォルト選択肢が明確に勝った場合、提案は採択されず、議題はメーリングリストに戻されます。これは正式な結果です。ある選択肢よりもデフォルト選択肢を上位にすることは、開発者が「Debian がこれを述べるくらいなら、何も述べないほうがよい」と意思表示する方法です。

2022 年 3 月以降、投票用紙は秘密扱いです。秘密投票に変更した決議は Sam Hartman が提案し、2022 年 3 月 13 日から 26 日にかけて投票されました。採択された選択肢では、どの開発者がどの投票用紙を提出したかを隠しながら、投票者自身は自分の投票が集計に含まれたことを確認できます。それ以前は、すべての順位付き投票が、投票者名とともに公開されていました。

実際に変わった一般決議

init システム、2 回。 2014 年 2 月 11 日、技術委員会は「jessie の Linux アーキテクチャーにおけるデフォルトの init システムを systemd とする」と決議しました。議論が行き詰まったため、委員長の Bdale Garbee が決裁票を投じて決着させました。委員会自身の決議には、jessie のリリース前にプロジェクトが init システムに関する GR を可決した場合、「その決定がこの投票の結果に置き換わる」とも記されていました。Ian Jackson がその GR を提案しました。投票は 2014 年 11 月 5 日から 18 日まで行われ、最多票を得た選択肢は「一般決議は不要」でした。プロジェクトはこの投票によって、自らの委員会の決定を覆さないことを選びました。

この問題は 2019 年 12 月、「init システムと systemd」という議題で再び提起されました。5 人の開発者が作成した実質的な選択肢は 7 つあり、「systemd に集中する」から「複数の init システムをサポートすることが必要」までの範囲に及びました。投票は 2019 年 12 月 7 日から 27 日まで行われ、集計では 425 票が記録されました。最多票を得たのは「systemd を採用するが、代替案の検討を支援する」でした。

non-free firmware とダウンロードする installer。 2022 年、プロジェクトは公式 installer にネットワークカードなどのハードウェア用 non-free firmware を含めるかどうかを投票しました。6 つの提案が投票に進みました。投票は 2022 年 9 月 18 日から 10 月 1 日まで行われ、最多票を得たのは「installer の non-free firmware について Social Contract を変更し、installer を 1 つにする」でした。この選択肢は Social Contract を改正するものだったため、デフォルトの選択肢に対して 3:1 の差で勝つ必要があり、実際に勝利しました。

この投票は、投票結果があなたのマシンに届く最も明確な例です。2023 年 6 月 10 日にリリースされた Debian 12 "bookworm" では、ほとんどの firmware パッケージが non-free から新しい non-free-firmware コンポーネントへ移され、ハードウェアが必要とする場合は installer がそのコンポーネントを有効にします。投票前は、firmware を必要とするネットワークカードを搭載したマシンでは、非公式のイメージを取得する方法を知っておく必要がありました。メーリングリストへの投稿、投票、そしてあなたがダウンロードする ISO は、1 つの出来事の連鎖です。

意図的に何も表明しない。 2021 年 4 月、プロジェクトは Richard Stallman が Free Software Foundation の理事会に復帰したことについて公式声明を出すかどうかを投票しました。8 つの選択肢が投票に進みました。最多票を得たのは「Debian はこの問題について公式声明を出さない」でした。決議によって、プロジェクトには共同の立場がないことを明確にできます。これは企業の広報部門ではめったに決められないことです。

Debian における LLM 利用に関する決議の投票中

現在、大規模言語モデル（LLM）に関する議論が進行しています。「Debian における LLM 利用」に関する決議案は、2026年7月23日から8月13日まで debian-vote で議論され、異なる開発者がそれぞれ提出した8つの提案にまとまりました。

• Social Contract を通じた Debian への LLM による貢献を認めない
• 条件付きで AI 支援による貢献を認める
• 実務上可能な範囲で LLM を拒否し、Code of Conduct を更新する
• Debian 固有の作業では AI による貢献を認める
• 生成 AI を責任を持って利用する
• 生成 AI には慎重に対応する
• Debian は人間によって作られる
• LLM の利用を避ける。気候破壊は受け入れられない

最初の提案は Social Contract を改訂する内容であるため、デフォルトの選択肢に対して3:1の多数が必要です。残りの7つには単純過半数が必要です。投票は2026年8月15日に始まり、2026年8月28日に締め切られます。

ここで結果を予測したり、結論を示したりすることはありません。投票期間の終了後、Secretary が完全な一対一比較行列を含む集計結果をDebian の投票ページで公開します。引用する価値がある情報源は、そのページだけです。以前の提案「人工知能（AI）モデルに関する DFSG の解釈」は、投票に進む前の2025年中に取り下げられました。提案の取り下げも手続きの一部です。DFSG は Debian Free Software Guidelines を指し、準備が整っていない提案は提出者が取り下げられます。この問題は Debian だけのものではなく、他のプロジェクトも、まったく異なる方法でAI 支援による貢献に関する独自の方針を決めています。

サーバーのディストリビューションを選ぶときの意味

判断の違いを、2 つの形として明確に比較します。

Debian では、ポリシーの変更はポリシーになる前に公開文書になります。提案が投稿された日に内容を読めます。競合する選択肢が示されていく過程を追えます。スポンサーの名前を確認できます。投票が可能になる最短の日付を把握できます。投票後には集計結果も読めます。代わりに速度は遅くなります。これらの投票にはそれぞれ数週間の議論が必要でした。init system の問題については、安定した結論に達するまで 5 年と 2 回の決議を要しました。

Ubuntu では、方向性が企業内部で決まります。Ubuntu の ガバナンスページには Community Council と Technical Board が記載されています。また、プロジェクトのスポンサーである Mark Shuttleworth が、両組織の候補者を絞り込み、各組織で casting vote を持つことも明記されています。その肩書きは self-appointed benevolent dictator for life です。結果として決定は速くなります。2014 年 2 月 14 日、Debian の委員会が systemd を選んだ 3 日後、Shuttleworth は Ubuntu が Upstart を廃止し、Debian に従って systemd に移行すると発表しました。Upstart は Canonical が 2006 年から作成してリリースしてきた init system です。Debian は、委員会の投票、2014 年の 1 回の General Resolution、2019 年のもう 1 回の決議を経て、同じ結論に達しました。

どちらのモデルが抽象的に優れているということはありません。問題が起きる形も異なります。投票は遅く、強い意志を持つグループは、有権者の判断が変わるまで同じ問題を投票にかけ続けることができます。企業の決定は速い一方で、自分が参加していない戦略会議によって覆されることがあります。選んでいるのは、通知をどこから受け取るかです。購読できる公開リストから受け取るのか、その日に読むリリース発表から受け取るのかという違いです。

日々の運用で違いを感じるのは、投票よりもリリースポリシーを通じてです。実際に次に確認すべきなのは、Debian の サーバーにおける stable、testing、unstable suite です。新しいサーバーで 2 つの系列を比較している場合、ガバナンスは複数ある判断材料の 1 つです。Debian と Ubuntu が分岐した経緯では残りの背景を説明し、VPS のオペレーティングシステムの選び方では他の候補と並べて比較します。このパターンは古く、ディストリビューション系列が分岐した経緯を見ると、コードではなくガバナンスが fork の原因になった例が多いことが分かります。

投票結果を自分で読み解く方法

この手順に従うために、Developer である必要はありません。確認する場所は 4 つです。

• https://www.debian.org/vote/ の投票一覧には、撤回されたものを含め、年ごとにすべての決議が掲載されています。
• 各投票ページには、提案、提案者の名前、議論と投票の日付、各選択肢に必要な過半数が掲載されています。
• 各結果ページには、ペアワイズ行列と計算結果が示されています。定足数の行は Option 1 Reached quorum: 307 > 47.6943392867539 のように表示されます。
• debian-vote と debian-devel-announce のアーカイブには、選択肢が作成された経緯となる議論が収録されています。

憲章本体は https://www.debian.org/devel/constitution. にあります。Appendix A は投票について説明している部分であり、結果に疑問を感じた場合に読むべきセクションです。

FAQ

Debian General Resolution に投票できるのは誰ですか？

Debian Developer、つまり Debian の New Member process を通じてプロジェクトのメンバーとして認められた人です。人数はおよそ1000人で、パッケージを保守していなくても、プロジェクト内で別の作業を担当しているメンバーが含まれます。参加手続きを完了していない Contributor、メンバー資格のないパッケージメンテナー、ユーザーには投票権がありません。投票権は個々のメンバーに属するため、雇用主が議席やまとまった投票権を持つことはありません。

General Resolution で「None of the above」が最多になった場合、どうなりますか？

どの提案も採択されず、議題は mailing list に戻ります。デフォルトの選択肢はすべての投票用紙にあり、取り下げることはできません。また、他の2つの規則でも基準になります。定足数を満たす票の中でデフォルトより上位に十分な票を得られなかった選択肢は除外され、必要な比率でデフォルトを上回れなかった選択肢も除外されます。したがって、3:1 の過半数が必要な提案は、「None of the above」に対して3対1で勝つ必要があります。対立する他の提案は、この判定の対象になりません。

General Resolution で Technical Committee または Project Leader の決定を覆せますか？

はい。constitution では、それぞれに異なる要件が定められています。Project Leader または Delegate が権限に基づいて行った決定を覆すには、単純過半数が必要です。Technical Committee の決定を覆すには2:1が必要です。constitution、または Social Contract などの基礎文書を改正するには3:1が必要です。2014年11月、プロジェクトは init systems に関する Technical Committee の決定を覆すかどうかを問う resolution を実施しましたが、「General Resolution is not required」という選択肢が最多となったため、覆さないことを選びました。

General Resolution は提案から結果が出るまでどのくらいかかりますか？

通常は、およそ1か月です。議論の期間は最低2週間、最長3週間です。その後、Project Secretary が議論終了から7日以内に投票用紙を公開し、投票を開始します。近年の投票期間は2週間でした。LLM usage に関する2026年の resolution は典型的な流れを示しています。議論は2026年7月23日から8月13日まで行われ、投票は2026年8月15日から8月28日まで行われました。