การเลือกใบอนุญาตสำหรับโครงการโอเพ่นซอร์ส


30

ฉันได้ทำโครงการโอเพนซอร์สและฉันวางแผนที่จะทำมากขึ้นในอนาคต จนถึงตอนนี้ฉันได้เปิดตัวรหัสทั้งหมดของฉันภายใต้ GPL แต่ฉันได้อ่านบทความสองสามฉบับที่อ้างว่า GPL นั้นมีข้อ จำกัด เกินไปที่จะใช้รหัสใด ๆ ในสภาพแวดล้อมขององค์กร นี้จะช่วยลดการมีส่วนร่วม

นี่คือสิ่งที่ฉันต้องการจะทำ:

สำหรับการใช้งานเต็มรูปแบบ :

  • ไม่มีการใช้งานเชิงพาณิชย์ยกเว้นการสนับสนุนการขายสำหรับแอปพลิเคชัน (เช่นแอปไม่สามารถขายได้ แต่ทุกอย่างที่อยู่รอบ ๆ สามารถทำได้)

สำหรับไลบรารี (คอมโพเนนต์, ปลั๊กอิน, ... ):

  • สามารถรวมอยู่ในโครงการเชิงพาณิชย์โดยไม่มีการดัดแปลง
  • การดัดแปลงใด ๆ ที่ห้องสมุด / องค์ประกอบจะต้องเปิดแหล่งที่มา (สนับสนุนกลับ) - ส่วนที่เหลือของโครงการเชิงพาณิชย์หรือไม่จะไม่ได้รับผลกระทบ

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

ส่วนใหญ่ฉันต้องการให้คนใช้รหัสของฉันทุกที่ที่พวกเขาต้องการตราบใดที่มีการปรับปรุงใด ๆ กลับคืนมา

สิ่งนี้นำมาสู่คำถามของฉัน: LGPL เป็นตัวเลือกเชิงตรรกะสำหรับห้องสมุดโอเพ่นซอร์สส่วนประกอบปลั๊กอิน ฯลฯ หรือไม่ มีทางเลือกที่ดีกว่านี้ไหม? GPL เป็นตัวเลือกที่ดีสำหรับแอปพลิเคชันของฉันหรือมีสิ่งที่ดีกว่า

ปรับปรุง:

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

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


1
คุณหมายถึงไม่มีการใช้ในเชิงพาณิชย์หรือไม่มีการจำหน่าย / การขายต่อ?
MIA

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

4
เป็นสิ่งสำคัญที่จะต้องทราบว่า (ตรงกันข้ามกับคำตอบบางส่วน) คำถามที่พบบ่อยของCreative Commonsอย่างชัดเจนว่าไม่ควรใช้สัญญาอนุญาต CC สำหรับซอฟต์แวร์ (ในการอุทิศตนมอนส์ CC0 โดเมนสาธารณะ จะได้รับการอนุมัติสำหรับการใช้งานกับซอฟต์แวร์ แต่จะไม่เหมาะสมสำหรับวัตถุประสงค์ที่ระบุไว้ในคำถามเดิม.) แทน CC แนะนำให้เลือกใบอนุญาตที่ได้รับอนุมัติโดยมูลนิธิซอฟต์แวร์ฟรีหรือมาเปิดความคิดริเริ่ม
Peter Briggs

1
การเดาของฉันคือถ้าคุณไม่ได้คิดอะไรที่เป็นเอกลักษณ์และมีประโยชน์จริง ๆ โอกาสของ "การค้าที่ไม่ดี" จะมีขนาดเล็กจนไม่คุ้มค่ากับเวลาที่ใช้ในการพยายามป้องกัน
ไบรอัน Oakley

1
ในกรณีที่ใครบางคนสนใจมีข้อเสนอสำหรับไซต์ถามตอบเกี่ยวกับสิทธิ์ใช้งานโอเพ่นซอร์สที่ area51: area51.stackexchange.com/proposals/58715/ …
Kurt Pattyn

คำตอบ:


8

ฟังดูแล้วเหมือนกับ GPL และ LGPL เป็นสิ่งที่คุณต้องการสำหรับโครงการของคุณ


ดังนั้นคุณจะบอกว่า LGPL เป็นตัวเลือกที่ดีสำหรับความต้องการของฉัน ฉันไม่ได้เป็นนักกฎหมายดังนั้นฉันแค่ตรวจสอบ :)
ดร. Hannibal Lecter

1
ฉันไม่ใช่ทนายความ แต่ฉันคิดว่า LGPL เป็นสิ่งที่คุณต้องการสำหรับห้องสมุดและ GPL สำหรับการใช้งานเต็มรูปแบบ
ทางเลือก

การขายแอป GPL นั้นถูกกฎหมาย คุณ (โดยหลัก) เพิ่งมีรหัสแหล่งที่มาและให้สิทธิ์ GPL เดียวกับที่คุณมีให้กับลูกค้าของคุณ
bdsl

8
  • ไม่มีการใช้งานเชิงพาณิชย์ยกเว้นการสนับสนุนการขายสำหรับแอปพลิเคชัน (เช่นแอปไม่สามารถขายได้ แต่ทุกอย่างที่อยู่รอบ ๆ สามารถทำได้)

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


จริง ๆ แล้วฉันก็โอเคด้วยเพราะซอร์สโค้ดจะลอยไปรอบ ๆ และใครสักคนจะได้ประโยชน์จากมัน ;)
ดร. Hannibal Lecter

ฉันไม่เข้าใจจริงๆ ฉันหมายความว่าถ้าฉันสามารถหาแหล่งที่มาได้ฉันสามารถรวบรวมและไม่มีอะไรที่ห้ามไม่ให้ฉันใช้มันใช่ไหม?
Camilo Martin

@Camilo: สิ่งที่คุณไม่ได้รับ?
Konrad Rudolph

ตอนที่ 4 และ 6b ของ GPL เวอร์ชัน 3 ครอบคลุมสิ่งที่คุณพูด @KonradRudolph
Rudolf Olah

พวกเขาไม่ต้องให้ซอร์สโค้ดฟรีหากรวมไว้ในแพ็คเกจเมื่อขายแอปพลิเคชัน
bdsl

5

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

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

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

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


ธุรกิจที่ใช้ซอฟต์แวร์ GPL ภายในไม่ใช่การใช้ซอฟต์แวร์เชิงพาณิชย์ ...
ทางเลือก

3
@ ช่างพูดคำว่า "ธุรกิจ" และ "การใช้" ไม่ทำให้คุณรู้สึกเหมือนกับ "การใช้เพื่อการค้า" หรือไม่? definitions.uslegal.com/c/commercial
Huperniketes

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

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

2
@dr มันไม่ได้เป็นการละเมิดเพราะใบอนุญาต Apache ไม่ได้ห้ามใช้ในเชิงพาณิชย์ apache.org/foundation/licence-FAQ.html#WhatDoesItMEAN "อนุญาตให้คุณ: ดาวน์โหลดและใช้งานซอฟต์แวร์ Apache ได้อย่างอิสระไม่ว่าทั้งหมดหรือบางส่วนเพื่อวัตถุประสงค์ส่วนตัวภายใน บริษัท หรือเพื่อการค้า"
Huperniketes

4

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


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

4

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

(นี่เป็นสิ่งที่เกี่ยวข้องโดยเฉพาะอย่างยิ่งสำหรับห้องสมุดเพราะห้องสมุด GPL-ed สามารถใช้กับซอฟต์แวร์ GPL เท่านั้น)

ระมัดระวังเกี่ยวกับการมีส่วนร่วมภายนอกหรือแพทช์ที่คุณรวมไว้ในรหัสของคุณ (เนื่องจากคุณไม่ได้เป็นเจ้าของพวกเขา)


1

ไม่ว่าคุณจะสามารถสมัครใช้ MPL หรือ GPL เท่านั้นนั้นขึ้นอยู่กับความแตกต่างที่สำคัญอย่างหนึ่ง:

"สิทธิในที่นี้" รวมถึงสิทธิ์ที่มอบให้แก่ผู้รับเพื่อเชื่อมโยง MPL "รหัสที่ครอบคลุม" กับรหัสที่ไม่ใช่ MPL ส่วนตัวเพื่อสร้าง "งานที่ใหญ่กว่า" (MPL 3.7 งานที่ใหญ่กว่า) GPL ไม่ให้สิทธิ์ดังกล่าวแก่ผู้รับ ดังนั้นผู้รับไม่สามารถเปลี่ยนข้อกำหนดสิทธิ์ใช้งานเพื่อใช้ GPL แทน MPL

ดูนี่สิ

สิ่งนี้หมายความว่าสำหรับคุณคือถ้าคุณใช้ส่วนประกอบใด ๆ ที่เป็น GPL'ed คุณ (อาจ) ไม่สามารถปล่อยรหัส (ซึ่งใช้สิ่งนี้) ภายใต้ MPL; MPL จะพยายามอนุญาตให้แจกจ่ายรหัส GPL'ed อีกครั้งภายใต้ MPL ซึ่งไม่เหมาะสม นี่เป็นเรื่องปกติถ้าการพึ่งพาของคุณอยู่ในลำดับของ MIT หรือ Apache

โดยทั่วไปหากคุณไม่ได้ทำสิ่งใดให้ดีขึ้นโดยเลือก MPL ผ่าน GPL เพียงอย่างเดียวเว้นแต่ว่าคุณใช้ MPL แล้ว GPL จะทำให้มั่นใจว่าผลงานจะได้รับการเผยแพร่กลับเช่นกัน

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

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

MPL และ GPL เข้ากันไม่ได้เลยทีเดียว

คุณสามารถดูได้ที่นี่: MIT กับ BSD กับ Dual Licenseสำหรับการอภิปรายเกี่ยวกับนัยของสิทธิ์ใช้งานแบบคู่


ความเข้ากันไม่ได้ของ GPL ควรได้รับการแก้ไขด้วย MPL v2.0 (ฉันเดาว่าโพสต์นี้ทำก่อนที่ v2.0 จะวางจำหน่าย) ดูคำสั่งของ GNU ใน MPLv2.0
mucaho

0

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

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