Есть ли в GPL лазейка, позволяющая связать проприетарное программное обеспечение с библиотеками GPL?

Давайте рассмотрим гипотетический сценарий:

Компания X пишет проприетарную программу (A), которая динамически связывается с проприетарной библиотекой (B). Компания Y хочет использовать заменяющую библиотеку (C), лицензированную по GPL, и поэтому пишет библиотеку-обертку (D), которая динамически связывает и A, и C, и переводит вызовы API, используемые A, в вызовы API, используемые C.

Поскольку D предназначен для использования с C и использует вызовы API C, он является производной от C и поэтому должен распространяться в соответствии с условиями GPL *. В результате объединенная работа A и D также должна распространяться в соответствии с условиями GPL, что невозможно, если учесть, что Компания Y не обладает исходным кодом для A. Тем не менее, пока Компания Y сама распространяет D , нет проблем. Однако, независимо от действий Компании Y, Компания X не нарушает GPL, распространяя A, даже без B. Простое существование D не означает, что A внезапно является производным произведением C (через D), которое должно быть лицензировано в соответствии с GPL также.

Теперь это лазейка: ничто не мешает Компании X написать свою собственную версию D, распространяя ее отдельно от A и сообщая конечным пользователям, что нужно использовать D вместо B при запуске A. Кажется, что компания способна разработка проприетарной программы для использования библиотеки GPL без нарушения GPL при условии, что для изоляции проприетарной программы от библиотеки GPL используется модуль-обертка, и этот модуль распространяется отдельно.

Я прав в своих рассуждениях? Это настоящая лазейка в GPL?

* D также является производной от A, но для целей этого сценария Компания X прямо разрешила создание D и разрешила лицензировать его в соответствии с GPL.

IANAL, но вот мое мнение о том, что разрешено в рамках GPL:

• распространять объединенную работу "A - B" публично: отлично, можно сделать по любой проприетарной лицензии

• создайте обертку lib D для C с помощью Y: хорошо, это не означает, что A нужно поставить под GPL

• использовать комбинированный продукт "A - D - C" внутри Y: также хорошо, GPL не требует открытого источника A, если комбинация не распространяется среди общественности

• распространять объединенную работу "A - D - C" публично: для этого потребуется, чтобы A был открытым исходным кодом и был поставлен под GPL (и не имеет значения, распространяли ли эту комбинацию X или Y; кроме того, если Y хочет сделать это что, им, конечно, потребуется лицензия на распространение для A от X)

Интересный вопрос сейчас: может ли D & C распространяться отдельно как открытый исходный код под лицензией GPL, A & B (или просто A без B) распространяться по закрытой лицензии, и конечный пользователь заменяет B на D & C сам?

Здесь окончательная модификация «AB», которая делает A зависимым от библиотек D & C, выполняется конечным пользователем - после распространения . Таким образом, можно утверждать, что окончательная модификация выполняется только внутренне конечным пользователем. И кажется, что это действительно возможно без нарушения GPL - и вы получаете рабочую комбинацию «AC & D», где A находится под частной лицензией, а C & D под GPL.

Конечно, у адвоката или судьи может быть другое мнение по этому поводу. Чтобы получить окончательный ответ, я думаю, вы должны подождать, пока кто-нибудь не попробует его, а второй подаст в суд на него.

Я предполагаю, что для большинства систем будет трудно создать такое созвездие, не спроектировав "A" с самого начала таким образом, чтобы оно беспрепятственно работало с B или C. И в этом случае можно было бы предположить, что A был как-то получен из C.

РЕДАКТИРОВАТЬ: подумав немного об этом, мне в голову пришла похожая ситуация: написание и распространение лицензионных плагинов GPL для приложений с закрытым исходным кодом. Возьмем, к примеру, Photoshop. Я не думаю, что кто-то серьезно попытался бы заставить Adobe использовать Photoshop с открытым исходным кодом только потому, что существуют некоторые плагины GPL от сторонних поставщиков. Здесь даже не требуется «оболочка lib», поскольку существует четко определенный интерфейс. Однако изменит ли это ситуацию, если Photoshop будет включать некоторые из своих центральных функций из стороннего плагина под лицензией GPL? Я думаю, что для такого случая может быть действительно трудно решить, где провести черту, и в этот момент продукт с закрытым исходным кодом является работой, «основанной» на библиотеке GPL.

РЕДАКТИРОВАТЬ 2: Доступны библиотеки с двумя лицензиями, с лицензией GPL для некоммерческого использования и проприетарной лицензией для коммерческого использования, как, например, эта, Таким образом, ваша «лазейка» будет означать разработку продукта на основе такой библиотеки (используя коммерческую версию, чтобы GPL не применялась к вашему продукту), доставить ваш продукт с закрытым исходным кодом без библиотеки для широкой публики и дать Пользователь получает и устанавливает версию GPL самостоятельно. В таком случае, я полагаю, у продавца библиотеки будет хороший шанс предъявить вам иск за нарушение лицензии (если вы, конечно, не заплатите за его библиотеку). Стоит ли хлопот? Возможно нет. В частности, в приведенном мной примере вам также придется купить библиотеку, поскольку цена зависит не от того, как часто вы продаете свой продукт, а только от того, сколько разработчиков используют библиотеку во время разработки.

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

Практическим примером являются проприетарные графические драйверы для Linux, которые конечный пользователь должен установить самостоятельно. Для создателя проприетарного драйвера важно, что если конечный пользователь распространяет объединенную работу, это создает юридическое обязательство для конечного пользователя (которое он не может выполнить), но не для создателя драйвера.

Другой ответ утверждает, что «поскольку программа зависит от библиотеки, она все еще является производной работой», но если программа на самом деле не работает, потому что библиотеки нет, то она не является производной.

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

Связывание определяет производную от GPL. Эта специфическая ситуация - то, что LGPL был разработан для обработки: где вы хотите выпустить библиотеку как GPL, но определяете связывание как явное ограничение применяемой лицензии, или, альтернативно, где вы хотите связать с некоторым кодом GPL, но требуете, чтобы ваша собственная работа должна быть выпущена под лицензией не GPL.

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

Тем не менее, если проект требует, чтобы он был построен из исходного кода и распространялся только таким образом, не имеет значения, под какой лицензией находится связанная библиотека, так как это полностью вне рук разработчика, не являющегося лицензией GPL. То есть как вы можете знать, что ваш дистрибутив только для исходного кода будет построен на gcc с glibc VS, созданным на компиляторе IBM с их libc, если вы не укажете это в соответствии со своими условиями лицензирования? Это быстро приводит к добросовестному использованию и запретам на неисполнимые правовые условия (не то, чтобы фантазия не была вписана в закон в последнее время довольно часто).

Я не юрист, но, насколько я могу судить, вы не правы, так как программа зависит от библиотеки - это все еще производная работа. Точно так же, как продолжение это производная работа. Как минимум, он основан на API, определенных в библиотеке.