# GitHub license compliance เปิดใช้ทั่วไป ตรวจไลเซนส์ dependency ก่อน merge ทั้งองค์กร

> GitHub เปิด GitHub license compliance ให้ใช้ทั่วไปเมื่อ 16 ต.ค. 2026 องค์กรบน Enterprise Cloud ตั้งนโยบายไลเซนส์กลางและบล็อก dependency ที่ผิดนโยบายก่อน merge

- ประเภท: ข่าว · หมวด: Software & DevOps
- เผยแพร่: 2026-10-19T11:05:00.000Z · อัปเดต: 2026-10-19T11:05:00.000Z
- โดย: กองบรรณาธิการ THAI DATA, THAI DATA IT BUSINESS ENTERPRISE
- ที่มา: https://thaidata.co.th/software/github-license-compliance-ga-enterprise-cloud/

## สรุปประเด็นสำคัญ

- **GitHub** ประกาศเมื่อ **16 ตุลาคม 2026** ว่าฟีเจอร์ open source license compliance พ้นช่วง public preview ที่เริ่มเมื่อ**มิถุนายน 2026** เป็น general availability สำหรับ **GitHub Enterprise Cloud** รวมลูกค้าแบบ data residency
- ใช้ได้กับ repository ที่เปิด **GitHub Code Security** โดยนโยบายไลเซนส์ระดับองค์กรถูกบังคับผ่าน ruleset ได้ **3 ระดับ** คือ enterprise, organization และ repository
- ruleset มี **2 โหมด** โหมด Active บล็อก pull request ที่เพิ่ม dependency ผิดนโยบาย ส่วนโหมด Evaluate ติดคำเตือนใน pull request แต่ไม่บล็อกการ merge
- รุ่น GA เพิ่ม**บทบาทใหม่** Enterprise Open-Source License Manager สำหรับอนุมัติข้อยกเว้น และปรับปรุง **4 ด้าน** จากรุ่นทดลอง รวม audit log และ API ที่ให้ coding agent เช็กว่าแพ็กเกจผ่านนโยบายหรือไม่

GitHub เปิด GitHub license compliance หรือ open source license compliance ให้ใช้งานทั่วไปเมื่อ 16 ตุลาคม 2026 องค์กรบน GitHub Enterprise Cloud ตั้งนโยบายไลเซนส์ของ dependency ได้ที่จุดเดียว แล้วให้ระบบตรวจทุก pull request และบล็อกแพ็กเกจที่ใช้ไลเซนส์นอกนโยบายก่อนโค้ดถูก merge

ฟีเจอร์นี้เปิดทดลองแบบ public preview ตั้งแต่มิถุนายน 2026 ต่อยอดจาก dependency review action เดิมด้วยนโยบายไลเซนส์ระดับ enterprise ใช้ได้กับลูกค้า Enterprise Cloud รวมลูกค้าแบบ data residency และ repository ที่จะบังคับนโยบายต้องเปิด GitHub Code Security

## GitHub license compliance ทำงานอย่างไร

เอกสารของ GitHub อธิบายขั้นตอนไว้ดังนี้

- **กำหนดนโยบาย** ผู้ดูแลเลือกไลเซนส์ที่อนุญาตจากรายการในระบบ หรือเพิ่มเองด้วยรหัสไลเซนส์มาตรฐาน SPDX
- **ผูกนโยบายกับ ruleset** ใช้เงื่อนไขใหม่ Require license compliance results before merging คล้ายเงื่อนไขของ code scanning และตั้ง ruleset ได้ทั้งระดับ enterprise, organization และ repository
- **ตรวจตอนเปิด pull request** เมื่อ pull request แก้ไฟล์ manifest ของแพ็กเกจ ระบบเทียบ dependency ระหว่าง branch หลักกับ branch ของ pull request รวมถึง transitive dependency ที่ dependency graph ตรวจพบ แล้วรายงานตัวที่ผิดนโยบาย
- **แก้หรือขอข้อยกเว้น** นักพัฒนาเอาแพ็กเกจออกหรือเปลี่ยนตัว ขอแก้นโยบาย หรือขอข้อยกเว้นเฉพาะแพ็กเกจ

![หน้าแจ้งเตือนของ GitHub license compliance แสดงแพ็กเกจ sidekiq รุ่น 7.2.0 ที่ใช้ไลเซนส์ LGPL-3.0 นอกนโยบาย พร้อมลำดับเหตุการณ์ตั้งแต่เปิด alert จนผู้ดูแลอนุมัติคำขอปิด](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/github-license-compliance-ga-enterprise-cloud/github-license-compliance-alert-timeline.webp?v=9d3033a7) _(ภาพ: GitHub)_

ruleset ของ GitHub license compliance แบบ Active จะบล็อก pull request จนกว่าจะแก้ ส่วนแบบ Evaluate ตรวจและติดคำเตือนอย่างเดียว แต่ถ้า branch protection ตั้งให้ต้องตอบทุกความเห็นก่อน merge คำเตือนจากโหมด Evaluate ก็จะถูกนับด้วย คำเตือนไม่ได้สร้างคำขอข้อยกเว้นให้อัตโนมัติ เพราะนักพัฒนาอาจเลือกแก้โค้ดแทน

## ตัวอย่างการแจ้งเตือนจากประกาศของ GitHub

ภาพตัวอย่างในประกาศ GA แสดงสองกรณี กรณีแรกเป็นแพ็กเกจ NPM ในไฟล์ package-lock.json ที่ระบบพบไลเซนส์ BUSL-1.1 ซึ่งนโยบายไม่อนุญาต และเปิดการแจ้งเตือนสถานะ Open พร้อมบอกว่าแพ็กเกจเข้ามาจาก branch ใด กรณีที่สองเป็นแพ็กเกจ sidekiq รุ่น 7.2.0 ของ RubyGems ที่ใช้ไลเซนส์ LGPL-3.0 นักพัฒนาขอปิดการแจ้งเตือนโดยระบุว่าเป็นแพ็กเกจส่วนตัว ผู้ดูแลนโยบายอนุมัติคำขอ และหน้าแจ้งเตือนแสดงสถานะ Fixed ทุกขั้นถูกบันทึกเป็นลำดับเหตุการณ์ในหน้าเดียว ทีมกฎหมายหรือผู้ตรวจสอบจึงย้อนดูได้ว่าใครอนุมัติข้อยกเว้นเมื่อไร

## บทบาทใหม่ใน GitHub license compliance รุ่น GA

รุ่นนี้เพิ่มบทบาทสำเร็จรูประดับ enterprise ชื่อ Enterprise Open-Source License Manager สำหรับคนหรือทีมที่ตรวจและอนุมัติคำขอข้อยกเว้น ผู้มีบทบาทนี้ได้รับอีเมลแจ้งคำขอที่ค้าง และดูคำขอได้จากหน้าความปลอดภัยของ enterprise ส่วนนักพัฒนาที่มีสิทธิ์เขียนใน repository ดูนโยบายและข้อยกเว้นที่มีผลกับ repository ของตนได้

| สิ่งที่ปรับปรุงจากรุ่น public preview | ผลต่อผู้ใช้ |
| --- | --- |
| ข้อมูลไลเซนส์สำหรับลูกค้า data residency | ใช้ฟีเจอร์ได้ และ dependency graph กับไฟล์ SBOM ที่ export มีข้อมูลไลเซนส์ |
| audit log เมื่อแก้นโยบาย | ส่งต่อไประบบบันทึกหรือระบบกำกับดูแลภายนอกได้ |
| API ดาวน์โหลด แก้ และแทนที่นโยบาย | จัดการนโยบายแบบอัตโนมัติ |
| API เช็กว่าแพ็กเกจผ่านนโยบายหรือไม่ | coding agent เลี่ยงการแนะนำหรือใส่แพ็กเกจที่ผิดนโยบาย |

![เอกสาร About open source license compliance ของ GitHub Docs ระบุว่าฟีเจอร์ใช้ได้กับองค์กรใน enterprise account ที่เปิด GitHub Code Security](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/github-license-compliance-ga-enterprise-cloud/github-license-compliance-docs-overview.webp?v=11ca13bb) _(ภาพ: GitHub Docs (ภาพหน้าจอ))_

## แนวทางที่ GitHub แนะนำสำหรับองค์กรใหญ่

เอกสารของ GitHub วางรูปแบบไว้ 4 ขั้น คือ ตั้งนโยบายกว้าง ๆ จากส่วนกลาง มอบบทบาท License Manager ให้ผู้ตรวจนโยบาย ใช้ custom property ของ repository แบ่งเป็น inactive, evaluate หรือ active แล้วใช้ ruleset ที่ผูกกับค่าเหล่านั้นคุมระดับการบังคับของแต่ละ repository วิธีนี้ทำให้ค่อย ๆ เปิดใช้ทีละกลุ่มได้โดยไม่ทำให้ทุกทีมติดบล็อกพร้อมกัน

## ทำไมเรื่องนี้สำคัญ

ไลเซนส์ของโอเพนซอร์สเป็นความเสี่ยงทางกฎหมายที่มักถูกพบช้า เช่น แพ็กเกจที่ใช้ไลเซนส์แบบ copyleft หรือไลเซนส์ที่จำกัดการใช้เชิงพาณิชย์ในซอฟต์แวร์ที่องค์กรขายหรือแจกจ่าย GitHub license compliance ย้ายการตรวจจากรอบตรวจสอบปลายทางมาไว้ที่ pull request ซึ่งเป็นจุดที่แก้ได้ถูกที่สุด และ API ใหม่สำหรับ coding agent ตอบโจทย์ที่โค้ดและ dependency ถูกเพิ่มโดย AI มากขึ้น ฟีเจอร์นี้ต่อยอดงานด้าน software supply chain ของ GitHub เช่น[GitHub Secret Protection ที่ใช้ AI ตรวจรหัสผ่านที่หลุด](/software/github-secret-protection-ai-push-protection-model/)

## สิ่งที่องค์กรควรทำ

- **ให้ฝ่ายกฎหมายร่วมกำหนดรายการไลเซนส์** ที่อนุญาตและต้องห้าม ก่อนตั้งนโยบายใน GitHub license compliance
- **เริ่มจากโหมด Evaluate** ดูว่าโปรเจกต์ใดมี dependency ผิดนโยบายบ้าง แล้วค่อยเปลี่ยนเป็น Active ทีละกลุ่มผ่าน custom property
- **กำหนดผู้มีบทบาท Enterprise Open-Source License Manager** ให้ชัด และตั้งเวลาตอบคำขอข้อยกเว้น เพื่อไม่ให้งานค้าง
- **ใช้ข้อมูลไลเซนส์ใน SBOM** ที่ export จาก dependency graph ประกอบการตอบลูกค้าหรือผู้ตรวจสอบที่ขอรายการส่วนประกอบซอฟต์แวร์
- **ตรวจสิทธิ์การใช้งาน** ฟีเจอร์นี้ต้องใช้ GitHub Enterprise Cloud และ GitHub Code Security องค์กรที่ใช้แผนอื่นต้องประเมินค่าใช้จ่ายเพิ่ม

ติดตามข่าว DevOps โอเพนซอร์ส และเครื่องมือนักพัฒนาเพิ่มเติมได้ที่[หมวดซอฟต์แวร์](/software/)

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

### GitHub license compliance คืออะไร?

GitHub license compliance คือฟีเจอร์ตรวจไลเซนส์ของ dependency ใน repository เทียบกับนโยบายไลเซนส์ที่องค์กรกำหนด เมื่อ pull request เพิ่มหรือแก้ dependency ระบบจะตรวจและติดคำเตือนตัวที่ผิดนโยบาย และบล็อกการ merge ได้ถ้าตั้ง ruleset แบบ Active

### GitHub license compliance ใช้ได้กับแผนไหน?

GitHub license compliance ใช้ได้กับลูกค้า GitHub Enterprise Cloud รวมแบบ data residency ตั้งแต่ 16 ตุลาคม 2026 และ repository ที่จะบังคับนโยบายต้องมีไลเซนส์ GitHub Code Security ประกาศของ GitHub ไม่ได้ระบุถึง GitHub Enterprise Server

### ถ้า dependency ผิดนโยบายไลเซนส์ นักพัฒนาต้องทำอย่างไร?

เมื่อ GitHub license compliance พบ dependency ผิดนโยบาย นักพัฒนาเลือกได้สามทาง คือ เอา dependency นั้นออกหรือเปลี่ยนเป็นตัวอื่น ขอแก้นโยบายไลเซนส์ หรือขอข้อยกเว้นเฉพาะแพ็กเกจ คำขอข้อยกเว้นจะส่งไปให้ผู้มีบทบาท Enterprise Open-Source License Manager อนุมัติ ซึ่งได้รับแจ้งทางอีเมลด้วย

### โหมด Active กับ Evaluate ของ ruleset ต่างกันอย่างไร?

ใน GitHub license compliance ruleset โหมด Active ที่ใช้เงื่อนไข Require license compliance results before merging จะบล็อก pull request ที่เพิ่ม dependency ผิดนโยบายจนกว่าจะแก้ ส่วนโหมด Evaluate ตรวจและติดคำเตือนอย่างเดียว เหมาะกับช่วงเริ่มใช้เพื่อดูผลกระทบก่อนบังคับจริง


## แหล่งอ้างอิง

- [Open source license compliance generally available](https://github.blog/changelog/2026-10-16-open-source-license-compliance-generally-available/) — GitHub Changelog
- [About open source license compliance](https://docs.github.com/en/enterprise-cloud@latest/code-security/concepts/supply-chain-security/open-source-license-compliance) — GitHub Docs