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.