เกริ่นนำ (ข้อจำกัดความรับผิดชอบ)
บทความต้นฉบับ
Listed Providerに対するSPLAライセンス改定に関する私見 | DevelopersIO (Japanese)
เนื้อหานี้เป็นการพูดถึง Microsoft license ทางเราขอแจ้งข้อจำกัดความรับผิดชอบไว้ตามรายละเอียดทางด้านล่างนี้
ทางเราพยายามที่จะเขียนข้อมูลให้ถูกต้องที่สุดเท่าที่จะเป็นไปได้ ซึ่งนี่เป็นเพียงความเห็นส่วนตัวเท่านั้น โดยทางเราไม่รับประกันความถูกต้องของเนื้อหาเกี่ยวกับ license ในบทความนี้ โปรดทราบว่าหากเนื้อหาของบทความนี้มีข้อผิดพลาด และทำให้เกิดความเสียหายใด ๆ ก็ตาม ทางเราจะไม่รับผิดชอบใด ๆ ทั้งสิ้น
หากต้องการตรวจสอบความถูกต้องของ license กรุณาติดต่อ Microsoft และ AWS
รายละเอียดต่อจากนี้ไป จะเริ่มต้นจากการแก้ไข license ของ Microsoft โดย AWS จะได้รับผลกระทบจากการแก้ไขดังกล่าว
เกิดอะไรขึ้น
จากรายละเอียดทางด้านล่างจะไม่สามารถใช้ SPLA ของตนเอง (own SPLA) บน AWS ได้อีกต่อไปหลังจากวันที่ 30 กันยายน 2025
Due to Microsoft’s October 2022 license changes, service providers can only use their own SPLA on AWS until September 30, 2025. After that time, these customers should modernize or move to AWS license included offerings.
(ขีดเส้นเพิ่มโดยผู้เขียน)
ด้วยเหตุนี้ ผู้ที่กำลังใช้งาน SPLA ของตนเอง บน AWS ต้องดำเนินการย้ายไปใช้บริการที่ AWS ให้บริการ
ต้นเหตุของการแก้ไข license ของ Microsoft
เนื้อหาข้างต้นไม่ได้เพิ่มขึ้นอย่างกะทันหัน แต่มีการเผยแพร่เกี่ยวกับการแก้ไข license ของ Microsoft ตั้งแต่ปลายเดือนสิงหาคม 2022 และมีผลปรับใช้ตั้งแต่วันที่ 1 ตุลาคม 2022 ตามรายละเอียดด้านล่างนี้
โดยเนื้อหาของบทความนี้มุ่งเน้นไปที่การแก้ไขโปรแกรม Cloud Solution Provider (CSP) สำหรับการ resale Azure เป็นหลัก แต่ก็ยังมีเนื้อหาเกี่ยวกับการแก้ไข SPLA ในส่วนท้ายของบทความด้วย
To strengthen the hoster ecosystem by focusing the program on breadth hosters and encourage traditional outsourcers and datacenter providers, we are changing the SPLA terms to remove the ability to outsource SPLA licenses on Listed Provider datacenters. Traditional outsourcers and datacenter providers will benefit from this change, and it will help foster the hosting partner ecosystem. Any SPLA partner impacted by this change has until September 30, 2025 to transition from a Listed Provider for SPLA outsourced hosting or to license directly from the Listed Provider outside of their SPLA.
กล่าวโดยสรุปคือ
Microsoft ต้องการ "ลดเงื่อนไขในการเผยแพร่ผลิตภัณฑ์ Microsoft ให้กับผู้ให้บริการโฮสติ้งที่เป็น Partner ของ Microsoft"
แต่ในขณะเดียวกันก็มีการระบุถึง "ข้อบังคับที่เปลี่ยนไปของ Listed Provider อย่างเช่น AWS "
เงื่อนไขที่จะได้รับผลกระทบ
เงื่อนไขที่จะได้รับผลกระทบเกี่ยวกับ SPLA จากการแก้ไข license นี้
- มีการใช้งาน data center ของ Listed Provider
- มีการใช้ SPLA จากภายนอก (outsourced)
บนเว็บไซต์ของ AWS ใช้คำว่า "SPLA ของตนเอง (own SPLA)" แต่ผู้เขียนคิดว่าสำหรับผู้ที่ไม่คุ้นเคยกับ SPLA อาจเป็นเรื่องยากที่จะเข้าใจ เลยอยากจะลองอธิบายให้ฟัง
SPLA คืออะไร?
SPLA เป็นตัวย่อของ Microsoft Services Provider License Agreement โดยเป็น license สำหรับผู้ให้บริการที่เผยแพร่บริการที่ใช้ผลิตภัณฑ์ของ Microsoft
โดยปกติแล้ว license ของ ผลิตภัณฑ์ Microsoft จะออกแบบมาสำหรับองค์กรที่ต้องการซื้อ (ทำสัญญา) เพื่อใช้ในองค์กรของตนเอง แต่ในกรณีของ SPLA จะออกแบบมาสำหรับ "ผู้ให้บริการที่จะเผยแพร่บริการที่ใช้ผลิตภัณฑ์ของ Microsoft แก่บุคคลที่สาม"
โดยจะเรียกผู้ให้บริการเหล่านี้ว่า Service Provider (SP) ซึ่งโดยทั่วไปแล้วจะหมายถึงผู้ให้บริการโฮสติ้ง แต่ในบางกรณีอาจเป็นผู้ให้บริการด้านแอปพลิเคชัน หรือ system integrator ก็ได้
จุดสำคัญของ SPLA คือ "ผู้ใช้บริการจะทำสัญญาเพื่อใช้บริการของ SP เท่านั้น ไม่ได้ซื้อ (หรือทำสัญญา) กับผลิตภัณฑ์ของ Microsoft โดยตรง"
ตัวอย่างเช่น ในกรณีของ EC2 เป็นเพียง "การทำสัญญากับ AWS ในการใช้ virtual machine ที่มี Windows Server ที่ AWS เป็นผู้ให้บริการเป็นรายชั่วโมง" โดย "ผู้ใช้งานไม่ได้เช่า Windows Server license จาก Microsoft" เป็นต้น
อย่างไรก็ตาม ไม่ได้หมายความว่าผู้ใช้งานสามารถใช้ผลิตภัณฑ์ของ Microsoft ที่ให้บริการโดย SP ได้ไม่จำกัด
แต่จำเป็นต้องปฏิบัติตามข้อกำหนดของ SPUR(Services Provider Use Rights) (English) ด้วย
SPLA ของตนเอง (own SPLA)
พื้นฐานของ SPLA จะเป็นรูปแบบที่ SP เพียงแห่งเดียวเป็นผู้จัดหาบริการทั้งหมดตามรูปด้านล่าง
ตัวอย่าง เช่น "AWS ให้บริการ EC2 ที่มี Windows Server License Included " หรือ "การองรับ RDS for SQL Server" เป็นต้น
(อ้างอิงจาก SPLA License Guidebook หน้า 18)
นอกจากนี้ ยังอนุญาตให้ SP ติดตั้งซอฟต์แวร์ Microsoft บนเซิร์ฟเวอร์ของผู้ให้บริการ Data Center(SP อื่น) และมอบซอฟต์แวร์ดังกล่าวให้แก่ผู้ใช้งานได้อีกด้วย
ตัวอย่างเช่น "มีการใช้ infrastructure ของ AWS แต่ AWS ไม่มี EC2 ที่ติดตั้ง Office มาให้ จึงต้องให้ SP ติดตั้ง Office แยกเพื่อให้บริการ"
(อ้างอิงจาก SPLA License Guidebook หน้า 19)
- เอกสารอ้างอิง : SPLAライセンスガイドブック (PDF) (Japanese)
ผู้ใช้งานที่จะได้รับผลกระทบ และ ผู้ใช้งานที่ไม่ได้รับผลกระทบ
อย่างที่ได้เขียนไปในหัวข้อที่ผ่านมาว่าจะไม่สามารถใช้รูปแบบที่มีการใช้ "SPLA ของตนเอง (own SPLA)" ในกรณีของ Listed Provider สำหรับ Data Center ได้ตามที่ AWS ได้ระบุไว้ เนื่องจากตรงกับสัญญา SPLA สำหรับ SP
ด้วยเหตุนี้ ผู้ที่ใช้ผลิตภัณฑ์ Microsoft บน AWS โดยที่ใช้บริการของ SP ที่ใช้ SPLA นอกเหนือจาก AWS จะได้รับผลกระทบนี้
อย่างไรก็ตาม รูปแบบแรกจะไม่ได้รับผลกระทบจากการแก้ไข License จึงไม่มีผลกระทบต่อการใช้บริการ AWS โดยตรง
และผู้ใช้งาน AWS ทั่วไปจะไม่ได้รับผลกระทบใดๆ
เนื้อหาเพิ่มเติม : สรุปเป็นตารางทางด้านล่าง
หลังจากที่อ่าน Guidebook แล้ว คิดว่าตารางที่แสดงใน SPLA License Guidebook ค่อนข้างยากที่จะเข้าใจ เลยสรุปเป็นตารางให้ได้ดูกัน
หวังว่าจะเข้าใจเกี่ยวกับ "SPLA ของตนเอง" ได้ง่ายขึ้น
มาตรการรับมือ
จากรายละเอียดทั้งหมดทำให้เข้าใจสาเหตุที่แท้จริงคือการแก้ไข License ของ Microsoft ซึ่ง AWS และ SP ไม่มีทางเลือกอื่นนอกจากต้องปฏิบัติตาม
ด้วยเหตุนี้ จึงไม่มีประโยชน์ที่จะร้องเรียนกับ AWS หรือ SP และผู้ใช้งานไม่มีทางเลือกอื่นนอกจากต้องปฏิบัติตามการเปลี่ยนแปลงนี้
สำหรับวิธีการรับมือมีดังต่อนี้
1.ใช้บริการที่ผลิตโดย AWS
เนื่องจากเป็นปัญหาเรื่อง "SPLA ของตนเอง (own SPLA)" ทางออกที่ดีที่สุดคือการใช้บริการที่ผลิตโดย AWS
ตัวอย่างเช่น หากใช้งาน Visual Studio หรือ Microsoft Office เมื่อเร็ว ๆ นี้ Microsoft ได้นำเสนอ AMI ใหม่สำหรับการใช้งานเหล่านี้ ซึ่งคุณสามารถย้ายไปยังระบบนี้ได้ (แต่มีข้อกำหนดเบื้องต้นที่ค่อนข้างเข้มงวด)
https://aws.amazon.com/blogs/aws/new-run-visual-studio-software-on-amazon-ec2-with-user-based-license-model/
นอกจากนี้ หากเป็นเรื่องเกี่ยวกับ VDI ก็มีตัวเลือกในการย้ายไปยัง Amazon WorkSpaces หรือ Amazon AppStream 2.0 ได้เช่นกัน
แต่ก็น่าเสียดายที่ AWS ไม่ได้รองรับผลิตภัณฑ์ที่ SPLA ทั้งหมด จึงมีหลายกรณีที่ไม่สามารถโอนย้ายได้ และอาจมีความขัดแย้งด้านเรื่องของสภาพแวดล้อม หรือ ต้นทุนด้วย
อย่างไรก็ตาม โดยส่วนตัวแล้วคิดว่าการจัดการใบอนุญาตที่ยุ่งยากปล่อยให้ AWS ดูแลน่าจะดีที่สุด
2. ใช้บริการทดแทนผลิตภัณฑ์ของ Microsoft
แน่นอนว่าหากเป็นผลิตภัณฑ์ที่ไม่ใช่ของ Microsoft ก็สามารถแก้ไขปัญหาเรื่อง License ได้
และถือเป็นโอกาสที่ดีที่จะเปลี่ยนไปใช้บริการทดแทนที่ไม่มีข้อผูกมัดกับ License อีก
อย่างไรก็ตาม การค้นหาบริการทดแทนที่เหมาะสมก็จะตามมาด้วยปัญหาด้านสภาพแวดล้อม หรือ ต้นทุน ด้วย
3. นำ Microsoft license ไปใช้กับ AWS (BYOL)
ผลิตภัณฑ์บางตัวของ Microsoft มีระบบที่เรียกว่า "License Mobility" ซึ่งอนุญาตให้ย้าย License จากสภาพแวดล้อม On-Premise ไปยังสภาพแวดล้อมบนคลาวด์ได้
"License Mobility" เป็นสิทธิประโยชน์หนึ่งของ Software Assurance (SA) จึงจำเป็นต้องมีสัญญา SA ก่อน และจำเป็นต้องได้รับการอนุมัติจาก Microsoft ก่อนด้วย
ต่อไปนี้เป็นตัวอย่างการสอบถามที่พบบ่อยเกี่ยวกับผลิตภัณฑ์ที่เข้าเกณฑ์ของ "License Mobility"
- [NG] Windows Server OS : OS license ไม่รองรับ "License Mobility"
- [NG] Microsoft Office : Office ไม่รองรับ "License Mobility"
- [OK] Remote Desktop Service CAL : RDS CAL รองรับ "License Mobility"
ผลิตภัณฑ์อื่นๆ ตรวจสอบเพิ่มเติมได้ที่ที่เว็บไซต์ของ AWS
4. ใช้ Data Center ที่ไม่ใช่ Listed Provider
หากใช้สภาพแวดล้อม Data Center นอกจาก Listed Provider ก็จะสามารถใช้บริการ SPLA ของตนเองได้ตามปกติ
อย่างไรก็ตาม โปรดทราบว่า SPLA "เป็นสัญญาสำหรับการให้บริการโดย SP เท่านั้น" จึงมีความเป็นไปได้ที่ SP จะปฏิเสธการย้ายสภาพแวดล้อมการใช้งาน
โดยวิธีนี้เป็นไปได้ในทางทฤษฎี แต่ในทางปฏิบัติน่าจะเป็นเรื่องยาก
และส่วนตัวผู้เขียนคาดว่า SP จำนวนมากที่ใช้โครงสร้างพื้นฐานของ AWS อาจจะเลิกให้บริการในปี 2025
16
