Mozilla Public License (MPL 2.0) vs Lesser GNU General Public License (LGPL 3.0)


24

ฉันต้องการปล่อยห้องสมุดซอฟต์แวร์ที่เขียนด้วยภาษาโปรแกรมเชิงวัตถุ (Java) บนคลาสบนเว็บโฮสติ้งบริการซอร์สโค้ดซึ่งช่วยให้ส้อมของโครงการถูกรวมเข้ากับโครงการหลัก (GitHub ด้วยการดึง คำขอ) ฉันค้นคว้าบนเว็บและให้ความคิดมากเกี่ยวกับวิธีการอนุญาตให้ใช้สิทธิ์ซอฟต์แวร์ ฉันถูกต้องในสมมติฐานต่อไปนี้ (จากมุมมองของIANAL ) หรือไม่

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

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

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

  • ขณะนี้ไม่มีความแตกต่างอื่น ๆ ที่เกี่ยวข้อง (จากIANALมุมมอง)

  • รุ่นเก่าใบอนุญาตไม่ตอบสนองความต้องการของฉันเป็นคนดีใหม่ล่าสุด

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

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


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


4
ฉันจะเพิ่มคำถามของคุณในข้อเสนอสำหรับ Q & A เว็บไซต์เกี่ยวกับการออกใบอนุญาตเปิดแหล่งที่มา
Max Truxa

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

1
ฉันไม่เห็นคำถามจริงๆ คุณช่วยให้ชัดเจนว่าคำถามที่แท้จริงของคุณคืออะไร?
Bart van Ingen Schenau

คำตอบ:


15

ฉันเชื่อว่าคุณระบุความแตกต่างระหว่างสัญญาอนุญาตสาธารณะของ Mozillaกับสัญญาอนุญาตสาธารณะทั่วไปของGNU Lesserอย่างถูกต้องและอาจตอบสนองความต้องการของคุณได้ดี แต่คุณข้ามความแตกต่างที่สำคัญที่สุดระหว่างสองสัญญาอนุญาต:

ใครสามารถสร้างเวอร์ชันใหม่ได้บ้าง

ทั้ง MPL (ส่วนที่ 10) และ LGPL (ส่วนที่ 14) รวมอยู่ในใบอนุญาตให้สิทธิ์ในการแทนที่รุ่นปัจจุบันด้วยรุ่นหลังและไม่มีข้อ จำกัด ที่แท้จริงสำหรับสิ่งที่สามารถเข้าไปในใบอนุญาตเหล่านั้นได้ ในขณะที่มันไม่น่าเป็นไปได้สูงที่ทั้ง Mozilla Foundation หรือ Free Software Foundation จะทำสิ่งที่บ้าเหมือนพูดประโยคที่ระบุว่า "การมีส่วนร่วมทั้งหมดของซอฟต์แวร์นี้กลายเป็นสมบัติของเรา" มันไม่ได้เกินขอบเขตของความเป็นไปได้ที่ องค์กรจะออกใบอนุญาตรุ่นใหม่ที่คุณไม่ชอบ

ซึ่งนำไปสู่อีกจุดหนึ่งเกี่ยวกับการใช้ "Modified LGPL"


ใบอนุญาตที่ได้รับการแก้ไขไม่ใช่ใบอนุญาตเดียวกัน!

ในขณะที่คุณมีความสามารถที่น่าตื่นตาตื่นใจอย่างเป็นธรรมในการระบุเงื่อนไขใบอนุญาตของคุณเองและสามารถในสาระสำคัญกล่าวว่า"คุณสามารถแจกจ่ายนี้ตาม GPL แต่คุณจะต้องใส่ชื่อของฉันในเครดิตของคุณและจ่ายเงินให้ฉัน 1% ของรายได้ใด ๆ ที่คุณสร้าง" , เมื่อใดก็ตามที่คุณทำเช่นนั้นคุณกำลังสร้างใบอนุญาตใหม่ตามงานของคนอื่น ซึ่งหมายความว่าคุณไม่ได้ใช้ MPL หรือ LGPL คุณกำลังใช้ "ใบอนุญาต mucaho" ใหม่

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


แน่นอนว่าทั้งคู่เป็นคะแนนย่อย แม้แต่ "ความนิยมในใบอนุญาต" ก็ไม่สำคัญเว้นแต่คุณจะคาดหวังให้รหัสของคุณรวมเข้ากับโครงการขนาดใหญ่โดยตรง

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


สำหรับการสร้างเวอร์ชันใหม่กรณีของ FSF สร้างบทบัญญัติเพื่ออนุญาตให้ Wikipedia มีเนื้อหาที่น่าเชื่อถือเนื่องจาก CC-SA นั้นสมควรที่จะรับทราบ
Christian

ขอบคุณ! เพียงเพื่อชี้แจง: @DougM กล่าวว่า"ทั้ง MPL (มาตรา 10) และแอลจี (มาตรา 14) รวมไว้ในใบอนุญาตให้สิทธิเพื่อทดแทนรุ่นปัจจุบันกับรุ่นหลัง" ฉันยังคงสามารถเลือกได้ว่าซอฟต์แวร์ของฉันยังคงได้รับอนุญาตภายใต้รุ่นเก่าหรือหากฉันต้องการเปลี่ยนเป็นรุ่นลิขสิทธิ์ใหม่ที่ถูกต้อง (ดู MPL2.0 หัวข้อ 10.2) ดังนั้นหากฉัน intertrepeting จุดเกี่ยวกับรุ่นใหม่อย่างถูกต้องเฉพาะผู้ใช้ห้องสมุด LPGL / MPL ของฉันจะเสียเปรียบถ้าฉันเลือกที่จะเปลี่ยนเป็นรุ่นที่ใหม่กว่าและรุ่นที่ใหม่กว่าไม่ได้ฟ้องพวกเขา?
mucaho

2
LGPL และ MPL ไม่มีกลไกในการเพิกถอนสิทธิ์การใช้งาน เมื่อมีคนที่มีรหัสที่มันเป็นของพวกเขาภายใต้เงื่อนไขของใบอนุญาตว่าตลอดไป และพวกเขาจะเลือกว่าจะปฏิบัติตามใบอนุญาตที่มีอยู่แล้วหรือใบอนุญาตผู้สืบทอดอื่น ๆ (คุณสามารถสลับการกระจายใหม่เป็นรุ่นใหม่ แต่ทุกคนที่ต้องการที่จะแยก CNA ทำเช่นกันแม้ว่า "ส้อม" ของพวกเขาจะไม่เปลี่ยนแปลงส่วนอื่น ๆ เดียวของโปรแกรมของคุณ..)
DougM

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

1
พวกเขาสามารถลองได้ แต่การทำเช่นนั้นอาจจะไม่ประสบความสำเร็จ อย่างไรก็ตามพวกเขาสามารถพูดว่า "คุณสามารถขโมยชื่อของโครงการใด ๆ ที่คุณแยกไป LGPL4" หรือรุ่นที่ไม่คาดคิดอื่น ๆ (พวกเขาอาจจะไม่ทำอย่างนั้น แต่พวกเขาทั้งสองและ Mozilla ในทางเทคนิคทำได้ แต่ศาลอาจจะไม่ปล่อยให้พวกเขาบังคับใช้เช่นคำสั่ง.)
DougM

4

คำตอบของ 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 อุดมการณ์

อาจมีสิ่งอื่น ๆ "เล็กน้อย" เช่นนี้ที่ฉันพลาด

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.