6月26日、xlii.spaceが「Honesty gets Emacs patch rejected」と題した記事を公開した。LLMを活用したことを正直に申告したEmacsへのパッチが、GNUのポリシーにより却下された経緯と、その構造的な問題を論じた内容だ。

筆者が問題にしているのは「LLM支援成果物を受け付けないこと」ではなく、「申告した者だけが弾かれる」という非対称性だ。黙って出せば通っていたかもしれないパッチが、誠実に開示したことで却下される——このポリシー構造は、むしろ隠蔽を合理的な選択にしてしまう。

「正直に言ったら落とされた」

筆者はmacOS上のEmacsパフォーマンス改善に数ヶ月取り組んできた。着目したのは正規表現処理で、Emacs全体で広く使われているため、ここを改善できれば全体的なパフォーマンス向上につながると踏んでいた。

あるとき、友人から提供されたz.aiのMaxプランを通じてGLM 5.2（智谱AIが開発する中国発のオープンウェイトモデル）を利用し、約3時間の解析で複数の問題レポートを得た。筆者はそれぞれの正確性と影響度を検証し、パッチを手動でテストした上で、最も効果的なものをemacs-develメーリングリストに投稿した。

投稿時に申告した内容は以下のとおりだ。

• 問題の発見とパッチの草案はGLM 5.2によるもの
• 問題レポートの正確性と影響度は自分で検証済み
• パッチのレビューと修正は自分で実施
• 手動テストも自分で実施
• 法的な著者としては自分が責任を負う

パッチ本体は92行で、変更スコープは非常に狭い。翌日返ってきたのは却下通知だった。理由はGNUの「LLM支援による成果物は受け付けない」というポリシーだ。

「申告した者が損をする」構造

GNUはここ数年、LLM生成コードの著作権上の不確実性や「モデルが十分にオープンか」という問題を理由に、LLM支援成果物の受け入れを拒否する方針を採ってきた。ただし、このポリシーはGNU内部のメーリングリストでの議論を経て形成されており、外部から経緯が見えにくい。筆者はこの不透明さも批判している——「内部で決めて外に示さないのは、MetaがFacebookの方針を内部で決めるのと変わらない。それをオープンとは呼ばない」と述べている。

筆者が最も問題視するのは、ポリシーそのものではなくその構造的な歪みだ。

「LLMを使ったことを黙っていれば通っていた。正直に申告したことで却下された。これはLLMの使用そのものではなく、誠実さを罰するポリシーだ」

申告を禁じるのではなく、申告した者だけが弾かれる仕組みになっている。筆者はLLMをまったく信頼しておらず、「だからこそLLM支援の成果物にはより多くのレビューが必要だ」という立場だ。申告を促すのではなく隠蔽を促す現行ポリシーは、コード品質の観点からも逆効果という論点は説得力がある。

著作権論と「オープン性」への疑問

GNUがLLM利用を問題視する理由として筆者が伝聞した内容は2点——「モデルが十分にオープンか」と「法的に使用可能か」だ。

オープン性については、GLM 5.2は十分なVRAMとRAMがあれば手元で動かせるオープンウェイトモデルだ。「OpenRouterを経由したら駄目だがローカルなら良い」という線引きを筆者は不合理だと指摘する。

著作権については、米著作権局の見解を引用している。

「著作権局は、自然・動物・植物によって生み出された作品を登録しない。同様に、神的または超自然的存在によって作られたとされる作品も登録できない」

筆者の解釈は「LLM出力に著作権を付与することができないのが問題であって、それを使うこと自体が問題なのではない」だ。著作権が発生しない素材を使う方が法的にはシンプルという見方もできる。

約40本のパッチを抱えてEmacsから去る

筆者はEmacs関連の作業をやめると宣言した。手元には約40本のパフォーマンス改善パッチがあるが、今後の提出予定はない。直近で効果を確認できたものだけをGitHubに公開している。macOS上でのEmacsパフォーマンスに悩むユーザーにとっては、参照する価値がある。

OSSプロジェクトにおけるLLM活用の是非は、各コミュニティで判断が分かれている。GNUの立場はその中でも特に厳格だが、「申告した者が損をする」構造への批判は、ポリシーの実効性という観点から無視しにくい指摘だ。

詳細はHonesty gets Emacs patch rejectedを参照していただきたい。