Qt goes LGPL! (part two)

Aleksander Demko, June, 2015

Background

I celebrated when, almost seven years ago, Troll Tech licensed the venerable Qt library under the LGPLv2. This meant that you could use this library without having to get a costly commercial license, greatly expanding its usability and use.

However, many things have happened since then. Nokia bought Troll Tech and did this as a way to try to increase developers on their mobile platforms. To Nokia, sacrificing the commercial Qt license income was nothing compared to their phone sales and thus the trade off made sense. However, Nokia proceed to make some epic mistakes in the mobile world. The first was having Symbian, a visually stagnant operating system with a terrible programming interface, a non-unified app store and poor touch support. The second was hiring Stephen Elop, a Microsoft trojan horse of sorts that proceeded to hitch the struggling Nokia not to Android, the dominant mobile operating system but rather to Microsoft's mobile operating system with its negligible market share.

Unsurprisingly, the company failed spectacularly and Elop delivered its shattered remains to Microsoft to buy up for cheap. Microsoft then proceeded to layoff many of the staff and now uses what's left as a launch platform for what remains of their mobile OS strategy. Somewhere along the way the Qt part of Nokia was sold off to a small company called Digia, which is where it remains today.

Now Digia, lacking a larger revenue stream from which to subsidize Qt development needed Qt to be profitable by itself. It inherited the LGPLv2 situation from Nokia, and for the 4.x series of Qt it continued to release them under that license, even though it sacrificed commercial license sales

Enter Digia, Qt 5.x and mobile

For the Qt 5.x release cycle things get a little murky. 5.x added some new features the most notable of which is support for mobile platforms such as Android and iOS. Wow, you think to yourself, a free modern toolkit that can work on all the desktop and mobile platforms.

The web page says it's all open source. That's a broad question though, so it'd actually simpler and more direct to ask a more specific one:

Can one use the open source licensed Qt to write any type of Android applications and sell them on Google Play app store?

This should be a straightforward to answer. However, you won't find the answer anywhere on Digia's site. Instead, you'll find:

• Long proclamations on how Digia is a defender of free software and the free software foundation's (FSF) ideals. They talk at length about the FSF's "four tenants" and how they promote them. They even use the GNU Mascot image. This is all really ironic because just on the previous page they, you know, they just happen to sell commercial licenses that let you write as much non-free software as you'd like.
• They use vague and implicative language when you choose the open source license, nudging you to buy a commercial license. Rather than explicitly telling you what you can or can't do, they "leave it up to you" and tell you to "see a lawyer."
• They never commit to saying anything definitive on how you can or can't use the open source version. They tell you to "go check the licenses" and that "you should be sure," "we can't tell you" and "see a lawyer" They know very well what use cases people would be typically interested in and could easily provide some examples of what they can and cannot do.
• Specifically, they ominously allude to the relinking requirements of the LGPLv3 with no mention of its implications or limitations. They engineered the library (and build systems) and very well know how it links together and how it will be deployed.
• The FAQ, the traditional document of last resort doesn't help you at all. You're telling me the document that contains frequently asked questions shouldn't contain this question, which seemed to be frequently asked?
• Employee blogs and forum posts are equally vague. You can tell there has been some training on this topic from up above. Common developer employees don't talk about it at all, and the employees that do seem to repeat the same scripted language.

Having said all this, please note that my critique us really just about the messaging:

• I love Qt and I think it's an awesome multi-platform desktop library that allows developers to make nice & fast platform-native applications.
• I don't begrudge Digia from making money. Programmers have to be fed and it'd be shame if the business doesn't survive.
• I just wish they were more upfront with the business model. It shouldn't take me, a veteran Linux user and developer of 20 years hours of googleing to figure out your licensing scheme and the possible use cases.

No. I'd don't think you use it to write mobile apps.

This is my personal opinion/answer on the matter, deduced both from the tone of Digia's messaging and my understanding of the licensees involved. My reasoning goes like this:

• The mobile parts of the Qt library are licensed under LGPLv3 license, and not the LGPLv2 that the desktop ports use. Why's it different? There has to be a reason.
• Version 3 of the LGPL license is drastically different than version 2. The version 3 licenses added clauses about how software can be distributed and not just about the source code itself. Specifically it tries to enforce that if you've been given the software through a "locked down" platform, that instructions and access must be given to replace that software on the device. It was designed to fight against "Tivoization," a term Richard Stallman (RMS) made up after Tivo, who released Linux based devices that only ran their specific builds of the kernel. Although RMS uses the term in a derogatory manner, Tivo did nothing wrong or violate any licenses.
• However, I don't think Tivoization to be a problem. Many others, including Linus Torvalds seems to agree. Although it allows a hardware vendor to lock control a platform and limit it's utility, it could also be used for reasons of security, auditing and compliance. Regardless, should a software license dictate the hardware it runs on? Isn't this falling out of scope of the princples of freedom. Even on locked down hardware, any changes to the source code would still have to released, so the community benefits.
• Regardless, Tivoization is alive and well in all major mobile app stores and platforms. Typical Android phones use signing keys to restrict OS bootup and all application installations. Although it makes the devices less useful as general purpose computers, this control allows the manufacturer to secure the operating environment for both the OS and the sandboxed applications. Users seem to be ok with this as reduces the chances of viruses and phishing attacks.
• The most common method of distrubution on Android is via the app store. On iOS, it's the only way. This means that if you want to distrubte your app on those platforms you have to put them in the store.
• So if I have to put my app in the app store, won't I be violating the Tivoization clauses of the LGPLv3 license? Do you have to publish the signing keys? Do users have to side load their relinked versions? What if they can't do that (say, on iOS)? What if I have use anti-piracy mechanisms in my application, will my app still be expected to run when sided loaded? These critical points lead me to conclude that you cannot use the LGPLv3 to make app store applications. I'd love for Digia to correct me on this though.
• As an aside, it's interesting to note that in Digia's online FAQ they reassure purchases of their commercial licenses that they won't get any LGPLv3 libraries.

Is the sunning setting on the GPL licenses?

There seems to be a general trend going on in industry as a whole. The GPL ("copyleft") family of licenses seem to be on the decline and the more permissive (eg MIT) seem to be on the rise. Some reasons for this could include:

• GPL licenses are mostly avoided by businesses. In most cases, the business doesn't even want to modify (or hide the modifications) of open source libraries, they just want to use it without licensing hassles or risk. But the viral nature of the GPL licenses easily scare them off depriving GPL projects of users and possible contributors.
• This fact is so well know that often companies will use the GPL licenses to release "free" or "lite" versions of their application that contain less features than their main offering. They know companies won't use it in production (so no sales are sacrificed) while giving them positive PR with the open source community. This is known as the "open core" business model and although it sounds great at first, it's actually quite cunning as the open source version never gets community adoption, as the the company still has defacto control: they'll refuse patches without a license grant and not accept enhancements that might compete or encroach on their closed source offerings.
• There are numerous GPL licenses, causing confusion and conflict. First, pick a license (GPL, LGPL or AGPL), a version (2 or 3) and a clause ("only this version" vs "or later") That's 12 variants right there. Do you have two projects with different GPL licenses? They might conflict with each other. You better consult the 12 by 12 matrix to see fit they're compatible. I'm not joking, there's actually a matrix! GPL FAQ
• Lots of people don't share RMS's Tivoization concerns that the v3 licenses are trying to address and think it's an overstep of what a source code license should dictate
• In fact modern mobile computing depends on the Tivoization model and any chance to stop it is gone. What's more likely? That the GPLv3 licenses will convince the iOS and Android app stores to loosen up or that open source developers will simply switch to other licenses?

Ending Thoughts

As a programmer, I now prefer non-GPL open source licenses (like MIT) for both for my own software and for software I use. If a library is LGPLv2 I'll use it, but I stay clear of libraries with any of the other GPL variants (especially the v3 ones). As a user I'm not so particular.

I wish Ubuntu or Google would just buy the Qt code base and release it under a uniform license. Some motivations on why they should do this would fill another blog post.

For now I guess I'll stick with platform specific SDKs for mobile UI development, and generally treat UI code as throw away. The platforms are still young and rapidly changing, so who knows what will happen in the future.