With an apparent blame on the novel coronavirus, The Qt Company is said to be considering restricting new Qt releases to paying customers for a period of twelve months in an effort to boost their near-term finances.

Earlier today The Qt Company published a 2020 Qt road-map while following that a Phoronix reader tipped us off to the latest discussions between KDE, the Qt project, and The Qt Company.

KDE and the open-source Qt folks have been in discussions with The Qt Company especially with the restrictions announced back in January by The Qt Company that LTS point releases might only be available to commercial customers, Qt Accounts being needed for binary package downloads, etc.

Dear KDE community,

the relationship between the KDE community, the Qt project and The Qt Company 
has always been close and beneficial for all three.

* The Qt Company benefits from having a large and healthy community of 
contributors, developers and experts around their product.
* KDE benefits from being able to use Qt and to contribute directly to Qt.
* The Qt project benefits from having the company as a steward and very large 
contributor, and having KDE as a large and well-known sub-community.

Last December, I published a document explaining the win-win-win-relationship: 
http://www.olafsw.de/a-better-qt-because-of-open-source-and-kde/


Unfortunately, The Qt Company is currently considering to stop this healthy 
cooperation.

Fortunately, the KDE Free Qt Foundation exists, which secures the continued 
existence of Open Source Qt:
https://kde.org/community/whatiskde/kdefreeqtfoundation.php
Together with Martin Konold, I represent KDE in the board of the foundation.


I will now give you a bit of background information.

During the past two years, there have been negotiations between The Qt Company 
and the KDE Free Qt Foundation for updating the contract.

Our goals in negotiations:
* helping the company increase their revenue without harming the Qt project or 
the KDE community
* strengthening the protection of the Qt project and of the KDE community
* avoiding a parting of ways between The Qt Company and the Qt+KDE communities

Concrete areas included in the negotiations are:

* Fixing the incompatibility between paid Qt license terms and using or 
contributing to Open Source
(“Prohibited Combination” in https://www.qt.io/terms-conditions/ )
* Fixing the license incompatibility between the Qt Design Studio (which is 
only partly Free Software) and our existing contract with the company
* Making our contract with the company stronger, requiring them to make 
immediate Free Software releases of Qt (currently, they are allowed to delay 
by 12 months) to ensure the availability of LTS security fixes for KDE
* Updating our contract to include Wayland
* Evaluating contract changes suggested by the company aimed at making the Qt 
business more profitable, for example the option of selling bundles of Qt with 
other software, or making integrations with proprietary third-party software 
possible


One setback in the negotiations has been an announcement of The Qt Company in 
January: https://www.qt.io/blog/qt-offering-changes-2020
They announced that LTS releases of Qt will only be available for paid license 
holders. It is still unclear what this implies for contributions to Qt and for 
the sharing of security fixes between the various parties (including The Qt 
Company, the many Qt experts contributing, the KDE community, and Linux 
distributions).

At an in-person meeting in Frankfurt on March 6, we nevertheless managed to 
lay the groundwork for a possible path forward, continuing with an approach 
beneficial to all sides.


But last week, the company suddenly informed both the KDE e.V. board and the 
KDE Free QT Foundation that the economic outlook caused by the Corona virus 
puts more pressure on them to increase short-term revenue. As a result, they 
are thinking about restricting ALL Qt releases to paid license holders for the 
first 12 months. They are aware that this would mean the end of contributions 
via Open Governance in practice.

Obviously, it cannot be in the middle- and long-term health of The Qt Company 
to separate itself from the very strong Qt + KDE communities.

We hope The Qt Company will reconsider. However, this threat to the Open 
Source community needs to be anticipated, so that the Qt and KDE communities 
can prepare themselves.

The Qt Company says that they are willing to reconsider the approach only if 
we offer them concessions in other areas. I am reminded, however, of the 
situation half a year ago. We had discussed an approach for contract updates, 
which they suddenly threw away by restricting LTS releases of Qt instead.


What does this mean for the future of Qt and for the future of KDE?

All software changes in Qt will still be available at as Open Source as 
required by our contract – maybe with a delay of 12 months if the company 
decides to part ways with the communities.

We will continue to work on a contract update that helps all sides. But even 
if these negotiations were to be unilaterally stopped by The Qt Company, Qt 
will stay Open Source, and KDE will be able to use it. I am also absolutely 
sure that the Qt + KDE communities will continue cooperation on new features, 
bug fixes, and security fixes, even should The Qt Company decide to forgo the 
benefits of cooperation.

I invite The Qt Company to stay with us. It will be worthwhile.


Best regards,

Olaf

There is not much fun in creating your own desktop applications if you can't share them with other people — whether than means publishing it commercially, sharing it online or just giving it to someone you know. Sharing your apps allows other people to benefit from your hard work!

The good news is there are tools available to help you do just that with your Python applications which work well with apps built using Qt5. In this tutorial we'll look at the most popular tool for packaging Python applications: PyInstaller.

This tutorial is broken down into a series of steps, using PyInstaller to build first simple, and then increasingly complex PyQt5 applications into distributable EXE files on Windows. You can choose to follow it through completely, or skip ahead to the examples that are most relevant to your own project.

Last weekend would have been the traditional annual KDE PIM meeting in Toulouse, but with travel being largely shut down in Europe we had to do this virtually. That meant missing out on the culinary treats of being in France, but we got a few things done nevertheless.

[...]

Nico has been working on this, eventually enabling platform calendar abstraction behind the KCalendarCore API. So the same application code could be using a calendar from Akonadi on a desktop system and the Android calendar on a phone.

We hopefully managed to sort out the remaining conceptual questions for this (modeling hierarchies, lazy population of expensive calendars, separate classes for the calendar metadata or not).

Moving PIM modules to KDE Frameworks

KDAV is nearing completion for transitioning to Frameworks after the 20.04 release (so in May or June). A final review pass resulted in a few more improvements and API cleanups.

Following KDAV the possible candidates are the KGAPI library, which is already used externally and thus would benefit most, as well as the various email frameworks (MIME, IMAP, SMTP).