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

การทำให้เข้าใจผิด - ใบอนุญาตโอเพนซอร์ส ทวีต

เมื่อในปี 1984 Richard Stallman ได้เริ่มโครงการ GNU เพื่อสร้างระบบปฏิบัติการฟรีเขาได้ค้นพบแนวคิดที่ว่าควรใช้ซอฟต์แวร์ร่วมกันระหว่างนักพัฒนาวิศวกรและผู้ใช้ และพวกเขาควรจะสามารถปรับปรุงได้โดยร่วมมือกันในลักษณะเดียวกับที่วิทยาศาสตร์มักจะทำ

ตัวเลือกนี้ตรงข้ามกับแนวคิดปกติของซอฟต์แวร์ลิขสิทธิ์ที่เลือกโดย บริษัท ซอฟต์แวร์และนักพัฒนาซอฟต์แวร์ส่วนใหญ่เพื่อแจกจ่ายและขายโปรแกรมของตน วันนี้กว่าสามสิบปีต่อมาซอฟต์แวร์โอเพนซอร์สยังคงเอาชนะภาคส่วนต่างๆในอุตสาหกรรมของเราได้อย่างช้าๆ: Linux, Android, Apache และ Git เป็นตัวอย่างผลิตภัณฑ์โอเพนซอร์สชั้นนำในหมวดหมู่ของพวกเขา

โอเพ่นซอร์สหรือซอฟต์แวร์เสรี?

ในบทความนี้ฉันจะใช้คำว่า 'โอเพนซอร์ส' และ 'ฟรี' เป็นคำพ้องความหมายในขณะที่อ้างถึงซอฟต์แวร์หรือใบอนุญาต ในความคิดของฉันทั้งสองคำแสดงความคิดเดียวกัน “ โอเพ่นซอร์ส” แสดงออกในทางปฏิบัติและทางเทคนิคและการใช้“ ฟรี” ให้ความสำคัญกับความหมายเชิงปรัชญาและการเมืองของแนวคิด

น่าเสียดายที่คำว่า“ ฟรี” ในภาษาอังกฤษนอกจากจะเป็นคำคุณศัพท์ที่เกี่ยวข้องกับ“ เสรีภาพ” แล้วยังหมายถึง“ โดยไม่ต้องเสียค่าใช้จ่าย” อีกด้วย นี่คือเหตุผลที่ฉันมักจะพูดว่า 'โอเพนซอร์ส'

คุณสมบัติทั่วไปของซอฟต์แวร์โอเพ่นซอร์ส

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

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

ซอฟต์แวร์โอเพนซอร์สทั้งหมดตาม Open Source Initiative ได้รับการแจกจ่ายภายใต้ใบอนุญาตที่ให้สิทธิ์แก่ผู้ใช้และผู้พัฒนา (ผู้ได้รับอนุญาต) สามารถดูรายชื่อทั้งหมดได้ในไฟล์ นิยามโอเพนซอร์ส แต่นี่คือบทสรุปพื้นฐาน:

1. แจกจ่ายซอฟต์แวร์ฟรี: ซอฟต์แวร์สามารถขายหรือมอบให้เป็นผลิตภัณฑ์หรือรวมอยู่ในชุดซอฟต์แวร์ ซึ่งสามารถทำได้โดยไม่ต้องจ่ายค่าลิขสิทธิ์ใด ๆ
2. ซอร์สโค้ดของซอฟต์แวร์ที่ได้รับอนุญาตจะรวมอยู่ในการแจกจ่ายหรืออย่างน้อยก็มีวิธีการที่ได้รับการเผยแพร่อย่างดีในการรับซอร์สโค้ด ซอร์สโค้ดนี้สามารถใช้สำหรับการพัฒนาซอฟต์แวร์เวอร์ชันดัดแปลง
3. อนุญาตให้สร้างผลงานที่ได้รับมาและใบอนุญาตอนุญาตให้เผยแพร่ภายใต้เงื่อนไขและใบอนุญาตเดียวกันกับซอฟต์แวร์ต้นฉบับ ขึ้นอยู่กับใบอนุญาตของซอฟต์แวร์ต้นฉบับในบางกรณีผลงานที่ได้รับเหล่านี้จะต้องแตกต่างจากซอฟต์แวร์ต้นฉบับโดยการเปลี่ยนชื่อหรือหมายเลขเวอร์ชันหรือสามารถแจกจ่ายได้ในรูปแบบของโปรแกรมแก้ไขซอร์สโค้ดเท่านั้น
4. ซอฟต์แวร์สามารถใช้งานได้โดยบุคคลหรือกลุ่มบุคคลและในด้านความพยายามใด ๆ โดยไม่มีข้อ จำกัด

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

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

Copyleft

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

ตามความแข็งแรงของมันมีสองประเภทของ copyleft:

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

นอกจากนี้ยังมีใบอนุญาตโอเพนซอร์สที่ไม่มี copyleft พวกเขาไม่สนใจเกี่ยวกับการเปิดกว้างของซอฟต์แวร์ที่ได้รับในอนาคต

การอนุญาต

ตามการอนุญาตใบอนุญาตยังสามารถแบ่งได้ใน:

• ใบอนุญาตที่เข้มงวด: เมื่อคุณไม่สามารถผสมซอฟต์แวร์ที่ได้รับอนุญาตที่มีลิขสิทธิ์ที่แข็งแกร่งกับแหล่งที่มาปิดหรือแม้กระทั่งกับซอฟต์แวร์ที่ได้รับอนุญาตอนุญาตมากกว่า
• ใบอนุญาตที่ได้รับอนุญาต: เมื่อผลิตภัณฑ์สามารถผสมกับซอฟต์แวร์ปิดแหล่งที่มาหรือซอฟต์แวร์ที่มีใบอนุญาตโอเพนซอร์สทั้งหมดได้

โดยปกติแล้วใบอนุญาต copyleft ที่เข้มงวดจะเข้มงวดเช่นกันและใบอนุญาต copyleft ที่อ่อนแอจะได้รับอนุญาตมากกว่า แต่ไม่จำเป็นต้องเป็นเช่นนั้น

ความแตกต่างของใบอนุญาตโอเพนซอร์ส

มีใบอนุญาตโอเพนซอร์สมากมาย Open Source Initiative ได้อนุมัติแล้วมากกว่า 80 รายการ บางอย่างซ้ำซ้อนและอาจถือได้ว่าเทียบเท่ากับคนอื่น ๆ อื่น ๆ มีความเฉพาะเจาะจงสำหรับผลประโยชน์ของผู้เผยแพร่ซอฟต์แวร์ (เช่นใบอนุญาต NASA) หรือสำหรับสภาพแวดล้อมหรือวัตถุประสงค์ที่กำหนด (เช่นใบอนุญาตชุมชนการศึกษาหรือใบอนุญาตแบบอักษรเปิด)

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

• ประเภทของ copyleft: อ่อนแอหรือแข็งแรงหรือไม่มีอยู่
• ประเภทของการอนุญาต: อนุญาตหรือเข้มงวด
• ภาระผูกพันในการเพิ่มประกาศลิขสิทธิ์ในซอร์สโค้ดหรือในอินเทอร์เฟซผู้ใช้
• การให้สิทธิบัตรอัตโนมัติแก่ผู้รับใบอนุญาต
• พิจารณาในฐานะผู้รับอนุญาตไม่เพียง แต่ฝ่ายที่เผยแพร่ซอฟต์แวร์เท่านั้น แต่ยังรวมถึงผู้ใช้ซอฟต์แวร์ด้วย (เพื่อให้ผู้ใช้บริการในระบบคลาวด์ที่ใช้ซอฟต์แวร์โอเพนซอร์สประเภทนี้ควรมีทางเลือกในการดาวน์โหลดซอร์สโค้ดของ ซอฟต์แวร์)

ปัญหาการผสมรหัสกับใบอนุญาตที่แตกต่างกัน

ตามสิ่งที่เราได้กล่าวไปแล้วก่อนหน้านี้ใบอนุญาตบางรายการอนุญาตให้ผู้ใช้รวมรหัสกับซอร์สโค้ดที่ได้รับอนุญาตต่างกัน (อาจมีเงื่อนไขเพิ่มเติม) กรณีนี้จะอนุญาตให้ผสมซอฟต์แวร์ลิขสิทธิ์โอเพนซอร์สประเภทนี้กับซอฟต์แวร์ปิด ตัวอย่างของใบอนุญาตประเภทนี้คือ MIT License

อื่น ๆ มีข้อ จำกัด มากกว่าดังนั้นซอร์สโค้ดจึงสามารถใช้ร่วมกับรหัสที่ได้รับอนุญาตในลักษณะเดียวกันเท่านั้นและผลลัพธ์สุดท้ายจะต้องได้รับอนุญาตด้วยใบอนุญาตดั้งเดิมเดียวกัน ตัวอย่างของใบอนุญาตประเภทนี้คือ General Public License (GPL)

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

ตัวอย่างหนึ่งของสถานการณ์นี้คือ ZFS ZFS เป็นระบบไฟล์ขั้นสูงและเป็นนวัตกรรมใหม่ที่รวมอยู่ใน OpenSolaris ในปี 2548 เป็นซอฟต์แวร์โอเพ่นซอร์สที่ได้รับอนุญาตภายใต้เงื่อนไขของ Common Development and Distribution License (CDDL) แม้ว่าจะเป็นรหัสโอเพ่นซอร์ส แต่ก็ไม่สามารถรวมเข้ากับเคอร์เนล Linux ได้เนื่องจากซอร์สโค้ดของ ลินุกซ์ เผยแพร่ภายใต้เงื่อนไขของ General Public License ซึ่งเป็นสัญญาอนุญาตแบบโอเพนซอร์สที่มีข้อ จำกัด อื่น ๆ ไบนารีของเคอร์เนลลินุกซ์ที่คอมไพล์ด้วยการสนับสนุน ZFS ไม่สามารถแจกจ่ายได้เนื่องจากข้อขัดแย้งของใบอนุญาต

ความขัดแย้งประเภทนี้จะแก้ไขได้ก็ต่อเมื่อเจ้าของโปรแกรมโอเพนซอร์สทั้งหมดเห็นด้วยกับการเปลี่ยนใบอนุญาตหรือเพิ่มเงื่อนไขข้อยกเว้นในใบอนุญาตซอฟต์แวร์ ตัวอย่างเช่นโปรแกรมลิขสิทธิ์ GPL จำนวนมากเชื่อมโยงกับไลบรารี OpenSSL การแจกจ่ายไลบรารี OpenSSL ได้รับอนุญาตโดยต้องมีวลีปรากฏในสื่อโฆษณาและการแจกจ่ายซ้ำใด ๆ เงื่อนไขพิเศษเหล่านี้เข้ากันไม่ได้กับ GPL และเนื่องจากผู้พัฒนาผลิตภัณฑ์ GPL ที่ใช้ OpenSSL ได้รวมข้อยกเว้นไว้ในใบอนุญาตโดยเฉพาะที่อนุญาตให้เชื่อมโยงกับ OpenSSL

คุณสมบัติที่แตกต่างของใบอนุญาตโอเพ่นซอร์ส

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

GNU ใบอนุญาตสาธารณะทั่วไป (GPL)

ก๊าซหุงต้ม เป็นใบอนุญาตโอเพนซอร์สที่ได้รับความนิยมมากที่สุด FSF สร้างขึ้นเพื่อเป็นใบอนุญาตสำหรับโครงการ GNU และยังเป็นใบอนุญาตของเคอร์เนล Linux

ลักษณะที่แตกต่าง:

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

โดยปกติข้อความใบอนุญาตที่ใช้จะมีข้อความที่ระบุว่ามีการแจกจ่ายซอฟต์แวร์ภายใต้เงื่อนไขของ GPL เวอร์ชัน N (หรือเวอร์ชันที่ใหม่กว่า)

ปัจจุบันมีสิทธิ์การใช้งาน GPL อยู่สองเวอร์ชัน: v2 และ v3 เวอร์ชัน 3 ได้รับการเผยแพร่ในปี 2550 เพื่อแก้ไขปัญหาบางอย่างที่เกิดขึ้นตั้งแต่รุ่น 2 ในปี 1991

GPL v3 มีข้อกำหนดและเงื่อนไขพิเศษบางประการการจัดการกับกฎระเบียบความเข้ากันได้กับใบอนุญาตโอเพนซอร์สอื่น ๆ การออกใบอนุญาตสิทธิบัตรการกำหนดเงื่อนไขในการใช้ซอฟต์แวร์ที่ได้รับอนุญาตจาก GPL เป็นเฟิร์มแวร์ในอุปกรณ์และคำนึงถึงแนวคิดในการจัดการสิทธิ์ดิจิทัล

ใบอนุญาต MIT

ใบอนุญาตโอเพนซอร์สมักเรียกว่า ใบอนุญาต MIT a.k.a. ใบอนุญาต X11 เป็นสิทธิ์การใช้งานแบบ non-copyleft ที่อนุญาตอย่างมากซึ่งช่วยให้ทุกคนสามารถใช้รหัสที่ได้รับอนุญาตโดยทั่วไปสำหรับสิ่งที่คุณต้องการตราบเท่าที่คุณเก็บข้อความลิขสิทธิ์ไว้และทราบว่าซอฟต์แวร์นั้นมาโดยไม่มีการรับประกันใด ๆ

ใบอนุญาตนี้ได้รับความนิยมอย่างมากและถูกใช้โดยหลายโครงการเช่น X Window System, Ruby on Rails, jQuery หรือ Node.js

เข้ากันได้กับ GPL ดังนั้นคุณจึงสามารถผสมรหัสที่ได้รับอนุญาตจาก MIT ลงในซอฟต์แวร์ GPL

Apache License 2.0

ใบอนุญาต Apache ถูกสร้างขึ้นโดย Apache Software Foundation (ASF) เพื่อเป็นใบอนุญาตสำหรับ Apache HTTP Server

เช่นเดียวกับ MIT License เป็นใบอนุญาตแบบ non-copyleft ที่อนุญาตให้ใช้ซอฟต์แวร์เพื่อวัตถุประสงค์ใด ๆ แจกจ่ายแก้ไขและแจกจ่ายผลงานที่ได้รับมาโดยไม่ต้องกังวลเรื่องค่าลิขสิทธิ์ ความแตกต่างหลักเมื่อเทียบกับใบอนุญาต MIT คือ:

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

ใบอนุญาตนี้น่าสนใจเนื่องจากใบอนุญาตสิทธิบัตรอัตโนมัติและข้อเกี่ยวกับการส่งเงินบริจาค

มันเข้ากันได้กับ GPL ดังนั้นคุณจึงสามารถผสมรหัสลิขสิทธิ์ Apache ลงในซอฟต์แวร์ GPL ได้

ใบอนุญาต BSD

มีใบอนุญาต BSD ที่แตกต่างกัน 3 ใบ ทั้งหมดนี้เป็นใบอนุญาตที่อนุญาตอย่างมากโดยไม่มี copyleft

ใบอนุญาต BSD 2 ข้อ (หรือ Simplified BSD License) เทียบเท่ากับ MIT License ที่ได้อธิบายไว้ก่อนหน้านี้

ใบอนุญาต BSD 3 ข้อ (หรือใบอนุญาต BSD ใหม่) เพิ่มหนึ่งประโยคโดยระบุว่าไม่สามารถใช้ชื่อของผู้ถือลิขสิทธิ์หรือชื่อของผู้มีส่วนร่วมในการรับรองหรือส่งเสริมผลิตภัณฑ์ที่ได้รับจากซอฟต์แวร์โดยไม่ได้รับอนุญาตเป็นลายลักษณ์อักษรล่วงหน้า เวอร์ชันนี้เข้ากันได้กับ GPL ช่วยให้คุณสามารถผสมรหัสที่ได้รับอนุญาต 3-clause-BSD ลงในซอฟต์แวร์ GPL

ใบอนุญาต BSD 4 ข้อ (หรือสิทธิ์การใช้งาน BSD ดั้งเดิม) เพิ่มข้ออื่นโดยระบุว่าสื่อโฆษณาทั้งหมดที่กล่าวถึงคุณสมบัติหรือการใช้ซอฟต์แวร์จะต้องแสดงการยอมรับว่าผลิตภัณฑ์มีซอฟต์แวร์ที่พัฒนาโดยผู้ถือลิขสิทธิ์ ใบอนุญาต BSD 4 ข้อนี้เข้ากันไม่ได้กับ GPL รหัสที่มีใบอนุญาตนี้ไม่สามารถเปลี่ยนใหม่ได้ตามข้อกำหนดของ GPL เนื่องจากข้อที่สี่เพิ่มข้อกำหนดที่ไม่จำเป็นใน GPL

GNU Lesser General Public License (LGPL)

LGPL ถูกสร้างขึ้นโดย FSF โดยเป็นการดัดแปลง GPL ด้วย copyleft ที่อ่อนกว่าทำให้สามารถเชื่อมโยงซอฟต์แวร์ที่ได้รับอนุญาตจาก LGPL กับซอฟต์แวร์อื่น ๆ ในต้นกำเนิด LGPL ย่อมาจาก 'Library General Public License' แต่หลังจากนั้นใช้ชื่อปัจจุบันว่า 'Lesser General Public License' ตามความเห็นของ FSF ที่ระบุว่าซอฟต์แวร์ทั้งหมดควรเป็นแบบฟรีและด้วยเหตุนี้ LGPL จึงไม่ควรเป็น ใช้โดยทั่วไป

คุณสามารถเชื่อมโยงซอร์สโค้ดกับไลบรารี LGPL หรือซอฟต์แวร์และแจกจ่ายผลลัพธ์สุดท้ายได้ตราบเท่าที่:

• คุณระบุซอร์สโค้ดของชิ้นส่วน LGPLed พร้อมการปรับเปลี่ยนทั้งหมดที่คุณได้ทำไว้
• ผู้ใช้ที่มีความรู้เพียงพอสามารถแทนที่ส่วน LGPLed ของโปรแกรมด้วยเวอร์ชันที่ปรับเปลี่ยนได้ สิ่งนี้สามารถทำได้โดยแจกจ่ายส่วน LGPLed ของโปรแกรมเป็นไลบรารีไดนามิก (DLL ใน Windows, .so ใน Linux / Unix) หรือให้รหัสออบเจ็กต์ของส่วนที่ไม่ใช่ LGPLed ของโปรแกรม

LGPL v3 เข้ากันได้กับ GPLv3 ดังนั้นคุณสามารถป้อนรหัส LGPLv3 ลงในซอฟต์แวร์ GPL ได้

ใบอนุญาตศิลปะ

ใบอนุญาตศิลปะ ในเวอร์ชันปัจจุบัน 2.0 เป็นใบอนุญาตโอเพนซอร์สที่อนุญาตโดยไม่มี copyleft คล้ายกับใบอนุญาต MIT

ข้อแตกต่างที่สำคัญระหว่างใบอนุญาต MIT และใบอนุญาตศิลปะคือข้อหลังกำหนดให้การแก้ไขใด ๆ ที่ทำกับรหัสต้องระบุไว้อย่างชัดเจน

ใบอนุญาตนี้เกือบจะใช้เฉพาะในชุมชน Perl

Artistic License 2.0 ปัจจุบันเข้ากันได้กับ GPL: คุณสามารถผสมรหัส Artistic-Licensed กับซอฟต์แวร์ GPL

ใบอนุญาตสาธารณะของ Microsoft (MS-PL)

ใบอนุญาตสาธารณะของ Microsoft ก่อตั้งขึ้นในปี 2008 โดย บริษัท นี้เป็นหนึ่งในใบอนุญาตโอเพนซอร์สที่สร้างโดย Shared Source Initiative

เป็นใบอนุญาตที่เข้มงวดและอ่อนแอ: อนุญาตให้สร้างและแจกจ่ายโปรแกรมปิดที่มาพร้อมรหัส MS-PLed แต่จำเป็นต้องใช้ MS-PL เป็นใบอนุญาตของงานที่ได้รับหากมีการแจกจ่ายในซอร์สโค้ด

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

MS-PL เข้ากันไม่ได้กับ GPL

ใบอนุญาตสาธารณะ Eclipse (EPL)

สิทธิ์การใช้งานสาธารณะ Eclipse เป็นไลเซนส์ที่สร้างขึ้นโดย Eclipse Foundation สำหรับสภาพแวดล้อมการพัฒนาแบบบูรณาการ เป็นสัญญาอนุญาตที่เข้มงวดและอ่อนแอคล้ายกับ LGPL ในหลาย ๆ ด้าน นอกจากนี้ยังรวมถึงอนุประโยคสำหรับการให้ใบอนุญาตสิทธิบัตรอัตโนมัติ

EPL เข้ากันไม่ได้กับ GPL

Mozilla Public License (MPL)

Mozilla Public License เวอร์ชัน 2.0 เป็นสิทธิ์การใช้งานที่อ่อนแอซึ่งได้รับอนุญาตซึ่งสร้างขึ้นโดย Mozilla Foundation สำหรับผลิตภัณฑ์

เราสามารถพิจารณาสิทธิ์การใช้งานนี้คล้ายกับ LGPL แต่ด้วยความแตกต่างที่สำคัญที่ MPL ยังอนุญาตให้มีการเชื่อมโยงโค้ด MPLed แบบคงที่เข้ากับซอฟต์แวร์ปิด

MPL ในเวอร์ชันปัจจุบัน 2.0 เข้ากันได้กับ GPL สิ่งนี้ไม่เป็นความจริงสำหรับ MPL เวอร์ชันก่อนหน้า

ใบอนุญาตการพัฒนาและการแจกจ่ายทั่วไป (CDDL)

CDDL เป็นสิทธิ์การใช้งานที่อ่อนแอและได้รับอนุญาตซึ่งสร้างโดย Sun (ปัจจุบันคือ Oracle) โดยใช้ MPL เวอร์ชัน 1.1 โดยทั่วไปมีคุณสมบัติเช่นเดียวกับ MPL มีการชี้แจงข้อกำหนด แต่ไม่มีการเปลี่ยนแปลงอย่างมีนัยสำคัญ

CDDL เป็นใบอนุญาตโอเพนซอร์สที่ Sun (ปัจจุบันเป็น Oracle) เลือกสำหรับผลิตภัณฑ์หลายประเภทเช่น OpenSolaris หรือ NetBeans เป็นต้น

เนื่องจากใบอนุญาตนี้เป็นไปตาม MPLv1.1 ใบอนุญาตนี้จึงไม่สามารถใช้งานร่วมกับ GPL ได้ดังนั้นคุณจึงไม่สามารถผสมแหล่งที่ได้รับอนุญาตจาก CDDL เข้ากับซอฟต์แวร์ลิขสิทธิ์ GPL ได้ หลายคนบอกว่านี่เป็นความตั้งใจดังนั้นซอร์สโค้ด OpenSolaris จึงไม่สามารถนำไปใช้ในเคอร์เนล Linux ได้

GNU Affero ใบอนุญาตสาธารณะทั่วไป (AGPL)

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

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

AGPLv3 เข้ากันได้กับ GPL3 คุณสามารถใส่รหัส AGPLv3 ลงในรหัส GPLv3 ได้ตราบเท่าที่ผลลัพธ์สุดท้ายได้รับอนุญาตภายใต้ AGPLv3

ใบอนุญาต ISC

ใบอนุญาต ISC เป็นใบอนุญาตซอฟต์แวร์เสรีที่ได้รับอนุญาตซึ่งเขียนโดย Internet Software Consortium (ISC) ฟังก์ชันนี้เทียบเท่ากับสิทธิ์การใช้งาน BSD และ MIT 2 ข้อหลังจากลบบางภาษาที่คิดว่าไม่จำเป็นออกไป

เริ่มแรกใช้สำหรับการเปิดตัวซอฟต์แวร์ของ ISC เองนับตั้งแต่นั้นมาได้กลายเป็นใบอนุญาตที่ต้องการของ OpenBSD (ตั้งแต่เดือนมิถุนายน 2546) รวมถึงโครงการอื่น ๆ

เข้ากันได้กับ GPL: คุณสามารถผสมรหัสที่ได้รับอนุญาตจาก ISC ลงในซอฟต์แวร์ GPL

ใบอนุญาตซึ่งกันและกันของ Microsoft (MS-RL)

ใบอนุญาตซึ่งกันและกันของ Microsoft ก่อตั้งขึ้นในปี 2008 โดย บริษัท นี้เป็นหนึ่งในใบอนุญาตโอเพนซอร์สที่สร้างโดย Shared Source Initiative

คล้ายกับ MS-PL ที่อธิบายไว้ก่อนหน้านี้ แต่มี copyleft ที่แข็งแกร่งกว่าเล็กน้อยคล้ายกับเงื่อนไขของ LGPL, CDDL และ EPL กำหนดว่าหากคุณผสมรหัสของคุณกับซอร์สโค้ดที่ได้รับอนุญาต MS-RL และต้องการเผยแพร่ผลลัพธ์ขั้นสุดท้ายอย่างน้อยส่วนที่ได้รับอนุญาต MS-RL ดั้งเดิมจะต้องได้รับใบอนุญาตจากใบอนุญาตนี้ต่อไป

เข้ากันไม่ได้กับ GPL

สาธารณสมบัติ (CC0)

ตามวิกิพีเดีย 'งานที่เป็นสาธารณสมบัติคือผู้ที่สิทธิ์ในทรัพย์สินทางปัญญาหมดอายุถูกริบหรือไม่สามารถใช้งานได้' การอุทิศงานให้เป็นสาธารณสมบัติผู้เขียนสละสิทธิ์ทั้งหมดภายใต้กฎหมายลิขสิทธิ์

มีโครงการซอฟต์แวร์หลายโครงการภายใต้โดเมนสาธารณะตัวอย่างเช่น SQLite ไลบรารีที่ใช้เอ็นจิ้นฐานข้อมูล SQL แบบฝังได้และเรียบง่ายซึ่งรวมอยู่ในโครงการอื่น ๆ เช่นโครงการ Mozilla Android เป็นต้น

มีหลายวิธีในการอุทิศซอฟต์แวร์ให้เป็นสาธารณสมบัติ ครีเอทีฟคอมมอนส์ได้สร้างไฟล์ CC0 การอุทิศโดเมนสาธารณะ ซึ่งเป็นวิธีสากลในการมอบงานให้เป็นสาธารณสมบัติ FSF แนะนำให้ใช้ข้อความนี้เพื่ออุทิศซอฟต์แวร์ให้เป็นสาธารณสมบัติ

งานภายใต้โดเมนสาธารณะเข้ากันได้กับใบอนุญาตโอเพนซอร์สหรือแบบปิดและสามารถผสมกับซอฟต์แวร์อื่น ๆ ได้

การออกใบอนุญาตหลายรายการ

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

นี่เป็นกรณีปกติสำหรับห้องสมุดบางแห่ง ตัวอย่างเช่น NSS เป็นไลบรารีที่สร้างโดย Mozilla ซึ่งใช้การสนับสนุน SSL / TLS ท่ามกลางคุณสมบัติอื่น ๆ ที่เกี่ยวข้องกับความปลอดภัย ได้รับอนุญาตแบบสามเท่าภายใต้ใบอนุญาต MPL, GPL และ LGPL

กรุณาเลือกใบอนุญาต

ผู้คนจำนวนมากเผยแพร่โค้ดในแพลตฟอร์มเป็น GitHub โดยไม่มีใบอนุญาตเป็นลายลักษณ์อักษร ไม่ควรมีใครใช้รหัสนั้น เราไม่รู้เลยว่าเรามีสิทธิ์อะไรบ้างในการใช้งาน หากคุณใช้มันคุณอาจถูกฟ้องร้องได้ เหมือนกับว่าคนเหล่านี้แกล้งเราโดยพูดว่า“ เฮ้ดูสิว่าฉันทำอะไรลงไป! เจ๋งใช่มั้ย แต่คุณใช้ไม่ได้ฉันแค่อยากจะแสดงให้คุณเห็น!”

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

• หากคุณต้องการทำให้ง่ายและเป็นที่ยอมรับอนุญาตให้ทุกคนทำในสิ่งที่ต้องการด้วยรหัสของคุณตราบใดที่พวกเขาให้การระบุแหล่งที่มากลับมาให้คุณและไม่ต้องรับผิดต่อคุณให้ใช้ใบอนุญาต MIT
• หากคุณต้องการอนุญาตให้ทุกคนทำในสิ่งที่ต้องการด้วยรหัสของคุณ แต่แจกแจงสิทธิ์ภายใต้กฎหมายลิขสิทธิ์อย่างชาญฉลาดและให้สิทธิ์เหล่านั้นพร้อมกับการให้สิทธิ์ในสิทธิบัตรอย่างชัดเจนจากผู้ให้ข้อมูลแก่ผู้ใช้ให้ใช้สิทธิ์การใช้งาน Apache 2.0 .

• หากคุณสนใจเกี่ยวกับการแชร์การแก้ไขและไม่ต้องการให้ใช้โค้ดของคุณในการพัฒนาแบบปิด (ไม่ว่าจะในผลิตภัณฑ์ซอฟต์แวร์แบบปิดหรือในอุปกรณ์ฮาร์ดแวร์แบบปิด) ให้ใช้ GPL v3

  • หากคุณไม่สนใจเกี่ยวกับความเป็นไปได้ที่ซอฟต์แวร์ของคุณจะถูกใช้ในอุปกรณ์ปิดให้ใช้ GPL v2 แต่โปรดใช้ประโยค“ หรือเวอร์ชันที่ใหม่กว่า” เพื่อให้โค้ดของคุณสามารถใช้ในโครงการ GPLv3 ได้
  • หากคุณไม่สนใจเกี่ยวกับความเป็นไปได้ที่ซอฟต์แวร์ของคุณจะถูกใช้ในซอฟต์แวร์ปิดตราบใดที่ซอฟต์แวร์ของคุณหรือส่วนที่ใช้งานนั้นยังคงเป็นโอเพนซอร์สภายใต้เงื่อนไขเดียวกันให้ใช้ LGPL v3
  • หากคุณต้องการให้ทุกคนที่ใช้ซอฟต์แวร์ของคุณผ่านเครือข่ายมีสิทธิ์ในการรับซอร์สโค้ดให้ใช้ AGPL v3

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