Estoy planeando desarrollar un software comercial usando un software LGPL.
En el software LGPL que estoy usando algunas funciones en una clase no están completamente implementadas. Quiero modificar el código LGPL para que la clase y las funciones no implementadas se hagan visibles fuera de la dll agregando dllexport enfrente de la clase y agregando palabras clave virtuales enfrente de la función.
Luego planeo implementar esas funciones en mi software propietario. Estoy listo para distribuir el código LGPL modificado, pero no el software propietario que implementa las funciones de la manera que quiero.
¿Eso viola los términos y condiciones de LGPL?
Respuestas:
Esta es una pregunta compleja, pero creo que lo que propones no está permitido.
Usted está sugiriendo ganchos añadir a la biblioteca para que sea más fácil para que usted pueda subclase la biblioteca y, por tanto, por lo menos. para evitar el espíritu de la LGPL.
El problema es que si subclasifica una clase que está sujeta a la licencia LGPL en su propio código, entonces su trabajo se convierte en un trabajo basado en la biblioteca , en lugar de un trabajo que utiliza la biblioteca, lo que significa que su código es un derivado trabajo cubierto en la sección 2 ( LGPL v2.1 ) en lugar de uno cubierto en la sección 6 ( LGPL v2.1 ). Es decir, queda sujeto a la LGPL !
Creo que Stephen Colebourne ofrece un buen resumen sobre javalobby.
No soy un gran admirador de hablar con las sugerencias de su abogado , pero en este caso creo que valdría la pena hacerlo si planea continuar con esto, de lo contrario podría recibir una carta desagradable del Software Libre Equipo legal de la fundación .
Alternativamente, puede preguntarle directamente a la FSF . Desde su página de contacto :
Por cierto, en la pregunta relacionada Reflexión y LGPL , gbjbaanb responde con la perspectiva LGPL 3.0 .
fuente
Norma No soy un abogado exención de responsabilidad.
LGPL requiere que las modificaciones al código fuente de la biblioteca se distribuyan a cualquiera que haya usado su código. No , no requiere que el código, que utiliza la biblioteca, sea y publicado bajo la misma licencia de código abierto.
Wikipedia para una descripción más detallada, pero no jurídica, de LGPL, incluida una sección sobre herencia colectiva .
fuente
"Quiero modificar el código LGPL ..." esto dice lo suficiente que debe liberar cualquiera de ese código modificado. Luego, extender si el código modificado es o no un trabajo derivado queda en disputa y, de ser así, queda sujeto a la LGPL.
Lo que parece que estás tratando de hacer es evitar la LGPL, que en este caso con estas técnicas no puedes.
Pero si lo que intenta hacer es evitar la LGPL, me pondría en contacto con la FSF según lo recomendado por Mark Booth .
fuente
work based onporque están haciendo cambios a LGPL para exponer el código privado anterior.Mi suposición: (pero IANAL) debe liberar como código abierto la biblioteca modificada como código LGPL y luego colocarla en un programa comercial. Eso funcionaria. Efectivamente, terminaría teniendo una bifurcación de código abierto de la biblioteca y luego venderá un front-end para ello.
Pero como muchos otros dijeron con razón, pregúntele a la FSF : es un escenario patológico intrigante que tiene allí; podrían preguntarse tanto como usted si es aplicable o no. (o al menos molestarse lo suficiente como para publicar una entrada de preguntas frecuentes sobre el tema)
fuente
https://www.gnu.org/licenses/lgpl-java.html
En resumen, no hay ningún problema con la herencia siempre que no cambie el código de la biblioteca en sí, pero incluso si lo cambia, debe liberar solo el código modificado de la biblioteca, no el código de la aplicación.
fuente