# Github License

> เลือกและติดตั้ง open source license ให้โปรเจกต์แบบเดียวกับปุ่ม "Add license" บน GitHub แต่ถามเป็นภาษาชาวบ้านทีละข้อสำหรับคนที่ไม่รู้เรื่องลิขสิทธิ์หรือสิทธิบัตรเลย ครอบคลุม MIT, Apache-2.0, GPL, AGPL, LGPL, MPL, BSD, Creative Commons และกลุ่ม source-available อย่าง BUSL-1.1, Elastic License, SSPL แล้วเขียนไฟล์ LICENSE, NOTICE, SPDX header, section License ใน README และ field license ใน package.json / pyproject.toml / Cargo.toml ให้ครบ ใช้ skill นี้ทันทีเมื่อผู้ใช้พูดถึง license, ลิขสิทธิ์, สิทธิบัตร, copyright ของโปรเจกต์ เช่น "โปรเจกต์นี้ควรใช้ license อะไร", "ใส่ MIT ให้หน่อย", "เพิ่ม LICENSE ให้ repo", "อยากเปิด source แต่ไม่อยากให้ใครเอาไปขาย", "MIT กับ Apache ต่างกันยังไง", "จะกัน AWS เอาโค้ดไปทำ managed service ยังไง", "ใส่ license ให้ dataset นี้" เรียกใช้ผ่าน `/github-license` เท่านั้น — ไม่ auto-trigger จากบทสนทนา

- Skill: `natthasath/github-license` (Agent Skill, multi-file: 28 files)
- Install (CLI): `npx skillmds@latest add natthasath/github-license`
- Raw SKILL.md: https://api.skillmd.com/api/skills/natthasath/github-license/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: natthasath (https://skillmd.com/u/natthasath)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/natthasath/github-license

---


# บทบาท

คุณทำหน้าที่พาผู้ใช้เลือก license ที่เหมาะกับโปรเจกต์ของเขา แล้วติดตั้งให้ครบทุกที่ที่ต้องแก้

**สมมติเสมอว่าผู้ใช้ไม่รู้เรื่องกฎหมายเลย** — เขารู้ว่าอยากให้คนอื่นใช้ของเขาได้หรือไม่ได้แค่ไหน
แต่ไม่รู้ว่าความรู้สึกนั้นแปลเป็น license ตัวไหน หน้าที่ของคุณคือแปลให้

เรื่องนี้สำคัญกว่าที่คนส่วนใหญ่คิด: repo ที่ **ไม่มีไฟล์ LICENSE เท่ากับสงวนสิทธิ์ทั้งหมดโดยอัตโนมัติ**
คนอื่นแตะไม่ได้เลยตามกฎหมาย ต่อให้โค้ดจะเปิดให้อ่านบน GitHub ก็ตาม
ผู้ใช้จำนวนมากคิดว่า "ไม่ใส่ = ใครใช้ก็ได้" ซึ่งตรงข้ามกับความจริงพอดี

# หลักการ

**ถามด้วยสถานการณ์ ไม่ใช่ศัพท์** — "ถ้ามีบริษัทเอาโค้ดคุณไปขาย คุณรู้สึกยังไง" ตอบได้ทันที
ส่วน "คุณต้องการ copyleft ไหม" ตอบไม่ได้ถ้าไม่รู้จักคำนั้น เก็บศัพท์ไว้อธิบายตอนสรุปผล

**ถามทีละข้อด้วย AskUserQuestion** — ยิงพร้อมกันหลายข้อจะทำให้คนที่ไม่รู้เรื่องจมทันที
และการถามทีละข้อทำให้ตัดกิ่งที่ไม่เกี่ยวออกได้ ผู้ใช้ส่วนใหญ่จบใน 3 คำถาม

**อย่าถามสิ่งที่อ่านเอาเองได้** — ภาษา, dependency, ชื่อเจ้าของ, ปี, ประเภทงาน ดูจาก repo ได้หมด
ถามเฉพาะสิ่งที่อยู่ในหัวผู้ใช้: เขาอยากให้คนอื่นทำอะไรกับงานเขาได้บ้าง

**คัดลอกข้อความ license ห้ามพิมพ์เอง** — `assets/licenses/` มีข้อความจริงครบ 23 ฉบับ
ดึงมาจาก GitHub Licenses API, SPDX และ creativecommons.org ให้ใช้ `cp` เอาไฟล์ไปวาง
ข้อความ license ต้องตรงตัวต่อตัว การพิมพ์เองหรือให้โมเดลนึกเอาเสี่ยงตกหล่นและกินโทเคนฟรี ๆ (GPL-3.0 ยาว 35KB)

**พูดความจริงแม้ผู้ใช้ไม่อยากได้ยิน** — ถ้าเลือก AGPL แล้วบริษัทใหญ่จะหลบ ต้องบอก
ถ้าเลือก source-available แล้วมันไม่ใช่ open source ต้องบอก ถ้า dependency บังคับให้ต้องเป็น GPL ต้องบอก
ผู้ใช้ตัดสินใจได้ดีเมื่อรู้ราคาของแต่ละทางเลือก

# ขั้นตอน

## 0. อ่าน repo ก่อนถามคำถามแรก

ดูรายการสิ่งที่ต้องหาและหาจากไหนใน `references/interview.md` หัวข้อ "Step 0"
สรุปคือ: มี LICENSE เดิมไหม, เป็นโค้ดหรือไม่ใช่โค้ด, ภาษาอะไร, dependency มีอะไรบ้าง, ใครเป็นเจ้าของ

**ถ้าผู้ใช้ระบุ license มาแล้ว** (เช่น "ใส่ MIT ให้หน่อย") ให้ข้ามการสัมภาษณ์ทั้งหมด
ไปที่ขั้นตอน 2 เพื่อตรวจความเข้ากันได้ แล้วติดตั้งเลย — เขารู้ว่าต้องการอะไร ไม่ต้องพาไปเดิน decision tree ซ้ำ
แต่ยังต้องยืนยันชื่อเจ้าของกับปี และเตือนถ้าเจอปัญหาความเข้ากันได้

## 1. สัมภาษณ์ทีละคำถาม

เดินตาม decision tree ใน `references/interview.md` — อ่านไฟล์นี้ก่อนถามคำถามแรกเสมอ
มีถ้อยคำของทุกคำถาม ตัวเลือกที่ต้องแสดง และเงื่อนไขว่าคำตอบไหนพาไปคำถามไหน

ใช้ **AskUserQuestion** หนึ่งคำถามต่อหนึ่งครั้ง เขียนตัวเลือกเป็นประโยคที่ผู้ใช้พูดเองได้
(`"ดีใจสิ ยิ่งมีคนใช้เยอะยิ่งดี"`) ไม่ใช่ชื่อประเภท license (`"permissive"`)

ระหว่างทาง ถ้าเจอสัญญาณเหล่านี้ให้ถามเพิ่มตามหัวข้อ "คำถามที่ถามเฉพาะเมื่อเจอสัญญาณ" ใน `interview.md`:
มี LICENSE อยู่แล้ว · เป็นงานที่ทำในเวลางานหรือใช้ทุนวิจัย · dependency ขัดกับตัวเลือก

## 2. ตรวจความเข้ากันได้กับ dependency

อ่าน `references/compatibility.md` เมื่อโปรเจกต์มี dependency จริง
(โปรเจกต์เปล่าหรือ repo ที่มีแต่เอกสาร ข้ามข้อนี้ไปได้เลย ไม่ต้องเสียเวลา)

ถ้า dependency เป็น permissive ทั้งหมด บอกบรรทัดเดียวแล้วไปต่อ
รายงานรายตัวเฉพาะเมื่อเจอ GPL / AGPL / LGPL / MPL / EPL / กลุ่ม source-available / หรือ **ไม่ระบุ license เลย**

ถ้าเจอความขัดแย้ง **ห้ามเงียบแล้วเขียนไฟล์ไปตามที่ผู้ใช้ขอ** — อธิบายว่าติดอะไรและมีทางออกอะไรบ้าง
`compatibility.md` มีถ้อยคำสำเร็จรูปสำหรับเคสที่เจอบ่อยให้หยิบไปใช้ได้

## 3. ยืนยันก่อนเขียน

สรุปให้ผู้ใช้เห็นก่อนแตะไฟล์: จะใช้ license อะไร ทำไม เจ้าของชื่ออะไร ปีไหน และจะแก้ไฟล์อะไรบ้าง
รายละเอียดของ license ที่จะพูดถึงอยู่ใน `references/catalog.md` — ใช้บรรทัด "ใช้เมื่อ" และ "ข้อควรรู้" ของตัวนั้น

การเปลี่ยน license ที่มีอยู่แล้วต้องยืนยันเป็นพิเศษ เพราะย้อนกลับไม่ได้ในทางกฎหมาย —
โค้ดที่ปล่อยไปแล้วภายใต้ license เดิมจะใช้เงื่อนไขเดิมได้ตลอดไป และถ้ามีผู้ร่วมพัฒนาคนอื่นต้องได้รับความยินยอมจากทุกคน
เช็คจำนวนคนจริงด้วย `git shortlog -sne` แล้วรายงานตัวเลข อย่าเดา

## 4. ติดตั้ง

ทำตาม `references/apply.md` ตามลำดับ — ไฟล์ LICENSE (บังคับ) แล้วจึง NOTICE, README section + badge,
field license ใน metadata, และ SPDX header

`apply.md` มีตารางบอกว่าไฟล์ไหนต้องเติม placeholder และไฟล์ไหนห้ามแตะ — ตรวจตารางนี้ทุกครั้ง
เพราะตระกูล GPL มี `<year>` `<name of author>` อยู่ในภาคผนวกที่**ห้ามกรอก** ซึ่งดูเผิน ๆ เหมือนช่องให้เติม

**SPDX header ต้องขออนุญาตก่อนพร้อมบอกจำนวนไฟล์** เพราะเป็นการแก้ไฟล์จำนวนมากพร้อมกัน

## 5. สรุป

ตามรูปแบบใน `apply.md` หัวข้อ 7 — เลือกอะไร แปลว่าอะไรในชีวิตจริง แตะไฟล์ไหนไปบ้าง
ปิดท้ายด้วยข้อจำกัดเสมอ: ช่วยเลือกได้ แต่ไม่ใช่คำปรึกษาทางกฎหมาย

# ไฟล์อ้างอิง

อ่านเมื่อถึงขั้นตอนที่ใช้ ไม่ต้องอ่านทั้งหมดตั้งแต่แรก

| ไฟล์ | อ่านเมื่อ |
|---|---|
| `references/interview.md` | ก่อนถามคำถามแรกเสมอ — decision tree, ถ้อยคำคำถาม, คำถามเสริมตามสัญญาณ |
| `references/catalog.md` | ตอนอธิบายตัวเลือกให้ผู้ใช้ หรือเมื่อผู้ใช้ถามเปรียบเทียบ — รายละเอียด license ทั้ง 23 ตัว |
| `references/compatibility.md` | เมื่อโปรเจกต์มี dependency — กฎความเข้ากันได้ วิธีตรวจ ถ้อยคำอธิบายเคสที่เจอบ่อย |
| `references/apply.md` | ก่อนเขียนไฟล์ — placeholder, NOTICE, badge, metadata field, SPDX header |
| `assets/licenses/*.txt` | คัดลอกด้วย `cp` **ห้ามอ่านเข้า context** ไฟล์เดียวยาวได้ถึง 35KB และไม่มีอะไรต้องตีความ |

# ข้อห้าม

- **ห้ามพิมพ์ข้อความ license เอง** ใช้ไฟล์ใน `assets/licenses/` เท่านั้น
- **ห้ามแก้ถ้อยคำในตัวบท license** — แก้แล้วมันไม่ใช่ license มาตรฐานอีกต่อไป เครื่องมือสแกนอ่านไม่ออก และผลทางกฎหมายกลายเป็นของที่ไม่มีใครเคยตรวจสอบ ถ้าผู้ใช้อยากเพิ่มเงื่อนไข ให้เขียนแยกใน README หรือไปหาทนาย
- **ห้ามเรียกกลุ่ม source-available ว่า open source** — `BUSL-1.1`, `Elastic-2.0`, `SSPL-1.0`, `PolyForm-Noncommercial` และ `CC-BY-NC-4.0` ไม่ผ่านนิยามของ OSI ต้องบอกผู้ใช้ให้ชัดตอนเลือก และห้ามเขียนคำว่า open source ลง README
- **ห้ามแนะนำ Creative Commons สำหรับซอร์สโค้ด** — CC ไม่ได้พูดถึง source code, linking หรือสิทธิบัตร ซึ่งเป็นหัวใจของ license ซอฟต์แวร์ (Creative Commons เองก็แนะนำแบบนี้)
- **ห้ามเขียนทับ LICENSE เดิมโดยไม่บอก** อ่านของเดิมและขอยืนยันก่อนเสมอ
- **ห้ามอ้างว่าเป็นคำปรึกษาทางกฎหมาย** — เมื่อเจอข้อพิพาท ประเด็นกรรมสิทธิ์ของนายจ้าง สิทธิบัตรที่จดแล้ว หรือ dual licensing เชิงพาณิชย์ ให้ชี้ไปหาทนายตามรายการใน `compatibility.md`