Модули ядра без GPL с использованием GPL

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

// GPL 2 kernel module  (gpl.c -> gpl.ko)
void a_function(void)
{
// ...
}
EXPORT_SYMBOL(a_function)


// Closed Source module (closed.c -> closed.ko)
a_function();

Является ли это законным? Нарушаем ли мы лицензию GPL2 в этом примере? Обратите внимание, что closed.c не включает заголовочный файл gpl2.

Ответ 1

Для модулей есть флаг GPL_ONLY, который не должен использоваться в модулях, отличных от GPL. Поэтому, если модуль, о котором вы говорите, не GPL_ONLY, вы можете его использовать.

Но даже те, которые являются GPL_ONLY, могут использоваться, если вы обращаетесь к ним через пользовательские пробелы, которые возможны в 2.6.23. Именно это и произошло с подсистемой USB. http://www.linux-magazine.com/online/news/linux_2_6_25_without_closed_source_usb_drivers

Не совсем решать юридическую проблему, но дает вам некоторую идею: http://www.cyberciti.biz/tips/linus-rejects-the-idea-of-non-gpl-kernel-modules.html

Ответ 2

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

Однако вы могли бы рассмотреть другой раскол. Один из подходов состоит в том, чтобы полностью модуль GPL и поместить весь свой "секретный IP-адрес компании" пользователю космический водитель. Это подход, который я предпринял, когда компания, с которой я работал не был заинтересован в том, чтобы разоблачить детали нашей FPGA миру. Все решениях и настройках регистра, где в пользовательском пространстве и сторона ядра драйвера загружает только значения в IRQ. С осторожным вы можете управлять любыми проблемами в реальном времени, которые у вас есть, и хорошее чистое разделение между вашим закрытым драйвером и ядром. я считают, что это проще с более новыми ядрами с поддержкой пользовательского пространства хотя я не думаю, что они поддерживают DMA должным образом (я должен был кодировать модуль ядра DMA для поддержки DMA непосредственно между чипсет и пользовательское пространство).

Однако (опять же) я действительно рекомендую вам подумать о том, пытаясь защитить. Закрытые драйверы могут быть в порядке для встроенных приложений где у вас жесткий контроль над версией ядра и оборудованием. Но если этот драйвер рассматривается для чего-то более общего (т. продажи аппаратных людей будут подключаться к их собственным системам), затем закрывается драйверы источника будут только оказаться источником постоянной боли и головные боли обслуживания.

Ответ 3

1-й: вам нужно поговорить с адвокатом об этом; вероятно, юридический отдел вашей компании.

2nd: Важный вопрос: какой фрагмент кода выведен из другого кода.

К сожалению, ответов на этот вопрос почти не существует.

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

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

Ответ 4

Существует мнение некоторых ключевых разработчиков ядра (но не самого Линуса) о том, что любой модуль, не являющийся GPL'ом, является нарушением лицензии ядра.

Когда некоторые разработчики разорвали драйвер Belkin с маршрутизатора Linksys, изменили его и опубликовали результат, Белкин не смог остановить их из-за противодействия приведению этой интерпретации лицензии в суд в качестве защиты.

Ответ 5

Бесчисленные другие драйверы использовали "прокладку" с открытым исходным кодом для соединения объектного файла с закрытым исходным кодом с ядром с открытым исходным кодом. Большинство разработчиков ядра считают, что это нарушение, по крайней мере, по духу GPL.

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

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

* выше мое мнение *