Uso del módulo Python en la licencia LGPL en un producto comercial
licencia python (4)
Prueba simple: ¿puede el usuario cambiar la parte LGPL por su propia versión?
Está escrito en la licencia LGPL que puedo usar código vinculado no modificado en un producto comercial y cerrado sin cambiar la licencia del producto a LGPL. ¿Qué pasa con el módulo Python (* .py) en la licencia LGPL en un producto comercial? ¿Se trata como código vinculado?
Si entiendo su pregunta correctamente, está preguntando si puede usar una biblioteca LGPL dentro de un producto comercial de código cerrado. Si bien no pude encontrar nada que abordara esta situación específica, todo sugiere que no debería haber problemas. Primero, hay un artículo sobre el uso de LGPL en Java . Esta es la cita relevante del artículo:
La posición de la FSF se ha mantenido constante en todas partes: la LGPL funciona según lo previsto con todos los lenguajes de programación conocidos, incluido Java. Las aplicaciones que enlazan con las bibliotecas LGPL no necesitan ser lanzadas bajo la LGPL. Las aplicaciones solo deben cumplir con los requisitos de la sección 6 de la LGPL: permitir que las nuevas versiones de la biblioteca se vinculen con la aplicación; y permitir a la ingeniería inversa depurar esto.
Otra cita adicional del artículo que puede ser relevante:
Cuando distribuye la biblioteca con su aplicación (o solo), debe incluir el código fuente de la biblioteca. Pero si su aplicación requiere que los usuarios obtengan la biblioteca por su cuenta, no necesita proporcionar el código fuente de la biblioteca.
Y una última cita:
La LGPL no contiene disposiciones especiales para la herencia, ya que no son necesarias. La herencia crea trabajos derivados de la misma manera que los enlaces tradicionales, y la LGPL permite este tipo de trabajo derivado de la misma manera que permite las llamadas de función ordinarias.
Si bien es cierto que este caso en particular no ha sido juzgado en un tribunal de justicia (al menos que yo sepa), no me quedaría despierto por la noche preocupado por ello. Incluso si la LGPL no es exactamente clara en este tema, la FSF ha publicado una guía de que la LGPL funciona como se espera para todos los lenguajes de programación. En general, si un contrato es ambiguo, entonces se resuelve a favor del demandado (esto es una simplificación excesiva, pero puede encontrar más detalles here ). Si estás realmente nervioso, consideraría contactarme con la Free Software Foundation .
En resumen, parece que puede utilizar el software LGPL con Python si distribuye el código fuente de la biblioteca LGPL con su aplicación (junto con sus modificaciones) o si hace que el usuario final instale esta biblioteca por separado.
Una biblioteca de Python importada por su programa ciertamente no está vinculada de forma estática, la forma compilada de ella (o la forma de origen) no está incluida en los archivos .py (co) creados por usted. Por lo tanto, está al menos tan seguro importando módulos L / GPL como los controladores de dispositivo nvidia para linux están vinculados dinámicamente contra el núcleo. Tenga en cuenta que no debe empaquetar software libre con software no libre, por lo que si le proporciona a su biblioteca una L / GPL en el mismo archivo tar / zip o CD, es posible que tenga problemas. Esto también se aplica si está subclasificando una clase fuera de un módulo, ya que no está incluyendo el otro módulo directamente. (El usuario puede intercambiar el módulo L / GPLed por uno funcionalmente equivalente y su código no lo notará ni le importará). La única área gris es si modifica el contenido del módulo en tiempo de ejecución y luego distribuye el módulo modificado, momento en el que deberá distribuir la fuente que produjo el módulo modificado. (Tenga en cuenta que un .pyc, incluso si incluye un submódulo.a = 5 líneas o similar, no ha cambiado el submódulo, tendría que decapar o guardar el estado de ejecución del submódulo y luego distribuir el Estado guardado para que cuente como cambio del submódulo).
Creo que esta es la única forma sensata de verlo, o de lo contrario, un programa de hoja de cálculo de OpenOffice combinado con macros OO tendría que ser compatible con LGPL porque OpenOffice en sí es LGPL. Los módulos de Python que importan un módulo están usando ese módulo, no creando un trabajo derivado de él.
No creo que el problema (si la importación de un módulo de Python cuenta como "vinculación" con él, para los fines legales de la GPL) aún no se haya resuelto. No creo que se resuelva hasta que un caso judicial lo active (y posiblemente ni siquiera entonces). La GPL está (lamentablemente) escrita básicamente en términos de C y sus herramientas asociadas, por lo que solo es obvio cómo aplicarlo si el lenguaje y las herramientas utilizadas para el software tienen propiedades similares a las asociadas con C.
Sin embargo, la importación de un módulo Python es seguramente una situación al menos tan permisiva como la vinculación dinámica a una biblioteca compartida; el documento con derechos de autor (archivo de origen) con el que se vincula cuando escribe import foo no se determina hasta que el programa se ejecuta realmente, y se puede cambiar de forma trivial después de que el usuario final haya producido los documentos. o incluso simplemente cambiando PYTHONPATH.
Personalmente, encuentro que los argumentos anteriores llevan claramente a la conclusión de que agregar import foo a su propio archivo de origen no "copia ni adapta todo o parte de [foo.py] de una manera que requiera permiso de copyright" en absoluto , y por lo tanto la GPL no se aplica realmente si nunca modificas foo.py. (Cita de la versión 3 de GNU GPL , debajo de "0 Definiciones")
(Técnicamente, creo que este argumento se aplicaría a la vinculación dinámica a una biblioteca de C compartida también, excepto que para hacerlo normalmente debe #include <foo.h> , lo que significa que su programa compilado es un trabajo basado en foo. Incluso si argumenta que no es un trabajo basado en la biblioteca compartida. Aunque su código fuente no tendría ningún problema con la interpretación de la GPL con esta interpretación, de manera bastante interesante, entonces, si quisiera insistir, podría distribuir su código fuente con una licencia propietaria e instrucciones para que el usuario final se compile por sí mismo. Pero estoy divagando.)
No es que los argumentos de sentido común coincidan necesariamente con lo que decidiría un tribunal. Si trata a import foo.py como "enlace dinámico" con foo.py para los fines de la (L) GPL, no veo cómo podría fallar: nadie lo demandará por adherirse a las condiciones de licencia que técnicamente no cumplió. t tiene que