สัญญาจ้างพัฒนา Mobile Application ต้องมีอะไรบ้าง

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

• แนบรุ่นระบบและอุปกรณ์ทดสอบให้ชัด เพราะคำว่าใช้ได้ทุกเครื่องไม่มีเกณฑ์ตรวจรับ
• ชื่อเจ้าของบัญชีร้านแอป กุญแจลงนาม และบัญชีรับเงินต้องตรวจตั้งแต่ก่อนเริ่มงาน
• ร้านแอปเป็นผู้ตัดสินอนุมัติแอป ควรระบุผู้แก้และผู้จ่ายเมื่อถูกปฏิเสธตามข้อ 5
• หากใช้ข้อมูลผู้ใช้จริงให้ตรวจผู้ประมวลผลและการโอนต่างประเทศตาม พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล ม.28–29, 37(4), 40
• อากรจ้างทำของลักษณะ 4 คำนวณจากสินจ้างทั้งสัญญา ไม่ใช่รวมค่าใช้บริการภายนอกที่จ่ายตรง
• งานที่จ้างทำ ลิขสิทธิ์เป็นของผู้ว่าจ้างเว้นแต่ตกลงไว้เป็นอย่างอื่นตาม พ.ร.บ.ลิขสิทธิ์ ม.10 ถ้าจะให้ผู้พัฒนาเก็บสิทธิไว้ ต้องเขียนไว้โดยชัดแจ้งเพราะเป็นการยกเว้นหลักกฎหมาย
• บัญชีร้านแอปและกุญแจลงนามต้องอยู่ในชื่อผู้ว่าจ้างเสมอ เพราะเปลี่ยนผู้พัฒนาแล้วต้องอัปเดตแอปเดิมต่อได้ ไม่ใช่ต้องปล่อยแอปใหม่และเสียผู้ใช้เดิมทั้งหมด

• หากจ้างสร้างระบบซอฟต์แวร์ทั่วไปที่ไม่ต้องยื่นร้านแอป ให้ใช้ สัญญาจ้างพัฒนาซอฟต์แวร์ / ระบบสารสนเทศ
• หากจ้างทำเว็บไซต์ที่เผยแพร่ผ่านโดเมน ให้ใช้ สัญญาจ้างทำเว็บไซต์ (รวมโดเมนและโฮสติ้ง)
• หากเพียงสมัครใช้แอปสำเร็จรูปโดยไม่สร้างงานใหม่ ให้ใช้สัญญาอนุญาตใช้ซอฟต์แวร์หรือบริการที่ตรงรูปแบบจริง
• สัญญาจ้างพัฒนาเว็บไซต์และซอฟต์แวร์ ภาษาอังกฤษ — ใช้ Website and Software Development Agreement — สัญญาจ้างพัฒนาเว็บไซต์และซอฟต์แวร์ ภาษาอังกฤษ

ส่วนจ้างพัฒนาแอปเข้าลักษณะตราสาร 4 จ้างทำของ อากร 1 บาทต่อสินจ้างทุก 1,000 บาทหรือเศษ ผู้รับจ้างเป็นผู้เสียและขีดฆ่าแสตมป์ตามบัญชีอัตราอากรแสตมป์ คำนวณจาก … ได้ (ตามที่ระบบคำนวณจากค่าที่กรอก) โดยไม่รวมภาษีมูลค่าเพิ่มและค่าใช้บริการภายนอกที่ผู้ว่าจ้างจ่ายตรง คู่ฉบับส่วนจ้างทำของมีอากร (ตามที่ระบบคำนวณจากค่าที่กรอก) ให้ตรวจคู่ฉบับตามลักษณะ 23 และผู้มีหน้าที่เสียอากรตามกรณี

เมื่อสินจ้างตั้งแต่หนึ่งล้านบาทขึ้นไปต้องตรวจการชำระเป็นตัวเงินตามประกาศอธิบดีกรมสรรพากรเกี่ยวกับอากรแสตมป์ ฉบับที่ 37 หากลงนามอิเล็กทรอนิกส์ให้ตรวจวิธียื่นอากรอิเล็กทรอนิกส์และกำหนดภายใน 15 วันตามหลักเกณฑ์ที่ใช้บังคับ ตราสารที่ปิดอากรไม่บริบูรณ์ใช้เป็นพยานหลักฐานในคดีแพ่งไม่ได้จนชำระอากรและเงินเพิ่มตามประมวลรัษฎากร มาตรา 113–114 และ 118

สัญญาจ้างพัฒนาแอปไม่ต้องจดทะเบียน แต่มีสองอย่างที่ร้านแอปบังคับและต้องเตรียมก่อนยื่น

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

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

และถ้าผู้รับจ้างเข้าถึงข้อมูลผู้ใช้จริง กฎหมายคุ้มครองข้อมูลส่วนบุคคลบังคับให้ต้องมี สัญญาระหว่างผู้ควบคุมกับผู้ประมวลผล แนบท้าย ไม่ใช่ทางเลือก และถ้าไม่มี ผู้ว่าจ้างเป็นฝ่ายผิดเองเพราะเป็นผู้ควบคุมข้อมูล ในคลังของเว็บนี้ใช้ «สัญญาประมวลผลข้อมูลส่วนบุคคล (ผู้ควบคุม–ผู้ประมวลผล)» เป็นผนวกได้

หากผู้ว่าจ้างเป็นนิติบุคคลที่จ่ายค่าจ้างทำของให้ผู้รับในประเทศไทยตามเงื่อนไข ควรหักภาษี ณ ที่จ่ายอัตราปกติร้อยละ 3 ตามคำสั่งกรมสรรพากร ที่ ท.ป.4/2528 ข้อ 8 และออกหนังสือรับรอง ตรวจอัตราปัจจุบันก่อนจ่าย หากผู้รับจ้างจดทะเบียนภาษีมูลค่าเพิ่ม ให้ออกใบกำกับภาษีเมื่อความรับผิดเกิดตามประมวลรัษฎากร มาตรา 78/1 และ 86 ค่าใช้บริการร้านแอปหรือคลาวด์จากต่างประเทศต้องตรวจหน้าที่ภาษีเฉพาะรายการก่อนชำระ

สัญญาพัฒนาเว็บมีเรื่องโดเมนกับโฮสติ้ง สัญญาพัฒนาแอปมีเรื่องที่หนักกว่านั้นคือ กุญแจลงนามไฟล์แอป

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

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

การถูกปฏิเสธตอนยื่นตรวจเป็นเรื่องปกติ ไม่ใช่ความผิดพลาดร้ายแรง แต่ต้องตกลงไว้ก่อนว่าใครแก้และใครจ่าย เพราะสาเหตุมาจากคนละฝั่งกัน

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

ข้อ 5 แบ่งตามสาเหตุแบบนี้ ซึ่งเป็นธรรมกว่าการโยนให้ฝ่ายเดียวรับทั้งหมด และการโยนฝ่ายเดียวยังเสี่ยงเป็นข้อสัญญาที่ไม่เป็นธรรมด้วย

แอปไม่เหมือนเว็บตรงที่ ระบบปฏิบัติการออกรุ่นใหม่ทุกปีและบังคับให้แอปตามให้ทัน ถ้าไม่อัปเดต ร้านแอปอาจไม่ให้ส่งอัปเดตอีก หรือแอปเริ่มทำงานผิดบนเครื่องรุ่นใหม่

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

ถ้าแอปขายของดิจิทัลหรือรับสมัครสมาชิก ร้านแอปมักบังคับให้ใช้ระบบชำระเงินของเขาและหักส่วนแบ่ง เงินจึงเข้าร้านแอปก่อนแล้วจ่ายต่อมาเป็นรอบ

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

• บัญชีร้านแอปอยู่ในชื่อผู้รับจ้าง — ข้อผิดพลาดอันดับหนึ่ง เลิกจ้างแล้วอัปเดตแอปเดิมไม่ได้ และผู้ใช้เดิมตามมาไม่ได้
• ไม่เก็บสำเนากุญแจลงนาม — หายแล้วหายเลย ไม่มีใครกู้ให้ได้ แม้แต่ร้านแอปเอง
• ไม่ระบุรุ่นระบบที่รองรับ — พอระบบออกรุ่นใหม่แล้วเถียงกันว่าใครจ่ายค่าแก้
• คิดว่าตรวจรับงานแล้วเท่ากับแอปขึ้นร้านได้ — ข้อ 4 กับข้อ 5 แยกกันคนละเรื่อง งานอาจถูกตามสเปกทุกข้อแต่ร้านแอปยังปฏิเสธได้
• ลืมชุดพัฒนาภายนอกที่เก็บข้อมูลผู้ใช้ — เครื่องมือวิเคราะห์และรายงานแอปล่มเก็บข้อมูลไปด้วย ต้องประกาศในแบบแสดงการเก็บข้อมูลของร้านแอปและในนโยบายความเป็นส่วนตัว
• ไม่คิดเรื่องค่าบริการรายเดือนหลังส่งมอบ — บริการแจ้งเตือน คลาวด์หลังบ้าน และบัญชีนักพัฒนามีค่าใช้จ่ายต่อเนื่อง ข้อ 3 กำหนดให้แยกออกจากค่าจ้างและมีเพดาน
• ส่งไฟล์งานเข้าเครื่องมือ AI โดยไม่ขออนุญาต — ข้อ 10 กำหนดให้ทำได้เฉพาะเครื่องมือที่อนุมัติและจำกัดข้อมูลที่ส่ง
• จบงานแล้วไม่ได้ซอร์สโค้ดกับเอกสารสร้างไฟล์ — ได้แต่ไฟล์แอปสำเร็จรูปซึ่งแก้อะไรไม่ได้ ข้อ 12 กำหนดรายการส่งมอบไว้แล้ว ให้ตรวจทีละรายการตอนรับมอบ

• ตารางหน้าจอ ฟังก์ชัน รุ่นระบบ อุปกรณ์ทดสอบ งานหลังบ้าน งวดงาน และเกณฑ์ตรวจรับตามข้อ 1 และ 4
• หลักฐานเจ้าของบัญชีร้านแอป สิทธิสมาชิก ระบบแจ้งเตือน ที่เก็บซอร์สโค้ด และบัญชีกุญแจลงนาม โดยไม่แนบรหัสผ่านหรือกุญแจจริง
• รายการชุดพัฒนา โอเพนซอร์ส บริการภายนอก ค่าใช้จ่ายรายเดือน และข้อกำหนดของร้านแอปที่เกี่ยวกับการเผยแพร่
• คำอธิบายการเก็บข้อมูลในแอป ข้อมูลวิเคราะห์การใช้งานและข้อมูลแอปล่ม นโยบายความเป็นส่วนตัว ผู้ประมวลผลช่วง และประเทศที่เข้าถึงข้อมูลตาม พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล มาตรา 28–29, 37(4), 39 และ 40
• หากมีการซื้อในแอป ให้แนบรายการสินค้า ราคา อัตราหักของร้านแอป ผู้รับเงิน เงื่อนไขต่ออายุและคืนเงิน พร้อมกรณีทดสอบรายการซ้ำ

ทำสองฉบับข้อความตรงกัน คู่สัญญาเก็บฝ่ายละฉบับ ลงชื่อกำกับทุกหน้าและเอกสารแนบ พยานลงชื่อเมื่อมี ตรวจค่าจ้างทุกงวดรวมเท่ากับ … และตรวจว่าบัญชีร้านแอปเป็นชื่อผู้ว่าจ้างก่อนเริ่มงาน

ก่อนส่งข้อมูลผู้ใช้จริงให้ทดสอบด้วยข้อมูลจำลองก่อน หากต้องใช้ข้อมูลจริงให้ทำตามข้อ 10 และจำกัดสิทธิผู้พัฒนา ข้อความว่าเป็นผู้รับจ้างอิสระไม่ชี้ขาดสถานะ หากปฏิบัติจริงถูกควบคุมเวลา สถานที่ และวิธีทำงานอย่างลูกจ้าง อาจเข้าลักษณะจ้างแรงงานตาม ป.พ.พ. มาตรา 575 แทนจ้างทำของมาตรา 587

ข้อห้ามเรื่องบัญชี กุญแจ เงินสำรองจ่าย โอเพนซอร์ส เครื่องมือภายนอก และข้อมูลในข้อ 2, 3, 9, 10 และ 12 มีผลให้ผู้ฝ่าฝืนต้องคืนสิ่งที่รับไว้ ระงับความเสียหาย และรับผิดตามส่วนที่พิสูจน์ได้ตามข้อ 11 และ ป.พ.พ. มาตรา 387; หากมีการเข้าระบบหลังถูกถอนสิทธิหรือเผยแพร่ข้อมูลโดยมิชอบ ให้ตรวจ พ.ร.บ.ว่าด้วยการกระทำความผิดเกี่ยวกับคอมพิวเตอร์ พ.ศ. 2550 มาตรา 5–10 และกฎหมายข้อมูลส่วนบุคคลก่อนดำเนินการ

เขียนและตรวจทานโดย ภูวรา ครอบตะคุ ทนายความ (ใบอนุญาต 477/2558) · เนติบัณฑิตไทย · น.ม. กฎหมายทรัพย์สินทางปัญญาและสารสนเทศ — การเลือกประเด็น การจัดหมวด และคำอธิบายในบทความนี้เป็นงานอันมีลิขสิทธิ์ของผู้เขียน ส่วนตัวบทกฎหมายที่ยกมาไม่มีลิขสิทธิ์และตรวจกับราชกิจจานุเบกษาได้เสมอ · ทะเบียนบทความ OKC-8B1E47 · หากนำไปใช้ต่อ โปรดระบุชื่อผู้เขียนและลิงก์ต้นฉบับ