Можно ли LGPL использовать как библиотеку в коммерческом продукте, не открывая код продукта?

Question

[AllGrit]

Какая должна быть линковка? Статическая или обязательно динамическая? Нужно ли поставлять текст лицензии LGPL. Прочитал саму лицензию, исходя из этого ответ, что LGPL динамическая линковка позволяет держать свой код закрытым. Но хочу перестраховаться, поэтому спрашиваю вас! Большое спасибо, все-таки лицензии момент тонкий…



И еще правильно ли я понимаю, что GPL никак не обойти, чтобы использовать его в каком-нибудь виде, но не открывать свои коды? Или у кого есть какие идеи? Спасибо!

Answer 1

[MikhailEdoshin]

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

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

Comments

[MikhailEdoshin]

И да, GPL можно «обойти», если, например, вы работаете с GPL-продуктом через командную строку или какими-то иными «общими» методами. Но если речь идет о библиотеке, это не подходит.

[AllGrit]

Спасибо за ответ! Теперь все встало на свои места, то есть библиотеки искать только LGPL или BSD лиц.

Answer 2

[Константин Власов]

Линковка обязательно динамическая. По сути, публикации подлежит весь код тех модулей, которые написаны с использованием LGPL-кода. Статическая линковка внедряет код непосредственно в модуль, поэтому тоже попадает в данную категорию.

GPL можно использовать в закрытых проектах, если связь между компонентами происходит не путём загрузки в адресное пространство процесса, а, например, запуском GPL-программы как отдельного процесса и общением с ней через пайпы. Вот только есть ещё тонкий момент касательно распространения такого комбинированного продукта: GPL-программу нельзя комбинировать в одном пакете с проприетарной, если только это не aggregate (комплект отдельных, не связанных друг с другом программных пакетов, с которыми пользователи будут работать независимо; например, подборка для публикации на CD). Но разница между двумя независимыми программами и одной программой, состоящей из двух частей, зачастую слишком тонка и неопределённа.

Рекомендую почитать GPL FAQ.

Comments

[AllGrit]

Спасибо за подробный ответ. тоже попадает в данную категорию? то есть тоже может быть использована и коды открывать свои не нужно?

[MikhailEdoshin]

Разницу, наверное, можно определить так — если убрать GPL модуль, будет ли полезный смысл в оставшейся части программы? Если да, то GPL модуль необязательный и, если технические условия соблюдены (работа через pipes и т. п.), основной код можно не открывать.

[Константин Власов]

то есть тоже может быть использована и коды открывать свои не нужно?

Нет, наоборот: статическая линковка делает из LGPL-кода и не-GPL-кода единый, неделимый модуль, и код всего этого модуля ты обязан открыть.

Разницу, наверное, можно определить так — если убрать GPL модуль, будет ли полезный смысл в оставшейся части программы?

Да, приблизительно так, но всё-таки всё зависит от нюансов.

Answer 3

[AllGrit]

Значит, подводим итоги. Для того, чтобы не открывать свои коды мы:

1) Используем LGPL динамической линковки
2) Используем отдельное приложение на любой (?) лицензии и взаимодействуем с ним как внешним приложением
3) GPL можно использовать в закрытых проектах, если связь между компонентами происходит не путём загрузки в адресное пространство процесса, а, например, запуском GPL-программы как отдельного процесса и общением с ней через пайпы.
4) Используем BSD лицензию

если не прав поправьте, спасибо!