
Qt Could Go Proprietary, KDE Relationship and Qt-Based Free Software in Jeopardy - v-yadli
https://linuxreviews.org/Qt_Could_Go_Proprietary,_KDE_Relationship_And_Qt-Based_Free_Software_In_Jeopardy
======
RcouF1uZ4gsC
> while commercial developers of immoral proprietary software have been
> required to license the toolkit under a commercial license.

I wish free software advocates would stop calling proprietary software
immoral. If anything, free software underlies and has enables the locked in,
sever based, surveillance monetizing world we live in.

Back when software ran on your machine, you defacto owned your data because it
was on your machine. Now, because the data is not on your machine, you don’t
own the data.

Selling proprietary software for money is a lot less immoral than using free
software to sell user data for money, or using scale to run roughshod over
regulations which seems how a lot of software engineers are ultimately paid
these days.

~~~
kick
Oracle solely sells proprietary software that users can't own; AWS is
proprietary software users can't own; Microsoft's suite is proprietary
software users can't own: proprietary software is still causing the most harm,
people who defend proprietary software are still acting incredibly stupid
about it.

Like seriously, "seems how a lot of software engineers* are ultimately paid
these data" (by proprietary companies). Google is a proprietary software
company, so is Facebook, so is twitter. All companies that relentlessly abuse
users.

Free software advocates meanwhile have a social network with a few hundred
thousand active users, they've got privacy-respecting search engines, and have
operating systems that don't spy on you.

Proprietary software caused the problems you're ranting about, and your
comment reeks of "I work at a company that sells proprietary software and am
trying desperately to pin my own sins on people releasing software making the
world more free."

I'm nowhere near a free software extremist. Many of the people I find
admirable release proprietary software. But your comment is ridiculous.
Proprietary software is undeniably immoral.

* "Engineers" is the wrong term because software engineers don't exist.

~~~
cormacrelf
I'm not saying they're right, but I think the point was that:

\- GPL code can be used in a program you do not distribute

\- Not distributing can be done by running it on a server instead of local
machines

\- Run on server almost always means users don't own data

It's missing a step, which is that the GPL code in the world was so important
that people NEEDED to use it so much that they were willing to change the way
they distribute (or don't) their software... that's a pretty tough claim to
make out. What's the evidence for that?

~~~
TaylorAlexander
I don’t understand your bit at the end but I just wanted to mention that the
AGPL license was created by the FSF in 2002 to address this network loophole.

[https://en.wikipedia.org/wiki/Affero_General_Public_License](https://en.wikipedia.org/wiki/Affero_General_Public_License)

~~~
tsimionescu
And recently made irrelevant by Amazon, who discovered how to defeat its
purpose while fully respecting its terms (copy the code without any
contributions back to the authors, so you don't get any sharing back; do all
of the hard work of deployment logic in code you do not share, ensuring people
can't really move to self-hosting if they want to patch the software in any
way).

The AGPL is one of the strangest licenses to me, coming from a foundation that
considers running code you can't read or modify as a violation of your human
rights, but also making a license designed for software running on someone
else's computer entirely, where you have no possibility of any amount of
control.

~~~
cycloptic
That is not the purpose of the AGPL. If you were trying to use the AGPL as
some kind of trojan horse to get access to someone's deployment code, then it
should be no surprise that it didn't work. Perhaps your codebase is just hard
to contribute to? Is it possible your company has not given enough incentive
towards outside developers for them to contribute back? It doesn't even have
to be money, it starts with making some mutually beneficial promises and then
sticking to them.

In general I think it is wrong to try and characterize Amazon's developers as
being some kind of strange beasts who have somehow figured out how to use open
source better than everyone else. They are the same as every other corporate
developer in that they'll always take the easiest and cheapest path to
success.

~~~
tsimionescu
The purpose of the AGPL as envisioned by Stallman is to give you as a user of
the network-based software some of the same freedoms that you would have as a
user of a local GPL program.

This would include the freedom to know what code is running,and the freedom to
modify that code and run you own version. The ideal outcome of someone running
an AGPL server would be that if you find a bug or if they decide to terminate
the service, you can host your own version, so you are not locked in.

Unfortunately, it turns out that this freedom is very hard to actually
guarantee, as the deployment and monitoring of a server can be as daunting as
the actual application logic itself. This is somewhat similar to the case of
releasing GPL code without the instructions for building that code, but
probably far worse.

You seem to have assumed I am personally someone who was bitten by this, which
is not the case. I am not even a firm believer in FLOSS values. I am just a
by-stander observing how these things are used in practice as opposed to their
ideals.

By the way, even Mongo's initial use of the AGPL was somewhat counter to the
spirit of the thing - they also believed that the deployment part is going to
be too hard for many companies, so they hoped that companies would come to
them to pay for hosted deployments. If they were using the AGPL according to
its spirit, they could have made their own deployment and monitoring scripts
public and would have defeated Amazon's lock-in attempts that way (of course
they could never do that, their whole purpose was to create that lock-in
effect for themselves).

------
p4bl0
The relevant thread on the KDE Community mailing list starts here, it contains
a lot of information: [https://mail.kde.org/pipermail/kde-
community/2020q2/006098.h...](https://mail.kde.org/pipermail/kde-
community/2020q2/006098.html)

Most notably, it contains a discussion about the feasibility of a fork (and
even a name is discussed). What emerges from the discussion is that the OSS
community around the Qt project is quite large even outside of KDE (I remember
VLC being cited, for example), and that if efforts are united, it would be
feasible. The KDE project could provide the necessary infrastructure for
development, including CI (which would necessitate some startup work to change
framework if I understood correctly) and distribution.

~~~
em-bee
forking qt for kde can't be that much harder than maintaining gtk for gnome.
if the community is large enough, which i believe it is.

~~~
distances
According to one coverage report the project sizes are 7 million lines for Qt
vs. 1.2 million for GTK. If true, they are indeed much closer in size than I
imagined -- I was sure it's at least one magnitude of difference in size if
not even much more.

[https://scan.coverity.com/projects/qt-
project](https://scan.coverity.com/projects/qt-project)
[https://scan.coverity.com/projects/gtk](https://scan.coverity.com/projects/gtk)

------
dmoreno
> It would be very unfortunate if free software users would have to remain
> vulnerable for a full year before they could have access to a newer version
> with a fix.

The last published version, even if its 12 months old, is and will be open
source and free software, so it's up to the users and developers to keep it
security updated. As with all free software. Is not as if Qt does not fix it
nobody will. This is not closed software.

~~~
Karliss
Open source developers can keep working on the last published version but what
happens after 12 months? Try to resolve 12 months worth of merge conflicts,
hard fork and stop taking any further improvements from qt company, stop
making any changes except the simplest bugfixes?

~~~
em-bee
isn't this effectively like android now?

~~~
Karliss
Yes and it is working badly. Ecosystem is fragmented. Phone manufacturers are
struggling to keep up. Phone support gets dropped quickly, code written by
manufacturers for specific phones gets thrown out. Open source fork
maintainers need to gather code not only from Google but also each phone
manufacturer. Open source forks die. Open source fork support for running
newer Android version than one provided by manufacturer is limited, only a few
versions at best and only for most popular phones (because solving 12month
merge conflicts is hard).

That's with Android which is somewhat self-contained system and changes in
external interfaces wifi protocols, mobile networks take long time and are
incremental. Once a new version of windows or macOS comes out waiting 12
months is a big deal.

------
hereisdx
In fact,from Qt 5.15 onwards the offline installer is provided only for
commercial license holders.

Say goodbye to: \- Installing on multiple PCs at once \- Installing on PCs
without internet connections.

It's also possible that the online installer collects telemetry data.

~~~
Rochus
So why don't we start providing Qt binary version installers ourselves? Most
Linux distros already do it, so we can focus on Windows and MacOS. Maybe some
subdomain of kde.org?

~~~
edsac_xyzw
The trouble of distributing Qt in binary format is the C++ non standard ABI
problem. Qt has to be compiled for every possible compiler and many different
versions of the same compiler, in order to avoid linking error. On Unices,
most compilers, specially GCC and Clang, are using the Itanium ABI, but on
Windows, compilers still have different ABIs, so linking against Qt shared
libraries built with older versions of MSVC compiler may result in linking
error. On Linux, there still the problem of implicit dependency on GlibC (GNU
C Library), most applications built using newer versions of GlibC will not
work on distributions using older versions of GlibC. It would be nice for
Linux Desktop, if GlibC did not break the binary compatibility.

That said, the most suitable way to get Qt binaries for development may be
using a C++ package manager such as Conan or Vcpkg which can cache the library
compilation output and reuse it on many different projects without
recompilation, unless the current compiler has an incompatible ABI.

Conan C++ package manager recipes can also provide pre-compiled binaries which
reduces the compile time pain. Another interesting tool is the conan server
which allow fetching conan recipes and pre-compiled binaries on the local
network or across the internet.

~~~
Rochus
In practice there are not so many. And e.g. on Windows I use an old VS
compiler version and can then also use it with later VS versions (but not vice
versa). Linux is also no issue because Qt is usually part of the distribution,
i.e. there is no need to compile it as long as you depend on the standard
version (not a custom one).

Personally I don't work with package managers, but prefer so setup and control
the environment myself. It's not that difficult, and there is also Docker.

~~~
edsac_xyzw
On Windows, MSVC does not provide guarantees that it will not keep the ABI on
new releases. The drawback of using the Qt provided by the Linux distribution,
is the reproducibility of the development environment as it is not possible to
control the version of the Qt installed and also to have multiple Qt
installations with different versions. As a result, the compilation of a Qt
application may fail on different Linux distribution which uses a different
and incompatible version of Qt. Docker can solve the reproduciblity of the
development environment problem, but it still does not integrate well with
development tools such as IDEs, building systems and so on.

The advantage of a package manager is the reuse of binary artifact on many
projects and also the control over the library version. Conan package manager
could be used for providing pre-compiled binary artifacts of Qt library. For
instance, provides pre-compiled boost library and poco library for lots of
different compilers, compiler versions and operating systems which saves one
from building and installing those libraries.

------
bzb3
This was already resolved favourably by both parts. This article is from
April.

~~~
pdimitar
How was it resolved, sorry?

~~~
lerax
KDE will migrate to GTK. [joke]

~~~
azinman2
Link?

~~~
toyg
It's obviously a joke.

I've not heard anything after the rumbles in April, but nothing seems to have
changed, according to the website, so the 2015 agreement continues to be
valid, afaik.

~~~
azinman2
Ok. I wasn’t sure. It seemed preposterous but then again if they needed to get
away from QT...

------
Memosyne
I think the latest public update on this is the following quote from "Welcome
Meet Qt (Qt Virtual Tech Con 2020):

> Yes, of course Qt will remain open-source. I don't think anybody in our
> company is making any claims other than that and... let's be very practical:
> the only way we're going to have a big ecosystem going forward is to have
> open-source available. And we will have patch releases available for 5.15
> until Qt 6.0 comes out and after that we will focus our efforts on 6.0.
> Having said that of course we will do the patch releases for our commercial
> only branch -- for our paying customers. But rest assured there's going to
> be a lot of different patch releases available for open-source and you'll
> always have the latest available. [1]

[1] -
[https://www.youtube.com/watch?v=Ioons0BMSvs](https://www.youtube.com/watch?v=Ioons0BMSvs)

~~~
mpol
That sounds a bit vague :) I read into it that open source users get the
latest patch release, as in 5.15.3 for example. But major/minor releases are
first served to commercial users, like 6.0 and 6.1.

------
baybal2
I myself would've contributed to GTK+, but... GTK is a tough project to
contribute to. As many said, GTK has over the years turned from the Gimp
Toolkit to a Gnome Toolkit, and with that comes all the pleasures of working
with types like L.P, and other headstrong people.

~~~
alxlaz
The (unfortunate, I guess?) consequence is that GTK seems to move, slowly but
surely, to a "niche" role. 10-15 years ago it used to be the natural choice
for Linux GUI development -- people were still reticent about Qt, plus KDE 4
wasn't in a very good shape.

Nowadays, it's not so much the FOSS world's favourite toolkit as the toolkit
that every newcomer uses because it's the one they're most likely to encounter
first (via Ubuntu) and then ditches for Qt (or whatever else) as soon as they
have to work with upstream or maintain their program for more than two or
three years. The erosion isn't obvious because the largest players -- the
likes of Canonical -- can throw enough volunteer (and sometimes money) at this
problem and get to keep GTK-based programs working for everyone, not just the
(ironically, very narrow) user base that Gnome cares about. But nothing lasts
forever in tech.

There are still people doing amazing work with it. The folks at System76 with
popOS are more or less at the design "forefront" (but they aren't doing _that_
much with it, if we're being realistic), and the folks behind XFCE, Mate and
Cinnamon somehow manage to "encapsulate" a toolkit developed by a rather
hostile community in desktop environments that are nothing like that. But the
writing has been on the wall among older developers for a few years now, and
Qt's change of licensing -- if that ever were to happen -- wouldn't be enough
to erase it IMHO.

~~~
raverbashing
Then we wonder why Electron has become the platform of choice for multi-
platform apps.

There's (part of) the answer.

~~~
alxlaz
I don't know if/don't think that Qt's licensing is an issue for most of the
people who need to make cross-platform applications and reach out for
Electron. Electron seems to be the default choice not just for FOSS projects,
but also for commercial projects, which have no qualms using a toolkit that
might go proprietary, and can get a commercial license if they need it (which
most of them don't).

GTK, on the other hand, yeah, it hasn't been a good choice for cross-platform
development for years now. The only platform it properly supports is Gnome.

~~~
rrmm
I definitely started out as a strong gtk advocate. But these days I wouldn't
have qualms about using QT if it were the right fit for the project.

------
speedgoose
What is going on with the pictures of girls in this linuxreviews.org website ?

~~~
toyg
I think they are pictures of Wei Lin herself.

I'd never seen this site before, not sure why it's suddenly making HN front
page for rehashing a story from April.

~~~
EdwardDiego
Wai Lin (the biography and pictures) is a character from a Bond film - played
by Michelle Yeoh, whose cover story was as a reporter for New China News
Agency.

~~~
toyg
Are you saying the whole thing is pseudonymous trollbait?

Talk about the dangers of a “good” domain name...

------
mangecoeur
Maybe free software advocates should START by having a rational discussion
with their partner organisations like qt to determine their intentions instead
of starting an Internet dumpster fire flame war based on rumours. The qt
company has said repeatedly they will support the open source community as
they always have done. Maybe start by clarifying the situation with them
before flying off the handle.

------
Lammy
Nothing can really provide a "replacement" for any particular widget toolkit
that will look+feel identical and support all the same widgets, but I'm a big
fan of wXWidgets (nee wxWindows) for my personal projects:
[https://www.wxwidgets.org/](https://www.wxwidgets.org/)

------
adrianN
How much of the development work is done by Qt the company compared to the KDE
developers? Is a fork feasible?

~~~
brobdingnagians
There are already a few forks from the past like CopperSpice, I think there is
probably quite a good chance of a fork occuring if a major move happened.

~~~
pjmlp
All of them eventually die, because working for free on something like Qt
never matches on feature parity, deployment targets or support levels Qt
customers are used to.

------
mhd
Seems this will come up every few years again. I remember when I was part of
the "Linux Interface Project" in the 90s, which started out as a bunch of
fledgling Qt programmers trying to create some missing widgets. This was in
the Qt 0.x days, where there was still a lot of "basic" functionality missing.
And because of licensing issues and delusions of grandeur about proper OO
design (i.e. reading Taligent papers etc.), we decided to do our own stuff.

Others, including some German dude and his "Kool" desktop project were a lot
more pragmatic. Still seems the better approach, or otherwise we'd all be
using the Hurd.

------
Nokinside
People should think as normal business, not as moral issue.

There will be tensions when business interests diverge. For open source people
the interest is just few platforms: PC and Android and Apple. For Qt the
direction is embedded and operating systems and customers that use embedded.

If no common ground is found you get only what you have agreed on contract. In
this case GPLed code after 12 months. Open source people have to maintain
security patches themselves. There are also companies working on KDE and Qt
that can do it. Alternatively just fork the Qt (again) and go on your merry
way.

~~~
thePunisher
IMHO the Qt company is simply using the corona-crisis as an excuse to jack-up
prices. They would've done so in any case at some point.

The Qt company is very shortsighted since KDE has meant a lot for them in
terms of legitimacy and valuable feedback. The KDE developers also made some
important contributions, such as KHTML (the basis for WebKit and Chromium,
used in billions of web browsers).

Why don't they apply this new license only to their Embedded and mobile
versions? That's where the real money is being made by Qt anyway.

~~~
Nokinside
Established companies rarely fall for the "We can't pay you but you get
exposure". I don't think paying customers care about KDE or open source. If
you can give concrete examples showing something else, it would be
interesting.

The way to make money in open source is to sell service attached to software,
software development as QT does it where services is small component is just
not generating enough money. That's why RedHat is owned by IBM and Canonical
Ltd. has revenue only 2x of Qt despite large number of users.

~~~
thePunisher
If Qt hadn't been taken up by KDE some other UI framework (such as wxWidgets)
could've had much larger user base thereby rendering Qt much less attractive
to developers and undermining their business model.

I personally prefer wxWigets over Qt, but I'm a user of both.

~~~
pjmlp
Does wxWidgets still feel like a 90's clone of MFC?

~~~
thePunisher
I developed MFC applications and wxWidgets is FAR better than MFC. Much easier
to use too. Plus multi-platform.

~~~
pjmlp
Might be, I haven't look at it since late 90's.

So maybe it is worth another look.

However even OWL and VCL were better than MFC. :)

------
kavalg
Isn't this a good time for a new UI framework (e.g. Flutter) to conquer
grounds. Especially if it would be possible to automatically translate large
parts of the Qt UI to Flutter?

------
ekvintroj
That post is not true, check [https://www.qt.io/blog/qt-and-open-
source](https://www.qt.io/blog/qt-and-open-source)

------
dalu
Well with Stallman mobbed away from FSF and Linus mobbed away with a CoC over
his mouth, the way is free for stupid things to happen.

Good job corps.

The real question is, why is he using a wiki to post articles?

------
Abishek_Muthian
LXQT based Lubuntu has been perfect for a lightweight VM to me as I couldn't
deal with the Tiny Core Linux's compatability issues with Virtual Box.

QT is the recommended framework for app development in Ubuntu Touch and other
smartphone Linux OS; Postmarketos uses KDE Plasma.

All these would be in extreme trouble if Qt goes ahead with this plan.

------
hellozee
How clickbaity, Qt could never go proprietary thanks to KDE Free Qt Foundation

~~~
elcomet
The KDE project already lacks manpower, I'm not sure they will be able to
maintain a free Qt fork for long.

~~~
Rochus
References? Have you ever heard of KDAB and other companies supporting Qt on a
professional level?

~~~
toyg
It’s a perennial problem with all major FOSS projects and KDE is massive, it’s
basically a given. At the time I followed it a bit more closely, there was
clearly a churn of developers very similar to what JWZ described, with
constant rewrites of entire applications because nobody had the time and
inclination to maintain old ones (maintaining other people’s code is hard).
Yes, the associated entities do a lot of good work, but it’s never enough -
and realistically, nowhere near enough to be responsible for the entire Qt
library.

------
musicale
Qt seems to be a self-correcting problem.

------
m4r35n357
Stallman right again shocker!

------
dirtydroog
To be honest, the only QT-using program I use is QT Creator.

------
thePunisher
It was foolish of KDE to use commercial product as a base for their free
desktop. They should've use wxUniversal (the self drawing version of
wxWidgets).

Now, the only option they have left is to fork QT, which would put enormous
pressure on them since it would require a lot of effort to maintain.

~~~
syockit
Hindsight is 20/20\. Back when KDE was being developed, Trolltech offered free
software license claiming "if you create free software; Qt is backed up by a
professional organization which won't disappear tomorrow.". On the other hand,
wxWindows (now wxWidgets), although having started much earlier in 1992, only
had its first alpha in 1997, while KDE was already in development (starting in
1996), preparing for its first beta release. Surely that would be a good time
to consider the alternative, you'd say, but why bother, since Qt also had a
free license and had a whole company backing it, while wxWindows didn't.
Without the foresight, who would you have placed your bet on?

------
growlist
No great loss to me. I dislike both the technology and its licensing.

