[Development] The place of QML
aschmidt at dekaresearch.com
Fri May 11 17:59:09 CEST 2012
> For starters, there's already a foundation in place -
> That Foundation has the right to license Qt under a "BSD-style
> license or under other open source licenses" regardless of
> any other licensing. ...
No, there's no current right for KDE to distribute Qt under
other terms (than LGPL 2.1 and GPL 3). What there is is an
"escape clause" if "Nokia discontinue(s) the development
of Qt". Summarized at the site you cited, it reads:
"The Foundation has a license agreement with Nokia. This
agreement ensures that the Qt will continue to be available
under both the LGPL 2.1 and the GPL 3. Should Nokia discontinue
the development of the Qt Free Edition under these licenses,
then the Foundation has the right to release Qt under a BSD-
style license or under other open source licenses. The
agreement stays valid in case of a buy-out, a merger or
Now ask yourself how many millions of Euros could be
spent at some future point litigating whether or not
Nokia has "discontinued" the development of Qt. They
could entirely stop work on QWidget but the QML work
would probably prevent the triggering of the escape
From: development-bounces+aschmidt=dekaresearch.com at qt-project.org [mailto:development-bounces+aschmidt=dekaresearch.com at qt-project.org] On Behalf Of BRM
Sent: Friday, May 11, 2012 10:19
To: d3fault; development at qt-project.org
Subject: Re: [Development] The place of QML
> From: d3fault <d3faultdotxbe at gmail.com>
> So, I'm supposed to want to contribute an upgraded C++ GUI API ("Yes,
> the Qt Widgets module we have in Qt 5 is right now marked as ‘done’,
> which means we don’t have anybody actively working on new features for
> the module at this point in time. But this can change any day if
> someone has some interest or need to do more active development in
> this area." -Lars) to this "open source"' project wherein my
> components (upgraded C++ GUI API) can be sold alongside your
> components (expensive/unnecessary front-end to your efficient
> back-end) and I not receive a single dime of it? (That described
> scenario also shows how Nokia will receive false confidence in their
> QML product. Qt/C++ attracts the real users, QML/"New"/Flashy gets all
> the credit). The Qt Contributor's Agreement is very permissive with
> what Nokia (and not you or I) may do with any/all code contributed to
> the Qt Project. Not only that, but the money earned from Commercial
> sales is used against the majority's interest
> (http://qt-project.org/forums/viewthread/16693/ is skewed (this one's
> biased, but is still more accurate:
> http://qt-project.org/forums/viewthread/16465/ ), because "Desktop
> Components" is of course the next logical step for the only language
> that interfaces with QtQuick. It's playing catch-up with QWidgets
> functionality. Additionally, Desktop Components becomes the
> unquestionable winner for anyone not paying attention to the C++ vs.
> QML "religious war" -some guy on the forums. We need an un-biased poll
> that compares the 2 real issues: Qml/Js/Vm vs. Upgraded C++ GUI with
> bindings (made it: http://qt-project.org/forums/viewthread/17137/ )).
> Sure, Nokia deserves some moneys for Qt. Equally, they should be
> obligated to benefiting the majority of their userbase (Interest -
> "List for developers who _use_ Qt"). Nokia is for some reason (driven
> by a CEO could be the problem) off creating a "Toy Programming
> Language" (QML) targeting their mobile lineup when they should be
> focusing strictly on their core customers (C++ developers). The ones
> who made Qt what it is today.
1. We are not _Nokia's_ core customers. Never were. Qt is extremely small compared to Nokia at large.
2. Elop's move to the Windows platform side-lines what Nokia did plan on with Qt at the start; so that probably is affecting things.
3. I do agree that QML is being pursued to the demise of QWidget. It's evident in where new functionality is showing up, etc.
Now if QML was free of GPL (e.g. Commercial customers could use it without qualms about licensing) then #3 wouldn't be an issue aside from the migration path.
But that migration path and how far apart QML and QWidgets are leaves a lot to be desired.
That is - looking from the outside, QML is great for when you have a complete display that lacks everything and every kind of widget needs to be rethought (e.g. Embedded).
But it absolutely doesn't do well when you just need a standard set of widgets that ought to look like the platform they are running on for the Desktop - Linux/GNOME/KDE, Windows, Mac.
This is mostly what has kept me personally from trying out QML more; but I'm still undecided on it in whole; I'll wait until Qt5 is out before saying more in that respect, but it's still got a ways go to - which everyone here seems to admit.
Irregardless, I'm just saying the above to show that there are people that do sympathize with your position;
but I'm this discussion is heading in a constructive or useful direction either so I'm going to leave it there.
> long term, i see a fork. qt (and derivs) will suffer
> one solution to this is a Qt Charity that receives all Qt Commercial
> fundings and puts them toward a) support and b) future development
> based on "developers who _USE_ qt" 's needs/wants
For starters, there's already a foundation in place - http://www.kde.org/community/whatiskde/kdefreeqtfoundation.php.
That Foundation has the right to license Qt under a "BSD-style license or under
other open source licenses" regardless of any other licensing.
Qt is protected in that manner for both Open Source _and_ commercial users.
That said, KDE4 uses QML extensively so I'm not sure they (KDE) would necessarily agree with you.
So no new charity/organization is required; and no other fork will get that kind of licensing ability either.
This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.
Please consider the environment before printing this email.
More information about the Development