Unity’s Open-Source Double Standard: the ban of VLC
151 comments
·May 7, 2025jdlyga
jmull
I don't know much about the way unity apps are distributed, but I'd be a little surprised if they are only intended to be distributed in a way that satisfies LGPL.
I would have thought, e.g., that apps distributed only through stores to platforms that require apps to be signed could not contain LGPL components, since you would not be able to modify the LGPL components. (Maybe it would be OK if the software was available for download freely and side loading wasn't too difficult??? IDK.)
Legal specifics aside (IANAL after all), my general point is that despite being more flexible than full GPL, LGPL is still pretty restrictive. Proprietary software generally may need to keep things simple or be careful (probably including consulting an attorney with the relevant expertise) to ensure they are compliant.
In that light, I can see why Unity would disallow LGPL software. It's not that it couldn't be done properly, but that it's probably not feasible to do a proper legal review of every asset added to the sure (not for Unity and not for the asset providers).
giancarlostoro
> require apps to be signed could not contain LGPL components, since you would not be able to modify the LGPL components.
You COULD make the changes, but you MUST keep the changes to the LGPL'd software made available in some way. This is not going to affect the rest of your project, only the LGPL'd library. I think not including any private keys or signed files will still satisfy the LGPL as long as any code changes you made are included. I don't think configuration that compromises your security is within scope, and I'd feel like RMS would agree there.
Its really interesting the goal of the LGPL is to allow for LIBRE libraries to exist where there's proprietary components that already do a solid job, so in order to convince people to use GPL / LGPL tools / libraries it was thrown in that umbrella.
The FAQ is worth a read every now and then, you get a feel for what is intended in plain English.
dwaite
I believe the GP is referring to the LGPL requirement that users be able to replace LGPL components with modified versions.
Being able to replace subsystems of a signed application with arbitrary third party code adds complexity and is a security risk, but is a requirement of the LGPL.
roblabla
> I would have thought, e.g., that apps distributed only through stores to platforms that require apps to be signed could not contain LGPL components, since you would not be able to modify the LGPL components. (Maybe it would be OK if the software was available for download freely and side loading wasn't too difficult??? IDK.)
IIRC, That's a difference between LGPLv2 and LGPLv3 - LGPLv3 has the same anti-tivoization clauses that GPLv3 has - while LGPLv2 does not. So afaict, it's totally OK to distribute software in ways that does not allow the user to modify the library when that library is licensed LGPLv2.
VLC is licensed under LGPLv2.1, which is not subject to the tivoization clause.
Pxtl
Doesn't that mean the anti-tivoization clause makes LGPL3 software unusable on most mobile platforms since they're all fixated on signing libraries?
voakbasda
> So afaict, it's totally OK to distribute software in ways that does not allow the user to modify the library when that library is licensed LGPLv2.
Legally that might be true, but that interpretation stands directly opposed to the intention of the license. In that light, it is unambiguously unethical to use that loophole.
jsiepkes
> The LGPL is specifically designed to allow proprietary applications to link to open-source libraries without requiring the proprietary application’s source code to be released, provided certain conditions are met.
It's not that simple. The LGPL says that one must basically be able to make modifications to the opensource library, rebuild the library and be able to reintegrate this new library in the existing application. And you, as a developer using an LGPL library, need to make this "possible". What this practically means, is open to interpretation. This is also why lawyers (and companies) don't like the LGPL, because it contains even more of this "open to interpenetration" text than the GPL.
nightpool
> What this practically means, is open to interpretation.
Is it? It seems very straightforward to me—just use a DLL. The LGPL even says explicitly that it's fine as long as you use a shared library.
The situation gets trickier for Android or Xbox games I guess. I'm curious how Unity complies with the LGPL provisions there. But for any normal desktop platform this should be trivial to comply with.
EDIT: ah, upthread they mention this is only a provision for the LGPLv3. I would expect that the LGPLv3 is pretty rarely used for this reason.
reverius42
"Just use a DLL"
Like you say, it gets trickier for Android, or Xbox games, or...
iOS, which requires each library binary to be signed by the publisher, or...
Rust or Go, which encourage static linking of all dependencies...
These days a "normal desktop platform" is really a minority of software.
torginus
Afaik not necessarily. You migh make modifications to the LGPL library (such as changing the API) and then use that in your proprietary app.
Although the modified library would still be LGPL, it would be both practically useless to everyone on the street, and unfortunately the (L)GPL doesn't even specify how you must share the source. It's perfectly legal to say 'send us a request and we email you the modified sources'
Scaevolus
No. Read the license. https://www.gnu.org/licenses/lgpl-3.0.en.html
"4. Combined Works.
You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following:
- d) Do one of the following:
-- 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
-- 1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version."
em-bee
if your application contains LGPL code then as a user of your application i must be able to make changes to that LGPL code. that means i need either the code of the whole application or at least object files and infrastructure so that i can relink my changed LGPL code to your application.
thegrim33
Every thread about software licenses always devolves into a firehose of debate and conflicting beliefs. How, in 2025, are we still in a state where, on HN of all places, nobody has any idea what the specifics of LGPL really means or how it has to be implemented? How is it so convoluted, confusing, and up to interpretation?
There's demonstrably room for innovation here - coming up with some new system that actually makes sense, that people can actually understand. I suppose there's licenses like MIT that fall in that bucket. Everyone is pretty clear about something like the MIT license. But the various GPL licenses and other, more custom/convoluted licenses ideally need to be replaced by something much better.
nightpool
> Everyone is pretty clear about something like the MIT license
I don't think this is really true. I think people are often upset or surprised when their MIT-licensed programs are used in ways they don't agree with, or they reuse MIT-licensed programs in ways that violate their license terms (e.g. it takes many companies many, many years to realize they have to actually include a way for users to view copyright notices).
Open source software is built on many different fuzzy notions of community and collaboration, encoded into an imperfect-but-legally-robust set of protocols that try to establish common language for people to build on. These protocols have proven very, very successful in encouraging collaboration and minimizing exploitation, but there's still a regularization/compromise process that's necessary so that everybody has a common ground to work from.
For another perspective, think about them like security software—I personally might not know why TLS uses DH key exchange, or how it works, but if I threw it out in hopes of making thing simpler, things would probably go pretty badly for me when someone else notices.
kelnos
> But the various GPL licenses and other, more custom/convoluted licenses ideally need to be replaced by something much better.
What, though? I expect that people with a greater understanding of copyright law and how to write legal documents, have tried and failed. The GPL, LGPL, the Affero variants have specific goals around keeping software open. I don't think writing a license to achieve those goals can be simple or straightforward.
belorn
That is legaleze for you, and it not at all surprising that we are still discussing how such a text should be interpreted. Its mostly impossible to create a legal text that has unchanged interpretation for several decades, or centuries for that matter. Just look how courts often discussion the interpretation and enforcement of specific laws, even laws that are older than the judges themselves.
dcow
It’s because the genesis of these convoluted license terms is rooted deeply in the archaic copyright law in the US. Until that is fixed, these legal hacks will be necessary.
If you’re not pushing an agenda, you have the public domain or the unlicense as options completely simple understandable options.
JCattheATM
> How is it so convoluted, confusing, and up to interpretation?
I don't think it is so much as many people mistaking their beliefs for facts.
ack_complete
That Unity itself or Unity-based games use LGPL components doesn't matter. What matters here is what is allowed on the Unity Asset Store. There is nothing requiring Unity to allow everything on their Asset Store that could be linked into a Unity game, and apparently at the time, the Provider agreement simply said: you can't sell LGPL assets on the store.
It isn't surprising or unreasonable that the Store might have additional requirements, and there are plenty of reasons to do so. One is Unity limiting their risks as a distributor of third-party content. Another is that the Unity Asset Store does not require assets sold to be used with Unity, and for some assets it can be allowed depending on the specific asset's license:
https://support.unity.com/hc/en-us/articles/34387186019988-C...
On the other hand, not enforcing the LGPL rule evenly against other assets also currently being distributed with LGPL components, on the other hand, is more problematic.
phkahler
>> The LGPL is specifically designed to allow proprietary applications to link to open-source libraries without requiring the proprietary application’s source code to be released, provided certain conditions are met. This is particularly true when the LGPL-licensed library is used in a way that allows users to modify or replace it independently of the proprietary application.
That requires the library to be dynamically linked. Not sure if that's in play here.
jcelerier
voxic11
It doesn't strictly require it to be dynamically linked but does place additional requirements on applications which are statically linked to LGPLed libraries.
> If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
Epa095
This is the relevant part:
>If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
zoobab
"but Unity uses LGPL assets themselves."
So Unity will ban itself?
armada651
As the devil's advocate I'd like to argue that legal is probably more comfortable with Unity's own use of LGPL libraries, because they can ensure that Unity only links dynamically to those libraries. And given how critical these dependencies are to the engine, legal is willing to take the "risk" of allowing LGPL dependencies.
The ban of LGPL in assets on the asset store is probably due to legal being concerned that someone would publish an asset that statically links to an LGPL library and that it would allow anyone to demand the source/object code of any Unity game that uses that asset.
Legal probably sees it as too much effort to vet every asset to see if it links correctly to LGPL libraries and simply instituted a blanket ban to simplify enforcement.
firtoz
Unity's lawyers continue killing the company, not a big surprise there.
I used to work there, proud of their technical accomplishments, ashamed of pretty much everything else.
AIoverlord
[dead]
NoahKAndrews
Edit: nevermind, they are in fact affiliated, and most of the core VLC devs work at VideoLabs. I've kept the original comment below.
This blog post links to the "VideoLab Store", hosted at https://videolabs.io, which prominently uses a logo extremely similar but not identical to the VLC (which stands for VideoLAN, not VideoLab) logo. Their homepage even goes as far as displaying "Hire the VLC team" as its headline.
As far as I'm aware, VideoLab has nothing to do with the VideoLAN non-profit, and it very much seems like they are intentionally trying to mislead people into thinking that they are the developers of VLC.
jbk
(President of VideoLAN here).
So far, VideoLabs is hiring most of the VLC core developers and those people are the main force of development of VLC. It's setup this way so that if the Videolabs company does not live forever, VLC stays forever free, and the non-profit lives.
This is quite classic of open source projects, and in the case of VideoLAN, there are 3 or 4 companies doing consulting.
NoahKAndrews
Very cool, that definitely makes sense! I've edited my comment, apologies for that. Hopefully bringing attention to the fact that you guys are easily available for hire ends up doing more good than harm.
squigz
What does this mean? What harm does it do?
TheAmazingRace
I love this model! Love what you guys do, and please keep up the good work.
Ragnarork
> As far as I'm aware, VideoLab has nothing to do with the VideoLAN non-profit
VideoLabs is a company which has been founded by one of the creators of VLC/VideoLAN and president of the VideoLAN non-profit.
It's basically a for-profit that hired/employs most of the VLC main contributors and pay them a salary to work on that ecosystem while providing consulting and other services to finance all that.
They are significant contributors to the VLC codebase.
After having worked with them in the context of a partnership, I can add that "for-profit" is mostly the legal form but not the mindset.
bionade24
Well, the author does have a link to the git forge of the VideoLAN project prominently displayed on the blog and also contributes to projects there: https://code.videolan.org/videolan/LibVLCSharp
Additionally, Videolabs is listed at https://www.videolan.org/videolan/partners.html
I guess the project is well-aware of the corporation.
NoahKAndrews
Just discovered some of that myself, I'm glad everything's on the up-and-up.
spyder
From their about page:
Videolabs was born from the VideoLAN community and started by maintaining the VLC ports on mobile. It is now the main contributor to VLC, hiring its historical developers, and building custom solutions around the VLC and FFmpeg ecosystems.
paulbgd
The CTO is the president of the VideoLAN non-profit, so it seems accurate. Supposedly from their about page they’re the primary maintainers of vlc.
lyntier
I really would like to use Unity for projects. I actually really like the editor, the API and the ability for me to set up a lot of tooling quite easily for people who are not tech-savvy in-editor. Unity just makes it so difficult for me every step of the way with hostile behaviour towards its users, the twenty different beta packages they are Totally Making Stable Next Year, I Swear, the _harshly_ degrading performance on even just empty projects..
I'm mainly using Godot now and it's nice but it just doesn't quite compare.
w4rh4wk5
Please correct me if I am wrong here.
From my understanding, using LGPL v2 code in console releases is fine since v2 does not have a tivoization clause (i.e. even if the end-user cannot re-link the program because the platform is locked down, that's still ok).
However, websockify.js (and perhaps other dependencies) are LGPL v3, which means they cannot be included on a platform like the Nintendo Switch as the end-user cannot replace that component.
Is Unity excluding such components on locked down platforms, or are they simply in violation of LGPL v3?
tzs
> Please correct me if I am wrong here
Will do! :-) The good news is that what you got wrong is something that probably 99% of people get wrong about *GPLv3: the scope of the Tivoization clause.
The Tivoization clause was written quite narrowly to stop what Tivo was doing, which was selling a device with a locked down OS that includes *GPLv3 software. It applies if and only if:
1. the software is conveyed in a "User Product", and
2. that conveyance occurs as part of a transaction in which the right of possession and use of that product is transferred to the recipient.
A "User Product" is defined as 'either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling'.
For the Nintendo Switch it means that Nintendo cannot include any *GPLv3 software in the Switch itself or in anything that comes with the Switch when you buy it.
Add on software that you obtain and install later, including software sold by Nintendo through their online store or on physical media, is not covered by the Tivoization clause. As far as the Tivoization clauses goes there is no problem with Unity including *GPLv3 code for any locked down platforms they use and for any developers who use Unity to write games for those platforms.
Where there might be a problem is with other parts of *GPLv3. For example when software is distributed through app stores such as Apple's or Nintendo's and you buy that software it is Apple or Nintendo that is making and distributing the copy that you download. That's fine because they have permission from the copyright owner.
But to use that app store you usually have to agree to a TOS that prohibits things like redistributing and reverse engineering. That violates *GPLv3. If the owner of the copyright owns the copyright on all the code they used they can grant Apple or Nintendo a license that allows the distribution.
If they have included some third party *GPL library in the app or game and the third party has not granted such a license to the store owner then that app or game cannot be distributed on that store.
pabs3
The GPLv3 does not stop what Tivo actually did, and both GPLv2 and GPLv3 do stop what became known as Tivoization (preventing modification).
What Tivo actually did was break their proprietary software when you modified the GPL parts of the system.
Some related links:
https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t... https://events19.linuxfoundation.org/wp-content/uploads/2017...
kmeisthax
> But to use that app store you usually have to agree to a TOS that prohibits things like redistributing and reverse engineering.
LGPL has it a requirement that the application needs to be distributed in a form where you can replace and modify the LGPL bits. Either via dynamic linking or separately-distributed object files. I'm not sure how you could be considered in compliance with this when the development environment for consoles is an expensive devkit you have to sign an agreement for and the SDK/APIs etc are trade secret. At the very least, I imagine a court would take a very dim view of "well we technically shipped object files in this encrypted container that you can't read or Nintendo will sue you up the ass".
If Unity didn't get an exception license for their LGPL bits, then them and pretty much every indie dev that has shipped on console is violating the license. Bonus points for the fact that the termination clause on *GPLv2 is basically one-strike-and-your-out, so they would have to individually go to each LGPL library Unity touched and beg for forgiveness before ever using those libraries ever again.
On iOS, any iCloud account can get a development profile set up to build and run code signed for your device. And on the App Store you can write custom EULA language that says "any activity required to exercise your rights under LGPL is explicitly allowed, App Store TOS not-withstanding." The biggest problem is just getting access to the object files and assets in order to relink the app. iOS application binaries are encrypted, and app bundles, while not encrypted, are a pain in the ass to get a copy of on a real desktop OS where the developer tools can run. For a fully FOSS app, you can just link to a Git repository to satisfy the GPL copyleft, but I doubt proprietary developers want to distribute a whole unlinked copy of their code just so you can link it in.
There was a problem with VLC on iOS a decade ago, but it mainly has to do with the fact that Apple wants team accounts to be verified with DUNS numbers. VLC is a nonprofit, which apparently made it a pain in the ass to get a DUNS number; but that was fixed a long time ago and VLC is on the iOS App Store.
hedora
No, you're right. Here's the best "article" I can find about this at the moment:
https://opensource.stackexchange.com/questions/7387/what-is-...
(copy paste from a dead link.)
Apple has the same problem as unity. Try this on a mac:
% bash --version
GNU bash, version 3.2.57...
Copyright (C) 2007 Free Software Foundation, Inc.
I looked at the LGPL 2.1, and the "or later" bit of the license is weird. Users can convert it to any version of GPL >= 2.1 at their discretion. However, the author of the library needs to specify LGPL (= any version), LGPL 2.1 (= exactly 2.1), or (recommended) "LGPL 2.1 or later" in a COPYING file.
Unity says they "deprecated" LGPL code. That makes sense unless the code pins the LGPL version. Upstream LGPL vendors could rug-pull them, bash-style, at any moment.
However, VLC's libraries are listed as "LGPL 2.1 only" here, so they explicitly claim they cannot rug pull (unless they jump to GPL3 -- that wouldn't be too surprising, since most of their stuff is AGPL, though it'd probably cause a fork):
https://code.videolan.org/explore/projects/starred
Except VLC didn't incorporate the license properly (COPYING and COPYING.lib don't say if they pin LGPL versions), and their README.md says:
> libVLC, the engine is released under the LGPLv2 (or later) license. This allows embedding the engine in 3rd party applications, while letting them to be licensed under other licenses.
https://code.videolan.org/videolan/vlc
So, Unity's probably right to be worried. "or later" includes v3, which is specifically incompatible with stuff like anti-cheat technology and consoles.
However, my best guess is that Unity's worried about pissing off third parties that have patents on the algorithms VLC implements, and they use the LGPL thing as an excuse to avoid revealing the details of those private deals.
adzm
Interesting 5.10.4 does not seem to exist in the provider agreement? https://unity.com/legal/provider
At one point this used to contain the clause:
> 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.
However this was removed sometime between December 3rd and December 12th according to the Wayback Machine.
axus
Looks like it was moved into the "Submission Guidelines 1.2.b" linked from 5.10.1:
https://assetstore.unity.com/publishing/submission-guideline...
daveoc64
The post is over a year old (January 2024).
red_trumpet
The relevant email is even dated 31st of August 2023.
null
minima
Godot ftw.
Unity is a bad business decision nowadays. If I had to pick something commercial I'd rather pick Epic Games who at least uses lawyers to fight Apple instead of f*ing with open source devs.
tobyhinloopen
Unity again showing their hostility. Perma-banning developers for this reason is crazy.
TheRealPomax
Not so much "again" as "before they doubled down and went full unity". This happened before the "per install" fees, in August of 2023.
null
pnw
I thought most dev stores have prohibitions against GPL and LGPL code like this? Epic's Fab distribution agreement says you can't use LGPL "unless you are merely dynamically linking a shared library" which is obviously impossible for them to enforce and not technically feasible on some gaming platforms.
The Godot store seems to allow LGPLv3 licensed code which is interesting.
Unity themselves using LGPL code isn't related because presumably they can control the way in which it is used, unlike a third party plug-in.
tokai
No surprise here. Unity is such a horrible company.
falcor84
Previous discussion (Jan 2024): https://news.ycombinator.com/item?id=38964972
Clearly, the legal team got bad information and made it part of their agreement. Like the article says, not only do tons of Unity assets use LGPL dependencies, but Unity uses LGPL assets themselves. Even shipped games created using Unity use LGPL assets. The intent was probably only to screen out GPL dependencies. For those who don't know, there's a huge difference between the GPL and LGPL. The LGPL is specifically designed to allow proprietary applications to link to open-source libraries without requiring the proprietary application’s source code to be released, provided certain conditions are met. This is particularly true when the LGPL-licensed library is used in a way that allows users to modify or replace it independently of the proprietary application.
In contrast, the GNU General Public License (GPL) has stricter requirements. If your software incorporates GPL-licensed code, the entire derivative work must also be licensed under the GPL, which includes releasing the source code.