Проприетарные модули в ядрах GPL и BSD

Поскольку ядро Linux является GPL, а не LGPL, я полагаю, что незаконно связывать с ним проприетарный код. Как индустрия обходит это? Я ожидал бы, что лицензия GPL заставит любого разработчика выпустить под GPL-драйвер и/или модуль ядра.

Возможно, я запутался, и внедрение нового модуля на самом деле не связано с кодом ядра??? Как компании справляются с этим? Может быть, ссылка на другой путь (от ядра к их двоичным файлам)?

С другой стороны, есть ядро BSD. Где вы можете связать защищенный IP-адрес. Можете ли вы получить лучший дизайн, реализующий ваши драйверы в ядре BSD? Есть ли какие-либо ограничения в дизайне при реализации драйверов для ядер GPL?

Ответы

Ответ 1

Как вы сказали, лицензия BSD, используемая ядром BSD, намного более либеральна, поэтому нет необходимости связывать любые лицензированные модули.

В случае с linux правильно, что GPL запрещает привязку кода, не совместимого с GPL, который не позволяет связывать проприетарные модули или даже модули LGPL.

Однако обладатели авторских прав на linux предоставляют вам ссылку на ваш модуль LGPL с любым проприетарным кодом. Примером этого является драйвер nvidia:

/------------.-\
| Kernel       |
|              |
|   /--------\ |
|   | Module | |     /-------------------\
|   | (LGPL) <========> proprietary code |
|   \--------/ |     \-------------------/
\--------------/

Это все равно будет незаконным в GPL в целом, но явным образом разрешено для ядра Linux явно . В качестве справочной информации см. информацию о том, что говорит Линус Торвальдс об этой проблеме:

http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html

P.S. Связывание является симметричной операцией в терминах GPL.

Ответ 2

Это не действие связывания себя, которое активирует ограничения GPL.

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

Теперь вопрос становится одним из тех, где нарисована линия "производная работа" - которая далека от кристально чистой (и, вероятно, будет отличаться в разных юрисдикциях!). Например, если вы распространёте скомпилированный ядро Linux с двоичным кодом, статически связанным со своим кодом, это довольно ясно, что весь двоичный файл является "производной работой". С другой стороны, если вы распространяете только ваш модуль, который использует только "опубликованные интерфейсы" ядра, то это, вероятно, не "производная работа".

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

Ответ 3

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

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

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