3 ms·

First, the problem is not iOS, but the AppStore. GPL and LGPL are totally fine with iOS. About the AppStore, the issue is mainly that it does not allow shared

by jbk 15y ago

First, the problem is not iOS, but the AppStore. GPL and LGPL are totally fine with iOS. About the AppStore, the issue is mainly that it does not allow shared-objects, as far as I know, and makes it hard to replace parts of the code. However, IIRC, AppStore allows Frameworks. So, if a Framework is LGPL, and therefore weakly- linked, it might be just fine. But, yes, it is normal that the FSF does not answer, since this is a complex issue.

forrestthewoods 15y ago
Got it. I don't know of a way for end users to replace frameworks with a newer version so it seems unlikely. Was there ever any discussion of going to an even more open license such as MIT/BSD?
- jbk 15y ago
  Nope. We didn't even discussed about it. We were GPL. We want other people to use the Library, so we went L-GPL, since this was the simplest solution and the more respectful of the spirit of old developers.
zbowling 15y ago
This isn't really correct. When you say AppStore you have to make a distinction between Mac and iOS. As a platform, iOS doesn't allow you to bundle any dynamically linked libraries with your application (so everything everyone ships on iOS is statically linked). You can dynamically link system libraries though. Since they don't allow you to download and execute any code not shipped with the app, this hasn't been a big issue (except with trying to use LGPL code and to port apps that are already configured around dynamic loading or use different processes to isolate functionality). Now Mac apps fully allow dynamically linked libraries bundled with your app (even with sandboxing enabled). There are fewer restrictions on the Mac AppStore in this respect. Like for example, plugins are fully allowed and supported. Code added to the app after the fact is fine (as long as the advertised core in the app store is there without downloading additional code). On this, working with LGPL restrictions are little more plausible. A framework is basically a bundle of dynamic libraries and headers in a package. Frameworks for that reason are no different than dynamic libraries, so your usage of the term here and false distinction from "shared-objects" is incorrect here. LGPL requires that you allow the user to be able replace the LGPL library out completely and that you release the source to the library if you, the user, who I distributed a binary copy from, requests it. This is just not possible on iOS with static linking of course, but it is possible on Mac OSX. The bigger issue is that Apple is the "distributor" of the app and not the developer that gave the copy to Apple. If I wanted to request LGPL code, I would have to contact Apple because I obtained the application from them not the developer that gave them a copy. Apple doesn't have a facility for this.
- gillianseed 15y ago
  Well, unless there's been changes made to the LGPL'd code then the App using it could simply point to VLC's webpage for the source code. LGPL only requires changes made to the actual LGPL licenced code be made open source, unlike GPL which requires the entire application using/linking GPL licenced code to be open sourced under GPL. The reason why Apple AppStore and GPL don't mix is that Apple added a restriction as to how many times you could copy the binary while GPL explicitly states that you are allowed to make as many copies as you want.
RexRollman 15y ago
Couldn't you just release a VLC app with an in-app link to the source code from the VLC servers? I've never understood the problem with the AppStore anyway. For example, if I bought a copy of Red Hat Linux from Best Buy and it didn't include the source code, I would go to Red Hat for it, not Best Buy. To me, the AppStore is just a middleman.

by jbk 15y ago

forrestthewoods 15y ago

Got it. I don't know of a way for end users to replace frameworks with a newer version so it seems unlikely. Was there ever any discussion of going to an even more open license such as MIT/BSD?

jbk 15y ago
Nope. We didn't even discussed about it. We were GPL. We want other people to use the Library, so we went L-GPL, since this was the simplest solution and the more respectful of the spirit of old developers.

zbowling 15y ago

This isn't really correct. When you say AppStore you have to make a distinction between Mac and iOS. As a platform, iOS doesn't allow you to bundle any dynamically linked libraries with your application (so everything everyone ships on iOS is statically linked). You can dynamically link system libraries though. Since they don't allow you to download and execute any code not shipped with the app, this hasn't been a big issue (except with trying to use LGPL code and to port apps that are already configured around dynamic loading or use different processes to isolate functionality). Now Mac apps fully allow dynamically linked libraries bundled with your app (even with sandboxing enabled). There are fewer restrictions on the Mac AppStore in this respect. Like for example, plugins are fully allowed and supported. Code added to the app after the fact is fine (as long as the advertised core in the app store is there without downloading additional code). On this, working with LGPL restrictions are little more plausible. A framework is basically a bundle of dynamic libraries and headers in a package. Frameworks for that reason are no different than dynamic libraries, so your usage of the term here and false distinction from "shared-objects" is incorrect here. LGPL requires that you allow the user to be able replace the LGPL library out completely and that you release the source to the library if you, the user, who I distributed a binary copy from, requests it. This is just not possible on iOS with static linking of course, but it is possible on Mac OSX. The bigger issue is that Apple is the "distributor" of the app and not the developer that gave the copy to Apple. If I wanted to request LGPL code, I would have to contact Apple because I obtained the application from them not the developer that gave them a copy. Apple doesn't have a facility for this.

gillianseed 15y ago
Well, unless there's been changes made to the LGPL'd code then the App using it could simply point to VLC's webpage for the source code. LGPL only requires changes made to the actual LGPL licenced code be made open source, unlike GPL which requires the entire application using/linking GPL licenced code to be open sourced under GPL. The reason why Apple AppStore and GPL don't mix is that Apple added a restriction as to how many times you could copy the binary while GPL explicitly states that you are allowed to make as many copies as you want.

RexRollman 15y ago

Couldn't you just release a VLC app with an in-app link to the source code from the VLC servers? I've never understood the problem with the AppStore anyway. For example, if I bought a copy of Red Hat Linux from Best Buy and it didn't include the source code, I would go to Red Hat for it, not Best Buy. To me, the AppStore is just a middleman.