Looking at the videos it seems like they have used qt/lighthouse to port over to the phone. Whereas this project is trying to use more of the native controls and interfaces. I didn't see anywhere where they posted code though.
In the space of open source the more projects the better. This will give the developer more opportunities for their project.
So good luck on both projects!
Regards,
Mark Kromis
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Indeed! Although the Qt developer will have to be a commercial Qt licensee to develop apps for the App Store. The Qt license states that in order to link statically one needs a commercial license…
Unfortunately, the App Store is not compatible with GPL or LGPL licenses (even if Apple were to allow dynamic libraries).
It's possible to get around this by going through a 'publisher' that has a commercial Qt license (and Apple Developer License)… However, neither of those are free, so it's unlikely that there will be any free Qt based apps in the App Store any time soon (not legally anyway).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In theory, the owner (Nokia) could give permission for some aspects of the LGPL to be waived, but without that it's not legal (witness the case of VLC). The purpose of LGPL is to allow the user to recompile the library and use it with the application. That's not possible with App Store applications as modifying the app bundle will break the code signing and render the app inoperable.
If dynamic linking was allowed for apps in the App Store (it appears that it is not currently), without a 'publisher' the developer could provide full source for the application under GPL and satisfy GPL licensing. There are some apps which are sold on the App Store that use GPL licensing, the idea being that most users would rather pay $1 than have to become an Apple developer and build the app themselves…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It also seems that even if you have commercial license, this does not cover WebKit that is built into Qt, nor Photon. They don't control those sources.
I don't know how hard it would be to make the qt use the system webkit instead of built-in one.
Regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not a big deal. The App Store rules don't permit applications that use their own browsing engine (they must use the WebKit framework supplied by Apple). There isn't a backend for Phonon that would work on iOS anyway, so if one was going to implement a multimedia engine, it would make more sense to use the Qt Mobility APIs. Phonon is being deprecated in favour of native (Qt) multimedia APIs…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You guys should read your LGPL. Section 6(a) allows you to statically link, provided you provide source and/or object code so the user can modify and relink to create a modified executable. Users using the App store will probably never do this, but my understanding is that you have to at the very least make an offer to do so as part of your EULA.
Also, the conditions of the commercial Qt license forbid the migration of code produced under the LGPL to a commercial license, so I don't think a commercial publisher would be able to statically link and distribute such code.
Anyway, thumbs up on both your houses, I look forward to these projects getting traction.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also from http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html
6a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)
I hope static linking will not be a problem. Also that the app store add DRM to it may also complicate the issue.
Regards,
Mark Kromis
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@llamatronique: So you're more or less just repeating what's been written previously in this topic… ;)
In any case that condition in the Qt commercial license you refer to, is to prevent LGPL code from being moved to a more restrictive license. If you've never released the software (in source or object form), it's not relevant…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
both the points I made were completely new pieces of information.
the provision in 6a for statically linking under the LGPL wasn't mentioned at all. all that was mentioned is that only dynamic linking is allowed which is a common misunderstanding.
"You must purchase a Qt Commercial Developer License from us or from one of our authorized resellers before you start developing commercial software as you are not permitted to begin your development with an open source licensed Qt version and convert to the commercially license version at a later . The Qt Commercial Developer License includes a restriction that prevents the combining of code developed with the Qt GNU LGPL v. 2.1 or GNU GPL v. 3.0 license versions with commercially licensed Qt code."
i.e. 'developed' not 'released'… so it's mighty relevant.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"without a 'publisher' the developer could provide full source for the application under GPL and satisfy GPL licensing. There are some apps which are sold on the App Store that use GPL licensing, the idea being that most users would rather pay $1 than have to become an Apple developer and build the app themselves… "
The opensource/commercial Qt thing is a bit hard to prove if the software hasn't ever been released… Also a bit hard to believe that Nokia would come after their paid customers, but you're right, the license does state that it's not permitted… :)
A bigger issue, which hasn't really been touched on, is that Qt really has much too big a footprint to be used either statically, or dynamically where it must be shipped with the app… ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"In theory, the owner (Nokia) could give permission for some aspects of the LGPL to be waived, but without that it's not legal (witness the case of VLC)"
VLC's code in question was released under the GPL, not the LGPL. the GPL prohibits the application of "further restrictions".
the LGPL also has this clause, however it allows you to distribute '…under terms of your choice, provided…" which may be (and has been) interpreted to allow DRM such as that in the App Store… just as you can deliver commercial software which has software key protection, hardware dongle protection, iris scans, dna profiling checks or whatever).
So no, Nokia doesn't need to give any permission for aspects of the LGPL to be waived in order for their code to be released on the App Store, provided it is (a) statically linked which it needs to in order to comply with the app store terms and (b) the terms are met in section 6a of the LGPL.
anyway, assuming you meant to cite the GPL, you then contradict that by saying:
"…without a 'publisher' the developer could provide full source for the application under GPL and satisfy GPL licensing."
sorry? first it's not legal, and then it's perfectly ok?… according to the FSF it is not. personally i think their interpretation is convoluted and pretty shakey, but it's up to the author of the code to enforce according to their interpretation, and so far at least two takedowns have occurred as a result. if you release GPL code on the app store you run that risk, and apple have shown that they are willing to just take it down to give the relevant copyright holders the benefit of the doubt.
"The opensource/commercial Qt thing is a bit hard to prove if the software hasn't ever been released… Also a bit hard to believe that Nokia would come after their paid customers, but you're right, the license does state that it's not permitted… :)"
good luck with that… nokia is a huge multinational corporation, not a care bear, and paid customers are more vulnerable as they have means to pay. i don't think it is at all wise to try to predict what their course of action might be for a perceived breach of the license agreement.
"A bigger issue, which hasn't really been touched on, is that Qt really has much too big a footprint to be used either statically, or dynamically where it must be shipped with the app… ;)"
based on what evidence?… Qt runs fine on symbian and meego devices, most of which have less resources than iOS devices, and the components generally used for mobile devices (mobility, declarative) are lightweight and designed specifically for this purpose.
also, static linking only links in the code you actually use, so the 'footprint' is entirely application dependant. most games link statically to 3rd party game engines of varying degrees of complexity in the same way, and that doesn't seem to be a 'big issue'.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@llamatronique: "based on what evidence?… Qt runs fine on symbian and meego devices, most of which have less resources than iOS devices, and the components generally used for mobile devices (mobility, declarative) are lightweight and designed specifically for this purpose."
I'm not talking about memory footprint (I haven't looked at that). BTW it's not shipped with the app on those systems, it's pre-installed, which is the point I'm making. If you have to ship the whole of Qt with your app, it makes it a lot bigger than the 500Kb-1Mb app that you could have if you didn't have to ship the framework…
I would be very surprised if you could fit your app and the Qt framework into the 10Mb limit that the AppStore has for 3G downloads… (in fact, apparently, Qt apps for iOS are 20Mb+ with statically linked Qt) ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"There is debate in the legal and open source communities as to whether static linking is permissible under the LGPL version 2.1. The uncertainty is caused by an inconsistency in the LGPL license itself. The LGPL v. 2.1 defines “a work based on the Library” to be anything that would be a derivative work under copyright law. Unfortunately, the LGPL is neutral from a legal jurisdictional point of view – the question of which jurisdiction’s copyright laws should be considered is undefined and open to interpretation depending on numerous factors such as where the application is distributed, created, etc. In many jurisdictions, an application that is statically linked with the LGPL licensed library will be considered a derivative work. Thus, in accordance with the LGPL’s definition of a “work based on the Library”, a statically linked application could be subject to the provisions regarding modification and distribution of the Library included in Sections 1, 2, and 4 of the LGPL. Those who believe that static linking is permissible under the LGPL v. 2.1 primarily refer to Sections 5 and 6(a) of the LGPL to support their argument. Those arguing that static linking is permitted under the LGPL argue that Section 5 specifically acknowledges that the executable that results from the static linking of the application with the library is a derivative work of the Library. However, the language in Section 5 gives some indications that despite the executable being a derivative work, it can be distributed in accordance with Section 6. Unfortunately, it is precisely this acknowledgment that the executable may be a derivative work that creates the inconsistency within the license.
Due to the varying opinions on whether static linking is permissible, it is Nokia’s recommendation that Qt users dynamically link their applications to the LGPL-licensed Qt libraries so as to ensure that the application source code, which a user may want to keep private, does not have to be shared with downstream recipients. Ultimately, however, this decision is one of risk and the individual Qt user should make this decision based on their own specific circumstances. Some of the recent posts have stated a desire to have Nokia’s position on whether static linking is permissible. Because the LGPL v. 2.1 source code obligations can be enforced by any recipient of the application and LGPL-licensed library, Nokia’s position on this issue is not particularly relevant and is merely one opinion among many."
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
you can't ship the whole qt library on iOS devices, as only static linking is supported, so the footprint of the 'entire' of qt is moot. this is a condition which likely to never change.
as far as the 'derivative work' argument is concerned, that interpretation should of course be given serious consideration, but as far as I know it is still considered ambiguous because it has never been tested. that opinion also seems to me to be quite selective and fails to acknowledge the explicit nature of section 6's preamble.
specifically, it is 'as an exception to the sections above', so even if it is unambiguous that the work is a derivative (which section 6 itself states) then sections 1-5 don't apply except where specifically referenced in 6a with respect to the 'Library'. it is clear to me at least, that the language used to define the 'work', the 'Library' and the 'executable linked with the Library' are also unambiguous.
so i still strongly stand by the argument that in its current form, the LGPLs provisions are sufficient, however it would make a great deal of sense for nokia to provide an exception for such cases to eliminate uncertainty. i guess it's up the them to decide what 'Qt Everywhere' actually means.
anyway, none of this obviously constitutes legal advice. the aim of the exercise is to argue for 'free' distribution of shared code according to the spirit of the various licenses. restricting distribution of software based on prejudice against a users' choice of platform is becoming an absurdity which needs fixing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Based on experience with embedded Linux (on ARM), the executable for a QML app, if linked statically, is in the region of 55-60Mb (which will be more or less the same for iOS). That's before you start including resources (artwork etc.). The minimum you need is: Core, Gui, Declarative, Network, Script, Sql, Svg & Xmlpatterns… Not much of Qt left that you're not including there… And a *massive* footprint for a mobile app executable… ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ok, fair enough. after linking a minimal qml app on a mac, the best I can do is 22MB, there's probably additional savings to be made (i didn't use -Os for the libs), but probably not what's you might consider reasonable.
dead stripping isn't as effective as it used to be.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The linker can't strip out much in a QML app. Anything that could possibly be used by any code path in Declarative will be left in. How would the linker know what a QML script was actually using? BTW, ARM object code (Qt libaries) is about 40% bigger than x86. The way to start slimming Qt down would be to #ifdef out parts of Gui (it's the largest single library)…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
http://developer.qt.nokia.com/forums/viewthread/1759/
Looking at the videos it seems like they have used qt/lighthouse to port over to the phone. Whereas this project is trying to use more of the native controls and interfaces. I didn't see anywhere where they posted code though.
In the space of open source the more projects the better. This will give the developer more opportunities for their project.
So good luck on both projects!
Regards,
Mark Kromis
Indeed! Although the Qt developer will have to be a commercial Qt licensee to develop apps for the App Store. The Qt license states that in order to link statically one needs a commercial license…
Unfortunately, the App Store is not compatible with GPL or LGPL licenses (even if Apple were to allow dynamic libraries).
It's possible to get around this by going through a 'publisher' that has a commercial Qt license (and Apple Developer License)… However, neither of those are free, so it's unlikely that there will be any free Qt based apps in the App Store any time soon (not legally anyway).
hmmm…. I think if I read the agreement right that LGPL would be acceptable if dynamic linked.
However the publisher idea is very interesting.
Regards,
Mark Kromis
In theory, the owner (Nokia) could give permission for some aspects of the LGPL to be waived, but without that it's not legal (witness the case of VLC). The purpose of LGPL is to allow the user to recompile the library and use it with the application. That's not possible with App Store applications as modifying the app bundle will break the code signing and render the app inoperable.
If dynamic linking was allowed for apps in the App Store (it appears that it is not currently), without a 'publisher' the developer could provide full source for the application under GPL and satisfy GPL licensing. There are some apps which are sold on the App Store that use GPL licensing, the idea being that most users would rather pay $1 than have to become an Apple developer and build the app themselves…
It also seems that even if you have commercial license, this does not cover WebKit that is built into Qt, nor Photon. They don't control those sources.
I don't know how hard it would be to make the qt use the system webkit instead of built-in one.
Regards
Not a big deal. The App Store rules don't permit applications that use their own browsing engine (they must use the WebKit framework supplied by Apple). There isn't a backend for Phonon that would work on iOS anyway, so if one was going to implement a multimedia engine, it would make more sense to use the Qt Mobility APIs. Phonon is being deprecated in favour of native (Qt) multimedia APIs…
You guys should read your LGPL. Section 6(a) allows you to statically link, provided you provide source and/or object code so the user can modify and relink to create a modified executable. Users using the App store will probably never do this, but my understanding is that you have to at the very least make an offer to do so as part of your EULA.
Also, the conditions of the commercial Qt license forbid the migration of code produced under the LGPL to a commercial license, so I don't think a commercial publisher would be able to statically link and distribute such code.
Anyway, thumbs up on both your houses, I look forward to these projects getting traction.
IANAL, but this is what Nokia has to say about it.
http://blog.qt.nokia.com/2009/11/30/qt-making-the-right-licensing-decision/
Note the handy reference chart.
Also from http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html
6a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)
I hope static linking will not be a problem. Also that the app store add DRM to it may also complicate the issue.
Regards,
Mark Kromis
@llamatronique: So you're more or less just repeating what's been written previously in this topic… ;)
In any case that condition in the Qt commercial license you refer to, is to prevent LGPL code from being moved to a more restrictive license. If you've never released the software (in source or object form), it's not relevant…
both the points I made were completely new pieces of information.
the provision in 6a for statically linking under the LGPL wasn't mentioned at all. all that was mentioned is that only dynamic linking is allowed which is a common misunderstanding.
also… (typos included, emphasis mine)
from http://qt.nokia.com/products/licensing/
"You must purchase a Qt Commercial Developer License from us or from one of our authorized resellers before you start developing commercial software as you are not permitted to begin your development with an open source licensed Qt version and convert to the commercially license version at a later . The Qt Commercial Developer License includes a restriction that prevents the combining of code developed with the Qt GNU LGPL v. 2.1 or GNU GPL v. 3.0 license versions with commercially licensed Qt code."
i.e. 'developed' not 'released'… so it's mighty relevant.
@llamatronique:
"without a 'publisher' the developer could provide full source for the application under GPL and satisfy GPL licensing. There are some apps which are sold on the App Store that use GPL licensing, the idea being that most users would rather pay $1 than have to become an Apple developer and build the app themselves… "
The opensource/commercial Qt thing is a bit hard to prove if the software hasn't ever been released… Also a bit hard to believe that Nokia would come after their paid customers, but you're right, the license does state that it's not permitted… :)
A bigger issue, which hasn't really been touched on, is that Qt really has much too big a footprint to be used either statically, or dynamically where it must be shipped with the app… ;)
"In theory, the owner (Nokia) could give permission for some aspects of the LGPL to be waived, but without that it's not legal (witness the case of VLC)"
VLC's code in question was released under the GPL, not the LGPL. the GPL prohibits the application of "further restrictions".
http://www.fsf.org/blogs/licensing/more-about-the-app-store-gpl-enforcement
the LGPL also has this clause, however it allows you to distribute '…under terms of your choice, provided…" which may be (and has been) interpreted to allow DRM such as that in the App Store… just as you can deliver commercial software which has software key protection, hardware dongle protection, iris scans, dna profiling checks or whatever).
So no, Nokia doesn't need to give any permission for aspects of the LGPL to be waived in order for their code to be released on the App Store, provided it is (a) statically linked which it needs to in order to comply with the app store terms and (b) the terms are met in section 6a of the LGPL.
anyway, assuming you meant to cite the GPL, you then contradict that by saying:
"…without a 'publisher' the developer could provide full source for the application under GPL and satisfy GPL licensing."
sorry? first it's not legal, and then it's perfectly ok?… according to the FSF it is not. personally i think their interpretation is convoluted and pretty shakey, but it's up to the author of the code to enforce according to their interpretation, and so far at least two takedowns have occurred as a result. if you release GPL code on the app store you run that risk, and apple have shown that they are willing to just take it down to give the relevant copyright holders the benefit of the doubt.
"The opensource/commercial Qt thing is a bit hard to prove if the software hasn't ever been released… Also a bit hard to believe that Nokia would come after their paid customers, but you're right, the license does state that it's not permitted… :)"
good luck with that… nokia is a huge multinational corporation, not a care bear, and paid customers are more vulnerable as they have means to pay. i don't think it is at all wise to try to predict what their course of action might be for a perceived breach of the license agreement.
"A bigger issue, which hasn't really been touched on, is that Qt really has much too big a footprint to be used either statically, or dynamically where it must be shipped with the app… ;)"
based on what evidence?… Qt runs fine on symbian and meego devices, most of which have less resources than iOS devices, and the components generally used for mobile devices (mobility, declarative) are lightweight and designed specifically for this purpose.
also, static linking only links in the code you actually use, so the 'footprint' is entirely application dependant. most games link statically to 3rd party game engines of varying degrees of complexity in the same way, and that doesn't seem to be a 'big issue'.
@llamatronique: "based on what evidence?… Qt runs fine on symbian and meego devices, most of which have less resources than iOS devices, and the components generally used for mobile devices (mobility, declarative) are lightweight and designed specifically for this purpose."
I'm not talking about memory footprint (I haven't looked at that). BTW it's not shipped with the app on those systems, it's pre-installed, which is the point I'm making. If you have to ship the whole of Qt with your app, it makes it a lot bigger than the 500Kb-1Mb app that you could have if you didn't have to ship the framework…
I would be very surprised if you could fit your app and the Qt framework into the 10Mb limit that the AppStore has for 3G downloads… (in fact, apparently, Qt apps for iOS are 20Mb+ with statically linked Qt) ;)
"There is debate in the legal and open source communities as to whether static linking is permissible under the LGPL version 2.1. The uncertainty is caused by an inconsistency in the LGPL license itself. The LGPL v. 2.1 defines “a work based on the Library” to be anything that would be a derivative work under copyright law. Unfortunately, the LGPL is neutral from a legal jurisdictional point of view – the question of which jurisdiction’s copyright laws should be considered is undefined and open to interpretation depending on numerous factors such as where the application is distributed, created, etc. In many jurisdictions, an application that is statically linked with the LGPL licensed library will be considered a derivative work. Thus, in accordance with the LGPL’s definition of a “work based on the Library”, a statically linked application could be subject to the provisions regarding modification and distribution of the Library included in Sections 1, 2, and 4 of the LGPL. Those who believe that static linking is permissible under the LGPL v. 2.1 primarily refer to Sections 5 and 6(a) of the LGPL to support their argument. Those arguing that static linking is permitted under the LGPL argue that Section 5 specifically acknowledges that the executable that results from the static linking of the application with the library is a derivative work of the Library. However, the language in Section 5 gives some indications that despite the executable being a derivative work, it can be distributed in accordance with Section 6. Unfortunately, it is precisely this acknowledgment that the executable may be a derivative work that creates the inconsistency within the license.
Due to the varying opinions on whether static linking is permissible, it is Nokia’s recommendation that Qt users dynamically link their applications to the LGPL-licensed Qt libraries so as to ensure that the application source code, which a user may want to keep private, does not have to be shared with downstream recipients. Ultimately, however, this decision is one of risk and the individual Qt user should make this decision based on their own specific circumstances. Some of the recent posts have stated a desire to have Nokia’s position on whether static linking is permissible. Because the LGPL v. 2.1 source code obligations can be enforced by any recipient of the application and LGPL-licensed library, Nokia’s position on this issue is not particularly relevant and is merely one opinion among many."
you can't ship the whole qt library on iOS devices, as only static linking is supported, so the footprint of the 'entire' of qt is moot. this is a condition which likely to never change.
as far as the 'derivative work' argument is concerned, that interpretation should of course be given serious consideration, but as far as I know it is still considered ambiguous because it has never been tested. that opinion also seems to me to be quite selective and fails to acknowledge the explicit nature of section 6's preamble.
specifically, it is 'as an exception to the sections above', so even if it is unambiguous that the work is a derivative (which section 6 itself states) then sections 1-5 don't apply except where specifically referenced in 6a with respect to the 'Library'. it is clear to me at least, that the language used to define the 'work', the 'Library' and the 'executable linked with the Library' are also unambiguous.
so i still strongly stand by the argument that in its current form, the LGPLs provisions are sufficient, however it would make a great deal of sense for nokia to provide an exception for such cases to eliminate uncertainty. i guess it's up the them to decide what 'Qt Everywhere' actually means.
anyway, none of this obviously constitutes legal advice. the aim of the exercise is to argue for 'free' distribution of shared code according to the spirit of the various licenses. restricting distribution of software based on prejudice against a users' choice of platform is becoming an absurdity which needs fixing.
Based on experience with embedded Linux (on ARM), the executable for a QML app, if linked statically, is in the region of 55-60Mb (which will be more or less the same for iOS). That's before you start including resources (artwork etc.). The minimum you need is: Core, Gui, Declarative, Network, Script, Sql, Svg & Xmlpatterns… Not much of Qt left that you're not including there… And a *massive* footprint for a mobile app executable… ;)
are you not using dead stripping? (ld -dead_strip).
ok, fair enough. after linking a minimal qml app on a mac, the best I can do is 22MB, there's probably additional savings to be made (i didn't use -Os for the libs), but probably not what's you might consider reasonable.
dead stripping isn't as effective as it used to be.
The linker can't strip out much in a QML app. Anything that could possibly be used by any code path in Declarative will be left in. How would the linker know what a QML script was actually using? BTW, ARM object code (Qt libaries) is about 40% bigger than x86. The way to start slimming Qt down would be to #ifdef out parts of Gui (it's the largest single library)…