Human Emacs
(human-emacs.org)- Human Emacsは、GNUの最終方針にかかわらず、LLM生成の貢献を受け入れないEmacsを使い開発していくという参加者たちの宣言である
- GNU Emacsにおける現在の禁止は、すべてのGNUパッケージに適用されるGNU共通方針が確定するまで維持される予防的な暫定措置である
- GNUがLLM生成の貢献を許可した場合、過去のEmacsフォークを巡る対立や成功可能性の低さを承知のうえで、別個のLLM不使用Emacsを維持する方針である
- LLMの性能や公開ウェイトモデルは核心的な争点ではなく、出所を偽ったLLM生成パッチは既存の剽窃事例と同じ方法で扱えるとみている
- GNU共通方針が許可したとしても、Emacsメンテナーはより厳しい追加方針を設けられるため、現在の暫定禁止を恒久化できるという立場である
EmacsがGNU共通方針を懸念する理由
- Emacsは、倫理的原則を損なうことなくユーザーの力を高める自由ソフトウェアプロジェクトであり、参加者たちは今後も善意のもとで利用し貢献できることを望んでいる
- 参加者たちは、2026年に入ってから信頼してきたソフトウェアプロジェクトが相次いでLLMベースの開発を採用したとみている
- VimやrsyncもLLMベースの開発を積極的に受け入れたことで、中核ユーザー層を疎外したと評価している
- その結果として現れたフォーク事例に vim-classic を挙げている
- GNU Emacsの指導部は現在、LLM生成の貢献を受け入れていない
- emacs-develでの議論 によれば、GNUプロジェクトがすべてのGNUパッケージに適用する方針を定めるまで維持される予防措置である
- Emacsプロジェクト単独の決定ではなく、GNU全体の次元で定めるべき事案だという立場である
- 参加者たちは、今後のGNU方針がGNUが歴史的に維持してきた高い倫理基準に達しない可能性を懸念している
- LLMの負の外部性は大きいとみているが、まだ明確な方針が出ておらず、最終方針が関連する問題を防げないおそれがあると心配している
LLM生成の貢献がないEmacsを維持する方針
- GNUがどのような方針を選んでも、LLM生成の貢献がないEmacsを使い開発していく計画である
- GNUがコストを考慮して同じ決定を下すなら、引き続き支援する
- GNUが別の決定を下すなら、その成果物がGNU Emacsでなくとも別バージョンを維持する
- Emacsのフォークは歴史的に大きな論争を呼び、常に成功したわけでもないため、参加者たちもフォークの可能性を軽く見てはいない
- しかし、GNU EmacsがLLM生成の貢献を許可するなら、選択肢は多くないとみている
- 多くの参加者にとって、Emacsを手放すことはコンピューティング全体、あるいはコンピューティングにおける楽しさのある部分を手放すことに近い
- GNUの上位方針が問題を扱わなくても、Emacsメンテナーはその上に追加方針を設けられるとみている
- GNU共通方針と矛盾しない範囲で、現在の暫定禁止を恒久方針へ移行できるという立場である
人間が作るソフトウェアを守ろうとする根拠
- Guixの合意文書 Standing up for human crafting は、Emacsのように依存度の高いプログラムになぜこのような方針が必要なのかを詳しく扱っている
- 参加者たちは、LLMの害は十分に明白だと考えており、同じ根拠を再び列挙する代わりにこの文書を参照先としている
- ただしGuixは、Emacsのような暫定禁止措置を先に設けなかったため、方針にいくつかの例外を残さざるを得なかったと評価している
核心的議論から除外した争点
-
LLMの性能
- LLMが主張される機能を実際にどの程度うまく果たすかは議論の対象ではない
- 性能とは別に、LLMの使用がユーザーの力を高めることを志向する原則あるソフトウェア運動に含まれうるのかを問題にしている
-
公開ウェイトモデル
- 公開ウェイトモデルも代替案として扱っていない
- こうしたモデルも、企業がデータセンターを通じてWebデータを破壊的に収集し、地域社会に被害を与える基盤の上で作られているとみている
- 最終利用者が同意を得て収集したデータでモデル全体を自ら学習できる場合にのみ議論できるのであり、現時点では空想と推測の領域だと判断している
-
パッチ出所を偽る貢献
- 悪意ある貢献者がパッチの出所を隠す可能性も、別個の争点とはみなしていない
- 貢献者がパッチのライセンスや著作権上の問題を偽る危険は以前から存在してきた
- LLM生成パッチを他の形の剽窃と同じ方法で扱えば十分だとみている
議論への参加と運営
- 議論は メーリングリスト と Libera Chat の
#human-emacsチャンネルで行っている- メーリングリストに登録しなくても投稿できる
- 署名に名前と任意のURLを追加したい場合は、メーリングリストに投稿するか
#human-emacsチャンネルで依頼すればよい - サイトの ソースコード も公開されている
1件のコメント
Lobste.rsの意見
Emacsユーザーではないが、中核的な開発ツールを低品質なAI生成物とその追随者から守るという断固たる宣言を見て心強く感じた
今後のGNUの方針が、歴史的に守ってきた高い倫理基準をEmacsにも維持できないのではないかという懸念は、なぜ生じているのか? GNUは最終的に、ほとんどが非自由モデルであるLLMを自らのソフトウェアで許容しようとしているのか?
他のGNUプロジェクトでも倫理的行動に基づく方針に対してかなりの反発があり、GNUプロジェクトの中で指導部を最も信頼しているGuixでさえ、まだ対応策を議論している: https://codeberg.org/guix/guix-consensus-documents/pulls/13
GNUは歴史的に、他のあらゆる要素を犠牲にしてでも、ライセンスと著作権にだけ近視眼的に集中してきた。LLM支持者がライセンス上は問題ないという理屈を作れば、GNUがその先にある数多くの問題をもはや議論しなくなるのではないかと懸念している
もちろんGNUが正しい決定を下し、こうした準備のすべてが不要になる可能性もあり、それこそが私たちの望む最善の結果だ
GNUの哲学では、LLMは少なくとも明示的には倫理問題ではなく、多くの自由ソフトウェア開発者は別個に倫理的理由からLLMに反対している。より直接的な懸念は、LLM生成コードが著作権保護を受けられず、コピーレフトを無効化しうる点にある
すでにあまりにも多くのプロジェクトがLLMを受け入れる姿を見てきたので、実際に起こる前に備える必要がある
rsyncがLLMを積極導入したと言うが、最近はLLM特有の痕跡のためにrsyncへの貢献が拒否されたという話を読まなかったか?
EmacsはGNUが決定を下すまでLLM生成の貢献を受け付けていないので、この宣言はやや先走りに見える
LLMは、以前は改善が難しかった領域でEmacsを発展させられる可能性がある。すでに、多くの作業を要していた非常に複雑なバグや抽象化レイヤーを改善した前例もある
「議論しない事項」の節で述べているように、LLMが主張されるほど有効かどうかは論点ではない。核心は、LLMの利用がユーザーの権限強化を志向する原則的なソフトウェア運動の一部たりうるのか、という点だ