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.
jmull · 14h ago
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 · 12h ago
> 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.
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.
dcow · 7h ago
I think modernity has complicated things. The proprietary vendor signing all the binary components to prevent tampering is different from the platform package manager and kernel requiring signed packages/pages. If you have the proprietary blob and a bunch of modified third party dynamically loaded components, you (or the platform) can re-generate your own signature over the modified composition to execute it in {context that requires signed code execution for security/integrity}. The LGPL is addressing the former. I don’t see a spirited problem with the latter.
roblabla · 13h ago
> 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 · 12h ago
Doesn't that mean the anti-tivoization clause makes LGPL3 software unusable on most mobile platforms since they're all fixated on signing libraries?
notpushkin · 7h ago
I don’t think so, at least on Android. If you replace a library in an app, you just sign it with your own keys.
voakbasda · 13h ago
> 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.
socalgal2 · 7h ago
Plenty of projects intentionally stay on older GPL licenses because they want that permissiveness.
jsiepkes · 14h ago
> 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 · 14h ago
> 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 · 6h ago
"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 · 14h ago
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'
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 · 14h ago
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.
Maxatar · 13h ago
>at least object files and infrastructure so that i can relink my changed LGPL code to your application.
This part is true but I'd like to emphasize that the infrastructure is on the user to acquire. The distributor of the application is not required to make that infrastructure available.
jcelerier · 4h ago
no, it is. it's explicitly mentioned that the distributor has to provide for instance build instructions.
> The “Corresponding Application Code” for a Combined Work means the object code and/or source code for the Application, including any data and utility programs needed for reproducing the Combined Work from the Application, but excluding the System Libraries of the Combined Work.
> If you use option 4d0, the Installation Information must accompany the Minimal Corresponding Source and Corresponding Application Code. If you use option 4d1, you must provide the Installation Information in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
The only thing you don't have to provide is e.g. the platform toolchain, headers, etc. e.g. you don't have to ship Windows.h and cl.exe if you are making a windows app that comes with an LGPL library.
em-bee · 12h ago
i am not sure about that. isn't it required that i get everything needed to rebuild the application? if it's a standard compiler, sure. but any config files, nonstandard tools to link, say if the non-LGPL part is written in an inhouse language with a non-public compiler and linker, you still need to give me the tools to relink the objects. i mean that's very unlikely to happen, but if it does, those tools need to be shared.
Maxatar · 11h ago
Yes that's true, if it's a non-public compiler, linker, operating system, or whatever... then the source code for all of those need to be provided.
em-bee · 7h ago
not the source code, but binaries that can run on the same target machine.
Maxatar · 6h ago
The license specifies that it must be the source code. Binaries are not sufficient.
em-bee · 5h ago
are you sure? how is that supposed to work if i build an application with a compiler that i don't have the source for? even for a pure GPL program that can't be a requirement. LGPL requires object files for the non-LGPL parts to allow relinking, but it requires the source for the tool that does the relinking? that doesn't make much sense to me.
LegionMammal978 · 4h ago
From section 1 of the GPLv3:
"The 'Corresponding Source' for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work."
The LGPL refers to the GPL by reference. I don't think the intent is to recursively require the source code of the entire universe. But the definition of "System Libraries" is somewhat vague, and the undefined term "general-purpose tools" is even vaguer. Would, say, MSVC be a "general-purpose tool", even though it arguably isn't a "generally-available free program"? (And which "free" are they using here?) I can see why many legal teams would be wary, at least.
thegrim33 · 8h ago
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 · 6h ago
> 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.
belorn · 7h ago
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.
kelnos · 8h ago
> 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.
dcow · 7h ago
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 · 5h ago
> 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 · 12h ago
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:
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 · 15h ago
>> 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.
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.
jcelerier · 4h ago
this is not an additional requirement, this is another way to apply the core requirement of the LGPL to the static linking case in C, which is: the end-user must be able to patch / replace the LGPL parts of the app.
Epa095 · 14h ago
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.
And is this easy? I don't know much about how this works, but would it be trivial for unity to distribute a version of unity with statically linked LGPL libraries where you can also easily relink?
Maxatar · 13h ago
It's as easy as building the project in the first place. Anytime you build your application you also build the object files for it as well.
As an end user having to take those object files and relink them can be difficult for sure, but that's not something the distributor has to do. The distributor simply has to provide some additional files that their build process will already produce.
Sophira · 11h ago
Of course, those build files won't be stripped, meaning that it would be easier to reverse-engineer them - which might not be something the distributor wants.
jcelerier · 4h ago
? there's nothing that prevents to call strip on .o files
voxic11 · 14h ago
I wouldn't call it completely trivial at the scale and complexity of something like unity, but its certainly possible.
phkahler · 13h ago
In practice it's probably easier to dynamically link the library.
arka2147483647 · 13h ago
I think you would find it very difficult to find even a single game which has done this.
zoobab · 15h ago
"but Unity uses LGPL assets themselves."
So Unity will ban itself?
armada651 · 15h ago
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 · 15h ago
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.
No comments yet
NoahKAndrews · 13h ago
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 · 13h ago
(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 · 13h ago
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 · 12h ago
What does this mean? What harm does it do?
jdbernard · 11h ago
The harm I imagine would be the reputation damage from people believing that "they are intentionally trying to mislead people into thinking that they are the developers of VLC." NoahKAndrews, having been informed that these really are the devs of VLC, is hoping his earlier, uninformed statement did not cause too many people to think poorly of VideoLabs.
TheAmazingRace · 13h ago
I love this model! Love what you guys do, and please keep up the good work.
Ragnarork · 13h ago
> 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 · 13h ago
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
I guess the project is well-aware of the corporation.
NoahKAndrews · 13h ago
Just discovered some of that myself, I'm glad everything's on the up-and-up.
spyder · 13h ago
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 · 13h ago
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 · 56m ago
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 · 14h ago
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 · 13h ago
> 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.
kmeisthax · 11h ago
> 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 · 14h ago
No, you're right. Here's the best "article" I can find about this at the moment:
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.
They can't upgrade bash past 3.2 (which is the last GPLv.2 release), so they're maintaining an ancient version themselves (it's old enough to smoke + vote + go to war in the US!), and they're trying to get users to switch to zsh.
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):
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.
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.
> 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 · 15h ago
Looks like it was moved into the "Submission Guidelines 1.2.b" linked from 5.10.1:
The relevant email is even dated 31st of August 2023.
minima · 14h ago
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 · 15h ago
Unity again showing their hostility. Perma-banning developers for this reason is crazy.
TheRealPomax · 14h ago
Not so much "again" as "before they doubled down and went full unity". This happened before the "per install" fees, in August of 2023.
pnw · 5h ago
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 · 16h ago
No surprise here. Unity is such a horrible company.
I don't know if VLC itself is even legal in countries that enforce software patents.
99nala · 13h ago
We moved away from Unity a few years ago when they introduced their updated licensing plan. I believe they backtracked on it almost immediately but we are still happy with our decision.
bartvk · 13h ago
If not home-grown, where did you move to?
Fokamul · 7h ago
Only madman would develop anything with Unity after last fiasco.
jillyboel · 15h ago
Unity is actually permanently banning accounts for uploading a package that they decree has now been deprecated? What are they smoking?
mcv · 13h ago
Yeah, it feels to me like there's some other reason they dislike VLC that they're not telling. Does it compete with their own media player or something? Did the creator of VLC date a Unity exec's ex?
simoncion · 8h ago
> ...for uploading a package that they decree has now been deprecated?
Unity appears to be using the term "deprecated" to mean "removed" or "deleted". This is a fucking stupid trend that I wish we would collectively push through, but we're not quite there yet.
My interpretation of the memo from Unity is that they have deleted the VLC library from the Unity Store and have permanently banned the VLC group's Unity Store account for violation of the terms of the contract with Unity.
Corpo jargon can be difficult to understand. (This might be the primary purpose of corpo jargon.)
ttoinou · 16h ago
I’ve read a bit this post and the gitlab repo link but I still have no idea if it’s about having a VLC desktop player playing Unity assets / games, or a plugin for Unity to have a little VLC player inside the games.. or something else ?
bayindirh · 16h ago
It's more like allowing VLC media player inside the games, maybe as a cutscene player, or playing media via a control which players can interact with inside the game.
I believe the gem lies in this sentence: "allowing (you) to build your own media-player based on VLC technology in Unity-based games".
Telemakhos · 16h ago
> The integration essentially was a bridge between the Unity game engine and the VLC multimedia engine, allowing to build your own media-player based on VLC technology in Unity-based games.
giancarlostoro · 12h ago
Every time I think about using Unity they remind me why I'm right in preferring something fully open source that isn't gate keeping my use of it.
m3kw9 · 16h ago
They removed someone’s entire app and they say “sorry for the inconvenience”
mystified5016 · 13h ago
Sure would be a shame if someone went through the unity store and reported every single LGPL asset to Unity legal.
globalnode · 14h ago
did your app threaten their advertising network or revenue perhaps?
actinium226 · 14h ago
Can the link please be updated to note that this is from 2024?
msie · 11h ago
Ugh.
doctorpangloss · 12h ago
Unfortunately for these guys, even if they have come up with the right solution - their own store - it doesn’t matter from the POV of commercial success. Right solutions are often NOT financially successful.
mschuster91 · 15h ago
> After months of slow back-and-forth over email trying to find a compromise, including offering to exclude LGPL code from the assets, Unity basically told us we were not welcome back to their Store, ever. Even if we were to remove all LGPL code from the Unity package.
It's high time the EU clamps down on Unity as well and classifies them as a gatekeeper. This behavior is absolutely unhinged.
shmerl · 4h ago
Another reason for people to ditch it and use Godot.
jasonlotito · 15h ago
It is amazing to me the commentary confusing GPL and LGPL on this site. The misinformation being spread about the LGPL, or just assuming the LGPL is the same as the GPL is mind boggling. I can't be to surprised, I guess. GPL happens after the L, and of course, we know GPL "doesn't allow commercial applications" right? So that's all we need to discuss.
Seriously, it's just four characters, and doesn't take long to look up without just assuming it's the same as the GPL.
The argument "the lawyers saw GPL in LGPL and just made an assumption" is all the more plausible when you have people in the field who make the same mistake.
kragen · 15h ago
The GPL does allow commercial applications. That's how we got Linux, nearly every embedded board support package ever, etc.
jasonlotito · 14h ago
I should have been more explicit by making it clear that part was sarcasm based on the comments I'm seeing elsewhere on this post. Apologies.
kragen · 57m ago
Sorry, I probably should have given the quotation marks more weight.
WesolyKubeczek · 14h ago
I remember that VLC could not get into iOS App Store for the same reason, and the story about it was spun by everyone and their dog. Ffmpeg is there because it doesn’t have this kind of PR, and that’s it.
Reason077 · 14h ago
Different issue. The App Store controversy was because VLC was, back in 2011, licensed under the GPL. One of the VLC developers complained to Apple that the GPL license was incompatible with the App Store distribution model, so it was pulled.
The engine parts of VLC were subsequently relicensed under LGPL-2.1, and the rest of the app under MPL.
VLC has been back on the App Store since 2013.
mouse_ · 16h ago
Big companies hate GPL
No surprise here
diggan · 16h ago
But they still use libraries under GPL themselves:
> It gets better… Unity itself, both the Editor and the runtime (which means your shipped game) is already using LGPL dependencies! Unity is built on libraries such as Lame, libiconv, libwebsockets and websockify.js (at least). Full list of open-source Unity dependencies here.
So what they hate seem to be "publishers and Unity users using GPL libraries", not using it themselves.
kragen · 15h ago
Those libraries are under the LGPL, not the GPL, which is a huge difference in this context.
Dylan16807 · 14h ago
I'm assuming mouse_ was including LGPL when they said GPL because otherwise their comment has nothing to do with the article.
kragen · 2h ago
They are very different licenses, so their comment has nothing to do with the article, which is what I was pointing out. Including the LGPL in a comment about the GPL makes as much sense as including Switzerland in a comment about Sweden. It's an easy mistake to make if you aren't very familiar with them, but it's still a mistake, and one which leads you to nonsensical conclusions if you don't correct it.
diggan · 14h ago
Ah, you're very right, I misread it somehow when I first came across it... Thanks for the correction!
kragen · 1h ago
It's an easy mistake to make!
zorgmonkey · 13h ago
libVLC the library is LGPL licensed, VLC the application is GPL licensed. This plugin was of course just using libVLC so it being GPL was not the issue. As you said several other libraries unity uses are also LGPL licensed.
kragen · 1h ago
Thank you for the explanation! If I knew that, I had forgotten.
HenryBemis · 16h ago
Nothing wrong to use someone else's work to make money for yourself.
Plenty wrong to use someone else's work to make money for others.
Oversimplification I know.. but.. right?
The Ferenghi would be proud of Unity!
bitmasher9 · 16h ago
GPL/LGPL is more about treating users fairly than not making money. It’s just that most software companies exploit their users to various degrees.
matheusmoreira · 16h ago
Open source is just the transfer of property and capital from well meaning developers straight into the pockets of corporations and billionaires. Developers are well advised to always apply the AGPLv3 to everything they make. It's either AGPLv3 or all rights reserved, everything in between makes no sense.
> To the Beggar Baron, open source's value is its free donation.
> You would never stand on the street and offer to buy the wallets off people who are about to donate a few dollars to you.
> That'd be stupid. They're giving you their money for free. Take it and run.
kragen · 15h ago
Your comment makes no sense: first it attacks “open source” with derogatory language, then it strongly recommends using a certain open-source license, and then it returns to attacking “open source” with derogatory language pasted from a clueless blog post by a plonker renowned for his clueless rants.
Dylan16807 · 14h ago
It makes sense when you add the fact that 99% of open source is not AGPL. Criticizing "open source" is slight hyperbole.
kragen · 1h ago
If there's something wrong with open source software as a class, that thing would almost certainly have to be wrong with the AGPL as well, since it's a central example of the class of open source licenses, and, contrary to your comment, one of the most popular ones. If it's an exception to the generalization, you need to explain why.
So it isn't "slight hyperbole". It's utter incoherence.
matheusmoreira · 14h ago
Free software and open source software are not the same. AGPLv3 is not an open source license, it is the strongest copyleft free software license available at this point in time.
It's not that no begging ever happens. It's just that you're saying that "open source is just the transfer of property and capital" and it isn't.
tempfile · 16h ago
It's the LGPL, not the GPL. Huge difference.
badgersnake · 16h ago
This is about the LGPL, which is a very different licence. I’ve not heard of it causing any problems. Glibc is licensed in this way, everything uses that.
kragen · 15h ago
The LGPL is a very different license, but glibc is not licensed under it, nor under the GPL.
pmontra · 14h ago
It's got a number of different licenses for it's various components. LGPL 2.1 is among them.
I appreciate the correction. It looks like specifically the long double libm functions (things like extended precision square root and logarithm) and the DES implementation from SSLeay are licensed under the LGPL? That seems to conflict with badgersnake's link https://www.gnu.org/software/libc/#license
Not trying to play devils advocate, but it goes both ways. There are proprietary libraries in a lot of solutions too. The LGPL is under many distributed closed solutions that are sold for profit, so I think its WEEE bit of the kettle calling .. ya you get it. I don't want to turf war, but its more systemic than you probably think. In this case, its just the pry-bar used that the risk to blow up the entire community of developed software with open libraries.
Tread lightly maybe.
Dylan16807 · 14h ago
What goes both ways? Everyone involved is fine with proprietary libraries being used.
> The LGPL is under many distributed closed solutions that are sold for profit, so I think its WEEE bit of the kettle calling .. ya you get it.
No, I don't get it. The LGPL allows that and they're happy with it. Where are you seeing hypocrisy?
No comments yet
zigzag312 · 16h ago
I find popularity of LGPL licenses a bit weird.
Allows:
- Commercial use of the software
- Commercial use of the source code for projects that run on the company's servers or internally
- Commercial use of the library is allowed if dynamically linked
Blocks:
- Commercial use of the source code for local apps that run on user's device
- Commercial use of the library if statically linked for local apps that run on user's device
I would expect a licence like MPL to be more popular than LGPL.
vinceguidry · 15h ago
The GPLs don't concern themselves with commercial use. You can use GPL-licensed software for any application you wish, that is what software freedom means. It's just that if you do use copylefted free software, you must provide, free of charge, the source code of the software using it and any modifications made.
zigzag312 · 15h ago
If you run things on the servers/cloud (excluding more recent AGPL) you don't need to provide any source code.
lupusreal · 15h ago
If this weren't the case, then every web server running linux would have to offer their users the source code to linux. Seems pretty silly, probably most software shouldn't be AGPL.
AGPL is best used by projects that want to offer dual licensing for a fee, so they can get corporations to fund their development.
tmtvl · 15h ago
Most software probably should be AGPL licensed and its use is best for projects who want to protect what ought to be basic human rights which unfortunately aren't enshrined in law.
lupusreal · 11h ago
Oh give me a break. What basic human rights are being violated by Linux being licensed with the GPL? GPLv3 would be a nice improvement, but human rights violations for it not being AGPL??
Dylan16807 · 14h ago
I'm not a huge fan of AGPL but I think being "silly" is the least of my worries. A few redundant github links on the about page is a small cost for getting open source to stay actually open in the era of cloud services.
I do agree that it's "best" used in that kind of dual licensing, but I wish companies were less allergic to it so it could be used in general purpose ways. (It or a lawyer-friendly alternative.)
lolinder · 15h ago
The FSF has a whole article on why you'd choose GPL or LGPL [0]. In general they agree with you that LGPL is overused, but they do identify a few reasons why you might choose LGPL.
That said, if the other option is something like MPL then I can think of a number of reasons why LGPL is better. At least LGPL ensures that modifications to your library itself remain free, whereas a more permissive license allows changes to be locked up entirely in a proprietary fork.
Doesn't MPL require to release any modifications made to the library itself?
lolinder · 15h ago
Oh, yes, I missed that! You're correct.
It's still more permissive than LGPL in that it isn't 'infectious' even when statically linked, the license only applies to the source file, not to any derived work. That makes the requirements more straightforward but does limit the freedom of the user to dynamically swap the library out for one that they'd prefer.
kragen · 15h ago
Not if you put them in a new source code file, no.
jenadine · 15h ago
You're confusing "commercial" and "proprietary".
Also LGPL doesn't block static linking with proprietary software, it just want that you allow the end user to replace the library with a modified version, and there are several ways to allow it.
stackedinserter · 13h ago
"just"
jeroenhd · 15h ago
LGPL is pretty much the license for "if you use my code, you must also provide your customers a source copy of the same license, but if you ship a binary just let people know so they can ask me for the source".
Users get the benefit of not having to keep a source code archive for compiled libraries every release, but still apply GPL restrictions and rights if you decide to copy code from within the library.
If your customer is internal, that's not a problem. But realistically, internal tooling may as well be based on pirated and stolen code. How would anyone even find out?
I think it has its charms. You can use the library as-is and everyone who cares can find the source code elsewhere (it's probably on github somewhere anyway), but you can't take it as a basis and alter it to make your own project out of it without keeping the product open.
In the modern "everything requires HTTP calls to the network" era of software, AGPL may be a better solution for making sure the source code remains open, but for old-fashioned on-device apps there's a nice balance between freedom and obligations.
No comments yet
freeone3000 · 15h ago
The freedom it was intended to preserve was the ability to modify the library and replace it, having your changes reflected in the application. Static linking breaks that freedom.
zigzag312 · 15h ago
Maybe that's why web apps have become more prevalent?
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.
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).
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.
https://www.gnu.org/licenses/gpl-faq.html
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.
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.
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.
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.
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.
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.
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'
"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."
This part is true but I'd like to emphasize that the infrastructure is on the user to acquire. The distributor of the application is not required to make that infrastructure available.
> The “Corresponding Application Code” for a Combined Work means the object code and/or source code for the Application, including any data and utility programs needed for reproducing the Combined Work from the Application, but excluding the System Libraries of the Combined Work.
> If you use option 4d0, the Installation Information must accompany the Minimal Corresponding Source and Corresponding Application Code. If you use option 4d1, you must provide the Installation Information in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
The only thing you don't have to provide is e.g. the platform toolchain, headers, etc. e.g. you don't have to ship Windows.h and cl.exe if you are making a windows app that comes with an LGPL library.
"The 'Corresponding Source' for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work."
The LGPL refers to the GPL by reference. I don't think the intent is to recursively require the source code of the entire universe. But the definition of "System Libraries" is somewhat vague, and the undefined term "general-purpose tools" is even vaguer. Would, say, MSVC be a "general-purpose tool", even though it arguably isn't a "generally-available free program"? (And which "free" are they using here?) I can see why many legal teams would be wary, at least.
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.
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.
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.
If you’re not pushing an agenda, you have the public domain or the unlicense as options completely simple understandable options.
I don't think it is so much as many people mistaking their beliefs for facts.
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.
That requires the library to be dynamically linked. Not sure if that's in play here.
> 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.
As an end user having to take those object files and relink them can be difficult for sure, but that's not something the distributor has to do. The distributor simply has to provide some additional files that their build process will already produce.
So Unity will ban itself?
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.
I used to work there, proud of their technical accomplishments, ashamed of pretty much everything else.
No comments yet
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.
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.
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.
Additionally, Videolabs is listed at https://www.videolan.org/videolan/partners.html
I guess the project is well-aware of the corporation.
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.
I'm mainly using Godot now and it's nice but it just doesn't quite compare.
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?
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.
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.
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:
They can't upgrade bash past 3.2 (which is the last GPLv.2 release), so they're maintaining an ancient version themselves (it's old enough to smoke + vote + go to war in the US!), and they're trying to get users to switch to zsh.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.
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.
https://assetstore.unity.com/publishing/submission-guideline...
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.
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.
Unity appears to be using the term "deprecated" to mean "removed" or "deleted". This is a fucking stupid trend that I wish we would collectively push through, but we're not quite there yet.
My interpretation of the memo from Unity is that they have deleted the VLC library from the Unity Store and have permanently banned the VLC group's Unity Store account for violation of the terms of the contract with Unity.
Corpo jargon can be difficult to understand. (This might be the primary purpose of corpo jargon.)
I believe the gem lies in this sentence: "allowing (you) to build your own media-player based on VLC technology in Unity-based games".
It's high time the EU clamps down on Unity as well and classifies them as a gatekeeper. This behavior is absolutely unhinged.
Seriously, it's just four characters, and doesn't take long to look up without just assuming it's the same as the GPL.
The argument "the lawyers saw GPL in LGPL and just made an assumption" is all the more plausible when you have people in the field who make the same mistake.
The engine parts of VLC were subsequently relicensed under LGPL-2.1, and the rest of the app under MPL.
VLC has been back on the App Store since 2013.
No surprise here
> It gets better… Unity itself, both the Editor and the runtime (which means your shipped game) is already using LGPL dependencies! Unity is built on libraries such as Lame, libiconv, libwebsockets and websockify.js (at least). Full list of open-source Unity dependencies here.
So what they hate seem to be "publishers and Unity users using GPL libraries", not using it themselves.
Oversimplification I know.. but.. right?
The Ferenghi would be proud of Unity!
https://zedshaw.com/blog/2022-02-05-the-beggar-barons/
> To the Beggar Baron, open source's value is its free donation.
> You would never stand on the street and offer to buy the wallets off people who are about to donate a few dollars to you.
> That'd be stupid. They're giving you their money for free. Take it and run.
So it isn't "slight hyperbole". It's utter incoherence.
https://www.gnu.org/philosophy/open-source-misses-the-point....
https://www.gnu.org/philosophy/words-to-avoid.html
And it's hard to disagree with the clueless guy when what he says is happening keeps happening.
https://twitter.com/FFmpeg/status/1775178803129602500
https://twitter.com/FFmpeg/status/1775178805704888726
https://trac.ffmpeg.org/ticket/10341#comment:4
It's not that no begging ever happens. It's just that you're saying that "open source is just the transfer of property and capital" and it isn't.
License file at https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=LICEN...
Source at https://sourceware.org/git/?p=glibc.git;a=summary
Tread lightly maybe.
> The LGPL is under many distributed closed solutions that are sold for profit, so I think its WEEE bit of the kettle calling .. ya you get it.
No, I don't get it. The LGPL allows that and they're happy with it. Where are you seeing hypocrisy?
No comments yet
Allows:
- Commercial use of the software
- Commercial use of the source code for projects that run on the company's servers or internally
- Commercial use of the library is allowed if dynamically linked
Blocks:
- Commercial use of the source code for local apps that run on user's device
- Commercial use of the library if statically linked for local apps that run on user's device
I would expect a licence like MPL to be more popular than LGPL.
AGPL is best used by projects that want to offer dual licensing for a fee, so they can get corporations to fund their development.
I do agree that it's "best" used in that kind of dual licensing, but I wish companies were less allergic to it so it could be used in general purpose ways. (It or a lawyer-friendly alternative.)
That said, if the other option is something like MPL then I can think of a number of reasons why LGPL is better. At least LGPL ensures that modifications to your library itself remain free, whereas a more permissive license allows changes to be locked up entirely in a proprietary fork.
[0] https://www.gnu.org/licenses/why-not-lgpl.en.html
It's still more permissive than LGPL in that it isn't 'infectious' even when statically linked, the license only applies to the source file, not to any derived work. That makes the requirements more straightforward but does limit the freedom of the user to dynamically swap the library out for one that they'd prefer.
Users get the benefit of not having to keep a source code archive for compiled libraries every release, but still apply GPL restrictions and rights if you decide to copy code from within the library.
If your customer is internal, that's not a problem. But realistically, internal tooling may as well be based on pirated and stolen code. How would anyone even find out?
I think it has its charms. You can use the library as-is and everyone who cares can find the source code elsewhere (it's probably on github somewhere anyway), but you can't take it as a basis and alter it to make your own project out of it without keeping the product open.
In the modern "everything requires HTTP calls to the network" era of software, AGPL may be a better solution for making sure the source code remains open, but for old-fashioned on-device apps there's a nice balance between freedom and obligations.
No comments yet