Barrapunto

Hace tiempo se discutió este tema en la lista del kernel [lkml.org] y tu comentario me recuerda a un argumento de Linus acerca del enlazado y la interdependencia.

La idea era que ld empaqueta código de varias fuentes, con distintos titulares de los derechos, en un solo fichero... Y esto es exactamente lo mismo que hace mkisofs (o ar). La ley evidentemente no puede depender de si el fichero resultante se llama *.exe o se llama *.iso y nadie -- imagino que tú tampoco -- consideraría que una iso es obra derivada del software GPL que contiene. Incluso si quitando las partes GPL esa iso dejase de ser arrancable.

El punto de vista de Linus realmente es similar al de la FSF pero llega por un camino distinto a la misma conclusión. No es abogado, creo que nadie en el hilo de LKML lo es, pero hay bastantes argumentos tanto a favor como en contra por si te interesa.

El problema aquí, vuelvo a repetir, es que la GPL dice "obras derivadas de acuerdo a la ley" pero la ley no dice lo que ellos quieren que diga -- más bien lo contrario -- y eso genera incertidumbre.

En la GPLv3 han omitido las referencias a obras derivadas y a la ley del copyright.

La única diferencia es que en vez de ser enlazados con ld y sus símbolos fijos y resueltos cuando se crea la imagen del proceso en memoria, es que todo eso se debe hacer a mano usando dlopen() en Linux o a LoadLibrary() en Windows y obteniendo referencias a los símbolos después.

Evidentemente los símbolos del plugin no aparecerán en los índices que genera ld porque ld no tiene conocimiento de ellos, si es a eso a lo que te refieres.

Desde el punto de la FSF, además, los plugins se tratan exactamente igual que las bibliotecas [gnu.org]. Por cierto en el faq la propia FSF te da otra pista más para saltarte la GPL: haz un pequeño wrapper ejecutable y llama al código GPL con fork/exec :-)

Plugins, componentes outproc o rpc. Conceptualmente es todo igual/a la licencia le trae sin cuidado.