MALUS - Clean Room as a Service ที่ปลดแอกจากการระบุลิขสิทธิ์โอเพนซอร์ส

 (malus.sh)
4 คะแนน โดย GN⁺ 2026-03-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หุ่นยนต์ AI สร้างโครงการโอเพนซอร์สขึ้นใหม่อย่างอิสระ เพื่อมอบโค้ดที่แยกขาดทางกฎหมายและไลเซนส์ที่เป็นมิตรต่อองค์กร
  • เขียนซอฟต์แวร์ใหม่ที่มีฟังก์ชันเหมือนกันโดย วิเคราะห์เฉพาะเอกสาร, API และ type definition โดยไม่ดูโค้ดต้นฉบับ
  • ผลลัพธ์ถูกเผยแพร่ภายใต้ ไลเซนส์ MalusCorp-0 ซึ่งไม่มีภาระต้องระบุลิขสิทธิ์, เปิดเผยซอร์สโค้ด หรือแชร์การแก้ไข
  • ผู้ใช้เพียงอัปโหลดรายการ dependency เช่น package.json แล้วระบบจะ คำนวณราคาอัตโนมัติตามขนาดแพ็กเกจที่ $0.01/KB
  • มุ่งลดภาระการปฏิบัติตามไลเซนส์โอเพนซอร์ส และ ลดความเสี่ยงทางกฎหมายขององค์กรให้น้อยที่สุด

ปัญหาของโอเพนซอร์ส

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

ทางแก้: Robot-Powered Clean Room Recreation

  • ระบบสร้างใหม่แบบคลีนรูมด้วย AI วิเคราะห์เฉพาะเอกสารและสเปก API โดยไม่ดูโค้ดต้นฉบับเลย
    • หุ่นยนต์ฝั่งวิเคราะห์และหุ่นยนต์ฝั่งพัฒนาทำงานเป็น ทีมที่แยกขาดจากกัน จึงไม่เกิดการคัดลอกหรือผลงานดัดแปลง
  • ผลลัพธ์ถือเป็น โค้ดที่เป็นอิสระทางกฎหมาย และผู้ใช้เป็นเจ้าของได้ทั้งหมด
  • คุณสมบัติหลัก
    • โค้ดเขียนโดยหุ่นยนต์ 100%
    • การเปิดเผยโค้ดต้นฉบับ 0%
    • ได้ผลลัพธ์ที่มีฟังก์ชันเทียบเท่ากัน
    • เลือกไลเซนส์ที่เป็นมิตรต่อองค์กรได้
    • รับประกันการคุ้มครองทางกฎหมาย (ในนามบริษัทย่อยต่างประเทศ)

ขั้นตอน Liberation

  • ขั้นที่ 1: อัปโหลด manifest
    • อัปโหลดรายการ dependency เช่น package.json, requirements.txt, Cargo.toml
  • ขั้นที่ 2: วิเคราะห์แบบแยกขาด
    • หุ่นยนต์ตรวจดูเฉพาะ README, เอกสาร API และ type definition
  • ขั้นที่ 3: สร้างขึ้นใหม่อย่างอิสระ
    • ทีมหุ่นยนต์อีกชุดหนึ่งเขียนโค้ดใหม่จากสเปก
  • ขั้นที่ 4: ปลดแอกไลเซนส์
    • ผลลัพธ์จะถูกส่งมอบภายใต้ MalusCorp-0 License
      • ตัดภาระโอเพนซอร์สเดิมทิ้ง (การระบุข้อความ, การแชร์การแก้ไข, การเปิดเผยซอร์สโค้ด ฯลฯ)
      • ผู้ใช้ไม่มีข้อจำกัดในการแก้ไข, แจกจ่าย หรือใช้งานเชิงพาณิชย์

นโยบายราคา

  • คิดค่าบริการตามขนาด: ขนาดแตกไฟล์ของแพ็กเกจ npm (KB) × $0.01
    • ยอดสั่งซื้อขั้นต่ำ $0.50
    • ตัวอย่าง: lodash(1.3MB) → $13.78, moment(4.1MB) → $42.48
  • สิ่งที่รวมอยู่ในบริการ
    • การสร้างใหม่แบบ AI คลีนรูมและไลเซนส์ MalusCorp-0
    • เอกสารสเปก CSP 10 รายการ
    • รองรับแพ็กเกจขนาดสูงสุด 10MB และสั่งได้สูงสุด 50 แพ็กเกจ
    • ไม่มีค่าสมาชิก จ่ายเท่าที่ปลดแอกเท่านั้น

การรับประกันและกรณีตัวอย่าง

  • MalusCorp Guarantee™: หากเกิดการละเมิด จะคืนเงินเต็มจำนวนและย้ายสำนักงานใหญ่ (สู่น่านน้ำสากล)
  • กรณีสำเร็จ
    • ปลดแอก dependency แบบ AGPL 847 รายการใน 3 สัปดาห์ และระหว่างกระบวนการซื้อกิจการมีปัญหาไลเซนส์เป็น ‘0’
    • ลดค่าใช้จ่ายที่ฝ่ายกฎหมายประเมินไว้ 4 ล้านดอลลาร์ เหลือ 5 หมื่นดอลลาร์
    • สร้างแพ็กเกจ npm ใหม่ 2,341 รายการ ทำให้ แดชบอร์ด compliance กลับมาเป็นปกติทันที

คำถามที่พบบ่อย

  • ความถูกกฎหมาย: เป็นการสร้างขึ้นใหม่อย่างอิสระโดยไม่ดูโค้ดต้นฉบับ และอิงตามบรรทัดฐานทางกฎหมาย
  • มีการตอบแทนนักพัฒนาเดิมหรือไม่: การเผยแพร่เป็นโอเพนซอร์สเป็นทางเลือกของพวกเขาเอง จึงไม่มีภาระต้องจ่ายค่าตอบแทนเพิ่มเติม
  • ต่างจากการคัดลอกอย่างไร: เป็นการพัฒนาให้ได้ฟังก์ชันเดียวกันอย่างอิสระ โดยเจตนาและกระบวนการต่างกัน
  • ถ้ามีบั๊ก: รับประกันเพียงความเทียบเท่าด้านฟังก์ชัน บั๊กเป็นความรับผิดชอบของผู้ใช้
  • จะเปิดเผยหุ่นยนต์หรือไม่: ไม่เปิดเผยที่ตั้ง แต่ลูกค้าองค์กรสามารถเข้าชมได้หลังลงนาม NDA
  • รองรับไลเซนส์ใดบ้าง: ปลดแอกได้ทุกไลเซนส์ เช่น MIT, Apache, GPL, AGPL, LGPL, BSD, MPL

การชำระเงินและการใช้งาน

  • หลังชำระเงินอย่างปลอดภัยผ่าน Stripe ระบบจะดำเนินการอัตโนมัติ
  • ใบเสนอราคาฟรี รองรับการชำระเป็น USD·EUR·BTC·stock options
  • ปิดท้ายบริการด้วยข้อความว่า “หากมีหุ่นยนต์มากพอ ภาระของโอเพนซอร์สก็เป็นเพียงข้อเสนอเท่านั้น”

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

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

 
GN⁺ 2026-03-13
ความเห็นจาก Hacker News

  • ระหว่างอ่าน บล็อก Malus.sh ก็เจอประเด็นที่น่าสนใจ นี่เป็นปัญหาที่รู้สึกมาหลายสิบปีแล้ว แต่ระบบกฎหมายก็ยังจัดการไม่ได้อยู่ดี นั่นคือปัญหาเรื่อง ต้นทุนการบังคับใช้ (costs matter)
    ยกตัวอย่าง แค่ตั้งป้ายจำกัดความเร็ว 55mph อย่างเดียวไม่พอ การใช้คนออกมาตรวจจับเป็นครั้งคราว กับการใช้หุ่นยนต์ตรวจจับได้สมบูรณ์แบบ เป็นนโยบายที่ต่างกันโดยสิ้นเชิง แม้ตัวบทกฎหมายจะเหมือนกัน แต่นโยบายที่เกิดขึ้นจริงกลับต่างกันมาก
    ในอดีตกฎหมายมักต่างกันระหว่าง de jure (ตามตัวบท) กับ de facto (ในทางปฏิบัติจริง) แต่ตอนนี้เทคโนโลยีทำให้สองอย่างนี้ตรงกันได้แล้ว ทว่าแทบไม่มีใครตระหนักว่าการเปลี่ยนแปลงนี้ใหญ่แค่ไหน ยิ่งบังคับใช้ได้ง่ายขึ้น ความหมายของกฎหมายก็ยิ่งเปลี่ยนไปโดยสิ้นเชิง หลายศตวรรษที่ผ่านมา กฎหมายถูกออกแบบภายใต้สมมติฐานว่า ‘การบังคับใช้นั้นยาก’ ดังนั้นการเอาไปทำอัตโนมัติแบบมืดบอดจึงเป็น ความคิดที่แย่สำหรับทุกคน
    สักวันหนึ่งในบรรทัดฐานทางกฎหมาย อาจมีวันที่ ‘ต้นทุนการบังคับใช้’ ถูกนำมาพิจารณาเป็นส่วนหนึ่งของการตัดสินความชอบด้วยกฎหมายก็ได้

    • ผมคิดว่าเราควรต้อนรับ การบังคับใช้กฎหมายที่แม่นยำขึ้น การบังคับใช้ที่ไม่สมบูรณ์นำไปสู่การเลือกบังคับใช้เป็นรายกรณี และนั่นทำให้ผู้บังคับใช้กฎหมายมีอำนาจเปลี่ยนกฎหมายตามอำเภอใจ แต่ยิ่งการบังคับใช้สมบูรณ์มากขึ้น กฎและบทลงโทษ ก็ต้องถูกปรับตามไปด้วย ไม่อย่างนั้นจะเกิดความปั่นป่วนทางสังคม กฎหมายเดิมถูกออกแบบให้เปลี่ยนช้าอยู่แล้ว แต่ตอนนี้อาจตามความเร็วไม่ทัน
    • Dean Ball พูดถึงประเด็นเดียวกันนี้ในรายการของ Ezra Klein เขาเคยคิดว่าการบังคับใช้ที่สมบูรณ์แบบจะนำความยุติธรรมมาให้ แต่ถ้าไม่มี แผนการย้ายผ่าน (migration plan) มันก็ไม่มีความหมายอะไรเลย AI สัญญาถึงอนาคตอันยอดเยี่ยม แต่ กระบวนการเปลี่ยนผ่าน ไปสู่จุดนั้นต่างหากที่ยากที่สุด
    • ปัญหานี้เกิดได้ทั้งสองทาง หน่วยงานรัฐหลายแห่งมีภาระตามกฎหมายที่ต้องตอบคำร้องเป็นลายลักษณ์อักษรของประชาชน แต่เมื่อก่อนคนแทบไม่เขียนจดหมายกันเลย ทว่าด้วย LLM ตอนนี้ใครก็สามารถร่างหนังสือราชการได้ง่ายมาก หากมี AI ที่เขียน ‘จดหมายร้องเรียน’ ให้อัตโนมัติขึ้นมา ระบบงานปกครองก็คงรับไม่ไหว
    • ถ้าอ่านงานของ Pamela Samuelson และ Suzanne Scotchmer (Yale Law Journal PDF) จะเห็นว่ากฎหมายลิขสิทธิ์เองก็เคยมอง ‘ทางอ้อมที่มีต้นทุน’ ในเชิงบวก กล่าวคือ การหลบเลี่ยงที่ฟรีทั้งหมดหรืออัตโนมัติเต็มรูปแบบไม่ใช่สิ่งที่พึงประสงค์ น่าสนใจที่ระบบกฎหมาย รับรู้นัยสำคัญของต้นทุน เอาไว้โดยปริยายอยู่แล้ว
    • ผมชอบมุมมองที่ว่า ‘ต้นทุนการบังคับใช้มีความสำคัญ’ มาก กฎหมายในศตวรรษที่ 18–19 ถูกสร้างขึ้นบนสมมติฐานว่ากำลังตำรวจมีจำกัด แต่ตอนนี้ เทคโนโลยีเฝ้าระวัง กำลังเปลี่ยนทุกอย่าง การบังคับใช้อย่างสมบูรณ์แบบย่อมก่อให้เกิด ต้นทุนด้านความเป็นส่วนตัว อย่างไรก็ตาม ยังมีข้อโต้แย้งกลับว่า การบังคับใช้อัตโนมัติอาจช่วยลดความไม่เป็นธรรมจากการเลือกบังคับใช้ได้

  • ตอนแรกผมไม่รู้ว่านี่เป็นงานเสียดสี แต่พอคิดดูดี ๆ มันอาจพัฒนาเป็น โมเดลคืนรายได้ให้ผู้พัฒนา OSS ก็ได้ เช่น สร้าง “clean room as a service” แต่ให้รายได้ไหลกลับไปยังผู้สร้างต้นฉบับ ไม่ใช่ Malus.sh โดยตรง OSS ทั้งหมดเปลี่ยนไปใช้ไลเซนส์แบบ AGPL แล้วบริษัทต่าง ๆ ก็จ้างทำ implementation แบบปรับแต่งเฉพาะโดยจ่ายเงินให้ อยากรู้เหมือนกันว่า MVP ของระบบแบบนี้จะหน้าตาเป็นยังไง

    • จริง ๆ แล้วเว็บนี้ไม่ใช่งานเสียดสี ใช้ Stripe จ่ายเงินได้ และมันสร้างโค้ดจริง ๆ เพียงแต่ถูกห่อด้วย ภาษาที่มีลักษณะเสียดสี เท่านั้น
    • ถ้านี่เป็นข้อเสนอจริงจัง ก็ทำได้อยู่แล้วผ่านแนวทาง dual licensing ที่มีอยู่ก่อนแล้ว ถ้าเป็นมุกก็ตลกดี แต่ถ้าพูดจริงก็อาจเป็นความเข้าใจที่คลาดเคลื่อนได้
    • จุดมุ่งหมายดั้งเดิมของ Copyleft คือการปกป้อง เสรีภาพ (freedom) ของซอฟต์แวร์ ข้อเสนอที่ล็อกโค้ดบางส่วนไว้ขัดกับหลักการนั้นตรง ๆ
    • ตอนแรกผมก็ไม่รู้ว่าเป็นงานเสียดสี แต่พอเห็นรีวิวปลอม ๆ ตรงท้ายเว็บก็รู้ทันที ประโยคอย่าง “ปลดปล่อย dependency AGPL 847 ตัวใน 3 สัปดาห์” นี่ฮามาก
    • โมเดลแบบนี้อาจเวิร์กก็ได้ ผู้พัฒนา OSS จะได้โฟกัสกับการพัฒนาอย่างเดียวโดยไม่ต้องสนใจ งานขายหรือที่ปรึกษา และไม่จำเป็นต้องพึ่งสปอนเซอร์จากบริษัทด้วย

  • ประโยคที่ว่า “ฉันรู้สึกผิดกับผู้ดูแลโอเพนซอร์ส แต่ความรู้สึกผิดไม่ได้สะท้อนอยู่ในผลประกอบการรายไตรมาส” นี่สมจริงเกินไป
    ◆ Chad Stockholder, ผู้อำนวยการฝ่ายวิศวกรรม Profit First LLC

    • ความสัมพันธ์ระหว่าง OSS กับซอฟต์แวร์เชิงพาณิชย์มักปะปนกันระหว่าง ความตึงเครียดทางศีลธรรม กับอุดมคติแบบไร้เดียงสาอยู่เสมอ

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

    • แม้จะเป็นงานเสียดสี แต่จริง ๆ แล้ว ไลเซนส์ FLOSS ไม่ได้บังคับให้ต้องเปิดเผยเมื่อใช้ภายในองค์กร ต่อให้ AI สร้าง implementation ใหม่ทั้งหมด การคุ้มครองด้วยลิขสิทธิ์ก็ยังไม่สมบูรณ์อยู่ดี
    • โปรเจ็กต์นี้จริง ๆ แล้วเป็นงานเสียดสีที่นำเสนอในงาน FOSDEM และผู้เขียนก็เป็นคนจากชุมชนโอเพนซอร์สด้วย

  • ตอนแรกผมไม่รู้ว่าเป็นงานเสียดสี แต่ในทางหนึ่งมันก็สะท้อนความเป็นจริงของยุคนี้ โลกกำลังเปลี่ยนเร็วเกินไป

    • เว็บนี้จ่ายเงินผ่าน Stripe ได้จริง ดังนั้นแม้จะดูเป็นงานเสียดสี แต่มันก็เป็นบริการจริง
    • ตอนแรกผมก็ไม่รู้ว่าเป็นงานเสียดสี แต่พอเห็นรีวิวปลอมก็โล่งใจ อย่างน้อยตอนนี้มันยังไม่ใช่ความจริง
    • แต่พอเห็นชื่อว่า ‘Malus’ ก็เหมือนจะมารู้ทีหลังว่านี่คือการเสียดสี
    • จะชื่ออะไรก็ตาม เรื่องแบบนี้สุดท้ายก็น่าจะ กลายเป็นจริงได้ อยู่ดี

  • แนวคิด clean-room implementation แบบดั้งเดิมคือแยกทีมกัน ฝั่งหนึ่งเขียนสเปก อีกฝั่งทำ implementation แต่ LLM อาจเคยเรียนรู้โค้ดต้นฉบับมาแล้ว ถ้าอย่างนั้นประเด็นทางกฎหมายที่แท้จริงก็คือ “ตัวโมเดลเองคือห้องที่ปนเปื้อนหรือเปล่า?”

  • ถ้าดูกรณีจริงใน chardet issue #327 และ #331 จะเห็นว่ามีคนกำลังลองแนวทางแบบนี้อยู่

    • มีตัวอย่างที่โมเดล Opus 4.6 จำและสร้าง ซอร์สโค้ดทั้งหมด ของ chardet ขึ้นมาใหม่ได้โดยไม่ต้องเข้าถึงเว็บ (ลิงก์ gist)
    • นักพัฒนาคนหนึ่งที่ดูแลโปรเจ็กต์นี้มากว่า 10 ปี พยายามทำ การ reimplement ภายใต้ไลเซนส์ MIT แต่กลับถูกชุมชนตำหนิ เรื่องนี้น่าเศร้ามาก
    • นี่เป็นกรณีสำคัญมากจนควรแยกไปถกเป็นหัวข้อเฉพาะต่างหาก

  • ประโยคที่ว่า “ถ้าโค้ดของเราถูกตัดสินว่าเป็นการละเมิด เราจะคืนเงินเต็มจำนวนและย้ายสำนักงานใหญ่ไปยังน่านน้ำสากล” เป็น งานเสียดสีระดับอัจฉริยะ จริง ๆ เหมือนทำนายอนาคตไว้ล่วงหน้า

    • ความสมบูรณ์ของงานเสียดสีสูงมาก ตอนแรกดูเหมือนของจริง แต่พออ่านไปเรื่อย ๆ จะเห็น เบาะแสที่จงใจซ่อนไว้ ทั่วไปหมด และยิ่งน่ากลัวตรงที่มันอาจกลายเป็นความจริงได้

  • ผมรู้จักแนวคิด “คลีนรูม” ครั้งแรกจาก ฐานข้อมูลสถิติเบสบอล ข้อมูลทางการอาจใช้ฟรี แต่รูปแบบและโครงสร้างของมันอาจมีลิขสิทธิ์อยู่ แฟน ๆ จึงสร้างข้อมูลขึ้นใหม่อย่างอิสระ เกมอย่าง Baseball Mogul ก็เคยใช้แนวทางนี้ คิดว่าในอนาคตเราน่าจะเห็นความพยายามแบบ การสร้างใหม่อย่างอิสระ เพิ่มขึ้นอีกมาก

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

    • จริง ๆ แล้วทุกคนใช้ LLM รุ่นใหม่ได้อยู่แล้ว จึงไม่มีเหตุผลมากนักที่จะต้องจ่ายเงินให้บุคคลที่สามมาทำ “clean-room implementation” ให้ มูลค่าที่แท้จริงน่าจะอยู่ที่ wrapper ที่รับความเสี่ยงทางกฎหมายแทน มากกว่า
    • โลกนี้มีโอกาสให้ทำเรื่องไม่ดีได้มากมาย แต่คนส่วนใหญ่ก็ยังมี ข้อจำกัดทางศีลธรรม ของตัวเองอยู่ เพียงแต่เมื่อไอเดียแบบนี้ถูกเผยแพร่ออกไป มันก็อาจเพิ่มความพยายามเลียนแบบแบบ copycat crime ได้
    • ที่จริงเรื่องแบบนี้เกิดขึ้นแล้ว นักพัฒนาอาจสั่ง AI ว่า “ช่วยทำฟีเจอร์นี้ให้หน่อย แล้วดู GitHub repo นี้ประกอบด้วย” ซึ่งนำไปสู่ การ reimplement โดยไม่ตั้งใจได้
    • ปัญหาคือ ความเชื่อถือและความปลอดภัย ถ้าต้องมอบความลับของบริษัทให้ SaaS ดูแล ผมคิดว่าใช้ AI แบบรันในเครื่องจะดีกว่า ตอนนี้ระบบลักษณะนั้นก็มีอยู่และถูกใช้งานอย่างจริงจังแล้ว
    • และในทางปฏิบัติ LLM ก็ยังไม่เก่งพอจะเขียน โค้ดที่ซับซ้อน ได้อย่างสมบูรณ์ ดังนั้นบริการแบบนี้จะให้ใช้งานได้จริงก็คงยาก