Debianの投票方法とGeneral Resolutionの仕組み
Debianの政策は約1000人のDeveloperが順位投票で決めます。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 が必要です。覆すことが難しい決定ほど、成立させるための基準が高く設定されています。
誰が投票し、リーダーが実際にできること
投票できるのは Debian Developers だけです。Debian の New Member process を通じて承認されたプロジェクトメンバーが該当します。パッケージを保守していなくても、プロジェクトの別の作業を担当していればメンバーになれます。この手続きを経ていない contributor には投票権がなく、user にもありません。投票権は個々のメンバーに属します。そのため、雇用主が議席やまとまった票を持つことはありません。
DPL は毎年春に、同じ順位付け方式で選出されます。デフォルトの選択肢は "None of the above" です。任期は 1 年です。2026 年の選挙では、立候補受付が 3 月 7 日から 13 日まで、選挙運動が 4 月 3 日まで、投票が 2026 年 4 月 4 日から 17 日まで行われました。Sruthi Chandran は唯一の候補者として立候補し、当選しました。集計では、候補者を None of the above より支持した票が 289 票、逆方向の票が 50 票でした。結果は 2026 年 4 月 19 日に公開されました。
この役職の権限は、肩書きから受ける印象ほど強くありません。DPL は delegate を任命し、プロジェクトを代表し、緊急対応が必要な事項を決定します。また、他に責任を負う者がいない事項も決定します。ただし、DPL が命令だけで技術方針を定めることはできません。section 4.1 により、Developers は leader に認められたあらゆる決定を覆せるためです。この覆しには単純過半数しか必要ありません。
Project Secretary は、他の仕組みを機能させる目立たない役職です。Secretary は投票用紙を公開し、投票を実施し、集計を行います。また、各選択肢にどの過半数が必要かといった手続き上の問題について判断します。
一般決議の提案と支持
決議は公開メーリングリスト、実際には debian-vote@lists.debian.org へのメールとして始まります。誰でも内容を読めます。提案できるのは Developer だけです。
憲章では、決議または投票項目は「いずれかの Developer が提案し、少なくとも K 人の他の Developer が支持した場合に導入される」と定めています。K はプロジェクトの規模から決まり、定足数も同様です。
2022 voting secrecy 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 surviveQ は現在の Developer 数の平方根の 2 分の 1 で、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 日まで、直近の LLM 決議では 2026 年 8 月 15 日から 28 日までです。
投票を順位付けする理由とデフォルト選択肢の役割
Debian は Condorcet 方式で投票を集計します。各投票者は、選択肢を希望順に順位付けします。集計では、選択肢をすべて 1 組ずつ比較します。選択肢 A と B の場合、A を B より上位にした投票数と、B を A より上位にした投票数を数えます。すべての 1 対 1 比較に勝つ選択肢が勝者です。選好が循環してそのような選択肢が存在しない場合、constitution は Schwartz 集合から勝者が現れるまで、最も弱い敗北を取り除きます。Schwartz 集合とは、集合の外側にあるどの選択肢にも負けない選択肢のグループです。
順位付けにより、票の分散による問題を解消できます。大筋で一致する 4 つの提案が互いに票を奪い合って消えることはありません。投票者は、そのうち 1 つを好む場合でも、嫌いな選択肢より上に残り 3 つを順位付けできるためです。
すべての General Resolution の投票では、最後にデフォルト選択肢が置かれます。constitution では、これを「提案者もスポンサーもなく、修正も撤回もできない」と定めています。現在の名称は「None of the above」です。2022 年 1 月に投票された手続き変更までは「Further Discussion」と呼ばれており、古い結果ページには今もその名称が表示されます。
デフォルト選択肢は、提案を単独で廃止できる 2 つの規則の基準点です。
- 定足数: デフォルト以外の選択肢で、デフォルトより上位にした票を少なくとも 3Q 票得られなかったものは、審議対象から除外されます。2022 年では約 48 票でした。
- 特別多数: デフォルト以外の選択肢で、必要な比率でデフォルトに勝てなかったものは除外されます。3:1 の提案は、「None of the above」に 3 対 1 で勝つ必要があります。
2 つ目の規則は、誤って記憶されやすいため、2 回読んでください。Debian の特別多数は、デフォルト選択肢を基準に判定します。対立する提案は、この判定には関与しません。
デフォルト選択肢が明確に勝った場合、提案は採択されず、質問はメーリングリストに戻されます。これは正式な結果です。ある選択肢よりデフォルト選択肢を上位にすることは、「これを言うくらいなら、Debian には何も言わないでほしい」と開発者が示す方法です。
2022 年 3 月以降、投票は秘密になっています。この決議は 2022 年 3 月 13 日から 26 日まで投票され、特別多数の規則が実際に適用された例です。Sam Hartman が提案した投票者の身元を隠す選択肢は、デフォルト選択肢に 149 対 94 でしか勝てず、constitution の変更に必要な 3:1 に届かなかったため除外されました。Judit Foglszinger が提案した当選選択肢は、185 対 61 でこの基準を満たし、constitution version 1.9 になりました。これにより、どの開発者がどの投票を行ったかは隠されますが、投票者は自分の投票が集計に含まれたことを確認できます。それ以前は、順位付き投票がすべて、投票者名とともに公開されていました。
実際に変わった一般決議
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日から28日まで行われました。名簿上の開発者は1045人で、定足数は約48.5票でした。8つの選択肢はすべて定足数に達しました。
この結果から、前のセクションで説明した2つの規則が実際に適用されたことが分かります。Social Contract の選択肢は、「上記以外のすべて」より上位に順位付けした投票が144票、下位に順位付けした投票が257票でした。比率は0.560で、必要な値は3だったため、除外されました。「実行可能な範囲で LLM を拒否し、Code of Conduct を更新する」は、デフォルトの選択肢に176対230で敗れたため、除外されました。勝者は「生成 AI を責任を持って利用する」でした。この提案はデフォルトの選択肢に281対126で勝ち、他のすべての選択肢にも一対一の比較で勝利しました。2026年10月12日時点で、Debian の2026年投票インデックスではこの決議は完了扱いになっており、他に公開中の General Resolution はありません。
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日まで行われました。