O duplo padrão open source da Unity: bloqueio do VLC
(mfkl.github.io)- O VLC for Unity é uma integração open source que conecta o motor de jogos Unity ao motor multimídia VLC, e vinha distribuindo binários por plataforma na Unity Store desde dezembro de 2019
- No fim do verão de 2023, após um e-mail da Unity, a conta de publisher foi bloqueada imediatamente e, mesmo depois de meses de negociação e da proposta de excluir código LGPL, o retorno à Store foi impedido
- Na Unity Store ainda há muitos assets que incluem dependências LGPL, como FFmpeg, e o próprio Unity Editor e o runtime também usam bibliotecas LGPL como Lame, libiconv, libwebsockets e websockify.js
- Depois da remoção do asset, clientes passaram a perguntar sobre manutenção e atualizações de build; então a Videolabs abriu a Videolabs Store em seu próprio site e começou a vender binários sem depender da Unity Store
- Além dos binários do plugin VLC Unity, a Videolabs Store também cobre uma estrutura de suporte comercial para LibVLC·FFmpeg, licença do LibVLCSharp, ebook sobre LibVLC, Kyber e produtos planejados de integração com Unreal
VLC for Unity bloqueado na Unity Store
- VLC for Unity é uma integração em ponte que permite criar, em jogos baseados em Unity, players de mídia usando o motor VLC
- Como o Unity tem alta portabilidade via Mono, e o LibVLC também é altamente portátil por si só, essa integração tem como objetivo o uso multiplataforma
- Desde dezembro de 2019, binários da integração open source VLC for Unity eram distribuídos na Unity Store, com três plataformas-alvo
- Windows
- UWP
- Android
- No fim do verão de 2023, depois que a Unity enviou um e-mail, a conta de publisher foi bloqueada imediatamente
- Nos meses seguintes, buscou-se um acordo por e-mail, e até foi proposta a exclusão do código LGPL do asset, mas a Unity não permitiu o retorno à Store
- A resposta recebida foi que, mesmo removendo todo o código LGPL do pacote Unity, ele não poderia retornar
- Na Unity Store ainda existem de centenas a milhares de assets que incluem dependências LGPL, como FFmpeg
- A própria Unity também usa dependências LGPL no Editor e no runtime, o que afeta também jogos distribuídos com Unity
- Lame, libiconv, libwebsockets e websockify.js são listados como exemplos de bibliotecas
- A lista completa de dependências open source da Unity pode ser vista em uma lista separada
- O conflito central está no duplo padrão da Unity: ela usa bibliotecas open source LGPL, mas não permite que publishers e usuários da Unity Store façam distribuições baseadas em LGPL
Videolabs Store e suporte comercial
- Depois que o asset VLC for Unity foi removido, clientes antigos e novos perguntaram se haveria manutenção e como obter atualizações de build
- Como muitas empresas usam tecnologias relacionadas, como o LibVLC SDK e o FFmpeg, a Videolabs decidiu abrir sua própria Videolabs Store
- Clientes antigos e novos podem comprar binários do plugin open source VLC Unity mesmo sem a Unity Store
- Como o VLC for Unity é open source, os usuários também podem fazer o build por conta própria
- A Videolabs Store se torna um canal para criar uma estrutura de oferta de produtos e serviços clara para LibVLC e FFmpeg
- Alguns usuários pedem resolução de problemas ou novos recursos, mas há limites para atender a tudo apenas com o tempo limitado da comunidade e de um pequeno número de voluntários
- A equipe da Videolabs é composta por especialistas em VLC e FFmpeg, cobrindo diversos protocolos, formatos e plataformas
- Os pacotes de consultoria multimídia oferecidos são de 3 horas, 10 horas e 24 horas, e podem ser comprados como serviço avulso ou assinatura mensal
- O escopo do suporte inclui builds customizados, correções de bugs, integração de SDK e respostas a perguntas sobre requisitos específicos
- O suporte pode ser prestado independentemente da plataforma de sistema operacional ou toolkit
- A Store também inclui uma licença comercial do LibVLCSharp e um ebook sobre LibVLC
- Entre os produtos planejados estão Kyber, um SDK de streaming de jogos e desktop com latência ultrabaixa e controle remoto, além de integrações adicionais com motores de jogos como Unreal
4 comentários
Uma empresa que nem consegue fazer um motor direito fica fazendo todo tipo de besteira mesmo kkk
É uma ideia vaga e extrema, mas quando surge um problema incompreensível no setor de tecnologia, quase parece que a culpa é dos engravatados, não é?
A Unity de novo...
Eles já tinham levado a empresa quase à ruína por causa de licenciamento e ainda conseguem irritar as pessoas de novo haha
Opiniões do Hacker News
Parece claro que o departamento jurídico recebeu informações erradas e colocou isso no contrato
Como o texto diz, muitos assets da Unity usam dependências LGPL, a própria Unity também usa assets LGPL, e jogos lançados feitos com Unity também incluem assets LGPL
A intenção provavelmente era filtrar apenas dependências GPL
Há uma grande diferença entre GPL e LGPL: a LGPL é uma licença projetada para permitir que aplicações proprietárias façam link com bibliotecas open source, sem exigir a divulgação do código-fonte da aplicação, desde que certas condições sejam cumpridas
Já a GPL impõe requisitos mais rígidos: qualquer derivado que inclua código GPL deve ser distribuído como GPL, e o código-fonte também deve ser divulgado
Por exemplo, eu achava que apps distribuídos apenas por lojas de plataformas em que assinatura é obrigatória não poderiam incluir componentes LGPL, porque o usuário não conseguiria modificar esses componentes LGPL
Mesmo deixando de lado os detalhes jurídicos, a LGPL é mais flexível que a GPL, mas ainda é bastante restritiva; então software proprietário precisa manter as coisas simples ou consultar advogados especializados na área para verificar cuidadosamente a conformidade
Nesse sentido, dá para entender a Unity proibir software LGPL. Não quer dizer que seja impossível fazer direito, mas que não é realista a Unity ou o fornecedor revisar juridicamente, toda vez, todos os assets que entram na loja
Mesmo em 2025, é estranho que nem no HN ninguém saiba ao certo o significado específico da LGPL ou seus requisitos de implementação
Se o estado das coisas é tão complexo, confuso e sujeito a interpretação, certamente há espaço para criar um novo sistema de licenças melhor, que as pessoas consigam entender de verdade
Licenças como a MIT são compreendidas de forma relativamente clara por todos, mas o ideal seria substituir as várias famílias GPL e licenças personalizadas mais complexas por algo melhor
O importante aqui é o que permitir na Unity Asset Store
A Unity não tem obrigação de permitir na loja tudo que possa ser linkado a um jogo Unity, e o contrato de fornecedor da época parece ter dito simplesmente que assets LGPL não poderiam ser vendidos na loja
Não é surpreendente nem injusto a loja impor requisitos adicionais, e há motivos para reduzir riscos como distribuidora de conteúdo de terceiros
Além disso, os assets da Unity Asset Store não precisam necessariamente ser usados apenas na Unity; dependendo da licença, alguns assets também podem ser usados em outros engines: https://support.unity.com/hc/en-us/articles/34387186019988-C...
Ainda assim, é mais problemático continuar distribuindo outros assets que incluem componentes LGPL enquanto as regras da LGPL não são aplicadas de forma uniforme
A LGPL basicamente exige que o usuário possa modificar a biblioteca open source, recompilá-la e reintegrar essa nova biblioteca à aplicação existente
O desenvolvedor que usa uma biblioteca LGPL precisa tornar isso “possível”, mas o que isso significa na prática é algo aberto a interpretação
O motivo de advogados e empresas evitarem a LGPL também é que ela envolve ainda mais margem para interpretação do que a GPL
Não sei bem se essa premissa se aplica aqui
Os advogados da Unity continuam destruindo a empresa, e isso não surpreende muito
Trabalhei lá no passado; eu tinha orgulho das conquistas técnicas, mas quase todo o resto me envergonhava
Correção: na verdade havia relação, e a maioria dos principais desenvolvedores do VLC trabalhava na VideoLabs
Vou manter o comentário original
Este post do blog aponta para a “VideoLab Store” em https://videolabs.io, usando em destaque um logotipo muito parecido com o do VLC (que significa VideoLAN, não VideoLab), mas que não é idêntico
Na página inicial, há até a frase “Hire the VLC team”
Pelo que eu sabia, a VideoLab não tinha relação com a organização sem fins lucrativos VideoLAN e parecia estar tentando induzir as pessoas a acreditar que eram desenvolvedores do VLC
Atualmente, a VideoLabs emprega a maioria dos principais desenvolvedores do VLC, e essas pessoas são a principal força por trás do desenvolvimento do VLC
O motivo dessa estrutura é garantir que, mesmo que a empresa Videolabs não exista para sempre, o VLC continue sendo software livre para sempre e a organização sem fins lucrativos também continue existindo
É uma estrutura bastante típica em projetos open source e, no caso da VideoLAN, há 3 ou 4 empresas que fazem consultoria
Em essência, é uma entidade com fins lucrativos que emprega e remunera a maioria dos principais contribuidores do VLC para trabalharem nesse ecossistema, financiando isso com consultoria e outros serviços
Também contribui bastante para a base de código do VLC
Acrescentando como alguém que já trabalhou com eles em parceria, “com fins lucrativos” era principalmente uma forma jurídica; a mentalidade não era essa
Além disso, a Videolabs também aparece em https://www.videolan.org/videolan/partners.html
O pessoal do projeto parece conhecer bem a empresa
Hoje, como principal contribuidora do VLC, emprega desenvolvedores históricos e cria soluções personalizadas em torno dos ecossistemas VLC e FFmpeg
Segundo a página “Sobre”, eles são os principais mantenedores do VLC
Corrijam-me se eu estiver errado
Pelo que entendo, usar código LGPL v2 também é aceitável em lançamentos para consoles. A v2 não tem uma cláusula anti-tivoização, o que significa que não há problema se o usuário final não puder relincar o programa por causa de uma plataforma bloqueada
Mas websockify.js e provavelmente outras dependências são LGPL v3, e isso parece significar que elas não podem ser incluídas em plataformas como o Nintendo Switch, nas quais o usuário final não consegue substituir esses componentes
Fico curioso se a Unity está excluindo esses componentes em plataformas bloqueadas, ou se está simplesmente violando a LGPL v3
Essa cláusula foi escrita de forma bem restrita para impedir o que a Tivo fazia. Ou seja, mira casos em que se vende um dispositivo com um sistema operacional bloqueado que inclui software *GPLv3
Para se aplicar, o software precisa ser transmitido dentro de um “produto de usuário”, e essa transmissão precisa fazer parte de uma transação que transfere ao destinatário o direito de posse e uso do produto
“Produto de usuário” normalmente significa um bem pessoal tangível usado para fins pessoais, familiares ou domésticos, ou algo projetado e vendido para incorporação a um espaço residencial
No caso do Nintendo Switch, isso significa que a Nintendo não pode colocar software *GPLv3 no próprio Switch nem no que é fornecido junto com ele na compra
Software adicional baixado e instalado depois, software vendido pela loja online da Nintendo ou em mídia física, não está sujeito à cláusula anti-tivoização
Portanto, olhando apenas para essa cláusula, não há problema em a Unity incluir código *GPLv3 para plataformas bloqueadas, nem em desenvolvedores criarem jogos com Unity para essas plataformas
O que pode ser problemático são outras partes da *GPLv3. Quando um software é distribuído e comprado por meio de uma loja de apps como a da Apple ou da Nintendo, quem cria e distribui as cópias baixadas é a Apple ou a Nintendo
Se elas receberam permissão do detentor dos direitos autorais, tudo bem; mas, para usar essas lojas, normalmente é preciso concordar com termos que proíbem redistribuição ou engenharia reversa, e isso viola a *GPLv3
Se o detentor dos direitos autorais possui os direitos de todo o código usado, ele pode conceder permissão de distribuição à Apple ou à Nintendo
Mas, se o app ou jogo inclui uma biblioteca *GPL de terceiros e esse terceiro não concedeu essa licença ao operador da loja, esse app ou jogo não pode ser distribuído nessa loja
É uma cópia do conteúdo de um link morto
A Apple também tem o mesmo problema que a Unity. Se você rodar
% bash --versionno macOS, aparece GNU bash 3.2.57; como não pode atualizar para além da 3.2, a última versão sob GPL v2, ela mantém por conta própria essa versão antigaÉ uma versão antiga o bastante para, nos EUA, poder fumar, votar e ir para a guerra, e a Apple está tentando mover os usuários para o zsh
Dei uma olhada na LGPL 2.1, e a parte “or later” da licença é estranha. O usuário pode, a seu critério, mudar para qualquer versão da GPL 2.1 ou posterior
Só que o autor da biblioteca precisa declarar no arquivo COPYING a LGPL, especificamente a LGPL 2.1, ou a forma recomendada “LGPL 2.1 or later”
Faz sentido a Unity dizer que código LGPL está “deprecated”, desde que o código não fixe a versão da LGPL. Um fornecedor LGPL upstream pode fazer a qualquer momento um rug pull de licença, como o bash
Mas as bibliotecas do VLC aparecem aqui marcadas como “LGPL 2.1 only”, ou seja, estão afirmando explicitamente que não podem dar esse rug pull sem saltar para a GPL3: https://code.videolan.org/explore/projects/starred
Só que o VLC não incluiu a licença corretamente; COPYING e COPYING.lib não dizem se fixam a versão da LGPL, e o README.md diz
libVLC, the engine is released under the LGPLv2 (or later) license.: https://code.videolan.org/videolan/vlcEntão a preocupação da Unity parece, até certo ponto, fazer sentido. “or later” inclui a v3, e a v3 combina especialmente mal com tecnologias antitrapaça ou coisas como consoles
Mas meu palpite é que a Unity está preocupada em irritar terceiros que detêm patentes sobre algoritmos implementados pelo VLC, e está usando a LGPL como desculpa para esconder os detalhes desses acordos confidenciais
Godot é melhor
Hoje em dia, Unity é uma má escolha de negócios
Se eu tivesse que escolher uma engine comercial, escolheria pelo menos a Epic Games, que usa advogados para brigar com a Apple em vez de perseguir desenvolvedores open source
Curiosamente, parece que não há a cláusula 5.10.4 no contrato de provedor: https://unity.com/legal/provider
Em algum momento, essa cláusula existia:
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.Mas, segundo a Wayback Machine, ela foi removida entre 3 e 12 de dezembro
Eu realmente queria usar Unity no projeto
Eu de fato gosto do editor e da API, e dá para criar várias ferramentas dentro do editor com bastante facilidade para pessoas que não são familiarizadas com tecnologia
Mas a Unity dificulta o uso a cada passo, com atitudes hostis ao usuário, uns 20 pacotes beta no estilo “prometemos de verdade que no ano que vem vai ficar estável”, e até desempenho ficando muito pior mesmo em projetos vazios
Hoje uso principalmente Godot e ele é bom, mas não é totalmente comparável ao Unity
A Unity agora está banindo permanentemente contas só porque alguém subiu um pacote que ela decidiu marcar como deprecated? Que diabos eles estão fumando?
Ele compete com o player de mídia próprio deles? Ou será que quem fez o VLC está saindo com ex de algum executivo da Unity?
É uma moda muito idiota, e todos deveríamos empurrar de volta contra isso, mas ainda não chegamos lá
Interpretando a nota da Unity, parece significar que eles removeram a biblioteca VLC da Unity Store e baniram permanentemente a conta do grupo do VLC na Unity Store por violação dos termos do contrato com a Unity
Jargão corporativo pode ser difícil de entender. Talvez esse seja justamente o principal objetivo do jargão corporativo
A Unity mostrando hostilidade de novo
Banir permanentemente um desenvolvedor por esse motivo é loucura
Isso aconteceu em agosto de 2023, antes da polêmica da cobrança por instalação
Não surpreende. A Unity é uma empresa realmente terrível