Có giấy phép LGPL mà tôi không thể sử dụng mã không được sửa đổi, liên kết trong sản phẩm đóng gói thương mại mà không thay đổi giấy phép sản phẩm cho LGPL. Điều gì về mô-đun Python (* .py) trên giấy phép LGPL trong sản phẩm thương mại? Nó được coi là mã được liên kết?Sử dụng mô-đun Python trên giấy phép LGPL trong sản phẩm thương mại
Tôi không nghĩ rằng vấn đề (cho dù nhập khẩu một mô-đun Python được tính là "liên kết" với nó, cho các mục đích pháp lý của GPL) đã được giải quyết chưa. Tôi không nghĩ rằng nó sẽ được giải quyết cho đến khi một trường hợp tòa án bật nó (và có thể không ngay cả sau đó). GPL được viết một cách cơ bản về mặt C và các công cụ liên quan của nó, vì vậy chỉ rõ ràng cách áp dụng nó nếu ngôn ngữ và công cụ được sử dụng cho phần mềm có các thuộc tính tương tự với các liên kết với C.
Tuy nhiên, nhập Mô-đun Python chắc chắn ở số ít nhất như cho phép tình huống liên kết động với thư viện được chia sẻ; tài liệu có bản quyền (tệp nguồn) bạn liên kết khi bạn nhập import foo không được xác định cho đến khi chương trình thực sự chạy và có thể được thay đổi một cách trivially sau tài liệu có bản quyền của bạn được người dùng cuối di chuyển tệp .py xung quanh trên hệ thống của họ hoặc thậm chí chỉ thay đổi PYTHONPATH.
Cá nhân, tôi thấy các đối số trên dẫn đến kết luận rõ ràng rằng việc thêm import foo vào tệp nguồn của riêng bạn không "sao chép hoặc chỉnh sửa tất cả hoặc một phần [foo.py] theo cách yêu cầu bản quyền" tại tất cả và do đó GPL không thực sự áp dụng nếu bạn không bao giờ sửa đổi foo.py. (Trích dẫn từ the GNU GPL version 3, trong "0 Định nghĩa")
(Về mặt kỹ thuật, tôi cho rằng đối số này cũng sẽ áp dụng để tự động liên kết với thư viện C được chia sẻ, ngoại trừ việc làm như vậy bạn thường phải làm như vậy là #include <foo.h> chương trình biên dịch của bạn là một tác phẩm dựa trên foo.h ngay cả khi bạn cho rằng đó không phải là một tác phẩm dựa trên thư viện được chia sẻ. muốn đẩy điểm bạn có thể phân phối mã nguồn của bạn với giấy phép sở hữu độc quyền và hướng dẫn cho người dùng cuối để biên dịch bản thân. Nhưng tôi digress.)
Không phải là đối số thông thường nhất thiết phải phù hợp với những gì tòa án sẽ quyết định. Nếu bạn coi import foo.py là "liên kết động" với foo.py vì mục đích của (L) GPL, tôi không thấy bạn có thể sai - không ai sẽ kiện bạn vì tôn trọng các điều kiện cấp phép mà bạn không phải .
Mặc dù hợp lý trừ khi bạn yêu thích các vụ kiện tại sao lại có cơ hội. Sự hiểu biết chung là tránh vận chuyển bất kỳ mã LGPL nào trong một sản phẩm thương mại trừ khi nó có thể được biên dịch * thành một tệp nhị phân được chia sẻ trong thư viện. Thật không may Python không thể biên dịch một mô-đun thành một thư viện được chia sẻ nhị phân. Cuối câu chuyện. – swdev
Là tác giả của thư viện, nó có giúp ích gì không nếu tôi chỉ định thêm định nghĩa "liên kết" trong ngữ cảnh của Python? –
@Franklin Làm như vậy đang thay đổi giấy phép. Vì vậy, nó sẽ không giúp bạn sử dụng một thư viện python GPL (L) hiện có.Nếu bạn muốn đưa ra các thư viện python bằng cách sử dụng biến thể của bạn (L) GPL thì có thể, mặc dù bạn có nguy cơ rằng giấy phép của bạn không nhất thiết được coi là tương thích với GPL. – Ben
Kiểm tra đơn giản - người dùng có thể hoán đổi phần LGPL cho phiên bản của riêng mình không?
Thư viện python được nhập bởi chương trình của bạn chắc chắn không được liên kết tĩnh, dạng được biên dịch của nó (hoặc dạng nguồn cho vấn đề đó) không được bao gồm trong các tệp .py (co) do bạn tạo. Vì vậy, bạn ít nhất là sae nhập L/GPLed mô-đun như trình điều khiển thiết bị nvidia cho Linux đang được tự động liên kết với hạt nhân. Chỉ cần nhớ rằng bạn không phải gói phần mềm miễn phí với phần mềm không miễn phí, vì vậy nếu bạn cung cấp thư viện của mình với một thư viện L/GPLed trong cùng một tệp tarball/zip hoặc CD, bạn có thể gặp sự cố. Điều này cũng áp dụng nếu bạn đang phân lớp một lớp ra khỏi một mô-đun, vì bạn không bao gồm trực tiếp mô đun khác. (Người dùng có thể hoán đổi mô-đun L/GPLed cho một mô-đun tương đương với chức năng và mã của bạn sẽ không thông báo hoặc quan tâm). Vùng màu xám duy nhất là nếu bạn sửa đổi nội dung của mô-đun tại thời gian chạy, và sau đó phân phối mô-đun đã sửa đổi, tại thời điểm đó bạn sẽ cần phân phối nguồn đã tạo mô-đun đã sửa đổi. (Hãy nhớ rằng một .pyc, ngay cả khi nó bao gồm một submodule.a = 5 dòng hoặc tương tự trong nó, đã không thay đổi submodule, bạn cần phải pickle hoặc nếu không lưu trạng thái thực hiện của submodule và sau đó phân phối trạng thái đã lưu để nó được tính là thay đổi mô-đun phụ).
Điều này tôi nghĩ là cách duy nhất để xem xét nó, nếu không một chương trình bảng tính OpenOffice kết hợp với các macro OO sẽ cần phải tương thích với LGPL vì bản thân OpenOffice là LGPL. Mô-đun Python nhập mô-đun là sử dụng mô-đun, không tạo ra một tác phẩm có nguồn gốc từ mô-đun đó.
Nếu tôi hiểu chính xác câu hỏi của bạn, bạn đang hỏi xem bạn có thể sử dụng thư viện LGPL trong một sản phẩm thương mại nguồn đóng hay không. Mặc dù tôi không thể tìm thấy bất kỳ điều gì giải quyết tình huống cụ thể này, mọi thứ đều cho thấy không có vấn đề gì. Đầu tiên, có một bài viết về việc sử dụng LGPL in Java. Đây là trích dẫn có liên quan từ bài viết: vị trí
FSF đã vẫn không đổi trong suốt: LGPL hoạt động như dự định với tất cả các ngôn ngữ lập trình nổi tiếng, bao gồm cả Java. Các ứng dụng liên kết đến thư viện LGPL không cần phải được phát hành theo LGPL. Các ứng dụng chỉ cần thực hiện theo các yêu cầu trong phần 6 của LGPL: cho phép các phiên bản mới của thư viện được liên kết với ứng dụng; và cho phép kỹ thuật đảo ngược gỡ lỗi này.
Một quote bổ sung khác từ bài viết có thể có liên quan:
Khi bạn phát hành thư viện với ứng dụng của bạn (hoặc ngày của riêng mình), bạn cần phải có mã nguồn cho thư viện. Nhưng nếu ứng dụng của bạn thay vì yêu cầu người dùng tự mình có được thư viện, bạn không cần phải cung cấp mã nguồn cho thư viện.
Và một quote lần cuối:
Các LGPL chứa không có quy định đặc biệt đối với thừa kế, vì không cần thiết. Thừa kế tạo ra các tác phẩm phái sinh giống như cách liên kết truyền thống và LGPL cho phép loại tác phẩm phái sinh này giống như cách cho phép các cuộc gọi hàm bình thường.
Mặc dù trường hợp cụ thể này không được thử trong một tòa án của pháp luật (ít nhất là tôi biết), tôi sẽ không thức khuya vào ban đêm đáng lo ngại về điều đó. Ngay cả khi LGPL không rõ ràng về vấn đề này, FSF đã xuất bản hướng dẫn rằng LGPL hoạt động như mong đợi đối với tất cả các ngôn ngữ lập trình. Nói chung, nếu một hợp đồng là mơ hồ, sau đó nó được giải quyết có lợi cho bị cáo (đây là một sự đơn giản hóa, nhưng bạn có thể tìm thêm chi tiết here). Nếu bạn thực sự lo lắng, tôi sẽ xem xét việc liên hệ với Free Software Foundation.
Tóm lại, có vẻ như bạn có thể sử dụng phần mềm LGPL bằng Python nếu bạn phân phối mã nguồn của thư viện LGPL với ứng dụng của bạn (cùng với các sửa đổi) hoặc bạn làm cho người dùng cuối cài đặt riêng thư viện này.
Tôi đang bỏ phiếu để đóng câu hỏi này là không có chủ đề vì đó là về cấp phép hoặc các vấn đề pháp lý, chứ không phải lập trình hoặc phát triển phần mềm. [Xem tại đây] (http://meta.stackoverflow.com/questions/274963/questions-about-licensing/274964#274964) và [tại đây] (http://meta.stackexchange.com/questions/139804/can- cấp phép-câu hỏi-bao giờ-được-về-chủ đề) để biết chi tiết, và [trợ giúp] để biết thêm. – JasonMArcher