LINUX.ORG.RU

Linux Kernel Module - обязательно ли он должен быть под GPL лицензией?

 , , ,


0

1

Всем привет.

Разрабатываю железку, которую планируется массово продавать. В первый раз имею дело с Linux и его драйверами : ) Посему не судите строго за, возможно, нубские вопросы. Тему предварителько пытался понять из гуглопоиска, но что-то вот не понял ничего из прочитанного. Везде по-разному пишут.

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

И тут встаёт вопрос - как лицензировать драйвер? В нём используются функции, экспортируемые ядром через EXPORT_SYMBOL_GPL (например platform_device_register), которые, как я понял, могут использоваться _только_ GPL драйверами.

Собственно, как обычно делается в таких случаях? Как, например, NVIDIA разрабатывает свои проприетарные драйвера?

Можно ли сделать какой-то GPL загрузчик нашего основного проприетарного модуля? Или какие вообще есть варианты?

Заранее большое спасибо.

Ответ на: комментарий от devl547

А не подскажете ли ссылок, где можно об этом почитать?

Ещё такой вопрос: читал где-то в интернетах, что дрова, поставляемые не с самим линуксом, могут быть проприетарными и свободно распространяться.

То есть возможен ли такой вариант: поставка железа с линуксом без нужных драйверов, дрова на отдельном диске с установщиком, который сам по всем девайсам раскидает их.

l-proger
() автор топика

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

trex6 ★★★★★
()

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

Это не мне здесь решать, посему дальнейшее обсуждение этого бессмысленно.

l-proger
() автор топика
Ответ на: комментарий от trex6

Это весьма геморройный путь на самом деле. Девайсы работают на Linux-е, но весь софт для работы с самими девайсами пишется для Windows-а. Компилировать тогда придётся удалённо на самих девайсах.

l-proger
() автор топика
Ответ на: комментарий от trex6

А что скажете насчёт такого варианта:

1. Пишется GPL драйвер-прослойка, который просто оборачивает GPL функции и экспортирует их под другими именами. Он автоматически загружается с системой и символы эти всегда доступны

2. Пишется не GPL драйвер, который линкуется с первым драйвером динамически. Таким образом компилировать ничего не надо будет. Всё что надо будет сделать юзеру - залинковать 2-й драйвер.

l-proger
() автор топика
Ответ на: комментарий от l-proger

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

trex6 ★★★★★
()

Linux Kernel Module - обязательно ли он должен быть под GPL лицензией?

Это зависит от того, является ли модуль ядра derivative work. FSF и Торвальдс считают, что является. Но судебных прецедентов пока не было, поэтому единого мнения нет.

Практика такова, что не-GPL модули существуют и Торвальдс обещал сохранить их поддержку.

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

Собственно, как обычно делается в таких случаях? Как, например, NVIDIA разрабатывает свои проприетарные драйвера?

nVidia распространяет GPL-ную прослойку + проприетарный блоб, сборка собственно ядерного модуля происходит на машине пользователя. Поэтому nVidia как бы ни при чем. Но если вдруг когда-нибудь суд решит, что ядерные модули — derivative work, то такая модель станет нелегальной.

Подробнее: http://tldp.org/HOWTO/Module-HOWTO/copyright.html

Relan ★★★★★
()
Ответ на: комментарий от l-proger

Пишется не GPL драйвер, который линкуется с первым драйвером динамически.

не важно динамически или статически, все равно он должен быть под gpl, если первый под gpl

hatefu1_dead
()
Ответ на: комментарий от l-proger

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

Чтобы собрать модуль ядра вам нужны заголовки ядра. Поэтому бинарь будет содержать GPL код => весь модуль обязан быть под GPL.

Relan ★★★★★
()
Ответ на: комментарий от trex6

trex6

существляет пользователь и вся ответственность за нарушение лицензии ложится на его плечи

лицензия будет нарушена только в том случае, если пользователь будет распрострянять результат линковки

unC0Rr ★★★★★
()
Ответ на: комментарий от Relan

Но если вдруг когда-нибудь суд решит, что ядерные модули — derivative work, то такая модель станет нелегальной.

И придется пользоваться нелегальным линуксом …

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от vasily_pupkin

С чего бы? Заголовки != код

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

l-proger
() автор топика
Ответ на: комментарий от hatefu1_dead

Ок, тогда получается можно делать так:

Я пишу единый драйвер. Один из его объектных файлов - враппер GPL_ONLY функций, все остальные модули юзают только эти функции, никак не инклудя в себя хедеры самого линукса.

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

Отдельно юзер через нашу тулзу апдейта докачивает проприетарные объектные файлы и всё что остаётся сделать - слинковать .ko из готовых объектников.

l-proger
() автор топика
Ответ на: комментарий от unC0Rr

Интересно получается..

Судя по всему выходит следующее: если я просто свой драйвер компилирую но не линкую в .ko , то я ничего не нарушаю? Я могу отдать юзеру набор скомпилированных *.o объектных файлов а он сам для себя их уже соберёт. И никто ничего не нарушит (если он потом это распространять не станет).

Верно?

l-proger
() автор топика
Ответ на: комментарий от vasily_pupkin

Чтобы собрать модуль ядра вам нужны заголовки ядра. Поэтому бинарь будет содержать GPL код

С чего бы? Заголовки != код

Возникает вопрос: а что считать кодом? Тело функции — это код? В хедерах линукса есть inline функции. Опять же, не понятно как это вообще соотносится с понятием derivative work, которое не разделяет этот самый work на код и не код.

Relan ★★★★★
()
Ответ на: комментарий от Relan

Бинарь не будет содержать заголовки ядра, он будет содержать только заголовки «прокладки». Прокладка для драйвера может быть под public domain, так что ее можно и с GPL-кодом слинковать и с закрытым. Линкуется она и с тем и с другим руками пользователя, так что дальше за все несоответствия лицензий отвечает пользователь.

trex6 ★★★★★
()
Последнее исправление: trex6 (всего исправлений: 1)
Ответ на: комментарий от l-proger

В принципе, да. Теоретически твои объектники могут быть и не для ядра линукса, это дело юзера сделать из них драйвер именно под gpl-ный линукс.

unC0Rr ★★★★★
()
Ответ на: комментарий от vasily_pupkin

Посмотри обсуждения про bionic

Насколько я понял, там ничего нового сказано не было. Столлман еще давно говорил, что derivative work получается благодаря макросам и инлайн-функциям в хедерах: http://lkml.indiana.edu/hypermail/linux/kernel/0301.1/0362.html

Relan ★★★★★
()

Я не силен в лицензиях, но разве нет стандартного пути в виде GPL ядро -> LGPL прослойка -> Закрытый код?

pathfinder ★★★★
()
Ответ на: комментарий от pathfinder

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

l-proger
() автор топика
Ответ на: комментарий от l-proger

если нельзя не использовать gpl-only функции, то это все будет неудобнее, так как надо будет таскать с собой компилятор на устройствах.

Друглой вариант - подготовить инсталлятор с colinux/qemu и кросскомпилятором, который соберет/слинкует модули на рабочей станции пользователя, и задеплоит на железки. Хотя честно говоря, не встречал ни единого раза ресльно стоящее IP в ядре - обычно удавалось убедить манагеров, что оно того не стоит. Рельно дельные алгоритмы всегда были в userspace.

slapin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.