Нарушение ли LGPL Qt

Да

очевидно, я знал что будет или «да» или «нет» )
но хотелось бы развернутый ответ
программа ведь стартует и работает (какое то время)

С чего бы вдруг?

Если программа закрытая, т.е. распространяется без исходников (в ОП это не указано, но иначе какой смысл в такой проверке) - то однозначно нарушение. Суть основного требования LGPL как раз и состоит в предоставлении возможности линковки с другой сборкой Qt. (Она даже не обязательно должна быть динамической - просто при статической линковке надо предоставить хотя бы объектные модули).

не совсем понял слово «линковка» в применении к динамической библиотеке
есть бинарник и либы qt
бинарник можно запустить и с другой версией qt и он будет работать - выведет qmessagebox. т.е. возможность запуска есть

Ну ты же сам понимаешь, что это неполноценная работа. :)

понимаю, но понятие «полноценная» работа разве оговорено в lgpl ?

Интересно, считаешь ли ты, что программа работает, если она запускается и сразу крашится?

Работает, но совсем чучуть :)

а если крашится после часа работы?

если у вас пропатченая qt, то просто выложите свои патчи на нее и инструкцию по сборке, как этого требует lgpl. Если у пользователя будет возможность собрать правильные бинари, которые проходят проверку, то нарушения lgpl тут не вижу.

так ведь не крашится, а корректно выходит, да работая немного иначе - это запрещено ?

Лучше честно напиши - зачем тебе эта ерунда? Разве обычного стандартного ни-капли-не-патченного Qt5 недостаточно?

не пропатченная, может даже «штатная» из убунты
или сам собрал, но включив опции оптимизации, выкинув лишнее
показать строку сборки - не вопрос
у пользователя да, будет возможность собрать теже самые либы вплоть до байта (ну почти, если что линкер добавит сам, без моего ведома)

никапли непатченного qt5 - достаточно конечно
но не хочу запускать с «неизвестными» либами - вот такое желание обдумываю

Так если ты не сделал никаких модификаций, то как ты узнаешь твои это либы или нет?

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

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

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

именно это я и спрашиваю - это нарушение какого пункта lpgl ?

а если не та либа - не работаем, уязвимость невозможна )

это я понимаю, что суд и все дела ...

но чисто по lpgl четкого запрета не нашел, потому и спросил
технически программа запускается и «работает» - т.е. процесс загрузки либ прошел успешно

Пункт 4 Combined Works.

You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications

Четко написано что не должно быть никаких ограничений на модификацию библиотеки.

но не хочу запускать с «неизвестными» либами - вот такое желание обдумываю

Ну так и предупреждай пользователя перед запуском, что «Моё крутое приложение протестировано на Qt 5.10.0, использование библиотек другой версии может привести к нежелательным последствиям.».

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

P.S. и вообще ломать пальцы надо таким ограничаторам, никакой полезности эти модификации не несут, а лишь усложняют работу с приложением. Это самый что ни на есть bad practice.

а если не та либа - не работаем, уязвимость невозможна )

А если либа та — работаем с уязвимостью)))))))))))))))))))))))))))))))))))))))))))))))))))))

^ Вся суть подобных идиотских ограничений.

Тебе просто версию проверять? Главное чтобы не старее чем нужно, а дальше работать будет без проблем. То, чего ты опасаешься, бывает в редчайших случаях нарушения совместимости. Если какого-то плагина или там собрано без нужной тебе опции - то пиши что «не хватает Х, ой не могу работать» - вот и всё.

ну если тут читать как «любые» модификации, то наверно да, нельзя

пока иных мыслей не имею

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

а привязать к либам, которые «протестированы» - нельзя

Ты лучше тогда по другому делай - пиши какие либы рекомендованы, а если либа не рекомендована пиши варнинг, что либа может не подходить, содержать уязвимость и т.д.. Так ты ничего не нарушишь, скорее всего.

просто выложите свои патчи на нее и инструкцию по сборке, как этого требует lgpl.

Не катит: lgpl требует выложить исходники целиком, а не только патчи. Мелочь, но существенная

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

Суть основного требования LGPL как раз и состоит в предоставлении возможности линковки с другой сборкой Qt.

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

ты обязан открыть как эти изменения, так и код своего софта.

А не только изменённую библиотеку разве?

так и код своего софта.

Откуда это утверждение?

Если пользователь может собрать «ту» версию из исходников, которые ты ему предоставишь, то нет нарушений

А, ну тогда ок, а то я что-то даже растерялся прям)

На тивоизацию похоже.

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

mpv так и делает да так усердно, что в Debian его патчат, отучают от выдачи предупреждения, что версия ffmpeg не точь-в-точь, как на момент линковки.

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

я хотел именно не работать с иными либами (по любым причинам), но на данный момент получается это нарушает lgpl

Мне кажется эту неоднозначность в формулировке пофиксили в LGPLv3 так что уже не надо открывать свой софт.

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

Полный бред. Модификация LGPL-бибилиотеки приводит к созданию новой LGPL-библиотеки, которая имеет не меньше прав называться «немодифицированной», чем первая.

mpv прав, Debian нет. Т.к. ffmpeg постоянно меняется, у него нет понятия стабильного релиза.

Debian вполне прав. У ffmpeg есть вполне стабильные релизы: x.y. Для каждого баг-фикс-релиза x.y.z нет никакой необходимости пересобирать все зависящие от ffmpeg пакеты, включая mpv.

Пофиксилили ж уже

https://github.com/mpv-player/mpv/issues/2110

Я о том, что это вернули взад (mpv 0.18.1): https://github.com/mpv-player/mpv/commit/d057e7a142a327c653f3f037901456702844...

Значит стало снова актуально :-)

Предполагается, что ты полагаешься на API/ABI библиотеки, которое должно быть стабильным, в теории. Но на практике, конечно, видим такую картину: https://abi-laboratory.pro/tracker/timeline/qt/

Вот только чаще всего «движуха» ломания API идёт в новоиспечённых модулях, а старые давно окаменели и стабильны. Я сильно сомневаюсь, что ты используешь именно новые модули.

Политика запрещения и добавления палок в колёса — это плохо, именно для того и созданы эти лицензии. Ты можешь перенять опыт того же mpv и выдавать предупреждение при запуске. Это будет самым рациональным и правильным решением.

Каждый случай - потенциальный повод для судебного разбирательства, там много тонкостей. Могут признать derived work, могут нет. Поэтому в общем случае модифицировать библиотеку не надо, если не хочется открываться под копилефтом.

Пункт №6:

b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with.

Приложение должно собираться и работать одинаково с любой библиотекой, которая предоставляет совместимый интерфейс (семантика реализации в интерфейс не входит).

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

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

Это уже проблемы пользователя, что у него софт может некорректно отработать. Ты можешь его предупредить, если прям уверен, что на новых версиях Qt будут проблемы. Правда, тогда лучше просто таскать с собой свою версию Qt (а то пользователь накатит апдейтов и всё). Тогда можно и на проверки забить - если пользователь полез заменять файлы приложения, то он уже ССЗБ и пусть всё делает на свой страх и риск. С таким успехом он может вообще заменить несколько рандомных байт в основном бинарнике и приложение начнёт сегфолтиться ещё до проверок.

Или же ты беспокоишься, что пользователь модифицирует поведение функции Qt, на которой строится какая-нибудь твоя хитрая защита от копирования твоего софта? Обойти это будет не сложнее, чем патчить нужную функцию.

Приложение должно собираться и работать одинаково с любой библиотекой, которая предоставляет совместимый интерфейс (семантика реализации в интерфейс не входит).

что значит «одинаково» ?

Но на практике, конечно, видим такую картину: https://abi-laboratory.pro/tracker/timeline/qt/

Интересно, конечно, как они эту Backward Compatibility меряют...

При своем старте программа проверит с какими либами она стартовала и если это не те «нужные», то выход.

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