Human Emacs

 (human-emacs.org)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Human Emacs คือคำประกาศของผู้เข้าร่วมว่าจะใช้และพัฒนา Emacs ที่ไม่รับ contribution ที่สร้างโดย LLM ไม่ว่านโยบายสุดท้ายของ GNU จะเป็นอย่างไร
  • การห้ามในปัจจุบันของ GNU Emacs เป็นเพียงมาตรการชั่วคราวเชิงป้องกัน ซึ่งจะคงไว้จนกว่าจะสรุป นโยบายร่วมของ GNU ที่จะใช้กับแพ็กเกจ GNU ทั้งหมด
  • หาก GNU อนุญาต contribution ที่สร้างโดย LLM ก็มีแผนจะดูแลรักษา Emacs ที่ไม่ใช้ LLM แยกต่างหาก แม้ต้องยอมรับความขัดแย้งแบบที่เคยเกิดกับ fork ของ Emacs ในอดีตและโอกาสสำเร็จที่ต่ำ
  • ประสิทธิภาพของ LLM หรือโมเดลแบบ open weights ไม่ใช่ประเด็นหลัก และเห็นว่า แพตช์ที่สร้างโดย LLM ซึ่งปกปิดแหล่งที่มาสามารถจัดการได้ด้วยวิธีเดียวกับกรณี plagiarism ที่มีอยู่เดิม
  • แม้นโยบายร่วมของ GNU จะอนุญาต ผู้ดูแล Emacs ก็ยังสามารถวางนโยบายเพิ่มเติมที่เข้มงวดกว่าได้ จึงมีจุดยืนว่าสามารถทำให้ การห้ามชั่วคราวกลายเป็นถาวร ได้

เหตุผลที่ Emacs กังวลต่อนโยบายร่วมของ GNU

  • Emacs เป็น โครงการซอฟต์แวร์เสรี ที่เสริมพลังให้ผู้ใช้โดยไม่บั่นทอนหลักการทางจริยธรรม และผู้เข้าร่วมต้องการให้ยังสามารถใช้งานและมีส่วนร่วมด้วยเจตนาดีต่อไปได้
  • ผู้เข้าร่วมมองว่าในปี 2026 โครงการซอฟต์แวร์ที่พวกเขาไว้วางใจเริ่มนำการพัฒนาบนฐาน LLM มาใช้ต่อเนื่องกัน
    • ประเมินว่า Vim และ rsync ก็ยอมรับการพัฒนาบนฐาน LLM อย่างแข็งขัน จนทำให้กลุ่มผู้ใช้หลักรู้สึกถูกทอดทิ้ง
    • ยก vim-classic เป็นตัวอย่าง fork ที่เกิดขึ้นจากผลลัพธ์ดังกล่าว
  • ผู้นำของ GNU Emacs ปัจจุบัน ไม่รับ contribution ที่สร้างโดย LLM
    • ตาม การอภิปรายใน emacs-devel นี่เป็นมาตรการป้องกันที่คงไว้จนกว่าโครงการ GNU จะกำหนดนโยบายที่จะใช้กับแพ็กเกจ GNU ทั้งหมด
    • มีจุดยืนว่านี่ไม่ใช่การตัดสินใจเฉพาะของโครงการ Emacs แต่เป็นเรื่องที่ต้องกำหนดในระดับ GNU ทั้งหมด
  • ผู้เข้าร่วมกังวลว่านโยบายของ GNU ในอนาคตอาจไม่ถึงมาตรฐานจริยธรรมระดับสูงที่ GNU เคยรักษามาในอดีต
    • แม้มองว่าผลกระทบภายนอกเชิงลบของ LLM มีมาก แต่ทิศทางนโยบายที่ชัดเจนยังไม่ออกมา และกังวลว่านโยบายสุดท้ายอาจไม่สามารถป้องกันปัญหาที่เกี่ยวข้องได้

แนวทางดูแล Emacs ที่ไม่มี contribution จาก LLM

  • ไม่ว่า GNU จะเลือกนโยบายใด ก็มีแผนจะใช้และพัฒนา Emacs ที่ไม่มี contribution ที่สร้างโดย LLM
    • หาก GNU ตัดสินใจแบบเดียวกันโดยคำนึงถึงต้นทุน ก็จะสนับสนุนต่อไป
    • หาก GNU ตัดสินใจต่างออกไป ก็จะดูแลรักษาเวอร์ชันแยก แม้ผลลัพธ์นั้นจะไม่ใช่ GNU Emacs ก็ตาม
  • ในอดีต fork ของ Emacs ก่อให้เกิดข้อถกเถียงอย่างมาก และไม่ได้ประสบความสำเร็จเสมอไป ผู้เข้าร่วมจึงไม่ได้มอง ความเป็นไปได้ของการ fork อย่างเบาใจ
  • อย่างไรก็ตาม หาก GNU Emacs อนุญาต contribution ที่สร้างโดย LLM ก็เห็นว่ามีตัวเลือกไม่มากนัก
    • สำหรับผู้เข้าร่วมจำนวนมาก การเลิกใช้ Emacs คล้ายกับการเลิกใช้คอมพิวเตอร์ทั้งหมด หรือเลิกส่วนที่ทำให้การใช้คอมพิวเตอร์มีความสนุก
  • แม้นโยบายระดับบนของ GNU จะไม่จัดการปัญหานี้ ผู้ดูแล Emacs ก็สามารถจัดทำ นโยบายเพิ่มเติม ทับขึ้นไปได้
    • มีจุดยืนว่าสามารถเปลี่ยนการห้ามชั่วคราวในปัจจุบันให้เป็นนโยบายถาวรได้ ตราบเท่าที่ไม่ขัดกับนโยบายร่วมของ GNU

เหตุผลในการปกป้องซอฟต์แวร์ที่มนุษย์สร้างขึ้น

  • เอกสารฉันทามติของ Guix Standing up for human crafting อธิบายอย่างละเอียดว่าทำไมโปรแกรมที่มีการพึ่งพาสูงอย่าง Emacs จึงต้องมีนโยบายเช่นนี้
  • ผู้เข้าร่วมเห็นว่าความเสียหายจาก LLM ชัดเจนเพียงพอแล้ว จึงใช้เอกสารนี้เป็นแหล่งอ้างอิงแทนการแจกแจงเหตุผลเดิมซ้ำ
  • อย่างไรก็ตาม ประเมินว่า Guix ไม่ได้จัดทำ มาตรการห้ามชั่วคราว ไว้ก่อนเหมือน Emacs จึงจำเป็นต้องเหลือข้อยกเว้นบางส่วนไว้ในนโยบาย

ประเด็นที่ไม่นำมารวมในการอภิปรายหลัก

  • ประสิทธิภาพของ LLM

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

  • โมเดลแบบ open weights

    • โมเดลแบบ open weights ก็ไม่ถูกนำมาพิจารณาเป็นทางเลือกเช่นกัน
    • มองว่าโมเดลเหล่านี้ก็ถูกสร้างขึ้นบนฐานที่บริษัทต่าง ๆ รวบรวมข้อมูลเว็บอย่างทำลายล้างผ่านศูนย์ข้อมูล และสร้างความเสียหายต่อชุมชนท้องถิ่น
    • จะอภิปรายได้ก็ต่อเมื่อผู้ใช้ปลายทางสามารถฝึกทั้งโมเดลได้เองด้วยข้อมูลที่เก็บรวบรวมโดยได้รับความยินยอมแล้วเท่านั้น และในปัจจุบันถือว่าเป็นเรื่องในขอบเขตของจินตนาการและการคาดเดา

  • contribution ที่ปกปิดแหล่งที่มาของแพตช์

    • ความเป็นไปได้ที่ผู้ร่วมพัฒนาที่ประสงค์ร้ายจะซ่อนแหล่งที่มาของแพตช์ก็ไม่ได้ถือเป็นประเด็นแยกต่างหาก
    • ความเสี่ยงที่ผู้ร่วมพัฒนาจะหลอกลวงเรื่องไลเซนส์หรือลิขสิทธิ์ของแพตช์มีอยู่มาก่อนแล้ว
    • เห็นว่าเพียงจัดการ แพตช์ที่สร้างโดย LLM ด้วยวิธีเดียวกับ plagiarism รูปแบบอื่นก็เพียงพอ

การเข้าร่วมอภิปรายและการดำเนินงาน

  • การอภิปรายดำเนินอยู่ใน เมลลิงลิสต์ และช่อง #human-emacs บน Libera Chat
    • สามารถส่งข้อความได้แม้ไม่ได้สมัครเมลลิงลิสต์
  • หากต้องการเพิ่มชื่อและ URL ที่เป็นทางเลือกลงในลายเซ็น ให้โพสต์ในเมลลิงลิสต์หรือร้องขอในช่อง #human-emacs
  • ซอร์สโค้ด ของเว็บไซต์ก็เปิดเผยต่อสาธารณะด้วย

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 시간 전
ความเห็นจาก Lobste.rs

  • แม้ผมจะไม่ใช่ผู้ใช้ Emacs แต่พอเห็นคำประกาศที่แน่วแน่ว่าจะปกป้องเครื่องมือพัฒนาหลักจาก ผลงานที่สร้างโดย AI คุณภาพต่ำ และเหล่าผู้สนับสนุน ก็รู้สึกอุ่นใจ

  • ความกังวลที่ว่านโยบายของ GNU ในอนาคตอาจไม่สามารถรักษา มาตรฐานทางจริยธรรมระดับสูง ที่ยึดถือมาในอดีตไว้กับ Emacs ได้นั้น เกิดขึ้นได้อย่างไร? สุดท้ายแล้ว GNU กำลังจะอนุญาตให้ใช้ LLM ซึ่งส่วนใหญ่เป็นโมเดลที่ไม่เสรี ในซอฟต์แวร์ของตนหรือไม่?

    • เป็นคำถามที่สมเหตุสมผลมาก ในกรณีนี้ การตอบสนองที่ถูกต้องนั้นชัดเจนและทำได้ง่ายมาก แต่ข้อเท็จจริงที่ว่า GNU ยังไม่ได้ลงมือทำก็ดูเหมือนเป็น สัญญาณอันตรายแรก แล้ว
      ในโปรเจกต์ GNU อื่น ๆ ก็มีแรงต่อต้านอย่างมากต่อนโยบายที่ตั้งอยู่บนพฤติกรรมเชิงจริยธรรม และแม้แต่ Guix ซึ่งเป็นหนึ่งในโปรเจกต์ GNU ที่ผู้คนไว้วางใจผู้นำมากที่สุด ก็ยังอยู่ระหว่างหารือแนวทางรับมือ: https://codeberg.org/guix/guix-consensus-documents/pulls/13
      ในอดีต GNU มักจดจ่ออย่างสายตาสั้นอยู่กับไลเซนส์และลิขสิทธิ์ แม้ต้องแลกกับปัจจัยอื่นทั้งหมดก็ตาม หากผู้สนับสนุน LLM สร้างเหตุผลขึ้นมาได้ว่าไม่มีปัญหาในแง่ไลเซนส์ ก็เป็นกังวลว่า GNU อาจไม่ถกประเด็นอีกมากมายที่อยู่ไกลกว่านั้นอีกต่อไป
      แน่นอนว่า GNU อาจตัดสินใจได้ถูกต้องจนการเตรียมการทั้งหมดนี้ไม่จำเป็น และนั่นคือผลลัพธ์ที่ดีที่สุดที่เราหวังไว้
    • ดูเป็นไปได้ต่ำ จากที่ได้ยินมาจากคนของ FSF พวกเขากำลังจัดการเรื่องนี้อย่างระมัดระวังมาก
      ในปรัชญาของ GNU อย่างน้อยในเชิงชัดแจ้ง LLM ไม่ใช่ประเด็นทางจริยธรรม และนักพัฒนาซอฟต์แวร์เสรีจำนวนมากก็คัดค้าน LLM ด้วยเหตุผลทางจริยธรรมแยกต่างหาก ความกังวลที่ตรงกว่านั้นคือโค้ดที่สร้างโดย LLM อาจไม่ได้รับความคุ้มครองลิขสิทธิ์ ทำให้ copyleft เป็นโมฆะได้
      เราเห็นโปรเจกต์จำนวนมากเกินไปยอมรับ LLM ไปแล้ว จึงจำเป็นต้องเตรียมรับมือก่อนที่มันจะเกิดขึ้นจริง

  • แม้จะบอกว่า rsync นำ LLM มาใช้อย่างจริงจัง แต่ช่วงหลังไม่ได้อ่านเจอหรือว่า contribution ต่อ rsync ถูกปฏิเสธเพราะมีร่องรอยเฉพาะแบบ LLM?

    • ดูเหมือนจะสับสนกับโปรเจกต์อื่น ในโพสต์ล่าสุด ไม่พบเนื้อหาแบบนั้น แต่ยืนยันได้ว่า rsync ใช้ LLM

  • เนื่องจาก Emacs ยังไม่รับ contribution ที่สร้างโดย LLM จนกว่า GNU จะตัดสินใจ คำประกาศนี้จึงดูเหมือนล้ำหน้าไปหน่อย

    • หน้านั้นก็เขียนขึ้นบนสมมติฐานข้อเท็จจริงนี้ และกล่าวถึงโดยตรงแถว ๆ ย่อหน้าที่สาม

  • LLM สามารถ พัฒนา Emacs ให้ก้าวหน้า ในส่วนที่ก่อนหน้านี้ปรับปรุงได้ยาก มีตัวอย่างมาแล้วที่ช่วยปรับปรุงบั๊กที่ซับซ้อนมากและเลเยอร์ abstraction ซึ่งเดิมต้องใช้แรงงานจำนวนมาก

    • แรงจูงใจของความเคลื่อนไหวนี้อยู่ที่ จริยธรรม ล้วน ๆ
      ตามที่ระบุไว้ในส่วน ‘สิ่งที่ไม่อยู่ในการถกเถียง’ ประเด็นไม่ได้อยู่ที่ว่า LLM มีประสิทธิผลตามที่กล่าวอ้างหรือไม่ แก่นสำคัญคือการใช้ LLM สามารถเป็นส่วนหนึ่งของขบวนการซอฟต์แวร์ที่มีหลักการซึ่งมุ่งเสริมอำนาจให้ผู้ใช้ได้หรือไม่