คำตอบหลัก
คนที่เขียนโค้ดไม่ได้เป็นเจ้าของโค้ดในแบบที่ธุรกิจของคุณต้องการโดยอัตโนมัติ กฎหมายไทยมีหลักทั่วไปที่ต่างกันระหว่างกรณีที่นักพัฒนาเป็นพนักงานกับกรณีที่เป็นผู้รับจ้างภายนอก และหลักเหล่านี้ครอบคลุมเฉพาะงานที่สร้างขึ้นเพื่อคุณจริง ๆ เท่านั้น
หลักกฎหมาย (พระราชบัญญัติลิขสิทธิ์ พ.ศ. 2537) โปรแกรมคอมพิวเตอร์เป็นงานวรรณกรรมที่ได้รับความคุ้มครอง (มาตรา 4) ถ้านักพัฒนาเป็นพนักงานหรือลูกจ้าง มาตรา 9 ให้ลิขสิทธิ์เป็นของผู้สร้างสรรค์ หากไม่ได้ตกลงเป็นหนังสือไว้เป็นอย่างอื่น โดยนายจ้างมีสิทธินำงานออกเผยแพร่ตามวัตถุประสงค์ของการจ้าง ถ้าเป็นการรับจ้างทำงาน มาตรา 10 ให้ผู้ว่าจ้างเป็นผู้มีลิขสิทธิ์ เว้นแต่ผู้สร้างสรรค์กับผู้ว่าจ้างตกลงกันเป็นอย่างอื่น ส่วนการโอนลิขสิทธิ์ต้องทำเป็นหนังสือลงลายมือชื่อทั้งสองฝ่าย (มาตรา 17)
มุมมองเชิงปฏิบัติของเรา อย่าพึ่งหลักทั่วไปอย่างเดียว ควรมีสัญญาเป็นหนังสือที่ระบุว่าใครเป็นเจ้าของอะไร โอนโค้ดให้บริษัทของคุณเป็นหนังสือ ระบุสิ่งที่ผู้พัฒนาเก็บไว้ได้ (เครื่องมือและโค้ดเดิมของเขา) และผูกการจ่ายเงินกับงวดงานที่ผ่านการทดสอบแล้ว เช็กลิสต์ในหัวข้อที่ 8 ใช้ส่งให้ทนายความตรวจได้ทันที
1. source code ได้รับความคุ้มครองลิขสิทธิ์ในประเทศไทยหรือไม่
ได้ มาตรา 4 ให้ความหมายของ "วรรณกรรม" รวมถึงโปรแกรมคอมพิวเตอร์ และนิยามโปรแกรมคอมพิวเตอร์ว่า คำสั่ง ชุดคำสั่ง หรือสิ่งอื่นใดที่นำไปใช้กับเครื่องคอมพิวเตอร์ เพื่อให้เครื่องทำงานหรือให้ได้ผลอย่างหนึ่งอย่างใด ไม่ว่าจะเป็นภาษาโปรแกรมแบบใด มาตรา 15 ให้เจ้าของลิขสิทธิ์มีสิทธิแต่ผู้เดียวในการทำซ้ำหรือดัดแปลง เผยแพร่ต่อสาธารณชน ให้เช่าต้นฉบับหรือสำเนางานโปรแกรมคอมพิวเตอร์ ให้ประโยชน์อันเกิดจากลิขสิทธิ์แก่ผู้อื่น และอนุญาตให้ผู้อื่นใช้สิทธิ
มาตรา 4 ยังให้ความหมายของ "ดัดแปลง" ในส่วนโปรแกรมคอมพิวเตอร์ว่ารวมถึงการทำซ้ำโดยเปลี่ยนรูปใหม่ ปรับปรุงแก้ไขเพิ่มเติมในส่วนอันเป็นสาระสำคัญ โดยไม่มีลักษณะเป็นการจัดทำขึ้นใหม่ ดังนั้นหากภายหลังคุณจ้างนักพัฒนาคนที่สองมาแก้โค้ดของคนแรก คุณต้องมีสิทธิดัดแปลง ไม่ว่าจะโดยเป็นเจ้าของลิขสิทธิ์เองหรือโดยสัญญาอนุญาตที่ครอบคลุมการแก้ไข
2. จ้างนักพัฒนาแล้ว ใครเป็นเจ้าของโค้ด
ขึ้นอยู่กับลักษณะความสัมพันธ์
| ความสัมพันธ์ | หลักทั่วไป | ในทางปฏิบัติ |
|---|---|---|
| พนักงาน (สัญญาจ้างแรงงาน) | มาตรา 9: ลิขสิทธิ์เป็นของผู้สร้างสรรค์ (พนักงาน) เว้นแต่ตกลงเป็นหนังสือเป็นอย่างอื่น นายจ้างนำงานออกเผยแพร่ได้ตามวัตถุประสงค์ของการจ้าง | บริษัทมีสิทธิใช้ตามขอบเขตของงาน แต่ไม่แน่ว่าเป็นเจ้าของ ควรเพิ่มข้อตกลงเรื่องความเป็นเจ้าของในสัญญาจ้างแรงงาน |
| ผู้รับจ้างหรือบริษัทรับพัฒนา (จ้างทำของ) | มาตรา 10: ผู้ว่าจ้างเป็นผู้มีลิขสิทธิ์ เว้นแต่ผู้สร้างสรรค์กับผู้ว่าจ้างตกลงกันเป็นอย่างอื่น | หลักนี้ช่วยได้ แต่เฉพาะงานที่สร้างขึ้นตามที่ว่าจ้าง |
| ฟรีแลนซ์ที่ทำงานโดยไม่มีสัญญา | ในทางปฏิบัติไม่ชัด ต้องดูข้อเท็จจริงว่าเป็นจ้างแรงงาน จ้างทำของ หรืออย่างอื่น | หลีกเลี่ยง ควรทำสัญญาก่อนเริ่มงาน |
ในกรณีผู้รับจ้าง สัญญามักเป็นสัญญาจ้างทำของ ซึ่งมาตรา 587 แห่งประมวลกฎหมายแพ่งและพาณิชย์ให้ความหมายว่า เป็นสัญญาที่ผู้รับจ้างตกลงทำการงานสิ่งใดสิ่งหนึ่งจนสำเร็จ และผู้ว่าจ้างตกลงให้สินจ้างเพื่อผลสำเร็จของการนั้น งานพัฒนาซอฟต์แวร์ที่กำหนดขอบเขตชัดเจนมักเข้าลักษณะนี้ ส่วนงานแบบรายเดือน การส่งคนมาทำงานร่วมกับทีม หรือบริการดูแลต่อเนื่อง อาจใกล้เคียงสัญญาจ้างแรงงานหรือสัญญาบริการมากกว่า ชื่อสัญญาที่เขียนไว้จึงไม่ใช่ตัวตัดสินด้วยตัวเอง
3. ทำไมยังต้องมีหนังสือโอนลิขสิทธิ์
มีสี่เหตุผล
- หลักทั่วไปมีช่องว่าง มาตรา 10 ครอบคลุมเฉพาะงานที่ผู้พัฒนาสร้างขึ้นตามที่ว่าจ้าง ไลบรารี เฟรมเวิร์ก เทมเพลต และโค้ดที่ผู้พัฒนามีอยู่ก่อนโครงการไม่ใช่งานที่สร้างขึ้นเพื่อคุณ
- ตกลงเป็นอย่างอื่นได้ ถ้าเงื่อนไขมาตรฐานของบริษัทรับพัฒนาเขียนว่า "ผู้พัฒนาสงวนสิทธิ์ทั้งหมด" นั่นคือ "ตกลงกันเป็นอย่างอื่น" ตามกฎหมาย
- การพิสูจน์ ข้อสัญญาที่ลงนามว่า "โค้ด เอกสาร และงานออกแบบที่สร้างขึ้นในโครงการเป็นของผู้ว่าจ้าง" พิสูจน์ได้ง่ายกว่าการโต้เถียงเรื่องลักษณะความสัมพันธ์มาก
- มาตรา 17 หากต้องการ "โอน" ไม่ใช่เพียงอนุญาตให้ใช้ ต้องทำเป็นหนังสือลงลายมือชื่อผู้โอนและผู้รับโอน และถ้าไม่ระบุระยะเวลา กฎหมายถือว่าโอนมีกำหนดสิบปี จึงควรเขียนว่า "ตลอดอายุแห่งการคุ้มครองลิขสิทธิ์"
สิทธิทางศีลธรรมเป็นอีกเรื่องหนึ่ง มาตรา 18 ให้ผู้สร้างสรรค์มีสิทธิแสดงว่าตนเป็นผู้สร้างสรรค์ และห้ามผู้รับโอนหรือผู้อื่นบิดเบือน ตัดทอน ดัดแปลงจนเกิดความเสียหายต่อชื่อเสียงหรือเกียรติคุณ เว้นแต่ตกลงกันเป็นลายลักษณ์อักษรเป็นอย่างอื่น สัญญาจึงมักมีข้อกำหนดเรื่องการให้เครดิตผู้พัฒนาและการที่ผู้ว่าจ้างแก้ไขโค้ดได้
โอนหรืออนุญาตให้ใช้ สัญญาอนุญาตแบบเด็ดขาดไม่มีกำหนดเวลา ไม่เพิกถอนได้ และเป็นเอกสิทธิ์ บางครั้งก็ตอบโจทย์ธุรกิจได้ โดยเฉพาะเมื่อผู้พัฒนานำแพลตฟอร์มแกนกลางไปใช้กับลูกค้ารายอื่น หากเลือกแบบอนุญาต ให้ระบุว่าเป็นเอกสิทธิ์หรือไม่ แก้ไขได้หรือไม่ อนุญาตช่วงต่อ ให้ผู้ให้บริการเว็บโฮสติ้งใช้ได้หรือไม่ และโอนสิทธิได้หรือไม่เมื่อขายกิจการ ประเด็นคู่ขนานเรื่องชื่อและโลโก้ดูได้ใน ความเป็นเจ้าของแบรนด์และเครื่องหมายการค้าเมื่อตั้งบริษัท
4. เรื่อง repository และการเข้าถึงระบบ
เป็นเจ้าของโค้ดแต่ผู้พัฒนาถือสำเนาเดียว ก็แทบไม่มีประโยชน์ ควรเขียนสัญญาให้ควบคุมได้จริง
- repository อยู่ในบัญชีที่ บริษัทของคุณเป็นเจ้าของ (ระดับองค์กร) โดยเชิญผู้พัฒนาเข้ามาเป็นผู้ร่วมพัฒนา
- บัญชีคลาวด์ โดเมน แอปในสโตร์ API key และใบรับรอง ลงทะเบียนในนามบริษัท ไม่ใช่ชื่อบุคคล
- ผู้พัฒนา commit สม่ำเสมอ เพื่อให้โค้ดที่จ่ายเงินแล้วอยู่ใน repository ของคุณทุกงวด ไม่ใช่รอตอนท้าย
- ส่งมอบรหัสผ่านผ่านช่องทางที่ปลอดภัย และเปลี่ยนรหัสเมื่อส่งมอบ
- ข้อมูลลูกค้าหรือข้อมูลส่วนบุคคลในระบบทดสอบและระบบจริงต้องมีกติกาล่วงหน้า ดู เช็กลิสต์ PDPA และ นโยบาย AI ของบริษัทกับข้อมูลลูกค้า ซึ่งกล่าวถึง source code ในเครื่องมือ AI สาธารณะ
5. ส่วนประกอบโอเพนซอร์สและของบุคคลที่สาม
ซอฟต์แวร์สมัยใหม่เกือบทั้งหมดมีส่วนประกอบที่ผู้พัฒนาไม่ได้เขียนเอง และสัญญาอนุญาตของส่วนประกอบเหล่านั้นติดมากับงาน ในระดับปฏิบัติ
- สัญญาอนุญาตแบบผ่อนปรน โดยทั่วไปอนุญาตให้ใช้ในผลิตภัณฑ์เชิงพาณิชย์ได้ หากคงข้อความแจ้งตามที่กำหนดไว้
- สัญญาอนุญาตแบบ copyleft อาจกำหนดเงื่อนไขกับซอฟต์แวร์ที่นำไปรวมหรือเผยแพร่ร่วมกับส่วนประกอบนั้น และในบางกรณีอาจต้องเปิดเผย source code ของคุณภายใต้สัญญาอนุญาตเดียวกัน เงื่อนไขแตกต่างกันตามสัญญาอนุญาตแต่ละฉบับและวิธีใช้ (เช่น แจกจ่ายให้ลูกค้า หรือรันบนเซิร์ฟเวอร์ของคุณเอง) ควรให้ตรวจข้อความสัญญาอนุญาตจริงก่อนตัดสินใจใช้
- ส่วนประกอบเสียเงินของบุคคลที่สาม (SDK ฟอนต์ เทมเพลต API ชำระเงินหรือแผนที่) มักคิดค่าธรรมเนียมรายโครงการหรือรายผู้ใช้ และสิทธิอาจไม่โอนมาให้คุณโดยอัตโนมัติ
ข้อสัญญาที่ควรมี ผู้พัฒนาจัดทำรายการส่วนประกอบของบุคคลที่สามและโอเพนซอร์สทั้งหมดพร้อมสัญญาอนุญาต รับรองว่าไม่มีอะไรบังคับให้เปิดเผยโค้ดกรรมสิทธิ์ของคุณ และไม่เพิ่มส่วนประกอบที่มีเงื่อนไขเข้มงวดโดยไม่ได้รับอนุมัติ ผู้พัฒนาควรรับรองด้วยว่ามีสิทธิส่งมอบโค้ดและงานไม่ละเมิดสิทธิของผู้อื่น เราไม่ตัดสินสัญญาอนุญาตฉบับใดฉบับหนึ่งในที่นี้ ให้ตรวจข้อความของสัญญาอนุญาตที่เกี่ยวข้องเสมอ
6. งวดงานและการตรวจรับควรเป็นอย่างไร
กฎหมายไทยไม่ได้กำหนดขั้นตอนตรวจรับซอฟต์แวร์ไว้ สัญญาจึงต้องกำหนดเอง และเรื่องนี้สำคัญ เพราะตามมาตรา 598 แห่งประมวลกฎหมายแพ่งและพาณิชย์ ถ้าผู้ว่าจ้างยอมรับมอบงานทั้งที่ชำรุดบกพร่องโดยมิได้อิดเอื้อน ไม่ว่าโดยแสดงออกชัดหรือโดยปริยาย ผู้รับจ้างไม่ต้องรับผิด เว้นแต่ความชำรุดบกพร่องนั้นเป็นเช่นจะไม่พึงพบได้ในขณะรับมอบ หรือผู้รับจ้างปิดบังไว้ การนิ่งเฉยหลังส่งมอบจึงอาจเป็นผลร้ายแก่คุณ ควรกำหนดระยะเวลาตรวจรับที่แน่นอน และระบุว่าการนำไปใช้งานจริงเพื่อทดสอบไม่ถือเป็นการตรวจรับ
ตัวอย่างสมมติ (ตัวเลขเพื่อประกอบการอธิบาย) บริษัทจ้างทำระบบสั่งซื้อออนไลน์ราคา 600,000 บาท ตารางด้านล่างแสดงการผูกการจ่ายเงินกับงานที่ผ่านการทดสอบ
| งวดงาน | สิ่งที่ส่งมอบ | เกณฑ์ตรวจรับ | การจ่ายเงิน (ตัวอย่าง) |
|---|---|---|---|
| 1. ข้อกำหนดและการออกแบบ | เอกสารความต้องการ ผังขั้นตอนผู้ใช้ ภาพหน้าจอ แผนทางเทคนิค | ผู้ว่าจ้างลงนามรับรองขอบเขตเป็นหนังสือ ข้อสงสัยที่ค้างปิดครบ | 20% |
| 2. พัฒนาส่วนหลัก | ฟีเจอร์หลักทำงานบนเซิร์ฟเวอร์ทดสอบ โค้ดอยู่ใน repository ของผู้ว่าจ้าง | ผ่านกรณีทดสอบตามข้อกำหนด ไม่มีข้อบกพร่องระดับวิกฤตค้างอยู่ | 30% |
| 3. เชื่อมระบบและข้อมูล | ระบบชำระเงิน การแจ้งเตือน และการนำเข้าข้อมูลทำงานกับบัญชีทดสอบ | ผู้ว่าจ้างรันสคริปต์ทดสอบที่ตกลงกัน ข้อมูลที่นำเข้าตรงกับต้นทาง | 20% |
| 4. ทดสอบโดยผู้ใช้ (UAT) | ระบบเต็มรูปแบบบนสภาพแวดล้อม staging และบันทึกการเปลี่ยนแปลง | ผู้ว่าจ้างทดสอบตามระยะเวลาที่ตกลง จัดระดับข้อบกพร่อง ไม่มีข้อบกพร่องวิกฤตหรือสำคัญค้างอยู่ | 20% |
| 5. ขึ้นระบบจริงและส่งมอบ | ติดตั้งบนระบบจริง source code เอกสาร รหัสผ่าน การฝึกอบรม | ทดสอบเบื้องต้นบนระบบจริงผ่าน และลงนามรายการส่งมอบ | 10% (กันไว้จนลงนาม) |
ข้อสัญญาตรวจรับที่ดีควรมี ใครเป็นผู้ทดสอบ ทดสอบบนสภาพแวดล้อมใด ใช้กรณีทดสอบชุดไหน มีเวลาตรวจกี่วัน (เช่น 7 ถึง 14 วัน ปรับตามโครงการ) จัดระดับข้อบกพร่องอย่างไร (วิกฤต สำคัญ เล็กน้อย) ผู้พัฒนาต้องแก้ไขภายในเวลาใด และถ้าครบกำหนดตรวจแล้วไม่ตอบจะเป็นอย่างไร ผู้ว่าจ้างหลายรายต้องการให้การนิ่งเฉย ไม่ ถือว่ารับมอบ หากผู้พัฒนายืนยันให้มีข้อสันนิษฐานว่ารับมอบ ควรทำให้ระยะเวลานานพอที่จะทดสอบได้จริง
7. การเปลี่ยนแปลงงาน ข้อบกพร่อง และการเลิกสัญญา
ขอเปลี่ยนแปลงงาน (change request) ขอบเขตงานบานปลายเป็นสาเหตุข้อพิพาทที่พบบ่อยที่สุด ควรกำหนดให้การเปลี่ยนแปลงต้องทำเป็นหนังสือ ระบุราคา และลงนามทั้งสองฝ่ายก่อนเริ่มทำ พร้อมผลต่อกำหนดเวลา และระบุว่าใครเป็นผู้วินิจฉัยว่าเรื่องใดเป็น "การเปลี่ยนแปลง" หรือ "ข้อบกพร่อง"
การรับประกันและข้อบกพร่อง หากสัญญาไม่ได้กำหนดไว้ มาตรา 600 แห่งประมวลกฎหมายแพ่งและพาณิชย์ให้ผู้รับจ้างรับผิดสำหรับความชำรุดบกพร่องที่ปรากฏภายในหนึ่งปีนับแต่วันส่งมอบ (ห้าปีสำหรับสิ่งปลูกสร้างกับพื้นดิน ซึ่งไม่เกี่ยวกับซอฟต์แวร์) และมาตรา 601 ห้ามฟ้องผู้รับจ้างเมื่อพ้นหนึ่งปีนับแต่วันที่ความชำรุดบกพร่องปรากฏ บทบัญญัติเหล่านี้เขียนขึ้นสำหรับงานที่จับต้องได้ การที่ศาลจะนำมาใช้กับซอฟต์แวร์อย่างไรควรปรึกษาทนายความ จึงควรกำหนดการรับประกันไว้ในสัญญา ได้แก่ ระยะเวลา คำนิยามข้อบกพร่อง ระดับความรุนแรง เวลาตอบสนองและแก้ไข และบริการดูแลหลังหมดรับประกันว่าเป็นแพ็กเกจที่คิดเงินแยกหรือไม่
การเลิกสัญญา มาตรา 605 ให้ผู้ว่าจ้างบอกเลิกสัญญาจ้างทำของได้ตราบใดที่งานยังไม่แล้วเสร็จ โดยต้องชดใช้ค่าสินไหมทดแทนแก่ผู้รับจ้างสำหรับความเสียหายที่เกิดจากการเลิกสัญญา สัญญาควรเจาะจงกว่านั้น ได้แก่ ระยะเวลาบอกกล่าว ค่างานที่ทำไปแล้ว และที่สำคัญคือต้องส่งมอบโค้ดและเอกสารที่ทำไปทั้งหมดแม้โครงการหยุดกลางคัน รวมถึงสิทธิเลิกสัญญาเมื่อผู้พัฒนาผิดสัญญา (ส่งงานไม่ทันงวด ทิ้งงาน) และเมื่อฝ่ายคุณผิดสัญญา (ไม่ชำระเงิน) และผูกการโอนความเป็นเจ้าของกับการชำระเงิน เพื่อไม่ให้ต้องเลือกระหว่างจ่ายบิลที่มีข้อโต้แย้งกับสูญเสียโค้ด
การส่งมอบเมื่อจบงาน เมื่อเสร็จงานหรือเลิกสัญญา ควรได้รับ source code ครบ สคริปต์สำหรับ build โครงสร้างฐานข้อมูล วิธีติดตั้ง รายการสภาพแวดล้อมและรหัสผ่าน รายการส่วนประกอบโอเพนซอร์ส และการสนับสนุนถ่ายทอดความรู้ช่วงสั้น ๆ หากผู้พัฒนาต้องการเก็บ repository หรือโฮสติ้งไว้เอง ให้กำหนดบริการ escrow หรือการส่งสำเนาให้คุณเป็นประจำ
8. เช็กลิสต์ข้อสัญญา
- คู่สัญญา คำอธิบายโครงการ และข้อกำหนดเป็นหนังสือแนบท้ายสัญญา
- ราคาเหมาหรือเกณฑ์คิดตามเวลาและวัสดุ พร้อมตารางจ่ายเงินที่ผูกกับงวดที่ตรวจรับแล้ว
- ความเป็นเจ้าของ: ข้อตกลงโอนลิขสิทธิ์เป็นหนังสือให้บริษัทของคุณ (มาตรา 17) ระบุว่าโอนตลอดอายุแห่งการคุ้มครอง และลงนามทั้งสองฝ่าย
- ข้อยกเว้น: เครื่องมือและโค้ดเดิมของผู้พัฒนาระบุเป็นรายการ พร้อมสัญญาอนุญาตให้คุณแบบไม่มีกำหนดเวลา เพิกถอนไม่ได้ และครอบคลุมการแก้ไขและโฮสติ้ง
- รายการโอเพนซอร์สและของบุคคลที่สามพร้อมสัญญาอนุญาต และการรับรองว่าไม่มีหน้าที่เปิดเผยโค้ดของคุณ
- repository และบัญชีต่าง ๆ เป็นของบริษัทคุณ commit สม่ำเสมอ และส่งมอบรหัสผ่าน
- ขั้นตอนตรวจรับ: กรณีทดสอบ สภาพแวดล้อม ระยะเวลาตรวจ ระดับความรุนแรง และกฎเรื่องถือว่ารับมอบ
- กระบวนการขอเปลี่ยนแปลงงานเป็นหนังสือ พร้อมราคาก่อนเริ่มทำ
- ระยะเวลารับประกัน คำนิยามข้อบกพร่อง เวลาแก้ไข และเงื่อนไขบริการดูแล
- การรักษาความลับ การจัดการข้อมูลส่วนบุคคล และความปลอดภัย (ดูคู่มือ PDPA ข้างต้น)
- สิทธิทางศีลธรรมและการให้เครดิต: ผู้พัฒนาได้รับเครดิตอย่างไร และผู้ว่าจ้างแก้ไขงานได้
- การจ้างช่วงต้องได้รับอนุมัติ และผู้รับจ้างช่วงต้องโอนลิขสิทธิ์ในลักษณะเดียวกัน
- ค่าปรับหรือวิธีเยียวยาเมื่อล่าช้า วงเงินความรับผิด และการชดใช้กรณีถูกอ้างว่าละเมิดสิทธิ
- สิทธิเลิกสัญญา ค่างานที่ทำแล้ว และการส่งมอบโค้ดเมื่อเลิก (มาตรา 605 เป็นหลักทั่วไป)
- กฎหมายที่ใช้บังคับ ศาล และการลงนามอิเล็กทรอนิกส์ ดู การลงลายมือชื่ออิเล็กทรอนิกส์ในสัญญาบริษัท
สัญญาที่เป็นหนังสือพิสูจน์ได้ง่ายกว่าคำพูดมาก ดูเหตุผลใน สัญญาปากเปล่าบังคับได้หรือไม่
อ่านเพิ่มเติม
- ความเป็นเจ้าของแบรนด์และเครื่องหมายการค้าเมื่อตั้งบริษัทไทย
- นโยบาย AI ของบริษัทกับข้อมูลลูกค้า
- การลงลายมือชื่ออิเล็กทรอนิกส์ในสัญญาบริษัท
- สัญญาปากเปล่าบังคับได้หรือไม่
- BOI สำหรับผู้ก่อตั้ง SaaS: ทรัพย์สินทางปัญญาในต่างประเทศ
ให้โค้ดเป็นของบริษัทคุณตั้งแต่ในกระดาษก่อนจ่ายเงิน หนังสือโอนลิขสิทธิ์ที่ลงนามแล้ว repository ที่บริษัทเป็นเจ้าของ และการจ่ายเงินตามงวดที่ผ่านการทดสอบ ปกป้องคุณได้ดีกว่าหลักทั่วไปของกฎหมาย
เราร่างและตรวจสัญญาพัฒนาซอฟต์แวร์ สัญญาอนุญาตให้ใช้สิทธิ และสัญญาบริการให้ธุรกิจไทย ปรึกษาเบื้องต้นฟรี โทร 092-254-2045 หรือ ส่งรายละเอียดให้เรา ดูเพิ่มเติมได้ที่ สัญญาและเอกสาร และ ที่ปรึกษากฎหมายประจำ
คู่มือนี้เผยแพร่โดย สำนักงานกฎหมายสุวรรณวรา ลอว์เฟิร์ม — สำนักงานกฎหมายในจังหวัดขอนแก่น ก่อตั้งเมื่อปี 1986 เป็นข้อมูลทั่วไปเท่านั้น ไม่ใช่คำแนะนำทางกฎหมายสำหรับเรื่องใดเรื่องหนึ่งโดยเฉพาะ
