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 libc
GPL.
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 .so
o .dll
, ¿requeriría que mi aplicación sea de código abierto?
Respuestas:
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).
fuente
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".
fuente
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.
fuente