Có lỗ hổng nào trong GPL cho phép phần mềm độc quyền được liên kết với các thư viện GPL không?

Hãy xem xét một kịch bản giả thuyết:

Công ty X viết chương trình độc quyền (A) liên kết động với thư viện độc quyền (B). Công ty Y muốn sử dụng thư viện thay thế (C) được cấp phép theo GPL và do đó viết thư viện trình bao bọc (D) tự động liên kết với cả A và C và dịch các lệnh gọi API được A sử dụng sang các lệnh gọi API được sử dụng bởi C.

Vì D được dự định sẽ được sử dụng với C và sử dụng các lệnh gọi API của C, đây là công việc phái sinh của C và do đó phải được phân phối theo các điều khoản của GPL *. Do đó, công việc kết hợp của A và D cũng phải được phân phối theo các điều khoản của GPL, điều không thể xảy ra là Công ty Y không sở hữu mã nguồn cho A. Điều đó nói rằng, miễn là Công ty Y tự phân phối D , không có vấn đề gì cả. Tuy nhiên, bất kể hành động của Công ty Y là gì, Công ty X không vi phạm GPL bằng cách phân phối A, ngay cả khi không có B. Sự tồn tại đơn thuần của D không có nghĩa là A đột nhiên là một sản phẩm phái sinh của C (thông qua D) phải được cấp phép theo GPL là tốt.

Bây giờ đây là lỗ hổng: không có gì ngăn Công ty X viết phiên bản D của riêng mình, phân phối riêng từ A và bảo người dùng cuối sử dụng D thay vì B khi chạy A. Có vẻ như một công ty có khả năng thiết kế chương trình độc quyền để sử dụng thư viện GPL mà không vi phạm GPL, miễn là mô-đun trình bao được sử dụng để cách ly chương trình độc quyền từ thư viện GPL và mô-đun đó được phân phối riêng.

Tôi có đúng trong lý luận của tôi? Đây có phải là một lỗ hổng thực sự trong GPL?

* D cũng là một tác phẩm phái sinh của A, nhưng với mục đích của kịch bản này, Công ty X đã ủy quyền rõ ràng việc tạo ra D và cho phép nó được cấp phép theo GPL.

IANAL, nhưng đây là ý kiến ​​của tôi về những gì được cho phép trong giới hạn của GPL:

• phân phối công việc kết hợp "A - B" ở nơi công cộng: tốt, có thể được thực hiện theo bất kỳ giấy phép độc quyền nào

• tạo một trình bao bọc lib D cho C bởi Y: tốt, điều này không có nghĩa là A phải được đặt dưới GPL

• sử dụng sản phẩm kết hợp "A - D - C" trong nội bộ của Y: cũng tốt, GPL không yêu cầu mở nguồn A miễn là sự kết hợp không được phân phối cho công chúng

• phân phối công việc kết hợp "A - D - C" ở nơi công cộng: điều này sẽ yêu cầu A phải có nguồn mở và được đặt theo GPL (và không quan trọng nếu X hoặc Y phân phối kết hợp này; ngoài ra, nếu Y muốn làm điều này, tất nhiên họ sẽ yêu cầu giấy phép phân phối cho A từ X, tất nhiên)

Câu hỏi thú vị bây giờ là: D & C có thể được phân phối riêng dưới dạng nguồn mở theo GPL, A & B (hoặc chỉ A không có B) được phân phối theo giấy phép độc quyền và người dùng cuối thay thế B bằng D & C không?

Ở đây, việc sửa đổi cuối cùng thành "AB" khiến A phụ thuộc vào libs D & C được thực hiện bởi người dùng cuối - sau khi phân phối . Vì vậy, người ta có thể lập luận rằng việc sửa đổi cuối cùng chỉ được thực hiện bởi người dùng cuối. Và dường như điều này thực sự có thể xảy ra mà không vi phạm GPL - và những gì bạn nhận được là sự kết hợp hoạt động của "AC & D" trong đó A theo giấy phép độc quyền và C & D theo GPL.

Tất nhiên, một luật sư hoặc một thẩm phán có thể có ý kiến ​​khác về điều đó. Để có câu trả lời cuối cùng, tôi nghĩ bạn phải đợi cho đến khi ai đó thử nó và người thứ hai kiện anh ta.

Tôi đoán đối với hầu hết các hệ thống, sẽ khó tạo ra một chòm sao như vậy nếu không thiết kế "A" ngay từ đầu để nó hoạt động trơn tru với B hoặc C. Và trong trường hợp này, người ta có thể nghi ngờ rằng A bằng cách nào đó có nguồn gốc từ C.

EDIT: suy nghĩ một lúc về điều này, một tình huống tương tự xuất hiện trong đầu tôi: viết và phân phối các plugin được cấp phép GPL cho các ứng dụng nguồn đóng. Hãy lấy ví dụ, Photoshop. Tôi không nghĩ ai đó sẽ nghiêm túc cố gắng thực thi Adobe đối với Photoshop nguồn mở chỉ vì tồn tại một số plugin GPL từ các nhà cung cấp bên thứ ba. Ở đây, thậm chí không cần "lib bọc" vì có giao diện được xác định rõ. Tuy nhiên, liệu nó có thay đổi được tình huống nếu Photoshop sẽ kết hợp một số chức năng trung tâm của nó từ trình cắm của bên thứ ba GPLed không? Tôi nghĩ đối với trường hợp như vậy, có thể rất khó để quyết định nơi vẽ đường, tại thời điểm đó, sản phẩm nguồn đóng là một tác phẩm "dựa trên" lib GPL.

EDIT2: Có các lib giấy phép kép có sẵn, với giấy phép GPL cho sử dụng phi thương mại và giấy phép độc quyền cho sử dụng thương mại như ví dụ này. Vì vậy, "lỗ hổng" của bạn có nghĩa là phát triển một sản phẩm dựa trên lib đó (sử dụng phiên bản thương mại, do đó GPL không áp dụng cho sản phẩm của bạn), cung cấp sản phẩm của bạn dưới dạng nguồn đóng mà không có lib cho công chúng và để cho kết thúc người dùng tự nhận và cài đặt phiên bản GPLed. Trong trường hợp như vậy, tôi đoán rằng nhà cung cấp lib sẽ có cơ hội tốt để kiện bạn vi phạm giấy phép (tất nhiên nếu bạn không trả tiền cho lib của anh ấy). Có đáng để phiền phức không? Chắc là không. Đặc biệt trong ví dụ tôi liên kết, bạn cũng sẽ phải mua lib, vì giá cả không phụ thuộc vào tần suất bạn bán sản phẩm của mình, mà chỉ có bao nhiêu nhà phát triển đang sử dụng lib trong quá trình phát triển.

Cuối cùng, vì những rủi ro pháp lý đó, nếu tôi có ý định sử dụng lib nguồn mở trong một sản phẩm nguồn đóng, tôi sẽ tránh các lib của GPL nếu có thể và không cố gắng sử dụng "lỗ hổng" này. LGPL hoặc GPL với ngoại lệ liên kết sẽ an toàn hơn nhiều, hoặc bất kỳ loại giấy phép HĐH không virus nào.

Một ví dụ thực tế là các trình điều khiển đồ họa độc quyền cho Linux mà người dùng cuối phải tự cài đặt. Điều quan trọng đối với người tạo trình điều khiển độc quyền, nếu người dùng cuối phân phối công việc kết hợp, điều đó tạo ra nghĩa vụ pháp lý cho người dùng cuối (mà họ không thể thực hiện được) nhưng không phải là người tạo trình điều khiển.

Một câu trả lời khác khẳng định "vì chương trình phụ thuộc vào thư viện nên nó vẫn là một tác phẩm phái sinh" - nhưng nếu chương trình không thực sự hoạt động vì thư viện không có ở đó, thì nó không phải là phái sinh.

Nhưng cuối cùng, nếu bạn dựa vào "sơ hở" thì bạn nên cân nhắc rằng cách tiếp cận của bạn có thể không đúng đắn ngay từ đầu.

Liên kết định nghĩa một đạo hàm của GPL. Tình huống cụ thể này là những gì LGPL được thiết kế để xử lý: nơi bạn muốn phát hành thư viện dưới dạng GPL nhưng xác định liên kết là giới hạn rõ ràng của giấy phép được áp dụng, hoặc thay vào đó, nơi bạn muốn liên kết với một số mã GPL nhưng yêu cầu đó là của riêng bạn công việc được phát hành theo giấy phép không phải GPL.

Trong trường hợp người dùng cuối sẽ thực hiện liên kết (xây dựng mã riêng của mình từ các nguồn không phải GPL có thể liên kết với thư viện GPL), người dùng cuối đã không tạo một phiên bản GPL bất kể sản phẩm cuối cùng là gì, vì anh ta không được phép thay đổi giấy phép của phần không GPL của dự án vì anh ta không phải là chủ sở hữu của nó. Điều này thường ngăn chặn phân phối bởi người dùng cuối dưới mọi hình thức, nhưng sẽ không cấm sử dụng.

Điều đó nói rằng, nếu một dự án yêu cầu nó được xây dựng từ nguồn và chỉ được phân phối theo cách đó thì không liên quan đến giấy phép nào mà thư viện được liên kết phải chịu, vì điều này hoàn toàn nằm ngoài tầm tay của nhà phát triển không phải GPL. Đó là, làm thế nào bạn có thể biết phân phối chỉ nguồn của mình sẽ được xây dựng trên gcc dựa trên glibc VS được xây dựng trên trình biên dịch IBM chống lại libc của họ trừ khi bạn chỉ định điều này theo các điều khoản cấp phép của riêng bạn? Điều này nhanh chóng được sử dụng hợp pháp và các lệnh cấm đối với các điều kiện pháp lý không thể thực thi (không phải là tưởng tượng đã không được viết thành luật trong một vài lần gần đây).

Tôi không phải là một luật sư, nhưng theo như tôi có thể nói với bạn là không đúng, vì chương trình phụ thuộc vào thư viện - nó vẫn là một công việc mang tính xúc phạm. Giống như cách mà một phần tiếp theo là một tác phẩm xúc phạm. Tối thiểu nó dựa trên các API được xác định trong thư viện.