4 ms·

For clarity, I presume you're talking about L(ibrary)GPLv2.0 published[0] in June of '91, since afaik there was never an LGPLv1. Anyway, do you think it's good

by Y_Y 3y ago

For clarity, I presume you're talking about L(ibrary)GPLv2.0 published[0] in June of '91, since afaik there was never an LGPLv1. Anyway, do you think it's good or bad if Unity is stopping people from potentially deploying to e.g. iOS when this would violate the LGPL, even if the responsibility for the violation would not lie with Unity? [0] https://www.gnu.org/licenses/old-licenses/lgpl-2.0.html https://www.gnu.org/licenses/old-licenses/lgpl-2.0.html

simiones 3y ago
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.
gumby 3y ago
The original was used, IIRC to license glibc when Steve Chamberlain and I (mainly him I’m pretty sure) were starting out on it — I think that was the motivation. You’re right: I’m not sure we actually shipped a glibc with that version. This was long before we hired Drepper.

by Y_Y 3y ago

simiones 3y ago

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.

gumby 3y ago

The original was used, IIRC to license glibc when Steve Chamberlain and I (mainly him I’m pretty sure) were starting out on it — I think that was the motivation. You’re right: I’m not sure we actually shipped a glibc with that version. This was long before we hired Drepper.