Hacker News Reader

Doesn't the LGPL give users the right to replace the LGPL part with a modified library of their choice? It seems doubtful that users can modify downloaded Unity apps at their leisure, so that would mean that LGPL cannot be supported on Unity, wouldn't it?

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.

The obvious way to comply with LGPL is to link dynamically the LGPL libraries, even if everything else is linked statically.

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.

Sometimes even dynamic linking might be not enough - on iOS you can build dynamic frameworks that are dynamically linked but they are signed with developer provisioning key when distributed via App Store. AFAIK there is not other way for end user to swap such dynamic framework/library unless developer will provide source code or object files or compiled code (e.g. in other dynamic framework that links dynamically to such LGPL code). Not sure about jailbroken iPhones.

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.

> 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.

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

> LGPL does require that you provide users the ability to link against a modified version of the LGPL library.

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.

> can technically go replace the class files corresponding to the LGPLv2 library in your apk

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.

But you don't have to publish that modified apk to Play Store. You can just sign it with your own key and install the apk manually, no root needed.

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.

They must be signed to be on the store, but I don't think it's impossible to run unsigned apks on the device (maybe you need the developer mode, though).

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"?

On iOS things are even shadier, since iOS didn't allow apps to use the dynamic linker until iOS 8(?), and you have to pay Apple $100 for the priviledge of deploying the resulting app on your own device...

That is irrelevant, look at the way the clauses are structured:

> (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.

This isn't a linguistic disagreement, LGPL and similar licenses are literally forbidden by the direct plain text of the agreement.

> (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.

The complaint was not that it is not true that they have not complied with the agreement, but that this rule is only selectively enforced and that nobody truly complies with it.

Moreover, the rule has no rational reason, because unlike with GPL, compliance with LGPL is very easy to achieve, even for proprietary programs.

The rule is completely rational. It is impossible to use LGPL-licensed components on the Android app store or Apple app store without becoming infected with the full GPL. (As extensively discussed throughout this thread).

Sounds like Apple and Google should fix their broken app stores then.

The LGPL breaks because the app stores require signed executables, and signed static libraries, which is a Very Good Thing.

Sounds like people should use MIT licenses (or similar non-viral licenses) instead of LGPL licenses.

> LGPL is a regular license, it is not a viral license.

> 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.

Calling a license "viral" is a gross pejorative intended to discourage copyleft.

okay