Google จับมือ Speakeasy เปิดซอร์ส generator ที่ปั้น SDK ของ Gemini — แต่ใบอนุญาตของ 'โค้ดที่ถูก generate' ไม่ได้ฟรีอย่างที่บล็อกบอก

วันที่ 17 กันยายน 2026 Google Developers Blog เผยแพร่บทความ “Why client SDK generation belongs in the open” โดย Amir Hardon (Senior Staff Software Engineer) และ Philipp Schmid (Developer Relations Engineer) ประกาศว่า Google ร่วมมือกับ Speakeasy เปิดซอร์ส OpenAPI code generation suite ทั้งชุดภายใต้ใบอนุญาต AGPLv3 — เครื่องมือชุดเดียวกับที่ใช้ปั้น Google GenAI SDK รุ่นใหม่สำหรับ Interactions, Agents และ Webhooks API

เหตุผลเบื้องหลังตรงไปตรงมาและค่อนข้างเจ็บ: “In May 2026, right as we were gearing up for Google I/O and the General Availability of the Interactions API, the SDK generation provider we were using was acquired and abruptly announced its shutdown.” Google สรุปบทเรียนว่า generator แบบปิดซอร์สสร้าง “platform risk ที่ยอมรับไม่ได้” และถ้าอุตสาหกรรมพึ่ง OpenAPI เป็นตัวนิยาม interface เครื่องมือที่คอมไพล์ interface เหล่านั้นเป็น client library, CLI และ agent tool ก็ควรเป็น open infrastructure

Google ไม่ได้ระบุชื่อผู้ให้บริการรายนั้นในบทความ แต่ไทม์ไลน์ตรงกับดีลที่ Anthropic ประกาศซื้อ Stainless เมื่อ 18 พฤษภาคม 2026 — ทีมที่เคยสร้าง SDK ให้ทั้ง OpenAI, Google และ Cloudflare และมีรายงานว่า hosted SDK generator ส่วนกลางจะถูกทยอยปิด (เรารายงานไว้เมื่อ 24 พ.ค.)

มีอะไรถูกเปิดซอร์สบ้าง

ตามบทความ ชุดเครื่องมือที่ปล่อยออกมาประกอบด้วยสามส่วน:

• Multi-language SDK generators — สร้าง client library 7 ภาษา (Python, TypeScript, Go, Java, C#, PHP, Ruby) แต่ละตัวมาพร้อม static typing, สตรีมแบบ server-sent events (SSE), retry และ pagination
• Agent-native CLI generator — คอมไพล์เป็น CLI binary เดี่ยว ๆ เพื่อให้ AI coding agent เรียก API ได้ตรงจาก terminal โดยไม่ต้องเขียนสคริปต์ HTTP ทิ้งขว้าง
• Documentation MCP server generator — แปลง OpenAPI spec + เอกสาร markdown ให้กลายเป็น MCP server เพื่อให้ coding agent สอบถาม schema ที่ verify แล้วแบบสด ๆ แทนการเดาเมธอดที่ล้าสมัย

ฝั่งการใช้งานจริงของ Google เองก็น่าสนใจ: ทีม Google DeepMind บอกว่าเลือก “เครื่องมือให้เหมาะกับแต่ละชั้นของสแต็ก” — ใช้ generator ที่ deterministic และ type-safe เป็นแกน แล้วใช้ Antigravity AI agent เร่งเฉพาะส่วนที่ต้อง custom ผลคือ pipeline ที่ครอบคลุม 6 target (ปล่อย SDK แล้ว 3 ตัว) ดูแลด้วยวิศวกร ราวคนเดียว จากเดิมที่การดูแล generator เขียนมือต้องใช้หลายคน

ตัวรีโปอยู่ที่ github.com/speakeasy-api/openapi-generation เขียนด้วย Go (1.26.2) สร้างเมื่อ 10 กันยายน 2026 และยังมีคอมมิตเข้าอยู่ ณ วันที่ 17 กันยายน README ในรีโประบุ target มากกว่าที่บล็อกบอก — 12 target หลัก: C#, Go, Java, MCP TypeScript, PHP, Python, Ruby, TypeScript, Unity บวก CLI application, Postman collection และ Terraform provider รองรับ OpenAPI 3.0/3.1 และรองรับบาง construct ของ 3.2 (ยังไม่รองรับ 3.2 เต็มเวอร์ชัน)

เงื่อนไขที่บล็อกของ Google ไม่ได้บอก

บทความของ Google เขียนเรื่องใบอนุญาตไว้แบบสบายใจว่า AGPLv3 “allows you to run it in your development or CI pipeline while keeping complete ownership of your generated code/SDKs under your chosen license (such as MIT or Apache 2.0)”

แต่เมื่ออ่าน README.md และ LICENSING.md ในรีโปจริง ภาพต่างออกไปพอสมควร:

• generator ปฏิเสธที่จะรันถ้าไม่เลือกใบอนุญาตก่อน (“the generator refuses to run without an election”)
• เส้นทางฟรีคือส่งแฟล็ก --license agpl-3.0-only ซึ่งแปลว่าโค้ดส่วนที่ Speakeasy เป็นผู้เขียนใน output ถูกอนุญาตแบบ AGPL-3.0-only และ generator จะแปะไฟล์ LICENSE กับ NOTICE ลงไปในผลลัพธ์
• เส้นทางที่ทำให้ “เลือกใบอนุญาตเองได้” ต้องมี commercial license token — LICENSING.md ระบุว่า artifact ที่ generate ภายใต้แผน/ทดลอง/สิทธิ์เชิงพาณิชย์ที่ยังใช้งานอยู่เท่านั้นที่ปลอดพันธะ AGPL และสิทธิ์นั้นเป็นแบบถาวรต่อ artifact นั้นแม้ token จะหมดอายุ แต่ “Generating new artifacts without those obligations requires a current commercial authorization”

พูดให้ชัดคือ: generator เป็นโอเพนซอร์สจริง แต่ “โค้ดที่มันพ่นออกมา” จะเป็น MIT/Apache ได้ก็ต่อเมื่อคุณจ่ายเงิน — ถ้าใช้ฟรี ผลลัพธ์ก็ติด AGPL ไปด้วย ซึ่งสำหรับทีมที่ต้องแจก SDK เป็นแพ็กเกจสาธารณะถือเป็นความแตกต่างที่ใหญ่มาก และเป็นจุดที่บทความของ Google กล่าวไว้ไม่ครบ

อีกสองข้อจากรีโปที่ควรรู้ก่อนเสียบเข้า CI:

• Telemetry เปิดโดยดีฟอลต์ ปิดด้วย export SPEAKEASY_DISABLE_TELEMETRY=true README ระบุเองว่าข้อมูลที่เก็บรวมถึง target/template ที่เลือก, ผลสำเร็จหรือล้มเหลว, OS/architecture, เวอร์ชัน generator และ CLI, run location, config/feature flag — และ เมื่อมีข้อมูล ยังอาจรวม server URL, ข้อมูลติดต่อฝ่ายสนับสนุน, ชื่อเอกสาร, เวอร์ชัน OpenAPI, customer/workspace identifier รวมถึง validation warning และ error ด้วย README ถึงกับเตือนเองว่า “Review document content before generating if telemetry remains enabled”
• ระบบ snapshot ที่ใช้ตรวจ output regression เป็นรีโปส่วนตัว — pull request จากภายนอกได้เห็นแค่สถานะรวมแบบ public-safe

มุมมอง AI Curator

ข่าวนี้ควรถูกอ่านเป็นสองชั้น และชั้นที่สองสำคัญกว่า

ชั้นแรกคือ บทเรียนเรื่อง supply chain ของ developer tooling — Google บริษัทที่มีวิศวกรเป็นแสน ยังโดนบีบให้รื้อ SDK pipeline ทั้งชุดในเวลาจำกัด เพราะ vendor รายหนึ่งถูกซื้อไป ถ้าเรื่องแบบนี้เกิดกับ Google ได้ ทีมไทยที่พึ่งบริการ SaaS ปิดซอร์สตัวเดียวสำหรับงาน codegen, eval หรือ agent runtime ก็ควรถามตัวเองตรง ๆ ว่า “ถ้าพรุ่งนี้เจ้านี้ถูกซื้อและปิด เราเสียเวลากี่สัปดาห์” คำตอบของ Google คือไม่ใช่แค่ย้ายผู้ให้บริการ แต่ต่อรองให้เครื่องมือถูกเปิดซอร์สเป็นเงื่อนไขของดีล — นั่นคือท่าที่ทีมเล็กทำไม่ได้ แต่ได้ประโยชน์ตามไปด้วย

ชั้นที่สองคือสิ่งที่เราอยากให้ผู้อ่านจำมากที่สุด: อย่าเชื่อคำว่า “open source” จากบล็อกประกาศ ให้ไปอ่าน LICENSE ในรีโปเสมอ กรณีนี้ไม่ใช่ความไม่ซื่อสัตย์ แต่เป็นการสรุปที่ลัดจนคลาดเคลื่อน — และมันคือรูปแบบที่เราเจอซ้ำ ๆ ในปีนี้ ตั้งแต่โมเดลที่ประกาศว่า MIT แต่ต้องพึ่ง encoder ที่ห้ามใช้เชิงพาณิชย์ ไปจนถึงโมเดลพี่น้องในรีโปเดียวกันที่ถือใบอนุญาตคนละแบบ สำหรับทีมไทยที่มักไม่มีฝ่ายกฎหมายในทีมวิศวกรรม ความต่างระหว่าง “generator เป็น AGPL” กับ “output เป็น AGPL” คือความต่างระหว่างใช้ได้กับใช้ไม่ได้

ในทางปฏิบัติ ข้อแนะนำคือ: ถ้าจะใช้ตัวนี้ปั้น SDK ภายในองค์กรที่ไม่ได้แจกออกไป เส้นทาง AGPL ฟรีก็มักไม่มีปัญหา แต่ถ้าคุณจะ publish package ขึ้น PyPI หรือ npm ให้ลูกค้าใช้ ต้องคุยเรื่อง commercial token ตั้งแต่วันแรก และอย่าลืมปิด telemetry ก่อนเอา spec ภายในไปรันใน CI — โดยเฉพาะทีมที่ spec มี endpoint และชื่อระบบภายในอยู่ในนั้น

ส่วนที่น่าตื่นเต้นที่สุดในทางเทคนิคกลับเป็นส่วนที่คนพูดถึงน้อยสุด: documentation MCP server generator ถ้าทุก API ในองค์กรสามารถกลายเป็น MCP server ที่ agent สอบถาม schema จริงได้ในคำสั่งเดียว ปัญหา “agent เขียนโค้ดเรียกเมธอดที่ไม่มีอยู่จริง” จะหายไปเป็นชั้น ๆ — และนี่คือสิ่งที่ทีมไทยควรลองก่อนใคร เพราะมันได้ผลทันทีแม้กับ API เดิมที่มีอยู่แล้ว

แหล่งข่าว

• Why client SDK generation belongs in the open — Google Developers Blog (17 ก.ย. 2026)
• speakeasy-api/openapi-generation — GitHub (README + LICENSING.md)
• Anthropic ซื้อกิจการ Stainless — รายงานก่อนหน้าของเรา (24 พ.ค. 2026)