Le double standard open source de Unity : le blocage de VLC
(mfkl.github.io)- VLC for Unity est une intégration open source qui relie le moteur de jeu Unity au moteur multimédia VLC ; depuis décembre 2019, elle distribuait sur le Unity Store des binaires propres à chaque plateforme
- À la fin de l’été 2023, après un e-mail de Unity, le compte éditeur a été immédiatement bloqué et, malgré plusieurs mois de discussions et une proposition d’exclure le code LGPL, le retour sur le Store est resté impossible
- De nombreux assets incluant des dépendances LGPL comme FFmpeg sont toujours présents sur le Unity Store, et Unity Editor ainsi que le runtime utilisent eux-mêmes des bibliothèques LGPL comme Lame, libiconv, libwebsockets et websockify.js
- Après le retrait de l’asset, des clients ayant demandé comment assurer la maintenance et les mises à jour de builds, Videolabs a ouvert le Videolabs Store sur son propre site afin de commencer à vendre des binaires sans passer par le Unity Store
- Le Videolabs Store couvre, en plus des binaires du plugin VLC Unity, un dispositif de support commercial pour LibVLC et FFmpeg, ainsi que la licence LibVLCSharp, l’ebook LibVLC, Kyber et de futures intégrations Unreal
VLC for Unity bloqué sur le Unity Store
- VLC for Unity est une intégration passerelle qui permet de créer, dans des jeux basés sur Unity, un lecteur multimédia exploitant le moteur VLC
- Unity via Mono, et LibVLC de son côté, étant très portables, cette intégration vise un usage cross-platform
- Depuis décembre 2019, les binaires de l’intégration open source VLC for Unity étaient distribués sur le Unity Store, pour trois plateformes cibles
- Windows
- UWP
- Android
- À la fin de l’été 2023, après l’envoi d’un e-mail par Unity, le compte éditeur a été immédiatement bloqué
- Pendant les mois qui ont suivi, des compromis ont été recherchés par e-mail, avec même une proposition de retirer le code LGPL de l’asset, mais Unity n’a pas autorisé son retour sur le Store
- La réponse reçue indiquait qu’un retour serait impossible même si tout le code LGPL était supprimé du package Unity
- Le Unity Store compte encore aujourd’hui des centaines, voire des milliers d’assets contenant des dépendances LGPL comme FFmpeg
- Unity utilise lui-même des dépendances LGPL dans l’Editor et le runtime, ce qui a aussi des implications pour les jeux distribués avec Unity
- Les bibliothèques citées en exemple sont Lame, libiconv, libwebsockets et websockify.js
- La liste complète des dépendances open source de Unity est disponible dans une liste séparée
- Le cœur du conflit tient au double standard selon lequel Unity utilise des bibliothèques open source LGPL, tout en n’autorisant pas les éditeurs et utilisateurs du Unity Store à distribuer sur cette base LGPL
Videolabs Store et support commercial
- Après le retrait de l’asset VLC for Unity, des clients existants et nouveaux ont demandé si la maintenance continuerait et comment obtenir des mises à jour de builds
- De nombreuses entreprises utilisant des technologies connexes comme le SDK LibVLC et FFmpeg, Videolabs a décidé d’ouvrir son propre Videolabs Store
- Les clients existants comme nouveaux peuvent acheter les binaires du plugin open source VLC Unity sans passer par le Unity Store
- VLC for Unity étant open source, les utilisateurs peuvent aussi le compiler eux-mêmes
- Le Videolabs Store devient un canal permettant de clarifier la structure d’offre de produits et services autour de LibVLC et FFmpeg
- Certains utilisateurs demandent des corrections de problèmes ou de nouvelles fonctionnalités, mais il est difficile d’y répondre avec seulement le temps limité de la communauté et d’un petit nombre de bénévoles
- L’équipe Videolabs est composée d’experts de VLC et de FFmpeg, couvrant de nombreux protocoles, formats et plateformes
- Les packages de conseil multimédia proposés sont de 3 heures, 10 heures et 24 heures, disponibles en prestation ponctuelle ou en abonnement mensuel
- Le périmètre du support inclut les builds personnalisés, les corrections de bugs, l’intégration de SDK et les questions-réponses sur des besoins spécifiques
- Le support est possible quel que soit le système d’exploitation ou le toolkit
- Le Store inclut aussi une licence commerciale LibVLCSharp et un ebook LibVLC
- Parmi les produits prévus figurent Kyber, un SDK de streaming et de contrôle à distance pour jeux et desktop à latence ultra-faible, ainsi que des intégrations avec d’autres moteurs de jeu comme Unreal
4 commentaires
Une entreprise même pas capable de faire correctement un moteur se met à enchaîner toutes les conneries possibles, hein ? mdr
C’est une pensée vague et extrême, mais j’ai l’impression que, lorsqu’un problème incompréhensible surgit dans l’industrie tech, c’est presque toujours la faute des types en costume.
Unity, encore...
Ils ont déjà été jusqu’à mettre l’entreprise en péril à cause des questions de licence, et voilà qu’ils réussissent encore à énerver les gens haha
Avis de Hacker News
Il semble clair que l’équipe juridique a reçu de mauvaises informations et les a intégrées au contrat.
Comme le dit l’article, une bonne partie des assets Unity utilisent des dépendances LGPL, Unity lui-même utilise des assets LGPL, et des jeux publiés créés avec Unity contiennent aussi des assets LGPL.
L’intention était très probablement de ne filtrer que les dépendances GPL.
Il y a une grande différence entre GPL et LGPL : la LGPL est une licence conçue pour permettre, sous certaines conditions, à des applications propriétaires de lier des bibliothèques open source sans exiger la publication du code source de l’application.
À l’inverse, la GPL impose des exigences plus strictes : toute œuvre dérivée contenant du code GPL doit être distribuée sous GPL, avec son code source publié.
Par exemple, je pensais qu’une app distribuée uniquement via la boutique d’une plateforme où la signature est obligatoire ne pouvait pas inclure de composants LGPL, puisque l’utilisateur ne peut pas modifier ces composants LGPL.
Même en laissant de côté les détails juridiques, la LGPL est plus souple que la GPL, mais elle reste assez contraignante ; les logiciels propriétaires doivent donc rester simples ou consulter un avocat spécialisé pour vérifier prudemment la conformité.
De ce point de vue, il est compréhensible que Unity interdise les logiciels sous LGPL. Cela ne veut pas dire qu’ils ne pourraient pas le faire correctement, mais qu’il n’est pas réaliste que Unity ou le fournisseur examine juridiquement, à chaque fois, tous les assets publiés sur le store.
Même en 2025, il est étrange que, même sur HN, personne ne sache avec certitude ce que signifie précisément la LGPL ni ce qu’elle exige en termes d’implémentation.
Si la situation est aussi complexe, confuse et laissée à l’interprétation, il y a clairement de la place pour créer un nouveau système de licences meilleur, que les gens puissent réellement comprendre.
Les licences comme MIT sont comprises assez clairement par tout le monde, mais les diverses variantes de la famille GPL et les licences personnalisées plus complexes gagneraient idéalement à être remplacées par quelque chose de meilleur.
Ce qui compte ici, c’est ce que le Unity Asset Store autorise.
Unity n’a aucune obligation d’autoriser sur son store tout ce qui pourrait être lié à un jeu Unity, et l’accord fournisseur de l’époque semble avoir simplement interdit la vente d’assets LGPL sur le store.
Il n’est ni surprenant ni injuste qu’un store impose des exigences supplémentaires, et il y a aussi des raisons de réduire les risques en tant que distributeur de contenus tiers.
De plus, les assets du Unity Asset Store ne doivent pas nécessairement être utilisés uniquement avec Unity ; certains assets peuvent être utilisés avec d’autres moteurs selon leur licence : https://support.unity.com/hc/en-us/articles/34387186019988-C...
Cela dit, le fait de continuer à distribuer d’autres assets contenant des composants LGPL tout en n’appliquant pas les règles de la LGPL de manière uniforme est plus problématique.
Fondamentalement, la LGPL exige que l’utilisateur puisse modifier la bibliothèque open source, la reconstruire, puis réintégrer cette nouvelle bibliothèque dans l’application existante.
Le développeur qui utilise une bibliothèque LGPL doit rendre cela « possible », mais ce que cela signifie concrètement reste ouvert à interprétation.
Si les avocats et les entreprises se méfient de la LGPL, c’est aussi parce qu’elle laisse davantage de marge d’interprétation que la GPL.
Je ne suis pas sûr que cette prémisse s’applique ici.
Les avocats de Unity continuent de ruiner l’entreprise, et ce n’est pas vraiment surprenant.
J’y ai travaillé autrefois ; j’étais fier des réalisations techniques, mais presque tout le reste me faisait honte.
Correction : en réalité, il y avait bien un lien, et la plupart des développeurs principaux de VLC travaillaient chez VideoLabs
Je laisse le commentaire initial
Ce billet de blog renvoie vers le « VideoLab Store » sur https://videolabs.io, avec un grand logo très similaire à celui de VLC (qui signifie VideoLAN, pas VideoLab), mais pas identique
La page d’accueil affiche même la phrase « Hire the VLC team »
À ma connaissance, VideoLab n’avait aucun lien avec l’association à but non lucratif VideoLAN, et cela donnait l’impression qu’ils cherchaient à faire croire aux gens qu’ils étaient les développeurs de VLC
Aujourd’hui, VideoLabs emploie la plupart des développeurs principaux de VLC, et ce sont eux le principal moteur du développement de VLC
Cette organisation existe pour que VLC reste à jamais un logiciel libre et que l’association à but non lucratif continue d’exister, même si la société Videolabs ne devait pas durer éternellement
C’est une structure assez typique dans les projets open source, et dans le cas de VideoLAN, il existe 3 ou 4 sociétés qui font du conseil
En substance, c’est une entité commerciale qui emploie et rémunère la plupart des principaux contributeurs de VLC pour travailler dans cet écosystème, et finance cela par du conseil et d’autres services
Elle contribue aussi de manière importante à la base de code de VLC
Pour avoir travaillé avec eux dans le cadre d’un partenariat, j’ajouterais que le côté « commercial » relève surtout de la forme juridique, pas de l’état d’esprit
En plus, Videolabs figure aussi sur https://www.videolan.org/videolan/partners.html
Le projet semble donc bien connaître cette entreprise
Aujourd’hui, en tant que contributeur majeur de VLC, elle emploie des développeurs historiques et crée des solutions sur mesure autour des écosystèmes VLC et FFmpeg
D’après la page À propos, ils sont les mainteneurs principaux de VLC
Corrigez-moi si je me trompe
D’après ce que je comprends, utiliser du code LGPL v2 est acceptable même pour une sortie sur console. La v2 ne comporte pas de clause anti-tivoïsation, ce qui signifie que ce n’est pas un problème si l’utilisateur final ne peut pas relinker le programme à cause d’une plateforme verrouillée
Mais websockify.js et sans doute d’autres dépendances sont sous LGPL v3, ce qui semble signifier qu’elles ne peuvent pas être incluses sur des plateformes comme la Nintendo Switch, où l’utilisateur final ne peut pas remplacer ces composants
Je me demande si Unity exclut ces composants sur les plateformes verrouillées, ou s’il viole simplement la LGPL v3
Cette clause a été rédigée de manière assez étroite pour empêcher ce que faisait TiVo. Autrement dit, elle vise les cas où l’on vend un appareil doté d’un système d’exploitation verrouillé et incluant du logiciel sous *GPLv3
Pour qu’elle s’applique, le logiciel doit être transmis dans un « produit utilisateur », et cette transmission doit faire partie d’une transaction où les droits de possession et d’usage du produit sont transférés au destinataire
Un « produit utilisateur » désigne en général un bien meuble corporel normalement utilisé à des fins personnelles, familiales ou domestiques, ou conçu et vendu pour être intégré à un logement
Dans le cas de la Nintendo Switch, cela signifie que Nintendo ne peut pas intégrer de logiciel sous *GPLv3 dans la Switch elle-même, ni dans ce qui est fourni avec à l’achat
Les logiciels supplémentaires téléchargés et installés par la suite, ceux vendus via la boutique en ligne de Nintendo ou sur support physique, ne sont pas concernés par la clause anti-tivoïsation
Donc, si l’on ne considère que cette clause, il n’y a pas de problème à ce qu’Unity inclue du code sous *GPLv3 pour des plateformes verrouillées, ni à ce qu’un développeur crée avec Unity des jeux pour ces plateformes
Ce qui peut poser problème, ce sont d’autres parties de la *GPLv3. Quand un logiciel est distribué et acheté via un app store comme ceux d’Apple ou de Nintendo, l’entité qui crée et distribue les copies téléchargées est Apple ou Nintendo
Si l’autorisation du titulaire des droits a été obtenue, c’est acceptable, mais utiliser ce type de boutique implique généralement d’accepter des conditions interdisant la redistribution ou la rétro-ingénierie, ce qui constitue une violation de la *GPLv3
Si le titulaire des droits détient le copyright sur tout le code utilisé, il peut accorder à Apple ou Nintendo l’autorisation de le distribuer
Mais si une app ou un jeu inclut une bibliothèque tierce sous *GPL et que ce tiers n’a pas accordé une telle licence à l’opérateur de la boutique, cette app ou ce jeu ne peut pas être distribué via cette boutique
C’est une copie du contenu d’un lien mort
Apple a le même problème qu’Unity. Si l’on fait
% bash --versionsous macOS, on obtient GNU bash 3.2.57 ; Apple ne peut pas le mettre à jour au-delà de la 3.2, dernière version publiée sous GPL v2, et maintient donc lui-même cette vieille versionC’est une version assez vieille pour, aux États-Unis, fumer, voter et partir à la guerre, et Apple essaie de faire migrer les utilisateurs vers zsh
J’ai regardé la LGPL 2.1, et la partie « or later » de la licence est étrange. L’utilisateur peut, à sa discrétion, passer à n’importe quelle version de la GPL 2.1 ou ultérieure
En revanche, l’auteur de la bibliothèque doit indiquer dans le fichier COPYING la LGPL, précisément la LGPL 2.1, ou la formulation recommandée « LGPL 2.1 or later »
Le fait qu’Unity dise avoir rendu le code LGPL « deprecated » se comprend, sauf si le code fixe une version précise de la LGPL. Car un fournisseur amont en LGPL peut à tout moment faire un rug pull de licence, comme bash
Mais les bibliothèques VLC sont indiquées ici comme étant « LGPL 2.1 only », ce qui revient à affirmer explicitement qu’elles ne peuvent pas faire de rug pull sans passer à la GPL3 : https://code.videolan.org/explore/projects/starred
Cela dit, VLC n’a pas inclus correctement sa licence : COPYING et COPYING.lib ne disent pas si la version de la LGPL est figée, et README.md indique
libVLC, the engine is released under the LGPLv2 (or later) license.: https://code.videolan.org/videolan/vlcDonc les inquiétudes d’Unity semblent en partie fondées. « or later » inclut la v3, et la v3 est particulièrement peu compatible avec des technologies anti-triche ou des consoles
Mais mon hypothèse est qu’Unity craint surtout de mécontenter des tiers détenant des brevets sur des algorithmes implémentés par VLC, et utilise la LGPL comme prétexte pour masquer les détails de ces accords non publics
Godot est mieux
De nos jours, Unity est un mauvais choix business
S’il faut choisir un moteur commercial, je prendrais au moins Epic Games, qui dépense ses avocats pour se battre contre Apple plutôt que pour harceler les développeurs open source
Fait intéressant, il semble que la clause 5.10.4 ne figure pas dans le contrat fournisseur : https://unity.com/legal/provider
À une époque, cette clause y figurait :
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.Mais d’après la Wayback Machine, elle a été supprimée entre le 3 et le 12 décembre
J’ai vraiment envie d’utiliser Unity pour des projets
J’aime réellement l’éditeur et l’API, et on peut assez facilement créer dans l’éditeur divers outils pour des personnes peu à l’aise avec la technique
Mais Unity rend son utilisation difficile à chaque étape, entre des comportements hostiles aux utilisateurs, une vingtaine de packages bêta du genre « promis, l’an prochain ce sera stable », et des performances qui se dégradent fortement même dans un projet vide
Aujourd’hui j’utilise surtout Godot, et c’est très bien, mais ce n’est pas totalement comparable à Unity
Unity bannit donc définitivement un compte parce qu’il a publié un package qu’ils ont désormais décidé de marquer comme deprecated ? Ils fument quoi, exactement ?
Est-ce que ça concurrence leur propre lecteur multimédia ? Ou bien le créateur de VLC sortirait-il avec l’ex d’un dirigeant d’Unity ?
C’est une mode vraiment stupide, et il faudrait qu’on la combatte collectivement, mais on n’en est pas encore là
En interprétant la note d’Unity, cela semble vouloir dire qu’ils ont supprimé la bibliothèque VLC de l’Unity Store et banni définitivement le compte Unity Store du groupe VLC pour violation des conditions contractuelles avec Unity
Le jargon corporate peut être difficile à comprendre. Peut-être que c’est justement l’objectif principal du jargon corporate
Unity montre encore une fois son hostilité
Bannir définitivement un développeur pour une raison pareille, c’est délirant
Cette affaire remonte à août 2023, avant le fiasco de la facturation par installation
Rien d’étonnant. Unity est vraiment une entreprise abominable