Flathub ไม่อนุญาตการส่งผลงานที่อิงกับ LLM

• ในการ ตรวจทานการส่งขึ้น Flathub มีการส่งงานคุณภาพต่ำที่อิงกับ LLM เพิ่มขึ้น ทำให้ภาระของผู้ตรวจทานอาสาสมัครสูงขึ้น และเป็นฉากหลังสำคัญที่ทำให้ต้องชี้นโยบายให้ชัดเจน
• ข้อยกเว้นมีแนวโน้มจะใช้กับโปรเจ็กต์ที่มี การมีส่วนร่วมจากชุมชน, มีรอบการออกรุ่น, มี CI และมีร่องรอยว่าไม่ใช่ผลงานที่ใช้ความพยายามต่ำทำขึ้นในช่วงเวลาสั้น ๆ
• เกณฑ์เดิมที่ดูจากประวัติการพัฒนาและ สุขภาพของโปรเจ็กต์ เพียงอย่างเดียว ไม่ได้ช่วยลดภาระงานรีวิว และกลับเพิ่มข้อพิพาทเรื่องการตีความกฎ
• นโยบายใหม่ไม่ได้มุ่งห้ามทั้งแอป FOSS ที่พัฒนาเต็มที่ซึ่งใช้ LLM บางส่วน หรือแอป proprietary เดิมทั้งหมด แต่โฟกัสที่การกัน งานส่งแบบใช้ความพยายามต่ำ
• บางส่วนกังวลว่านี่อาจทำให้เกิด ความกระจัดกระจายของช่องทางแจกจ่าย ในระบบนิเวศ Flatpak อีกครั้ง และทำให้บริษัทหลีกเลี่ยง Flathub โดยมีข้อเสนอให้เก็บค่าธรรมเนียมแทนการแบนทั้งหมด

---

การเปลี่ยนนโยบายการส่งผลงานที่ใช้ LLM ของ Flathub

• ในการ ตรวจทานการส่งขึ้น Flathub มีการส่งงานคุณภาพต่ำที่อิงกับ LLM เพิ่มขึ้น ทำให้ภาระของผู้ตรวจทานอาสาสมัครสูงขึ้น ซึ่งเป็นเหตุผลหลักของการเปลี่ยนนโยบายครั้งนี้
• Sjoerd Stendahl มองว่าในรายการ PR ของ Flathub มีการส่งแบบ “AI-slop” จำนวนมาก และเมื่อดูจากขนาดของปัญหา มาตรการนี้อาจเป็นทางเลือกที่ดีกว่า
• Bart Piotrowski ระบุว่า หากโปรเจ็กต์มี การมีส่วนร่วมจากชุมชน, มีรอบการออกรุ่น, มี CI และมีร่องรอยว่าไม่ใช่ผลงานคุณภาพต่ำที่ทำขึ้นอย่างเร่งรีบ ก็มีแนวโน้มสูงที่จะได้รับข้อยกเว้น
• ก่อนหน้านี้ก็พยายามกันงานส่งคุณภาพต่ำโดยดูจากประวัติการพัฒนาที่เพียงพอและ สุขภาพของโปรเจ็กต์ โดยรวม แต่สุดท้ายไม่ได้ช่วยลดภาระงานรีวิว และมีแต่สร้างข้อพิพาทเรื่องการตีความกฎ

ข้อยกเว้นและเกณฑ์ความเป็นโปรเจ็กต์ที่เติบโตเต็มที่

• Nexi มองว่าปัญหาการส่งขึ้น Flathub แบบใช้ความพยายามต่ำมีอยู่จริง แต่การห้ามโค้ดที่สร้างด้วย AI หรือมี AI ช่วยทั้งหมดแบบเหมารวมนั้นรุนแรงเกินไป
• หากโปรเจ็กต์เดิมอย่าง Firefox, VSCode และ Chromium อาจถูกลบโดยไม่มีข้อยกเว้น เขาเสนอว่าควรใช้ ตัวชี้วัดเชิงวัตถุวิสัยของความเป็นโปรเจ็กต์ที่เติบโตเต็มที่ เพื่อคัดกรองงานส่งคุณภาพต่ำแทน
• Bart Piotrowski ตอบว่าเกณฑ์ด้านความเติบโตเต็มที่นั้นมีอยู่โดยพฤตินัยแล้ว แต่ในทางปฏิบัติก็ไม่ได้ช่วยลดภาระการรีวิว
• Nexi มองว่าควรสะท้อนเกณฑ์ข้อยกเว้นให้ชัดในนโยบาย และอาจระบุเพิ่มเติมได้ด้วยว่า หากคุณภาพโค้ดต่ำเกินไป ก็อาจถูกปฏิเสธได้โดยไม่ต้องมีคำอธิบายเพิ่มเติม
• Sjoerd Stendahl มองว่านโยบายใหม่นี้เปิดข้อยกเว้นให้กับ โปรเจ็กต์ที่เติบโตเต็มที่และได้รับการดูแลอย่างดี และไม่ได้เป็นนโยบายที่มุ่งแบนทั้งแอปพลิเคชัน FOSS ที่ผ่านการพิสูจน์แล้วซึ่งใช้ LLM บางส่วน หรือแอปพลิเคชัน proprietary เดิมทั้งหมด

ผลกระทบต่อระบบนิเวศและความกังวลเรื่องช่องทางแจกจ่าย

• Dmitry Mantis กังวลว่านโยบายนี้อาจทำให้เกิด ความกระจัดกระจายของช่องทางแจกจ่าย บน Linux อีกครั้ง ซึ่ง Flatpak เดิมตั้งใจจะแก้ปัญหานี้
• การที่แอป proprietary อย่าง Slack และ Spotify มีให้ใช้บน Flathub ในรูปแบบ sandbox ถือเป็นข้อดี และยังมีการตั้งคำถามว่าโค้ดแบบปิดอาจกลับได้เปรียบหรือไม่ เพราะไม่มีทางรู้วิธีที่มันถูกพัฒนาขึ้นมา
• ก็มีข้อโต้แย้งเช่นกันว่า แอป proprietary จากนักพัฒนาหน้าใหม่ที่ยังไม่เป็นที่รู้จัก ก็คงไม่ควรถูกเผยแพร่บน Flathub ทันทีอยู่แล้ว แม้ไม่มีนโยบายนี้
• กระแสที่บางแอปซึ่งเดิมใช้แค่ AppImage เริ่มรองรับ Flatpak อย่างเป็นทางการถือเป็นสัญญาณที่ดี แต่ก็มีความกังวลว่าหลังนโยบายนี้ บริษัทต่าง ๆ อาจหลีกเลี่ยงการเข้ามาบน Flathub
• ยังมีข้อเสนอว่าการเก็บ ค่าธรรมเนียม เพื่อนำไปชดเชยต้นทุนการรีวิวสำหรับงานส่งที่อิงกับ AI น่าจะดีกว่าการแบนทั้งหมด
• นี่อาจกลายเป็นสัญญาณให้ไปแจกจ่ายที่อื่นก่อนจนกว่าจะมีผู้ใช้ถึงระดับหนึ่ง และหากแอปที่ได้รับการดูแลอย่างดีซึ่งใช้ LLM เพียงบางส่วนในงานทดสอบหรือทำเอกสารอัตโนมัติไปตั้งหลักบนช่องทางแจกจ่ายอื่นแล้ว แรงจูงใจในการย้ายมา Flathub ก็อาจลดลง

มุมมองที่แตกต่างต่อเครื่องมือ LLM

• Thomas Fuchs มองว่าปัญหา LLM ใกล้เคียงกับปัญหาเรื่อง ผู้คนและการตลาด มากกว่าตัวเทคโนโลยีเอง
• เขาชี้ว่าบริษัท LLM ขาย LLM ราวกับเป็นเวทมนตร์หรือทาสแรงงานส่วนตัว และปัญหาคือผู้ใช้จำนวนมากเชื่อคำกล่าวอ้างนั้นตรง ๆ
• หากผู้ใช้ที่มีทักษะรู้จุดแข็งจุดอ่อนและใช้กับงานเฉพาะทาง มันอาจเป็นเครื่องมือที่ยอดเยี่ยมได้ แต่เขาอธิบายว่าอุตสาหกรรมกลับโหมโปรโมตมันอย่างดุดันราวกับ “แจกเลื่อยยนต์ติดไฟฟรีไว้สำหรับการเล่นโยนรับ”
• Wolkensteine ไม่ได้มองว่า LLM ไร้ประโยชน์โดยสิ้นเชิง แต่เห็นว่าในกรณีส่วนใหญ่มันไม่ค่อยมีประโยชน์ และตอนนี้ก็ยังไม่มีโมเดลที่ทั้งมีประโยชน์และถูกสร้างขึ้นในแบบที่เขาอยากสนับสนุนในเชิงจริยธรรม
• โมเดล on-device อาจช่วยเรื่องตรวจสะกดหรือการคาดเดาคำในการแก้ไขอัตโนมัติบนคีย์บอร์ดมือถือได้ แต่สิ่งที่มันทำได้โดยไม่มีข้อผิดพลาดนั้น โดยมากแล้วมนุษย์ก็ทำเองได้ง่ายและยังได้เรียนรู้ไปด้วย
• Ember มองว่าแม้แต่กรณีใช้งานที่อาจมีศักยภาพเหล่านั้นก็ทำได้ด้วยเครื่องมือก่อนยุค generative AI อยู่แล้ว และในบางกรณีที่พบไม่บ่อย ML แบบเฉพาะทางที่ฝึกจากข้อมูลเฉพาะอาจเหมาะกว่า
• Kroc Camen ยืนยันว่า LLM ไม่มีการใช้งานที่ชอบธรรมในที่ใดเลย เพราะปัญหาเรื่องการขโมยโค้ด อคติที่ฝังอยู่ และผลกระทบต่อสิ่งแวดล้อม

วัฒนธรรมชุมชนและความเป็นขั้วของข้อถกเถียง

• trisweb มองว่าวัฒนธรรมรอบโค้ดที่สร้างด้วย LLM และผู้ใช้งานมัน มักไม่สอดคล้องกับแนวทางที่เป็นมิตรและร่วมมือกันซึ่งจำเป็นต่อการรักษาชุมชนโอเพนซอร์ส
• ragectl มองว่าแอปใหม่อาจต้องมีแนวคิดคล้าย ช่วงพักรอดูสถานการณ์ และจนกว่าจะผ่านหลายรุ่นและมีผู้ร่วมพัฒนาที่เป็นมนุษย์คนที่สองเกิดขึ้น ก็น่าจะยังมีความเสี่ยงสูง
• Sjoerd Stendahl มองว่าต้องระวังการล่าแม่มด แต่การผลักดัน LLM อย่างก้าวร้าวจากบิ๊กเทคก็กำลังยิ่งทำให้ผู้คนต่อต้านมากขึ้น
• มีนายจ้างบางรายบังคับให้ใช้ LLM ในการทำงานพร้อมกับขู่เลิกจ้าง ฟังก์ชันง่าย ๆ อย่างการค้นหาก็พังไปแล้ว และเขาอธิบายว่า “Agentic future” มีความต้องการจริงแคบมาก ทั้งที่หลายผลิตภัณฑ์กลับกลายสภาพเป็นเหมือนเศษซากที่เลียนแบบงานของมนุษย์
• razze มองว่าปัญหาการใช้ LLM กับการค้นหาหรือแชตบอตนั้นเป็นอีกเรื่องหนึ่งจากการใช้กับโค้ด เพราะโค้ดพิสูจน์ได้และมี trade-off ที่ชัดเจน จึงควรถูกประเมินแยกกัน
• Zeeshan Ali Khan ชี้ถึงความก้าวร้าวของฝ่ายต่อต้าน LLM และ Bart Piotrowski ตอบว่าทั้งฝั่ง pro-LLM และ anti-LLM ต่างก็มีภาวะสุดโต่งสูง โดย “vibecoders” เองก็ชอบทำตัวเหมือนเป็นเหยื่อเมื่อถูกวิจารณ์

[GN⁺]

ความเห็นจาก Lobste.rs

• ข้อความที่ว่า "ไม่อนุญาตแอปพลิเคชันที่มีโค้ด เอกสาร หรือคอนเทนต์อื่น ๆ ที่ AI สร้างขึ้นหรือช่วยสร้าง" ดูค่อนข้างแข็งกร้าวทีเดียว
  Flathub เป็นแหล่งยอดนิยมมากที่ผู้ใช้เดสก์ท็อป Linux ใช้ดาวน์โหลดแอป และเรียกตัวเองว่าเป็น "app store สำหรับ Linux" โดยมีแอปมากกว่า 1000 ตัว
  นี่หมายความว่าจริง ๆ แล้วในบรรดาแอปเหล่านั้นจะไม่มีแม้แต่ตัวเดียวที่ใช้โค้ดที่มี AI ช่วยเลยหรือ? มันสมจริงหรือ? หรือว่าสายเกินไปแล้ว?

  • เมื่อดูจากถ้อยคำที่ว่า "อาจอนุญาตข้อยกเว้นสำหรับโครงการที่เติบโตเต็มที่และมีการดูแลรักษาอย่างดี" ก็ดูเหมือนว่าตั้งใจจะป้องกันไม่ให้มีการอัปโหลดโครงการที่ทำแบบ vibe coding ล้วน ๆ แล้วปล่อยทิ้งมากกว่า
  • ไม่มีคำว่าสายเกินไป
    แม้แต่โครงการที่ขึ้น FlatHub ไปแล้ว ถ้าถูกเปิดเผยว่าเป็นงาน vibe coding ก็ยังถอดออกได้ และยังส่งสารที่ชัดเจนได้ด้วย
  • กฎนี้น่าจะต้องมองว่าเป็นสิ่งที่บังคับใช้ตามดุลยพินิจ
    แอปหลักที่มีอยู่เดิมบางตัวอาจได้รับการยกเว้น และถึงอย่างนั้นข้อจำกัดก็น่าจะถูกใช้กับ การแพ็กเกจแบบ flatpak ที่แยกออกมาต่างหาก มากกว่ากับโค้ดของแอปเอง

• แม้แนวทางที่แข็งกร้าวแบบนี้จะบังคับใช้ได้ไม่ 100% แต่ในสถานการณ์ที่บริษัทต่าง ๆ กำลังผลักดัน การนำ LLM มาใช้ อย่างหนัก ชุมชนก็คงต้องการจุดยืนที่แข็งแรงแบบนี้ในฐานะการต่อต้านขั้นต่ำที่พอทำได้

• เมื่อนึกถึงเหตุการณ์ด้าน ซัพพลายเชน ช่วงหลัง ๆ ก็ฟังดูเป็นการตัดสินใจที่มีเหตุผลไม่น้อย

• ไม่ว่าโปรเจกต์จะห้าม LLM หรือห้ามคนผมหงอก หรือห้ามคนที่สูง 160 ซม. เป๊ะ ๆ ผมก็สนับสนุนเสรีภาพที่จะกำหนดกติกาเองแบบ 100%
  ไม่ได้หมายความว่าอยากจำกัดเสรีภาพนั้น แต่การดูแลแพ็กเกจเป็นงานซ้ำ ๆ แบบคลาสสิกที่ได้ประโยชน์จากความช่วยเหลือของ LLM มาก
  ผมก็พอเข้าใจคนที่มองว่าโค้ดของตัวเองเป็นงานศิลปะบริสุทธิ์หรือเป็นงานเชิงช่างฝีมืออยู่บ้าง แต่ทำไมถึงไม่ปล่อยให้งานที่น่าเบื่อที่สุดถูกทำให้อัตโนมัติล่ะ?

  ผมยังจำได้ว่าช่วงแรก ๆ หลังจาก AUR ของ Arch Linux เริ่มต้น มีคนที่ดูแลแพ็กเกจหลายร้อยตัวได้สำเร็จ
  มันอัปเดตอยู่เสมอและแทบไม่พังเลย ซึ่งแน่นอนว่าพวกเขาคงทำให้อัปเดตอัตโนมัติอยู่แล้ว
  ถ้าทำสิ่งเดียวกันในทุกวันนี้ด้วย ความช่วยเหลือจาก LLM ก็แทบจะแน่นอนเลยว่าน่าจะทำให้แข็งแรงยิ่งขึ้นได้

  บางทีเราอาจต้องแบนมนุษย์ไปเลยก็ได้
  นอกจากการโจมตีซัพพลายเชนแล้ว มนุษย์มีอะไรจะช่วยได้อีก? สักวันผมน่าจะลองทำ ดิสโทร LLM เพื่อพิสูจน์ว่าความเห็นของผมถูกหรือผิด
  แต่ก่อนหน้านั้นคงต้องทำภาษาโปรแกรมนี้ให้เสร็จก่อน ฮา