4 ms·

Given that Unity itself also uses LGPLv2.0 dependencies in its own iOS version, it seems clear that at least Unity believes that there is no issue deploying LGP

Given that Unity itself also uses LGPLv2.0 dependencies in its own iOS version, it seems clear that at least Unity believes that there is no issue deploying LGPLv2.0 code to iOS.

dagmx 3y ago
Or they’ve dual licensed the libraries in question.
- simiones 3y ago
  You're suggesting they have obtained permission from the copyright holders of, say, libiconv, to distribute their code under a non-LGPL license?
  - doctorpangloss 3y ago
    I don't think there are any LGPL licensed libraries linked or distributed by a Unity iOS build. Neither you nor I have looked carefully, but it's almost certainly not the case. With regards to libiconv, which I don't know if Unity iOS builds use it, there is a BSD implementation of it, which is almost certainly the case also with what iOS uses. I can't speak to the work the author of this blogpost did with regards to investigating the usage of the specific LGPL libraries. The specific examples specified would all make sense as strictly used by the Editor. My opinion is that if you are looking for wholesale license violations by giant corporations like Unity, libraries are the wrong place. Huge corporations launder license violations by line-by-line rewriting the code and pretending their implementation is original.
    - simiones 3y ago
      The authors of the article claim that the Unity runtime uses (some of) those libraries, and that it is being used on iOS as well. You're right of course that I have not done any independent research on it, and so they may be lying or wrong for all I know. However, even if Unity is not using those libraries in the iOS runtime but does use them somewhere else, that still seems that they were arbitrary in their enforcement of the rules, since the VLC packages mentioned here were not being distributed for iOS at all. So they were certainly not using LGPL on iOS either. I'd also mention that I'm not claiming that Unity is breaking the LGPL. I'm rather more of the opinion that distributing LGPL apps for iOS is not in contradiction with any of the terms of the LGPL, and that Unity thinks so as well.
      - debugnik 3y ago
        > The authors of the article claim that the Unity runtime uses (some of) those libraries, and that it is being used on iOS as well. The article doesn't mention iOS or Apple even once, they in fact mention they only had assets for Windows, UWP and Android as three different packages, so everyone here thinking Unity is blocking the packages because of iOS has completely missed the context.
      - doctorpangloss 3y ago
        > 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.
        simiones 3y 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.
    - microtherion 3y ago
      libiconv ships with iOS, so Unity does not need to distribute it, only link to it. And according to the macOS man page, this is the BSD version.

Given that Unity itself also uses LGPLv2.0 dependencies in its own iOS version, it seems clear that at least Unity believes that there is no issue deploying LGPLv2.0 code to iOS.

dagmx 3y ago

Or they’ve dual licensed the libraries in question.

simiones 3y ago
You're suggesting they have obtained permission from the copyright holders of, say, libiconv, to distribute their code under a non-LGPL license?
- doctorpangloss 3y ago
  I don't think there are any LGPL licensed libraries linked or distributed by a Unity iOS build. Neither you nor I have looked carefully, but it's almost certainly not the case. With regards to libiconv, which I don't know if Unity iOS builds use it, there is a BSD implementation of it, which is almost certainly the case also with what iOS uses. I can't speak to the work the author of this blogpost did with regards to investigating the usage of the specific LGPL libraries. The specific examples specified would all make sense as strictly used by the Editor. My opinion is that if you are looking for wholesale license violations by giant corporations like Unity, libraries are the wrong place. Huge corporations launder license violations by line-by-line rewriting the code and pretending their implementation is original.
  - simiones 3y ago
    The authors of the article claim that the Unity runtime uses (some of) those libraries, and that it is being used on iOS as well. You're right of course that I have not done any independent research on it, and so they may be lying or wrong for all I know. However, even if Unity is not using those libraries in the iOS runtime but does use them somewhere else, that still seems that they were arbitrary in their enforcement of the rules, since the VLC packages mentioned here were not being distributed for iOS at all. So they were certainly not using LGPL on iOS either. I'd also mention that I'm not claiming that Unity is breaking the LGPL. I'm rather more of the opinion that distributing LGPL apps for iOS is not in contradiction with any of the terms of the LGPL, and that Unity thinks so as well.
    - debugnik 3y ago
      > The authors of the article claim that the Unity runtime uses (some of) those libraries, and that it is being used on iOS as well. The article doesn't mention iOS or Apple even once, they in fact mention they only had assets for Windows, UWP and Android as three different packages, so everyone here thinking Unity is blocking the packages because of iOS has completely missed the context.
    - doctorpangloss 3y ago
      > 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.
      - simiones 3y 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.
  - microtherion 3y ago
    libiconv ships with iOS, so Unity does not need to distribute it, only link to it. And according to the macOS man page, this is the BSD version.