มีช่องโหว่ใน GPL ที่อนุญาตให้ซอฟต์แวร์ลิขสิทธิ์เชื่อมโยงกับไลบรารี GPL หรือไม่

ตรวจสอบสถานการณ์สมมุติ:

Company X เขียนโปรแกรมที่เป็นกรรมสิทธิ์ (A) ที่เชื่อมโยงกับไลบรารีที่เป็นกรรมสิทธิ์ (B) บริษัท Y ต้องการใช้ไลบรารี่ทดแทน (C) ที่ได้รับสิทธิการใช้งานภายใต้ GPL และเขียนไลบรารีแรปเปอร์ (D) ที่ลิงก์ไปยังทั้ง A และ C แบบไดนามิกและแปลการเรียก API ที่ใช้โดย A เป็นการเรียก API ที่ C ใช้

เนื่องจาก D มีวัตถุประสงค์เพื่อใช้กับ C และใช้การเรียก API ของ C จึงเป็นงานที่ต่อเนื่องของ C ดังนั้นจึงต้องเผยแพร่ภายใต้ข้อกำหนดของ GPL * เป็นผลให้การทำงานร่วมกันของ A และ D ต้องถูกแจกจ่ายภายใต้เงื่อนไขของ GPL ซึ่งเป็นไปไม่ได้เนื่องจาก บริษัท Y ไม่มีรหัสแหล่งที่มาสำหรับ A. ที่กล่าวว่าตราบใดที่ บริษัท Y กระจาย D ด้วยตัวเอง , ไม่มีปัญหา. อย่างไรก็ตามโดยไม่คำนึงถึงการกระทำของ บริษัท Y บริษัท X จะไม่ละเมิด GPL โดยการกระจาย A แม้ว่าไม่มี B การมีอยู่เพียง D ไม่ได้หมายความว่า A นั้นเป็นงานที่ต่อเนื่องของ C (ถึง D) ซึ่งต้องได้รับอนุญาตภายใต้ GPL เช่นกัน

ตอนนี้นี่คือช่องโหว่: ไม่มีสิ่งใดที่ทำให้ บริษัท X ไม่สามารถเขียนเวอร์ชัน D ของตนเองแจกจ่ายแยกต่างหากจาก A และบอกให้ผู้ใช้ปลายทางใช้ D แทน B เมื่อใช้งาน A.ดูเหมือนว่า บริษัท จะสามารถ การออกแบบโปรแกรมที่เป็นกรรมสิทธิ์เพื่อใช้ไลบรารี GPL โดยไม่ละเมิด GPL ตราบใดที่โมดูลแรปเปอร์ถูกใช้เพื่อป้องกันโปรแกรมที่เป็นกรรมสิทธิ์จากไลบรารี GPL และโมดูลนั้นจะถูกแจกจ่ายแยกต่างหาก

ฉันถูกต้องในการให้เหตุผลของฉัน? นี่เป็นช่องโหว่ที่แท้จริงใน GPL หรือไม่

* D เป็นผลงานต่อเนื่องของ A แต่สำหรับวัตถุประสงค์ของสถานการณ์นี้ บริษัท X ได้อนุญาตให้สร้าง D และอนุญาตให้อนุญาตภายใต้ GPL

IANAL แต่นี่คือความเห็นของฉันเกี่ยวกับสิ่งที่ได้รับอนุญาตภายในขอบเขตของ GPL:

• แจกจ่ายงานรวม "A - B" ในที่สาธารณะ: ดีสามารถทำได้ภายใต้ใบอนุญาตกรรมสิทธิ์ใด ๆ

• สร้าง wrapper lib D สำหรับ C โดย Y: ใช้ได้นี่ไม่ได้หมายความว่า A จะต้องอยู่ภายใต้ GPL

• ใช้ผลิตภัณฑ์ที่รวมกัน "A - D - C" ภายในโดย Y: ยังดี GPL ไม่จำเป็นต้องเปิดแหล่งที่มาตราบใดที่การรวมกันไม่ได้แจกจ่ายให้กับประชาชน

• กระจายงานรวมกัน "A - D - C" ในที่สาธารณะ: นี้จะต้องมีที่มาเปิดและจะอยู่ภายใต้ GPL (และมันไม่สำคัญว่า X หรือ Y กระจายชุดนี้นอกจากนี้ถ้า Y ต้องการที่จะทำ สิ่งนี้พวกเขาจะต้องมีใบอนุญาตการจัดจำหน่ายสำหรับ A จาก X แน่นอน)

คำถามที่น่าสนใจในขณะนี้คือ: สามารถกระจาย D & C แยกต่างหากเป็นโอเพ่นซอร์สภายใต้ GPL, A & B (หรือเพียงแค่ A โดยไม่ต้อง B) ได้รับการแจกจ่ายภายใต้ใบอนุญาตกรรมสิทธิ์และผู้ใช้ปลายทางแทนที่ B&C ด้วยตัวเอง?

นี่คือการปรับเปลี่ยนครั้งสุดท้ายเป็น "AB" ซึ่งทำให้ A ขึ้นอยู่กับ libs D & C จะกระทำโดยผู้ใช้ปลายทาง - หลังการแจกจ่ายหลังจากการจัดจำหน่ายดังนั้นหนึ่งอาจยืนยันว่าการปรับเปลี่ยนขั้นสุดท้ายจะทำภายในโดยผู้ใช้ปลายทางเท่านั้น และดูเหมือนว่าสิ่งนี้เป็นไปได้โดยไม่ละเมิด GPL - และสิ่งที่คุณได้รับคือการผสมผสานการทำงานของ "AC&D" โดยที่ A อยู่ภายใต้ใบอนุญาตกรรมสิทธิ์และ C&D ภายใต้ GPL

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

ฉันเดาว่าระบบส่วนใหญ่มันจะยากที่จะสร้างกลุ่มดาวที่ไม่มีการออกแบบ "A" ตั้งแต่ต้นดังนั้นมันจะทำงานได้อย่างราบรื่นกับทั้ง B หรือ C และในกรณีนี้เราอาจสงสัยว่า A มาจากซีอย่างใด

แก้ไข: เมื่อเราคิดถึงเรื่องนี้สถานการณ์คล้าย ๆ กันก็อยู่ในใจของฉัน: การเขียนและแจกจ่ายปลั๊กอินลิขสิทธิ์ GPL สำหรับแอปพลิเคชันแบบโอเพ่นซอร์ส ลองยกตัวอย่างเช่น Photoshop ฉันไม่คิดว่าจะมีคนพยายามบังคับ Adobe ให้จริงจังกับ Photoshop โอเพ่นซอร์สเพียงเพราะมีปลั๊กอิน GPL บางส่วนจากผู้ขายบุคคลที่สาม ที่นี่ไม่จำเป็นต้องมี "wrapper lib" เนื่องจากมีอินเตอร์เฟสที่กำหนดไว้อย่างดี อย่างไรก็ตามมันจะเปลี่ยนสถานการณ์หรือไม่หาก Photoshop จะรวมฟังก์ชั่นส่วนกลางบางส่วนจากปลั๊กอินบุคคลที่สามของ GPLed ฉันคิดว่าในกรณีเช่นนี้มันอาจเป็นเรื่องยากที่จะตัดสินใจว่าจะวาดเส้นตรงไหน ณ จุดที่ผลิตภัณฑ์ปิดแหล่งที่มาเป็นงาน "ตาม" GPL lib

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

ในที่สุดเนื่องจากความเสี่ยงทางกฎหมายหากฉันตั้งใจจะใช้ libs โอเพนซอร์ซภายในผลิตภัณฑ์โอเพ่นซอร์สฉันจะหลีกเลี่ยง GPL libs หากเป็นไปได้และไม่พยายามใช้ "ช่องโหว่" นี้ LGPL หรือ GPL ที่มีข้อยกเว้นการเชื่อมโยงนั้นปลอดภัยกว่ามากหรือใบอนุญาต OS ที่ไม่ใช่ไวรัสชนิดใด ๆ

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

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

แต่ท้ายที่สุดถ้าคุณพึ่งพา "ช่องโหว่" คุณควรพิจารณาว่าแนวทางของคุณอาจไม่ถูกต้องตั้งแต่แรก

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

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

ที่กล่าวว่าหากโครงการต้องการให้สร้างขึ้นจากแหล่งที่มาและแจกจ่ายเฉพาะในลักษณะที่ไม่เกี่ยวข้องกับไลเซนส์ไลบรารี่ที่ลิงก์อยู่ภายใต้เนื่องจากเป็นสิ่งที่อยู่ในมือของผู้พัฒนาที่ไม่ใช่ GPL นั่นคือคุณจะรู้ได้อย่างไรว่าการแจกจ่ายเฉพาะซอร์สของคุณจะถูกสร้างขึ้นบน gcc เทียบกับ glibc VS ที่สร้างขึ้นบนคอมไพเลอร์ IBM กับ libc ของพวกเขาจนกว่าคุณจะระบุสิ่งนี้ภายใต้เงื่อนไขการออกใบอนุญาตของคุณเอง? สิ่งนี้เกิดขึ้นอย่างรวดเร็วในการใช้งานอย่างเป็นธรรมและข้อห้ามตามเงื่อนไขทางกฎหมายที่บังคับใช้ไม่ได้

ฉันไม่ได้เป็นนักกฎหมาย แต่เท่าที่ฉันสามารถบอกคุณได้ว่าไม่ถูกต้องเนื่องจากโปรแกรมขึ้นอยู่กับห้องสมุด - มันยังคงเป็นงานสืบเนื่อง เช่นเดียวกับที่ภาคต่อเป็นงานสืบเนื่อง อย่างน้อยมันก็ขึ้นอยู่กับ API ที่กำหนดไว้ในห้องสมุด