What's the rational for not allowing LGPL code on the unity store? It makes no sense for the ban imho (tho i m not very familiar with unity store's model so i might just be missing something).
They are just being obtuse - which looks fishy when coupled with VLC's claims that they wouldn't allow them back in even if all LGPL code was removed. They probably don't want competition for some component.
But I guess that's another thing they don't want to test in court and it's easier to say they don't want it.
It's easier for them to refuse to be a party to that contract by not allowing any software under that license on their property to begin with.
For example, if you build an app for iOS or visionOS, you have to distribute it via Apple’s stores, and there are technical barriers (code signing, DRM) that get in the way of an end user being able to exercise their right to replace LGPL components with modified versions. I mention this example because there was a big tie up for Unity and visionOS announced with the Apple Vision Pro last summer, but presumably the same applies to Unity games on consoles etc as well.
I can see why from Unity’s perspective it is cleaner to just forbid LGPL entirely, that way it is harder for their customers to mistakenly violate licenses.
I wonder if that is an issue for LGPLv2. Pretty sure that for LGPLv3, the distributor would have to give instructions explaining how to do it (which they could not do), but LGPLv2 does not require that, right?
As in, wouldn't code signing and DRM count as some kind of tivoization?
> 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.
LGPL doesn't impose combined redistribution requirements, does it? They're just tilting against that whole ecosystem specially. And if you apply the same standard as LGPL, MIT/BSD are basically the same right? Probably CDDL falls in too? that's absolutely a crazy thing but it's pretty straightforward in the licensing agreement.
No, no, they got it all wrong:
"not, invented here!"
GPL is a viral license.
The GNU glibc uses LGPL and almost any program run on a Linux system uses glibc, regardless in what programming language it has been written, at least for the system calls. If LGPL had been a viral license too, all programs would have been affected.
> GPL is a viral license.
The LGPL's level of "virality" is small, but nonzero - it imposes requirements on a larger program of which you use LGPL code as a part. Those requirements are much smaller than the requirements imposed by GPL code in the same circumstances, but they are real, and much more substantial than e.g. including a copyright notice.
> The GNU glibc uses LGPL and almost any program run on a Linux system uses glibc, regardless in what programming language it has been written, at least for the system calls.
glibc has an explicit linking exception for programs using its public interface.
Though then it would seem that LGPL libraries on almost any app store are being used against their license terms, so I must be wrong.
I am pretty sure that the Unity executables link dynamically glibc anyway.
The alternative is to do the static linking in 2 steps. First link everything else into a big ELF object file, then do the final linking of the LGPL libraries.
For compliance with the LGPL, it is enough to provide access to the big binary object file, so that a user may relink the possibly modified LGPL libraries, if desired.
A dynamically-linked executable and an object file that needs a final static linking step with additional libraries have almost identical content and they provide equivalent information.
Also for more complicated iOS projects (that require iOS capabilities e.g. in-app-purchase, push notifications, app pay, icloud etc.) end user would need to have a paid apple developer account to create and sign build.
> (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.
it's not a question of terms similarity in that clause, it literally forbids any usage of GPL or LGPL by name. These licenses are "name banned", not just by "features". You can't have GPL or LGPL, nor can you require clients to sublicense you to GPL/LGPL for your program to operate, or any other license that has similar propagating terms to sub-licensed entities.
Obviously you can turn the world on "terms similar", h265 user/device licensing or whatever isn't terms similar here. But just by the plain text it's very obviously a direct swipe at GPL and viral licensing, they're banned by name, at minimum they probably want to see BSD/MIT I guess.
Article isn't wrong that's a crazy-ass term.
You are not wrong. LGPL does require that you provide users the ability to link against a modified version of the LGPL library. It is a requirement that has been rather honoured in the breach in this age of appstores
That's correct for LGPLv3, but I believe LGPLv2 is more nuanced.
With LGPLv2, I don't think it requires that you provide the ability. It has to be possible if you get access to the executable (which may require that you jailbreak your device, for instance). For instance, it is my opinion (not legal advice) that it is fine to use an LGPLv2 Java library in a proprietary Android app, because you can technically go replace the class files corresponding to the LGPLv2 library in your apk. It's not easy to do (unlike swapping a dynamic library), but it is possible.
APKs in the Android app store MUST be cryptographically signed. So, it is impossible.
The only practical solution that an LGPL license provides for Android apps is to fall back to the viral GPL license.
I know there are some apps that do its own cryptographic signature verification on their own, but most apps don't do that, so replacing a LGPL library in an APK is actually feasible in most cases. It is not hard to do so either.
But even then, wouldn't that count like tivoization? LGPLv3 says you need to provide instructions to replace the lib, but LGPLv2 does not. Couldn't I say "I honor the LGPLv2, because it would be technically possible to update the library, but unfortunately for you it is behind some tivoization that you would need to break first"?
> (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.
Moreover, the rule has no rational reason, because unlike with GPL, compliance with LGPL is very easy to achieve, even for proprietary programs.
Sounds like people should use MIT licenses (or similar non-viral licenses) instead of LGPL licenses.
> LGPL doesn't impose combined redistribution requirements, does it?
It does, in that if you modify the source-code of an LGPL-licensed library and distribute the binary, you are required to also distribute the source (i.e. the source of your modified version). Your modified source must also use the LGPL licence.
If you distribute an unmodified binary for an LGPL-licensed library, you must also provide access to the unmodified source. (This isn't to say you need to bundle it into the same archive file.)
It differs from the vanilla GPL in that an LGPL-licensed library permits you to dynamically link to it from application code that doesn't need to use any particular licence.
(This is at least the gist of the matter as it applies to application code. This isn't legal advice, I'm not a lawyer, etc.)
See the final point on this page from the FSF (authors of the GPL and LGPL) - https://www.fsf.org/bulletin/2014/fall/common-gpl-misconcept...
It's also less precise. Proprietary licenses can be 'viral' too. DRM libraries, for instance, may require that application source code not be made publicly available.
> At the risk of seeming pedantic
Parroting others in this way comes across as juvenile and antagonistic.
honestly you are over-reading and projecting here
Having a simple licensing story for assets on the store lets users have trust in whatever they see they can use in their game worry free.
Edit: Removed bit about LGPL applying to the original code because of static linkage because it was incorrect and distracting from my point
Only linking with a GPL library makes GPL applicable to the whole program.
This is the difference between LGPL and GPL. LGPL is a normal license that applies only to the library.
Since glibc uses LGPL, if your theory had been true than almost all programs run on a Linux system, regardless of their origin, would have been covered by LGPL.
Static linking can be split into two linking steps, first everything except the LGPL libraries can be linked into a big ELF object file, which no longer contains any information about the internal structure and the internal symbols, exactly like an executable file. The only difference between such an object file and an executable is that it contains unresolved external references, like a dynamically-linked executable.
Then in the second and final linking step, the big binary object file is linked with the LGPL libraries.
For compliance with LGPL it is enough to offer access to the big binary object file for the users who would want to replace the LGPL libraries.
> so now your game code is also under the LGPL and you have to publish your game code.
AFAIK, that's only true of the GPL, not the LGPL.