Módulos de kernel no GPL que usan GPL

Question

La empresa para la que trabajo está desarrollando un módulo kernel de fuente cerrada (archivo .ko). Este módulo tiene que hacer llamadas a funciones que están contenidas en un módulo gpl2. Básicamente tenemos una situación como esta:

// 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(); 

¿Esto es legal? ¿Estamos violando la licencia GPL2 en este ejemplo? Tenga en cuenta que closed.c no incluye ningún archivo de encabezado gpl2.

Answer 1

Hay GPL_ONLY indicador para los módulos, que no deben utilizarse en módulos que no sean GPL. Entonces, si el módulo del que está hablando no es GPL_ONLY, puede usarlo.

Pero incluso estos que son GPL_ONLY se pueden utilizar si accede a ellos a través de user-space drivers, which are possible in 2.6.23. Eso es exactamente lo que le sucedió al subsistema USB. http://www.linux-magazine.com/online/news/linux_2_6_25_without_closed_source_usb_drivers

No abordar exactamente tema legal, pero le da una idea: http://www.cyberciti.biz/tips/linus-rejects-the-idea-of-non-gpl-kernel-modules.html

Answer 2

1º: Debe hablar con un abogado al respecto; probablemente el departamento legal de su compañía.

2º: La pregunta importante es qué parte del código se deriva de qué otro código.

Desafortunadamente, hay casi cualquier número de respuestas para esta pregunta.

Algunos sostienen que todos los módulos del kernel son trabajos derivados del núcleo, por lo que tienen que ser GPL independientemente de la inclusión del encabezado.

Alternativamente, su módulo cerrado se deriva del módulo GPL, y el módulo GPL deriva del kernel, por lo que el módulo cerrado también debe ser GPL.

Answer 3

IANAL por lo que realmente debe buscar la opinión legal cualificado. Sin embargo, este enfoque va contra el espíritu de la licencia y no le ganará ningún amigo en kernel land.

Sin embargo, podría considerar una división diferente. Un enfoque es tener un módulo completamente GPL y poner toda su "IP de compañía secreta" en un controlador de espacio de usuario . Este es un enfoque que tomé cuando la empresa para la que trabajaba no estaba interesada en exponer los detalles de nuestra FPGA al mundo. Todas las decisiones y la configuración del registro fueron decididas en el espacio del usuario y el lado del núcleo del controlador acaba de cargar valores en IRQ. Con el diseño cuidadoso puede administrar cualquier problema de tiempo real que pueda tener y tener una buena separación limpia entre su controlador cerrado y el kernel. I creo que esto es más fácil con núcleos más nuevos con soporte para espacio de usuario controladores aunque no creo que admitan DMA correctamente todavía (tuve que codificar un espacio de usuario módulo de kernel DMA para admitir DMA directamente entre el chipset y el espacio de usuario)

Sin embargo (de nuevo) realmente recomendaría que consideras lo que está tratando de proteger tu . Los controladores cerrados pueden estar bien para las aplicaciones integradas donde tiene un control estricto sobre la versión del kernel y el hardware. Pero si este controlador se está considerando para algo más genérico (es decir vendiendo hardware, las personas se conectarán a sus propios sistemas) y luego cerró , los controladores de origen solo probarán ser una fuente de dolor constante y dolores de cabeza por mantenimiento.

Answer 4

Algunos desarrolladores de kernel clave (pero no el propio Linus) opinan que cualquier módulo no GPL es una violación de la licencia del kernel.

Cuando algunos desarrolladores arrancaron el controlador de Belkin del enrutador Linksys, lo diseñaron de forma inversa y publicaron el resultado, Belkin no pudo detenerlos debido a la contrademanda de presentar esta interpretación de licencia ante el tribunal como defensa.

Answer 5

Innumerables otros controladores han utilizado una "cuña" de código abierto para unir un archivo de objeto de código cerrado con el kernel de código abierto. Esto es considerado por la mayoría de los desarrolladores de kernel como una violación, al menos en espíritu, de la GPL.

En mi opinión, depende de si distribuye el software. Si está ejecutando esto puramente en software como servicio, eso debería estar permitido. Si está distribuyendo un dispositivo incorporado o un producto en caja, es un no-no.

Mueve la funcionalidad que necesites del kernel, o abre los componentes de código fuente de tu kernel. Eso es lo que hacen los demás (honestos), y generalmente no es tan complicado, porque cualquiera que tenga una cantidad significativa de "propiedad intelectual" en el kernel-space, o tiene un mal modelo comercial o un equipo de ingeniería incompetente.

* lo anterior es mi opinión *