4 ms·

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

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.

adrian_b 3y ago
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.
- pzo 3y ago
  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.
swiftcoder 3y ago
> 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
- palata 3y ago
  > 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.
  - rerdavies 3y ago
    > 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.
    - maple3142 3y ago
      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.
    - palata 3y ago
      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"?
  - 3y ago
paulmd 3y ago
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.

adrian_b 3y ago

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.

pzo 3y ago
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.

swiftcoder 3y ago

> 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

palata 3y ago
> 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.
- rerdavies 3y ago
  > 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.
  - maple3142 3y ago
    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.
  - palata 3y ago
    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"?
- 3y ago

paulmd 3y ago

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.