Probably overly cautious legal advice from lawyers who don't know how much LGPL stuff is already in the store and used by Unity itself.

It is as you suspect; Unity is run by idiot suits who don't understand their own business.

LGPL is specific to the library. A proprietary application can ship with an LGPL library, as long as the library hasn't shipped with proprietary modifications.

But Unity can’t do that because it transpiles code on build… simply linking using LD wouldn’t make you have to adopt. Any modifications would, and would have to be published in source code form.

This is why, in Unity, LGPL is the black plague.

unity only does transpiling for C# to native code if you enable it in your project. it cannot transpile the (presumably) linked native library so this shouldnt be an issue here

Consoles operate a bit differently. Sometimes it’s necessary to binary patch. Breaking LGPL.

These VLC packages only had assets for Windows, UWP and Android.

Why would transpiling mean anything special?

You are confusing GPL with LGPL.

“Generally, dynamic linking of LGPL code is considered best practice, as static linking makes meeting the license requirements more complicated. While it is possible to comply with LGPL code that is integrated into proprietary code as a statically linked library, it requires more effort. There is a kind of safe harbor for using LGPL code as a dynamically linked library; for statically linked libraries, a distributor must offer access to not only the library’s source code, but other information or materials necessary to rebuild the program.”

This makes IL2CPP kinda hairy in Unity-land. Since it’s being modified to static-link, it must be released as source. So no, I don’t think I’m confused at all.

IL2CPP should affect only .NET libraries, it won't do anything to included native code .dll,.so libraries. I would expect that in 80% of cases the LGPL librararies you might want to use are actually written in C or C++ so they would still be dynamically linked even with IL2CPP.

LGPL has nothing to do with IL2CPP, even when the library is statically linked.

Regardless how Unity might transpile their applications, they must be combined with a LGPL library only after everything has been converted into binary object files, by the linker.

In order to comply with the LGPL requirement that the user must be able to rebuild the application after possibly modifying the LGPL library, the only thing that must be provided is the linker command line that creates the final static executable.

No other information about the proprietary source files or about how they are compiled needs to be provided.

If it is desired that no function names should be leaked from the proprietary code, everything except the LGPL libraries can be pre-linked into a big binary object file without information about the internal symbols, which can be linked with the LGPL libraries only as a final step for generating the statically-linked executable.

In this way, there is absolutely no difference in the information provided when static linking is used and when dynamic linking is used.

The claim that dynamic linking is necessary with LGPL libraries is completely wrong, because linking them statically, but only after linking the other libraries, is completely equivalent.

>In order to comply with the LGPL requirement that the user must be able to rebuild the application after possibly modifying the LGPL library, the only thing that must be provided is the linker command line that creates the final static executable.

This isn't possible with IL2CPP.