sirve - python historia
Complementos propietarios para programas GPL: ¿qué pasa con los idiomas interpretados? (3)
La distinción entre fork / exec y dynamic linking, además de ser algo artificial,
No creo que sea artificial en absoluto. Básicamente, están haciendo la división según el nivel de integración. Si el programa tiene "complementos" que son esencialmente fuego y se olvidan sin integración de nivel de API, entonces es poco probable que el trabajo resultante se considere un trabajo derivado. En términos generales, un complemento simplemente bifurcado / ejecutado se ajustaría a este criterio, aunque puede haber casos en los que no lo haga. Este caso se aplica especialmente si el código "complemento" también funcionaría independientemente de su código.
Si, por otro lado, el código depende en gran medida del trabajo de GPL, como las API de llamadas extensas o la estrecha integración de la estructura de datos, entonces es más probable que las cosas se consideren un trabajo derivado. Es decir, el "complemento" no puede existir solo sin el producto GPL, y un producto con este complemento instalado es esencialmente un trabajo derivado del producto GPL.
Entonces, para hacerlo un poco más claro, los mismos principios podrían aplicarse a su código interpretado. Si el código interpretado depende en gran medida de sus API (o viceversa), entonces se consideraría un trabajo derivado. Si solo se trata de un script que se ejecuta solo con muy poca integración, puede que no.
¿Eso tiene más sentido?
Estoy desarrollando una aplicación con licencia de GPL en Python y necesito saber si la GPL permite que mi programa use complementos propios. Esto es lo que la FSF tiene que decir sobre el tema:
Si un programa publicado bajo la licencia GPL utiliza complementos, ¿cuáles son los requisitos para las licencias de un complemento?
Depende de cómo el programa invoca sus complementos. Si el programa usa fork y exec para invocar plug-ins, los plug-ins son programas separados, por lo que la licencia del programa principal no exige nada.
Si el programa enlaza dinámicamente los complementos, y se hacen llamadas de función entre sí y comparten estructuras de datos, creemos que forman un único programa, que debe tratarse como una extensión tanto del programa principal como de los complementos. Esto significa que los complementos deben ser liberados bajo la GPL o una licencia de software libre compatible con GPL, y que los términos de la licencia GPL deben seguirse cuando se distribuyen dichos complementos.
Si el programa enlaza dinámicamente los complementos, pero la comunicación entre ellos se limita a invocar la función ''principal'' del complemento con algunas opciones y esperar a que vuelva, ese es un caso límite.
La distinción entre fork / exec y dynamic linking, además de ser algo artificial, no se traslada a los lenguajes interpretados: ¿qué pasa con un plugin Python / Perl / Ruby, que se carga mediante import o execfile ?
(Editar: Entiendo por qué la distinción entre fork / exec y dynamic linking, pero parece que alguien que quería cumplir con la GPL pero va en contra del "espíritu" --no-- podría usar fork / exec y comunicación entre procesos para hacer casi cualquier cosa).
La mejor solución sería agregar una excepción a mi licencia para permitir explícitamente el uso de complementos propios, pero no puedo hacerlo ya que estoy usando Qt / PyQt, que es GPL.
¿Cuánta información estás compartiendo entre los complementos y el programa principal? Si está haciendo algo más que simplemente ejecutarlos y esperar los resultados (al no compartir datos entre el programa y el complemento en el proceso), entonces es probable que se salga con la suya, de lo contrario probablemente tendrían que ser GPL '' re.
@Daniel
La distinción entre fork / exec y dynamic linking, además de ser algo artificial, no se traslada a los lenguajes interpretados: ¿qué pasa con un plugin Python / Perl / Ruby, que se carga mediante import o execfile?
No estoy seguro de que la distinción sea artificial. Después de una carga dinámica, el código del complemento comparte un contexto de ejecución con el código GPLed. Después de un fork / exec no lo hace.
En cualquier caso, supongo que la import hace que el nuevo código se ejecute en el mismo contexto de ejecución que el bit GPL, y debería tratarlo como el caso del enlace dinámico. ¿No?