¿Cómo se aplica la regla de vinculación estática frente a dinámica de GPL a los idiomas interpretados?


19

Según tengo entendido, la GPL prohíbe la vinculación estática del código no GPL al código GPL, pero permite la vinculación dinámica del código no GPL al código GPL. Entonces, ¿qué sucede cuando el código en cuestión no está vinculado porque el código está escrito en un lenguaje interpretado (por ejemplo, Perl)?

¡Sería demasiado fácil explotar la regla si se considerara un enlace dinámico, pero por otro lado, también sería imposible hacer referencia legal al código GPL de un código que no es GPL si se considera estático! Los lenguajes compilados al menos tienen una distinción entre enlaces estáticos y dinámicos, pero cuando todos los "enlaces" solo ejecutan scripts, ¡es imposible saber cuál es la intención sin una licencia explícita!

¿O es que mi comprensión de este problema es incorrecta, haciendo que la pregunta sea discutible? También he oído hablar de una "excepción de classpath" que implica la vinculación dinámica; ¿No es eso parte de la GPL, sino algo que se le puede agregar, por lo que el enlace dinámico solo se permite cuando la licencia incluye esta excepción?



2
@delnan lgpl! = gpl
Johann

Respuestas:


16

En cuanto a la pregunta específica sobre los idiomas interpretados, las preguntas frecuentes de GPL son muy claras :

El programa interpretado, para el intérprete, son solo datos; una licencia de software libre como la GPL, basada en la ley de derechos de autor, no puede limitar en qué datos utiliza el intérprete. Puede ejecutarlo en cualquier dato (programa interpretado), de la manera que desee, y no hay requisitos para otorgar licencias de esos datos a nadie.

En cuanto a la pregunta genérica sobre la vinculación dinámica vs estática. En primer lugar, la opinión de FSF y Stallman es que no importa si el enlace es estático o dinámico, GPL infecta de cualquier manera. De FSF GPL FAQ:

Si el programa vincula dinámicamente complementos , y realizan llamadas de función entre sí y comparten estructuras de datos, creemos que forman un solo programa, que debe tratarse como una extensión tanto del programa principal como de los complementos. Esto significa que la combinación del complemento cubierto por la GPL con el programa principal no libre violaría la GPL.

y

Vincular [nombre de su programa] estática o dinámicamente con otros módulos es hacer un trabajo combinado basado en [nombre de su programa]. Por lo tanto, los términos y condiciones de la Licencia Pública General de GNU cubren toda la combinación

Sin embargo, esto es cuestionable desde el punto de vista legal. En el único caso que realmente acudió a los tribunales con respecto a la vinculación dinámica ( Galoob v. Nintendo) , el Tribunal de Apelaciones dictaminó que el trabajo derivado "debe incorporar una parte del trabajo protegido por derechos de autor de alguna forma" . Cuál no es el caso con la vinculación dinámica.

De todos modos, independientemente de si la vinculación dinámica realmente infecta o no, hay una solución alternativa. Nvidia lo utiliza, por ejemplo, para proporcionar controladores binarios para Linux. Usted crea (L) contenedor GPL, pero como autor puede agregar una excepción especial para vincular con código cerrado específico. Vide FSF GPL Preguntas frecuentes .


Una de las características de un trabajo derivado es que no es posible separar limpiamente el trabajo original del titular de los derechos de autor. Si Bob's Foo()está vinculado estáticamente para llamar a Joe's Bar(), ¿a qué titular de derechos de autor debe CALLatribuirse la instrucción entre ellos? Dicha interacción sería suficiente para constituir un "trabajo derivado". Sin embargo, si el trabajo de Joe permanece completamente dentro de un archivo y el de Bob permanece completamente dentro de otro, la mera aparición de esos archivos en diferentes directorios en el mismo disco constituye agregación, no derivación.
supercat

2
@thepaul: ya existe una precedencia legal que establece que al menos una parte del trabajo protegido por derechos de autor debe incluirse en un trabajo para constituir un trabajo derivado. Las creencias de Stallman a menudo tienen muy poca base en la ley real real.
vartec

1
@thepaul: por un lado tienes práctica legal utilizada por una compañía de 9 mil millones de dólares, en otros reclamos de un tipo al que le gusta usar sombrero de papel de aluminio. Afirma que lo último es más confiable y tiene todo el derecho de creerlo.
vartec

1
Usted cita la parte incorrecta de las preguntas frecuentes de GPL es muy clara . ¿De qué parte de la cita se trata? Si se publica un intérprete de lenguaje de programación bajo la GPL, ¿eso significa que los programas escritos para ser interpretados por él deben estar bajo licencias compatibles con la GPL? ! De ahí el intérprete [con licencia GPL] . La parte relevante son los últimos 2 párrafos: [...] Otro caso similar y muy común es proporcionar a las bibliotecas el intérprete que ellos mismos interpretan. Por ejemplo, Perl viene con muchos módulos Perl [...]
Chris Wesseling

1
«El programa interpretado, para el intérprete, son solo datos; una licencia de software libre como la GPL, basada en la ley de derechos de autor, no puede limitar en qué datos utiliza el intérprete. Puede ejecutarlo en cualquier dato (programa interpretado), de la forma que desee, y no hay requisitos para otorgar licencias de esos datos a nadie ». Se trata de ejecutar programas en cualquier licencia, incluso de un intérprete de GPL, ¿verdad? Que no cubre el tema del uso de un complemento no libre en un programa GPL en un lenguaje interpretado.
tuxayo

4

Nota: esta es una pregunta legal. Programmers.SE no es un foro legal, es un foro de programación. Si bien las personas aquí saben bastante sobre programación, no saben nada sobre la ley. Si desea hacer una pregunta legal, debe hacerlo en un foro legal, donde hay personas que realmente saben algo sobre el tema.


La GPL no dice nada sobre enlaces estáticos o dinámicos. Ni siquiera dice nada sobre vinculación en absoluto . Cada abogado o juez con el que hablé dice que el tema de la vinculación estática y dinámica es completamente irrelevante.

El derecho de autor es acerca de la creatividad. La vinculación estática frente a dinámica es un detalle técnico de implementación. Si algo está vinculado estática o dinámicamente no es un acto creativo, no puede cambiar el estado de copyright de una obra.

En su pregunta, habla de "idiomas interpretados". Pero ese término no tiene sentido: no existe un lenguaje interpretado. Un lenguaje es un conjunto abstracto de reglas y restricciones matemáticas. Un idioma no se interpreta ni se compila. Un idioma simplemente es . El término "lenguaje interpretado" no solo es incorrecto , no es sensitivo . Si el inglés fuera un idioma escrito, sería un error de tipo.

La interpretación y la compilación son rasgos del intérprete o compilador (¡duh!), No del lenguaje. Cada idioma puede implementarse con un intérprete, y cada idioma puede implementarse con un compilador. La mayoría de los idiomas tienen ambos. La implementación del lenguaje más moderno incluso combina ambos en un solo motor de ejecución.

La implementación de Rubinius Ruby, por ejemplo, contiene un compilador estático anticipado que compila el código Ruby en el código de bytes Rubinius, un intérprete que interpreta el código de bytes Rubinius y un compilador dinámico justo a tiempo que compila el código de bytes Rubinius en LLVM IR, que la infraestructura LLVM a su vez compila en código máquina nativo. La implementación de Ruby de MacRuby no contiene un intérprete, compila el código de Ruby directamente a LLVM IR y luego al código de máquina nativo.

Por otro lado, hay intérpretes para C o C ++.

Todo esto son solo detalles técnicos. Es completamente irrelevante para los derechos de autor.

Simplemente no tiene sentido que si alguien viola o no los derechos de autor de otra persona depende de si una tercera persona elige ejecutar el programa con un intérprete o compilarlo primero.

La pregunta es si un trabajo se deriva o no de otro trabajo. Se puede vincular dinámicamente y seguir derivando, y se puede vincular estáticamente y no derivar en absoluto.


¿Qué pasa con los lenguajes interpretados de "código intermedio"? Uno de los principios detrás de la GPL es que cualquiera debería poder adaptar el programa a cualquier máquina razonable que tenga las mismas herramientas de lenguaje disponibles que el original. Si alguien libera código fuente para un intérprete de código intermedio, junto con un montón de código de forma intermedia que puede ejecutar, ¿cuáles serían las reglas para liberar información relacionada con ese blob de código intermedio? A diferencia de los ejecutables compilados, que son específicos de la máquina, el blob de código intermedio sería totalmente portátil.
supercat

Lo siento; ¡Iba a preguntar en stackoverflow.com, y sugirió que pregunte aquí cuando use la etiqueta "gpl"! ¿Este tipo de discusión también está prohibida aquí? ejecutivo ("abogado de killall -9"); : D
ekolis

Y sí, estoy de acuerdo en que no tiene sentido que un detalle de implementación no tenga ningún efecto sobre el estado legal de la reutilización; ¡Solo pensé que había tal distinción y estaba pidiendo una aclaración!
ekolis

2
@ekolis: no está prohibido, per se. Es solo que no es una buena idea hacer preguntas legales a las personas que no saben nada sobre cuestiones legales (como los programadores, por ejemplo), cuando hay personas que saben sobre cuestiones legales (también conocidos como abogados), puede preguntar en su lugar. No tengo nada en contra de los abogados, todo lo contrario. Pero no le pediría consejo a un algoritmo, y tampoco le pediría consejo a un programador.
Jörg W Mittag

IANAL: Puede ser un detalle técnico, pero aún hace una gran diferencia, porque cambia lo que se distribuye de una manera legalmente significativa. Con la vinculación estática, está creando un trabajo combinado que, de acuerdo con las reglas de la GPL, no puede distribuirse fuera de la GPL. Con la vinculación dinámica, también podría estar haciendo esto, por ejemplo, si empaqueta las bibliotecas con su software en un archivo ZIP. Pero con el enlace dinámico, puede distribuirlo sin las bibliotecas, y es 100% su trabajo, incluso si no funciona por sí solo. Y todavía puede, por supuesto, ofrecer las bibliotecas bajo GPL.
flarn2006

0

No tengo idea de cuánta verdad hay en esto, e IANAL, etc .; pero en mi interpretación, lo importante es si la biblioteca con la que se vincula está incluida de alguna forma en el "binario" (donde "binario", en el caso de los lenguajes de programación dinámicos, es solo el código fuente como se distribuye; esto es lo que hago de la definición de FSF de "binario" en este contexto).

Entonces, si hace referencia a las bibliotecas de su código sin incluirlas en su distribución, consideraría que esto es equivalente a "vinculación dinámica", mientras que si agrupa las bibliotecas con su producto, o copia y pega partes de la biblioteca en su propio código, se aplicaría el escenario de "enlace estático". Esto, al menos, está en el espíritu de la GPL: puede usar libremente (ejecutar, inspeccionar, hacer referencia) el software de la GPL sin restricciones, pero tan pronto como se derive de él (al vincular o copiar partes de él en su propio producto distribuible), se vuelve viral, y su software también debe ser GPL.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.