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

15

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

Компания 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.

Майкл Курлас
источник
1
Краткий ответ: нет.
whatsisname
2
Я всего лишь юрист, но, насколько я понимаю, динамическое связывание с библиотекой не превращает ваш код в производную работу. В противном случае было бы невозможно распространять что-либо под, скажем, лицензией BSD, которая динамически связывается с чем-то, что может быть под лицензией GPL. Статическое связывание - это отдельная история, и, конечно, вы не можете распространять саму динамически связанную библиотеку ни под чем, кроме GPL.
tdammers
4
@tdammers: AFAIK динамическое связывание делает код производным продуктом, и вы правы, вероятно, невозможно распространять программное обеспечение по лицензии BSD, когда оно использует библиотеки GPL. Вот почему многие авторы библиотек с открытым исходным кодом предлагают свои библиотеки под LGPL вместо GPL.
Док Браун
2
@tdammers: для целей этого сценария я использую подход Столлмана к созданию ссылок: динамическое и статическое соединение нарушают GPL.
Майкл Курлас
3
@mouviciel Были судебные решения, указывающие, что копирование API для целей взаимодействия является законным. Я считаю, что это было установлено независимыми судами высокого уровня как в США, так и в ЕС, поэтому правовой статус довольно солидный (если кто-то активно не изменяет закон).
Donal Fellows

Ответы:

10

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 со ссылками на исключение намного безопаснее, или любой вид невирусной лицензии ОС.

Док Браун
источник
2
Мое инстинктивное чувство подсказывает мне, что адвокаты начнут настаивать сильнее, если компания, которая делает это, Aтакже начнет рекламировать A - C&Dкомбо.
Барт ван Инген Шенау
1
@BartvanIngenSchenau: я согласен. Но я могу представить себе другой сценарий: X распространяет AB, а Y распространяет (и рекламирует) только «дополнительный» C & D с установщиком, который заменяет B в папке установки AB?
Док Браун
Я могу себе представить , что альтернативный сценарий , а также, и это будет намного труднее , адвокаты поставить дыру, если Aи C&Dпроисходят из различных юридических лиц.
Барт ван Инген Шенау
1
@DocBrown: Имеет ли значение эквивалентная фирменная библиотека B? Разве компания X не могла продать А самостоятельно, предполагая, что конечный пользователь должен будет найти рабочую библиотеку, чтобы использовать ее, а затем «удобно» предоставить им D?
Майкл Курлас
1
@MichaelKourlas: из-за наличия lib B продавцу C будет намного сложнее предъявлять иск X, поскольку для X будет проще доказать, что A не является «производным произведением» C.
Док Браун,
3

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

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

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

gnasher729
источник
Должен ли конечный пользователь устанавливать компонент GPL, не имеет значения. Проприетарные модули ядра, которые включают оболочки GPL, обычно распространяют компонент GPL только в форме исходного кода и требуют от пользователя их компиляции. DKMS автоматизирует это. Для этого используется другая «лазейка» GPL, заключающаяся в том, что вы можете делать все, что захотите, с локальной копией программы GPL, если вы не распространяете ее в форме объектного кода. Поскольку конечные пользователи обычно не распространяют ядро ​​Linux вместе с проприетарными модулями ядра и скомпилированными обертками GPL, они в целом безопасны.
Клемент Черлин
1

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

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

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

zxq9
источник
0

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

Офир
источник
Не может ли проблема API быть решена путем включения модуля-оболочки, на который у вас есть авторские права? (см. windyroad.com.au/2006/04/20/… для примера того, о чем я говорю)
Майкл Курлас
Я обновил вопрос, чтобы добавить компонент оболочки.
Майкл Курлас
@ user92103 Этот FAQ отвечает на ваш вопрос? gnu.org/licenses/gpl-faq.html Или этот вопрос P.SE: programmers.stackexchange.com/questions/50118/…
apsillers
1
@apsillers: вопрос P.SE касается связи клиент-сервер по сети. Хотя это, безусловно, возможный способ обойти GPL, это то, о чем я говорю здесь (динамическое связывание). Я посмотрел на FAQ по GPL, и у них есть вопрос, касающийся модуля-оболочки, но этот вопрос предполагает, что распространитель связывает библиотеку GPL с проприетарным приложением в точке распространения. В этом случае конечный пользователь выполняет пакетирование, которое резко меняет ситуацию.
Майкл Курлас