ข้อดีและข้อเสียของ GPL คืออะไร [ปิด]


31

ฉันกำลังดูลิขสิทธิ์ซอฟต์แวร์โอเพนซอร์ซและกำลังดู GPL อยู่ ข้อดีและข้อเสียของการใช้ใบอนุญาตนี้คืออะไร?


1
ความเป็นไปได้ที่ซ้ำกันของซอฟต์แวร์ฟรีจึงดีสำหรับโปรแกรมเมอร์?

6
ไม่ซ้ำกัน คำถามนี้มุ่งเน้นไปที่ GPL อย่างแคบและไม่ได้รับมุมมอง "มุมมองสูง"
goodguys_activate

1
ฉันมักจะไปมากหนึ่งหรืออื่น ๆ : AGPL หรือ WTFPL
TRiG

ลองใส่มุมมองนี้กัน หากไมโครซอฟท์ต้องการที่จะเกิดขึ้นกับใบอนุญาตนี้ก่อนและเก็บรักษาข้อกำหนดทั้งหมดไว้อย่างแน่นอนใบอนุญาตจะไม่เหมือนกันดังต่อไปนี้ FOSS และ GLP ไม่ใช่สิ่งที่พวกเขาดูเหมือนจะเป็น อ่านประกาศของพวกเขา พวกเขาไม่ได้เกี่ยวกับอนาธิปไตยพวกเขาเกี่ยวกับการควบคุม
Andrew T Finnell

คำตอบ:


45

ตกลงรายการข้อดีและข้อเสียของ GPL ของฉัน:

ข้อดี

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

จุดด้อย

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

ในที่สุดสำหรับฉันข้อเสียมากกว่าข้อดี สำหรับฉันแล้วผู้สอนศาสนาโอเพ่นซอร์สที่พยายามหลอกโลกให้หันมาใช้โอเพ่นซอร์สแทนการชักชวนให้โลกรู้ถึงประโยชน์ของมัน


9
+1 สำหรับข้อเสียบางข้อซึ่งใช่ฉันเห็นด้วยก็คือ "เข้มงวด" เกินไป ใบอนุญาต MIT เป็นทางเลือกที่ดี
โกง

16
นี่คือ FUD ที่โปร่งใสดังกล่าว: "มันเป็นข้อตกลงที่สมบูรณ์แบบสำหรับองค์กรส่วนใหญ่พวกเขาไม่สามารถรับความเสี่ยงของรหัสลิขสิทธิ์ GPL ที่ได้รับในผลิตภัณฑ์ของพวกเขา ." รหัสและโครงการที่ได้รับอนุญาต GPL นั้นไม่มีการโต้เถียงที่ Fortune 500s ตั้งแต่ปี 2004 อย่างน้อยและแน่นอนว่า บริษัท ขนาดใหญ่หลายแห่ง (Google, IBM, Oracle เพื่อชื่อไม่กี่) นั้นมีพื้นฐานมาจากธุรกิจของพวกเขา

13
มีความแตกต่างระหว่าง บริษัท ผลิตภัณฑ์ซอฟต์แวร์ที่มักจะไม่สามารถแตะรหัส GPLed ได้และ บริษัท ที่ใช้ซอฟต์แวร์สำหรับการใช้ภายในซึ่ง GPL ไม่มีผลกระทบเป็นหลัก มีมากขึ้นกว่าหลัง
David Thornley

9
BTW, GPL ได้รับการออกแบบให้เป็นตัวขับเคลื่อนของขบวนการเคลื่อนไหวทางสังคม แต่ความตั้งใจคือการสร้างแหล่งเก็บข้อมูลของซอฟต์แวร์เสรีที่จะยังคงฟรีอยู่เสมอและจะดึงดูดให้ใช้มากขึ้น มันไม่ได้เป็นเท่าที่ฉันสามารถบอกได้ความพยายามที่จะหลอกลวงนักพัฒนาให้เป็นอะไร นอกจากนี้บุคคลที่อยู่เบื้องหลัง GPL Richard Stallman ไม่ชอบการเชื่อมต่อทั้งหมดกับโอเพ่นซอร์สซึ่งต่างจากซอฟต์แวร์เสรี
David Thornley

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

2

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

การเปรียบเทียบใบอนุญาตซอฟต์แวร์เสรี (การเปรียบเทียบตาราง) การ
ริเริ่มโอเพ่นซอร์ส - ใบอนุญาตตามชื่อ (สิ่งที่กล่าว - ใบอนุญาตที่ใช้กันทั่วไปในโลกซอฟต์แวร์ปัจจุบัน) รายการใบอนุญาตซอฟต์แวร์รวมถึงที่รองรับ GPL

F --- GPL <- การวิจารณ์อย่างชาญฉลาด (ต้องรักไข่มุกแห่งปัญญา ":-)


2

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

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

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


2

การเลือกGPLเป็นขั้นตอนในอุดมคติ:

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

การเลือกสิทธิ์ใช้งานที่ จำกัด น้อยลงเช่น MIT นั้นมีประโยชน์มากกว่า:

คุณสามารถใช้ห้องสมุดของคุณด้วยตัวเองเมื่อเข้ารหัสเพื่อเงิน (ในฐานะอิสระในฐานะพนักงาน) อย่างไรก็ตามทุกคนสามารถทำได้ดังนั้นคุณจึงช่วยให้ บริษัท ประหยัดเงินแม้ว่าพวกเขาจะร่ำรวยอยู่แล้วหากปราศจากมัน


+1 GPL เป็นการตัดสินใจเชิงอุดมคติและเชิงปรัชญาไม่ใช่เชิงเทคนิค ไม่ว่าจะเป็นเรื่องดีหรือไม่ดีก็ขึ้นอยู่กับปรัชญาและขึ้นอยู่กับแต่ละโครงการหรือทีมที่จะตัดสินใจ
Andres F.

1

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


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

ฉันคิดว่ามันเป็นเรื่องจริงถ้าในสถานการณ์ที่ไม่ใช่ SaaS ... และฉันอาจต้องหาส้อมของฉันและขอให้พวกเขาแบ่งปันสำเนากับฉัน
goodguys_activate

นั่นเป็นเรื่องจริงสำหรับ SaaS มี AGPL การระบุช่องโหว่ไม่ใช่เรื่องเล็กน้อย แต่เมื่อพบมีคนช่วยคุณ: gpl-violations.org
LennyProgrammers

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