โอเพ่นซอร์สลิขสิทธิ์และการแก้ไขข้อผิดพลาดเล็กน้อย


10

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

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

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

หมายเหตุ: นี่เป็นสถานการณ์สมมติไม่ใช่คำถาม "เพื่อน" ของฉันมีปัญหานี้ "



2
คุณรู้หรือไม่ว่าคุณกำลังขอคำแนะนำทางกฎหมายจากกลุ่มคนที่ไม่ระบุชื่อ (ส่วนใหญ่) ทางอินเทอร์เน็ตที่ไม่ได้แกล้งเป็นทนายความ?
Dan Pichelman

9
ใช่ฉันทำ. และฉันจะบอกผู้พิพากษาว่า "อินเทอร์เน็ตพูดอย่างนั้น"
Benjamin Kloster

3
แต่คุณสามารถใช้จ่ายหลายพันดอลลาร์สำหรับมืออาชีพเพื่อให้ความเห็นที่จะโต้แย้งในศาลโดยมืออาชีพอื่นสำหรับการพิจารณาคดีที่ในที่สุดไม่ได้หมายความว่าอะไรจนกว่าจะได้รับการขึ้นโดย บริษัท ขนาดใหญ่ที่มีแบ๊งค์เพื่อจ่าย 10 รอบ ดึงดูดให้ตอกตะปูในโลงศพจริงๆ จนกว่ารัฐสภาจะผ่านไปแล้วยังมีอีกไซเบอร์บิลล์ที่โยนทุกอย่างเป็นปัญหา สำหรับประเทศสหรัฐอเมริกา ... ใช่ยินดีต้อนรับสู่สีเทานิรันดร์นั่นคือกฎหมายทรัพย์สินทางปัญญา
Philip

2
@DanPichelman คำถามที่พบบ่อยบอกว่ามันตกลงที่จะถามคำถามลิขสิทธิ์ซอฟต์แวร์ที่นี่ใน programmers.SE

คำตอบ:


6

Caveat: ฉันไม่ใช่ทนายความ!

อัปเดต: การแก้ไขข้อบกพร่องเล็กน้อยอาจไม่อยู่ภายใต้ลิขสิทธิ์ ดูคำตอบของ Michael Shaw ซึ่งฉันเชื่อว่าแม่นยำกว่าที่ฉันพูดในตอนแรกสำหรับข้อมูลเพิ่มเติม

อย่างไรก็ตามถึงแม้ว่าสถานการณ์นี้จะน้อยกว่าอุดมคติ:

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

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

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

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


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

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

@MichaelShaw ฉันได้อัปเดตคำตอบเพื่อลบข้อมูลที่ไม่ถูกต้อง ขอบคุณสำหรับข้อมูลของคุณ

6

หากการแก้ไขข้อผิดพลาดเล็กน้อยนั้นอาจเป็นไปได้ว่าจะไม่มีลิขสิทธิ์โดยเฉพาะอย่างยิ่งหากไม่มีวิธีอื่นใดในการเขียนรหัส if (*p == NULL)มีหลายร้อยล้านของวิธีในการเขียนบทกวีรักหรือวิดีโอเกมจะมีจริงๆมีไม่เกินหนึ่งหรือสองวิธีในการเขียน ลิขสิทธิ์อยู่ในการแสดงออกของความคิดดังนั้นหากไม่มีตัวเลือกใด ๆ ในการแสดงความคิดจะไม่มีลิขสิทธิ์

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

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

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


-2

ความเห็นที่ไม่ชำนาญของฉันหลังจากอ่านhttp://www.ifosslr.org/ifosslr/article/view/30/64เป็นสิ่งนี้:

งานต้นฉบับมีผลงานเพียงผู้เดียวและบุคคลนั้นเป็นเจ้าของลิขสิทธิ์และอาจเลือกที่จะอนุญาตงานที่พวกเขาต้องการและมี

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

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

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

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