Vibecodingの公開によりEmacsパッチが却下される
(xlii.space)- macOS向けのEmacs性能改善のために作られた小さなパッチが
emacs-develに提出されたが、LLM補助作業を受け入れないGNUの方針により受理されなかった - 投稿者は、GLM 5.2が問題発見と草案作成を行ったと公開する一方で、正確性・影響分析、修正、手動テスト、個人としての責任は自分が負ったと説明した
- 却下されたパッチは範囲の狭い92行のもので、LLM使用の事実を隠すこともできたため、この方針は使用そのものよりも正直な開示を不利にしていると批判した
- GNU側の懸念は、LLM生成物の公開性・法的な利用可能性に近いものだったが、彼はオープンウェイトモデルと実際の業界利用事例を根拠に同意しなかった
- 彼は今後Emacs作業を行わないと述べ、ハードドライブにあった約40件の性能改善パッチのうち、最近確認した一部のみを公開した
macOS Emacs性能改善作業
- Przemysław Alexander Kamińskiは数か月にわたりmacOSでEmacsの性能を改善し、計測の接続やベンチマーク作成に時間を費やした
- 複数のLLMにEmacsコードベースを与えて特定の問題を探させたが、全体として結果はあまり良くなかった
- パッチを分析すると、影響が小さいか、問題を誤解しているケースが多かった
- 当時の性能ボトルネックに関する判断は次のとおりだった
- macOSでの主な問題はレンダリングの問題と、高速な割り当て・解放によるメモリスラッシング
- macOSのシステム
malloc方式は、メモリ圧縮の欠如により仮想メモリの膨張とキャッシュ局所性の損失を引き起こす - Emacsコアにも性能上の問題が残っている
- regexp処理は複数箇所で使われるため、改善すれば全体性能に影響しうる
GLM 5.2で見つけたパッチと提出までの過程
- 友人からz.ai Maxプランをもらい、GLM 5.2を使えるようになり、彼はこのモデルをコード最適化にかなり有能だと評価した
- すでに蓄積していた知識をもとにEmacsに関する具体的な質問を投げ、GLM 5.2に問題探索と分析を任せた
- 約3時間後にいくつかの報告を受け取り、提案とコードを確認したうえで各項目の影響をテストし、ベンチマークを実行した
- パッチ提出向けの整理には時間がかかるため、最も有望な項目を1つ選んで作業し、記事執筆の2日前に
emacs-develメーリングリストへ送った - 翌日、GNUにはLLM補助作業を受け入れない方針があり、そのためパッチは受理されないと知った
提出メールで開示したLLM利用範囲
- メーリングリストにパッチを送る際、LLM利用の事実と自分のレビュー範囲をあわせて明記した
- 問題発見とパッチ草案の作成はGLM 5.2が行い、GLM 5.2は中国のオープンウェイトモデルだと説明した
- 問題報告の正確性と影響を自分で分析した
- パッチをレビューして修正した
- パッチを手動テストした
- 法的目的のため提出物の著作者性を宣言し、自分の寄与がLLMより大きいと主張する用意があると述べた
- 提出物について全面的に個人責任を負うと宣言した
- 提出物は実装範囲が非常に狭く、規模も小さかった
- 公開したパッチは92行で、コメント内に存在理由が含まれている
- 彼はこのパッチを「slop」に分類できるものではないと考えるが、判断は各自に任せると付け加えた
GNU方針への反論
- 彼はGNUの方針を尊重はするが同意しておらず、方針には十分な根拠がないと見ている
- LLM利用の事実を隠すこともできたが、明示的に開示した結果、投稿が不利になったと判断している
- そのため、この方針はLLM利用そのものよりも正直な開示を罰していると批判した
- 彼はLLMをまったく信頼していないため、LLM補助作業にはレビューを減らすのではなく、より多くのレビューと注視が必要だと考えている
- 方針の全体的な文脈はGNU内部リストで議論されているため分からず、過去の対話で触れた疑問は、LLMの寄与が十分にオープンか、法的に利用できるかに近かったと整理した
- オープンウェイトモデルの公開性を問題視する論理には同意していない
- たとえばローカル環境でQwen 3.6を使えば問題なく、OpenRouter経由で使うとだめだというような区別は不合理だと考えている
- GLM 5.2はオープンウェイトモデルであり、256GB RAMと24GB VRAMがあればローカルで実行して「SaaSは閉じている」という論点を避けられると述べた
- インターネットには非自由なコンテンツが多いのだから、同じ論理なら提出物を作る際のインターネットアクセスも禁止すべきなのかと問い返した
- 法的懸念にも同意していない
- ゲーム会社はIPとLLMにより敏感だが、それでもLLM利用は見られ、ChatGPTには10億人のアクティブユーザーがおり、数十万から数百万の組織が毎日LLM出力を使っていると述べた
- 自分は米国の弁護士ではないと断ったうえで、著作権登録の問題は著作権表示を付ける側にあると理解しているとした
- GNUが自分たちの弁護士と意見に最も大きな重みがあると信じる姿勢には同意しないと述べた
Emacs作業の中止と公開されたパッチ
- 彼はGNUには自ら決定する自由があり、自分にも批判する自由があると述べた
- 内部で方針を議論しながら利用者に透明でないやり方は、MetaがFacebookの方向性を社内で決めるのと同程度にしか開かれていないと批判した
- 結果として、彼は今後Emacs作業を行わないと明らかにした
- ボランティアで行う作業で「棒を持つ位置が間違っている」と言われるような状況が嫌だと述べた
- ハードドライブには約40件の性能改善パッチがあり、一部は互いに重複し、一部は実際の影響がまだ証明されていない
- 最近確認して動作し、有意な影響を示した一部のパッチだけを公開しており、それらのパッチは実際に違いを生むと彼は述べている
1件のコメント
Lobste.rsの意見
著者は "open weight" の open の意味を誤解しているように思える
最終的な行列の塊が公開されていて、ある程度ファインチューニングできるからといって、それを作るのに使われた学習データまでオープンソースだったことを意味するわけではない。OSI seems to agree もおおむね同じ見解のようで、だとすれば著作権の問題はまったく解決していない
善意で無償の貢献をしようとする人に共感はするが、GNU はルールを明確に書いており、そこへ行って「少しだけ破ったけど、はいパッチです」と言えば、拒否されても不思議ではない。拒否の理由は正直だったことではなく、明示的にするなと言われていたことをしたからだ
著者には、何十億人もの人が間違っている可能性があることを今日学んでほしい。Normalization of deviance は逸脱を正当化するものではなく、その逸脱が広がっていく仕組みを説明するものにすぎない
chatbot psychosis で見られるパターンの一つは、反対したり異なる意見を出したりする人間を敵として認識することだ。チャットボットが学習した narremes には、ユーザーが主人公であり、肩越しのカメラ視点と読みやすい個人的な物語を持つという観点が含まれている。チャットボットの後処理された好みの物語がユーザーに直接影響して主人公意識を強め、十分にイオン化されると中立的な立場すら受け入れられなくなる
この件では、著者がリンクも引用もしていない the original discussion を読むことを勧める。Emacs コミュニティは著者に対して親切で、受容的で、質問し、関心を示し、受け入れる姿勢を見せていた。パッチを拒否する際にも、著者を非難するのではなく GNU の方針に焦点を当てて穏やかに語っている
[incomprehensible]タグまで付いているそれでも文脈から意味は分かるし、ここでは有用でよく合う概念に見える
GNU Project は米国の著作権問題だけでなく、世界中の著作権上の懸念 を考慮しなければならない。米国法ですらまだ完全には整理されていない
GNU は重要な貢献について、自分たちが著作権を 100% 保有していると確信したいのだ。ここで著者の法解釈は重要ではなく、GNU Project は安全策を取っている。LLM についておそらく持っている別の懸念は、まだ考慮すらしていない段階だ
しかも、リポジトリに LLM 生成コードが入っているのに、そのコードが明確に区別・表示されていなければ、リポジトリ全体が著作権保護もライセンス付与もできないものと見なされる
言い換えれば、著者が嘘をついてコードをコミットさせていたなら、Emacs コードベース全体のライセンス効力を危険にさらしていた可能性がある
これらすべては、「自分は法律家ではないが弁護士たちは明らかに間違っている」という、妄想に近い尊大な態度とは別の話だ。関連する法律条文の一部だけを見ながら、同時に弁護士たちを傲慢だと非難している
[1] 約2か月前に会社の法務チームとこの話をした時点では最新の理解だった
「嘘をついていれば受け入れられていただろう」が意味のある論拠かどうかはよく分からない
それはその人たちについて何か良いことを言っているのだろうか？
管理者たちを LLM 賛成・反対の方針のことで悩ませても良いことはないと思う。彼らは仕事をしており、どの貢献を評価し、受け入れ、拒否するかを選ぶ権利がある
もちろん不満を述べるのは構わないと思う。この人はブログで自分の立場を明らかにしており、そうやって議論の焦点を合わせていくのだから。ただ、その framing には同意しない。ここでの問題は「正直さ」ではない。no-LLM 方針が告知されていたのなら、そうした貢献を望まないプロジェクトに LLM を使って貢献しようと時間を使った責任は本人にある
これはヴィーガンに肉やチーズ入りの食べ物を渡して、材料を「正直に」言ったのに食べないと文句を言うのと変わらない。「言わなければ乳製品が入っていると分からなかったはずだ」は好意的には見えないし、「言わなければ自分が LLM を使ったと分からなかったはずだ」も同じだ
GNUとFSFは、専門的な法的助言を受けるためにかなりの投資をしている。ところがこの潜在的な貢献者は、インターネット上の誰かの発言に従って、その専門的助言を無視しろと勧めているようなものだ
専門的助言に費用を払ったのなら、その助言に従うのが合理的であり、同意できないなら別の専門家を探すべきだ。無作為なネットのコメント投稿者の助言のせいでそれを無視するのは、「ほとんど風刺的」なのではなく、単に愚かだ
拒否とは別に、今後かなり興味深い法廷での事例が生まれる気がする。大規模モデル提供企業が何らかの形の補償を提供し、「私たちが手伝って作ったコードなのだから、好きなように著作権を主張してよい」と言うかもしれないし、逆に問題を押し進めて、自分たちが所有しており特定の用途にはライセンス取得が必要だと言い出すかもしれない。Claudeは現在コードをユーザーに渡すが、どのような補償を提供するのかは分からない。他のモデルについてもよく分からない
犯罪は捕まったときだけ違法だという事実を知っていたか
GNUの熱烈なファンというわけではまったくないが、LLMコーディングツールはGNUの哲学の正反対にあるのではないか？ 猫カフェに犬を連れて行って追い出されたのに怒っているような感じだ
タイトルを"Honesty gets Emacs patch rejected"からVibecoding gets Emacs patch rejectedに変えたのは、非常に不誠実だと思う
著者のようにAIツールの助けを受けていたとしても、コードにそれだけの時間と理解を注いでいたなら、明らかにバイブコーディングではない。「Emacsをもっと速くしてくれ」とAIに投げて、結果をろくに見ずに提出したならバイブコーディングだろうが、文章を読む限り、明らかにそうではなかった
自分なら"Breaking contribution policy gets Emacs patch rejected"くらいにしたと思う。相変わらず皮肉っぽいが、反論はしにくい
ここで目につくのは、著者が2か月間継続して作業したと主張している一方で、問題を見つけて解決するのに使ったというモデルは12日前にリリースされたと説明している点だ
著者がかなり腹を立てているのは理解できるが、結局のところオープンソースは何らかの権利を与えるものではなく、すでに作られたコードを使える特権に近いと思う。利点があるなら、おそらくあるだろうし、macOSについて書いている内容もおおむね正しいので、Emacs開発者が時間を取って見てくれるかもしれない。ただしmacOSが彼らの主な関心事ではなさそうだ
このポリシーがどれほど愚かかを証明する簡単な解決策がある。2台目のモニターにLLM補助PR diffを表示しておき、メインモニターで修正内容を最初から手で書き直せばいい。変数名やコメントの内容も少し変えればいい
これでもう人間が書いたコードになったのだから、マージできる