¿Puedo vincularme a una biblioteca GPL desde una aplicación de código cerrado?


34

De acuerdo, antes de que todos griten sobre preguntas duplicadas, sí, ya he visto varias preguntas como esta aquí. Pero ninguno responde la pregunta.

Si enlazo con una biblioteca GPL-ed sin modificar esa biblioteca, ¿necesito liberar mi código fuente?

Según esta pregunta , ¡la respuesta es sí!

Pero esta respuesta no es satisfactoria para mí. La respuesta básicamente dice que no puedo usar el código GPL de ninguna manera sin hacer que mi código sea de código abierto.

Pero si lo anterior es cierto, eso indicaría que ninguna persona u organización podría lanzar ningún software propietario en Linux. Lo cual debe estar mal. Simplemente porque para que cualquier aplicación pueda hacer algo útil, abrir archivos, escribir en la consola, crear conexiones TCP, la aplicación debe estar vinculada a libcGPL.

Entonces, mi pregunta es la siguiente: si la GPL establece, como dicen todas las respuestas anteriores en el sitio, que un programa que se vincula a otro programa GPL debe ser la misma GPL, ¿cómo es posible crear / liberar / vender cualquier aplicación propietaria? en absoluto lo que se ejecuta en Linux? Como, como describí anteriormente, esa aplicación debe gustarle al código GPL solo para ejecutarse en Linux.

Un ejemplo más práctico dice que enlace a una biblioteca compartida que está editada con GPL en una aplicación que no es GPL, ¿obligaría eso a que la aplicación que no sea GPL se convierta en GPL? Más específicamente, si uso una biblioteca GPL sin modificarla y luego la distribuyo como .soo .dll, ¿requeriría que mi aplicación sea de código abierto?


9
Sigues haciendo la misma pregunta con la esperanza de una respuesta diferente. No puede usar GPL en software no compatible con GPL. Muy simple.
Andrew T Finnell

1
¿Él realmente? Caray. La respuesta es simple; ¿Por qué no te pones en contacto con los autores del programa GPL y les preguntas si les importa? Si dicen que está bien, ¡eso es grandioso! Si se oponen, tratar de armarlos con detalles legales te hará muy impopular, no importa cuán "correcto" te sientas.
James

3
@ James: Si eligieron GPL, es bastante fuerte declaración que hacen la mente. Las personas que no les importa elegir MIT o BSD o LGPL en primer lugar. Es muy raro ver una biblioteca bajo la GPL completa. Cuando lo haga, puede estar casi seguro de que fue intencional.
Jan Hudec

@ Jan Quizás, depende de la aplicación y del uso previsto de john-charles. Pero creo que es extraño cómo JC está abordando esto. ¿Jc solo está tratando de obtener la respuesta que quiere? Hay muchas preguntas en este sitio que podrían resolverse con un "solo habla con ellos, por el amor de Dios". :-)
James

@ JanHudec: Estoy de acuerdo. He argumentado que publicaremos parte de la propiedad intelectual de nuestra empresa en forma de biblioteca GPL, ya que eso sería esencialmente inútil para nuestros competidores y aún sería muy útil para nuestra comunidad.
MSalters

Respuestas:


33

Si se vincula a una biblioteca GPL, entonces ha creado un trabajo derivado y su código debe ser GPL; esto es diferente al código L GPL que específicamente permite la vinculación dinámica de código con licencia diferente. Las bibliotecas del sistema, incluida libc, son todas LGPL.

También hay una exención especial para los encabezados del kernel de Linux y libgcc (la biblioteca a la que el compilador llama implícitamente).


19
No libc es LGPL: puede vincularse a programas LGPL. También hay una exención general para las llamadas de kernel / system, por lo que no hay argumento sobre qué es una llamada de sistema vs biblioteca
Martin Beckett,

66
LGPL no es una licencia nueva, se lanzó por primera vez en 1991. libc siempre ha sido LGPL.
FigBug

44
@ john-charles: por eso LGPL se inventó en 1991 con gplv2. A medida que Linux (y otros núcleos FOSS) se hicieron populares, y es por eso que originalmente se llamaba Library-GPL, existía el temor de que cada proveedor de compiladores produjera una gran cantidad de libc si las aplicaciones comerciales no podían usar gcc.
Martin Beckett

1
@MartinBeckett Esta es la opinión de la FSF (no se puede vincular al código GPLd si no licencia el suyo bajo GPL), sin embargo, no es indiscutible. No ha habido ninguna demanda importante (que yo sepa, si me equivoco, corríjame) para confirmar la opinión de la FSF sobre el enlace.
K.Steff

2
@ john-charles: sí, todas las leyes comunes se prueban en los tribunales, pero existe mucha jurisprudencia sobre derechos de autor. Si afirmo que mi copia no modificada de un DVD de Batman no es un trabajo derivado y puedo vender tantos como quiera, ¡es poco probable que la MPAA esté de acuerdo! El copyleft GNU usos de derechos de autor para hacer cumplir un acuerdo de licencia de una manera muy inteligente - una de las razones por las que nunca se ha probado en los tribunales es que todo el mundo siempre se ha asentado
Martin Beckett

7

En el caso general, tiene razón en que no puede vincular a una biblioteca GPL, distribuir su código y luego no liberar su código como GPL.

Sin embargo, existe la Excepción de la biblioteca del sistema, que es la forma en que las personas se vinculan contra las bibliotecas de Linux y aún lanzan su producto bajo licencias que no son GPL.

Otra excepción es cuando las dos licencias son compatibles entre sí. Consulte la página de licencia compatible con FSF para obtener más información.

Finalmente, los autores de la biblioteca GPL'd pueden crear excepciones específicas, como para uso no comercial o de aficionados.

Desafortunadamente, hay demasiadas potencialidades para tener una regla dura y rápida. Sin más detalles en su pregunta, su respuesta es "probablemente no pueda, pero tal vez pueda".


1
El SLE también responde a la pregunta de que un programa es un trabajo derivado del compilador, ya que contiene un analizador generado por el compilador
Martin Beckett

3
No, SLE permite desarrollar código GPL utilizando una cadena de herramientas no libre y tiempo de ejecución estándar, por ejemplo, Visual Studio. No permite vincular aplicaciones no libres con la biblioteca GPL, nunca.
Jan Hudec

1
La salida de un programa GPL no está cubierta por la GPL. Consulte gnu.org/licenses/gpl-faq.html#GPLOutput
Maximus Minimus el

-1

La respuesta corta es que nadie lo sabe realmente. (Esta discusión es sobre GPL, no LGPL).

La GPL tiene un lenguaje vago sobre "Obras derivadas", que diferentes personas interpretan de diferentes maneras. El consenso parece ser que el enlace estático viola, pero las llamadas a través de interrupciones del sistema (por ejemplo, al kernel de Linux) no lo hacen. Esto último se basa principalmente en el hecho de que compañías como Oracle se envían en Linux y no han sido demandadas, no está claro en la licencia.

La vinculación dinámica no está clara, probablemente 70/30 dicen que viola. Llamar a un programa usando tuberías o llamadas a procedimientos remotos, probablemente 30/70 no viola, aunque esto sea esencialmente lo mismo. Llamar a través de COM, o usar un Java Jar, no está completamente claro.

Básicamente, si hay alguna duda, y no le gustan los abogados, manténgase alejado de GPL.


1
GPL no es realmente tan vago, y hay una jurisprudencia bien discutida sobre la cuestión de qué es y qué no es un trabajo derivado. La diferencia entre la interfaz syscall de Linux y libc es que la primera es necesaria para hacer que el software funcione (que se ha afirmado como una excepción a los derechos de autor) mientras que la segunda no (puede implementar la suya propia). No tiene nada que ver con cómo se invocan las operaciones, lo que no tiene relevancia legal. ANAL, esto no es asesoramiento legal.
Julio

"70/30 dice que viola" y "30/70 no viola": ¿es intencional que la proporción de violar / no violar sea la misma? "a pesar de que esto es esencialmente lo mismo" sugiere que estaba destinado a ser diferente.
Mateusz Konieczny
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.