El doble estándar de código abierto de Unity: el bloqueo de VLC
(mfkl.github.io)- VLC for Unity es una integración de código abierto que conecta el motor de juegos Unity con el motor multimedia VLC, y desde diciembre de 2019 venía distribuyendo binarios por plataforma en Unity Store
- A fines del verano de 2023, tras un correo de Unity, la cuenta de publisher fue bloqueada de inmediato y, pese a meses de conversaciones y a la propuesta de excluir el código LGPL, se impidió su regreso a la Store
- En Unity Store siguen existiendo muchos assets que incluyen dependencias LGPL como FFmpeg, y tanto Unity Editor como el runtime de Unity usan bibliotecas LGPL como Lame, libiconv, libwebsockets y websockify.js
- Después de la eliminación del asset, cuando los clientes preguntaron por mantenimiento y actualizaciones de builds, Videolabs abrió la Videolabs Store en su propio sitio web y empezó a vender binarios sin depender de Unity Store
- Además de los binarios del plugin VLC Unity, Videolabs Store también cubre un esquema de soporte comercial para LibVLC·FFmpeg, licencias de LibVLCSharp, el ebook de LibVLC, Kyber y productos previstos de integración con Unreal
VLC for Unity bloqueado en Unity Store
- VLC for Unity es una integración puente que permite crear reproductores multimedia usando el motor VLC en juegos basados en Unity
- Como Unity, a través de Mono, y LibVLC, por su cuenta, tienen una alta portabilidad, esta integración apunta a un uso multiplataforma
- Desde diciembre de 2019 se distribuían en Unity Store los binarios de la integración de código abierto VLC for Unity, con 3 plataformas objetivo
- Windows
- UWP
- Android
- A fines del verano de 2023, después de que Unity enviara un correo, la cuenta de publisher fue bloqueada de inmediato
- Durante los meses siguientes se intentó encontrar un acuerdo por correo, e incluso se propuso excluir el código LGPL del asset, pero Unity no permitió el regreso a la Store
- Recibieron la respuesta de que no podrían volver aunque eliminaran todo el código LGPL del paquete de Unity
- En Unity Store todavía existen entre cientos y miles de assets que incluyen dependencias LGPL como FFmpeg
- Unity también usa dependencias LGPL en el Editor y en el runtime, lo que afecta también a los juegos distribuidos con Unity
- Como ejemplos de bibliotecas se enumeran Lame, libiconv, libwebsockets y websockify.js
- La lista completa de dependencias de código abierto de Unity puede verse en una lista separada
- El conflicto central está en el doble estándar de que Unity usa bibliotecas de código abierto LGPL, pero no permite la distribución basada en LGPL por parte de publishers y usuarios de Unity Store
Videolabs Store y soporte comercial
- Tras la eliminación del asset VLC for Unity, clientes existentes y nuevos preguntaron si habría mantenimiento y cómo obtener actualizaciones de builds
- Como muchas empresas usan tecnologías relacionadas como LibVLC SDK y FFmpeg, Videolabs decidió abrir su propia Videolabs Store
- Los clientes actuales y nuevos pueden comprar los binarios del plugin VLC Unity de código abierto sin pasar por Unity Store
- Como VLC for Unity es de código abierto, los usuarios también pueden compilarlo por su cuenta
- Videolabs Store se convierte en un canal para crear una estructura de oferta de productos y servicios clara para LibVLC y FFmpeg
- Algunos usuarios piden resolución de problemas o nuevas funciones, pero responder solo con la comunidad y el tiempo limitado de unos pocos voluntarios tiene sus límites
- El equipo de Videolabs está formado por expertos en VLC y FFmpeg, y trabaja con diversos protocolos, formatos y plataformas
- Los paquetes de consultoría multimedia ofrecidos son de 3 horas, 10 horas y 24 horas, y pueden comprarse como servicio único o como suscripción mensual
- El alcance del soporte incluye builds personalizados, corrección de bugs, integración de SDK y preguntas y respuestas sobre requisitos específicos
- Pueden brindar soporte sin importar la plataforma de sistema operativo o el toolkit
- La Store también incluye una licencia comercial de LibVLCSharp y un ebook de LibVLC
- Entre los productos previstos se encuentran Kyber, un SDK de streaming de juegos y escritorio con latencia ultrabaja y control remoto, e integraciones con motores de juego adicionales como Unreal
4 comentarios
Una empresa que ni siquiera puede hacer bien su motor anda haciendo todo tipo de tonterías, jajaja.
Es una idea vaga y extrema, pero cuando surge un problema incomprensible en la industria tecnológica, casi dan ganas de pensar que no es culpa de esos tipos de traje.
Unity otra vez...
Ya habían llevado a la empresa al borde del colapso por temas de licencias y aun así vuelven a hacer enojar a la gente jaja
Opiniones de Hacker News
Claramente parece que el equipo legal recibió información incorrecta y la metió en el contrato
Como dice la publicación, una parte considerable de los assets de Unity usa dependencias LGPL, el propio Unity también usa assets bajo LGPL, y los juegos publicados hechos con Unity también incluyen assets LGPL
Lo más probable es que la intención haya sido filtrar solo las dependencias GPL
Hay una gran diferencia entre GPL y LGPL: la LGPL está diseñada para que, si se cumplen ciertas condiciones, una aplicación privativa pueda enlazar bibliotecas de código abierto sin exigir que se publique el código fuente de la aplicación
En cambio, la GPL tiene requisitos más estrictos: toda la obra derivada que incluya código GPL debe distribuirse bajo GPL y también debe hacerse público su código fuente
Por ejemplo, yo pensaba que una app distribuida solo a través de tiendas de plataformas donde la firma es obligatoria no podía incluir componentes LGPL, porque el usuario no podría modificar esos componentes LGPL
Aun dejando de lado los detalles legales, la LGPL es más flexible que la GPL, pero sigue siendo bastante restrictiva, así que el software privativo debería mantenerse simple o consultar a un abogado especializado y verificar con cuidado el cumplimiento
En ese sentido, se entiende que Unity prohíba software LGPL. No significa que no se pueda hacer bien, sino que no es realista que Unity o el proveedor revisen legalmente cada asset que llega a la tienda en todos los casos
Incluso en 2025, resulta extraño que ni siquiera en HN nadie parezca tener claro el significado concreto de la LGPL ni sus requisitos de implementación
Si esto es tan complejo, confuso y tan sujeto a interpretación, claramente hay espacio para crear un nuevo sistema de licencias mejor, que la gente realmente pueda entender
Licencias como MIT son relativamente claras para todo el mundo, pero lo ideal sería que las distintas variantes de GPL y otras licencias personalizadas más complejas fueran reemplazadas por algo mejor
Lo importante aquí es qué se permite en la Unity Asset Store
Unity no tiene obligación de permitir en la tienda todo aquello que pueda enlazarse con juegos de Unity, y el contrato del proveedor de ese momento aparentemente solo decía que no se podían vender assets LGPL en la tienda
No sorprende ni es injusto que una tienda imponga requisitos adicionales, y además tiene razones para reducir riesgos como distribuidor de contenido de terceros
Además, los assets de Unity Asset Store no necesariamente deben usarse solo en Unity, y algunos assets también pueden usarse en otros motores según la licencia: https://support.unity.com/hc/en-us/articles/34387186019988-C...
Aun así, seguir distribuyendo otros assets que incluyen componentes LGPL mientras no se aplican las reglas LGPL de forma uniforme es más problemático
Básicamente, la LGPL exige que el usuario pueda modificar la biblioteca de código abierto, volver a compilarla y reintegrar esa nueva biblioteca en la aplicación existente
El desarrollador que usa una biblioteca LGPL tiene que hacer eso “posible”, pero lo que eso significa en la práctica deja margen de interpretación
Esa es también una razón por la que abogados y empresas evitan la LGPL: tiene incluso más margen de interpretación que la GPL
No estoy seguro de que ese supuesto se cumpla aquí
Los abogados de Unity siguen arruinando la empresa, y no sorprende mucho
Trabajé ahí hace tiempo, y aunque me enorgullecían los logros técnicos, casi todo lo demás me avergonzaba
Corrección: en realidad sí había relación, y la mayoría de los desarrolladores principales de VLC trabajaban en VideoLabs
Dejo el comentario original
Esta entrada del blog enlaza a “VideoLab Store” en https://videolabs.io y usa en grande un logo muy parecido, aunque no idéntico, al de VLC (VLC significa VideoLAN, no VideoLab)
En la página principal incluso aparece la frase “Hire the VLC team”
Hasta donde yo sabía, VideoLab no estaba afiliada a la organización sin fines de lucro VideoLAN, y parecía intentar confundir a la gente haciéndoles creer que eran desarrolladores de VLC
Actualmente, VideoLabs emplea a la mayoría de los desarrolladores principales de VLC, y esas personas son la fuerza principal detrás del desarrollo de VLC
La razón de estructurarlo así es que, incluso si la empresa Videolabs dejara de existir algún día, VLC seguiría siendo software libre para siempre y la organización sin fines de lucro también podría continuar
Es una estructura bastante típica en proyectos open source, y en el caso de VideoLAN hay 3 o 4 empresas que hacen consultoría
Básicamente, es una entidad con fines de lucro que emplea y paga a la mayoría de los principales contribuidores de VLC para que trabajen en ese ecosistema, y financia eso con consultoría y otros servicios
También contribuye bastante al código base de VLC
Como alguien que ha trabajado con ellos en una alianza, agregaría que “con fines de lucro” era sobre todo una forma legal; su mentalidad no lo era
Además, Videolabs también aparece en https://www.videolan.org/videolan/partners.html
Parece que el proyecto conoce bien a esa empresa
Ahora es un contribuidor importante de VLC, emplea a desarrolladores históricos y crea soluciones personalizadas alrededor de los ecosistemas de VLC y FFmpeg
Según la página de presentación, ellos son los principales mantenedores de VLC
Corríjanme si me equivoco.
Según entiendo, usar código LGPL v2 está bien incluso para lanzar en consolas. v2 no tiene una cláusula anti-tivoización, así que no habría problema aunque el usuario final no pueda volver a enlazar el programa por tratarse de una plataforma bloqueada.
Pero
websockify.jsy quizá otras dependencias son LGPL v3, y eso parecería significar que no pueden incluirse en plataformas como Nintendo Switch, donde el usuario final no puede reemplazar ese componente.Me pregunto si Unity está excluyendo esos componentes de las plataformas cerradas, o si simplemente está violando la LGPL v3.
Esa cláusula fue redactada de forma bastante limitada para impedir específicamente lo que hacía Tivo: vender dispositivos con un sistema operativo bloqueado *que incluyen software GPLv3.
Para que aplique, el software tiene que entregarse dentro de un “producto de usuario”, y esa entrega debe formar parte de una transacción en la que se transfieran al receptor los derechos de propiedad y uso del producto.
“Producto de usuario” normalmente significa propiedad personal tangible usada de forma personal, familiar o doméstica, o algo diseñado o vendido para incorporarse a una vivienda.
En el caso de Nintendo Switch, eso significa que Nintendo no puede incluir software GPLv3 *en la Switch misma ni en lo que venga con ella al comprarla.
El software adicional que se descarga e instala después, ya sea desde la tienda en línea de Nintendo o vendido en medio físico, no está cubierto por la cláusula anti-tivoización.
Por lo tanto, si nos limitamos solo a esa cláusula, no habría problema con que Unity incluya código GPLv3 *para plataformas cerradas, ni con que un desarrollador haga juegos para esa plataforma usando Unity.
Lo que sí puede ser un problema son *otras partes de la GPLv3. Si el software se distribuye y compra a través de una tienda de apps como la de Apple o Nintendo, entonces quienes hacen y distribuyen la copia descargable son Apple o Nintendo.
Si tienen permiso del titular de los derechos, no hay problema, pero para usar esas tiendas normalmente hay que aceptar términos que prohíben la redistribución o la ingeniería inversa, y eso viola la *GPLv3.
Si el titular de los derechos posee el copyright de todo el código usado, puede autorizar a Apple o Nintendo a distribuirlo.
Pero si una app o juego incluye una biblioteca GPL de terceros *y ese tercero no le ha dado esa licencia al operador de la tienda, entonces esa app o juego no puede distribuirse en esa tienda.
Es una copia del contenido de un enlace muerto.
Apple tiene el mismo problema que Unity. Si en macOS ejecutas
% bash --version, sale GNU bash 3.2.57, y como no pueden subir de la 3.2, que fue la última versión bajo GPL v2, mantienen ellos mismos una versión vieja.Es una versión tan vieja que, en EE. UU., ya tendría edad para fumar, votar e ir a la guerra, y Apple está intentando mover a los usuarios a zsh.
Revisé la LGPL 2.1, y la parte de “or later” en la licencia es rara. El usuario puede cambiarla, a su discreción, por cualquier versión de GPL 2.1 o superior.
Eso sí, el autor de la biblioteca tiene que indicar en el archivo COPYING si es LGPL, específicamente LGPL 2.1, o la recomendada “LGPL 2.1 or later”.
Que Unity haya dicho que el código LGPL está “deprecated” tiene sentido, siempre que el código no fije una versión concreta de LGPL. Eso se debe a que un proveedor upstream de LGPL podría hacer en cualquier momento una jugada de licencia como la de bash.
Pero la biblioteca de VLC aparece aquí como “LGPL 2.1 only”, así que están afirmando explícitamente que no pueden hacer esa jugada salvo que salten a GPL3: https://code.videolan.org/explore/projects/starred
Sin embargo, VLC no incluyó correctamente la licencia, y ni
COPYINGniCOPYING.libdicen si fijan la versión de LGPL, mientras queREADME.mddicelibVLC, the engine is released under the LGPLv2 (or later) license.: https://code.videolan.org/videolan/vlcAsí que la preocupación de Unity parece tener algo de fundamento. “or later” incluye v3, y v3 choca especialmente con DRM o con cosas como las consolas.
Pero mi sospecha es que a Unity le preocupa molestar a algún tercero con patentes sobre algoritmos implementados por VLC, y que está usando la LGPL como pretexto para ocultar los detalles de ese acuerdo confidencial.
Godot es mejor.
Hoy en día, Unity es una mala decisión de negocio.
Si tuviera que elegir un motor comercial, al menos escogería Epic Games, que gasta a sus abogados en pelearse con Apple en vez de molestar a desarrolladores de código abierto.
Curiosamente, parece que 5.10.4 ya no está en el acuerdo para proveedores: https://unity.com/legal/provider
En algún momento sí incluía esta cláusula:
5.10.4 Provider represents and warrants that its Assets shall not contain (a) any software licensed under the GNU General Public License or GNU Library or Lesser General Public License, or any other license with terms that include a requirement to extend such license to any modification or combined work and provide for the distribution of the combined or modified product’s source code upon demand so that Customer content becomes subject to the terms of such license; or (b) any software that is a modification or derivative of any software licensed under the GNU General Public License or Library or Lesser Public License, or any other license with terms similar thereto so that Customer content become subject to the terms of such license.Pero según Wayback Machine, lo eliminaron en algún momento entre el 3 y el 12 de diciembre
De verdad quiero usar Unity en un proyecto
De hecho me gustan el editor y la API, y permite crear varias herramientas dentro del editor con bastante facilidad para gente que no es muy técnica
Pero Unity hace que usarlo sea difícil en cada paso: comportamiento hostil hacia los usuarios, 20 paquetes beta con el clásico “de verdad prometemos estabilizarlo el próximo año”, e incluso un rendimiento terriblemente malo hasta en proyectos vacíos
Ahora uso principalmente Godot y está bien, pero no se compara del todo con Unity
¿Unity ahora te banea permanentemente la cuenta por subir un paquete que ellos mismos marcaron como deprecated? ¿Qué demonios están fumando?
¿Compite con su propio reproductor multimedia? ¿O el creador de VLC salió con la ex de algún ejecutivo de Unity o qué?
Es una moda realmente estúpida y deberíamos erradicarla entre todos, pero todavía no llegamos a eso
Si interpretas la nota de Unity, parece decir que eliminaron las librerías de VLC de la Unity Store y banearon permanentemente la cuenta del grupo de VLC en la Unity Store por violar las condiciones del contrato con Unity
La jerga corporativa puede ser difícil de entender. Tal vez ese sea justamente el propósito principal de la jerga corporativa
Unity vuelve a mostrar hostilidad
Banear permanentemente a un desarrollador por algo así es una locura
Esto pasó en agosto de 2023, antes del escándalo del cobro por instalación
No sorprende. Unity es una empresa realmente terrible.