у других topic станет невалидным
но это не делает их вместе производной работой?
However, copyright law obviously
hinges on the definition of «derived work», and as such anything can
always be argued on that point.
I personally consider anything a «derived work» that needs special hooks
in the kernel to function with Linux (ie it is _not_ acceptable to make a
small piece of GPL-code as a hook for the larger piece), as that obviously
implies that the bigger module needs «help» from the main kernel.
Similarly, I consider anything that has intimate knowledge about kernel
internals to be a derived work.
What is left in the gray area tends to be clearly separate modules: code
that had a life outside Linux from the beginning, and that do something
self-containted that doesn't really have any impact on the rest of the
kernel. A device driver that was originally written for something else,
and that doesn't need any but the standard UNIX read/write kind of
interfaces, for example.
Суть в наличии исключений из GPL. Без них нет способа проприетарному коду использовать GPL код
The «user program» exception is not an exception at all, for example, it's
just a more clearly stated limitation on the «derived work» issue. If you
use standard UNIX system calls (with accepted Linux extensions), your
program obviously doesn't «derive» from the kernel itself.
GPL определяет правила взаимодействия с программными интерфейсами
Программы же взаимодействуют не с ядром, а с glibc прежде всего… В чём я не прав?
чтобы взаимодействовать с GPL нужно следовать правилам GPL
Такова логика лицензии
Что касается Nvidia: драйверы взаимодействуют с ядром. Без ядра они бесполезны. Значит — они дополняют ядро. Значит — они его модификация.
не знаю, что делать с qemu/kvm, ведь они действительно не поддерживают релокацию локального APIC
А вот касательно перемещения регистров, можно подробнее?