MPL 2.0 คืออะไร?
โดย
เคยไหมครับ… คุณอยากเปิดซอร์สโค้ดให้คนอื่นเอาไปใช้และพัฒนาต่อ แต่ก็ยังแอบหวงโค้ดบางส่วนที่เป็นความลับหรือเป็นหัวใจสำคัญของธุรกิจ? ครั้นจะเลือก MIT ก็ดูจะปล่อยโล่งโจ้งเกินไป กลัวเขาจะยกโค้ดเราไปชุบมือเปิบเป็นของตัวเองหมด หรือจะเลือก GPL ก็เข้มงวดเกินไป แค่หยิบโค้ดเราไปแปะไว้นิดเดียวก็ต้องบังคับเปิดซอร์สหมดทั้งโปรเจกต์ซะงั้น!
แล้วมันมี License ไหนไหมที่ให้อิสระพอประมาณ แต่ก็ยังปกป้องโค้ดเราไว้ได้บ้าง?
คำตอบคือ มีครับ! และ สิ่งนั้นคือ Mozilla Public License 2.0 (MPL 2.0) License จากโครงการ Firefox เว็บเบราว์เซอร์ชื่อดังของ Mozilla ที่ถูกออกแบบมาให้ ยืดหยุ่นที่สุดในบรรดา Copyleft License” ด้วยแนวคิดแบบ File-Level Copyleft หรือ เรียกง่ายๆ ว่าสัญญาแบบรายไฟล์นั่นเอง
บทความนี้จะพาคุณไปรู้จักกับ MPL 2.0 กันแบบจัดเต็ม ตั้งแต่ประวัติ กลไกเด็ด การเปรียบเทียบ ไปจนถึงกรณีศึกษาซอฟต์แวร์ระดับโลกที่เลือกใช้ License นี้ พร้อมแล้วไปลุยกันเลยครับ!
- ★🦊 MPL 2.0 คืออะไร? และจุดเริ่มต้นจากหมาป่าไฟ
MPL ย่อมาจาก Mozilla Public License โดยเวอร์ชัน 2.0 เป็นใบอนุญาตแบบ Open Source ที่พัฒนาโดย Mozilla Foundation (องค์กรเบื้องหลัง Firefox) จุดเริ่มต้นนั้นมาจากความต้องการใช้กับโค้ดของโปรเจกต์ Netscape ในยุคที่ทำสงครามเบราว์เซอร์กับ Internet Explorer ครับ
⚪ วิวัฒนาการ
เริ่มจาก MPL 1.0 (ปี 1998) ขยับมาเป็น MPL 1.1 (ปี 1999) จนกระทั่งมาถึง MPL 2.0 (ปี 2012) ซึ่งเป็นเวอร์ชันล่าสุด และ เป็นเวอร์ชันที่แนะนำให้ใช้ในปัจจุบัน
⚪ การยอมรับ
MPL 2.0 ได้รับการรับรองจากทั้ง OSI (Open Source Initiative) และ FSF (Free Software Foundation) ว่าเป็น Free Software License ที่ถูกต้องตามมาตรฐาน
⚪ ความนิยม
ติดอันดับ Top 10 ลิขสิทธิ์ยอดนิยมบน GitHub (อัปเดตล่าสุดปี 2026) และ มีโปรเจกต์ระดับโลกเลือกใช้มากมาย
⚪ ปรัชญาของ MPL
คือการเป็น Weak Copyleft หรือ Copyleft แบบผ่อนปรน ซึ่งสร้างขึ้นมาเพื่อหาจุดสมดุลระหว่างการเปิดกว้างให้ธุรกิจนำไปใช้ในเชิงพาณิชย์ได้ กับ การปกป้องโค้ดต้นฉบับไม่ให้ถูกนำไปดัดแปลงเป็นซอฟต์แวร์ปิดโดยไม่ยอมส่งซอร์สโค้ดที่แก้ไขกลับคืนสู่ชุมชน
เรียกได้ว่า MPL คือ ทางสายกลาง ระหว่าง MIT (เปิดสุดขีด) กับ GPL (เข้มงวดสุดขั้ว) นั่นเองครับ
- ★📁 หัวใจของ MPL สัญญาแบบ รายไฟล์
จุดเด่นที่ทำให้ MPL แตกต่างจากคนอื่นอย่างสิ้นเชิงคือแนวคิด File-Level Copyleft หรือ กฎลูกโซ่ที่มีผลเฉพาะในระดับไฟล์
- ●มันหมายความว่าอย่างไร?
ถ้าคุณเข้ามาแก้ไขซอร์สโค้ดภายในไฟล์เดิมของโปรเจกต์ที่เป็น MPL คุณต้องเปิดเผยซอร์สโค้ดของไฟล์นั้นภายใต้ข้อตกลง MPL เช่นเดิม
แต่ถ้าคุณสร้างไฟล์ใหม่ขึ้นมาเอง (เช่น เขียนคลาสใหม่ หรือโมดูลใหม่แยกออกไป) เพื่อเชื่อมต่อกับโค้ด MPL คุณไม่จำเป็นต้องเปิดซอร์สไฟล์ใหม่นั้นครับ คุณสามารถปิดเป็นความลับ หรือ ใช้ License อื่นตามใจชอบได้เลย
- ●เปรียบเทียบให้เห็นภาพชัดๆ
⚪ GPL : แตะโค้ดนิดเดียว โดนบังคับเปิดซอร์สทั้งโปรเจกต์ (เหมือนไวรัส)
⚪ MPL : แก้ไขไฟล์ไหน ก็เปิดซอร์สคืนกลับมาแค่ไฟล์นั้น (เป็นรายไฟล์ไป)
⚪ MIT : แตะยังไง แก้ยังไง ก็ไม่ต้องเปิดซอร์สอะไรเลย
- ●ตัวอย่างสถานการณ์
สมมติคุณทำโปรเจกต์หนึ่งแล้วมีไฟล์ดังนี้
⚪ utils.js (หยิบมาจากโอเพนซอร์สที่เป็น MPL) → ถ้าคุณแก้ไฟล์นี้ = ต้องเปิดซอร์ส utils.js คืนให้ชุมชน
⚪ main.js (คุณเขียนขึ้นมาเองใหม่ทั้งหมด) → ไม่ต้องเปิดซอร์สปิดเป็นความลับทางการค้าได้เลย
⚪ api.js (คุณเขียนใหม่ แต่มีการเรียกใช้ฟังก์ชันจาก utils.js) → ถือเป็นไฟล์ใหม่ของคุณเองไม่ต้องเปิดซอร์สเช่นกัน
นี่คือความยืดหยุ่นระดับที่นักธุรกิจ และ นักพัฒนารักเลยล่ะครับ!
- ★📋 สิทธิ์และหน้าที่ของผู้ใช้งาน
✅ สิทธิ์ที่คุณได้รับ (Permissions)
✅ ใช้ในเชิงพาณิชย์ : นำไปขาย นำไปทำซอฟต์แวร์บริการ (SaaS) หรือใช้ในธุรกิจได้เต็มที่
✅ ดัดแปลงและแจกจ่าย : สามารถแก้ไข เพิ่มเติม หรือ ลบฟีเจอร์ แล้วแจกจ่ายต่อได้
✅ รวมกับโค้ด License อื่นได้ : MPL เข้ากันได้ดีกับทั้ง MIT, BSD, Apache และ GPLv3
✅ สิทธิ์ในการใช้สิทธิบัตร : ได้รับสิทธิ์สิทธิบัตรจากผู้ร่วมพัฒนาโดยอัตโนมัติ
⚠️ หน้าที่ที่คุณต้องทำ (ห้ามลืม!)
1) ต้องเก็บ Copyright Notice ไว้
ห้ามลบชื่อผู้เขียนเดิม และ ข้อความสิทธิ์ในไฟล์ MPL เด็ดขาด
2) เปิดซอร์สเฉพาะไฟล์ที่แก้ไข หากมีการแก้โค้ดในไฟล์ที่เป็น MPL ต้องปล่อยไฟล์นั้นเป็น MPL 2.0 เสมอ
3) แจ้งการเปลี่ยนแปลง ควรระบุในโค้ดให้ชัดเจนว่าคุณมีการแก้ไขไฟล์นั้นๆ (เช่น การใส่คอมเมนต์ระบุวันที่และชื่อผู้แก้)
4) ถ้ารวมเป็นโปรเจกต์ใหญ่ คุณต้องแจ้งให้ผู้ใช้ทราบชัดเจนว่า โค้ดส่วนไหนที่เป็นไฟล์ของ MPL
5) ห้ามใช้ชื่อแอบอ้าง ห้ามนำชื่อ Mozilla หรือ ผู้เขียนเดิมไปใช้โฆษณาโปรโมทสินค้าของคุณโดยไม่ได้รับอนุญาต
- ★🔒 กลไกการคุ้มครองสิทธิบัตร
MPL 2.0 มีกลไกการคุ้มครองสิทธิบัตรที่แข็งแรงกว่า MIT/BSD แต่จะมีความเฉพาะเจาะจงมากกว่า Apache 2.0 ครับ
- ●ใจความสำคัญคือ
⚪ ผู้ร่วมพัฒนา (Contributor) ที่ส่งโค้ดเข้ามาในโปรเจกต์ MPL จะมอบสิทธิ์ในการใช้สิทธิบัตรที่เกี่ยวข้องกับโค้ดส่วนนั้นให้คุณโดยอัตโนมัติ
⚪ กฎการสิ้นสุดสิทธิ์ (Patent Termination Clause)
ถ้าวันหนึ่งคุณดันไปฟ้องร้องผู้ร่วมพัฒนาคนนั้นเรื่องสิทธิบัตรที่เกี่ยวกับโค้ดของเขา สิทธิ์ที่คุณเคยได้รับในการใช้สิทธิบัตรจากโปรเจกต์ MPL นี้จะสิ้นสุดลงทันที (กลไกเซฟตัวเองเหมือนกับ Apache 2.0 และ GPLv3)
⚪ จุดต่างจาก Apache 2.0
Apache 2.0 จะคุ้มครองสิทธิบัตรในภาพรวมของทั้งซอฟต์แวร์แบบกว้างๆ แต่ MPL 2.0 จะเน้นคุ้มครองสิทธิบัตรที่ผูกอยู่กับตัวไฟล์โค้ดของ MPL เป็นหลัก ดังนั้นถ้าโปรเจกต์ของคุณเน้นเรื่องสิทธิบัตรเข้มข้นมากๆ Apache 2.0 ยังคงได้เปรียบกว่าครับ
- ★🥊 การเปรียบเทียบมวย MPL 2.0 vs. MIT vs. GPLv3
⚪ ประเภทของ License
MIT เป็นแบบใจกว้างสุดๆ (Permissive) / MPL 2.0 เป็นแบบผ่อนปรน (Weak Copyleft ในระดับไฟล์) / GPLv3 เป็นแบบเข้มงวด (Strong Copyleft)
⚪ ขอบเขตการบังคับเปิดซอร์สเมื่อมีการแก้ไข
MIT ไม่ต้องเปิดอะไรเลย / MPL 2.0 บังคับเปิดเฉพาะไฟล์ที่เข้าไปแก้ไข / GPLv3 บังคับเปิดซอร์สโค้ดทั้งหมดในโปรเจกต์นั้น
⚪ การนำไปใช้ในซอฟต์แวร์ระบบปิด
MIT ทำได้รวดเร็ว / MPL 2.0 ทำได้ ตราบใดที่ไม่ไปแก้ไฟล์ฝั่ง MPL โดยตรง (หรือถ้าแก้ก็เปิดแค่ไฟล์นั้น) / GPLv3 ไม่สามารถทำได้หากมีการแจกจ่ายสู่สาธารณะ
⚪ การคุ้มครองด้านสิทธิบัตร (Patent Grant)
MIT ไม่มีระบุไว้ / MPL 2.0 มีระบุไว้ชัดเจนในระดับไฟล์ / GPLv3 มีระบุไว้ชัดเจน และ ครอบคลุมสูงกว่า
⚪ ความเข้ากันได้กับข้อตกลง GPLv3
MIT เข้ากันได้แบบทางเดียว / MPL 2.0 เข้ากันได้ดี (สามารถอัปเกรดโค้ด MPL ไปใช้ GPLv3 ร่วมกันได้) / GPLv3 เข้ากันได้อยู่แล้ว
⚪ ความซับซ้อนของกฎหมาย
MIT ต่ำมาก / MPL 2.0 ปานกลาง / GPLv3 สูงมาก
- ★🔗 ความเข้ากันได้กับ License อื่น
นี่คือจุดเด่นที่ทำให้ MPL 2.0 ชนะใจนักพัฒนา เพราะออกแบบมาให้รวมร่างกับคนอื่นได้ง่ายมากครับ
⚪ กลุ่ม Permissive (MIT, BSD, Apache 2.0)
คุณสามารถนำไฟล์ MPL ไปวางรวมกับโค้ดเหล่านี้ในโปรเจกต์เดียวกันได้เลย เรียกว่า Larger Work โดยไฟล์ของใครก็ใช้เงื่อนไขของคนนั้น แยกกันชัดเจน ไม่ล้ำเส้นกัน
⚪ กลุ่ม Copyleft (GPLv3)
ทาง FSF ประกาศรับรองเลยว่า MPL 2.0 เข้ากันได้กับ GPLv3 ดังนั้นคุณสามารถนำโค้ด MPL 2.0 ไปรวมและแจกจ่ายต่อภายใต้ GPLv3 ได้ (แต่ขยับย้อนกลับมาไม่ได้นะ)
⚠️ ข้อควรระวัง
MPL 2.0 เข้ากันไม่ได้กับ GPLv2 (อย่างเดียว) ดังนั้นถ้าโปรเจกต์เก่าของคุณล็อกไว้ว่าเป็น GPLv2 only จะไม่สามารถนำโค้ด MPL 2.0 ไปผสมได้ครับ
- ★🦾 กรณีศึกษา ซอฟต์แวร์ระดับโลกที่ใช้ MPL
⚪ Firefox & Thunderbird
สองโปรเจกต์หลักของ Mozilla แน่นอนว่าใช้ MPL เพื่อให้แกนหลักของเบราว์เซอร์ได้รับการพัฒนา และ ส่งต่อโค้ดกลับมา แต่ในขณะเดียวกันก็ยอมให้เหล่านักพัฒนาภายนอกสร้าง Add-on หรือส่วนเสริมแบบปิดเพื่อทำเงินได้โดยไม่ต้องเปิดซอร์สโค้ดของตัว Add-on
⚪ LibreOffice
ชุดโปรแกรม Office แจกฟรีที่แยกตัวมาจาก OpenOffice ปรับมาใช้ MPL 2.0 เพื่อให้โค้ดมีความยืดหยุ่นในการพัฒนาร่วมกับชุมชนมากขึ้น
⚪ Unity (Game Engine)
ในส่วนของระบบ Mono (C# runtime) ที่ Unity นำมาใช้เลือกใช้ MPL เพื่อช่วยให้ผู้สร้างเกมสามารถสร้างเกมแบบปิดเพื่อขายได้ โดยที่หากมีการแก้ไขตัวแกนของ Mono ค่อยส่งโค้ดกลับคืนมา
⚪ MariaDB
ระบบฐานข้อมูลชื่อดัง เลือกใช้ MPL ในส่วนของปลั๊กอิน และ Storage Engine บางตัวเพื่อดึงดูดภาคธุรกิจ
⚪ Syncthing
เครื่องมือซิงค์ข้อมูลแบบ P2P เลือกใช้ MPL เพื่อต้องการให้คนที่เอาโค้ดไปแก้ต้องแชร์โค้ดหน้านั้นคืนมา แต่ไม่ไปบังคับเปิดซอร์สส่วนอื่นๆ ของระบบที่ธุรกิจนำไปต่อยอด
- ★🎯 บทสรุป เมื่อไหร่ที่คุณควรเลือกใช้ MPL 2.0?
✅ เลือก MPL 2.0 ทันที ถ้าคุณ
1) สร้าง Library หรือ Framework
ที่แยกโครงสร้างไฟล์ชัดเจน และอยากให้คนอื่นแก้ไขแล้วส่งโค้ดไฟล์นั้นกลับมาพัฒนาชุมชน
2) ทำซอฟต์แวร์เชิงพาณิชย์
ที่ต้องมีการหยิบยืมซอฟต์แวร์โอเพนซอร์สมาใช้ แต่ไม่อยากเสี่ยงโดนบังคับเปิดซอร์สโค้ดหลักของบริษัททั้งหมดเหมือน GPL
3) ต้องการข้อตกลงที่คุ้มครองสิทธิบัตรในระดับหนึ่ง แต่ไม่ชอบความยาวเหยียด และ เงื่อนไขที่ซับซ้อนเกินไปของ Apache 2.0
4) ต้องการความยืดหยุ่นสูง
ในการเอาโปรเจกต์ไปทำงานร่วมกับซอฟต์แวร์ที่ใช้ลิขสิทธิ์อื่นๆ ทั้ง MIT และ GPLv3
❌ยังไม่ควรเลือก MPL ถ้า
1) อยากให้คนเอาโค้ดไปทำอะไรก็ได้แบบ 100% โดยไม่คิดจะเอาโค้ดคืนเลย → ไป MIT หรือ BSD
2) ต้องการบังคับให้ทุกคนในโลกที่เอาโค้ดไปใช้ต้องเปิดซอร์สโค้ดทุกส่วน ของระบบ → ไป GPLv3
3) ทำระบบ Web Service หรือ Cloud (SaaS) แล้วอยากบังคับให้คนที่เอาไปเปิดบริการบนคลาวด์ต้องเปิดซอร์สด้วย → ไป AGPL เพราะ MPL ไม่ได้คลุมถึงช่องโหว่นี้ครับ
- ★💬 คำส่งท้าย
MPL 2.0 คือ GPL ในแบบที่สตาร์ทอัพรักครับ เพราะมันยอมให้คุณปกป้องซอร์สโค้ดในส่วนที่เป็นแกนกลางที่เป็นประโยชน์ต่อส่วนรวม แต่ในขณะเดียวกันก็เปิดพื้นที่ให้ภาคธุรกิจได้เติบโตและเก็บรักษาความลับทางการค้าในส่วนอื่นๆ ได้อย่างสบายใจ
ถ้าเปรียบเทียบให้เห็นภาพง่ายๆ:
- MIT = รั้วเปิดกว้าง ยินดีต้อนรับทุกคนให้เข้ามาหยิบอะไรออกไปก็ได้
- MPL = รั้วรอบขอบชิด ใครเข้ามาแก้ของในบ้านต้องบอก (เปิดซอร์สคืนมา) แต่หลังบ้านคุณจะสร้างตึกปิดส่วนตัวอะไรเพิ่มเติม...เราไม่ยุ่ง
- GPL = พื้นที่ส่วนรวม ทุกคนต้องแชร์ทุกอย่างร่วมกัน ห้ามมีความลับเด็ดขาด
ในยุคปัจจุบัน การเลือก License ที่เหมาะสมกับโมเดลธุรกิจสำคัญพอๆ กับการเลือก Stack เทคโนโลยีเลยครับ และ MPL 2.0 คือคำตอบที่ใช่ที่สุดสำหรับคนที่อยากให้โลกได้ร่วมใช้ประโยชน์จากโค้ดของเรา แต่ก็ยังอยากรักษาหัวใจหลักและอนาคตของธุรกิจเอาไว้
คุณล่ะครับเคยใช้ MPL ในโปรเจกต์ตัวเองไหม? หรือกำลังชั่งใจระหว่าง MIT กับ GPL อยู่? คอมเมนต์มาคุยกันได้เลยนะครับ! 🦊✨
✏️ Shoper Gamer
- ✓MIT License คืออะไร? 👇
- ✓Apache 2.0 คืออะไร? 👇
- ✓GNU License คืออะไร 👇
Credit :
👇
- ●https://www.mozilla.org/en-US/MPL/2.0/
- ●https://www.newcastle.edu.au/library/teaching-and-research-support/copyright/open-licensing/other-licences/mozilla-public-license-mpl-for-software
- ●https://fossa.com/blog/open-source-software-licenses-101-mozilla-public-license-2-0/
- ●https://dev.to/vitalisorenko/unveiling-the-mozilla-public-license-20-a-deep-dive-into-open-source-licensing-and-fair-code-ckn
โฆษณา
- ดาวน์โหลดแอปพลิเคชัน
- © 2026 Blockdit
