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

15

Examinemos un escenario hipotético:

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

Dado que D está destinado a ser utilizado con C y usa las llamadas a la API de C, es un trabajo derivado de C y, por lo tanto, debe distribuirse según los términos de la GPL *. Como resultado, el trabajo combinado de A y D también debe distribuirse según los términos de la GPL, lo cual es imposible dado que la Compañía Y no posee el código fuente de A. Dicho esto, siempre que 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 de repente un trabajo derivado de C (a través de D) que debe ser licenciado bajo la GPL también.

Esta es la laguna: no hay nada que impida que la Compañía X escriba su propia versión de D, la distribuya por separado de A, y que los usuarios finales utilicen D en lugar de B cuando ejecuten 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.

¿Tengo razón en mi razonamiento? ¿Es esto una verdadera laguna en la GPL?

* D también es un trabajo derivado de A, pero para los fines de este escenario, la Compañía X ha autorizado explícitamente la creación de D y ha permitido que se le otorgue una licencia bajo la GPL.

    
pregunta Michael Kourlas 26.05.2013 - 07:21

4 respuestas

9

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

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

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

  • use el producto combinado "A - D - C" internamente por Y: también está bien, la GPL no requiere abrir la fuente A siempre que 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é sujeto a GPL (y no importa si X o Y distribuyeron esta combinación; adicionalmente, , si Y quiere hacer esto, requerirían una licencia de distribución para A de X, por supuesto)

La pregunta interesante ahora es: can D & C se distribuye por separado como código abierto bajo GPL, A & B (o simplemente A sin B) se distribuye bajo una licencia propietaria, y el usuario final reemplaza B por D & C por sí mismo.

Aquí, la modificación final de "A-B" que hace que A dependa de las librerías D & C es realizado por el usuario final, 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 "A-C & D" donde A está bajo una licencia de propiedad y C & D bajo la GPL.

Por supuesto, un abogado o un juez pueden tener una opinión diferente sobre eso. Para obtener una respuesta final, creo que debes esperar hasta que alguien lo pruebe y un segundo lo pida.

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 manera que funcione a la perfección con B o C. Y, en este caso, se podría llegar a la sospecha de que A se derivó de alguna manera de C.

EDITAR: pensando un momento 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 aplicar Adobe a Photoshop de código abierto solo porque existen algunos complementos GPL de proveedores externos. Aquí, ni siquiera se necesita una "libreta de envoltura" 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 de GPL? Creo que, en este caso, puede resultar muy difícil decidir dónde dibujar la línea, momento en el que el producto de código cerrado es un trabajo "basado en" la GPL lib.

EDIT2: hay librerías de doble licencia disponibles, con una licencia GPL para uso no comercial y una licencia propietaria para uso comercial como esta, por ejemplo . Por lo tanto, su "laguna" significaría desarrollar un producto basado en tal lib (utilizando la versión comercial, por lo que GPL no se aplica a su producto), entregar su producto como fuente cerrada sin la liberación al público y dejar que el final 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 con éxito por violación de la licencia (si no paga la licencia, por supuesto). ¿Vale la pena la molestia? Probablemente no. Especialmente en el ejemplo al que me vinculé, también tendrías que comprar la biblioteca, ya que el precio no depende de la frecuencia con la que vendas tu producto, sino de cuántos desarrolladores utilizan la biblioteca durante el desarrollo.

Finalmente, debido a esos riesgos legales, si pretendo usar las bibliotecas de código abierto dentro de un producto de fuente cerrada, evitaría las librerías de GPL si es posible, y no intentaré hacer uso de esta "laguna". LGPL o GPL con excepción de enlace es mucho más seguro, o cualquier tipo de licencia de sistema operativo no viral.

    
respondido por el Doc Brown 26.05.2013 - 16:05
4

Un ejemplo práctico son los controladores de gráficos propietarios para Linux que el usuario final tiene que 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 el creador del controlador.

Otra respuesta dice "ya 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 un derivado.

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

    
respondido por el gnasher729 09.06.2017 - 21:16
1

La vinculación define un derivado por la GPL. Esta situación específica es para lo que fue diseñada la LGPL: donde desea liberar la biblioteca como GPL pero defina el enlace como el límite explícito de la licencia aplicada, o alternativamente, donde desea enlazar contra algún código GPL pero requiere que su propio el trabajo se publicará bajo una licencia que no sea GPL.

En el caso de que el usuario final realice la vinculación (compile su propio código a partir de fuentes no GPL que puedan vincularse con una biblioteca GPL), el usuario final no ha creado efectivamente una versión GPL de cualquiera que sea el producto final, ya que no se le permite cambiar la licencia de la parte no GPL del proyecto 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 compile desde la fuente y solo se distribuye de esa manera, es irrelevante en qué licencia se encuentra la biblioteca vinculada, ya que esto está completamente fuera de las manos de los desarrolladores que no son GPL. Es decir, ¿cómo puede saber que su distribución de solo fuente se construirá en gcc en contra de glibc VS en un compilador de IBM en contra de su libc a menos que especifique esto bajo sus propios términos de licencia? Esto se ejecuta rápidamente en el uso justo y las prohibiciones contra las condiciones legales no exigibles (no es que la fantasía no haya sido escrita en la ley en varias ocasiones recientemente).

    
respondido por el zxq9 25.03.2014 - 23:02
0

No soy abogado, pero, por lo que puedo decir, no es correcto, ya que el programa depende de la biblioteca, aún es un trabajo derivado. De la misma manera que una secuencial es una obra derivada. Como mínimo, se basa en las API definidas en la biblioteca.

    
respondido por el Ofir 26.05.2013 - 07:35

Lea otras preguntas en las etiquetas