Flathub、LLMベースの提出を認めず
(social.treehouse.systems)- Flathubの提出審査でLLMベースの低品質な提出が増え、ボランティアレビュアーの負担が大きくなったことが、方針明確化の背景となった
- 例外は、コミュニティ参加、リリース周期、CI、短期間で作られた手抜き成果物ではない痕跡があるプロジェクトに適用される可能性が高い
- 既存の開発履歴やプロジェクトの健全性基準だけではレビュー作業量は減らず、ルール解釈をめぐる争いだけが増えた
- 新方針は、LLMを一部使った成熟したFOSSアプリや既存のプロプライエタリアプリ全体を禁止するものではなく、手抜き提出を防ぐことに焦点がある
- 一部では、Flatpakエコシステムの配布の断片化再発や企業によるFlathub回避を懸念し、全面禁止より手数料課金を提案している
FlathubのLLM提出ポリシー変更
- Flathubの提出審査でLLMベースの低品質な提出が増え、ボランティアレビュアーの負担が大きくなっていることが、今回の方針変更の主な背景である
- Sjoerd Stendahlは、FlathubのPR一覧に「AI-slop」提出が多く、その規模を考えると今回の措置はより良い選択になり得ると見ている
- Bart Piotrowskiは、プロジェクトにコミュニティ参加、リリース周期、CI、短期間で作られた低品質な成果物ではない痕跡があれば、例外となる可能性が高いと述べた
- これまでも十分な開発履歴や全体的なプロジェクトの健全性を基準に低品質な提出を防ごうとしてきたが、レビュー負担は減らず、ルール解釈をめぐる争いだけが生じた
例外と成熟度の基準
- Nexiは、手抜きのFlathub提出が問題であること自体は事実だが、AI生成またはAI補助コード全体を一律に禁止する方法は行き過ぎだと見ている
- Firefox、VSCode、Chromiumのような既存プロジェクトまで例外なく削除対象になり得るなら、低品質な提出をふるい落とす客観的なプロジェクト成熟度指標のほうが適切だと提案した
- Bart Piotrowskiは、成熟度基準はすでに事実上存在していたが、結果としてレビュー負担の軽減にはつながらなかったと答えた
- Nexiは、例外基準を方針に明確に反映し、コード品質があまりに低ければ追加説明なしに却下され得るという但し書きも置けると見ている
- Sjoerd Stendahlは、新方針は成熟し適切に保守されているプロジェクトに例外を設けるものであり、LLMを一部使用した実績あるFOSSアプリケーションや既存のプロプライエタリアプリケーション全体を禁止する方針ではないと見ている
エコシステムへの影響と配布経路への懸念
- Dmitry Mantisは、この方針がFlatpakの解決対象であるLinuxの配布の断片化を再び生む可能性を懸念している
- SlackやSpotifyのようなプロプライエタリアプリがFlathubでサンドボックス形式で提供される点は利点であり、クローズドソースは作成方法が分からないという理由で、むしろ有利になるのかという疑問も提起された
- 新しく無名の開発者によるプロプライエタリアプリケーションは、この方針がなくてもFlathubに即時公開しないほうがよいという反論も出ている
- AppImageのみだった一部アプリが公式Flatpakをサポートし始めた流れは前向きだが、この種の方針の後では企業がFlathub参入を避ける可能性があるとの懸念がある
- AIベースの提出に、レビュー費用を賄うための手数料を課す方式が全面禁止より良いという提案もある
- 一定規模のユーザーを獲得するまでは他で配布せよというシグナルになり得るし、テストや文書自動化の一部にLLMを使った、よく保守されたアプリが別の配布経路に定着すると、Flathubへ移る動機が弱まる可能性がある
LLMツールをめぐる相反する評価
- Thomas Fuchsは、LLMの問題は技術そのものより人とマーケティングの問題に近いと見ている
- LLM企業がLLMを魔法や個人用の作業奴隷のように売り込み、利用者がその主張をそのまま信じてしまうことが問題だと指摘した
- 熟練した利用者が長所と短所を理解して限定的な用途に使えば優れたツールになり得るが、業界は「火のついたチェーンソーをジャグリング用として無料配布している」かのように攻撃的に宣伝していると表現した
- Wolkensteineは、LLMがまったく役に立たないとは見ていないが、ほとんどの場合は有用でなく、倫理的に支持したい形で作られた有用なモデルもまだ存在しないと見ている
- オンデバイスモデルは、スペルチェックや携帯電話キーボードの自動修正における単語予測には役立つかもしれないが、誤りなくできる作業の多くは人間が簡単にこなしつつ学べるものだと見ている
- Emberは、そのような潜在的用途も生成AI以前のツールで可能だったし、まれなケースでは特定データで訓練した特化型MLのほうが優れていると見ている
- Kroc Camenは、コード盗用、内在するバイアス、環境への影響のため、LLMにはどこにも有効な用途はないと主張している
コミュニティ文化と論争の二極化
- triswebは、LLM生成コードとその利用者を取り巻く文化が、オープンソースコミュニティを維持するのに必要な親切で協力的な姿勢と合わない場合が多いと見ている
- ragectlは、新しいアプリにはクーリング期間のような考え方が必要かもしれず、複数回のリリースと2人目の人間の貢献者が現れるまではリスクが高い可能性があると見ている
- Sjoerd Stendahlは魔女狩りには注意すべきだが、ビッグテックによる攻撃的なLLM推進が人々の反発を強めていると見ている
- 一部の雇用主は解雇の脅しとともに業務でのLLM使用を要求しており、検索のような単純な機能すら壊され、「Agentic future」は非常に限定的な需要しかないのに、多くの製品が人間の作業をまねた残滓のようなものへと変わっていると表現した
- razzeは、検索やチャットボットにLLMを使う問題とコードに使う問題は別であり、コードは検証可能でトレードオフも明確なので分けて判断すべきだと見ている
- Zeeshan Ali Khanは反LLM陣営の攻撃性を指摘し、Bart Piotrowskiはpro-LLMとanti-LLMの双方で二極化が激しく、「vibecoders」も批判されると被害者のように振る舞うと答えた
厳選された技術トピックを続けて受け取りたいですか？
Telegramチャンネルをフォローしてください。 @GeekNewsJP
1件のコメント
Lobste.rs の意見
「AI が生成した、または補助したコード、ドキュメント、その他のコンテンツを含むアプリケーションは認めない」というのは、かなり強硬に見える
Flathub は Linux デスクトップユーザーがアプリを入手する非常に一般的な場所で、自らを「Linux 向けアプリストア」と呼んでおり、1000 個以上のアプリがある
本当にそのアプリのどれ一つとして AI 補助コードを使ってはいけないという意味なのか？ 現実的なのか？ もう手遅れではないのか？
すでに FlatHub に載っているプロジェクトでも、バイブコーディング されたものだと判明すれば削除できるし、明確なメッセージも送れる
既存の主要アプリケーションの一部は例外として認められる可能性があり、そうした場合でも制限はアプリ自体のコードより独立した flatpak パッケージング により強く適用されそうだ
こうした強硬なアプローチが 100% 執行可能ではないとしても、企業が LLM 導入 を強引に押し進めている状況では、コミュニティができる最低限の抵抗として、こういう強い立場は必要だ
最近の サプライチェーン 関連の事件を考えると、かなり妥当な判断に聞こえる
プロジェクトが LLM を禁止しようと、白髪の人や身長が正確に 160cm の人を禁止しようと、好きに決める自由は 100% 支持する
その自由を制限しようという意味ではないが、パッケージ管理は LLM の助けを大いに受けられる典型的な反復作業だ
自分のコードを純粋芸術や職人技の産物だと考える人たちもある程度は理解できるが、いちばん退屈な作業を自動化させない理由は何だろう？
Arch Linux の AUR が始まって間もないころ、数百個のパッケージをうまく保守していた人たちがいたのを覚えている
常に最新状態で、ほとんど壊れることもなかったが、当然自動で更新していたはずだ
今日同じことを LLM 補助 で行えば、ほぼ確実にもっと堅牢にできるはずだ
もしかするとその過程で人間を禁止すべきなのかもしれない
サプライチェーン攻撃以外に、人間は何を貢献できるのか？ いつか自分の考えが正しいか間違っているかを証明するために LLM ディストリビューション を作ってみるべきかもしれない
その前にまずこのプログラミング言語を終わらせないと、笑える