[QGIS-Developer] FYI: Qt LTS Releases To Be Restricted To Commercial Customers

Nyall Dawson nyall.dawson at gmail.com
Mon Jan 27 15:27:30 PST 2020


On Tue, 28 Jan 2020 at 02:34, Paolo Cavallini <cavallini at faunalia.it> wrote:
>
> Thanks Even. As I read it, this essentially means we are more or less
> forced to use the latest version, not the LTS (or to stick to an older
> one). This could mean more bugs.
> Any deeper insight?
> Cheers.

It's an unexpected move, but I can honestly understand the rationale behind it.

Here's my analysis of the impact it will have on QGIS (using quotes
from https://lists.qt-project.org/pipermail/development/2020-January/038316.html)

> "One is a change in policy regarding the LTS releases, where the LTS part of a release is in the future going to be restricted to commercial customers. All bug fixes will (as agreed on the Qt Contributor Summit) go into dev first. Backporting bug fixes is something that the Qt Company will take care of for these LTS branches. We’ve seen over the past that LTS support is something mainly required by large companies, and should hopefully help us get some more commercial support for developing Qt further."

Doesn't greatly affect us, since this change mainly has distro level
impact. Of our supported platforms, we have:

- linux: Qt releases are a distro responsibility, so no direct impact
to us there. Distros will either need to manually backport fixes from
Qt current releases to older releases, or update more frequently to
newer Qt releases. I can understand this will be painful for distro
level Qt maintainers, but for our users there's likely to be minimal
impact, and possibly we'll see a **better** end user experience IF
distros decide to start updating Qt major releases more frequently.
- mac: Zero impact. The mac builds use infrastructure that regularly
updates to the current Qt versions and don't use LTR releases.
- Windows: Zero impact -- osgeo4w doesn't use Qt LTR releases, and
doesn't regularly update Qt versions. It's done on an ad-hoc basis and
will likely continue this way

On the flip side, if this move increases the revenue stream and
viability of the Qt company, then it's a GOOD thing for us.

> "The second change is that a Qt Account will be in the future required for binary packages. Source code will continue to be available as currently. This will simplify distribution and integration with the Marketplace. In addition, we want open source users to contribute to Qt or the Qt ecosystem. Doing so is only possible with a valid Qt Account (Jira, code review and the forums all require a Qt Account)."

Almost zero impact. A bit of annoyance for the handful of QGIS
developers who build QGIS using custom (non distro) Qt versions or who
use upstream Qt Creator releases, but likely all those already have Qt
Accounts for use on the Qt bug tracker.

> "The third change is that The Qt Company will in the future also offer a lower priced product for small businesses. That small business product is btw not limited to mobile like the one Digia had some years ago, but covers all of Qt for Device Creation."

Zero impact.

Lastly, from https://www.qt.io/blog/qt-offering-changes-2020 :

> "The offline installer will become available to commercial licensees only"

This is the biggest impact. I understand that osgeo4w qt libraries are
based off the offline installer packages (correct me if I'm wrong here
Jürgen!). The consequence of this is that we'd need to self-build Qt
libraries for inclusion in osgeo4w and the QGIS installers. Outcome:
more work for the Windows installer maintainers̶.

Nyall


More information about the QGIS-Developer mailing list