5 ms·

Is LGPL3 permitted on the appstore?

belorn 11y ago
> Qt user will then either help the ecosystem by creating an open device that allows Qt developers to target a larger market, or help the ecosystem by funding further development of the product Apple devices are not open, are not compatible with users right to replace QT with a modified version. QT users who target those devices (through the appstore) will have to help fund QT instead. However, this is no change from previous LGPLv2 licensing which is also incompatible with the restrictions imposed by the appstore license agreement.
- hugs 11y ago
  I was wondering how this license change helps them make more money. This is it.
  - carussell 11y ago
    Except that it doesn't, and the post that you're replying to even already said so: > this is no change from previous LGPLv2 licensing. It too was incompatible with appstore
    - the_mitsuhiko 11y ago
      > Except that it doesn't, and the post that you're replying to even already said so: As mentioned earlier: [citation needed] on this please. There are plenty of apps using LPGLv2 libraries on the app store. //EDIT: currently the Qt website under does not recommend a commercial license for mobile apps from what I can tell and the wiki page is very ambiguous: https://wiki.qt.io/Licensing-talk-about-mobile-platforms https://wiki.qt.io/Licensing-talk-about-mobile-platforms
      - deleted 11y ago
        [deleted]
      - FigBug 11y ago
        http://multinc.com/2009/08/24/compatibility-between-the-iphone-app-store-and-the-lgpl/ http://multinc.com/2009/08/24/compatibility-between-the-ipho... Some LGPL2 libraries add a static linking exception. Others the authors don't really care and don't bother submitting copyright violations to Apple.
        the_mitsuhiko 11y ago
        The link you just provided says this: > have a couple of choices according to the license requirements […] You can keep your app closed-source, but you provide to your users all the object code of your application necessary to re-link your application. That means for example all the .o and .a files. Most people forget that this option is in fact available to iPhone app developers.
        carussell 11y ago
        Spend two minutes to read the rest of the article. It's technically possible for anyone developing with iPhone SDK to satisfy the LGPL, but that's so trivial an observation that there's hardly a reason to mention it. Writing an app with the iPhone SDK and publishing it on the App Store are not the same thing. The latter is the point that we're discussing.
      - carussell 11y ago
        Let's be clear: The comment made the original assertion that LGPL versions 2.1 and 3 differ in that the changes in 3 makes it incompatible with App Store, where 2.1 was not. That's a strong claim, and the onus is on that person to back it up. If you're actually interested in LGPLv2.1/App Store compatibility, the issue is so well-discussed that you can turn something up by searching for yourself. This is not a cop out. A scenario where someone puts a claim out there, someone challenges it, and then the challenger is told, "well prove it's not true", is not the proper thing, and that's what your comment does. So I'm turning down your request on those grounds.
        the_mitsuhiko 11y ago
        > The comment made the original assertion that LGPL versions 2.1 and 3 differ in that the changes in 3 makes it incompatible with App Store, where 2.1 was not. That's a strong claim, and the onus is on that person to back it up. Where was that claim made? The question was brought up if the LGPLv3 is compatible with the app store and it was mentioned that LGPLv2 code is presently being distributed via the app store. > If you're actually interested in LGPLv2.1/App Store compatibility, the issue is so well-discussed that you can turn something up by searching for yourself. It actually is not. There are various different opinions with regards to the LPGLv2 compatibility with the app store but there has not been any definite (eg: the FSF mentioned anything) answers to this dilemma. In particular many of these discussions predate the current state of affairs with regards to iOS where dynamic linking is now possible. > A scenario where someone puts a claim out there, someone challenges it, and then the challenger is told, "well prove it's not true", is not the proper thing I don't remember making a claim. I precisely mentioned that from my understanding the distribution of LPGv2 software on the app store is possible judging by what is actively being done. Something that cannot be said for any other *GPL license. In any case none of this has been challenged in court so any of this is interpretation of a license by random people on the internet with more or less credibility on the topic.
  - pjmlp 11y ago
    Many companies that are allergic to GPLv3, now need either to change their software stack or pay for a commercial license. EDIT: Apparently stating facts how many companies see GPLv3, regardless of the license contents, hits a nerve with the downvote squad.
    - wolfgke 11y ago
      That's a problem of the companies. GPLv3 contains no fundamental changes in the freedoms it gives and requires to be uphold - it just clarifies some things explicitly (in particular that tivoization is explicitly forbidden, where before it was some legal gray area) and gives better compatibility between the GPL and other FOSS licenses.
      - pjmlp 11y ago
        I didn't say that it was a licence problem. Many companies have legal departments that forbid any form of GPL software. I had customers that any third party dependency required legal approval before being used in the code.
        wolfgke 11y ago
        You explicitly wrote about GPLv3 in your post above. For GPL software in general, your claim is surely true. But I see no reason why GPLv3 might make a difference (except for the few rare cases where tivoization might play a role) over GPLv2 here.
        pjmlp 11y ago
        Every licence change, even a comma, triggers a new legal review in such customers.
        chris_wot 11y ago
        Given they were using the LGPL before, which means they were already using GPL software, it means they are already in conflict with their legal department. In other words, what you say isn't the case.
- the_mitsuhiko 11y ago
  > However, this is no change from previous LGPLv2 licensing. It too was incompatible with appstore. Can you elaborate on this? I was under the impression that LGPLv2 is compatible with the app store under the assumption that users can get access to the source of that library and object files of the application for re-linking.
  - belorn 11y ago
    You do not need to give users the right to republish your application on the AppStore, but you need to give users the right to deploy your app with the modified version of the LGPL code on their own devices. The Appstore agreement prohibits this, which means it adds an conflicting legal condition to the users. The Appstore agreement also restricts the use of reverse engineering, a condition which is incompatible with LGPLv2, section 6. Section 2.6 in the "iPhone Developer Program License Agreement" prohibits reverse engineering, including anything that would "enable others" to reverse engineer.
    - comex 11y ago
      I think you may be right, but if there is a conflict, it's narrower than you say. > You agree not to, or to enable others to, copy (except as expressly permitted under this Agreement), decompile, reverse engineer, disassemble, attempt to derive the source code of, modify, decrypt, or create derivative works of the Apple Software, Apple-issued certificates or any services provided by the Apple Software or otherwise provided hereunder, > "Apple Software" means the iOS SDK, the iOS, the Provisioning Profiles and any other software that Apple provides to You under the Program, including any Updates thereto that may be provided to You by Apple. Those terms don't apply to your own app. Of course, this is the agreement developers have to sign; let's look at what users have to sign, the iTunes ToC: http://www.apple.com/legal/internet-services/itunes/us/terms.html#APPS http://www.apple.com/legal/internet-services/itunes/us/terms... The relevant clauses are: > You agree not to violate, circumvent, reverse-engineer, decompile, disassemble, or otherwise tamper with any of the security technology related to such Usage Rules for any reason—or to attempt or assist another person to do so. Again it only applies to "security technology", not the app itself. There is also a default license for apps themselves that has similar language, but it has an exception if "that App Store Product is covered by a valid end user license agreement between you and the Application Provider of that App Store Product". However, all apps are distributed encrypted and any attempt to decrypt them would presumably be considered circumventing "security technology". And the LGPL requires that the terms allow for: > modification of the work for the customer's own use and reverse engineering for debugging such modifications. The latter part is potentially more broad than reverse engineering the library itself, and is probably the biggest problem. Also, in the former, "the work" refers to the entire linked binary, which per above is distributed encrypted. But I (who ANAL) think there may be a valid argument that if the app submitter separately distributes unencrypted copies of the binary, these terms are satisfied. The "security technology" in question does not actually include any code linked into the binary - the only transformation to it is encryption - so the unencrypted and encrypted versions could be considered two different representations of the same work, rather than the latter being a derivative work. Thus it would still be possible to modify and reverse engineer it by referring to the unencrypted version. But not reverse engineer iOS to debug it, so that's still a problem. Maybe if the library was sufficiently isolated from the system that it could not be reasonably considered necessary to do so... You are incorrect about needing to give users the right to deploy modified versions. An App Store submitter can satisfy either 6a or 6b: 6a requires distributing object or source code to relink the app, but says nothing about installation of the relinked version; 6b merely says "will operate properly with a modified version of the library, if the user installs one", which is different from providing a means for the user to install one. (Anyway, this may often be accomplished by jailbreaking.) edit: Not that any of this matters much. Chances are Apple will be conservative and remove an app from the store if it has any ambiguity as to valid licensing - if someone asks. Meanwhile, right now nobody is asking, and some LGPLv2 apps and libraries are in the store. The exact terms only matter if it gets to court, and because of that conservatism, it won't.
- roel_v 11y ago
  "will have to help fund QT instead." Lol this is one of the worst cases of newspeak I've seen in months. Just say "will have to pay" because that's what you really mean.
- joosters 11y ago
  LGPLv2 is compatible with the app store. It certainly goes against the spirit of the licence, but does not break the letter. See the comments in https://lwn.net/Articles/526355/ https://lwn.net/Articles/526355/ for a discussion about LGPL and VLC on the app store.

> Qt user will then either help the ecosystem by creating an open device that allows Qt developers to target a larger market, or help the ecosystem by funding further development of the product Apple devices are not open, are not compatible with users right to replace QT with a modified version. QT users who target those devices (through the appstore) will have to help fund QT instead. However, this is no change from previous LGPLv2 licensing which is also incompatible with the restrictions imposed by the appstore license agreement.

hugs 11y ago
I was wondering how this license change helps them make more money. This is it.
- carussell 11y ago
  Except that it doesn't, and the post that you're replying to even already said so: > this is no change from previous LGPLv2 licensing. It too was incompatible with appstore
  - the_mitsuhiko 11y ago
    > Except that it doesn't, and the post that you're replying to even already said so: As mentioned earlier: [citation needed] on this please. There are plenty of apps using LPGLv2 libraries on the app store. //EDIT: currently the Qt website under does not recommend a commercial license for mobile apps from what I can tell and the wiki page is very ambiguous: https://wiki.qt.io/Licensing-talk-about-mobile-platforms https://wiki.qt.io/Licensing-talk-about-mobile-platforms
    - deleted 11y ago
      [deleted]
    - FigBug 11y ago
      http://multinc.com/2009/08/24/compatibility-between-the-iphone-app-store-and-the-lgpl/ http://multinc.com/2009/08/24/compatibility-between-the-ipho... Some LGPL2 libraries add a static linking exception. Others the authors don't really care and don't bother submitting copyright violations to Apple.
      - the_mitsuhiko 11y ago
        The link you just provided says this: > have a couple of choices according to the license requirements […] You can keep your app closed-source, but you provide to your users all the object code of your application necessary to re-link your application. That means for example all the .o and .a files. Most people forget that this option is in fact available to iPhone app developers.
        carussell 11y ago
        Spend two minutes to read the rest of the article. It's technically possible for anyone developing with iPhone SDK to satisfy the LGPL, but that's so trivial an observation that there's hardly a reason to mention it. Writing an app with the iPhone SDK and publishing it on the App Store are not the same thing. The latter is the point that we're discussing.
    - carussell 11y ago
      Let's be clear: The comment made the original assertion that LGPL versions 2.1 and 3 differ in that the changes in 3 makes it incompatible with App Store, where 2.1 was not. That's a strong claim, and the onus is on that person to back it up. If you're actually interested in LGPLv2.1/App Store compatibility, the issue is so well-discussed that you can turn something up by searching for yourself. This is not a cop out. A scenario where someone puts a claim out there, someone challenges it, and then the challenger is told, "well prove it's not true", is not the proper thing, and that's what your comment does. So I'm turning down your request on those grounds.
      - the_mitsuhiko 11y ago
        > The comment made the original assertion that LGPL versions 2.1 and 3 differ in that the changes in 3 makes it incompatible with App Store, where 2.1 was not. That's a strong claim, and the onus is on that person to back it up. Where was that claim made? The question was brought up if the LGPLv3 is compatible with the app store and it was mentioned that LGPLv2 code is presently being distributed via the app store. > If you're actually interested in LGPLv2.1/App Store compatibility, the issue is so well-discussed that you can turn something up by searching for yourself. It actually is not. There are various different opinions with regards to the LPGLv2 compatibility with the app store but there has not been any definite (eg: the FSF mentioned anything) answers to this dilemma. In particular many of these discussions predate the current state of affairs with regards to iOS where dynamic linking is now possible. > A scenario where someone puts a claim out there, someone challenges it, and then the challenger is told, "well prove it's not true", is not the proper thing I don't remember making a claim. I precisely mentioned that from my understanding the distribution of LPGv2 software on the app store is possible judging by what is actively being done. Something that cannot be said for any other *GPL license. In any case none of this has been challenged in court so any of this is interpretation of a license by random people on the internet with more or less credibility on the topic.
- pjmlp 11y ago
  Many companies that are allergic to GPLv3, now need either to change their software stack or pay for a commercial license. EDIT: Apparently stating facts how many companies see GPLv3, regardless of the license contents, hits a nerve with the downvote squad.
  - wolfgke 11y ago
    That's a problem of the companies. GPLv3 contains no fundamental changes in the freedoms it gives and requires to be uphold - it just clarifies some things explicitly (in particular that tivoization is explicitly forbidden, where before it was some legal gray area) and gives better compatibility between the GPL and other FOSS licenses.
    - pjmlp 11y ago
      I didn't say that it was a licence problem. Many companies have legal departments that forbid any form of GPL software. I had customers that any third party dependency required legal approval before being used in the code.
      - wolfgke 11y ago
        You explicitly wrote about GPLv3 in your post above. For GPL software in general, your claim is surely true. But I see no reason why GPLv3 might make a difference (except for the few rare cases where tivoization might play a role) over GPLv2 here.
        pjmlp 11y ago
        Every licence change, even a comma, triggers a new legal review in such customers.
      - chris_wot 11y ago
        Given they were using the LGPL before, which means they were already using GPL software, it means they are already in conflict with their legal department. In other words, what you say isn't the case.
the_mitsuhiko 11y ago
> However, this is no change from previous LGPLv2 licensing. It too was incompatible with appstore. Can you elaborate on this? I was under the impression that LGPLv2 is compatible with the app store under the assumption that users can get access to the source of that library and object files of the application for re-linking.
- belorn 11y ago
  You do not need to give users the right to republish your application on the AppStore, but you need to give users the right to deploy your app with the modified version of the LGPL code on their own devices. The Appstore agreement prohibits this, which means it adds an conflicting legal condition to the users. The Appstore agreement also restricts the use of reverse engineering, a condition which is incompatible with LGPLv2, section 6. Section 2.6 in the "iPhone Developer Program License Agreement" prohibits reverse engineering, including anything that would "enable others" to reverse engineer.
  - comex 11y ago
    I think you may be right, but if there is a conflict, it's narrower than you say. > You agree not to, or to enable others to, copy (except as expressly permitted under this Agreement), decompile, reverse engineer, disassemble, attempt to derive the source code of, modify, decrypt, or create derivative works of the Apple Software, Apple-issued certificates or any services provided by the Apple Software or otherwise provided hereunder, > "Apple Software" means the iOS SDK, the iOS, the Provisioning Profiles and any other software that Apple provides to You under the Program, including any Updates thereto that may be provided to You by Apple. Those terms don't apply to your own app. Of course, this is the agreement developers have to sign; let's look at what users have to sign, the iTunes ToC: http://www.apple.com/legal/internet-services/itunes/us/terms.html#APPS http://www.apple.com/legal/internet-services/itunes/us/terms... The relevant clauses are: > You agree not to violate, circumvent, reverse-engineer, decompile, disassemble, or otherwise tamper with any of the security technology related to such Usage Rules for any reason—or to attempt or assist another person to do so. Again it only applies to "security technology", not the app itself. There is also a default license for apps themselves that has similar language, but it has an exception if "that App Store Product is covered by a valid end user license agreement between you and the Application Provider of that App Store Product". However, all apps are distributed encrypted and any attempt to decrypt them would presumably be considered circumventing "security technology". And the LGPL requires that the terms allow for: > modification of the work for the customer's own use and reverse engineering for debugging such modifications. The latter part is potentially more broad than reverse engineering the library itself, and is probably the biggest problem. Also, in the former, "the work" refers to the entire linked binary, which per above is distributed encrypted. But I (who ANAL) think there may be a valid argument that if the app submitter separately distributes unencrypted copies of the binary, these terms are satisfied. The "security technology" in question does not actually include any code linked into the binary - the only transformation to it is encryption - so the unencrypted and encrypted versions could be considered two different representations of the same work, rather than the latter being a derivative work. Thus it would still be possible to modify and reverse engineer it by referring to the unencrypted version. But not reverse engineer iOS to debug it, so that's still a problem. Maybe if the library was sufficiently isolated from the system that it could not be reasonably considered necessary to do so... You are incorrect about needing to give users the right to deploy modified versions. An App Store submitter can satisfy either 6a or 6b: 6a requires distributing object or source code to relink the app, but says nothing about installation of the relinked version; 6b merely says "will operate properly with a modified version of the library, if the user installs one", which is different from providing a means for the user to install one. (Anyway, this may often be accomplished by jailbreaking.) edit: Not that any of this matters much. Chances are Apple will be conservative and remove an app from the store if it has any ambiguity as to valid licensing - if someone asks. Meanwhile, right now nobody is asking, and some LGPLv2 apps and libraries are in the store. The exact terms only matter if it gets to court, and because of that conservatism, it won't.
roel_v 11y ago
"will have to help fund QT instead." Lol this is one of the worst cases of newspeak I've seen in months. Just say "will have to pay" because that's what you really mean.
joosters 11y ago
LGPLv2 is compatible with the app store. It certainly goes against the spirit of the licence, but does not break the letter. See the comments in https://lwn.net/Articles/526355/ https://lwn.net/Articles/526355/ for a discussion about LGPL and VLC on the app store.