¿Hay una laguna en la GPL que permita que el software propietario se vincule con las bibliotecas GPL?

Examinemos un escenario hipotético:

La empresa X escribe un programa propietario (A) que se vincula dinámicamente con una biblioteca propietaria (B). La empresa Y quiere usar una biblioteca de reemplazo (C) con licencia bajo la GPL, y escribe una biblioteca de envoltura (D) que se vincula dinámicamente a A y C y traduce las llamadas API utilizadas por A a las llamadas API utilizadas por C.

Como D está destinado a usarse con C, y usa las llamadas API de C, es un trabajo derivado de C y, por lo tanto, debe distribuirse bajo los términos de la GPL *. Como resultado, el trabajo combinado de A y D también debe distribuirse bajo los términos de la GPL, lo cual es imposible dado que la Compañía Y no posee el código fuente para A. Dicho eso, siempre y cuando la Compañía Y distribuya D por sí misma , no hay ningún problema. Sin embargo, independientemente de las acciones de la Compañía Y, la Compañía X no viola la GPL al distribuir A, incluso sin B. La mera existencia de D no significa que A sea repentinamente un trabajo derivado de C (a través de D) que debe tener licencia bajo el GPL también.

Ahora bien, esta es la laguna: no hay nada que impida a la Compañía X escribir su propia versión de D, distribuirla por separado de A y decirle a los usuarios finales que usen D en lugar de B cuando ejecutan A. Parece que una compañía es capaz de diseñar un programa propietario para usar una biblioteca GPL sin violar la GPL, siempre que se use un módulo contenedor para aislar el programa propietario de la biblioteca GPL y ese módulo se distribuya por separado.

¿Estoy en lo correcto en mi razonamiento? ¿Es esta una laguna real en la GPL?

* D también es un trabajo derivado de A, pero a los efectos de este escenario, la Compañía X autorizó explícitamente la creación de D y permitió que se licenciara bajo la GPL.

IANAL, pero aquí está mi opinión sobre lo que está permitido dentro de los límites de GPL:

• distribuir el trabajo combinado "A - B" en público: bien, se puede hacer bajo cualquier licencia de propiedad

• cree una envoltura lib D para C por Y: bien, esto no implica que A tenga que estar bajo GPL

• use el producto combinado "A - D - C" internamente por Y: también está bien, GPL no requiere abrir el código fuente A mientras la combinación no se distribuya al público

• distribuya el trabajo combinado "A - D - C" en público: esto requerirá que A sea de código abierto y esté bajo GPL (y no importa si X o Y distribuyeron esta combinación; además, si Y quiere hacerlo esto, requerirían una licencia de distribución para A de X, por supuesto)

La pregunta interesante ahora es: ¿ pueden distribuirse D&C por separado como código abierto bajo GPL, A&B (o simplemente A sin B) pueden distribuirse bajo una licencia patentada, y el usuario final reemplaza B por D&C por sí mismo?

Aquí, el usuario final realiza la modificación final a "AB" que hace que A dependa de las bibliotecas D y C, después de la distribución . Por lo tanto, se podría argumentar que la modificación final solo la realiza internamente el usuario final. Y parece que esto es posible sin violar la GPL, y lo que obtienes es una combinación funcional de "AC&D" donde A está bajo licencia de propiedad y C&D bajo GPL.

Por supuesto, un abogado o un juez pueden tener una opinión diferente al respecto. Para obtener una respuesta final, creo que debes esperar hasta que alguien lo pruebe y otro lo demande.

Supongo que para la mayoría de los sistemas, será difícil crear una constelación de este tipo sin diseñar "A" desde el principio de una manera que funcione sin problemas con B o C. Y en este caso, uno podría sospechar que A fue derivado de alguna manera de C.

EDITAR: pensando un poco en esto, me vino a la mente una situación similar: escribir y distribuir complementos con licencia GPL para aplicaciones de código cerrado. Tomemos por ejemplo, Photoshop. No creo que alguien trate seriamente de exigir a Adobe que use Photoshop de código abierto solo porque existen algunos complementos de GPL de terceros. Aquí, ni siquiera se necesita un "wrapper lib", ya que existe una interfaz bien definida. Sin embargo, ¿cambiaría la situación si Photoshop incorporara algunas de sus funciones centrales de un complemento de terceros GPL? Creo que para tal caso puede ser realmente difícil decidir dónde trazar la línea, en cuyo punto el producto de código cerrado es un trabajo "basado en" la biblioteca GPL.

EDIT2: hay libs de doble licencia disponibles, con una licencia GPL para uso no comercial y una licencia patentada para uso comercial como esta, por ejemplo. Por lo tanto, su "escapatoria" significaría desarrollar un producto basado en dicha biblioteca (utilizando la versión comercial, por lo que GPL no se aplica a su producto), entregar su producto como fuente cerrada sin la biblioteca al público y dejar que el el usuario obtiene e instala la versión GPL por sí mismo. Para tal caso, supongo que el vendedor de la biblioteca tendrá una buena oportunidad de demandarlo exitosamente por violación de licencia (si no paga por su biblioteca, por supuesto). ¿Vale la pena la molestia? Probablemente no. Especialmente en el ejemplo al que me vinculé, también tendrías que comprar la lib, ya que el precio no depende de la frecuencia con la que vendes tu producto, sino solo de cuántos desarrolladores están usando la lib durante el desarrollo.

Finalmente, debido a esos riesgos legales, si tengo la intención de usar bibliotecas de código abierto dentro de un producto de código cerrado, evitaría las bibliotecas GPL si es posible, y no trataría de hacer uso de este "vacío legal". LGPL o GPL con excepción de enlace es mucho más seguro, o cualquier tipo de licencia de sistema operativo no viral.

Un ejemplo práctico son los controladores de gráficos patentados para Linux que el usuario final debe instalar ellos mismos. Es importante para el creador del controlador propietario, si el usuario final distribuye el trabajo combinado, eso crea una obligación legal para el usuario final (que posiblemente no puede cumplir) pero no para el creador del controlador.

Otra respuesta dice "dado que el programa depende de la biblioteca, sigue siendo un trabajo derivado", pero si el programa no funciona realmente porque la biblioteca no está allí, entonces no es derivado.

Pero al final, si confía en "lagunas", entonces debe considerar que su enfoque puede no ser el correcto en primer lugar.

La vinculación define una derivada por la GPL. Esta situación específica es para lo que se diseñó la LGPL: dónde desea lanzar la biblioteca como GPL pero define la vinculación como el límite explícito de la licencia aplicada, o alternativamente, dónde desea vincular con algún código GPL pero requiere que sea el suyo el trabajo se publicará bajo una licencia que no sea GPL.

En el caso en que el usuario final vaya a hacer la vinculación (construya su propio código a partir de fuentes que no sean GPL que puedan vincularse con una biblioteca GPL), el usuario final no ha creado efectivamente una versión GPL de lo que sea el producto final, ya que no se le permite cambiar la licencia de la parte del proyecto que no pertenece a la GPL porque no es el propietario del mismo. Esto generalmente impide la distribución por parte del usuario final en cualquier forma, pero no prohibiría su uso.

Dicho esto, si un proyecto requiere que se construya desde la fuente y solo se distribuya de esa manera, no tiene importancia la licencia de la biblioteca vinculada, ya que esto está completamente fuera del alcance de los desarrolladores que no pertenecen a GPL. Es decir, ¿cómo puede saber que su distribución de solo fuente se construirá en gcc contra glibc VS construida en un compilador de IBM contra su libc a menos que especifique esto bajo sus propios términos de licencia? Esto rápidamente se encuentra con el uso justo y las prohibiciones contra condiciones legales inaplicables (no es que la fantasía no se haya convertido en ley en varias ocasiones recientemente).

No soy abogado, pero por lo que puedo decir, no es correcto, ya que el programa depende de la biblioteca; sigue siendo un trabajo derivativo. De la misma manera que un sequal es un trabajo derivativo. Como mínimo, se basa en las API definidas en la biblioteca.