在商業產品的LGPL許可證上使用Python模塊

在LGPL許可證中記載了可以在不改變LGPL產品的許可證的情況下，在商業封閉產品中使用未經修改的鏈接代碼。商業產品中的LGPL許可證上的Python模塊（* .py）怎麼樣？它被視爲鏈接代碼？在商業產品的LGPL許可證上使用Python模塊

來源

2011-12-20 scdmb

我投票關閉這一問題作爲題外話，因爲它是關於許可或法律問題，而不是編程或軟件開發。 [見這裏]（http://meta.stackoverflow.com/questions/274963/questions-about-licensing/274964#274964）和[here]（http://meta.stackexchange.com/questions/139804/can-許可問題永遠在主題上）以獲取詳細信息，以及[幫助]瞭解更多信息。 – JasonMArcher 2015-06-14 00:44:49

我不認爲這個問題（爲了GPL的合法目的，導入Python模塊是否被視爲「鏈接」）已經得到解決。我認爲在法院案件打開之前（甚至可能還沒有），這個問題不會得到解決。 GPL（可惜）基本上是用C語言及其相關工具編寫的，所以如果軟件使用的語言和工具具有與C相關的語言和工具類似的特性，那麼只有很明顯。

但是，導入Python模塊肯定在至少作爲寬容的情況下動態鏈接到共享庫;當您鍵入import foo時鏈接到的受版權保護的文檔（源文件）只有在程序實際運行後才能確定，並且可以進行簡單更改後您的版權文檔由最終用戶在其系統上移動.py文件生成，甚至只是改變PYTHONPATH。

就個人而言，我覺得上述論點明確導致，添加import foo到自己的源文件中的結論並不「從複製或改編的[foo.py]全部或部分以一種方式需要版權許可」 在全部爲，因此如果您從不修改foo.py，則GPL並不適用。（引自the GNU GPL version 3，在「0定義」）

（從技術上講，我認爲這種說法也適用於動態鏈接到一個共享的C庫爲好，只是這樣做你通常不得不#include <foo.h>，這意味着你編譯的程序是基於foo.h的工作，即使你認爲它不是基於共享庫的工作。雖然你的代碼將完全不受GPL的影響，但有趣的是，如果你想推出一點，你可以分發你的源代碼與專有的許可證和最終用戶編譯自己的說明，但我離題了。）

不是常識性論據必然與法院的決定相匹配。如果您將import foo.py視爲「動態鏈接」與foo.py（L）GPL的目的，我不會看到你會怎麼做錯 - 沒有人會因爲遵守許可條件而起訴你技術上沒有的。

來源

2011-12-20 22:17:13 Ben

雖然合乎邏輯，除非你喜歡官司，爲什麼要這麼做呢。通用的理解是避免在商業產品中運送任何LGPL代碼，除非它可以*編譯成共享庫二進制文件。不幸的是，Python無法將模塊編譯爲共享庫二進制文件。故事結局。 – swdev 2015-03-03 01:01:16

作爲庫的作者，如果我另外在Python的上下文中指定「鏈接」的定義，它有幫助嗎？ – 2017-02-10 19:14:56

@Franklin這樣做改變了許可證。因此，它不會幫你使用現有的（L）GPL Python庫。如果你想使用你的（L）GPL變體來發布python庫，那麼儘管你冒着許可證不一定被認爲與GPL兼容的風險。 – Ben 2017-02-10 22:43:56

簡單測試 - 用戶可以將LGPL部件換成他們自己的版本嗎？

來源

2011-12-20 18:37:00

由程序導入的python庫肯定不是靜態鏈接的，它的編譯形式（或者源代碼形式）不包含在你創建的.py（co）文件中。所以你至少要導入L/GPLed模塊，因爲Linux的nvidia設備驅動程序正在與內核動態鏈接。請記住，您不應該將免費軟件與非免費軟件捆綁在一起，因此，如果您使用同一個tarball/zip文件或CD爲L/GPL庫提供庫，則可能會遇到問題。如果您將一個類從模塊中分類出來，這也適用，因爲您不直接包含其他模塊。（用戶可以將L/GPLed模塊替換爲功能相同的模塊，並且您的代碼不會注意或關心）。唯一的灰色區域是如果您在運行時修改模塊的內容，然後分發修改後的模塊，此時您需要分發生成修改模塊的源。（請記住，一個.pyc，即使它包含一個submodule.a = 5行或類似的東西，也沒有改變子模塊，你需要醃製或者保存子模塊的執行狀態，然後分發保存狀態以便計算爲更改子模塊）。
這是我認爲唯一的方法來看待它，否則OpenOffice電子表格程序結合OO宏需要LGPL兼容，因爲OpenOffice本身就是LGPL。導入模塊的Python模塊是，使用該模塊，而不是從中創建派生工作。

來源

2012-02-02 01:00:46 Perkins

如果我正確理解您的問題，您是問您是否可以在封閉源商業產品中使用LGPL'ed庫。雖然我找不到解決這一特定情況的任何事情，但一切都表明應該沒有問題。首先，有一篇關於使用LGPL in Java的文章。這是文章的相關報價：

FSF的位置始終保持不變：LGPL的工作原理與所有已知的編程語言一樣，包括Java。鏈接到LGPL庫的應用程序不需要在LGPL下發布。應用程序只需遵循LGPL第6節中的要求：允許庫的新版本與應用程序鏈接;並允許逆向工程來調試。從文章可能相關

一種其他額外的報價：

當你與你的應用程序分發庫（或自己），你需要包括庫的源代碼。但是，如果您的應用程序需要用戶自行獲取庫，則不需要提供庫的源代碼。

而最後一個報價：

的LGPL包含繼承無特殊規定，因爲需要沒有。繼承以與傳統鏈接相同的方式創建派生作品，並且LGPL允許以類似於允許普通函數調用的相同方式進行此類派生工作。

確實，這個特殊案件還沒有在法庭上審理過（至少我知道），我不會在夜裏熬夜擔心。即使LGPL在這個問題上並不完全清楚，FSF已經發布了指導意見，LGPL如預期地爲所有編程語言工作。一般來說，如果一份合同不明確，那麼它就被解決了，而被告的利益（這是一個過於簡單化，但你可以找到更多的細節here）。如果你真的很緊張，我會考慮聯繫Free Software Foundation。

總之，如果您將LGPL'ed庫的源代碼與您的應用程序（以及您的修改）一起分發，或者讓最終用戶單獨安裝此庫，則您可以在Python中使用LGPL軟件。

來源

2012-08-28 21:43:12

在商業產品的LGPL許可證上使用Python模塊

回答

相關問題