Проектирование библиотеки GPL со слабыми зависимостями от проприетарных библиотек, лучшие подходы?

Question

Я планирую написать библиотеку C, которая будет выступать в качестве «обертки» для нескольких других библиотек. Некоторые из библиотек будут GPL, а некоторые будут проприетарными. Более того, некоторые библиотеки могут быть недоступны во время компиляции, поэтому я планирую, чтобы автоинструменты обнаруживали их во время настройки. Мне также интересно, стоит ли мне поддерживать эти слабые зависимости, а затем обнаруживать их во время выполнения - особенно для проприетарных библиотек. И вот почему:

Не вдаваясь в подробности, библиотека предназначена для предоставления API для общения с различными устройствами, некоторые из которых не имеют драйверов с открытым исходным кодом. В настоящее время сложно программировать для этих устройств, потому что нет стандартного, легкодоступного API для использования. Каждый поставщик предоставляет свой. Есть несколько других доступных API, которые пытаются обернуть их, но они в общем и целом

• C ++ -. * Только 1006 *
• Предназначен для среды Windows с * nix в качестве запоздалой мысли.
• Сбой сборки, если у вас нет зависимостей в нужных местах, т. Е. Полное отсутствие надлежащей системы конфигурирования / сборки.
• Что наиболее важно, разработано таким образом, что они часто ссылаются непосредственно на проприетарные библиотеки, и я почти на 100% уверен, что эти API невозможно будет внедрить в Debian.

Поэтому моей конечной целью является создание очень простого и понятного C API, у которого есть шанс превратить его в дистрибутивы, чтобы люди могли на самом деле писать программы для этих устройств с помощью простого apt-get.

У меня вопрос: как мне лучше спроектировать библиотеку, чтобы она была совместима с GPL и Debian, но при необходимости иметь возможность обращаться к проприетарным библиотекам?

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

Мое беспокойство двоякое:

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

Как другие пакеты справляются с этой проблемой связи с проприетарными библиотеками и имеют слабые зависимости во время выполнения? dlopen правильный путь для всего? Должен ли я dlopen только фирменный материал? Каковы причины или случаи, когда Debian может отклонить такой пакет?

Наконец, я понимаю, что это, вероятно, не тот форум, на котором можно задать вопрос о политике Debian, поэтому кто-нибудь может указать мне лучшее место, чтобы задать этот вопрос?

Спасибо.

Answer 1

Использование dlopen не меняет того факта, что вы пишете программу для преднамеренного связывания с проприетарными библиотеками и библиотеками GPL, а просто переносит ссылки со времени компиляции на время выполнения. Хотя в народе существует общее мнение о том, что GPL не охватывает динамическое связывание таким образом во время выполнения, это небезопасный юридический совет, чтобы полагаться на такое общее понимание. Я бы решил эту проблему, написав программу с единственным универсальным API для плагинов (который может использовать dlopen, но главное, что вы специально не написали эту программу для связи с проприетарными библиотеками). Программа должна находиться под свободной лицензией, которая совместима со всеми плагинами, с которыми вы в конечном итоге хотите ее использовать (например, LGPL или GPL за исключением этого API). Затем напишите отдельные плагины для библиотек GPL и проприетарных библиотек и распространяйте их отдельно. Если за один раз может быть загружен только один плагин, то нет никаких юридических проблем. Если необходимо разрешить более одного плагина одновременно, то вы должны быть осторожны, чтобы разделить ваш дистрибутив. Поскольку GPL является лицензией на распространение, то, что делают конечные пользователи, не имеет значения.

Answer 2

Я не имею отношения к Debian и не могу говорить об их политике. Однако для вашей среды это кажется разумным подходом:

1. Определите простой заголовочный файл, который выражает необходимую вам функциональность этих плагинов
2. Создайте полезный плагин GPL / LGPL / BSD, который использует этот интерфейс
3. Пусть ваша основная программа загружается с использованием libdl, как вы упомянули (если ваша основная программа - GPL, вам нужно иметь лицензионное исключение, позволяющее связывать проприетарные плагины)
4. Отправьте их для включения в Debian и не упоминайте о проприетарных вещах

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