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.