มาตรฐานสองชั้นของ Unity ต่อโอเพนซอร์ส: บล็อก VLC
(mfkl.github.io)- VLC for Unity เป็นการผสานรวมแบบโอเพนซอร์สที่เชื่อม Unity game engine กับ VLC multimedia engine และได้เผยแพร่ไบนารีแยกตามแพลตฟอร์มบน Unity Store มาตั้งแต่เดือนธันวาคม 2019
- หลังจากอีเมลจาก Unity ในช่วงปลายฤดูร้อนปี 2023 บัญชีผู้เผยแพร่ถูกบล็อกทันที และแม้จะเจรจากันหลายเดือน รวมถึงเสนอให้นำโค้ด LGPL ออกจากแพ็กเกจ ก็ยังไม่สามารถกลับขึ้น Store ได้
- บน Unity Store ยังมีแอสเซ็ตจำนวนมากที่รวม dependency แบบ LGPL เช่น FFmpeg อยู่ และ Unity Editor กับ runtime เองก็ใช้ไลบรารี LGPL อย่าง Lame, libiconv, libwebsockets, websockify.js
- หลังจากแอสเซ็ตถูกนำออก ลูกค้าสอบถามเรื่องการบำรุงรักษาและการอัปเดต build ทำให้ Videolabs เปิด Videolabs Store บนเว็บไซต์ของตนเอง เพื่อเริ่มขายไบนารีได้แม้ไม่ผ่าน Unity Store
- Videolabs Store ครอบคลุมทั้งไบนารีของปลั๊กอิน VLC Unity รวมถึง ระบบซัพพอร์ตเชิงพาณิชย์ สำหรับ LibVLC·FFmpeg, ไลเซนส์ LibVLCSharp, LibVLC ebook, Kyber และผลิตภัณฑ์ผสานรวมกับ Unreal ที่อยู่ในแผน
VLC for Unity ถูกบล็อกจาก Unity Store
- VLC for Unity คือ การผสานรวมแบบ bridge ที่ช่วยให้สร้าง media player ซึ่งใช้เอนจิน VLC ในเกมที่พัฒนาด้วย Unity ได้
- Unity มีความสามารถในการพกพาสูงผ่าน Mono ส่วน LibVLC เองก็พกพาได้สูงเช่นกัน การผสานรวมนี้จึงมุ่งรองรับการใช้งานแบบ cross-platform
- ไบนารีของการผสานรวมโอเพนซอร์ส VLC for Unity ถูกเผยแพร่บน Unity Store มาตั้งแต่เดือนธันวาคม 2019 โดยมีแพลตฟอร์มเป้าหมาย 3 รายการ
- Windows
- UWP
- Android
- หลัง Unity ส่งอีเมลในช่วงปลายฤดูร้อนปี 2023 บัญชีผู้เผยแพร่ ก็ถูกบล็อกทันที
- หลังจากนั้นมีการพยายามหาจุดประนีประนอมทางอีเมลเป็นเวลาหลายเดือน และแม้จะเสนอให้ นำโค้ด LGPL ออกจากแอสเซ็ต Unity ก็ยังไม่อนุญาตให้กลับขึ้น Store
- ได้รับคำตอบว่าแม้นำโค้ด LGPL ทั้งหมดออกจากแพ็กเกจ Unity ก็ยังกลับขึ้น Store ไม่ได้
- ปัจจุบันบน Unity Store ยังมีแอสเซ็ตตั้งแต่หลายร้อยถึงหลายพันรายการที่มี dependency แบบ LGPL เช่น FFmpeg
- Unity เองก็ใช้ dependency แบบ LGPL ใน Editor และ runtime ซึ่งส่งผลถึงเกมที่เผยแพร่ด้วย Unity ด้วย
- ไลบรารีตัวอย่างที่ระบุไว้ ได้แก่ Lame, libiconv, libwebsockets, websockify.js
- รายการ dependency โอเพนซอร์สทั้งหมดของ Unity ดูได้จากรายการแยกต่างหาก
- แก่นของความขัดแย้งอยู่ที่ มาตรฐานสองชั้น: Unity ใช้ไลบรารีโอเพนซอร์ส LGPL เอง แต่ไม่อนุญาตให้ผู้เผยแพร่และผู้ใช้ Unity Store แจกจ่ายบนฐาน LGPL
Videolabs Store และซัพพอร์ตเชิงพาณิชย์
- หลังแอสเซ็ต VLC for Unity ถูกนำออก ลูกค้าเดิมและลูกค้าใหม่สอบถามว่าจะมีการบำรุงรักษาต่อหรือไม่ และจะรับ อัปเดต build ได้อย่างไร
- เนื่องจากมีบริษัทจำนวนมากใช้เทคโนโลยีที่เกี่ยวข้องอย่าง LibVLC SDK และ FFmpeg ทาง Videolabs จึงตัดสินใจเปิด Videolabs Store ของตนเอง
- ลูกค้าเดิมและลูกค้าใหม่สามารถซื้อไบนารีของปลั๊กอิน VLC Unity แบบโอเพนซอร์ส ได้โดยไม่ต้องผ่าน Unity Store
- VLC for Unity เป็นโอเพนซอร์ส ผู้ใช้จึงสามารถ build เองได้เช่นกัน
- Videolabs Store กลายเป็นช่องทางสำหรับทำให้ โครงสร้างการให้ผลิตภัณฑ์และบริการ สำหรับ LibVLC และ FFmpeg ชัดเจนขึ้น
- ผู้ใช้บางส่วนขอให้ช่วยแก้ปัญหาหรือเพิ่มฟีเจอร์ใหม่ แต่การพึ่งพาชุมชนและเวลาจำกัดของอาสาสมัครจำนวนน้อยทำให้การตอบสนองมีข้อจำกัด
- ทีม Videolabs ประกอบด้วยผู้เชี่ยวชาญด้าน VLC และ FFmpeg และครอบคลุมโปรโตคอล ฟอร์แมต และแพลตฟอร์มหลายแบบ
- แพ็กเกจที่ปรึกษาด้านมัลติมีเดียที่ให้บริการมีแบบ 3 ชั่วโมง, 10 ชั่วโมง และ 24 ชั่วโมง สามารถซื้อเป็นบริการครั้งเดียวหรือสมัครสมาชิกรายเดือนได้
- ขอบเขตการซัพพอร์ตรวมถึง custom build, การแก้บั๊ก, การผสานรวม SDK และการตอบคำถามตามความต้องการเฉพาะ
- สามารถซัพพอร์ตได้ไม่ว่าจะเป็นแพลตฟอร์มระบบปฏิบัติการหรือ toolkit ใด
- Store ยังรวม ไลเซนส์เชิงพาณิชย์ของ LibVLCSharp และ LibVLC ebook
- ผลิตภัณฑ์ที่อยู่ในแผน ได้แก่ Kyber ซึ่งเป็น SDK สำหรับสตรีมมิงเกมและเดสก์ท็อปแบบหน่วงต่ำมากพร้อมการควบคุมระยะไกล และการผสานรวมกับ game engine เพิ่มเติมอย่าง Unreal
4 ความคิดเห็น
บริษัทที่แม้แต่เอนจินยังทำออกมาได้ไม่ดี ก็มาทำเรื่องไร้สาระครบทุกแบบเลยสินะ 555
แม้จะเป็นความคิดที่คลุมเครือและสุดโต่ง แต่เวลาเกิดปัญหาที่อธิบายไม่ออกในวงการเทคโนโลยี ก็มักรู้สึกว่าเกือบทั้งหมดคงเป็นความผิดของพวกคนใส่สูท
Unity อีกแล้ว...
ทั้งที่เคยเกือบพาบริษัทพังเพราะเรื่องการออกไลเซนส์ไปแล้วแท้ ๆ ก็ยังมาทำให้คนหัวร้อนกันอีกนะ 555
ความคิดเห็นบน Hacker News
ดูเหมือนชัดเจนว่าทีมกฎหมายได้รับข้อมูลผิด ๆ แล้วใส่ลงไปในสัญญา
อย่างที่บทความบอก แอสเซ็ตของ Unity จำนวนมากใช้ dependency แบบ LGPL และตัว Unity เองก็ใช้แอสเซ็ต LGPL รวมถึงเกมที่วางจำหน่ายซึ่งสร้างด้วย Unity ก็มีแอสเซ็ต LGPL อยู่ด้วย
เจตนาน่าจะเป็นการคัดกรองเฉพาะ dependency แบบ GPL มากกว่า
GPL กับ LGPL ต่างกันมาก โดย LGPL เป็นไลเซนส์ที่ออกแบบมาเพื่อไม่บังคับให้แอปพลิเคชัน proprietary ต้องเปิดเผยซอร์สโค้ดของแอป แม้จะลิงก์กับไลบรารีโอเพนซอร์ส หากปฏิบัติตามเงื่อนไขบางอย่าง
ในทางกลับกัน GPL มีข้อกำหนดที่เข้มงวดกว่า คือผลงานดัดแปลงทั้งหมดที่มีโค้ด GPL อยู่ต้องเผยแพร่ภายใต้ GPL และต้องเปิดเผยซอร์สโค้ดด้วย
ตัวอย่างเช่น ผมเคยคิดว่าแอปที่แจกจ่ายได้เฉพาะผ่านสโตร์ของแพลตฟอร์มที่บังคับให้มีการลงนาม จะไม่สามารถรวมคอมโพเนนต์ LGPL ได้ เพราะผู้ใช้ไม่สามารถแก้ไขคอมโพเนนต์ LGPL ได้
แม้จะละรายละเอียดทางกฎหมายไว้ก่อน LGPL ยืดหยุ่นกว่า GPL แต่ก็ยังมีข้อจำกัดค่อนข้างมาก ดังนั้นซอฟต์แวร์ proprietary ควรทำให้เรียบง่ายไว้ หรือปรึกษาทนายผู้เชี่ยวชาญด้านนี้เพื่อตรวจสอบ การปฏิบัติตามข้อกำหนด อย่างระมัดระวัง
ในแง่นั้นจึงเข้าใจได้ที่ Unity จะห้ามซอฟต์แวร์ LGPL ไม่ได้หมายความว่าทำให้ถูกต้องไม่ได้ แต่เพราะการให้ Unity หรือผู้ให้บริการตรวจสอบแอสเซ็ตทุกชิ้นที่ขึ้นสโตร์ในเชิงกฎหมายทุกครั้งนั้นไม่สมจริง
แม้ในปี 2025 แม้แต่บน HN ก็ยังแปลกที่ไม่มีใครรู้แน่ชัดว่า LGPL หมายถึงอะไรในรายละเอียด หรือมีข้อกำหนดด้านการนำไปใช้งานอย่างไร
หากสถานะมันซับซ้อน สับสน และปล่อยให้ตีความกันมากขนาดนี้ ก็ย่อมมีพื้นที่ให้สร้าง ระบบไลเซนส์ใหม่ ที่ดีกว่า ซึ่งผู้คนเข้าใจได้จริง
ไลเซนส์อย่าง MIT ทุกคนเข้าใจได้ค่อนข้างชัดเจน แต่ไลเซนส์ตระกูล GPL หลายแบบและไลเซนส์เฉพาะทางที่ซับซ้อนกว่านั้น ตามอุดมคติแล้วควรถูกแทนที่ด้วยสิ่งที่ดีกว่า
สิ่งสำคัญตรงนี้คือจะอนุญาตให้อะไรอยู่ใน Unity Asset Store
Unity ไม่มีหน้าที่ต้องอนุญาตทุกอย่างที่อาจลิงก์กับเกม Unity ให้อยู่ในสโตร์ และสัญญาผู้ให้บริการในตอนนั้นดูเหมือนแค่ระบุว่าไม่สามารถขายแอสเซ็ต LGPL ในสโตร์ได้
การที่สโตร์ตั้งข้อกำหนดเพิ่มเติมไม่ใช่เรื่องน่าแปลกหรือไม่เป็นธรรม และในฐานะผู้จัดจำหน่ายคอนเทนต์บุคคลที่สาม ก็มีเหตุผลในการลดความเสี่ยงด้วย
อีกทั้งแอสเซ็ตใน Unity Asset Store ก็ไม่จำเป็นต้องใช้กับ Unity เท่านั้น และบางแอสเซ็ตสามารถใช้กับเอนจินอื่นได้ตามไลเซนส์: https://support.unity.com/hc/en-us/articles/34387186019988-C...
อย่างไรก็ดี การที่ยังแจกจ่ายแอสเซ็ตอื่น ๆ ที่มีคอมโพเนนต์ LGPL ต่อไป แต่ไม่บังคับใช้กฎ LGPL อย่างสม่ำเสมอ นั่นเป็นปัญหามากกว่า
โดยพื้นฐานแล้ว LGPL กำหนดว่าผู้ใช้ต้องสามารถแก้ไขไลบรารีโอเพนซอร์ส สร้างใหม่ และรวมไลบรารีใหม่นั้นกลับเข้าไปในแอปพลิเคชันเดิมได้
นักพัฒนาที่ใช้ไลบรารี LGPL ต้องทำให้สิ่งนี้ “เป็นไปได้” แต่ในทางปฏิบัติหมายความว่าอะไรนั้นยังมีช่องให้ตีความได้มาก
เหตุผลที่ทนายและบริษัทต่าง ๆ ไม่อยากแตะ LGPL ก็เพราะมันมี ช่องให้ตีความ มากกว่า GPL ด้วยซ้ำ
ผมไม่แน่ใจว่าข้อสมมตินั้นใช้ได้กับกรณีนี้หรือไม่
ทนายของ Unity กำลังทำลายบริษัทอยู่เรื่อย ๆ และก็ไม่น่าแปลกใจเท่าไร
ผมเคยทำงานที่นั่นมาก่อน และแม้จะภูมิใจกับความสำเร็จทางเทคนิค แต่แทบทุกอย่างนอกเหนือจากนั้นน่าอับอาย
แก้ไข: จริง ๆ แล้วมีความเกี่ยวข้องกัน และนักพัฒนาหลักของ VLC ส่วนใหญ่ทำงานอยู่ที่ VideoLabs
ขอคงคอมเมนต์เดิมไว้
บล็อกโพสต์นี้ลิงก์ไปยัง “VideoLab Store” ที่ https://videolabs.io โดยใช้โลโก้ขนาดใหญ่ที่คล้ายกับโลโก้ VLC (ซึ่งย่อมาจาก VideoLAN ไม่ใช่ VideoLab) มาก แต่ไม่เหมือนกัน
บนหน้าแรกยังมีข้อความว่า “Hire the VLC team” ด้วยซ้ำ
เท่าที่ทราบ VideoLab ไม่เกี่ยวข้องกับองค์กรไม่แสวงหากำไร VideoLAN และดูเหมือนพยายามทำให้ผู้คนเข้าใจผิดว่าตนเป็นนักพัฒนา VLC
ปัจจุบัน VideoLabs จ้าง นักพัฒนาหลักของ VLC ส่วนใหญ่ และคนเหล่านั้นเป็นแรงขับเคลื่อนหลักของการพัฒนา VLC
เหตุผลที่จัดโครงสร้างแบบนี้คือเพื่อให้ VLC ยังคงเป็นซอฟต์แวร์เสรีตลอดไป และองค์กรไม่แสวงหากำไรก็ยังคงอยู่ต่อไป แม้บริษัท Videolabs จะไม่ได้ดำรงอยู่ตลอดไปก็ตาม
นี่เป็นโครงสร้างที่ค่อนข้างพบได้ทั่วไปในโปรเจกต์โอเพนซอร์ส และในกรณีของ VideoLAN ก็มีบริษัทที่ทำคอนซัลติ้งอยู่ 3–4 แห่ง
โดยแก่นแท้แล้วเป็น นิติบุคคลแสวงหากำไร ที่จ้างและจ่ายเงินเดือนให้ผู้มีส่วนร่วมหลักของ VLC ส่วนใหญ่ เพื่อให้ทำงานในอีโคซิสเต็มนั้น และ финанс สิ่งนี้ด้วยงานคอนซัลติ้งและบริการอื่น ๆ
ยังมีส่วนร่วมกับ codebase ของ VLC เป็นจำนวนมากด้วย
จากมุมมองของคนที่เคยทำงานร่วมกันในฐานะพาร์ตเนอร์ ขอเสริมว่า “แสวงหากำไร” เป็นเพียงรูปแบบทางกฎหมายเป็นหลัก ไม่ใช่แนวคิดการทำงานของพวกเขา
นอกจากนี้ Videolabs ยังอยู่ในหน้า https://www.videolan.org/videolan/partners.html ด้วย
ฝั่งโปรเจกต์ดูเหมือนจะรู้จักบริษัทนี้ดี
ตอนนี้ในฐานะ ผู้มีส่วนร่วมหลักของ VLC พวกเขาจ้างนักพัฒนารุ่นเก่าแก่ และสร้างโซลูชันแบบปรับแต่งเฉพาะรอบ ๆ อีโคซิสเต็มของ VLC และ FFmpeg
ตามหน้าแนะนำ พวกเขาเป็นผู้ดูแลหลักของ VLC
หากผมเข้าใจผิดช่วยแก้ให้ด้วย
เท่าที่เข้าใจ การใช้โค้ด LGPL v2 ก็ยังโอเคสำหรับการออกบนคอนโซลด้วย ใน v2 ไม่มี ข้อกำหนดป้องกันการทิโวไลเซชัน ซึ่งหมายความว่าแม้ผู้ใช้ปลายทางจะลิงก์โปรแกรมใหม่ไม่ได้เพราะแพลตฟอร์มถูกล็อก ก็ไม่เป็นปัญหา
แต่ websockify.js และน่าจะมี dependency อื่น ๆ เป็น LGPL v3 และดูเหมือนว่านั่นหมายความว่ามันไม่สามารถถูกรวมไว้ในแพลตฟอร์มอย่าง Nintendo Switch ที่ผู้ใช้ปลายทางไม่สามารถเปลี่ยนคอมโพเนนต์นั้นได้
เลยสงสัยว่า Unity กำลังแยกคอมโพเนนต์เหล่านี้ออกจากแพลตฟอร์มที่ถูกล็อกอยู่หรือเปล่า หรือแค่กำลังละเมิด LGPL v3 อยู่เฉย ๆ
ข้อกำหนดนี้เขียนไว้ค่อนข้างแคบเพื่อหยุดสิ่งที่ Tivo เคยทำ กล่าวคือ มุ่งไปที่กรณีที่ขายอุปกรณ์ซึ่งมีระบบปฏิบัติการถูกล็อก และมีซอฟต์แวร์ *GPLv3 รวมอยู่ด้วย
จะมีผลบังคับใช้ก็ต่อเมื่อซอฟต์แวร์ถูกส่งมอบ “ภายในผลิตภัณฑ์สำหรับผู้ใช้” และการส่งมอบนั้นเป็นส่วนหนึ่งของธุรกรรมที่โอนสิทธิ์ความเป็นเจ้าของและการใช้งานผลิตภัณฑ์ให้แก่ผู้รับ
“ผลิตภัณฑ์สำหรับผู้ใช้” โดยทั่วไปหมายถึงทรัพย์สินส่วนบุคคลที่มีตัวตนซึ่งใช้เพื่อส่วนบุคคล ครอบครัว หรือในบ้าน หรือสิ่งที่ออกแบบและขายเพื่อให้รวมเข้าเป็นส่วนหนึ่งของที่อยู่อาศัย
ในกรณีของ Nintendo Switch นั่นหมายความว่า Nintendo ไม่สามารถใส่ซอฟต์แวร์ *GPLv3 ไว้ในตัว Switch เองหรือสิ่งที่ให้มาพร้อมตอนซื้อได้
ซอฟต์แวร์เพิ่มเติมที่ดาวน์โหลดมาติดตั้งภายหลัง ซอฟต์แวร์ที่ขายผ่าน Nintendo online store หรือสื่อกายภาพ ไม่อยู่ภายใต้ข้อกำหนดป้องกันการทิโวไลเซชัน
ดังนั้นถ้าดูเฉพาะข้อกำหนดนั้น Unity จะรวมโค้ด *GPLv3 สำหรับแพลตฟอร์มที่ถูกล็อก หรือให้นักพัฒนาสร้างเกมสำหรับแพลตฟอร์มนั้นด้วย Unity ก็ไม่มีปัญหา
สิ่งที่อาจเป็นปัญหาคือส่วนอื่นของ *GPLv3 เมื่อซอฟต์แวร์ถูกแจกจ่ายและซื้อผ่านแอปสโตร์อย่างของ Apple หรือ Nintendo ผู้ที่ทำสำเนาดาวน์โหลดและแจกจ่ายคือ Apple หรือ Nintendo
ถ้าได้รับอนุญาตจากเจ้าของลิขสิทธิ์ก็โอเค แต่การใช้สโตร์แบบนี้โดยทั่วไปต้องยอมรับเงื่อนไขที่ห้ามแจกจ่ายต่อหรือห้ามทำ reverse engineering และนี่เป็นการละเมิด *GPLv3
หากเจ้าของลิขสิทธิ์ถือครองลิขสิทธิ์ของโค้ดทั้งหมดที่ใช้ ก็สามารถให้สิทธิ์ Apple หรือ Nintendo ในการแจกจ่ายได้
แต่ถ้าแอปหรือเกมมีไลบรารี *GPL ของบุคคลที่สามรวมอยู่ และบุคคลที่สามนั้นไม่ได้มอบไลเซนส์แบบนั้นให้ผู้ให้บริการสโตร์ แอปหรือเกมนั้นก็ไม่สามารถถูกแจกจ่ายในสโตร์นั้นได้
เป็นการคัดลอกเนื้อหาจากลิงก์ที่ตายไปแล้ว
Apple ก็มีปัญหาแบบเดียวกับ Unity ถ้าลองรัน
% bash --versionบน macOS จะเห็น GNU bash 3.2.57 เพราะอัปเกรดไปไกลกว่ารุ่น 3.2 ซึ่งเป็นรุ่นสุดท้ายของ GPL v2 ไม่ได้ จึงต้องดูแลเวอร์ชันเก่าเองเป็นเวอร์ชันที่เก่าพอจะสูบบุหรี่ ลงคะแนนเสียง และไปรบได้ตามมาตรฐานสหรัฐฯ แล้ว และ Apple ก็กำลังพยายามย้ายผู้ใช้ไปใช้ zsh
ผมดู LGPL 2.1 แล้ว ส่วน “or later” ของไลเซนส์ดูแปลก ๆ ผู้ใช้สามารถเปลี่ยนไปใช้ GPL 2.1 หรือเวอร์ชันใด ๆ ที่ใหม่กว่าได้ตามดุลยพินิจ
อย่างไรก็ตาม ผู้เขียนไลบรารีต้องระบุไว้ในไฟล์ COPYING ว่าเป็น LGPL, ระบุชัดว่า LGPL 2.1, หรือข้อความที่แนะนำคือ “LGPL 2.1 or later”
ที่ Unity บอกว่าโค้ด LGPL ถูก “deprecated” นั้นพอเข้าใจได้ ตราบใดที่โค้ดไม่ได้ล็อกเวอร์ชัน LGPL ไว้ เพราะผู้จัดหา LGPL ต้นน้ำสามารถทำ license rug pull ได้ทุกเมื่อเหมือน bash
แต่ไลบรารี VLC ถูกระบุไว้ที่นี่ว่าเป็น “LGPL 2.1 only” จึงเท่ากับยืนยันอย่างชัดเจนว่าไม่สามารถ rug pull ได้ เว้นแต่จะกระโดดไป GPL3: https://code.videolan.org/explore/projects/starred
อย่างไรก็ตาม VLC ไม่ได้ใส่ไลเซนส์ไว้อย่างถูกต้อง และ COPYING กับ COPYING.lib ไม่ได้บอกว่าล็อกเวอร์ชัน LGPL ไว้หรือไม่ ส่วน README.md ระบุว่า
libVLC, the engine is released under the LGPLv2 (or later) license.: https://code.videolan.org/videolan/vlcดังนั้นสิ่งที่ Unity กังวลก็ดูมีเหตุผลอยู่บ้าง “or later” รวมถึง v3 และ v3 ไม่ค่อยเข้ากับเทคโนโลยีป้องกันการโกงหรือสิ่งอย่างคอนโซลเป็นพิเศษ
แต่ผมเดาว่า Unity กังวลว่าจะไปทำให้บุคคลที่สามซึ่งถือสิทธิบัตรในอัลกอริทึมที่ VLC นำไปใช้ไม่พอใจ และใช้ LGPL เป็นข้ออ้างเพื่อซ่อนรายละเอียดของข้อตกลงลับนั้นมากกว่า
Godot ดีกว่า
ทุกวันนี้ Unity เป็น ทางเลือกทางธุรกิจที่แย่
ถ้าต้องเลือกเอนจินเชิงพาณิชย์ อย่างน้อยผมก็จะเลือก Epic Games ที่ใช้ทนายไปสู้กับ Apple แทนที่จะไปรังแกนักพัฒนาโอเพนซอร์ส
ที่น่าสนใจคือในข้อตกลงผู้ให้บริการดูเหมือนจะไม่มีข้อ 5.10.4: https://unity.com/legal/provider
ครั้งหนึ่งเคยมีข้อกำหนดนี้อยู่:
5.10.4 Provider represents and warrants that its Assets shall not contain (a) any software licensed under the GNU General Public License or GNU Library or Lesser General Public License, or any other license with terms that include a requirement to extend such license to any modification or combined work and provide for the distribution of the combined or modified product’s source code upon demand so that Customer content becomes subject to the terms of such license; or (b) any software that is a modification or derivative of any software licensed under the GNU General Public License or Library or Lesser Public License, or any other license with terms similar thereto so that Customer content become subject to the terms of such license.แต่ตาม Wayback Machine ข้อนี้ถูกลบออกไประหว่างวันที่ 3 ธันวาคมถึง 12 ธันวาคม
อยากใช้ Unity กับโปรเจกต์จริง ๆ
ผมชอบตัว editor และ API จริง ๆ และสามารถสร้างเครื่องมือต่าง ๆ ใน editor ให้คนที่ไม่คุ้นเคยกับเทคโนโลยีใช้ได้ค่อนข้างง่าย
แต่ Unity ทำให้การใช้งานยากขึ้นในทุกขั้นตอน ตั้งแต่พฤติกรรมที่เป็นปฏิปักษ์ต่อผู้ใช้, แพ็กเกจเบต้า 20 ตัวแบบ “สัญญาจริง ๆ ว่าปีหน้าจะทำให้เสถียร”, ไปจนถึง ประสิทธิภาพที่แย่ลงอย่างหนัก แม้แต่ในโปรเจกต์เปล่า
ตอนนี้ส่วนใหญ่ใช้ Godot อยู่และก็โอเค แต่ก็ยังเทียบกับ Unity ได้ไม่เต็มที่
แค่เพราะอัปโหลดแพ็กเกจที่ Unity กำหนดให้เป็น deprecated แล้วตอนนี้ถึงกับ แบนถาวร บัญชีเลยเหรอ? นี่พวกเขาสูบอะไรกันอยู่เนี่ย?
มันไปแข่งกับ media player ของตัวเองหรือเปล่า? หรือคนทำ VLC ไปคบกับแฟนเก่าของผู้บริหาร Unity เข้า?
เป็นเทรนด์ที่โง่จริง ๆ และทุกคนควรช่วยกันผลักไสออกไป แต่เรายังไปไม่ถึงจุดนั้น
ถ้าตีความบันทึกของ Unity ก็ดูเหมือนว่าพวกเขาลบไลบรารี VLC ออกจาก Unity Store และแบนถาวรบัญชี Unity Store ของกลุ่ม VLC โดยอ้างว่าละเมิดเงื่อนไขสัญญากับ Unity
ศัพท์เฉพาะแบบองค์กรอาจเข้าใจยาก บางทีนั่นอาจเป็นจุดประสงค์หลักของ ศัพท์เฉพาะแบบองค์กร ก็ได้
Unity แสดงความเป็นปฏิปักษ์อีกแล้ว
การ แบนถาวร นักพัฒนาด้วยเหตุผลแบบนี้มันบ้าชัด ๆ
เรื่องนี้เกิดขึ้นในเดือนสิงหาคม 2023 ก่อนเหตุการณ์คิดเงินต่อการติดตั้ง
ไม่แปลกใจเลย Unity เป็นบริษัทที่แย่สุด ๆ