คำตอบของ DougM และ AER เป็นประเด็นที่ยุติธรรม MPLv2 และ LGPLv3 ที่มีข้อยกเว้นแบบคงที่จะเหมือนกันเกี่ยวกับเหตุการณ์ที่จะก่อให้เกิดสัญญาณ อย่างไรก็ตามฉันคิดว่าเราขาดความแตกต่างที่สำคัญมากระหว่าง LGPL และ MPL เมื่อ copyleft ถูกทริกเกอร์ copyleft จะใช้กับ:
- สำหรับ MPL: ไปยังไฟล์เดียวกันกับไลบรารีต้นฉบับของคุณ
- สำหรับ LGPL: ไปที่ "งานที่อิงกับไลบรารี" ตรงข้ามกับ "งานที่ใช้ไลบรารี" ดังนั้น LGPL จึงสามารถขยาย copyleft ของเขาไปยังไฟล์ใหม่ได้
Edge-case: การใช้ MPL ทำให้ผู้ใช้ไม่สามารถแบ่งปันการปรับปรุง
MPL เป็นลิขสิทธิ์ลิขสิทธิ์ระดับไฟล์ หมายความว่าหากใครบางคนฝังไว้ในโครงการขนาดใหญ่ (แบบคงที่หรือแบบไดนามิก) และทำการเปลี่ยนแปลงไฟล์ของคุณเขาจะต้องปล่อยการเปลี่ยนแปลงที่ทำกับไฟล์นี้เท่านั้น
หากคุณกังวลเกี่ยวกับการรักษาความสมบูรณ์ของฐานรหัสของคุณให้เปิดอยู่มีกรณีขอบซึ่งผลของการใช้ MPL อาจไม่เพียงพอ
ยกตัวอย่างเช่นบางคนอาจใช้เวลาหนึ่งของแฟ้มหลักของโครงการของคุณเพิ่ม"นำเข้า my_private_new_file"และปรับเปลี่ยนวิธีการหลักของคุณเช่นโดยการเพิ่ม"my_private_new_file.newAwesomeFeature.run ()"
และวิธีนี้เขาจะได้เพิ่มคุณสมบัติใหม่ในโครงการของคุณในขณะที่เพียงปล่อยไฟล์หลักแก้ไขและรักษาตรรกะที่เกิดขึ้นจริงของคุณลักษณะการปิดแหล่งใหม่ใน"my_private_new_file"
มีไฟล์หลักกลับไปที่ชุมชนเพียงแค่ให้ข้อมูลที่ "เฮ้คุณเพิ่มคุณสมบัติใหม่" แต่มันไม่ได้ช่วยให้คุณสามารถรวมคุณสมบัติใหม่นี้ในที่เปิด ... มันอาจจะน่ารำคาญถ้าคุณสมบัติใหม่อย่างใกล้ชิด - เกี่ยวข้องกับปัญหาที่ห้องสมุดของคุณพยายามแก้ไข
เห็นได้ชัดว่าเป็นกรณีที่มีความเป็นไปได้และมีคนไม่อยากทำเช่นนั้น แต่มันเป็นความเสี่ยงที่คุณต้องระวังเมื่อใช้ MPLv2
LGPL ถูกเขียนขึ้นเพื่อห้ามพฤติกรรมดังกล่าว ดู:
ฉันขอใบอนุญาต LGPL ดั้งเดิม:
ใส่ใจกับความแตกต่างระหว่าง "งานที่อิงกับไลบรารี" และ "งานที่ใช้ไลบรารี" อดีตประกอบด้วยรหัสที่ได้มาจากห้องสมุดในขณะที่หลังจะต้องรวมกับห้องสมุดเพื่อให้ทำงาน
copyleft นำไปใช้กับ "งานที่อ้างอิงไลบรารี" เท่านั้น ตอนนี้ "งานจากห้องสมุด" ในทางปฏิบัติคืออะไร? มันออกจากพื้นที่เพื่อการตีความ ซึ่งไม่เพียง แต่เป็นสิ่งที่ดีเพราะมันหมายถึงการปฏิบัติตามใบอนุญาตของคุณมีความซับซ้อนมากขึ้นและน่ากลัวมาก อาจทำให้บางคนไม่ใช้ห้องสมุดของคุณ
ในแง่นี้ LGPL มีข้อ จำกัด มากกว่า MPL แต่ยังช่วยป้องกันความสมบูรณ์ของโครงการ
MPL ช่วยให้ผู้ใช้จากโลกที่เป็นกรรมสิทธิ์สามารถแก้ไขไลบรารีของคุณและใช้งานได้ง่ายขึ้นในขณะที่ยังคงต้องแชร์การแก้ไข
ข้อดีสำหรับ MPL คือถ้าผู้ใช้พบข้อบกพร่องในไลบรารีของคุณเขาสามารถแก้ไขได้โดยตรงในไฟล์โดยไม่ต้องให้รหัสของเขาทั้งหมด แต่ให้การแก้ไขเท่านั้น พูดจริงเมื่อกระจายงานของเขาให้กับลูกค้าเขาก็สามารถให้ลิงค์ไปยังทางแยกของโครงการของคุณที่มีการแก้ไขและเขาก็เป็นสิ่งที่ดี
โดยการใช้ LGPL สิ่งต่าง ๆ มีความซับซ้อนมากขึ้น หากใครบางคนยึดโครงการของคุณแก้ไขข้อผิดพลาดและรวมไว้ในซอฟต์แวร์ที่เป็นกรรมสิทธิ์ของเขาเขาจะต้องแจกจ่าย "งานที่อิงกับห้องสมุด" ให้กับผู้ใช้ภายใต้ LGPL ซึ่งเป็นความคิดที่ค่อนข้างคลุมเครือโดยเฉพาะอย่างยิ่งเมื่อมีการฝังไลบรารีแบบคงที่ ... ในเรื่องนี้ฉันคิดว่ามันเป็นเหตุผลดั้งเดิมว่าทำไมไม่มีสิ่งนั้นเป็นข้อยกเว้น "คงที่" ใน LGPL ดั้งเดิม มันทำให้การระบุตัวตนของ "งานตามห้องสมุด" เป็นเรื่องเล็กน้อย: เป็นห้องสมุดแบบไดนามิกที่คุณเรียกใช้ในซอฟต์แวร์ที่เป็นกรรมสิทธิ์ของคุณ
เป็นผลให้ MPL ช่วยให้ผู้ค้าที่เป็นกรรมสิทธิ์ใช้และส่งการแก้ไขไปยังไลบรารีของคุณได้ง่ายกว่า LGPL
ในเวลาเดียวกันผู้ขายที่เป็นกรรมสิทธิ์ส่วนใหญ่ไม่มีทรัพยากรหรือเวลาที่จะดำดิ่งลงสู่ห้องสมุดที่ซับซ้อนของคุณและมักจะไม่แก้ไขด้วยตนเอง พวกเขาค่อนข้างจะเปิดปัญหาใน repo GitHub ของคุณหรือส่งอีเมลในรายชื่อผู้รับจดหมายและรอการแก้ไขของคุณ
ในเรื่องนี้ LGPL บังคับใช้พฤติกรรมประเภทนี้มากขึ้น แต่การบังคับใช้จำเป็นจริงๆหรือ?
ข้อสรุป
การเลือกระหว่าง LGPL และ MPL นั้นเป็นคำถามที่ยุ่งยากและตามปกติแล้วจะมีลิขสิทธิ์ซอฟต์แวร์ขึ้นอยู่กับเป้าหมายของคุณ ใบอนุญาตทั้งสองมีความคล้ายคลึงกันมาก แต่ในเวลาเดียวกันแตกต่างกันอย่างมาก พวกเขาถูกออกแบบมาเพื่อเป้าหมายและปรัชญาที่แตกต่างกันมาก
LGPL สร้างโดยมูลนิธิซอฟต์แวร์เสรีเพื่อให้สามารถใช้ห้องสมุดซอฟต์แวร์ฟรีในโลกที่เป็นกรรมสิทธิ์ได้ แต่โดยคำนึงถึงแนวคิดในการส่งเสริมซอฟต์แวร์ฟรีและต่อสู้กับซอฟต์แวร์ที่เป็นกรรมสิทธิ์อยู่เสมอ มันเป็นส่วนหนึ่งของกลยุทธ์ที่มีต่ออุดมการณ์ของพวกเขา ดู:
https://www.gnu.org/licenses/why-not-lgpl.html
MPL เป็นใบอนุญาตที่ใช้งานได้จริงที่ออกแบบโดย Mozilla เพื่อบังคับให้มีการแชร์บางอย่างกับไลบรารี่ดั้งเดิมในขณะที่ยังคงกระตุ้นให้คนทำซอฟท์แวร์และ Add-on ที่เป็นกรรมสิทธิ์ (รวมถึง Mozilla เอง) ซึ่งเป็นวิธีปฏิบัติที่ FSF อนุญาต LGPL แต่ก็ยังถือว่าเป็นอันตราย
โดยพื้นฐานแล้ว MPLv2 ได้รับการพิจารณาให้เป็นใบอนุญาตในขณะที่ LGPLv3 รวมถึงข้อยกเว้นแบบคงที่มักไม่ค่อยถูกเรียกเช่นนี้
แก้ไข
ฉันลืมพูดถึงสิ่งที่สำคัญ LGPLv3 (มีหรือไม่มีข้อยกเว้นแบบคงที่) ห้ามการปรับให้เป็นไฟล์ คุณอาจคิดว่ามันเป็น "รายละเอียด" แต่จริงๆแล้วมันไม่ได้ขึ้นอยู่กับเป้าหมายของคุณ คุณสนใจเกี่ยวกับผู้ใช้ Freedom หรือไม่? จากนั้นมันก็ไม่ใช่รายละเอียด คุณสนใจที่จะใช้ห้องสมุดของคุณบนอุปกรณ์ Apple หรือไม่? VLC ให้ความสำคัญกับการใช้งานมากขึ้นดังนั้นพวกเขาจึงตัดสินใจใช้ LGPLv2ซึ่งไม่มีข้อ จำกัด ดังกล่าว ในทำนองเดียวกันนั่นเป็นหนึ่งในเหตุผลที่Linux ใช้งาน GPLv2ต่อไป MPLv2 ยังไม่มีข้อ จำกัด ใด ๆ อย่างเห็นได้ชัดเนื่องจากเป็นใบอนุญาตที่สร้างขึ้นด้วยปรัชญา "โอเพ่นซอร์ส" ที่เป็นประโยชน์มากขึ้นในใจไม่ใช่ FSF อุดมการณ์
อาจมีสิ่งอื่น ๆ "เล็กน้อย" เช่นนี้ที่ฉันพลาด