Использование модуля Python на лицензии LGPL в коммерческом продукте

Ответ 1

Я не думаю, что проблема (будь то импорт модуля Python, считающегося "связыванием" с ним, для юридических целей GPL) еще не урегулирован. Я не думаю, что это будет разрешено, пока судебное дело не включит его (и, возможно, даже не тогда). GPL (к сожалению) написан в основном в терминах C и связанных с ним инструментов, поэтому он просто очевиден, как применять его, если язык и инструменты, используемые для программного обеспечения, имеют схожие свойства с теми, которые связаны с C.

Тем не менее, импортирование модуля Python, по крайней мере, как разрешительная ситуация, как динамическая привязка к общей библиотеке; который защищенный авторским правом документ (исходный файл), с которым вы ссылаетесь при вводе import foo, не определяется до тех пор, пока программа не будет запущена, и может быть тривиально изменена после того, как ваш защищенный авторским правом документ будет создан конечным пользователем, перемещающим файлы .py в их систему, или даже просто изменение PYTHONPATH.

Лично я считаю, что приведенные выше аргументы ясно показывают, что добавление import foo в ваш собственный исходный файл не "копирует или не адаптирует все или часть [foo.py] способом, требующим разрешения на использование авторских прав" вообще, и, таким образом, GPL не применяется, если вы никогда не изменяете foo.py. (Цитата из версия GNU GPL версии 3 в разделе "Определения" )

(Технически я считаю, что этот аргумент применим и к динамической привязке к общей библиотеке C, за исключением того, что для этого вам обычно приходилось #include <foo.h>, что означает, что ваша скомпилированная программа - это работа, основанная на foo.h даже если вы утверждаете, что это не работа, основанная на общей библиотеке. Хотя ваш исходный код был бы полностью исключен GPL с этой интерпретацией, достаточно интересно, поэтому, если вы хотите подтолкнуть точку, вы можете распространять исходный код с помощью проприетарную лицензию и инструкции для конечного пользователя для компиляции. Но я отвлекаюсь.)

Не то, что аргументы здравого смысла обязательно совпадают с тем, что решит суд. Если вы рассматриваете import foo.py как "динамически связывание" с foo.py для целей (L) GPL, я не вижу, как вы ошибетесь - никто не будет судиться с вами за соблюдение условий лицензии, которые вы технически не сделали должны.

Ответ 2

Простой тест - пользователь может поменять часть LGPL на свою собственную версию?

Ответ 3

Если я правильно понял ваш вопрос, вы спрашиваете, можете ли вы использовать библиотеку LGPLed в коммерческом продукте с закрытым исходным кодом. Хотя я не мог найти ничего, что касалось этой конкретной ситуации, все предполагает, что проблем не должно быть. Во-первых, есть статья об использовании LGPL в Java. Это соответствующая цитата из статьи:

Положение FSF оставалось постоянным: LGPL работает по назначению со всеми известными языками программирования, включая Java. Приложения, которые ссылаются на библиотеки LGPL, не должны выпускаться под LGPL. Приложения должны следовать только требованиям раздела 6 LGPL: разрешить связывание новых версий библиотеки с приложением; и разрешить обратное проектирование, чтобы отладить это.

Еще одна дополнительная цитата из статьи, которая может иметь значение:

Когда вы распространяете библиотеку с вашим приложением (или самостоятельно), вам необходимо включить исходный код для библиотеки. Но если ваше приложение вместо этого требует, чтобы пользователи сами получали библиотеку, вам не нужно предоставлять исходный код для библиотеки.

И одна последняя цитата:

LGPL не содержит специальных положений для наследования, потому что они не нужны. Наследование создает производные работы так же, как традиционное связывание, и LGPL разрешает этот тип производных работать так же, как позволяет обычные вызовы функций.

Хотя верно, что этот конкретный случай не был судим в суде (по крайней мере, я знаю), я бы не спал ночью, беспокоясь об этом. Даже если LGPL точно не знает эту проблему, FSF опубликовала руководство, согласно которому LGPL работает так, как ожидалось, для всех языков программирования. В целом, если договор неоднозначен, тогда он разрешается в пользу подсудимого (это упрощение, но вы можете найти более подробную информацию здесь). Если вы действительно нервничаете, я бы посоветовал обратиться в Free Software Foundation.

В целом, похоже, что вы можете использовать программное обеспечение LGPL с Python, если вы либо распространяете исходный код библиотеки LGPL с вашим приложением (вместе с вашими изменениями), либо вы производите установку этой библиотеки по отдельности.

Ответ 4

Библиотека python, импортированная вашей программой, конечно, не статически связана, скомпилированная ее форма (или исходная форма) не входит в файлы .py(co), созданные вами. Таким образом, вы, по крайней мере, импортируете модули L/GPLed, поскольку драйверы устройств nvidia для linux динамически связаны с ядром. Просто имейте в виду, что вы не должны связывать бесплатное программное обеспечение с несвободным программным обеспечением, поэтому, если вы предоставите библиотеке L/GPL в одном файле tarball/zip или на компакт-диске, у вас могут возникнуть проблемы. Это также относится к классу, если вы подклассифицируете класс из модуля, так как вы не включаете другой модуль напрямую. (Пользователь может поменять модуль L/GPLed на функционально эквивалентный, и ваш код не заметит и не позаботится). Единственная серая область - это изменение содержимого модуля во время выполнения, а затем распространение модифицированного модуля, после чего вам необходимо будет распространить источник, создавший модифицированный модуль. (Имейте в виду, что .pyc, даже если он включает в себя субмодуль. A = 5 или аналогичный в ней, не изменил подмодуль, вам нужно будет раскрыть или иначе сохранить состояние выполнения подмодуля, а затем распределить сохраненное состояние, чтобы оно учитывалось как изменение вспомогательного модуля).
Я думаю, это единственный разумный способ взглянуть на него, или же программа OpenSffice для электронных таблиц в сочетании с макросами OO должна быть совместима с LGPL, потому что OpenOffice сам LGPL. Модули Python, импортирующие модуль, используют этот модуль, не создавая из него производную работу.