undefined | Better HN

0 pointsdoctorpangloss2y ago0 comments

> The authors of the article claim that the Unity runtime uses (some of) those libraries...

Ultimately I sympathize with the author, and this is not meant to pass a subjectively negative judgement, I know the author didn't unpack a Unity iOS IPA and carefully check if any of the libraries are definitively LGPL and if they were definitively not cross licensed, that would be a waste of his time.

> distributing LGPL apps for iOS is not in contradiction with any of the terms of the LGPL

I don't want to make the author of the LGPL, who is commenting in this thread, regret commenting. There's a phrase he uses that makes it clear to me what its intent is, "right to repair." It comes down to whether or not you think it's impracticable to replace a library in an iOS app. For the average user it obviously is.

Is it practicable for sophisticated users? You can probably get the app bundle, replace a .dylib in an embedded Framework, resign it, and use the app bundle on your development enrolled device. But then you will lose a lot of functionality, like push notifications and IAP. And ad serving will also probably stop working. So my opinion is: no. You can't distribute LGPL libraries in iOS apps.

0 comments

simiones2y ago

> There's a phrase he uses that makes it clear to me what its intent is, "right to repair."

The intent of the (author of the) LGPL and the letter of the LGPL (+ applicable law) may well be different. That is, just because the LGPL itself was designed to help with right to repair, doesn't mean it is successful at that job. It's also not necessarily the intention of others who use the LGPL - just like Linus Torvalds' intentions for using the GPLv2 are different from RMS's intentions in writing the GPL (hence why Linux is not migrating to GPLv3).

My contention is that a license can't be invalidated by a 3rd party not giving you the technical means of exercising a right that you are granted. Similarly to how the GPLv2 couldn't stop TiVo from not allowing you to run their proprietary software if you modified the version of Linux they gave you, even if RMS intended it to.

error5032y ago

> My contention is that a license can't be invalidated by a 3rd party not giving you the technical means of exercising a right that you are granted. Similarly to how the GPLv2 couldn't stop TiVo from not allowing you to run their proprietary software if you modified the version of Linux they gave you, even if RMS intended it to.

What a way to twist things around. Apple (or the app developer, who chooses Apple to distribute their software) doesn't have the right to distribute the code without abiding by the terms of the license. Copyright applies by default unless those terms are met.

TiVo's code wasn't subject to the GPL, so obviously they can have it do whatever they want, it's not remotely analogous to distributing copyrighted works outside the terms of the license that is the only thing allowing you to distribute them at all.

Cryptographic controls might be an end-run around this (as they are being abused for many other anti-consumer purposes today). The license tries to account for this, but it looks like it only applies if the code is included with the device. Unfortunately. The law really needs to catch up with this, it's clearly a hack and not respecting the intent of this or other areas of law such as first-sale doctrine.

kelnos2y ago

Not to mention that in order to have that "development enrolled device", you need to first pay Apple a fee and get their permission. Seems to me that would count as an "extra restriction" added on top of the LGPL, which the license does not allow.