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.
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."