Before: LGPLv2.1 or LGPLv3 or GPLv2 or pay for a commercial license
After: LGPLv3 or GPLv2 or pay for a commercial license
"LGPL version 3 differs from version 2.1 in two fundamental aspects. It explicitly protects the right of the end user to not only compile their modifications, but also deploy and run them on the target device. This essentially prevents the creation of fully locked-down devices. Secondly, it explicitly includes a protection against patent claims from the entity distributing code licensed under LGPLv3. These two additions greatly help protect the end users’ freedom when using source code licensed under LGPLv3."
Plus they're open sourcing the previous commercial-only components:
Qt Charts
Qt Data Visualization
Qt Virtual Keyboard
QML Profiler
Clang static analyzer
Qt Test Integration
Qt Quick 2D renderer
Also, they're binding to the KDE Qt Free agreement all the editions of Qt, not just the X11 one. This is an important update, especially as Wayland takes off.
Wait, the non-OpenGL renderer for Qt Quick was commercial-only? You literally had to pay them $$$ if you wanted to develop a modern Qt app that actually worked if OpenGL wasn't available or functional (which it far too often isn't)? That's ridiculous. And even now it's only available under the GPLv3, which means that if you need to use any non-GPL-compatible code you have to pony up - and also means that distros probably can't safely ship it.
Yeah it's really bad. I feel for anyone that has stuck with these old-school 'cross-platform toolkits' over the last few years, they have really been missing out for a while now. On top of this, the whole scene is just stagnant and decades out-of-date from my experience (trying to get into Qt a couple of years ago). There are no devs there, you're basically on your own.
If you want to make cross-platform desktop apps (with opportunities for mobile too), I'd recommend hiring people who know web-dev and start looking at Electron [0] and NW.js [1]. Then you can tap into the web ecosystem with its (enormous, company-backed) massively vibrant frameworks, libraries, tools and communities.
It really doesn't make sense to use things like Qt, wxWidgets, GTK anymore (opinion - willing to be proved wrong).
I think you are wrong on pretty much everything you've stated here.
> There are no devs there, you're basically on your own
There is an extremely active mailing list and IRC channel (several official ones actually) where you can almost always get in touch with the actual Qt devs and others who use it for support without paying them anything. There are over 500 people in the IRC room right now.
> If you want to make cross-platform desktop apps (with opportunities for mobile too), I'd recommend hiring people who know web-dev and start looking at Electron [0] and NW.js [1].
Maybe when Web Assembly (or whatever its called) becomes a thing performance will be tolerable but I have yet to come across a web application that doesn't run incredibly slowly. I use Atom for a basic code viewer right now and it is pathetically slow compared to any native applications (GEdit, Kate, Geany, etc)... and this is on a desktop machine. I can't imagine anyone creating a remotely complex web application on mobile and expecting any sort of reasonable performance. Text editors should be some of the faster applications -- imagine creating something that's media rich like a music player, a video or photo editor; it would be a disaster.
Also regarding your "with opportunities for mobile too" comment, you know Qt is supported on iOS, Android, WinPho, BlackBerry, Sailfish right?
> massively vibrant frameworks, libraries, tools and communities
Yeah, its not like the native software community doesn't have that or anything. Unlike web tools, native tools have been developed for far longer and they are more robust and reliable.
>It really doesn't make sense to use things like Qt, wxWidgets, GTK anymore
Yes, if you don't care about performance and all the things web frameworks miss out on (how's that GL support looking? Native is getting ready to support Vulkan -- WebGL is still stuck on the ES2 equivalent) then jump on board the web app hype train.
You're also completely overlooking embedded where Qt specifically is used extensively. Kiosks, IVIs, small displays for smart appliances, etc.
I don't like the Qt model of using the GPL as a way to get people to go for their very expensive commercial offering and I think a model like Unreal Engine's (give us a share of your revenue) makes more sense as an additional option for smaller devs.
Technically, every distro that ships KDE or any other Qt Quick application that uses SSL is, though one would hope there's an exception for those. Beyond that, who knows? Someone would have to do an audit.
"Commercial license" is the wrong term. You (and they) should write "proprietary". You are allowed to use free software for commercial purposes.
The copyleft licenses simply require you to keep your modifications also free. Many commercial business models aren't possible with copyleft licenses, though.
When people talk about lowercase-f "free", they often aren't talking about copyleft- in my experience lowercase-f "free" is ambiguous to a lot of people. People who know nothing about open source software might assume free-as-in-price. Even people who know quite a bit about open source licensing might use lowercase-f "free" to refer to open source licenses in general, despite RMS and the FSF attempting to own that word in Orwellian fashion.
That's a long way of saying, I disagree with your definition of copyleft as simply requiring you to keep your modifications free- rather, the definition of copyleft simply requires you to keep your modifications also copylefted. I'm sure you know that as well, I'm not nitpicking you so much as using your comment as a starting point for a tangential rant. :)
Of course, if you buy into the FSF's attempt to co-opt the word "free" to only refer to their brand of freedom, what you said makes sense, but their habit of trying to co-opt common, ambiguous words like "freedom" to mean something very, very, very specific that they define is probably one of the top 2-3 reasons why they've driven so many people away from their cause over the past few decades. If they mean copyleft, they should just say copyleft. Trying to co-opt "free" is at best either dishonest marketing (because who hates freedom, right?) or a dishonest rhetorical device. It's used as a passive aggressive way of laying claim to a word that means lots of different things to lots of different people, even within the context of open source licensing. To the FSF's detriment, it confuses every single discussion about their goals, because it's never clear whether someone means free-as-in-beer vs. free-as-in-freedom vs. free-as-in-RMS.
And let's be clear- free-as-in-freedom is a different thing from free-as-in-RMS. Free-as-in-RMS can be a great thing too, I just wish they would be more intellectually honest about it.
You seem to be factually mistaken about an important point. Nobody, not even Richard Stallman or the FSF, uses the word "free" to mean "copyleft". The two are distinct concepts.
For example the MIT license is free, but not copyleft. GPL is free and copyleft. Copyleft ensures that all the derived works (AND those derived from the derived etc.) must also be distributed with a free license.
In practice licenses that people call "open source" are almost always considered "free" by the FSF's terms. I wouldn't say it's a very very specific brand of freedom. It's all necessary to have the user in control. But I agree that "free software" is not a good name, due to misunderstandings about price. It could also be called "user-freedom-respecting software" or "user-controlled software" or "the-users-have-the-final-say-in-how-their-computing-is-done-and-not-the-developer software", but it would be too long.
> might use lowercase-f "free" to refer to open source licenses in general
That's because "free" and "open source" are exactly the same thing. They refer to the exact same set of licenses and software (within epsilon of each other). "Open source" is a term coined in 1998 as a synonym for "free software":
When rms is talking about copyleft, he's not saying it's identical to free software. Copyleft is just a tool he advocates in order to promote free software, but it's not a goal in itself, nor a requirement for software to be free.
> 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.
> 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.
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.
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:
> 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.
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 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.
> 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.
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.
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.
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.
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.
It is a difference (also to the legal department) to use GPL/LGPL software (say, GNU/Linux) or develop (or even release publicly) software that uses components/libraries that are under GPL/LGPL. I think pjmlp was implicitly only talking about the second scenario.
You made a low-effort comment that GPLv3 is the only no-cost licensing option for Qt. But that's not a "fact"; it's still available under LGPL, which makes your comment untrue. That's why you got downvoted.
It looks like you didn't. Qt is still available under LGPL. Both the blog post itself and the top comment here (which is also the thread you responded to) spell that out.
If that's the only point you intended to make, then fine, say that. But you didn't. What you said was that anyone looking for a no-cost option for Qt now has to use GPLv3, or they can pay for a commercial license (and then complain about getting downvoted). These are not the same thing.
The former is something to have a discussion about.
The latter is verifiably untrue, and has massively wasted time for someone not wanting to see the lie get repeated or go uncorrected.
Whenever I hear about QT licensing changes I can't help but wonder if they had started off with a GPL based license and GTK never happened how the whole "Linux on the Desktop" situation would have panned out. Would open source developers eventually opted to just use QT for GUI applications? Would KDE have become the defacto standard DE across the top 10 Linux distributions? Would there have been a unified installation package allowing cross distribution installation of QT/KDE based applications thereby facilitating commercial software vendors being more open to porting their Windows applications to Linux? I realize it's a moot point but having spent my teen to college years heavily invested in Linux and being frustrated with the lack of standards at the time I can't help going down this thought experiment.
It was GPL (or pay license) to start with. I believe you mean you wonder if it had been LGPL to start with. Subtle, yet enormous difference for a library.
As to the speculation, I don't know. Special preprocessing phases to extend C++ are odd. The signals and sockets paradigm is a mixed bag. Plus there are serious trade offs to the entire application framework vs a library choices in the first place. On the other hand, the runtime type system and heavily stylized macro style of GTK's gobject system was certainly an odd duck to say the least.
Personally, between the web, mobile, "modern" UX/UI ideas, desktops that want to be tablets, etc, I think the 20-30 years of GUI exploration is coming up very empty handed. Character cell terminal, and CLI are more popular and mainstream than ever.
No, it was originally not open-source at all, and it was QPL (which was just barely open-source, and crucially GPL-incompatible) for a long time. Of course we're talking a decade ago now.
Heh. Qt was released in 1995 and the The Cathedral and the Bazaar was released in 1997 with the OSI being formed in 1998. This means Qt pre-dates the term 'open source' by approximately 3 years!
Well, to be fair, Qt was aware of the free software movement from near the beginning. Richard Stallman tried to convince them to liberate their code, and resulted in pushing for a free software replacement. The existence of that free software replacement forced Qt's hand and they released their code under the LGPL. The OSI, Eric S. Raymond and the other "open source" people were not involved AFAIK.
Obviously I having some fun with it. Developer/technician/hacker users a different audience. In my office for instance, people can use 'doz/osx/nix. If you walk around, 95% of every monitor you see has at least one terminal open. These are people doing totally different types of work for all sorts of projects.
I suspect a lot of the creative uses of C++ in Qt will fade over time as C++11/14/17 support in compilers improves. There are more options in the language now that would allow the project to move away from so many macros, etc.
I was under the impression that it was only at v2.2 that they finally GPL'd it. Prior it was there "QPL" license. Regardless valid points. I'll always wonder though :)
> Character cell terminal, and CLI are more popular and mainstream than ever.
No they are not -- mobile interfaces are the complete opposite of CLI, and they're more popular than anything else in absolute numbers.
CLI wins on the desktop because its flexibility allows for easier automation of "work", stuff humans don't really want to do, stuff that is still predominantly carried out with keyboard-based workstations (desktops and laptops). What you refer to is basically mainstream OS developers finally recognizing that first-class automation support via text interfaces is extremely efficient for power users in professional settings -- hence the rise of Powershell and the demise of graphic-based alternatives like Apple's Automator.
But that's it. For everything else, graphical icon-based interfaces are much more popular: they allow for easier exploration and are more finger-friendly.
> I think the 20-30 years of GUI exploration is coming up very empty handed
I think you are vastly overestimating the actual "exploration" that occurred over this time.
Windowing toolkits have extremely high barriers to entry as well as high networking effects.
The whole idea of a very hierarchical, single-threaded entity controlling all of your user interaction is very much anathema to modern CPU's. However, we are stuck with it because a new windowing toolkit would take a huge amount of effort.
I would say it's reasonably fair to call Qt's moc system "odd". Not the worst thing in the world. But you'd probably be interested to know that there are some working on experimental fork of Qt replacing the moc and a few other necessary-oddities with C++11 constructs http://www.copperspice.com/
Qt started off with a commercial license in 1995, adding GPL in 2000. But the lack of an LGPL option is what (arguably) lead to the rise of GNOME/GTK when that project started in 1997, because it's the LGPL that allows organizations to write closed-source proprietary software without paying a license fee. [Edit: corrected Qt's original license history.]
Thanks for the correction. I'll update my comment. Either way, GNOME started out as LGPL, and it was the lack of the LPGL in Qt option (added much later in 2009) that I believe lead to GNOME/GTKs larger uptake early on.
The first decade was non-free with later various shades of semi-free. Around the turn of the century it was apparent Gnome was going to dominate the market unless they acted quickly, so they GPLed at that time to maintain relevance. They're still around; guess that strategy worked.
Having lived thru it, the situation was much worse than you imply. Its not that the non-free licenses didn't allow closed source or whatever, they more or less intentionally carefully prevented distros from legally including Qt. Just barely tight enough that on technicalities it failed the DFSG, intentionally. Debian couldn't include Qt and therefore KDE in main until the 2000 relicense.
i don't think so, because it's really hard to write bindings to qt, and relatively easy to write them for gtk. gtk therefore became the default choice for a lot of language communities when they wanted a more modern alternative to tk. had gtk never existed, i think tk could have become a lot more popular, and seen faster improvements, rather than qt taking over the desktop entirely.
I suspect it wouldn't have made a meaningful difference. There are people who are opposed to KDE/Qt for reasons that have/had nothing to do with the Qt license at the time.
GNUStep (the official GNU desktop under a GPL license) predates KDE and it didn't stop KDE from happening.
I am curious what Richard Stallman (or generally FSF) can say about this, This is clearly one of the best thing happening to FSF.
Let be honest, with Gtk's lack of modernity (I don't know what to call it, but despite being gnome guy myself, we should be honest Gtk falls behind very badly these days in almost all category, ease of development is one of the important one), FSF needs a modern Toolkit and Qt can be the one.(Personally, this does not mean I love Qt, no, It designed very tidy, but I hate MOC, changing language is always bad idea in my perspective, you should play by rules, I don't care who does this, Microsoft or anyone else, and MOC does this.)
p.s. yes I know MOC is preprocessor step, but my logic is sound . Programmer does not program in pure C++ when he/she program in Qt. He/She program in Qt version of C++(and compatibility with existing C++ compiler does not change this fact).
> Programmer does not program in pure C++ when he/she program in Qt. He/She program in Qt version of C++(and compatibility with existing C++ compiler does not change this fact).
That's one of the reasons one might use Qt, to use Qt's data structures, etc.
Data structure nothing to do with language , you can implement all of them in any Turing complete language. My point was when you do use Qt , actually you are using specific version of C++ not ISO C++. And being preprocessor, does not change that fact.
> we should be honest Gtk falls behind very badly these days in almost all category
While I agree you'd have to be absolutely nuts to develop an application using GTK+ directly in C (Yes, I think the whole GNOME project is nuts... but it's telling that they adopted Javascript and Vala), the C++ bindings for GTK[0] weren't all that bad when I last looked at them.
Of course, without a MOC equivalent, you can't really beat the slickness of Qt/QML.
My biggest complaint with GTKmm right now is the lack of composite widget support. It's actually nice to develop a GTK+ application in Vala because composite widgets kick ass and remove a huge pain point for just wanting to throw a window up without all the nasty GTK signal connection maddness. Once GTKmm gets that support I'll probably start using it more.
Well I haven't looked at it since Gtk Builder was called Glade, but QML has convinced me that declarative UI markup with sprinklings of code, and custom widgets implemented on the side, is the way to go.
Agreed, hence why composite widget support in GTKmm would be really nice. In Vala you just make a normal class inheriting from whatever your base widget is, decorate it with a [GtkTemplate] attribute and whenever you construct that widget it will use the gtkbuilder XML you referenced in the attribute to construct the widget, binding all the callbacks referenced in the XML with the respective methods on the class.
Until recently C++ hasn't even had compile time reflection that would allow this to work very well, now that C++14/C++17 are adding that I think this would be very doable.
Qt has been available as free software for over a decade. "We're dropping the LGPL version 2.1 licensing option" is hardly more than a minor note and certainly not a game-changer.
You're changing the direction of the discussion. The comment I replied to was an explicit request for Stallman to comment on this announcement. Why would he?
It's great that you can use Qt under LGPLv3, but that was true yesterday, and that's not what this announcement is about.
> I am curious what Richard Stallman (or generally FSF) can say about this
What sort of comment are you looking for? Stallman has written about it before:
> In 1998, the management of TrollTech recognized that they could make Qt free software and continue charging for permission to embed it in proprietary software. I do not recall whether the suggestion came from me, but I certainly was happy to see the change[...]
Licensing has always been one of the reasons I have avoided Qt for some projects, but it looks like these are some major steps in the right direction in this regard. I have a feeling KDE and Waylands future has encouraged this move, but either way I am happy with the direction!
I've felt the licensing situation to be good ever since Nokia added LGPL to Qt licensing options. This extension of Free Qt code is of course excellent news anyway!
This might make it more difficult to ship on locked down platforms like iOS -- LGPLv3 means that the end user must be able to install new versions of QT into your closed source app.
LGPL version 2.1 is no different. There's no change here in that regard. Locked down platforms are inherently incompatible with the LGPL, whether it's version 2.1 or version 3.
Is that really true? As I understand it, anyone can build and put an app on their phone using Xcode, without needing any permissions from Apple. So if an app on the store is LGPL'd, the publisher can make the source available and I can build it and place it on my own phone.
(It's not the main point behind your question, but even if you're sideloading through Xcode, you need an Apple ID. AFAIK, jailbreaking remains the only option to install an app without getting Apple's permission.)
In response to your question: Yes. But, again, the same was true of LGPL version 2.1.
Ah, I didn't know that. I had heard that Apple had relaxed their restrictions a little, but have not tried it myself yet.
When you speak of an Apple ID, do you mean a free one, or the $99 publish-to-the-appstore type? The difference doesn't matter to the LGPL question, of course...
There's some good discussion about LGPL and app stores at https://lwn.net/Articles/526355/ - the comments give a good explanation about why you could get away with a LGPL app, even though there's no free way to re-link the program.
Now, if you could use Xcode to install an app on your own phone, without any other account or gatekeeper, then presumably (I guess), GPL'd apps could also be allowed on the store?
A lot of apps can't effectively be side-loaded and retain their features. Most of these problems stem from not having the real developer's certificates to sign the app with.
For example, you can't get the source for an AppStore app, side-load it, and have it get notifications meant for the original app.
The same applies to IAP purchases made with the original app (they won't be available to the re-created app).
So, in the very least, even if, generally, LGPL with side-loading is ok, there are definitely some apps where it would still be not.
Good point about the notifications & IAPs, I hadn't thought of that.
They make the licensing even murkier - you could envisage a situation where even if you had the app source code and the ability to build and install the app on a device, the app is worthless because a key feature depends upon secret keys that you have no access to. That's getting closer and closer to tivo-isation.
> When you speak of an Apple ID, do you mean a free one, or the $99 publish-to-the-appstore type?
I don't know. Is that something you're interested in? Why not look into it?
> Now, if you could use Xcode to install an app on your own phone, without any other account or gatekeeper, then presumably (I guess), GPL'd apps could also be allowed on the store?
Again, the problems with the App Store are specific to the terms, conditions, and restrictions that Apple chooses for it. Whether or not you can side load your own apps using Xcode doesn't change that. Problematic App Store terms are still problematic. "Yes, you can build an app under <license> for your own device in Xcode" does not automatically mean, "Yes, you can distribute apps with <license> on the App Store."
With regard to distribution on the app store for iOS, neither GPLv3 nor LGPLv3 change anything compared to GPLv2 or LGPLv2.
It is a very common misconception that GPLv3 and LGPLv3 would require that code covered by them on the app store include the necessary signing keys or whatever else is needed to make a modified app work with Apple's DRM so it could be installed.
People think this because GPLv3 includes an "anti-Tivoization" section meant to stop people from doing what Tivo does, which is ship a locked down device full of GPL code that you cannot replace even though they give you the source code.
Here is the relevant part from GPLv3 section 6 (which is incorporated into LGPLv3 by reference from LGPLv3 section 4(e)):
If you convey an object code work under this section
in, or with, or specifically for use in, a User
Product, and the conveying occurs as part of a
transaction in which the right of possession and use
of the User Product is transferred to the recipient
in perpetuity or for a fixed term (regardless of how
the transaction is characterized), the Corresponding
Source conveyed under this section must be
accompanied by the Installation Information.
"Installation Information" is defined thusly:
“Installation Information” for a User Product
means any methods, procedures, authorization keys,
or other information required to install and execute
modified versions of a covered work in that User
Product from a modified version of its Corresponding
Source. The information must suffice to ensure that
the continued functioning of the modified object
code is in no case prevented or interfered with
solely because modification has been made.
For the requirement to provide "Installation Information" to apply, there are two conditions that must be met.
First, the code has to be conveyed in, with, or for use in a "User Product". The term "User Product" is defined a couple paragraphs earlier:
A “User Product” is either (1) a “consumer
product”, which means any tangible personal
property which is normally used for personal,
family, or household purposes, or (2) anything
designed or sold for incorporation into a dwelling.
In determining whether a product is a consumer
product, doubtful cases shall be resolved in favor
of coverage. For a particular product received by a
particular user, “normally used” refers to a
typical or common use of that class of product,
regardless of the status of the particular user or
of the way in which the particular user actually
uses, or expects or is expected to use, the product.
A product is a consumer product regardless of
whether the product has substantial commercial,
industrial or non-consumer uses, unless such uses
represent the only significant mode of use of the
product.
iOS devices, and Macs for that matter, are clearly "User Products", and so no problem here. Software sold through either the iOS or the OS X app store is being sold for use in a "User Product".
The second condition is that the software conveyance occurs "as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized)".
When you go to the app store and buy and download some random app for your iPhone (the "User Product") that conveyance is NOT part of a transaction where the right of possession and use of the "User Product" (your iPhone) was transferred, and so the anti-Tivoization provision does not apply.
If Apple were to use GPLv3 or LGPLv3 software in the iOS software, or in any of the bundled apps they ship with the phone, then the anti-Tivoization provision would apply to them, and they would have to give you the "Installation Information".
In short, the (L)GPLv3 anti-Tivoization provisions are narrowly written to only apply to Tivo-like situations: hardware vendors shipping locked down GPL code with their hardware.
There is a problem with distributing GPL (any version) or LGPL (any version) on the app store, but it has nothing to do with DRM or ensuring that users have the technical ability to install modified versions. The problem is with the app store TOS, which users must agree to in order to be allowed to use the app store.
The TOS prohibits sharing and reverse engineering. These terms are incompatible with GPL. If the app store was just a marketplace that allowed sellers and buyers to match up and exchange payment, and the actual software download came from the developer's servers this might be OK, since Apple would not actually be involved in the copying and distribution of the software so nothing they do would matter from a GPL standpoint.
Unfortunately, that's not how the app store works. The developer uploads one copy of the app, and then it is Apple that makes and distributes a copy every time someone downloads. That means that Apple has to be in compliance with the license in order to legally distribute the software.
The developer who uploaded the software has almost certainly given Apple an implicit license to do this, regardless of what the license the developer purports to distribute under says. It's been a long time since I've read the Apple developer agreement, but I'd expect there is also something explicit in there that you give such a license to Apple.
So, as long as all the GPL code is owned by that developer, then the developer is really distributing on the app store with GPL + an exception to allow Apple to distribute.
If the developer incorporates any GPL code from others, though, then unless those others have also granted Apple a GPL exception it will not be legal for Apple to distribute that app.
Thank you for the comprehensive answer. So the situation is essentially unchanged. QT is good everywhere other than iOS.
(I know that one isn't supposed to post thank yous on HN but this post deserved more than just an upvote and the thread is old now so this shouldn't junk things up too much.)
Yeah. The two differences seem to be that end-users are guaranteed to be able to use their own version of Qt (because Qt is LGPL and the user should be able to modify it) and that now there's more protection against patent claims.
Somebody correct me if I'm wrong or missed something.
EDIT: oh, and I forgot the GPLv2 -> v3 bit, but that doesn't affect your use case.
Yes Dual License means Open Source and Commercial License.
> At the same time, this allows us to open up the parts of Qt for application development that have previously only been available under commercial terms to the Free Software community, unifying the product.
This sounds really good! I don't understand why people would buy the commercial license, though, so I must be missing something. With the LGPL, it seems like you could have closed source and just provide a copy of Qt.
* Static linking of closed source applications
* Apple's app stores
* Custom Qt modifications without need to release the changes
* Qt for Device Creation
* Support, supposedly with prioritized bugfixes
After: LGPLv3 or GPLv2 or pay for a commercial license
"LGPL version 3 differs from version 2.1 in two fundamental aspects. It explicitly protects the right of the end user to not only compile their modifications, but also deploy and run them on the target device. This essentially prevents the creation of fully locked-down devices. Secondly, it explicitly includes a protection against patent claims from the entity distributing code licensed under LGPLv3. These two additions greatly help protect the end users’ freedom when using source code licensed under LGPLv3."