GitHub เปิดตรวจ License ของ Dependency แบบ GA บังคับผ่านก่อน Merge ได้

GitHub ประกาศเมื่อวันที่ 16 ตุลาคม 2026 ว่าระบบตรวจการปฏิบัติตามเงื่อนไขใบอนุญาตของซอฟต์แวร์โอเพนซอร์ส หรือ Open-source license compliance เปิดใช้งานทั่วไปแล้วสำหรับองค์กรที่ใช้ GitHub Enterprise Cloud และเปิด GitHub Code Security ใน repository ที่เกี่ยวข้อง ข่าวนี้สำคัญกับทีมที่เพิ่ม dependency ผ่าน pull request อยู่เสมอ เพราะความเสี่ยงด้าน license มักถูกพบหลังจากนำไลบรารีเข้าระบบไปแล้ว ทำให้ต้องย้อนกลับมาเปลี่ยนแพ็กเกจหรือเจรจาข้อยกเว้นภายหลัง

สิ่งที่เปิดให้ใช้จริง

องค์กรสามารถกำหนดนโยบายใบอนุญาตในระดับ enterprise และสร้าง ruleset ชื่อ Require license compliance results before merging เพื่อให้ผลการตรวจเป็นเงื่อนไขก่อน merge ได้ ระบบพิจารณา dependency ที่เพิ่มหรือเปลี่ยนใน pull request แล้วเทียบกับนโยบายที่องค์กรตั้งไว้ หากไม่ผ่าน ทีมพัฒนาต้องจัดการประเด็นนั้นก่อน เช่น ถอน dependency เปลี่ยนเป็นแพ็กเกจอื่น ปรับนโยบาย หรือเพิ่มข้อยกเว้นให้แพ็กเกจตามกระบวนการอนุมัติขององค์กร การเปิดใช้งานทั่วไปครั้งนี้รวมองค์กรแบบ data residency ด้วย

GitHub เพิ่มบทบาท Enterprise Open-Source License Manager เพื่อให้แยกหน้าที่ผู้ดูแลนโยบายออกจากผู้ดูแลระบบทั้งหมด อีกทั้งมีบันทึก audit log สำหรับการเปลี่ยนนโยบาย มี API สำหรับจัดการนโยบาย และ API สำหรับตรวจสถานะการปฏิบัติตามเงื่อนไขของแพ็กเกจ สิ่งเหล่านี้ทำให้ทีม platform หรือ compliance สามารถติดตามการตัดสินใจย้อนหลัง และเชื่อมผลการตรวจเข้ากับขั้นตอนการอนุมัติที่มีอยู่ได้

ทำไมการตรวจใน pull request จึงต่างจากการตรวจย้อนหลัง

สมมติบริการหนึ่งเพิ่มไลบรารีเพื่ออ่านไฟล์เอกสาร ทีมอาจเห็นว่าทดสอบผ่านทั้งหมด แต่ใบอนุญาตของไลบรารีนั้นไม่อยู่ในรายการที่องค์กรยอมรับ หากตรวจตอนเปิด pull request ผู้พัฒนาจะเห็นปัญหาขณะยังมีบริบทว่าทำไมเลือกแพ็กเกจนี้ และยังเปลี่ยนตัวเลือกได้ง่ายกว่าหลัง deploy หลายบริการไปแล้ว อย่างไรก็ตาม ผลลัพธ์ขึ้นกับ dependency ที่ตรวจพบและนโยบายที่องค์กรกำหนด จึงไม่ควรตีความเครื่องหมายผ่านว่าเป็นคำรับรองทางกฎหมายสำหรับผลิตภัณฑ์ทั้งหมด

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

แนวทางนำไปใช้ในองค์กร

เริ่มจากยืนยันว่าองค์กรใช้ GitHub Enterprise Cloud และ repository เป้าหมายเปิด GitHub Code Security ตามเงื่อนไขของฟีเจอร์ จากนั้นให้ทีมกฎหมายหรือผู้รับผิดชอบโอเพนซอร์สกำหนดรายการใบอนุญาตที่ยอมรับและที่ต้องทบทวน ทดลองกับ repository ที่มี dependency หลากหลาย เปิด pull request ที่เพิ่มแพ็กเกจตัวอย่าง แล้วดูว่าผลการตรวจตรงกับนโยบายหรือไม่ เมื่อมั่นใจจึงค่อยเปิด ruleset บังคับก่อน merge ให้ครอบคลุมมากขึ้น

ควรทดสอบทั้งกรณีที่ควรผ่านและกรณีที่ควรถูกปฏิเสธ ตรวจว่าเจ้าของ pull request เข้าใจข้อความผลตรวจและรู้ช่องทางแก้ไข ตรวจ audit log เมื่อมีการเปลี่ยนนโยบาย และจำกัดสิทธิ์ของผู้แก้นโยบายให้เหมาะสม หากใช้ automation ผ่าน API ควรเก็บหลักฐานว่าระบบอ่านสถานะใดและตัดสินใจเมื่อไร เพื่อช่วยทบทวนเหตุการณ์ในภายหลัง

ข่าวนี้เป็นการเพิ่มจุดควบคุมใน workflow พัฒนา ไม่ใช่เครื่องมือที่ตัดสินข้อกฎหมายแทนผู้เชี่ยวชาญ ประโยชน์สูงสุดอยู่ที่การทำให้นโยบายชัด ตรวจได้ซ้ำ และแก้ปัญหาตั้งแต่ก่อน dependency ใหม่เข้าสู่สาขาหลัก

แหล่งข่าว: GitHub Changelog — Open-source license compliance generally available, 16 ตุลาคม 2026