В какой степени определения interop покрываются по их первоначальной лицензии

Question

У меня есть a project, который создает миниатюры для видеофайла, в значительной степени основанный на определениях interop в directshow.net.

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

Но ... Я рассматриваю включение этого кода в производный лицензионный проект MIT. Что оставляет меня в небольшом месте.

Directshow.net имеет лицензию под LGPL, что означает, что я могу зависеть от этой DLL. Но ... я не могу включить код под менее ограничительной лицензией.

Указанные файлы являются определениями взаимодействия, которые можно легко/утомительно определить, прочитав MSDN и переведя материал на C#, если бы я сделал это вручную, я бы скорее всего пришел к тому же коду (или что-то невероятно похожее).

Где я могу здесь бы быть? Как получить эту функциональность в моем лицензионном проекте MIT?

Похожие: http://sourceforge.net/forum/forum.php?thread_id=3040125&forum_id=460697

Answer 1

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

Вещи становятся немного более причудливыми, если вы хотите статически свяжите код библиотеки с исполняемым файлом. Точка LGPL заключается в том, что конечный пользователь должен иметь право изменять (и особенно обновлять) функциональность библиотеки по своей собственной инициативе. Если это автономная DLL, это просто вопрос обмена одной DLL для другой. Если вы берете код и статически связываете его, это не так просто. Затем у вас есть два варианта:

1. Открытый проект с полным исходным кодом с лицензией, совместимой с LGPL. (Этот становится уродливым.)
2. Предоставьте объектный код (файлы компиляции промежуточной стадии, которые передаются в компоновщик) вашим пользователям, чтобы они могли взять обновленную версию библиотеки и связать ее вручную. Это своего рода уродливое решение, но это разрешено.

Лучше всего использовать только DLL.

Answer 2

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

Answer 3

Кроме того, определения интерфейсов, sans 'creative' expression (например, описательные комментарии) не подпадают под действие авторских прав, если используется память. Если единственным кодом, который вы включаете, является такой «шаблонный», то все должно быть в порядке.

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

Answer 4

Возможно, было бы лучше просто избежать юридических головных болей и воссоздать определения взаимодействия. Взгляните на помощника P/Invoke Interop. Просто вставьте заголовки C++ в инструмент, и он даст вам ваши привязки. Это все еще утомительно, но гораздо менее болезненно, чем все это вручную.

Answer 5

Это дополнение к замечанию интерфейсов: (L) GPL - это лицензия, которая вызывается при связывании (вся ее формулировка касается момента связывания), и строго, когда используется заголовок LGPL, NO код LGPL не является фактически связаны.