Re: [Interest] Yocto is application or device creation license???

[Tuukka Turunen via Interest]

Hi,

The meta-qt6 layer is available at: 
https://code.qt.io/cgit/yocto/meta-qt6.git/tree/ It works for both commercial 
as well as open-source Qt as described at: 
https://code.qt.io/cgit/yocto/meta-qt6.git/tree/README.md

Your email mentions MCU, so in case you are looking to use Qt for MCUs it is a 
separate codebase, which is not dual licensed. More info: 
https://www.qt.io/product/develop-software-microcontrollers-mcu

The commercial Qt for Device Creation subscription includes prebuild binaries, 
convenience items, as well as some additional functionality. You can check what 
is available under which license bundle via: https://www.qt.io/product/features

We recommend using the commercial Qt for Device Creation product when making 
embedded devices. It is also possible to build embedded devices using the 
open-source license option as long as you ensure to meet the requirements set 
by open-source licensing. You can check more information on the L/GPL 
requirements at: https://www.qt.io/licensing/open-source-lgpl-obligations

Yours,

Tuukka


From: Interest  on behalf of Jérôme Godbout 
via Interest 
Date: Thursday, December 14, 2023 at 16:36
To: Qt Interest 
Subject: [Interest] Yocto is application or device creation license???
Hi,

I have a client who is looking for a GUI stack for their SPA devices. The 
device use a yocto we build for them. The Fuzzy license of Qt is not very clear 
on where does Yocto build fall in term of licensing.

My understanding if fall into the Linux embedded and force them to go into the 
device license I think. But this will be a show stopper for them if they have 
to paid royalty fee. Does Yocto Linux count as Linux Desktop, since we are 
building a desktop on arm chipset in the end.

The device creation is just plain impossible, the royalty fee is above the cost 
of the MCU itself, which is a no go.

I feel like I always end up in that impossible licensing problems with Qt, the 
embedded license is out of touch aside from huge expensive system like car!

So far, we look at Qt for hospital bed, SPA, car charging units… The price is 
just a show stopper at each time…


[signature_917022966]
Jérôme Godbout, B.Eng.
Software / Firmware Team Lead
[Smart Phone avec un remplissage uni] (581) 777-0050
[Envelope avec un remplissage uni] 
jgodb...@dimonoff.com
[World avec un remplissage uni] www.dimonoff.com

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] on bumping the minimum Android API level to Android 8.0 API 26

[Tuukka Turunen via Interest]

Hi,

“Supported” is a bit of a loaded term that can have at least the following 
meaning, depending upon how it is looked at:

  1.  When something technically works, it is “supported” to some extent
  2.  When something is tested in CI and release testing, some could consider 
calling that “supported”
  3.  If the issues found are actively fixed, many would say this item is 
“supported”
  4.  When customers with existing support agreement can request help from the 
technical support team, the item is “supported” for them

>From the viewpoint of https://doc.qt.io/qt-6/supported-platforms.html it is C 
>(for all users) and D (for eligible commercial license holders) that are 
>required to be Supported.

Meaning in regards of Android version below 8.0 usage with Qt 6.5 that until 
some upcoming NDK update makes it technically impossible to run on, users can 
still target these “unsupported” versions. User needs to do more testing, as 
there is no validation done for the release. When an issue is discovered, user 
needs to check if it happens also on a supported Android version. If it does 
not happen on a supported version on Android, it is unlikely that the issue 
gets fixed.

Same principles also for other platforms.

Yours,

Tuukka

From: Interest  on behalf of Maxim 

Date: Thursday, 6. April 2023 at 0.36
To: interest@qt-project.org 
Subject: [Interest] on bumping the minimum Android API level to Android 8.0 API 
26

Minimum supported API level recently raised from 21 (Qt 5.15) to 23 (Qt 6.0) 
then to 26 (Qt 6.5?) without details behind it, so possibility of deploying to 
devices with lower API level is unclean. I guess raising level 23 API may be 
caused by implementation of runtime permissons, but whats behind raising it to 
26?

"While changes in CI are not being made at this stage, we need to move
forward with setting user's expectations that they can no longer rely on
Qt remains compatible with Android versions that are no longer
maintained by Google." https://codereview.qt-project.org/c/qt/qtdoc/+/466788
What means no longer maintained by Google? Google supports development for wide 
range of Android API levels, their recent LTS NDK r25 still supports level 19+ 
API, they provide various 'Compat' classes for support lower APIs levels.

To favor focus of Qt on more recent Android versions, while still keeping 
possibility of building Qt applications for devices with lower API levels, i 
think there should be multiple documented minimal API levels:
-general minimal supported API level (e.g. 26) of Qt framework (favored in test 
configurations, bug priority, etc.)
-individual minimal API level requirements of Qt modules (e.g. for qtcore level 
23 or maybe even lower in some cases)
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of Mac Desktops

[Tuukka Turunen via Interest]

… and like the first line states, the telemetry functionality of Qt Creator is 
based on https://api.kde.org/frameworks/kuserfeedback/html/index.html

On the end user application analytics topic there is work ongoing to build a 
new product called Qt Insight, but that is currently not for open-source 
applications. You can learn more about Qt Insight at 
https://www.qt.io/product/insight

Yours,

Tuukka


Lähettäjä: Cristian Adam 
Lähetetty: maanantaina, joulukuuta 19, 2022 5:58 ip.
Vastaanottaja: Michael Jackson ; Tuukka Turunen 
; Macieira, Thiago ; 
developm...@qt-project.org ; 
interest@qt-project.org 
Aihe: Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of 
Mac Desktops

Hi,

See qt-creator/plugin-telemetry.git - A plugin that collects usage data from Qt 
Creator users. This data is used to improve the Qt user experience and is one 
information source for product 
decisions.<https://code.qt.io/cgit/qt-creator/plugin-telemetry.git/about/>

Cheers,
Cristian


From: Interest  on behalf of Michael Jackson 

Sent: Monday, December 19, 2022 16:47
To: Tuukka Turunen ; Macieira, Thiago 
; developm...@qt-project.org 
; interest@qt-project.org 
Subject: Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of 
Mac Desktops


Dear Tuuka or any other QtCreator Developers,

I am interested in finding out more how QtCreator has implemented their 
telemetry system. We would also like to add this capability to our open-source 
software but this is our first foray into this kind of telemetry system. Maybe 
just a hint what what code bits to grep for in the source would get me started.



Thank You.

--

Mike Jackson



From: Interest  on behalf of Qt Interest 

Reply-To: Tuukka Turunen 
Date: Saturday, December 17, 2022 at 3:45 AM
To: "Macieira, Thiago" , 
"developm...@qt-project.org" , Qt Interest 

Subject: Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of 
Mac Desktops



Hi,



Most of the macOS users are quite quick to take on new OS versions and this is 
true also for adoption of macOS versions with the new numbering scheme. Apple 
hardware is also rather good in keeping support for new OS versions and at 
least between versions 10.15 and 11 there does not seem to be a major drop in 
what HW is supported.



The challenge we have with supporting macOS versions is that some users migrate 
really quickly, so we need to work a lot with the unreleased (developer beta) 
versions in order to ensure Qt works well with the new macOS version optimally 
before it is even released for production. We also aim to keep supporting older 
versions and the ones in between. This means quite a lot of CI system load – 
especially as we now have both Intel and ARM architectures to test on.



There is also positive development happening. With the latest versions the 
virtualization support is improving so that we are hopeful to be able to use 
the hardware more efficiently (by running two virtual machines in each physical 
HW). So while macOS is still far from the convenience we have with Linux and 
Windows that support sever grade hardware, things are getting better with Macs 
as well going forward (not for 10.15, though).



Related to the usage of 10.15 one indication comes from Creator telemetry. 
Based of this roughly 8% of the macOS users this year have version 10.15. Of 
course, this is not a direct indicator for how many end users of Qt based apps 
there are with macOS 10.15, just how much of the developers using Creator have 
it. Telemetry is fully optional, but I think it is reasonable accurate for this 
type of data point as the OS version is unlikely to greatly affect sending or 
not sending the telemetry data. Note also that we have a lot of different Qt 
versions supporting macOS 10.15, and many applications are still using Qt 5.



Yours,



Tuukka



From: Interest  on behalf of Thiago Macieira 

Date: Saturday, 17. December 2022 at 1.20
To: developm...@qt-project.org , 
interest@qt-project.org 
Subject: Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of 
Mac Desktops

On Friday, 16 December 2022 18:15:11 -03 Alexander Dyagilev wrote:
> But why did you do this? Does the supporting of 10.15 really increase
> the development cost for Qt Company?

I can't speak for the Qt Company costs, particularly for the fact that this is
one of their LTS releases.

But in general, it does increase the costs overall. There are new APIs that we
can use if we don't have to keep 10.15 compat, there's one fewer platform to
test on (usually with a virtual machine) before release, and so on. The
benefits may not be realised now, but they will come in the future.

For me specifically, what matters is that 11.0 dropped support for Intel Macs
that don't have AVX2 support, meaning that I can now assume that all machines
running Qt 6.5 natively have 

Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of Mac Desktops

[Tuukka Turunen via Interest]

Hi,

This mailing list thread is actually already part of the discussion. I am sure 
the relevant stakeholders will read though the mails. One important thing: the 
question is whether or not the _latest_ Qt version supports 3 or 4 generations 
of macOS – because we already support the older macOS version with the earlier 
Qt releases. We are avoiding to the extent possible dropping supported 
platforms from released versions of Qt, so macOS 10.15 continues to be 
supported with Qt releases up to Qt 6.4 in any case. This also leads into Qt 
supporting such macOS versions that Apple no longer support – like the 
discussed macOS 10.15 that is supported in Qt 6.4, but no longer supported by 
Apple.

Yours,

Tuukka

From: Development  on behalf of coroberti 

Date: Monday, 19. December 2022 at 8.43
To: Qt development mailing list , Qt Interest 

Subject: Re: [Development] [Interest] Qt 6.5 Is Irrelevant for More than 95% of 
Mac Desktops

Thank you, Thiago, for your understanding and the assistance proposed.

Thus, we need it to be approved by the Qt Company.

Tukka, can we get the people of the Qt Company sitting and at least discussing:

1. The general issue related to the level of Qt support for Mac platforms
considering four (4) versions to support instead of the current three (3).


2. The concrete case of Mac Support for Qt 6.5.

Even if you come back and say - sorry, we considered, but decided to
turn it down,
still the effort will be very much appreciated.

Thanks in advance for considering the options.

Kind regards,
Robert Iakobashvili

___
Development mailing list
developm...@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 6.5 Is Irrelevant...

[Tuukka Turunen via Interest]

Hi,

One clarification: we are not talking about stopping support for macOS 10.15 in 
the already released version of Qt. It continues to be supported target with Qt 
5.15 LTS and Qt 6.2 LTS as well as Qt 6.4. Of course within reasonable limits 
as Apple itself has already stopped supporting it.

The discussion in this email thread has been about whether or not it should be 
supported in the next Qt release: Qt 6.5 coming in ~3,5 months from now.

Yours,

Tuukka

From: Interest  on behalf of Turtle Creek 
Software 
Date: Sunday, 18. December 2022 at 17.27
To: interest@qt-project.org 
Subject: Re: [Interest] Qt 6.5 Is Irrelevant...
We sell to construction companies.  They are not computer geeks, and often run 
the original OS until the machine dies.  Given the flakiness of some Mac OS 
upgrades, that may be ideal policy.

Apple moves far too fast with chip, OS and language changes. It's hard for 
small developers to keep up. We started on 680x0, Pascal and Toolbox. That's 3 
chips, 3 languages and 3 OS frameworks ago. A jolt every 3 years.

We gave up on Xcode/Cocoa since Obj-C seemed doomed and we have too much C++ 
code to ever port to Swift and/or SwiftUI.  I imagine Qt faces the same 
problems, but on a more system level.

If Qt Co does not have the resources to support more than 3 years of OS 
versions, then please at least create some good stopping points that solidly 
support older Mac OS versions. Explain which to use for which OS ranges. Then, 
developers may need to build multiple apps.  That kinda sucks, but it's better 
than losing/annoying users because they don't want the expense/pain of new 
hardware.

Casey McDermott
TurtleSoft.com
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of Mac Desktops

[Tuukka Turunen via Interest]

Hi,

Most of the macOS users are quite quick to take on new OS versions and this is 
true also for adoption of macOS versions with the new numbering scheme. Apple 
hardware is also rather good in keeping support for new OS versions and at 
least between versions 10.15 and 11 there does not seem to be a major drop in 
what HW is supported.

The challenge we have with supporting macOS versions is that some users migrate 
really quickly, so we need to work a lot with the unreleased (developer beta) 
versions in order to ensure Qt works well with the new macOS version optimally 
before it is even released for production. We also aim to keep supporting older 
versions and the ones in between. This means quite a lot of CI system load – 
especially as we now have both Intel and ARM architectures to test on.

There is also positive development happening. With the latest versions the 
virtualization support is improving so that we are hopeful to be able to use 
the hardware more efficiently (by running two virtual machines in each physical 
HW). So while macOS is still far from the convenience we have with Linux and 
Windows that support sever grade hardware, things are getting better with Macs 
as well going forward (not for 10.15, though).

Related to the usage of 10.15 one indication comes from Creator telemetry. 
Based of this roughly 8% of the macOS users this year have version 10.15. Of 
course, this is not a direct indicator for how many end users of Qt based apps 
there are with macOS 10.15, just how much of the developers using Creator have 
it. Telemetry is fully optional, but I think it is reasonable accurate for this 
type of data point as the OS version is unlikely to greatly affect sending or 
not sending the telemetry data. Note also that we have a lot of different Qt 
versions supporting macOS 10.15, and many applications are still using Qt 5.

Yours,

Tuukka

From: Interest  on behalf of Thiago Macieira 

Date: Saturday, 17. December 2022 at 1.20
To: developm...@qt-project.org , 
interest@qt-project.org 
Subject: Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of 
Mac Desktops
On Friday, 16 December 2022 18:15:11 -03 Alexander Dyagilev wrote:
> But why did you do this? Does the supporting of 10.15 really increase
> the development cost for Qt Company?

I can't speak for the Qt Company costs, particularly for the fact that this is
one of their LTS releases.

But in general, it does increase the costs overall. There are new APIs that we
can use if we don't have to keep 10.15 compat, there's one fewer platform to
test on (usually with a virtual machine) before release, and so on. The
benefits may not be realised now, but they will come in the future.

For me specifically, what matters is that 11.0 dropped support for Intel Macs
that don't have AVX2 support, meaning that I can now assume that all machines
running Qt 6.5 natively have it. We had further changes based on this
assumption ready to go for 6.5, but they got removed at the last minute due to
unexpected side-effects and the feature freeze being too close.

On Friday, 16 December 2022 19:44:16 -03 Michael Jackson wrote:
> I agree here. Is Qt 6.5 now using an API or a compiler feature that macOS
> 10.15 does not support?

As of *today*, no. This may change tomorrow, as developers continue to do
their work. That means that, as of *today*, Qt 6.5 *could* be compiled to run
on 10.15, by just lowering the default minimum version somewhere in a config
file. But we are not promising that this will remain true and especially we are
not testing that it works.

We had to make a call and following Apple's own support lifetime makes sense.
If you want to stay on an OS that is not receiving important fixes, then you
can also stay on a Qt that is not receiving fixes. Though unlike Apple, you can
backport fixes to 6.4 yourself or remove the new requirements from 6.5 yourself
(or contract someone to do it for you).

Moreover, there's a time delay. This affects Qt 6.5, which will be released in
March 2023, which means it probably affects applications released in May 2023
and later.

>  Is there a security library that Qt 6 depends on (OpenSSL is my guess) that
>  10.15 isn't now updating? Is Qt 6 using the new APIs from that version of
>  OpenSSL (or what ever library broke)? Is there a graphics API that Qt 6
>  now depends on that is macOS 11.0 and greater? Maybe that is the reason?

Any of the above or others may become another reason. The point is that we
need to officially drop the platform first, before we can depend on and require
some of those APIs. It's not the other way around.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list

Re: [Interest] Qt add on modules in Qt 6.2 commercial license

[Tuukka Turunen]

Hi,

These are dual licensed, so in that manner the code is available for both 
commercial and open-source users. However, as you can see from 
https://www.qt.io/product/qt6/qt-5-15-vs-6-2-feature-comparison none of these 
is currently released or supported for Qt 6.2.

Yours,

Tuukka


From: Interest  on behalf of Ramakanth 
Kesireddy 
Date: Monday, 27. December 2021 at 8.16
To: Qt Interest 
Subject: [Interest] Qt add on modules in Qt 6.2 commercial license
Hi,

Can you let me know if the Qt add on modules like Qt Location, QtQuick WebGL, 
Qt Speech etc shall be available for Qt 6.2 commercial license users?

Best Regards,
Ramakanth
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.15 LTS vs Qt 6.2 LTS

[Tuukka Turunen]

Hi Roland et al,

Certain industries have also defined approach to safety by separating the 
safety critical functionality from other functionality. Typically, in these the 
approach is such that the system needs to ensure the safety critical 
functionality to work with desired likelihood and the other functionality to 
not interfere with the safety critical functionality.

Qt is well suited for this type of an approach, and we also have a certified 
solution to the safety critical functionality: 
https://www.qt.io/product/functional-safety-and-qt

As a large framework Qt is not directly created for approach where it alone 
needs to provide a safety critical functionality without any support from the 
system architecture (noting that the Qt Safe Renderer is specifically created 
for this purpose). Anything is possible, but our recommendation is to approach 
the topic from system design viewpoint. Separating the safety critical 
functionality and creating a viable approach for it. If Qt libraries are used 
without such separation by the system, it requires extensive testing of the 
exact functionality used (both for Qt framework and the application).

It should be noted that while there are many similarities, multiple industries 
have also defined their own approach to functional safety. With Qt Safe 
Renderer we are directly addressing: IEC 61508, IEC 62304, ISO 26262 and EN 
50128. Check details from the link above, if interested. Other ones can be also 
addressed leveraging the material created during the certification process, but 
requires additional steps.

While you are free to discuss the creation of safety critical systems via the 
Qt project mailing lists, in case you or someone are planning to create one, 
would be better to discuss with our functional safety experts and leverage 
items that are part of our commercial offering.

Yours,

Tuukka



From: Interest  on behalf of Ulf Hermann 

Date: Saturday, 2. October 2021 at 18.15
To: interest@qt-project.org 
Subject: Re: [Interest] Qt 5.15 LTS vs Qt 6.2 LTS
> There are no patient killing bugs in the underlying OS or the previously
> used drivers. Those only exist in the new drivers, new OS patches and
> new Qt code. All of the new code has to be written following 62304 SDLC

Although I doubt that Windows XP or the new graphics drivers are free of
patient killing bugs, I have to admit that you have a point here: If MS,
AMD, NVidia etc. went through the certification process with their
software, we can trust their software as much as we can trust anything
in such a system.

Now, what you probably want from Qt is a package that eliminates most of
those 5000+ bugs and that can itself be certified or at least accepted
in the approval process. The way to get there might be as follows:

1. Define a the feature set you need from Qt.
2. Turn off all unnecessary features using -no-feature-xyz on the
configure script (possibly defining more features in order to be able to
turn them off).
3. Wade through the bug database and sort out the bugs that remain valid
for such a stripped down Qt.
4. Deal with those bugs in whatever way the approval process mandates.
5. Port the resulting Qt to your target platform.

I might be wrong with those steps because I don't know the approval
process. Yet, I'm sure there is some pragmatic way to produce what you
want. You may want to share your ideas on what it actually takes.

While all of this is possible, it obviously is a lot of work. If you
want to do the work yourself, let's discuss the details here. If you
want to pay for such work to be done, you may want to get in contact
with the Qt Company. If you want to lament about such a specialized Qt
not materializing out of thin air, you got my sympathies, but you may
not get everybody's sympathies here. If you want to repeat that no one
you know is using Qt anymore, that won't be necessary. We've read it
often enough.

best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.15 LTS vs Qt 6.2 LTS

[Tuukka Turunen]

Hi,

Without knowing the details, of course a bit difficult to give definite 
guidance. Generally, if you are now using an earlier release of Qt, it is a 
good approach to first migrate to Qt 5.15 and fix all deprecation warnings etc 
before migrating to Qt 6.x. Just from the development / porting viewpoint, i.e. 
whether you ever ship with Qt 5.15 does not matter in this regard. Some small 
application can be ported directly, but for larger codebase it can be 
beneficial to take this intermediate step.

Yours,

Tuukka

From: Interest  on behalf of Ramakanth 
Kesireddy 
Date: Thursday, 23. September 2021 at 9.38
To: Qt Interest 
Subject: [Interest] Qt 5.15 LTS vs Qt 6.2 LTS
Hi,

Our application on embedded linux uses Qt Quick, Qt5 sqlite, Qt5 Remote 
objects, Qt5 Concurrent, Qt5 Webengine, Qt5 Printsupport along with Qt5Core and 
Qt5GUI.

As we are currently planning to upgrade to Qt 5.15 LTS, does it makes sense to 
move to Qt 6.2 LTS wrto stability and performance?

Appreciate your suggestions in this regard.

Best Regards,
Ramakanth
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 6.2.0 RC released

[Tuukka Turunen]

Hi,

We have gotten a lot of valuable feedback on the Qt 6.2 pre-releases and the RC 
looks very solid. There are always some things to fix, and now it is crucially 
important to get all feedback quickly to the release team.

There is time to fix issues before the Qt 6.2.0 final, but that requires that 
the work is done soon. So please take a look into the RC and provide feedback 
as soon as possible.

We have quite a lot of dependencies for the Qt 6.2 release so after a fix is 
done, we do need a few days at least to make all the packages. There are also 
some marketing activities coming with Qt 6.2, so it is important to get it out 
the week after next as planned.

We will also make regular patch releases and there are already some fixes in 
the 6.2 branch targeted to Qt 6.2.1. So in case the issue is not mandatory to 
fix immediately, target fixes to the next patch release. The low-risk issues 
like documentation and examples, we can more easily take into Qt 6.2.0 – as 
long as these are done early enough.

Yours,

Tuukka

From: Releasing  on behalf of Jani Heikkinen 

Date: Thursday, 16. September 2021 at 14.37
To: annou...@qt-project.org , 
developm...@qt-project.org , 
releas...@qt-project.org 
Subject: [Releasing] Qt 6.2.0 RC released
Hi Everyone!

We have released Qt 6.2.0 RC today. As earlier you can get it via the online 
installer. Src packages are also available in the Qt Account and 
download.qt.io. Delta to the beta4 attached.

The target is to release Qt 6.2.0 at the end of September so please inform us 
immediately if you find some issue that has to be fixed before the official Qt 
6.2.0 release. And please make sure all blockers are also visible in the 
release blocker list: https://bugreports.qt.io/issues/?filter=23304

br,
Jani Heikkinen
Release Manager
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt design studio with Qt 5.15.3 commercial license

[Tuukka Turunen]

Hi,

No mixing is allowed is the generic rule.

However, why would there be a need to use open-source version of Qt Creator by 
a person who has a commercial license of Qt? The commercial editions have Qt 
Creator always included so when a person has commercial Qt license there is no 
need to purchase Creator separately.

Yours,

Tuukka

From: Ramakanth Kesireddy 
Date: Tuesday, 6. July 2021 at 10.38
To: Tuukka Turunen 
Cc: Qt Interest 
Subject: Re: [Interest] Qt design studio with Qt 5.15.3 commercial license
Thanks for the detailed response.

Is it applicable even for the Qt creator IDE say 4.14.2 to procure the license 
or we can use community edition of Qt creator?

Best Regards,
Ramakanth
On Tue, 6 Jul, 2021, 12:05 Tuukka Turunen, 
mailto:tuukka.turu...@qt.io>> wrote:

Hi,

In this case the answer is: You need to have commercial license also for the Qt 
tools such as the Qt Design Studio you use in development of commercially 
licensed Qt application as mixing commercial and open-source Qt (including 
tools) is not allowed as described in 3.4 (viii) of the commercial license 
agreement.

Link to licensing FAQ: 
https://www.qt.io/faq/2.7.-can-some-developers-in-our-team-working-on-the-same-project-use-open-source-version-of-qt-and-some-developers-use-commercial-version-of-qt

We could add a more specific licensing FAQ entry about the tools, as it may me 
immediately apparent.

Yours,

Tuukka

From: Ramakanth Kesireddy mailto:rama.k...@gmail.com>>
Date: Monday, 5. July 2021 at 15.31
To: Tuukka Turunen mailto:tuukka.turu...@qt.io>>
Cc: Qt Interest mailto:interest@qt-project.org>>
Subject: Re: [Interest] Qt design studio with Qt 5.15.3 commercial license
Sorry I got it wrong.

I mean if we can use community edition of Qt design studio with Qt 5.15 
commercial license or need to procure separate license for Qt design studio?

Best Regards,
Ramakanth
On Mon, 5 Jul, 2021, 16:53 Tuukka Turunen, 
mailto:tuukka.turu...@qt.io>> wrote:
Hi,

Qt Design Studio is part of some commercial products (packages): 
https://www.qt.io/pricing

If unsure how this will be for you, please contact Qt sales.

Yours,

Tuukka

From: Interest 
mailto:interest-boun...@qt-project.org>> on 
behalf of Ramakanth Kesireddy mailto:rama.k...@gmail.com>>
Date: Monday, 5. July 2021 at 12.29
To: Qt Interest mailto:interest@qt-project.org>>
Subject: [Interest] Qt design studio with Qt 5.15.3 commercial license
Hi,

Can anyone confirm if we can use Qt design studio with Qt 5.15 commercial 
license or we need to procure separate license for Qt design studio?

Thanks and Regards,
Ramakanth
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt design studio with Qt 5.15.3 commercial license

[Tuukka Turunen]

Hi,

In this case the answer is: You need to have commercial license also for the Qt 
tools such as the Qt Design Studio you use in development of commercially 
licensed Qt application as mixing commercial and open-source Qt (including 
tools) is not allowed as described in 3.4 (viii) of the commercial license 
agreement.

Link to licensing FAQ: 
https://www.qt.io/faq/2.7.-can-some-developers-in-our-team-working-on-the-same-project-use-open-source-version-of-qt-and-some-developers-use-commercial-version-of-qt

We could add a more specific licensing FAQ entry about the tools, as it may me 
immediately apparent.

Yours,

Tuukka

From: Ramakanth Kesireddy 
Date: Monday, 5. July 2021 at 15.31
To: Tuukka Turunen 
Cc: Qt Interest 
Subject: Re: [Interest] Qt design studio with Qt 5.15.3 commercial license
Sorry I got it wrong.

I mean if we can use community edition of Qt design studio with Qt 5.15 
commercial license or need to procure separate license for Qt design studio?

Best Regards,
Ramakanth
On Mon, 5 Jul, 2021, 16:53 Tuukka Turunen, 
mailto:tuukka.turu...@qt.io>> wrote:
Hi,

Qt Design Studio is part of some commercial products (packages): 
https://www.qt.io/pricing

If unsure how this will be for you, please contact Qt sales.

Yours,

Tuukka

From: Interest 
mailto:interest-boun...@qt-project.org>> on 
behalf of Ramakanth Kesireddy mailto:rama.k...@gmail.com>>
Date: Monday, 5. July 2021 at 12.29
To: Qt Interest mailto:interest@qt-project.org>>
Subject: [Interest] Qt design studio with Qt 5.15.3 commercial license
Hi,

Can anyone confirm if we can use Qt design studio with Qt 5.15 commercial 
license or we need to procure separate license for Qt design studio?

Thanks and Regards,
Ramakanth
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt design studio with Qt 5.15.3 commercial license

[Tuukka Turunen]

Hi,

Qt Design Studio is part of some commercial products (packages): 
https://www.qt.io/pricing

If unsure how this will be for you, please contact Qt sales.

Yours,

Tuukka

From: Interest  on behalf of Ramakanth 
Kesireddy 
Date: Monday, 5. July 2021 at 12.29
To: Qt Interest 
Subject: [Interest] Qt design studio with Qt 5.15.3 commercial license
Hi,

Can anyone confirm if we can use Qt design studio with Qt 5.15 commercial 
license or we need to procure separate license for Qt design studio?

Thanks and Regards,
Ramakanth
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Mac Big Sur - Qt Open-Source Support For

[Tuukka Turunen]

Hi,

By “rough edges”, I was referring to no pre-built binaries and functionality 
not tested so there can be issues even though a lot of things will probably 
work just fine (Qt in general has been supporting ARM since ages).

Yours,

Tuukka

From: Interest  on behalf of Nuno Santos 

Date: Friday, 7. May 2021 at 14.05
To: Qt Interest 
Subject: Re: [Interest] [Development] Mac Big Sur - Qt Open-Source Support For
Thanks for your reply.

Can you please be more specific about the “rough edges”?

I know people that have been able to compile Qt 5.15 from the source with M1 
and so far so good.

Thanks!

Regards,

Nuno


On 7 May 2021, at 11:16, Tuukka Turunen 
mailto:tuukka.turu...@qt.io>> wrote:

Hi,

Supporting Apple silicon is something we are actively working to have in place 
for Qt 6.2 including full CI coverage etc.

To some extent things will work also with Qt 5.15 if you build yourself, but 
there are some rough edges (and Qt 5.15 is not tested for M1).

Yours,

Tuukka

From: Interest 
mailto:interest-boun...@qt-project.org>> on 
behalf of Nuno Santos 
mailto:nuno.san...@imaginando.pt>>
Date: Friday, 7. May 2021 at 13.10
To: Tor Arne Vestbø mailto:tor.arne.ves...@qt.io>>
Cc: Qt development mailing list 
mailto:developm...@qt-project.org>>, Qt Interest 
mailto:interest@qt-project.org>>
Subject: Re: [Interest] [Development] Mac Big Sur - Qt Open-Source Support For
Tor,

What about building Qt 5.15.X for M1 Macs?

Is there any kind of wiki resource out there?

Regards,

Nuno



On 7 May 2021, at 10:47, Tor Arne Vestbø 
mailto:tor.arne.ves...@qt.io>> wrote:

Qt 6.0 and above has official support for Big Sur:

https://doc.qt.io/archives/qt-6.0/macos.html

5.15 is not yet officially supported, but should work fine as well, so please 
report any issues in JIRA, thanks!

Cheers,
Tor Arne



On 7 May 2021, at 11:00, coroberti 
mailto:corobe...@gmail.com>> wrote:

Dear Tukka and others,
Since September Big Sur is a reality.

Which Qt-version supports correctly QWidgets for this platform for
open-source development.

If there's no such version, when the support is planned if ever.

I'd appreciate not to hijack this question for any discussions beyond the
very narrow scope of this question.

Thanks,

Kind regards,
Robert
___
Development mailing list
developm...@qt-project.org<mailto:developm...@qt-project.org>
https://lists.qt-project.org/listinfo/development

___
Interest mailing list
Interest@qt-project.org<mailto:Interest@qt-project.org>
https://lists.qt-project.org/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Mac Big Sur - Qt Open-Source Support For

[Tuukka Turunen]

Hi,

Supporting Apple silicon is something we are actively working to have in place 
for Qt 6.2 including full CI coverage etc.

To some extent things will work also with Qt 5.15 if you build yourself, but 
there are some rough edges (and Qt 5.15 is not tested for M1).

Yours,

Tuukka

From: Interest  on behalf of Nuno Santos 

Date: Friday, 7. May 2021 at 13.10
To: Tor Arne Vestbø 
Cc: Qt development mailing list , Qt Interest 

Subject: Re: [Interest] [Development] Mac Big Sur - Qt Open-Source Support For
Tor,

What about building Qt 5.15.X for M1 Macs?

Is there any kind of wiki resource out there?

Regards,

Nuno


On 7 May 2021, at 10:47, Tor Arne Vestbø 
mailto:tor.arne.ves...@qt.io>> wrote:

Qt 6.0 and above has official support for Big Sur:

https://doc.qt.io/archives/qt-6.0/macos.html

5.15 is not yet officially supported, but should work fine as well, so please 
report any issues in JIRA, thanks!

Cheers,
Tor Arne


On 7 May 2021, at 11:00, coroberti 
mailto:corobe...@gmail.com>> wrote:

Dear Tukka and others,
Since September Big Sur is a reality.

Which Qt-version supports correctly QWidgets for this platform for
open-source development.

If there's no such version, when the support is planned if ever.

I'd appreciate not to hijack this question for any discussions beyond the
very narrow scope of this question.

Thanks,

Kind regards,
Robert
___
Development mailing list
developm...@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] L Word

[Tuukka Turunen]

Hi,

Functional safety is a complex topic with multiple different standards 
depending upon what you are creating. In essence the needed measures are 
depending upon how likely someone is to get hurt when something goes wrong. The 
need depends upon what is done and typically there are multiple ways to achieve 
what is needed.

Here is a few years old presentation on the topic: https://youtu.be/AaU0OcOKlFk

In the Qt website there is also further info on the topic: 
https://www.qt.io/product/functional-safety-and-qt

Yours,

Tuukka

From: Interest  on behalf of Benjamin TERRIER 

Date: Monday, 3. May 2021 at 19.22
To: eric.fedosej...@gmail.com 
Cc: Qt Interest 
Subject: Re: [Interest] L Word

Le lun. 3 mai 2021 à 18:03, 
mailto:eric.fedosej...@gmail.com>> a écrit :
So basically open source/standard Qt was considered appropriate for safety 
critical devices prior to the introduction of Safe Renderer in 2017, but now 
only commercial Qt with Safe Renderer is appropriate for that purpose.

Before anyone says otherwise, Qt was widely used in safety critical 
applications before Safe Renderer existed. See for example the text from 
introductory blog post about Safe Renderer:
“Industries such as automotive, medical and industrial automation, where Qt is 
the leading UI framework, can now satisfy safety critical requirements with Qt 
easier than before.”

Qt never came with functional safety guarantee, so if you want to use Qt for 
that you have to audit and certify a specific Qt version (or whatever the 
regulator asks you to do). That's what had to be done before the introduction 
of Qt Safe Renderer, and that is something you can still do.

As the blog post says, the Qt Safe Renderer make it easier to use Qt in 
functional safety products because you only need to have the Qt Safe Renderer 
audited/certified an possibly it is something that TQC already does, removing 
the burden from its clients.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] L Word

[Tuukka Turunen]

Hi,

Perhaps we have been too long tolerant for the behavior that many see 
problematic (myself included). The challenge is the mix of valid and invalid 
items. It is easier to react to things that are clear violations to our CoC: 
http://quips-qt-io.herokuapp.com/quip-0012-Code-of-Conduct.html and nothing 
else.

On the positive side, we have not had that much of these over the years. We 
have not been banning people regularly, so we also lack a bit of precedence 
with this. Technically it is a trivial thing to remove someone from a mailing 
list. The challenging part is to decide when it is time to do that.

Yours,

Tuukka



From: Interest  on behalf of Massimiliano 
Maini 
Date: Thursday, 29. April 2021 at 14.23
To: Bernhard Lindner 
Cc: interest@qt-project.org 
Subject: Re: [Interest] L Word
Yeah, maybe that's part of the problem but, as you said, the solution
should be simple: he leaves the mailing list
or, if that's not possible, the admins "make him leave".

On top, with his ramblings and often totally wrong assertions (the
"April's fool link"-gate scandal has been absolutely
hilarious, almost as the subsequent attempt to regain some
credibility, yeah .. nice try) he has now managed to scare
the hell out of me the next time I'll be tied to a medical device: the
mere chance he may be behind it now makes me
extremely nervous. Even if it's only a blood pressure monitor.

Losing valuable people in the mailing list and, at some point, the
mailing list at all is like throwing away a Ferrari
because a pidgeon keeps shitting on it. I'd argue that getting rid of
the pidgeon is a more sensible solution.

On Thu, 29 Apr 2021 at 12:05, Bernhard Lindner
 wrote:
>
> The main problem isn't trolling. The main problem is: Roland comes from a 
> completely
> different world. The world of functional safety. This world is difficult and 
> a completely
> different from conventional software development. It is particularly 
> different from
> smartphone and web development. And it doesn't have much to do with desktop 
> software
> development. I have also been in this world for more than 3 years. A world 
> where
> programming is the least important thing. Where documentation is important. 
> And the law.
> And prison. And accuracy and multi-level tests and reliability and 
> verification and
> validation and standards. And many years of support. And certifications. A 
> person who has
> worked in this world for a long time has different priorities. Roland calls 
> this "True
> Software Engineering".
>
> Obviously, Qt has nothing to do with this type of software engineering. And 
> it's obviously
> not suitable for functional safety (at least not if you take it seriously).
>
> What I don't understand is why Roland doesn't just leave the mailing list and 
> forget about
> Qt. Qt is not suitable for use in his industrial sector, so I can't 
> understand why he
> spends so much time writing about the conflict between the reality of Qt and 
> the reality
> of his industrial sector. If I were him, I would have given up trying to 
> influence Qt's
> strategy a long time ago.
>
> (Actually, I'm about to give up my hopes for desktop development with Qt).
>
> So, Roland, why are you keeping the conflicts going?
>
> --
> Best Regards,
> Bernhard Lindner
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] the path forward - that 7 year thing - was, , willy-nilly

[Tuukka Turunen]

Hi Jason,

Please contact our sales to discuss commercial licensing. Based on the email 
below you seem to misunderstand the commercial development and distribution 
licensing at least partially.

Yours,

Tuukka


Lähettäjä: Jason H 
Lähetetty: sunnuntaina, maaliskuuta 28, 2021 4:52 ip.
Vastaanottaja: Tuukka Turunen
Kopio: Roland Hughes; interest@qt-project.org; mike.jack...@bluequartz.net
Aihe: Re: [Interest] the path forward - that 7 year thing - was, , willy-nilly

Tukka, you (Digia, aka "QtCo") no longer offer the perpetuity clause of the 
license. Which is absolutely insane for a commercial customer.  If we are no 
longer developing that code, we should still be able to "distribute" that code. 
The revocation of the perpetuity clause in new licenses means we can no longer 
do that. We aren't even asking for support in perpetuity, just the ability to 
distribute what we had been...

The developers at Qt Co need to push back and tell Digia "that's not how this 
works" before we get to the points of users revolting in threads on the forums 
/ lists. It's a bad look. Anyone investigating Qt would be throughly turned off 
by now, and I can't say I would blame them.

It's really sad it's gotten this far. I've been licensing Qt off and on since 
2005 and watching it erode this whole time. I still think it's the greatest 
tech, but the licensing is quickly becoming the limiting factor.  So much so, 
that I have Qt in consideration at another company, and I am about to pull the 
plug because the licensing has changed so much.

At some point the business people have to realize that they are selling to 
engineers, and this is a much more nuanced field, and this license erosion is 
noticed.

Yeah, we noticed when QtPdf license changed:
https://www.qt.io/blog/2017/01/30/new-qtpdf-qtlabs-module (LGPLv3)
https://www.qt.io/blog/change-in-open-source-licensing-of-qt-wayland-compositor-qt-application-manager-and-qt-pdf
 (Tukka's own post)
https://lists.qt-project.org/pipermail/development/2019-October/037698.html 
(Not everyone was on board with the license change)
But it's now under the marketplace license?
https://marketplace.qt.io/collections/most-popular/products/qtpdf ($49/ 
Marketplace license)


Shenannigans. I declare shenannigans.

Sent: Saturday, March 27, 2021 at 4:23 AM
From: "Tuukka Turunen" 
To: "Roland Hughes" , "interest@qt-project.org" 
, "mike.jack...@bluequartz.net" 

Subject: Re: [Interest] the path forward - that 7 year thing - was, , 
willy-nilly

“When Qt chased these markets it knew what the lifetimes would be. Now it has 
abandoned them.”

I would like to point out that this is not a true statement. We do offer long 
term support and also extended support for those customers who need it. There 
are some who every now and then still need something related to Qt 3. Somewhere 
Qt 2 is still in use. Perhaps Qt 1 even, but personally not certain about that. 
Qt 4 based systems of course and majority of customers are with Qt 5 currently.

Each of these versions has changed API and we have tried our best to make the 
transition from Qt 5 to Qt 6 smooth. We are happy to get suggestions and 
feedback to it still and help in the transition.

Yours,

Tuukka


Lähettäjä: Interest  käyttäjän Roland Hughes 
 puolesta
Lähetetty: Friday, March 26, 2021 10:47:34 PM
Vastaanottaja: interest@qt-project.org ; 
mike.jack...@bluequartz.net 
Aihe: Re: [Interest] the path forward - that 7 year thing - was, , willy-nilly


On 3/26/21 1:39 PM, Michael Jackson wrote:
>  I'll start off by acknowledging your points, but we will just agree to 
> disagree. I acknowledge that you have a*lot*  of years making/maintaining 
> software for medical devices. But I'm with Hamish on this. I don't understand.
>
> What you are saying is that Qt was designed "perfectly" from day one with no 
> extra API, not one bad API implementation and no cruft. Qt should never be 
> updated to run on modern compilers against modern C++ specifications. Updated 
> to run on modern operating systems. Qt should not explore adding 
> APIs/Toolkits to the Qt ecosystem to allow Qt to be used on the billions of 
> devices that we use every day. Qt should just stick with its technology from 
> 20 years ago. TQtC shouldn't go after paying customers in order to, you know, 
> pay its developers. TQtC should rely solely on an industry that, by your own 
> writings, have a 15 year horizon. Not much of a business case for that. (For 
> the record, I don't particularly agree with TQtC current licensing or LTS 
> strategy.)

No. Not what I'm saying at all. I have no idea how you got there from
what I've said.

Stable API.  Nothing ever gets deleted until it has a direct or mostly
replacement *within* the existing product.

When Qt chased these markets it knew what the lifeti

Re: [Interest] the path forward - that 7 year thing - was, , willy-nilly

[Tuukka Turunen]

“When Qt chased these markets it knew what the lifetimes would be. Now it has 
abandoned them.”

I would like to point out that this is not a true statement. We do offer long 
term support and also extended support for those customers who need it. There 
are some who every now and then still need something related to Qt 3. Somewhere 
Qt 2 is still in use. Perhaps Qt 1 even, but personally not certain about that. 
Qt 4 based systems of course and majority of customers are with Qt 5 currently.

Each of these versions has changed API and we have tried our best to make the 
transition from Qt 5 to Qt 6 smooth. We are happy to get suggestions and 
feedback to it still and help in the transition.

Yours,

Tuukka


Lähettäjä: Interest  käyttäjän Roland Hughes 
 puolesta
Lähetetty: Friday, March 26, 2021 10:47:34 PM
Vastaanottaja: interest@qt-project.org ; 
mike.jack...@bluequartz.net 
Aihe: Re: [Interest] the path forward - that 7 year thing - was, , willy-nilly


On 3/26/21 1:39 PM, Michael Jackson wrote:
>  I'll start off by acknowledging your points, but we will just agree to 
> disagree. I acknowledge that you have a*lot*  of years making/maintaining 
> software for medical devices. But I'm with Hamish on this. I don't understand.
>
> What you are saying is that Qt was designed "perfectly" from day one with no 
> extra API, not one bad API implementation and no cruft. Qt should never be 
> updated to run on modern compilers against modern C++ specifications. Updated 
> to run on modern operating systems. Qt should not explore adding 
> APIs/Toolkits to the Qt ecosystem to allow Qt to be used on the billions of 
> devices that we use every day. Qt should just stick with its technology from 
> 20 years ago. TQtC shouldn't go after paying customers in order to, you know, 
> pay its developers. TQtC should rely solely on an industry that, by your own 
> writings, have a 15 year horizon. Not much of a business case for that. (For 
> the record, I don't particularly agree with TQtC current licensing or LTS 
> strategy.)

No. Not what I'm saying at all. I have no idea how you got there from
what I've said.

Stable API.  Nothing ever gets deleted until it has a direct or mostly
replacement *within* the existing product.

When Qt chased these markets it knew what the lifetimes would be. Now it
has abandoned them.

> I also don't understand your argument that you want to update a medical 
> device from 20 years ago with the latest and greatest toolkits. I can't 
> imagine anything electronic from 20 years ago being able to actually load and 
> run anything like Qt? How is the hardware even powerful enough to do this? 
> You can't convince me that the medical hardware device manufacturers were 
> thinking 15 years into the future for the next upgrade, 15 years ago.
The surgical robots being sold today will require 20 year support
lifespans. Many of the devices sold over the past decade were sold with
a minimum 10 year support and maintenance requirement. The development
effort on these devices runs into the millions. You can't make a bet
like that and find out a year later the supplier flew off to the Cayman
Islands with Ted Cruz and your money.
> 50 Year Old equipment. You make the case even more for TQtC to pursue 
> customers with a much shorter timeline. If TQtC concentrated on markets with 
> 20-50 year timelines for updates how much revenue do you think they would 
> make? Enough to sustain Qt development in any real capacity? Doubtful.

Okay. There's an education situation here.

I've never worked for a one-trick-pony medical device company. For
certain there are the grant/research funded things coming out of college
labs. That Phd. student doesn't take it to production. A Baxter,
Hill-Rom, GE, etc. type player will be who said thing gets sold to. They
will take it through FDA approval and to full production. Usually they
end up hiring the person or small college team that created it.

Baxter (and I imagine all the rest) actually invest in many tiny startup
medical device companies if there is a good idea that has already had
some fundamental work. They invest with the intent of consuming some/all
of it when it is obvious the thing will work. Here, this might help.

https://www.gehealthcare.com/products/accessories-and-supplies/clinical-accessories-and-supplies

Click on Products & Services and then click Equipment and follow across.
Those are just the devices GE puts out under its *own* brand. It owns
whole or in part lots of other little companies putting out medical
devices under their own brand. Hill-Rom is much the same from that
perspective.

You are thinking in terms of the x86 world where there are oceans of
one-trick-ponies. Companies like Install-Shield that had one big hit
followed by some flame-outs. Last I heard they were still just a one
product company. It's a cultural thing tied to that platform.

Here's reality in the medical device world.

Year one you get 

Re: [Interest] Interest Digest, Vol 114, Issue 23

[Tuukka Turunen]

Hi,

Feedback on the Qt 6 API is valuable and we are very interested in it. 
Portability was one of the key design principles and we have avoided making 
changes when not needed. That said, there can surely be some items that are 
unnecessarily changed.

Knowing what is the problem and the intended use case helps to have this 
discussion. Our API review process is fully open, but it is natural that users 
do not want to necessarily engage in it. So we welcome the feedback on the API 
also now and will try to seek ways to improve based on it.

Yours,

Tuukka


Lähettäjä: Interest  käyttäjän Turtle Creek 
Software  puolesta
Lähetetty: tiistaina, maaliskuuta 23, 2021 1:36 ap.
Vastaanottaja: interest@qt-project.org
Aihe: Re: [Interest] Interest Digest, Vol 114, Issue 23

Re: willy-nilly

I find this discussion interesting, because we ranted on the Cocoa-dev list for 
a while and probably sounded a lot like Roland.  That was after we spent 3 
years porting our C++ desktop app from Mac Carbon to Cocoa, and barely got half 
done.  With huge effort we might have finished about now, just in time for M1, 
Swift and SwiftUI rewrites. It seemed prudent to give up instead.

Many people seem to be looking for the same thing: a stable platform that will 
stick around for a decade or more. They're not finding it, in Qt or anywhere.  
Summed up in this post:

https://blog.royalsloth.eu/posts/sad-state-of-cross-platform-gui-frameworks/

After leaving Cocoa behind, we tried updating our Windows app with MFC. That 
was a horrible year. WinUi3 promises to make C++ apps easier but it probably 
will stay vapor or be bungled.  So we tried Qt.

After 8 months, so far it is working great for our needs. We may even ship 
something by late 2021.  But Qt's long-term future seems rather grim, and that 
is very discouraging.  We have 15 programmer-years of cross-platform business 
logic that's pining away for lack of a decent GUI framework that sticks around 
for long enough to recoup the investment.

I can relate to anyone who is unhappy about deprecated functions.  It is never 
fun when existing code breaks.  We want to be inventing new stuff, not going 
back and fixing old code just to stay in the same place.  The C++ language has 
been decent about advancing, but still keeping ancient code stable.  Windows 
bends over backwards to stay backwards compatible. I think it's a basic 
courtesy that all platforms owe to developers.  Programming is hard. Doing 
things once should be enough.

We know a lot about construction, accounting and estimating, and enough about 
programming to make useful software for it. But we need tools that let us spend 
time creating actual solutions.  Not reinventing wheels just to have the same 
GUI.

Casey McDermott
TurtleSoft.com
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Mixing Commercial and Open Source license for different projects

[Tuukka Turunen]

Hi James,

You asked if it is allowed for a developer who has purchased commercial license 
of Qt for project A to work on project B using open-source license of Qt. 
Assuming that these projects are separate (independent and not related to each 
other in any way), this is possible. The reason for limitation of mixing 
open-source and commercial versions is indented to prevent some person(s) who 
do not have a commercial license to use open-source version of Qt for work 
benefitting the commercially licensed software. This is not the case in the 
situation you described as long as these projects really are separate (not just 
paid by different companies).

Yours,

Tuukka

From: Interest  on behalf of James Maxwell 

Date: Sunday, 14. March 2021 at 16.32
To: interest@qt-project.org 
Subject: [Interest] Mixing Commercial and Open Source license for different 
projects
Hi,

I am confused by the requirement of not mixing licenses, see the discussion in 
this thread:
https://lists.qt-project.org/pipermail/interest/2020-March/034737.html

The situation is as follows: I am an independent software developer. If my 
customer A wants to use a commercial license and my customer B wants to use the 
GPL orLGPL license, can I still develop software for both?
For A I need a commercial license. Am I then still allowed to use QtCreator 
under my commercial license to develop a LGPL project for customer B?

Best regards,
James
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt WebEngine 5.15.3 tag

[Tuukka Turunen]

Hi,

I do understand the desire to have a supported / tagged release of QWE and it 
is possible that it might even work quite well on an earlier release of Qt. 
However, we are testing it in conjunction with the other changes of a new patch 
level release and do not want to give a guarantee that new releases of QWE 
would always work with earlier releases of other modules. Tagging a release 
would give such indication.

What would be a good way forward (other that testing each new QWE version to 
work on Qt 5.15.2)?

Yours,

Tuukka


Lähettäjä: Interest  käyttäjän Florian Bruhin 
 puolesta
Lähetetty: Tuesday, March 9, 2021 7:53:52 PM
Vastaanottaja: Benjamin TERRIER 
Kopio: Qt Interest 
Aihe: Re: [Interest] Qt WebEngine 5.15.3 tag

On Tue, Mar 09, 2021 at 06:37:35PM +0100, Benjamin TERRIER wrote:
> I am pretty sure that Linux distros which have Qt 5.15 would be interested
> in upgrading their Qt WebEngine to 5.15.3+

They can - Gentoo did even before the release, Archlinux did after I
asked them to do so and convinced them it's not an accident that no tag
exists for it (can't blame them, like I said, it's bizarre).

But other Linux package maintainers might not even notice or know a new
release is out (which I suspect is TQtC's aim here - keep in mind,
QtWebEngine is probably only still public because the LGPL enforces
that, apparently the people in charge of those decisions don't care
about the involved serious security bugs much...).

A dangerous and unethical game to play, even more so when considering
that pushing a git tag is zero effort and the change file already was
written...

Florian

--
m...@the-compiler.org | https://www.qutebrowser.org
   https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
 I love long mails! | https://email.is-not-s.ms/
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt WebEngine 5.15.3 tag

[Tuukka Turunen]

Hi,

The plan has been not to tag the release in the public repo as part of the 
commercial-lts phase.

Yours,

Tuukka

From: Interest  on behalf of Benjamin TERRIER 

Date: Thursday, 4. March 2021 at 16.21
To: Qt Interest 
Subject: [Interest] Qt WebEngine 5.15.3 tag
Hi,

Given that the Qt WebEngine module is an exception to the commercial only LTS 
support,
could we have v5.15.3 tags for https://code.qt.io/cgit/qt/qtwebengine.git/ and 
https://code.qt.io/cgit/qt/qtwebengine-chromium.git/ ?

Thanks

Benjamin
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] [Releasing] download.qt.io is down

[Tuukka Turunen]

Hi,

This mail was already sent earlier to the list.

Bugreport link is still valid. In case of issues, file a bug.

Yours,

Tuukka

From: Development 
Date: Friday, 5. February 2021 at 10.11
To: Alexandre Ribeiro 
Cc: Qt Project Development , Interests Qt 

Subject: Re: [Development] [Interest] [Releasing] download.qt.io is down

Hi,

There are some items still not fully working in the system for example related 
to being able to provide the right/best mirror.

Please file a bug with details. That is typically the best approach to help 
find out what is going wrong.

Direct link for filing a bug for the right component:

https://bugreports.qt.io/secure/CreateIssueDetails!init.jspa?pid=10510=1=19211

Yours,

Tuukka

From: Alexandre Ribeiro 
Date: Wednesday, 27. January 2021 at 14.24
To: Tuukka Turunen 
Cc: Qt Project Development , Interests Qt 

Subject: Re: [Interest] [Development] [Releasing] download.qt.io is down
Hi,

There are still issues with the online installer:



And if you go to 
https://download.qt.io/online/qtsdkrepository/mac_x64/desktop/tools_maintenance/
 the 2020-12-03-0501_meta.7z file is indeed missing.

Are there any workarounds for this issue?

Thanks,
Alex

On Fri, Jan 22, 2021 at 2:30 PM Tuukka Turunen 
mailto:tuukka.turu...@qt.io>> wrote:
Hi,

Servers have been restored and open-source downloads are working again.

Archive of old and historic releases is missing, but will be made available 
next week.

Blog post: https://www.qt.io/blog/open-source-downloads-working-again

Yours,

Tuukka

From: coroberti mailto:corobe...@gmail.com>>
Date: Friday, 22. January 2021 at 11.32
To: Nils Jeisecke 
mailto:nils.jeise...@saltation.com>>, Tuukka 
Turunen mailto:tuukka.turu...@qt.io>>, Qt Project 
Development mailto:developm...@qt-project.org>>
Subject: Re: [Development] [Releasing] [Interest] 
download.qt.io<http://download.qt.io> is down
On Fri, Jan 22, 2021 at 10:38 AM Nils Jeisecke via Development
mailto:developm...@qt-project.org>> wrote:
>
> Hi there,
>
> On Fri, Jan 22, 2021 at 7:59 AM Tuukka Turunen 
> mailto:tuukka.turu...@qt.io>> wrote:
>>
>> Hi,
>>
>>
>>
>> Status update of the problem with open-source downloads: Last night we 
>> finally got a disk big enough for the packages from the service provider. 
>> Most of the data has been transferred throughout the night with a few last 
>> things still being uploaded to the new virtual server. After the data 
>> transfer is complete we start testing and validation of the data and the 
>> system. Target is to enable first the online installer, then the offline 
>> packages and finally the achieve of old releases.
>
>
> just a little "Thank You" from my side.
>
> I try to imagine being of those spending hour after hour to get things 
> running again and then reading all those nasty comments on the blog post.
>
> Nils

Joining the thanks of Nils.
We are really appreciating your support of open-source distribution.

Kind regards,
Robert Iakobashvili

___
Interest mailing list
Interest@qt-project.org<mailto:Interest@qt-project.org>
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] [Releasing] download.qt.io is down

[Tuukka Turunen]

Hi,

There are some items not fully working in the system for example related to 
being able to provide the right/best mirror.

Please file a bug with details. That is typically the best approach to help 
find out what is going wrong.

Direct link for filing a bug for the right component:

https://bugreports.qt.io/secure/CreateIssueDetails!init.jspa?pid=10510=1=19211

Yours,

Tuukka


From: Alexandre Ribeiro 
Date: Wednesday, 27. January 2021 at 14.24
To: Tuukka Turunen 
Cc: Qt Project Development , Interests Qt 

Subject: Re: [Interest] [Development] [Releasing] download.qt.io is down
Hi,

There are still issues with the online installer:



And if you go to 
https://download.qt.io/online/qtsdkrepository/mac_x64/desktop/tools_maintenance/
 the 2020-12-03-0501_meta.7z file is indeed missing.

Are there any workarounds for this issue?

Thanks,
Alex

On Fri, Jan 22, 2021 at 2:30 PM Tuukka Turunen 
mailto:tuukka.turu...@qt.io>> wrote:
Hi,

Servers have been restored and open-source downloads are working again.

Archive of old and historic releases is missing, but will be made available 
next week.

Blog post: https://www.qt.io/blog/open-source-downloads-working-again

Yours,

Tuukka

From: coroberti mailto:corobe...@gmail.com>>
Date: Friday, 22. January 2021 at 11.32
To: Nils Jeisecke 
mailto:nils.jeise...@saltation.com>>, Tuukka 
Turunen mailto:tuukka.turu...@qt.io>>, Qt Project 
Development mailto:developm...@qt-project.org>>
Subject: Re: [Development] [Releasing] [Interest] 
download.qt.io<http://download.qt.io> is down
On Fri, Jan 22, 2021 at 10:38 AM Nils Jeisecke via Development
mailto:developm...@qt-project.org>> wrote:
>
> Hi there,
>
> On Fri, Jan 22, 2021 at 7:59 AM Tuukka Turunen 
> mailto:tuukka.turu...@qt.io>> wrote:
>>
>> Hi,
>>
>>
>>
>> Status update of the problem with open-source downloads: Last night we 
>> finally got a disk big enough for the packages from the service provider. 
>> Most of the data has been transferred throughout the night with a few last 
>> things still being uploaded to the new virtual server. After the data 
>> transfer is complete we start testing and validation of the data and the 
>> system. Target is to enable first the online installer, then the offline 
>> packages and finally the achieve of old releases.
>
>
> just a little "Thank You" from my side.
>
> I try to imagine being of those spending hour after hour to get things 
> running again and then reading all those nasty comments on the blog post.
>
> Nils

Joining the thanks of Nils.
We are really appreciating your support of open-source distribution.

Kind regards,
Robert Iakobashvili

___
Interest mailing list
Interest@qt-project.org<mailto:Interest@qt-project.org>
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] [Releasing] download.qt.io is down

[Tuukka Turunen]

Hi,

Servers have been restored and open-source downloads are working again.

Archive of old and historic releases is missing, but will be made available 
next week.

Blog post: https://www.qt.io/blog/open-source-downloads-working-again

Yours,

Tuukka

From: coroberti 
Date: Friday, 22. January 2021 at 11.32
To: Nils Jeisecke , Tuukka Turunen 
, Qt Project Development 
Subject: Re: [Development] [Releasing] [Interest] download.qt.io is down
On Fri, Jan 22, 2021 at 10:38 AM Nils Jeisecke via Development
 wrote:
>
> Hi there,
>
> On Fri, Jan 22, 2021 at 7:59 AM Tuukka Turunen  wrote:
>>
>> Hi,
>>
>>
>>
>> Status update of the problem with open-source downloads: Last night we 
>> finally got a disk big enough for the packages from the service provider. 
>> Most of the data has been transferred throughout the night with a few last 
>> things still being uploaded to the new virtual server. After the data 
>> transfer is complete we start testing and validation of the data and the 
>> system. Target is to enable first the online installer, then the offline 
>> packages and finally the achieve of old releases.
>
>
> just a little "Thank You" from my side.
>
> I try to imagine being of those spending hour after hour to get things 
> running again and then reading all those nasty comments on the blog post.
>
> Nils

Joining the thanks of Nils.
We are really appreciating your support of open-source distribution.

Kind regards,
Robert Iakobashvili

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Releasing] download.qt.io is down

[Tuukka Turunen]

Hi,

Yes, this is correct.

Yours,

Tuukka

From: Sze Howe Koh 
Date: Wednesday, 20. January 2021 at 0.10
To: Tuukka Turunen 
Cc: Mark Long , developm...@qt-project.org 
, Interests Qt , 
releas...@qt-project.org 
Subject: Re: [Releasing] [Interest] download.qt.io is down
On Wed, 20 Jan 2021 at 04:10, Tuukka Turunen  wrote:
>
>
> Hi,
>
> There are multiple mirrors, try for example:
>
>
>
> https://qt-mirror.dannhauer.de/
>
> https://www.funet.fi/pub/mirrors/download.qt-project.org/
>
> https://ftp.fau.de/qtproject/
>
>
>
> ...or just use the online installer, which picks mirrors automatically.
>
> Yours,
>
> Tuukka

Hi Tuuka,

The Online installer downloads files in 2 phases:

1. Retrieve metadata from download.qt.io
2. Retrieve actual binaries from the auto-selected mirror

Since Step #1 is blocked, it can't proceed to Step #2.


Regards,
Sze-Howe
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] download.qt.io is down

[Tuukka Turunen]

Hi,

There are multiple mirrors, try for example:



https://qt-mirror.dannhauer.de/

https://www.funet.fi/pub/mirrors/download.qt-project.org/

https://ftp.fau.de/qtproject/



...or just use the online installer, which picks mirrors automatically.

Yours,

Tuukka


Lähettäjä: Mark Long 
Lähetetty: tiistaina, tammikuuta 19, 2021 9:58 ip.
Vastaanottaja: Tuukka Turunen
Kopio: Jani Heikkinen; developm...@qt-project.org; releas...@qt-project.org; 
Interests Qt
Aihe: Re: [Interest] download.qt.io is down

It seems that the only mirror list I can find online is served from 
download.qt.io<http://download.qt.io>, which is quite unhelpful at the moment.  
Does anyone have a mirror link handy or a link to another list somewhere else?

Thanks much!
Mark

On Tue, Jan 19, 2021 at 12:59 PM Tuukka Turunen 
mailto:tuukka.turu...@qt.io>> wrote:
Hi,

Update on the status. The downtime is caused by severe disk system failure at 
our cloud service provider. The service provider has notified us that they will 
not be able to repair the disk systems during today.

Two important servers related to open-source package delivery are affected 
(download frontend and delivery system master). Mirrors are not affected, so 
online installer works and also offline packages can be downloaded directly 
from the mirrors. Commercial package distribution is done via a different 
system, which is not affected by this.

Yours,

Tuukka

From: Development 
mailto:development-boun...@qt-project.org>>
Date: Tuesday, 19. January 2021 at 11.21
To: developm...@qt-project.org<mailto:developm...@qt-project.org> 
mailto:developm...@qt-project.org>>, 
releas...@qt-project.org<mailto:releas...@qt-project.org> 
mailto:releas...@qt-project.org>>
Subject: [Development] download.qt.io<http://download.qt.io> is down
Hi all,

You have most probably already noticed that 
download.qt.io<http://download.qt.io> is down. We are fixing the issue so 
please be patient. I'll inform you when it should work OK

br,
Jani Heikkinen
Release Manager
___
Development mailing list
developm...@qt-project.org<mailto:developm...@qt-project.org>
https://lists.qt-project.org/listinfo/development
___
Interest mailing list
Interest@qt-project.org<mailto:Interest@qt-project.org>
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] download.qt.io is down

[Tuukka Turunen]

Hi,

Update on the status. The downtime is caused by severe disk system failure at 
our cloud service provider. The service provider has notified us that they will 
not be able to repair the disk systems during today.

Two important servers related to open-source package delivery are affected 
(download frontend and delivery system master). Mirrors are not affected, so 
online installer works and also offline packages can be downloaded directly 
from the mirrors. Commercial package distribution is done via a different 
system, which is not affected by this.

Yours,

Tuukka

From: Development 
Date: Tuesday, 19. January 2021 at 11.21
To: developm...@qt-project.org , 
releas...@qt-project.org 
Subject: [Development] download.qt.io is down
Hi all,

You have most probably already noticed that download.qt.io is down. We are 
fixing the issue so please be patient. I'll inform you when it should work OK

br,
Jani Heikkinen
Release Manager
___
Development mailing list
developm...@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.15 pull out of open source?!

[Tuukka Turunen]

Looking at how my text art came through the mailing list service, there is too 
much overlap. I tried to “draw” this so that next one begins around the time 
previous ends, but did not fully succeed. I hope the main point was still 
successfully conveyed.

Yours,

Tuukka

From: Interest 
Date: Thursday, 7. January 2021 at 17.42
To: Michael Jackson , interest@qt-project.org 

Subject: Re: [Interest] Qt 5.15 pull out of open source?!

Hi Michael,

All Qt feature releases are available for all users of Qt. It is just the 
extended period of long-term support that is available for commercial license 
holders only.

One way to visualize period of available patch releases for open-source users 
is as follows:

Qt 5.13 *
Qt 5.14 ***
Qt 5.15   **
Qt 6.0 
Qt 6.1   **
Qt 6.2  *
Qt 6.3  
**


Same thing for commercial users is as follows:

Qt 5.13 *
Qt 5.14 ***
Qt 5.15 LTS   
*
Qt 6.0 
Qt 6.1  **
Qt 6.2 LTS  
*
Qt 6.3  
**

Note that this is an indicative visualization of the period when patch releases 
are created for each Qt version, not accurate timeline representation of patch 
release dates.

In essence the situation for open-source users is just like it was for everyone 
before introducing the long-term supported releases (with Qt 5.6).

Yours,

Tuukka

From: Michael Jackson 
Date: Thursday, 7. January 2021 at 17.01
To: Tuukka Turunen , interest@qt-project.org 

Subject: Re: [Interest] Qt 5.15 pull out of open source?!
Dear Tuukka,
As an open source developer who has used Qt since 2009, I am still a bit 
confused as to what versions of Qt6 that my open-source project should be using 
over time? For example, we might be lucky enough to port to the 6.0 release, 
and then to 6.1. If 6.2 is LTS and commercial only, what is the next Qt 6 
version that an open-source project would jump to? Would that be 6.3? Is TQtC 
going to do something like the “odd (6.1, 6.3…)” releases are opensource but 
the “even (62, 6.4…)” releases are commercial only? Is there a longer term 
roadmap available that explains TQtC vision on how this will work?

--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net


From: Interest  on behalf of Tuukka Turunen 

Date: Thursday, January 7, 2021 at 4:38 AM
To: Giuseppe D'Angelo , "interest@qt-project.org" 

Subject: Re: [Interest] Qt 5.15 pull out of open source?!

Hi,

Apologies for not sending the mail also to the interest mailing list. This is 
nothing new, as this was announced in already February 2020. Otherwise Qt 
continues to be available for open-source users, but the long-term support 
releases of Qt will be available only for the commercial license holders. First 
commercial-only patch release being Qt 5.15.3 planned to be released in 
February 2021.

Qt 5.15.2 continues to be available for all users, so situation is similar as 
with Qt 5.13 and Qt 5.14, for example (no new patch releases). Qt 6.0.0 and 
subsequent patch releases, as well as upcoming Qt 6.1 and Qt 6.2 etc releases 
are also available for open-source users. Eventually we will enter 
long-term-support phase with Qt 6.2 LTS at which point again these are only for 
commercial license holders, but all releases done until that point continue to 
be available for all users.

Yours,

Tuukka



From: Interest 
Date: Thursday, 7. January 2021 at 10.45
To: interest@qt-project.org 
Subject: Re: [Interest] Qt 5.15 pull out of open source?!
Hi,

Il 07/01/21 04:03, Jérôme Godbout ha scritto:
> Hi,
> is this any true?
> https://www.phoronix.com/scan.php?page=news_item=Qt-5.15-LTS-Commercial-Phase

Please see the thread on development@ (no idea why the original message
was not posted on interest@ as well.).

> https://lists.qt-project.org/pipermail/development/2021-January/040798.html


HTH,

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
___ Interest mailing list 
Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-projec

Re: [Interest] Qt 5.15 pull out of open source?!

[Tuukka Turunen]

Hi Michael,

All Qt feature releases are available for all users of Qt. It is just the 
extended period of long-term support that is available for commercial license 
holders only. 

One way to visualize period of available patch releases for open-source users 
is as follows:

Qt 5.13 *
Qt 5.14 ***
Qt 5.15 **
Qt 6.0 
Qt 6.1   **
Qt 6.2  *
Qt 6.3  
**


Same thing for commercial users is as follows:

Qt 5.13 *
Qt 5.14 ***
Qt 5.15 LTS 
*
Qt 6.0 
Qt 6.1  **
Qt 6.2 LTS  
*
Qt 6.3  
**

Note that this is an indicative visualization of the period when patch releases 
are created for each Qt version, not accurate timeline representation of patch 
release dates. 

In essence the situation for open-source users is just like it was for everyone 
before introducing the long-term supported releases (with Qt 5.6). 

Yours,

Tuukka

From: Michael Jackson 
Date: Thursday, 7. January 2021 at 17.01
To: Tuukka Turunen , interest@qt-project.org 

Subject: Re: [Interest] Qt 5.15 pull out of open source?!
Dear Tuukka, 
As an open source developer who has used Qt since 2009, I am still a bit 
confused as to what versions of Qt6 that my open-source project should be using 
over time? For example, we might be lucky enough to port to the 6.0 release, 
and then to 6.1. If 6.2 is LTS and commercial only, what is the next Qt 6 
version that an open-source project would jump to? Would that be 6.3? Is TQtC 
going to do something like the “odd (6.1, 6.3…)” releases are opensource but 
the “even (62, 6.4…)” releases are commercial only? Is there a longer term 
roadmap available that explains TQtC vision on how this will work?
 
--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net
 
 
From: Interest  on behalf of Tuukka Turunen 

Date: Thursday, January 7, 2021 at 4:38 AM
To: Giuseppe D'Angelo , "interest@qt-project.org" 

Subject: Re: [Interest] Qt 5.15 pull out of open source?!
 
Hi,
 
Apologies for not sending the mail also to the interest mailing list. This is 
nothing new, as this was announced in already February 2020. Otherwise Qt 
continues to be available for open-source users, but the long-term support 
releases of Qt will be available only for the commercial license holders. First 
commercial-only patch release being Qt 5.15.3 planned to be released in 
February 2021. 
 
Qt 5.15.2 continues to be available for all users, so situation is similar as 
with Qt 5.13 and Qt 5.14, for example (no new patch releases). Qt 6.0.0 and 
subsequent patch releases, as well as upcoming Qt 6.1 and Qt 6.2 etc releases 
are also available for open-source users. Eventually we will enter 
long-term-support phase with Qt 6.2 LTS at which point again these are only for 
commercial license holders, but all releases done until that point continue to 
be available for all users. 
 
Yours,
 
    Tuukka
 
 
 
From: Interest 
Date: Thursday, 7. January 2021 at 10.45
To: interest@qt-project.org 
Subject: Re: [Interest] Qt 5.15 pull out of open source?!
Hi,

Il 07/01/21 04:03, Jérôme Godbout ha scritto:
> Hi,
> is this any true?
> https://www.phoronix.com/scan.php?page=news_item=Qt-5.15-LTS-Commercial-Phase

Please see the thread on development@ (no idea why the original message 
was not posted on interest@ as well.).

> https://lists.qt-project.org/pipermail/development/2021-January/040798.html


HTH,

-- 
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
___ Interest mailing list 
Interest@qt-project.org https://lists.qt-project.org/listinfo/interest 
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.15 pull out of open source?!

[Tuukka Turunen]

Hi,

Apologies for not sending the mail also to the interest mailing list. This is 
nothing new, as this was announced in already February 2020. Otherwise Qt 
continues to be available for open-source users, but the long-term support 
releases of Qt will be available only for the commercial license holders. First 
commercial-only patch release being Qt 5.15.3 planned to be released in 
February 2021.

Qt 5.15.2 continues to be available for all users, so situation is similar as 
with Qt 5.13 and Qt 5.14, for example (no new patch releases). Qt 6.0.0 and 
subsequent patch releases, as well as upcoming Qt 6.1 and Qt 6.2 etc releases 
are also available for open-source users. Eventually we will enter 
long-term-support phase with Qt 6.2 LTS at which point again these are only for 
commercial license holders, but all releases done until that point continue to 
be available for all users.

Yours,

Tuukka



From: Interest 
Date: Thursday, 7. January 2021 at 10.45
To: interest@qt-project.org 
Subject: Re: [Interest] Qt 5.15 pull out of open source?!
Hi,

Il 07/01/21 04:03, Jérôme Godbout ha scritto:
> Hi,
> is this any true?
> https://www.phoronix.com/scan.php?page=news_item=Qt-5.15-LTS-Commercial-Phase

Please see the thread on development@ (no idea why the original message
was not posted on interest@ as well.).

> https://lists.qt-project.org/pipermail/development/2021-January/040798.html


HTH,

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Tuukka Turunen]

Hi,

This clarification is related to independent open-source software. For example 
an independent open-source application containing Qt like 
https://wiki.wireshark.org/Development/QtShark or independent open-source 
library created using Qt such as https://inqlude.org/libraries/vlc-qt.html. If 
the software you want to use meets the terms defined, then it is ok. Note 
specifically that open-source Qt (including also tools) is not allowed to be 
mixed with commercially licensed Qt.

Yours,

Tuukka

From: Ramakanth Kesireddy 
Date: Monday 11. May 2020 at 16.52
To: Tuukka Turunen 
Cc: Bernhard Lindner , Qt Interest 

Subject: Re: [Interest] Qt Creator licensing for companies with Qt Commercial 
developers

Hi Tuukka,


Does it mean that if we use Qt 5.12.8 LTS commercial license, it is permitted 
to use Open source components like third party Qt WebKit  module in conjunction 
with commercial license?

Could you please let me know in this regard?

Thanks and Regards,
Ramakanth
On Mon, 11 May, 2020, 18:01 Tuukka Turunen, 
mailto:tuukka.turu...@qt.io>> wrote:
Hi,

We have now clarified the license agreement to allow use of independent 
open-source items in conjunction with commercially license Qt.

The updated agreement (version 4.2.3) states:

"Permitted Software" shall mean any (i) open source software (excluding Open 
Source Qt) that is a) generally available for public in source code form 
without additional cost under any of the licenses approved by Open Source 
Initiative as listed on  https://opensource.org/licenses; and (b) is in no way, 
directly or indirectly, developed by or for or otherwise related to or in the 
interest of the Licensee or its Affiliates, or (ii) software The Qt Company has 
made available via its Qt Marketplace online distribution channel.

Updated agreement can be found from https://www.qt.io/terms-conditions as well 
as from the Qt online installer.

This clarification should clear the usage of independent open-source tools and 
libraries containing or developed with Qt. Mixing of open-source Qt framework 
and tools with commercially licensed Qt remains forbidden, just like before.

Yours,

Tuukka

On 2.4.2020, 21.17, "Bernhard Lindner" 
mailto:priv...@bernhard-lindner.de>> wrote:

Hi Tuukaa!

> TTT: This part is difficult to generally answer, as it depends how these 
are used and
> what these are used for. Intention of the mixing restriction is to 
prevent cases where
> someone (e.g. a company) uses the open-source version of Qt in cases 
where they should
> use commercial version. Typical example of this is a case where only part 
of the
> developers using Qt together would have a commercial license. We are 
aware of the fact
> that the way how it is written is such that it might extend further than 
the primary
> intention. This is a topic that we do not currently have a proper 
solution for.

Then you should find a solution. This puts customers / developers / users 
in the situation
that they depend on the goodwill of a for-profit corporation. However, 
there is no good
will in a profit-making business.

It must be perfectly clear that development projects are not affected by 
the fundamental
use of third-party Qt-based applications.

I probably will not use Qt for new projects and I cannot recommend it (but 
I have to add
that this decision is also driven by the fact that the technical priorities 
in the Qt
project have not been in line with my priorities for a few years) .

--
Best Regards,
Bernhard Lindner

___
Interest mailing list
Interest@qt-project.org<mailto:Interest@qt-project.org>
https://lists.qt-project.org/listinfo/interest

___
Interest mailing list
Interest@qt-project.org<mailto:Interest@qt-project.org>
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Tuukka Turunen]

Hi,

We have now clarified the license agreement to allow use of independent 
open-source items in conjunction with commercially license Qt. 

The updated agreement (version 4.2.3) states:

"Permitted Software" shall mean any (i) open source software (excluding Open 
Source Qt) that is a) generally available for public in source code form 
without additional cost under any of the licenses approved by Open Source 
Initiative as listed on  https://opensource.org/licenses; and (b) is in no way, 
directly or indirectly, developed by or for or otherwise related to or in the 
interest of the Licensee or its Affiliates, or (ii) software The Qt Company has 
made available via its Qt Marketplace online distribution channel.
 
Updated agreement can be found from https://www.qt.io/terms-conditions as well 
as from the Qt online installer.

This clarification should clear the usage of independent open-source tools and 
libraries containing or developed with Qt. Mixing of open-source Qt framework 
and tools with commercially licensed Qt remains forbidden, just like before.

Yours,

Tuukka

On 2.4.2020, 21.17, "Bernhard Lindner"  wrote:

Hi Tuukaa!

> TTT: This part is difficult to generally answer, as it depends how these 
are used and
> what these are used for. Intention of the mixing restriction is to 
prevent cases where
> someone (e.g. a company) uses the open-source version of Qt in cases 
where they should
> use commercial version. Typical example of this is a case where only part 
of the
> developers using Qt together would have a commercial license. We are 
aware of the fact
> that the way how it is written is such that it might extend further than 
the primary
> intention. This is a topic that we do not currently have a proper 
solution for. 

Then you should find a solution. This puts customers / developers / users 
in the situation
that they depend on the goodwill of a for-profit corporation. However, 
there is no good
will in a profit-making business.

It must be perfectly clear that development projects are not affected by 
the fundamental
use of third-party Qt-based applications.

I probably will not use Qt for new projects and I cannot recommend it (but 
I have to add
that this decision is also driven by the fact that the technical priorities 
in the Qt
project have not been in line with my priorities for a few years) .

-- 
Best Regards,
Bernhard Lindner

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Tuukka Turunen]

Hi Bernhard,

See answers inline below.

Yours,

Tuukka

On 2.4.2020, 12.56, "Bernhard Lindner"  wrote:

Hello Tuukka,

maybe I missed something. Did you answer the following most critical 
question brought up
by Juergen Bocklage-Ryannel and others? From Juergens E-Mail:

> > I guess the conflicting terms are these:
> > 
> > “Prohibited Combination” shall mean any means to (i) use, combine, 
incorporate, link 
> > or integrate Licensed Software with any software created with or 
incorporating Open 
> > Source Qt, (ii) use Licensed Software for creation of any software 
created with or 
> > incorporating Open Source Qt, or (iii) incorporate or integrate 
Applications into a 
> > hardware device or product other than a Device."
> > 
> > Especially this combination: “use … Licensed Software with any software 
created with 
> > … Open Source Qt”
> > 
> > KDE, doxygen, Wireshark (just to name a few) are using Open Source Qt. 
> > 
> > Can someone reflect how does it apply to that software? Can a customer 
use them to 
> > create software under the Qt commercial License terms?

What about this?

TTT: This part is difficult to generally answer, as it depends how these are 
used and what these are used for. Intention of the mixing restriction is to 
prevent cases where someone (e.g. a company) uses the open-source version of Qt 
in cases where they should use commercial version. Typical example of this is a 
case where only part of the developers using Qt together would have a 
commercial license. We are aware of the fact that the way how it is written is 
such that it might extend further than the primary intention. This is a topic 
that we do not currently have a proper solution for. 

> I know licensing in general can be a challenging topic, 

Non-technical terms like "use", "combine", "integrate" and "incorporate" 
are a lawyer's
paradise and make me sit up and take notice. If you want to make things less
'challenging', use techncial terms. Otherwise complaints and distrust will 
never end.

TTT: I am sorry if the terms that I have used are not clear enough. I have 
tried to express also that for actual legally binding text, one should read the 
license agreement. That said, the baseline should be quite clear: restrictions 
on mixing commercial and open-source are only relevant for those who use Qt 
under both of these. If someone is using only the open-source Qt, LGPL and GPL 
are the main licenses to understand. 

> but I can't help thinking if some people are intentionally trying to 
twist things 
> around.  At least there are quite many who have not been talking about 
this in a 
> friendly tone.

No matter if you are wrong or right... if you are writing in behalf of a 
company, such
generalized blames are a cardinal error. If you think a certain person uses 
inadequate
words, criticize directly.

TTT: When discussing in the mailing lists we should follow the code of conduct: 
https://code.qt.io/cgit/meta/quips.git/tree/quip-0012-Code-of-Conduct.rst. I 
consider myself having quite thick skin, but in general when the tone of 
discussions in the mailing lists becomes negative or hostile, it starts to 
prevent people from responding. 

> That said, I hope there are at least some recipients in the mailing list 
who consider
> this discussion valuable. Unless there is any new actual question, this 
is my last email
> to the topic. 

See above.

-- 
Best Regards,
Bernhard Lindner



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Tuukka Turunen]

Hi Matthew,

I have tried to be very clear in explaining that the whole point of this email 
thread is about mixing open-source and commercial, which not a the most common 
use case. I do not know what are the questions that I have tried to avoid 
answering. Yes, there are many users of Qt who use it in many different ways. 
It is rather simple to answer for every specific case when all details are 
known, but rather hard to give a short answer that covers every possible way of 
using Qt. 

But trust me when I say that the vast majority is using either the commercial 
or open-source version. In both these cases licensing is rather 
straightforward: either follow LGPL and GPL (if you use the GPL parts), or the 
commercial license if that has been purchased. 

I know licensing in general can be a challenging topic, but I can't help 
thinking if some people are intentionally trying to twist things around. At 
least there are quite many who have not been talking about this in a friendly 
tone.

That said, I hope there are at least some recipients in the mailing list who 
consider this discussion valuable. Unless there is any new actual question, 
this is my last email to the topic. 

Yours,

Tuukka



On 1.4.2020, 23.04, "Matthew Woehlke"  wrote:

On 31/03/2020 09.46, Andy wrote:
> Even a solo developer needs to hire a lawyer before touching anything
> Qt-related.

Fortunately for the OSS community, you forgot "commercial" in that sentence.

> Once you start trying to codify all the different scenarios in your
> licensing, it becomes toxic and people will avoid it

Yup. Just in this thread, I've seen messages *from Tuukka* that said
"yes", "no", and avoided answering in various ways.

It's no wonder people are confused.

-- 
Matthew


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Tuukka Turunen]

Hi Matthew,

Unless you are in the situation described by the person who originated this 
email thread, I am rather sure you can continue using the GPL version of 
Creator. 

The whole point of this email thread was situations where the same development 
project team (creating the same product) would like to mix commercially and 
open-source licensed Qt frameworks or tools. This is not allowed, but also not 
the most common case. Typically either commercial or open-source version of Qt 
is used, which is the way indented.  

Yours,

Tuukka

On 1.4.2020, 22.16, "Matthew Woehlke"  wrote:

On 27/03/2020 08.55, Tuukka Turunen wrote:
> Correct. All users need to have commercial license. It is not allowed for 
part of the team to use commercial and part use open-source. Even though Qt 
Creator is great, it can feel odd to pay for full Qt license and only use the 
Creator IDE. 
> 
> We have been thinking about selling Qt Creator separately, but so far no 
decisions made on this. 

Wait, *WHAT?!* AFAIK, GPL imposes no restrictions on material created
*using* GPL'd software (with possible exceptions if such use results in
materials that incorporate parts of the software used, e.g. bison/flex).

That said, I wouldn't know what sorts of crazy provisions the Qt
commercial licensing may contain... IMHO though requiring licensees to
not use a particular IDE is pretty asinine.

> On 25.3.2020, 21.09, "Interest on behalf of Vyacheslav Lanovets" 
 wrote:
> 
> Hi,
> 
> Situation.
> 
> A company has a few developers with Qt Commercial subscription who
> write applications in Qt for iOS.
> There are many other developers, who work on other projects and don't
> use Qt libraries.
> They talk to each other and sometimes even work on the same code.
> 
> Is it still possible for the developers who don't use Qt libraries in
> any way, use Qt Creator IDE for editing and debugging?
> To be on the safe side, company plans to prohibit usage of Qt Creator
> IDE for all employees.
> I reckon this is a popular solution.
> If I understand correctly, Qt even sells a special option to ban all
> company IP addresses for open-source installer.
> 
> But is it really so?
> 
> Regards,
> Vyacheslav
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
> 
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
> 


-- 
Matthew


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Tuukka Turunen]

Hi,

As I have said earlier in this thread it can feel odd that the restriction of 
mixing extends also to the Qt tools, even in case framework libraries are not 
used.

I want to again emphasize that this is something that does not affect 
open-source use of Qt – as long as it is not done in conjunction with a 
commercially licensed Qt.

We have been considering of separately licensing some of the tools, but no 
decisions done yet.

Yours,

Tuukka

From: tomek 
Date: Wednesday 1. April 2020 at 13.28
To: Tuukka Turunen 
Cc: Krzysztof Kawa , "interest@qt-project.org" 

Subject: Re: [Interest] Qt Creator licensing for companies with Qt Commercial 
developers

Hi Tuukka,

so if the company's product is say modern car's head unit which is built from 
many, many blocks and to build one of those (UI) Qt with commercial license was 
used then hundreds or thousands of developers in the same company or many 
subcontractor companies developers are forbidden to use Qt Creator based on GPL 
license as their IDE of choice to C/C++ code development within that product 
(but for other modules not relying on Qt at all, physically stored in different 
repos/subrepos)? From the company/project management perspective there will be 
most probably many projects (per module/block) but in the end all will be 
bundled into one package which will land on the blackbox so according to your 
explanation it will be license violation, right?

Thanks,
Tomasz/

śr., 1 kwi 2020 o 07:24 Tuukka Turunen 
mailto:tuukka.turu...@qt.io>> napisał(a):
Hi,

To me your example does not sound problematic assuming that your application is 
like a typical app - a clearly different thing than the store that sells apps 
(the store sells a lot of different apps and your is in no way relevant for 
operating the store etc).

Also, for any particular real case at hand, you can ask if something is allowed 
for you or not.

Yours,

Tuukka


On 31.3.2020, 23.15, "Interest on behalf of Krzysztof Kawa" 
mailto:interest-boun...@qt-project.org> on 
behalf of krzysiek.k...@gmail.com<mailto:krzysiek.k...@gmail.com>> wrote:

> The key point is: The Qt Company, just like Trolltech initially and other 
companies in between, does not want mixing open-source Qt and commercial Qt.
> Reason is simple: if mixing was allowed, many companies would use it to 
pay less for their use of Qt.
> It is unfortunate that also real open-source projects may be affected in 
some cases. Majority of users are not affected in any way.

This got me thinking about quite a simple case that doesn't seem so
simple now: Lets say I make a game using open-source licensed Qt, or
even just open-source licensed Qt Creator. After few years of
development I decide to publish the game. It just so happens that my
publisher has a storefront app using commercial Qt or even just
written in Qt Creator under commercial license. To put my app in their
store there's usually some API, config file or whatever that
technically makes it mixing the two, even if not through Qt based
interface. Does that mean I can't publish my app in that store? If
that's the case then this pretty much makes Qt dead for any sort of
game development because there's no possible way to know which
publishers are gonna use what tech and under what license by the time
you ship. Same thing goes for any app distributed through external
stores I guess and I know at least few that use Qt.
___
Interest mailing list
Interest@qt-project.org<mailto:Interest@qt-project.org>
https://lists.qt-project.org/listinfo/interest


___
Interest mailing list
Interest@qt-project.org<mailto:Interest@qt-project.org>
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Creator licensing for companies with Qt, Commercial developers

[Tuukka Turunen]

Hi,

I think you are now twisting and mixing things incorrectly.

For example, working in a company who has a commercial license of Qt does not 
in any way hinder contributing to Qt. 

Yours,

Tuukka

On 1.4.2020, 9.32, "Interest on behalf of Roland Hughes" 
 
wrote:


On 3/30/20 1:03 PM, Andy wrote:
> That makes no sense. Your license prevents a company from using an
> open-source tool? It says "if you license our stuff you cannot use the
> open-source tool X"?
>
> This whole thread is yet another great example of where the Qt Company is
> totally tone-deaf.
>
> Nobody understands your licensing. You have fewer people using Qt and
> Qt-based things because of this.

I've honestly been expecting KDE to kick Qt to the curb any day now if 
they are reading this.

Medical device companies have been running screaming away from Qt over 
the past year. Many moving to Rust. Some are even moving to Zinc which 
really kind of surprised me.

Some companies in other markets are abandoning embedded Linux for 
embedded DOS so they can use other GUI tools. Before you Guffaw at that, 
AGCO uses a lot of embedded DOS and they make an awful lot of Ag heavy 
equipment. Last I heard they were moving away from Qt as well.

What is impressive is how "company" and "project" get thrown around 
interchangeably. So, if one tiny little project in GE in some remote 
location is using a commercial license, from what was stated, every 
person in every GE location around the world __must__ have a commercial 
Qt license to use QtCreator even if they are just using C++. I guess 
everyone has to move to Emacs, CodeLite, KDevelop, and VSCodium.

https://www.gnu.org/software/emacs/

https://codelite.org/

https://www.kdevelop.org/

https://vscodium.com/

I suppose if they didn't want free they could pay $299 for SlickEdit.

https://www.slickedit.com/

or a $100/yr annual subscription to UltraEdit.

Just be aware that UltraEdit like many other PC originating editors gets 
tabs wrong. When you set tabs to spaces and set their width to 4, 
hitting  when cursor is in first column of the line has to put the 
cursor in column 4, not 5 like far too many PC editors.


https://www.logikalsolutions.com/wordpress/information-technology/most-text-editors-get-tabs-wrong/

Having followed this "discussion" for a bit now I have a relevant question.

Assuming Intel, given all of the locations it has around the globe, owns 
a single commercial Qt license at any one of them, by what has been said 
here, Thiago not only has to have a commercial license to work on Qt, he 
technically can't work on the OpenSource version. He has to commit his 
code to the commercial version where it may or may not ever find its way 
into the OpenSource version, if there ever is to be an OpenSource 
version again.

Cause that's what I've been hearing in this conversation. The new new 
new new licensing "strategy" is once anyone in an organization has 
touched a commercial version they must perpetually pay forever and ever 
for everyone. It almost sounds like a person couldn't even leave a 
company and go work on OpenSource.

I went back tot he archive.

Vyacheslav Lanovets actually asked:

=

A company has a few developers with Qt Commercial subscription who
write applications in Qt for iOS.
There are many other developers, who work on other projects and don't
use Qt libraries.
They talk to each other and sometimes even work on the same code.

Is it still possible for the developers who don't use Qt libraries in
any way, use Qt Creator IDE for editing and debugging?
To be on the safe side, company plans to prohibit usage of Qt Creator
IDE for all employees.
I reckon this is a popular solution.
If I understand correctly, Qt even sells a special option to ban all
company IP addresses for open-source installer.

=

The question clearly states the second group just like the IDE for C++. 
They aren't using Qt at all. That was the question asked.

What this conversation is really starting to sound like is "The 
OpenSource version has ceased to exist."

Please clarify explicitly while I dust off my Zinc books.


https://books.google.com/books?id=cdx_nLaqMn0C=frontcover=Zinc+It!=en=1_redir=0=X=2ahUKEwidibzz8sLoAhVrUN8KHXzSBtkQ6AEwAXoECAIQAg#v=onepage=Zinc%20It!=false


https://books.google.com/books?id=4vu5LwUGT28C=PP1=Zinc+It!=en=1_redir=0=X=2ahUKEwidibzz8sLoAhVrUN8KHXzSBtkQ6AEwAHoECAEQAg#v=onepage=Zinc%20It!=false

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Tuukka Turunen]

Hi,

To me your example does not sound problematic assuming that your application is 
like a typical app - a clearly different thing than the store that sells apps 
(the store sells a lot of different apps and your is in no way relevant for 
operating the store etc).

Also, for any particular real case at hand, you can ask if something is allowed 
for you or not.

Yours,

Tuukka 


On 31.3.2020, 23.15, "Interest on behalf of Krzysztof Kawa" 
 wrote:

> The key point is: The Qt Company, just like Trolltech initially and other 
companies in between, does not want mixing open-source Qt and commercial Qt.
> Reason is simple: if mixing was allowed, many companies would use it to 
pay less for their use of Qt.
> It is unfortunate that also real open-source projects may be affected in 
some cases. Majority of users are not affected in any way.

This got me thinking about quite a simple case that doesn't seem so
simple now: Lets say I make a game using open-source licensed Qt, or
even just open-source licensed Qt Creator. After few years of
development I decide to publish the game. It just so happens that my
publisher has a storefront app using commercial Qt or even just
written in Qt Creator under commercial license. To put my app in their
store there's usually some API, config file or whatever that
technically makes it mixing the two, even if not through Qt based
interface. Does that mean I can't publish my app in that store? If
that's the case then this pretty much makes Qt dead for any sort of
game development because there's no possible way to know which
publishers are gonna use what tech and under what license by the time
you ship. Same thing goes for any app distributed through external
stores I guess and I know at least few that use Qt.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Tuukka Turunen]

Hi,

This disclaimer is because every case can be a bit special. We are trying to 
avoid a case where someone clearly violates the license and then comes with 
explanation, because N.N. said years ago that ABCDC is ok. 

The basic rules are simple:
- If you use Qt under open-source, check what LGPL and GPL (in case you use 
that) require you to do
- If you use Qt under commercial license, check what the commercial license 
agreement says, and ask in case it is not clear
- If you are involved in situation where both open-source and commercial Qt is 
used, do not mix them 

I think our licensing FAQ is quite clear, but I am naturally biased. 

Yours,

Tuukka

On 31.3.2020, 22.57, "Interest on behalf of Bernhard Lindner" 
 
wrote:

Hi Tuukka!

> I have also tried to explain these, but your tone feels rather 
aggressive. I do not
> understand what makes you say: “Even a solo developer needs to hire a 
lawyer before
> touching anything Qt-related.” 

Because this is what users hear in MLs and forums, when they ask about Qt 
licensing
issues. The recurring answer is: "don't know, don't understand, hire a 
lawer". 

And because this is written in your FAQ: "It is always recommended to 
contact a lawyer
familiar with open source licenses for a full review of your project to 
determine whether
you can fulfill all of the obligations of applicable open source licenses".

-- 
Best Regards,
Bernhard Lindner

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Tuukka Turunen]

Hi,

Note that I am not a lawyer, and also note that a generic comment may not be 
applicable in a specific case. If there is a company who wants to clarify their 
usage of Qt, it is best done by directly talking about that case. Remember, 
that the restriction on mixing is only relevant when Qt is commercially 
licensed.

That said, see comments inline below. Hopefully this clarifies, and does not 
confuse more.

Yours,

Tuukka

From: Jean-Michaël Celerier 
Date: Tuesday 31. March 2020 at 22.02
To: Tuukka Turunen 
Cc: Jérôme Godbout , "interest@qt-project.org" 

Subject: Re: [Interest] Qt Creator licensing for companies with Qt Commercial 
developers

Regarding 5.  :

>  Large company F is creating a product with Qt under commercial license. Part 
> of the work is subcontracted to Company G that uses Qt under commercial 
> license. Company G subcontracts some of the work further to low-cost Company 
> H, who uses Qt under open-source license. This is not allowed.

Could you clarify these cases :
1/ Is "Qt under open-source license" limited to the downloads on 
qt.io<http://qt.io>, or any software code related to Qt ?

TTT: In the case of mixing, what matters is the content of the commercial 
license agreement, i.e. what items have been licensed commercially. Typically 
Qt Creator is included, for example.

1/ a. Does this also cover people doing apt-get install qtcreator on Debian or 
brew install qtcreator on macOS

TTT: It does not matter how the open-source version of Qt (or any part of it) 
is acquired.

1/ b. Does this also cover forks of Qt ? say, company H builds a plug-in using 
Copperspice for the software ordered by company F. Does company H need to take 
a Qt license ?

TTT: To my understanding, yes as long as the fork contains parts of what has 
been commercially licensed (or their earlier versions).

1/ c. Does this also cover WebKit / Blink engines, which come from KHTML, which 
was developed at some point in the past with open-source Qt and thus every 
software using a derivative of WebKit on earth ? (electron, chrome, microsoft 
edge, etc)... eg. if I, as company H, ship an electron app in the context of 
the project of company F (say, the electron app is opened when a button is 
pressed in the app developed by company F), do I also need to get a Qt license ?

TTT: The upstream 3rd party copyright parts no, the Qt parts yes.

And, if the answer to c. is "no", how is that different from company H 
"subcontracting" by developing a library with open-source Qt, putting it on the 
Qt market place, and having company G download it and integrate it to its 
project ?

Thanks for your answers so far,
Jean-Michaël

On Tue, Mar 31, 2020 at 7:32 PM Tuukka Turunen 
mailto:tuukka.turu...@qt.io>> wrote:

Hi Jérôme et al,

This thread has long ago left the original question and become a discussion 
about Qt licensing in general and especially about the point of not mixing 
commercial Qt with open-source version of Qt.

The key point is: The Qt Company, just like Trolltech initially and other 
companies in between, does not want mixing open-source Qt and commercial Qt.

Reason is simple: if mixing was allowed, many companies would use it to pay 
less for their use of Qt.

It is unfortunate that also real open-source projects may be affected in some 
cases. Majority of users are not affected in any way.

It is also unfortunate if licensing is felt to be so complex that it is better 
to use some other technology. Commercial licensing of Qt is quite flexible and 
it is also possible to negotiate and ask for advice in case it is unclear what 
is allowed and what not.

Here are some examples that hopefully clarify the point about mixing 
open-source and commercial:

Example 1: Company A has 10 developers creating a product. 5 of them use Qt 
under commercial license and 5 do not use Qt at all. This is ok.

Example 2: Company B has 10 developers creating a product. 5 of them use Qt 
under open-source license and 5 do not use Qt at all. This is ok.

Example 3: Company C has 10 developers creating a product. 5 of them use Qt 
under commercial license and 5 use Qt under open-source license. This is not 
allowed.

Example 4: Large company D is creating a product with Qt under commercial 
license. Part of the work is subcontracted to Company E that uses Qt under 
commercial license. This is ok.

Example 5: Large company F is creating a product with Qt under commercial 
license. Part of the work is subcontracted to Company G that uses Qt under 
commercial license. Company G subcontracts some of the work further to low-cost 
Company H, who uses Qt under open-source license. This is not allowed.

Example 6: Company I is building two independent products with separate 
development teams. One development team uses Qt under commercial license to 
create product 1 and the other development team uses Qt under open-source 
license to create p

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Tuukka Turunen]

Hi Jérôme et al,

This thread has long ago left the original question and become a discussion 
about Qt licensing in general and especially about the point of not mixing 
commercial Qt with open-source version of Qt.

The key point is: The Qt Company, just like Trolltech initially and other 
companies in between, does not want mixing open-source Qt and commercial Qt.

Reason is simple: if mixing was allowed, many companies would use it to pay 
less for their use of Qt.

It is unfortunate that also real open-source projects may be affected in some 
cases. Majority of users are not affected in any way.

It is also unfortunate if licensing is felt to be so complex that it is better 
to use some other technology. Commercial licensing of Qt is quite flexible and 
it is also possible to negotiate and ask for advice in case it is unclear what 
is allowed and what not.

Here are some examples that hopefully clarify the point about mixing 
open-source and commercial:

Example 1: Company A has 10 developers creating a product. 5 of them use Qt 
under commercial license and 5 do not use Qt at all. This is ok.

Example 2: Company B has 10 developers creating a product. 5 of them use Qt 
under open-source license and 5 do not use Qt at all. This is ok.

Example 3: Company C has 10 developers creating a product. 5 of them use Qt 
under commercial license and 5 use Qt under open-source license. This is not 
allowed.

Example 4: Large company D is creating a product with Qt under commercial 
license. Part of the work is subcontracted to Company E that uses Qt under 
commercial license. This is ok.

Example 5: Large company F is creating a product with Qt under commercial 
license. Part of the work is subcontracted to Company G that uses Qt under 
commercial license. Company G subcontracts some of the work further to low-cost 
Company H, who uses Qt under open-source license. This is not allowed.

Example 6: Company I is building two independent products with separate 
development teams. One development team uses Qt under commercial license to 
create product 1 and the other development team uses Qt under open-source 
license to create product 2. This is ok.

Hopefully I was able to clarify the topic with these examples. The Qt Company 
wants to provide Qt under open-source license. There is no mega corporation 
with deep pockets behind. Development of Qt is funded with the revenues gained 
from commercial licensing.

Yours,

Tuukka



From: Jérôme Godbout 
Date: Tuesday 31. March 2020 at 17.56
To: Tuukka Turunen , Andy 
Cc: "interest@qt-project.org" 
Subject: RE: [Interest] Qt Creator licensing for companies with Qt Commercial 
developers

Hi,
the mix is not a corner case, it’s the reality of many people around. We are a 
services compagnie, and this is really a headache to understand where it should 
fall since we do project for client but we are a single cie. The license of Qt 
have is such an ambiguity and our lawyer recommend (not even sure himself where 
we do fall) we avoid using it as much as we can given the context we are in. 
When a client have commercial license, we ask them to use their infrastructure 
and avoid having any commercial license on premise (we cannot take any chance). 
If you think your licensing is clear and make it easy, it ain’t, we do more and 
more Xamarin, just for license reason not because we like it.  I continue Qt 
mostly on hobby, really like Qml and where the binding in C++ is heading. But 
for my work job, Qt is fading out.

The departure between mixing LGPL and Commercial one is such a gray area, 
nobody want to venture anywhere there.

Note: I don’t speak in the name of my cie, but my own opinion here. Just 
stating the fact that the Qt license is the main reason we often ditch Qt for 
some application.


From: Interest  On Behalf Of Tuukka Turunen
Sent: March 31, 2020 10:33 AM
To: Andy 
Cc: interest@qt-project.org
Subject: Re: [Interest] Qt Creator licensing for companies with Qt Commercial 
developers

Hi Andy,

You are asking to explicitly define terms like project, company, product. These 
are rarely possible to define outside of the generic use of the term and each 
individual contract. I assume you understand that it is not possible to take 
any stand of those in an email. We have these listed in the FAQ and contracts 
in as clear way as we have been able to list these.

I have also tried to explain these, but your tone feels rather aggressive. I do 
not understand what makes you say: “Even a solo developer needs to hire a 
lawyer before touching anything Qt-related.” For most of the situation the 
licensing of Qt is really simple and also very permissive. Yes, there are 
certain complex corner cases, like mixing of commercial on open-source versions 
of the Qt framework/tools. But how often do you need to mix these? Most of the 
Qt users are using either the commercial or the open-source version.

Yours,

Tuukka

From: Andy mai

Re: [Interest] Qt Creator licensing for companies with Qt, Commercial developers

[Tuukka Turunen]

Hi,

I apologise, if I have been unclear with words 'company' and project'. If you 
read the license agreement and faq behind the links I have posted multiple 
times, it should be rather clear what is meant. 

Yours,

Tuukka 

On 31.3.2020, 18.50, "Roland Hughes"  wrote:


I sent this the other day but it hasn't made it into the list yet. At 
least I haven't seen it. Forwarding because it is pertinent

 Forwarded Message 
Subject:Re: [Interest] Qt Creator licensing for companies with Qt, 
Commercial developers
Date:   Mon, 30 Mar 2020 14:09:42 -0500
From:   Roland Hughes 
To: interest@qt-project.org, asmalo...@gmail.com




On 3/30/20 1:03 PM, Andy wrote:
> That makes no sense. Your license prevents a company from using an
> open-source tool? It says "if you license our stuff you cannot use the
> open-source tool X"?
>
> This whole thread is yet another great example of where the Qt Company is
> totally tone-deaf.
>
> Nobody understands your licensing. You have fewer people using Qt and
> Qt-based things because of this.

I've honestly been expecting KDE to kick Qt to the curb any day now if 
they are reading this.

Medical device companies have been running screaming away from Qt over 
the past year. Many moving to Rust. Some are even moving to Zinc which 
really kind of surprised me.

Some companies in other markets are abandoning embedded Linux for 
embedded DOS so they can use other GUI tools. Before you Guffaw at that, 
AGCO uses a lot of embedded DOS and they make an awful lot of Ag heavy 
equipment. Last I heard they were moving away from Qt as well.

What is impressive is how "company" and "project" get thrown around 
interchangeably. So, if one tiny little project in GE in some remote 
location is using a commercial license, from what was stated, every 
person in every GE location around the world __must__ have a commercial 
Qt license to use QtCreator even if they are just using C++. I guess 
everyone has to move to Emacs, CodeLite, KDevelop, and VSCodium.

https://www.gnu.org/software/emacs/

https://codelite.org/

https://www.kdevelop.org/

https://vscodium.com/

I suppose if they didn't want free they could pay $299 for SlickEdit.

https://www.slickedit.com/

or a $100/yr annual subscription to UltraEdit.

Just be aware that UltraEdit like many other PC originating editors gets 
tabs wrong. When you set tabs to spaces and set their width to 4, 
hitting  when cursor is in first column of the line has to put the 
cursor in column 4, not 5 like far too many PC editors.


https://www.logikalsolutions.com/wordpress/information-technology/most-text-editors-get-tabs-wrong/

Having followed this "discussion" for a bit now I have a relevant question.

Assuming Intel, given all of the locations it has around the globe, owns 
a single commercial Qt license at any one of them, by what has been said 
here, Thiago not only has to have a commercial license to work on Qt, he 
technically can't work on the OpenSource version. He has to commit his 
code to the commercial version where it may or may not ever find its way 
into the OpenSource version, if there ever is to be an OpenSource 
version again.

Cause that's what I've been hearing in this conversation. The new new 
new new licensing "strategy" is once anyone in an organization has 
touched a commercial version they must perpetually pay forever and ever 
for everyone. It almost sounds like a person couldn't even leave a 
company and go work on OpenSource.

I went back tot he archive.

Vyacheslav Lanovets actually asked:

=

A company has a few developers with Qt Commercial subscription who
write applications in Qt for iOS.
There are many other developers, who work on other projects and don't
use Qt libraries.
They talk to each other and sometimes even work on the same code.

Is it still possible for the developers who don't use Qt libraries in
any way, use Qt Creator IDE for editing and debugging?
To be on the safe side, company plans to prohibit usage of Qt Creator
IDE for all employees.
I reckon this is a popular solution.
If I understand correctly, Qt even sells a special option to ban all
company IP addresses for open-source installer.

=

The question clearly states the second group just like the IDE for C++. 
They aren't using Qt at all. That was the question asked.

What this conversation is really starting to sound like is "The 
OpenSource version has ceased to exist."

Please clarify explicitly while I dust off my Zinc books.

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Tuukka Turunen]

Hi Andy,

You are asking to explicitly define terms like project, company, product. These 
are rarely possible to define outside of the generic use of the term and each 
individual contract. I assume you understand that it is not possible to take 
any stand of those in an email. We have these listed in the FAQ and contracts 
in as clear way as we have been able to list these.

I have also tried to explain these, but your tone feels rather aggressive. I do 
not understand what makes you say: “Even a solo developer needs to hire a 
lawyer before touching anything Qt-related.” For most of the situation the 
licensing of Qt is really simple and also very permissive. Yes, there are 
certain complex corner cases, like mixing of commercial on open-source versions 
of the Qt framework/tools. But how often do you need to mix these? Most of the 
Qt users are using either the commercial or the open-source version.

Yours,

Tuukka

From: Andy 
Date: Tuesday 31. March 2020 at 16.47
To: Tuukka Turunen 
Cc: Giuseppe D'Angelo , "interest@qt-project.org" 

Subject: Re: [Interest] Qt Creator licensing for companies with Qt Commercial 
developers

> "This is at the moment not listed as an allowed case..."

And this again is here the Qt company is digging it's own grave.

What constitutes a "product"? If a company has one team working on an open 
source library and another team using it in a proprietary application - what 
then? What if an internal tool uses some code or a library from proprietary 
application? What if...

Even a solo developer needs to hire a lawyer before touching anything 
Qt-related.

Once you start trying to codify all the different scenarios in your licensing, 
it becomes toxic and people will avoid it

---
Andy Maloney  //  https://asmaloney.com
twitter ~ @asmaloney<https://twitter.com/asmaloney>



On Tue, Mar 31, 2020 at 9:36 AM Tuukka Turunen 
mailto:tuukka.turu...@qt.io>> wrote:

Hi,

The point of the "Prohibited combination" is to prevent a company or a chain of 
companies (like in a typical subcontracting scenario) from making part of the 
product with non-paid Qt and part with paid. Qt being as defined in the 
commercial license agreement, i.e. including tools and framework. This was what 
the person initiating this mail thread asked about. I do agree that it gets 
complex when one starts including items created by an independent third party. 
This is at the moment not listed as an allowed case, even though it is not 
something we specifically aimed to prevent.

Yours,

Tuukka

On 31.3.2020, 15.03, "Interest on behalf of Giuseppe D'Angelo via Interest" 
mailto:interest-boun...@qt-project.org> on 
behalf of interest@qt-project.org<mailto:interest@qt-project.org>> wrote:

On 3/31/20 1:22 PM, Tuukka Turunen wrote:
> For completely independent projects/products this is fine. Note that 
these really should not be same or in practice the same - or in any way 
depending, relating, using etc each other as defined in the license agreement.
>
> See licensing FAQ question 2.7 
athttps://www.qt.io/faq/<http://www.qt.io/faq/>  and License agreement 
athttps://www.qt.io/terms-conditions/<http://www.qt.io/terms-conditions/>

It is still unclear if the usage of Qt _Creator_ for developing some
code would cause such code to fall under the restrictions of commercial
licensing.


Here's a few scenarios:

1) I have a Qt commercial license. In my project using commercial Qt I
want to use a library developed by

1a) some other team in my company;
1b) someone else.

This other library is under a liberal license; does NOT use Qt itself in
any way; but has been developed using Qt Creator (GPL). Can I use it in
my product under the commercial license? Or would it fall under the
"Prohibited Combination":

> “Prohibited Combination” shall mean any means to (i) use, combine, 
incorporate, link or integrate Licensed Software with any software created with 
or incorporating Open Source Qt, (ii) use Licensed Software for creation of any 
software created with or incorporating Open Source Qt

Does "created with" here extend to GPL Creator?



2) Same as 1, but this time with the library using Qt (as in: using
headers, linking against it). Example: a Qt-based library coming from
KDE Frameworks, developed using Creator.


Thanks,
--
Giuseppe D'Angelo | 
giuseppe.dang...@kdab.com<mailto:giuseppe.dang...@kdab.com> | Senior Software 
Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



___
Interest mailing list
Interest@qt-project.org<mailto:Interest@qt-project.org>
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Tuukka Turunen]

Hi,

The point of the "Prohibited combination" is to prevent a company or a chain of 
companies (like in a typical subcontracting scenario) from making part of the 
product with non-paid Qt and part with paid. Qt being as defined in the 
commercial license agreement, i.e. including tools and framework. This was what 
the person initiating this mail thread asked about. I do agree that it gets 
complex when one starts including items created by an independent third party. 
This is at the moment not listed as an allowed case, even though it is not 
something we specifically aimed to prevent.

Yours,

Tuukka

On 31.3.2020, 15.03, "Interest on behalf of Giuseppe D'Angelo via Interest" 
 wrote:

On 3/31/20 1:22 PM, Tuukka Turunen wrote:
> For completely independent projects/products this is fine. Note that 
these really should not be same or in practice the same - or in any way 
depending, relating, using etc each other as defined in the license agreement.
> 
> See licensing FAQ question 2.7 athttps://www.qt.io/faq/  and License 
agreement athttps://www.qt.io/terms-conditions/  

It is still unclear if the usage of Qt _Creator_ for developing some 
code would cause such code to fall under the restrictions of commercial 
licensing.


Here's a few scenarios:

1) I have a Qt commercial license. In my project using commercial Qt I 
want to use a library developed by

1a) some other team in my company;
1b) someone else.

This other library is under a liberal license; does NOT use Qt itself in 
any way; but has been developed using Qt Creator (GPL). Can I use it in 
my product under the commercial license? Or would it fall under the 
"Prohibited Combination":

> “Prohibited Combination” shall mean any means to (i) use, combine, 
incorporate, link or integrate Licensed Software with any software created with 
or incorporating Open Source Qt, (ii) use Licensed Software for creation of any 
software created with or incorporating Open Source Qt

Does "created with" here extend to GPL Creator?



2) Same as 1, but this time with the library using Qt (as in: using 
headers, linking against it). Example: a Qt-based library coming from 
KDE Frameworks, developed using Creator.


Thanks,
-- 
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Tuukka Turunen]

Hi Thiago,

As I wrote a bit earlier, for completely independent projects/products it is 
fine that one is using commercial and one open-source. This is much more likely 
to happen in a big corporation than a small company, but possible scenario in 
both. 

Note that these really should not be same or in practice the same - or in any 
way depending, relating, using etc each other as defined in the license 
agreement.

See licensing FAQ question 2.7 at https://www.qt.io/faq/ and License agreement 
at https://www.qt.io/terms-conditions/

Yours,

Tuukka

On 31.3.2020, 14.33, "Interest on behalf of Thiago Macieira" 
 wrote:

On Monday, 30 March 2020 16:59:11 -03 Elvis Stansvik wrote:
> > Please read the commercial license agreement and the licensing FAQ. The
> > restriction has nothing to do with open-source licensing. It is about a
> > company, who is using a commercially licensed Qt not to use parts of the
> > same licensed Qt product under open-source license. If there was no such
> > restriction, a company could have a team of 10 developers, but only 1 or
> > 2 commercial license for Qt.
> Up until now, you've said "same project". Now you are switching to
> "company". Please clarify.

And don't think of a 10-developer company. Think of a company with 2 
developers, with offices all over the world. If *any* of them buy a 
commercial 
licence, does it mean everyone else must stop using the open source Qt? And 
Qt 
Creator?

How about contributing to Qt open source? Do they have to stop too?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Tuukka Turunen]

Hi,

For completely independent projects/products this is fine. Note that these 
really should not be same or in practice the same - or in any way depending, 
relating, using etc each other as defined in the license agreement. 

See licensing FAQ question 2.7 at https://www.qt.io/faq/ and License agreement 
at https://www.qt.io/terms-conditions/ 

Yours,

Tuukka

On 30.3.2020, 23.25, "Michael Jackson"  wrote:

Dear Tuukka,
   Let us take a concrete example of a hypothetical company. The company 
has 10 software engineers and 2 projects.

Engineers 1,2,3,4,5 work on proprietary project A that uses Qt commercial 
license. Each engineer (1,2,3,4,5) has a commercial Qt license assigned to that 
engineer. They use QtCreator from the commercial package to develop such a 
software. The proprietary software being developed is for a Desktop application 
and uses Qt5 as part of its development.

Now, Engineers 6,7,8,9,10 all work on an open source project B that does 
not use Qt libraries at all. Those engineers (6,7,8,9,10) all really like 
QtCreator and want to use it to develop that open source library. I, as the 
company owner, instruct those engineers to download the open source version of 
QtCreator and use that open source version of QtCreator to develop their open 
source software.

There is *no* cross over between the 2 engineering groups.

Is this situation allowed by the Qt Commercial license? If it is *not* 
allowed consider me a lost supporter of Qt anything.

--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net 


On 3/30/20, 1:54 PM, "Tuukka Turunen"  wrote:

Hi Michael,

Please read the commercial license agreement and the licensing FAQ. The 
restriction has nothing to do with open-source licensing. It is about a 
company, who is using a commercially licensed Qt not to use parts of the same 
licensed Qt product under open-source license. If there was no such 
restriction, a company could have a team of 10 developers, but only 1 or 2 
commercial license for Qt.

I do understand that it can feel off to have such a restriction for 
using "Qt Creator" when others are using "Qt libraries". The important point is 
that both these are included in the Qt for Application Development product. So 
both need to be used with same type of license: open-source or commercial. 
 
Yours,
 
Tuukka

On 27.3.2020, 20.54, "Interest on behalf of Michael Jackson" 
 
wrote:

OK, Here goes the explanations of how to interoperate with Qt 
Software packages. IANAL. We will start from the easy and work our way towards 
difficult.

QtCreator: QtCreator is free. You, as a developer of software, can 
use QtCreator as your IDE to develop your own software. The GPL license of 
QtCreator will NOT infect your software. Use QtCreator to create open or closed 
software. Free or commercial. Your choice.

QtCreator as Part of a Commercial Qt License: The only thing this 
gets you is the ability to get some "commercial" support versus just posting on 
the qt-creator mailing list.

Modifying QtCreator: If you are actually modifying QtCreator 
yourself to create a distribution outside of your organization then ANY codes 
you write or modify are subject to the QtCreator license. This has 
ramifications if you happen to have a Qt commercial license.

Using Qt5 in your software project: If you use Qt in your project 
ANYBODY contributing to that same project MUST have the same kind of Qt 
license. Period. Full Stop.

For the original question;
"Is it still possible for the developers who don't use Qt libraries 
in
any way, use Qt Creator IDE for editing and debugging?"

The answer is YES, but the devil is in the details. They *should* 
be able to just download the free version of QtCreator from 
http://download.qt.io and use that version. They can't use the "commercial" 
version of QtCreator unless they have a commercial license for Qt. But if their 
projects are *not* using Qt, then why do they have a commercial license for Qt?


Again, IANAL, but I believe this to be a reasonable summary of the 
licensing of QtCreator and Qt.
--
Mike Jackson 



On 3/27/20, 12:21 PM, "Interest on behalf of alexander golks" 
 wrote:

Am Fri, 27 Mar 2020 17:11:16 +0100
schrieb Jean-Michaël Celerier :

> It is also the license of the binari

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Tuukka Turunen]

Hi Andy,

I know that the dual licensing can be confusing. To defend it a bit: it gets 
confusing mainly when the question is about mixing the license types. It is 
simple and straightforward when a company uses commercial license and asks also 
possible contractors (working in the same project) to use commercial. Similarly 
it is simple when all use the open-source version.

If you want to understand the topic better, please read the commercial license 
agreement and the licensing FAQ. The restriction has nothing to do with 
open-source licensing. It is about a company, who is using a commercially 
licensed Qt not to use parts of the same licensed Qt product under open-source 
license. If there was no such restriction, a company could have a team of 10 
developers, but only 1 or 2 commercial license for Qt.

I do understand that it can feel off to have such a restriction for using "Qt 
Creator" when others are using "Qt libraries". The important point is that both 
these are included in the Qt for Application Development product. So both need 
to be used with same type of license: open-source or commercial.

Yours,
Tuukka


From: Andy 
Date: Monday 30. March 2020 at 20.50
To: Tuukka Turunen 
Cc: Giuseppe D'Angelo , "interest@qt-project.org" 

Subject: Re: [Interest] Qt Creator licensing for companies with Qt Commercial 
developers

That makes no sense. Your license prevents a company from using an open-source 
tool? It says "if you license our stuff you cannot use the open-source tool X"?

This whole thread is yet another great example of where the Qt Company is 
totally tone-deaf.

Nobody understands your licensing. You have fewer people using Qt and Qt-based 
things because of this.

---
Andy Maloney  //  https://asmaloney.com
twitter ~ @asmaloney<https://twitter.com/asmaloney>



On Mon, Mar 30, 2020 at 1:43 PM Tuukka Turunen 
mailto:tuukka.turu...@qt.io>> wrote:

Hi,

That is not the question that was originally asked.

The question was about some developers using commercially licensed “Qt for 
Application Development” product and other developers using Qt Creator under 
open-source license. This is not allowed, because the license agreement of Qt 
for Application Development does not allow use of open-source versions of its 
contents in the same project (and Qt Creator is part of Qt for Application 
Development).

Yours,

Tuukka

From: Andy mailto:asmalo...@gmail.com>>
Date: Friday 27. March 2020 at 17.29
To: Tuukka Turunen mailto:tuukka.turu...@qt.io>>
Cc: Giuseppe D'Angelo 
mailto:giuseppe.dang...@kdab.com>>, 
"interest@qt-project.org<mailto:interest@qt-project.org>" 
mailto:interest@qt-project.org>>
Subject: Re: [Interest] Qt Creator licensing for companies with Qt Commercial 
developers

"This seems to become a longer thread than I envisioned, as apparently my 
original response was not clear enough."

As I pointed out - it's because you're not answering the question that was 
asked, and therefore confusing the issue.

"Is it still possible for the developers who don't use Qt libraries in any way, 
use Qt Creator IDE for editing and debugging?"

The answer is yes.

---
Andy Maloney  //  https://asmaloney.com
twitter ~ @asmaloney<https://twitter.com/asmaloney>



On Fri, Mar 27, 2020 at 11:23 AM Tuukka Turunen 
mailto:tuukka.turu...@qt.io>> wrote:

Hi,

This seems to become a longer thread than I envisioned, as apparently my 
original response was not clear enough.

In general, if there are any questions or concerns related to licensing, check 
the FAQ: https://www.qt.io/faq/

If you are looking for advise on licensing, I recommend either to read the FAQ 
or consult a lawyer. While everyone here tries their best to give good advice, 
it is possible that some incorrect information or interpretation is presented 
(because licensing can be a difficult topic).

Anyways, I'll now explain again the answer to the original question asked. The 
question was, as I understood it, "Is it allowed that people working in a 
project use commercially licensed Qt and some other persons in the same project 
who do not develop Qt use open-source licensed Qt tools?"

Answer to this is: No, it is not allowed to mix commercial "Licensed Software" 
and the open-source versions provided by The Qt Company in the same project.

This is a restriction coming from the commercial license agreement: 
https://www.qt.io/terms-conditions/

The basic rule of thumb is: Don't mix. Use either only commercial or only 
open-source versions of items provided by The Qt Company.

Yours,

Tuukka

On 27.3.2020, 16.26, "Interest on behalf of Giuseppe D'Angelo via Interest" 
mailto:interest-boun...@qt-project.org> on 
behalf of interest@qt-project.org<mailto:interest@qt-project.org>> wrote:

On 27/03/2020 15:03, Tomas Konir wrote:
  

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Tuukka Turunen]

Hi Michael,

Please read the commercial license agreement and the licensing FAQ. The 
restriction has nothing to do with open-source licensing. It is about a 
company, who is using a commercially licensed Qt not to use parts of the same 
licensed Qt product under open-source license. If there was no such 
restriction, a company could have a team of 10 developers, but only 1 or 2 
commercial license for Qt.

I do understand that it can feel off to have such a restriction for using "Qt 
Creator" when others are using "Qt libraries". The important point is that both 
these are included in the Qt for Application Development product. So both need 
to be used with same type of license: open-source or commercial. 
 
Yours,
 
Tuukka

On 27.3.2020, 20.54, "Interest on behalf of Michael Jackson" 
 
wrote:

OK, Here goes the explanations of how to interoperate with Qt Software 
packages. IANAL. We will start from the easy and work our way towards difficult.

QtCreator: QtCreator is free. You, as a developer of software, can use 
QtCreator as your IDE to develop your own software. The GPL license of 
QtCreator will NOT infect your software. Use QtCreator to create open or closed 
software. Free or commercial. Your choice.

QtCreator as Part of a Commercial Qt License: The only thing this gets you 
is the ability to get some "commercial" support versus just posting on the 
qt-creator mailing list.

Modifying QtCreator: If you are actually modifying QtCreator yourself to 
create a distribution outside of your organization then ANY codes you write or 
modify are subject to the QtCreator license. This has ramifications if you 
happen to have a Qt commercial license.

Using Qt5 in your software project: If you use Qt in your project ANYBODY 
contributing to that same project MUST have the same kind of Qt license. 
Period. Full Stop.

For the original question;
"Is it still possible for the developers who don't use Qt libraries in
any way, use Qt Creator IDE for editing and debugging?"

The answer is YES, but the devil is in the details. They *should* be able 
to just download the free version of QtCreator from http://download.qt.io and 
use that version. They can't use the "commercial" version of QtCreator unless 
they have a commercial license for Qt. But if their projects are *not* using 
Qt, then why do they have a commercial license for Qt?


Again, IANAL, but I believe this to be a reasonable summary of the 
licensing of QtCreator and Qt.
--
Mike Jackson 



On 3/27/20, 12:21 PM, "Interest on behalf of alexander golks" 
 wrote:

Am Fri, 27 Mar 2020 17:11:16 +0100
schrieb Jean-Michaël Celerier :

> It is also the license of the binaries that you can download there :
> https://download.qt.io/official_releases/qtcreator/4.11/4.11.1/
> 
> And it states quite succintly :
> "This License explicitly affirms your unlimited permission to run the
> unmodified Program."
> 
> > but if you just use qtcreator, just use it. its free.  
> 
> well, that is not what
> "
> Anyways, I'll now explain again the answer to the original question 
asked.
> The question was, as I understood it, "Is it allowed that people 
working in
> a project use commercially licensed Qt and some other persons in the 
same
> project who do not develop Qt use open-source licensed Qt tools?"
> 
> Answer to this is: No, it is not allowed to mix commercial "Licensed
> Software" and the open-source versions provided by The Qt Company in 
the
> same project."
> 
> seems to mean, which is why I'm wondering.

the problem is, as already stated, that some did not answer your 
question properly.
i understood your question. and as i said, your mixing up things. as we 
say: you mix apples and pears.

you're talking about using an executable X, based on open source 
software.
you're talking about using an library Y, for which you have a license, 
based on open source software, too.
you're talking about using exec X to use Y somehow.
you're talking about using exec X with other libraries.

now what has tool X todo with library Y? nothing.
well, it happen to be that tool X is written using library Y, but thats 
of no concern here.

the licese for Y only clearifies how you may use/include the library Y 
into your projects, 
and not how to use tool X to build apps using library Y.



other words:
would you ask if you have to use the commercial vs license because you 
bought a qt license?

-- 
/*
 *printk(KERN_DEBUG "%s: Done reprogramming Xilinx, %d bits, good 
luck!\n",...);
 *   

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Tuukka Turunen]

Hi,

Please read the commercial license agreement and the licensing FAQ. The 
restriction has nothing to do with open-source licensing. It is about a 
company, who is using a commercially licensed Qt not to use parts of the same 
licensed Qt product under open-source license. If there was no such 
restriction, a company could have a team of 10 developers, but only 1 or 2 
commercial license for Qt.

Yours,

Tuukka

From: Jean-Michaël Celerier 
Date: Friday 27. March 2020 at 17.46
To: Tuukka Turunen 
Cc: Giuseppe D'Angelo , "interest@qt-project.org" 

Subject: Re: [Interest] Qt Creator licensing for companies with Qt Commercial 
developers

> Answer to this is: No, it is not allowed to mix commercial "Licensed 
> Software" and the open-source versions provided by The Qt Company in the same 
> project.

What about open-source versions provided by another distributor, e.g. someone 
doing apt install qtcreator ?

Also how is that compatible with this part of the Qt Creator license  ?
https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/LICENSE.GPL3-EXCEPT#n493


Best,
Jean-Michaël



On Fri, Mar 27, 2020 at 4:24 PM Tuukka Turunen 
mailto:tuukka.turu...@qt.io>> wrote:

Hi,

This seems to become a longer thread than I envisioned, as apparently my 
original response was not clear enough.

In general, if there are any questions or concerns related to licensing, check 
the FAQ: https://www.qt.io/faq/

If you are looking for advise on licensing, I recommend either to read the FAQ 
or consult a lawyer. While everyone here tries their best to give good advice, 
it is possible that some incorrect information or interpretation is presented 
(because licensing can be a difficult topic).

Anyways, I'll now explain again the answer to the original question asked. The 
question was, as I understood it, "Is it allowed that people working in a 
project use commercially licensed Qt and some other persons in the same project 
who do not develop Qt use open-source licensed Qt tools?"

Answer to this is: No, it is not allowed to mix commercial "Licensed Software" 
and the open-source versions provided by The Qt Company in the same project.

This is a restriction coming from the commercial license agreement: 
https://www.qt.io/terms-conditions/

The basic rule of thumb is: Don't mix. Use either only commercial or only 
open-source versions of items provided by The Qt Company.

Yours,

Tuukka

On 27.3.2020, 16.26, "Interest on behalf of Giuseppe D'Angelo via Interest" 
mailto:interest-boun...@qt-project.org> on 
behalf of interest@qt-project.org<mailto:interest@qt-project.org>> wrote:

On 27/03/2020 15:03, Tomas Konir wrote:
>
> Sorry for possible misunderstanding, but i think, that original question
> was little different.
> Question was:
>
> There is company, where are two developer groups:
> Group1: Use QtCreator and works with QT libraries (and works with other
> code which not use QT libraries). All users have Commercial License.
> Group2: Would like to use QtCreator and not use QT libraries (they
> working only with QT unrelated code). The want use QtCreator only as IDE
>
> Can both groups use QtCreator?
> I thought, that using QtCreator as IDE is not conditioned with having QT
> Commercial license.

The only difference that comes to mind is that the first group can use
Qt Creator under its commercial license, which may come with some extra
features (not exactly sure of which ones, at this particular point in time).

The second group can instead just use Qt Creator under its open source
license. The open source license of Qt Creator itself does NOT extend in
any way to the software you develop (cf. the GPL FAQ).

HTH,
--
Giuseppe D'Angelo | 
giuseppe.dang...@kdab.com<mailto:giuseppe.dang...@kdab.com> | Senior Software 
Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



___
Interest mailing list
Interest@qt-project.org<mailto:Interest@qt-project.org>
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Tuukka Turunen]

Hi,

This seems to become a longer thread than I envisioned, as apparently my 
original response was not clear enough.

In general, if there are any questions or concerns related to licensing, check 
the FAQ: https://www.qt.io/faq/ 

If you are looking for advise on licensing, I recommend either to read the FAQ 
or consult a lawyer. While everyone here tries their best to give good advice, 
it is possible that some incorrect information or interpretation is presented 
(because licensing can be a difficult topic). 

Anyways, I'll now explain again the answer to the original question asked. The 
question was, as I understood it, "Is it allowed that people working in a 
project use commercially licensed Qt and some other persons in the same project 
who do not develop Qt use open-source licensed Qt tools?" 

Answer to this is: No, it is not allowed to mix commercial "Licensed Software" 
and the open-source versions provided by The Qt Company in the same project.

This is a restriction coming from the commercial license agreement: 
https://www.qt.io/terms-conditions/ 

The basic rule of thumb is: Don't mix. Use either only commercial or only 
open-source versions of items provided by The Qt Company.

Yours,

Tuukka

On 27.3.2020, 16.26, "Interest on behalf of Giuseppe D'Angelo via Interest" 
 wrote:

On 27/03/2020 15:03, Tomas Konir wrote:
> 
> Sorry for possible misunderstanding, but i think, that original question 
> was little different.
> Question was:
> 
> There is company, where are two developer groups:
> Group1: Use QtCreator and works with QT libraries (and works with other 
> code which not use QT libraries). All users have Commercial License.
> Group2: Would like to use QtCreator and not use QT libraries (they 
> working only with QT unrelated code). The want use QtCreator only as IDE
> 
> Can both groups use QtCreator?
> I thought, that using QtCreator as IDE is not conditioned with having QT 
> Commercial license.

The only difference that comes to mind is that the first group can use 
Qt Creator under its commercial license, which may come with some extra 
features (not exactly sure of which ones, at this particular point in time).

The second group can instead just use Qt Creator under its open source 
license. The open source license of Qt Creator itself does NOT extend in 
any way to the software you develop (cf. the GPL FAQ).

HTH,
-- 
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Tuukka Turunen]

Hi,

The question was related to mixing open-source and commercial version of Qt in 
the same project. See Qt licensing FAQ: https://www.qt.io/faq/

It states in question 2.7.: ”Q: Can some developers in our team working on the 
same project use open-source version of Qt and some developers use Commercial 
version of Qt?
A. No. Each developer must have their own assigned Qt license. Mixing Qt 
commercial licenses with Qt open-source licenses in one project/product is not 
permitted.”

Qt Creator under GPL license can be used for developing closed software. The 
restriction about mixing commercial and open-source Qt affects the case 
originally asked.

Yours,

Tuukka


From: Jakub Narolewski 
Date: Friday 27. March 2020 at 15.27
To: Jérôme Godbout , Tuukka Turunen , 
Vyacheslav Lanovets , "interest@qt-project.org" 

Subject: RE: Re: [Interest] Qt Creator licensing for companies with Qt 
Commercial developers

Maybe I misunderstood something so just correct me.
If I use – commercially – QtCreator as my daily IDE without using Qt library or 
attached modules, I still need to pay for full Qt license?

Cheers,
Jakub Narolewski

From: Jérôme Godbout<mailto:godbo...@amotus.ca>
Sent: 27 March 2020 14:22
To: Tuukka Turunen<mailto:tuukka.turu...@qt.io>; Vyacheslav 
Lanovets<mailto:s...@lanovets.ru>; 
interest@qt-project.org<mailto:interest@qt-project.org>
Subject: Re: [Interest] Qt Creator licensing for companies with Qt Commercial 
developers

Hi,

is it just me or this is heading into the wrong way, or at least into the 
opposite direction of the market. Most IDE are now free, even the embedded 
world start giving IDE away:
xCode is free
vs code is free
Atollic is free
STM32 TrueStudio is free
..

People are leaving pricy IDE behind, Keil anyone? less and less used. Starting 
to pay for an IDE like QtCreator, seem like you will only get less users toward 
Qt or people might be temped more and more to use VisualStudio as an IDE of 
choice.

This is my personnal point of view on the subject,
My 2 cents,

-Original Message-
From: Interest  On Behalf Of Tuukka Turunen
Sent: March 27, 2020 8:56 AM
To: Vyacheslav Lanovets ; interest@qt-project.org
Subject: Re: [Interest] Qt Creator licensing for companies with Qt Commercial 
developers


Hi,

Correct. All users need to have commercial license. It is not allowed for part 
of the team to use commercial and part use open-source. Even though Qt Creator 
is great, it can feel odd to pay for full Qt license and only use the Creator 
IDE.

We have been thinking about selling Qt Creator separately, but so far no 
decisions made on this.

Yours,

Tuukka

On 25.3.2020, 21.09, "Interest on behalf of Vyacheslav Lanovets" 
 wrote:

Hi,

Situation.

A company has a few developers with Qt Commercial subscription who
write applications in Qt for iOS.
There are many other developers, who work on other projects and don't
use Qt libraries.
They talk to each other and sometimes even work on the same code.

Is it still possible for the developers who don't use Qt libraries in
any way, use Qt Creator IDE for editing and debugging?
To be on the safe side, company plans to prohibit usage of Qt Creator
IDE for all employees.
I reckon this is a popular solution.
If I understand correctly, Qt even sells a special option to ban all
company IP addresses for open-source installer.

But is it really so?

Regards,
Vyacheslav
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Tuukka Turunen]

Hi,

Correct. All users need to have commercial license. It is not allowed for part 
of the team to use commercial and part use open-source. Even though Qt Creator 
is great, it can feel odd to pay for full Qt license and only use the Creator 
IDE. 

We have been thinking about selling Qt Creator separately, but so far no 
decisions made on this. 

Yours,

Tuukka

On 25.3.2020, 21.09, "Interest on behalf of Vyacheslav Lanovets" 
 wrote:

Hi,

Situation.

A company has a few developers with Qt Commercial subscription who
write applications in Qt for iOS.
There are many other developers, who work on other projects and don't
use Qt libraries.
They talk to each other and sometimes even work on the same code.

Is it still possible for the developers who don't use Qt libraries in
any way, use Qt Creator IDE for editing and debugging?
To be on the safe side, company plans to prohibit usage of Qt Creator
IDE for all employees.
I reckon this is a popular solution.
If I understand correctly, Qt even sells a special option to ban all
company IP addresses for open-source installer.

But is it really so?

Regards,
Vyacheslav
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Missing Qt versions in archives

[Tuukka Turunen]

Hi,

This is due to mirror’s disk space. If the size of the mirrored folders grows 
too big, we lose some mirrors completely.

You can find also the old releases from: http://download.qt.io/new_archive/qt/

Note that this is not mirrored, so it can be slow to download.

Yours,

Tuukka

From: Interest  on behalf of Benjamin TERRIER 

Date: Monday 16. March 2020 at 11.47
To: qt qt 
Subject: [Interest] Missing Qt versions in archives

Hi all,

Some Qt versions were recently removed from http://download.qt.io/archive/qt

Specifically versions 5.2 to 5.8 and versions 5.10 and 5.11 are not available.

A few weeks ago I was still able to download Qt 5.5 from 
http://download.qt.io/archive/qt/5.5/5.5.1/qt-opensource-linux-x64-5.5.1.run 
now I have a nice 404 error as the 5.5 folder does not exist anymore.

So now there is no way to download old versions like 5.5 as they are not in the 
online installer.
And this includes both the offline installer and the source tar packages.

Anyone knows what's going on?

I'd guess that it is link to the Qt Company new "no offline installer for GPL 
users".
But removing previously available offline installers for versions that are not 
in the online installer? And even removing  sources? What's the point?

Regards

Benjamin

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Change in open-source licensing of Qt Wayland Compositor, Qt Application Manager and Qt PDF

[Tuukka Turunen]

Hi,

Open-source licensing of Qt Wayland Compositor, Qt Application Manager and Qt 
PDF is to be changed from LGPLv3/Commercial to GPLv3/Commercial. Change becomes 
in effect with Qt 5.14 release. Going forward, these modules are no longer 
available under LGPLv3 license option. The key rationale for this is to 
increase the amount of GPLv3/Commercial licensed Qt add-ons. Blog post 
announcement of this is at: 
https://www.qt.io/blog/change-in-open-source-licensing-of-qt-wayland-compositor-qt-application-manager-and-qt-pdf

Qt Wayland Compositor and Application Manager are mainly used in complex multi 
process embedded systems. The Wayland Compositor is a special purpose module 
and is not used on desktop and mobile platforms. The module does require 
significant ongoing investments and licensing it under GPLv3 will help cover 
those expenses. The Application Manager is using the Wayland Compositor. It is 
currently not part of Qt and only available through the Automotive Suite, but 
being developed on qt-project.org<http://qt-project.org/>. Qt PDF is a new 
module, which has not been released earlier despite the pre-release code being 
available. Changing the license to GPLv3 will allow The Qt Company to support 
the module going forward.

Since January 2016 many of the completely new Qt add-on modules developed by 
The Qt Company have been licensed under GPLv3 license for open-source users in 
addition to the commercial licensing option. We use GPLv3 license for the 
selected Qt Add-Ons in order for those making closed-source applications or 
devices to pick the commercial option when using these add-on modules, while 
still providing the functionality under an open-source license for open-source 
applications.

In addition to developers from The Qt Company, the main contributors of these 
modules are from Luxoft and KDAB. We have discussed the license change 
beforehand with both of them and they accept making this license change.

The change in licensing of Qt Wayland Compositor, Qt Application Manager and Qt 
PDF is implemented in the coming days to be in effect by Qt 5.14 release 
timeframe and later releases.

Yours,

    Tuukka Turunen
The Qt Company




___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Licensing

[Tuukka Turunen]

Hi,

If there is misleading or incorrect information in the website, please let us 
know: https://www.qt.io/contact-us/other 

Open-source licensing is a complex topic, so it is always easiest to look into 
it case by case as it depends a lot upon what and how is developed. The qt.io 
website tries to give as accurate guidance as is meaningful for the generic 
case and without going too deep into the details. 

Yours,

Tuukka

On 09/10/2019, 22.27, "Interest on behalf of alexander golks" 
 wrote:

Am Wed, 9 Oct 2019 20:43:58 +0200
schrieb Uwe Rathmann :

> Of course this information is useless for someone who wants to change 
> the license - the decision for the LGPL had been made long before. It is 
> about sending the message that you should not do LGPL, if you don't want 
> to be banned later.

well, i'm 100% behind you. but this is not useless. 
at least you know, that the qc may reject your request.
on the other side, they may not. depends.

for me, presonally, there are few reasons to go commercial.

the information on their qt.io website was ever misguiding, several years 
already, and seems to continue.
but i think due to the nature of the "company" (shame on you!).

so, in turn, i hope some guys on this list will get some some ideas about 
(l)gpl theory.

+2

-- 
/*
 *  Q:  Why haven't you graduated yet?
 *  A:  Well, Dad, I could have finished years ago, but I wanted
 *my dissertation to rhyme.
 */


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Licensing

[Tuukka Turunen]

Hi Uwe,

This is not about making closed source applications with LGPL licensed Qt, or 
whatever kind of business is done with such.

The point is that Qt as a dual licensed technology has some rules related to 
the commercial license option. One of these rules is that the whole team should 
go commercial. That rule has nothing to do with any open-source license, but 
only the commercial license of Qt. Similar rule is related to not being ok to 
develop the solution with free version and then ship under commercial one. We 
do allow migration from open-source to commercial - of course. The case by case 
acceptance rule is there to avoid misuse.

I know that dual licensing can be complicated. For that reason it is best to 
talk with our local sales team when moving from open-source to commercial and 
look into the issue together with them. We aim to give a clear and correct view 
of this in our web pages, but as the topic has many angles, it is typically 
easiest to look into this on case by case basis when migrating to commercial. 

What comes to using FUD as sales strategy, that is not what we aim for at all. 
On the contrary we are actively trying to explain the dual licensing in the 
FAQ, videos, web pages, webinars, mailing lists etc exactly to relieve the U 
and D - and having enough and correct information helps with the Fear part as 
well. 

Yours,

Tuukka



On 09/10/2019, 12.07, "Interest on behalf of Uwe Rathmann" 
 wrote:

On 10/8/19 7:13 PM, Ilya Diallo wrote:

> In the latter case, the rational is (I guess) to prevent a company, 
> say, to work with 20 developers for 3 years on an OSS Qt license, 
> then switch to commercial when it's time to ship the product and the 
> team is reduced to a core maintenance crew. That late switch is 
> unfair to companies that are playing by the rule, ...

Please allow me to quote Wikipedia:

"The license allows developers and companies to use and integrate a
software component released under the LGPL into their own (even
proprietary) software without being required by the terms of a strong
copyleft license to release the source code of their own components."

The motivation for not using the LGPL - at least on the desktop - is
usually, that you want to avoid its obligations, when linking
statically. That's all.

There is no inner logic behind bundling the commercial license with
support contracts and the number of developers using it - beside, that
the Qt company makes this connection.

I don't have much opinion on this topic - not my business - but I don't
agree that "fair/unfair" is a valid category in this context.

But I have a strong opinion about using FUD as sales strategy:

- intimidation paragraphs
- blacklisting projects that follow the rules of the LGPL properly
- giving wrong information ( check the video ) about the LGPL

Uwe

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Licensing

[Tuukka Turunen]

“In the latter case, the rational is (I guess) to prevent a company, say, to 
work with 20 developers for 3 years on an OSS Qt license, then switch to 
commercial when it's time to ship the product and the team is reduced to a core 
maintenance crew. That late switch is unfair to companies that are playing by 
the rule, but it's probably hard to police for the Qt company.”

Yes, exactly.

Same reasoning behind the “no mixing of items developed with commercial and 
open-source licenses of Qt”. If that was allowed a company with 10 developers 
would have only 1 license to access support for all of the team’s problems and 
to get accelerated bug fixes – and of course to ship with.

Yours,

Tuukka

From: Interest  on behalf of Ilya Diallo 

Date: Tuesday, 8 October 2019 at 20.16
To: Melinda Seifert 
Cc: Uwe Rathmann , "interest@qt-project.org" 

Subject: Re: [Interest] Licensing

It would maybe be useful to clarify what his mistake is ?
From what I understand Uwe mixes "contributing to open source project" and 
"using open source Qt for a closed project". In the former case, of course he's 
welcome to buy commercial licences for whatever project he'll be working on. In 
the latter case, the rational is (I guess) to prevent a company, say, to work 
with 20 developers for 3 years on an OSS Qt license, then switch to commercial 
when it's time to ship the product and the team is reduced to a core 
maintenance crew. That late switch is unfair to companies that are playing by 
the rule, but it's probably hard to police for the Qt company.

Best regards

Ilya

Le mar. 8 oct. 2019 à 15:30, Melinda Seifert 
mailto:melinda.seif...@qt.io>> a écrit :
Uwe,
You are completely mistaken!  I'm more than happy to discuss this with you. My 
phone number is listed below. In the meantime please view https://www.qt.io/faq/

2.13. If I have started development of a project using the open source version 
(LGPL), can I later purchase a commercial version of Qt and move my code under 
that license?
"This is not permitted without written consent from The Qt Company. If you have 
already started the development with an open-source version of Qt, please 
contact The Qt Company to resolve the issue. If you are unsure of which license 
or version to use when you start development, we recommend you contact The Qt 
Company to advise you on the best choice based on your development needs."

Best Regards,

Melinda Seifert
Regional Director of the Americas
The Qt Company
O: 617-377-7918 | M: 617-413-4479
Qt Customer Case Studies - https://resources.qt.io/customer-stories-all


On 10/8/19, 3:54 AM, "Interest on behalf of Uwe Rathmann" 
mailto:interest-boun...@qt-project.org> on 
behalf of uwe.rathm...@tigertal.de> wrote:

On 10/8/19 1:21 AM, Melinda Seifert wrote:

> You can use commercial if you previously used Open Source but it’s on
> a case by case basis and you need to get approval from the Qt
> company.

Like you need to get approval from the Qt company when not having been
Open Source before - it is the basic right of any seller not to sell.

But your statement implies, that the Qt Company is blacklisting users
because of contributing to Open Source projects. Am I already
blacklisted because of offering code under an Open Source license ?

How does this all fit to the Qt project, that is in parts based on
contributions from Open Source developers. Am I invited to contribute to
the code base, while not being allowed to buy my own contribution
afterwards ?

Uwe

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Licensing questions for iOS and Android

[Tuukka Turunen]

Hi Vyacheslav,

Where are you located? It is probably easiest that our regional sales team or 
local reseller is in contact to discuss.

Commercial Qt licensing is developer based, so each person working on the same 
project (e.g. same end user application) needs to have a commercial license. 
One person can use many machines to develop across multiple operating systems. 
The persons who are not developing with Qt, do not need a license (e.g. in case 
you have some part of the application not done with Qt). 

We have a FAQ to explain how Qt licensing works:  https://www.qt.io/faq/ 

Yours,

Tuukka

On 08/10/2019, 10.19, "Interest on behalf of Vyacheslav Lanovets" 
 wrote:

I hope to hear expert opinions on the following.

Let's say the company has 10 developers who develop a Mobile app for
consumer phones.

2 persons use *Mac* to make the app work on iOS (static linking!).
Another 2 persons work from PCs on supporting Android specifics
(shared linking).
All 10 have primary PC with Microsoft Visual Studio for regular
development because it is faster.
Also there is 2 build machines:
1 PC for generating Android builds.
1 Mac for generating iOS builds.

So, how many licenses should the company pay for?
13 licenses (~4 euro a year)? Or 12? Or 10? Or just for 3 Macs? Or
maybe only for 2 developer Macs?

Has anyone investigated the case with the legals?
Opinions?
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt free software policy

[Tuukka Turunen]

“could the author ask the module to be also available under GPLv2?”

Yes, but since the preference is to have the v3 for new items, there probably 
would be some discussion and planning what would be the best approach.

Yours,

Tuukka

From: Benjamin TERRIER 
Date: Saturday, 17 August 2019 at 12.18
To: Tuukka Turunen , qt qt 
Subject: Re: [Interest] Qt free software policy

Le ven. 16 août 2019 à 08:41, Tuukka Turunen 
mailto:tuukka.turu...@qt.io>> a écrit :

I do agree that we should clarify this, especially the GPLv2 and GPLv3 part is 
not clearly explained at qt.io<http://qt.io> websites. The approach is to use 
the v3 of both LGPL and GPL for new things, but to keep GPLv2 option for 
Essentials and those Add-ons that existed in December 2015, see clause 4.4 and 
4.6 in  https://kde.org/community/whatiskde/Software_License_Agreement_2015.pdf


Thank you for claryfing that.
I have one last question. As Thiago said that it is up to the module author do 
choose the license, would a module author be able to choose only between GPLv3 
and LGPLv3? Or could the author ask the module to be also available under GPLv2?

Br,

Benjamin
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt free software policy

[Tuukka Turunen]

“Well you said "Alternative for using GPLv3 and commercial would be to only 
offer these add-ons separately under a commercial license".
You did not say _only alternative_ explicitly, but it does sound, at least to 
me, like it is implicitly here.”

Sorry for that. I also should have used words “did not mean” not “did not say” 
in my reply.

Emails as a medium is tricky, easy to misunderstand the tone.

I do agree that we should clarify this, especially the GPLv2 and GPLv3 part is 
not clearly explained at qt.io websites. The approach is to use the v3 of both 
LGPL and GPL for new things, but to keep GPLv2 option for Essentials and those 
Add-ons that existed in December 2015, see clause 4.4 and 4.6 in  
https://kde.org/community/whatiskde/Software_License_Agreement_2015.pdf

Yours,

Tuukka



From: Interest  on behalf of Benjamin TERRIER 

Date: Thursday, 15 August 2019 at 12.18
To: qt qt 
Subject: Re: [Interest] Qt free software policy



Le jeu. 15 août 2019 à 09:18, Vadim Peretokin 
mailto:vpereto...@gmail.com>> a écrit :
Still, it reads like the Instagram influencer argument: "Give me free stuff and 
I'll get you exposure.", and we all know how silly that sounds like.

That is a bit insulting toward Qt contributors.
And comparing free software projects (including Qt) with Instagram's "Give me 
free stuff and I'll get you exposure" is inappropriate.

If you look at the stats of Qt Base a large percentage of the commits (~40% I'd 
say) are made by people external to The Qt Company.
You can have a look on Thiago's blog: 
https://macieira.org/~thiago/qt-stats/current/qtbase.employer.relative.png
(BTW Thiago, if you read this, the SSL certificate is invalid and some charts 
are broken)

My point is that The Qt Company is not providing free stuff merely for 
exposure. It also gets many other things including developers
committing code for free, code that The Qt Company is then able to sell under 
its commercial license.

Also I never asked for anything free here. I am asking if "GPLv3 only" is and 
will be the standard licensing scheme for new modules
made by The Qt Company. I feel that it needs to be made clear, at least so that 
if an LGPL user need something he knows
that he should not expect to have it in a future version of Qt, but should 
rather contribute it himself ensuring that it will be available under LGPL.
I have also expressed my concerns that the lack of support for GPLv2 can be an 
issue for some projects.
I would also like that some modules, if they are not good sale arguments, could 
be licensed under LGPL as if they do not help
The Qt Company sales, they could at least contribute to growing the community.


On Thu, Aug 15, 2019 at 6:17 AM Tuukka Turunen 
mailto:tuukka.turu...@qt.io>> wrote:

“This is wrong to say that the only alternative to Commercial + GPLv3 is 
Commercial only.”

I did not say the _only_ alternative. Some new things are LGPL exactly to grow 
the user base. Qt for Python being one of such.


Well you said "Alternative for using GPLv3 and commercial would be to only 
offer these add-ons separately under a commercial license".
You did not say _only alternative_ explicitly, but it does sound, at least to 
me, like it is implicitly here.

+1 for Qt for Python.


BR

Benjamin
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt free software policy

[Tuukka Turunen]

“This is wrong to say that the only alternative to Commercial + GPLv3 is 
Commercial only.”

I did not say the _only_ alternative. Some new things are LGPL exactly to grow 
the user base. Qt for Python being one of such.

Yours,

Tuukka

From: Benjamin TERRIER 
Date: Wednesday, 14 August 2019 at 22.18
To: Tuukka Turunen 
Cc: qt qt 
Subject: Re: [Interest] Qt free software policy



Le mer. 14 août 2019 à 20:36, Tuukka Turunen 
mailto:tuukka.turu...@qt.io>> a écrit :

Hi,

Qt’s approach to open-source is publicly described, but perhaps a bit hidden, 
check for example:

· Section 3 of https://www.qt.io/faq/

· https://wiki.qt.io/Qt_Project_Open_Governance

· https://www.qt.io/licensing/

These pages are just presenting the current licensing options.
They do not cover how The Qt Company view the licensing of future Qt modules.

We have been releasing new add-on modules under GPLv3 and commercial licenses 
with intention of growing the adoption of commercial license for those making 
closed-source applications with Qt. Alternative for using GPLv3 and commercial 
would be to only offer these add-ons separately under a commercial license, 
which would mean not even those who are ok with GPLv3 license could use these 
add-ons. Some of such components do exist, but most of our code is available 
under an open-source license as well.

This is wrong to say that the only alternative to Commercial + GPLv3 is 
Commercial only.
The new add-ons modules could be provided as GPLv3 + GPLv2 + LGPLv3.
I understand the will to grow "the adoption of commercial license", but I 
believe that some modules which have a lot of alternatives available could be 
licensed also under GPLv2 and/or LPGLv3 without going against "the adoption of 
commercial license".
Also having more module on LGPL can grow the Qt community leading to indirect 
sales of the commercial license.

For instance when I work on GPLv3 projects I can use all Qt add-ons, but when I 
work on GPLv2 or LGPLv3 project I cannot use the most recent Qt modules.
Which means that I have to find an alternative anyway. In the end I do not use 
these Qt add-ons, even for the GPLv3 projects as I have an alternative ready.

At the same time we have developed a lot of new functionality, done a lot of 
improvements, and fixed a lot of bugs in functionality available also with LGPL 
license. This is a big investment, which directly benefits all Qt users whether 
they distribute their applications under LGPL, GPL or commercial license. Just 
look at the amount of new and changed code and you can see that the LGPLv3 
parts are clearly not some legacy functionality, but very actively developed 
areas of Qt.

I am not denying that.
It is just that all the novelties are GPLv3 only and I think it should be made 
clear to the community that new LGPL modules are not to be expected.

BR

Benjamin
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt free software policy

[Tuukka Turunen]

Hi,

Qt’s approach to open-source is publicly described, but perhaps a bit hidden, 
check for example:

  *   Section 3 of https://www.qt.io/faq/
  *   https://wiki.qt.io/Qt_Project_Open_Governance
  *   https://www.qt.io/licensing/

We have been releasing new add-on modules under GPLv3 and commercial licenses 
with intention of growing the adoption of commercial license for those making 
closed-source applications with Qt. Alternative for using GPLv3 and commercial 
would be to only offer these add-ons separately under a commercial license, 
which would mean not even those who are ok with GPLv3 license could use these 
add-ons. Some of such components do exist, but most of our code is available 
under an open-source license as well.

At the same time we have developed a lot of new functionality, done a lot of 
improvements, and fixed a lot of bugs in functionality available also with LGPL 
license. This is a big investment, which directly benefits all Qt users whether 
they distribute their applications under LGPL, GPL or commercial license. Just 
look at the amount of new and changed code and you can see that the LGPLv3 
parts are clearly not some legacy functionality, but very actively developed 
areas of Qt.

Yours,

Tuukka


From: Interest  on behalf of Benjamin TERRIER 

Date: Wednesday, 14 August 2019 at 19.21
To: qt qt 
Subject: [Interest] Qt free software policy

Hi everyone,

Since we are talking about the future of Qt these days, I would like
to know The Qt Company free software policy with Qt.

Today, most of Qt modules are released under 3 free software licenses: LGPLv3,
GPLv2 and GPLv3. Some modules are released only under GPLv3.
If my memory is good, these GPLv3-only modules are the ones which used to
be commercial-only modules (like Qt Charts).

However, it seems to me that most, if not all (except Qt 3D), new Qt modules
are now being released only under GPLv3:
 - Network Auth
 - WebGL
 - WASM
 - Http Server
 - Lottie
 - Quick 3D
 - MQTT

I understand that The Qt Company is only obligated to release new modules
under GPLv3 (because of the KDE agreement).
I understand also that The Qt Company business model is selling Qt licenses
and has no direct financial interests in releasing Qt under any other license.

So I can understand that some modules, in particular those valuable for wealthy 
industrial companies,
are only released under GPLv3.
However, for some modules like HttpServer, it seems to be an odd choice. There 
are plenty
alternatives available under LGPL or more permissive licenses, so I do not see 
what
would be the loss of releasing it under LGPLv3.

Also the fact that those modules are GPLv3 only is a problem when developing 
with other
components that are GPLv2 only (and not GPLv2+).

So I would like that someone could officially confirm if all new modules will be
released under GPLv3 only. Or if it is something that is decided on a per module
basis.

I believe that Qt users and contributors deserve to know what it The Qt Company
view on this.
Using an LGPLv3 framework is not the same thing as using a GPLv3 framework
where some historical parts are available under LGPLv3 and all new features 
will be GPLv3 only.

BR,

Benjamin


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.9 and OpenSSL 1.1?

[Tuukka Turunen]

Hi,

Let's create (if not yet created) and link the QTBUG JIRA tasks for Qt 5.9 and 
Qt 5.12 to the mailing list. Continue discussion there. Easier than mailing 
list for this type of a task.

In principle switch to new version should be well justified. We just need to 
check the practicalities.

We already have OpenSSL in use by the installer, but it is not currently a 
shipped 3rd party module of Qt. As long as it is not enabled by default for Qt 
apps, we could add it like we typically do for 3rd party items. 

Yours,

Tuukka

On 22/03/2019, 10.20, "Interest on behalf of Jani Heikkinen" 
 wrote:

> -Original Message-
> From: Interest  On Behalf Of Thiago
> Macieira
> Sent: perjantai 22. maaliskuuta 2019 4.12
> To: interest@qt-project.org
> Subject: Re: [Interest] Qt 5.9 and OpenSSL 1.1?
> 
> On Wednesday, 20 March 2019 23:45:38 PDT Roland Winklmeier wrote:
> > Wouldn’t it be good then if official binaries from newer releases
> > build against OpenSSL 1.1?
> 
> Yes and no. For future compatibility, we should do that and should have 
done
> that for 5.12 already. But doing so means the binaries so produced won't 
run
> on older, still supported Linux distributions.
> 
> > According to
> > https://wiki.qt.io/Qt_5.12_Tools_and_Versions all official binaries
> > are still built against 1.0.2. If that is end of live this year, is
> > there a plan to change this?
> 
> Not yet. Thanks for bringing it up, we'll have to make a decision. I'll 
bring this
> up with the release team to figure out if there's a limitation in the 
build
> servers (if it's the same environment that builds 5.9, for example).
> Then we'll make a recommendation.

We will check this. I know there is already work ongoing to switch that in 
dev (https://codereview.qt-project.org/#/c/244362/)

br,
Jani
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Fwd: vs. Flutter

[Tuukka Turunen]

Hi, 

No, that is not correct understanding. Mobile is well maintained and developed 
further - just like the desktop and embedded platforms. 

We are constantly investing to the mobile and improving it with each release. 
For all the new features we always aim to get it running cross-platform, 
including mobile, whenever possible. So the functionality of mobile grows 
constantly, just like desktop and embedded.

I do understand that you would like to have more of the device related items 
(volume control, brightness, ...) captured to a Qt API. But lack of this should 
not be seen as equal to lack of investment to mobile. What I wrote about it 
being relative easy to implement could be seen positively as well - at least I 
did not mean it in any way negative or insulting.

Yours,

Tuukka

On 27/02/2019, 10.19, "Jason H"  wrote:

So am I correct interpreting that Qt on mobile is "finished", and we're on 
our own? (Aside from maintenance) Your statement "often quite straightforward 
to capture in a cross-platform API." seems like a "let them eat cake" moment. I 
really think you are missing the point that these "straightforward" are 
anything but. Who knows Objective C and Java? Not many. Not to mention there 
are enough pain points in moving to another platform already. I believe the 
promise of cross platform Qt is at least to handle the code. 

What would it take to get Qt to commit to supporting device APIs?

> Sent: Tuesday, February 26, 2019 at 11:34 PM
> From: "Tuukka Turunen" 
> To: "Jason H" 
> Cc: "Bernhard B" , "interestqt-project. org" 

> Subject: Re: [Interest] Fwd: vs. Flutter
>
> 
> Hi,
> 
> Like you said, different users have slightly different needs, but there 
are also many things common. Our focus recently has been to make sure that old 
and new Qt features work nicely on mobile and in making sure new mobile 
platforms are supported swiftly. A lot of effort was put to WinRT / UWP to be 
supported in addition to iOS and Android. It is true that we have not been 
actively extending the support for device APIs, even though these are often 
quite straightforward to capture in a cross-platform API.
> 
> Yours,
    > 
> Tuukka
> 
> From: Jason H 
> Date: Monday, 25 February 2019 at 11.06
> To: Tuukka Turunen 
> Cc: Bernhard B , "interestqt-project. org" 

> Subject: Re: [Interest] Fwd: vs. Flutter
> 
> Tukka,
> 
> I don't think that there is a single Mobile user that finds your reply 
adequate.
> 
> It sounds like you're dragging Mobile users along. We need a specific 
mobile effort to add those mobile specific APIs the platform should have.  
Without these APIs, my organization will not be able to justify continued usage 
of Qt. I have to continually defend our selection of Qt. I've never spoken to 
someone who was happy to have to use Qt. Xamarin, Flutter, and ReactNative are 
what other developers want to use. I cannot expect to continue to win this 
fight as Qt falls behind.
> 
> 
> I'm not the only one. I'm just the Squeakiest wheel. I can't really 
justify another $1000/yr (1. that's just Indie, not Enerprise, 2. No 
transparent pricing) after spending $3000 on Qt.
> 
> I'm begging you to add mobile APIs for:
> - Device Hardware Control
> -- Device Button Integration (volume, etc)
> -- Display Brightness
> -- Volume Control
> -- Screen Control (Full Screen/ Nav Buttons, Wake Lock)
> - Notifications (Push & Local, Desktop?) (Probably the dingle biggest 
pain point)
> - iOS NFC (starts at iPhone 7, iOS 10)
> 
> These all might seem "not that hard", until you consider I have to do it 
for 3 platforms: OSX, iOS, Android, each with their own tech stack. (ObjC, JNI, 
Java) This is a huge pain point, considering that is the fundamental problem 
that Qt claims solve. Except it doesn't... on Mobile. It's not like I'm asking 
for bleeding edge APIs. Qt started supporting iOS & Android 12th Dec 2013 with 
Qt 5.2. In the 5 years since, none of the above have made it in and those are 
pretty basic features. Since that time there were some early iOS accessibilty 
additions and Android service capabilty. That's it.
> 
> I'm not asking for every possible mobile API to be supported, just a 
80/20. Other developers have their own needs, and I'm in favor of us together 
coming up with that list, and having Qt commit to the top item(s) each release. 
That's what I mean when I say I want a transparent roadmap for mobile.
> 
> 
> 
> Sent: Monday, February 25, 2019 at 3:20 AM
> From: "Tuukka Turunen" 
> To: "Be

Re: [Interest] Fwd: vs. Flutter

[Tuukka Turunen]

Hi,

Like you said, different users have slightly different needs, but there are 
also many things common. Our focus recently has been to make sure that old and 
new Qt features work nicely on mobile and in making sure new mobile platforms 
are supported swiftly. A lot of effort was put to WinRT / UWP to be supported 
in addition to iOS and Android. It is true that we have not been actively 
extending the support for device APIs, even though these are often quite 
straightforward to capture in a cross-platform API.

Yours,

Tuukka

From: Jason H 
Date: Monday, 25 February 2019 at 11.06
To: Tuukka Turunen 
Cc: Bernhard B , "interestqt-project. org" 

Subject: Re: [Interest] Fwd: vs. Flutter

Tukka,

I don't think that there is a single Mobile user that finds your reply adequate.

It sounds like you're dragging Mobile users along. We need a specific mobile 
effort to add those mobile specific APIs the platform should have.  Without 
these APIs, my organization will not be able to justify continued usage of Qt. 
I have to continually defend our selection of Qt. I've never spoken to someone 
who was happy to have to use Qt. Xamarin, Flutter, and ReactNative are what 
other developers want to use. I cannot expect to continue to win this fight as 
Qt falls behind.


I'm not the only one. I'm just the Squeakiest wheel. I can't really justify 
another $1000/yr (1. that's just Indie, not Enerprise, 2. No transparent 
pricing) after spending $3000 on Qt.

I'm begging you to add mobile APIs for:
- Device Hardware Control
-- Device Button Integration (volume, etc)
-- Display Brightness
-- Volume Control
-- Screen Control (Full Screen/ Nav Buttons, Wake Lock)
- Notifications (Push & Local, Desktop?) (Probably the dingle biggest pain 
point)
- iOS NFC (starts at iPhone 7, iOS 10)

These all might seem "not that hard", until you consider I have to do it for 3 
platforms: OSX, iOS, Android, each with their own tech stack. (ObjC, JNI, Java) 
This is a huge pain point, considering that is the fundamental problem that Qt 
claims solve. Except it doesn't... on Mobile. It's not like I'm asking for 
bleeding edge APIs. Qt started supporting iOS & Android 12th Dec 2013 with Qt 
5.2. In the 5 years since, none of the above have made it in and those are 
pretty basic features. Since that time there were some early iOS accessibilty 
additions and Android service capabilty. That's it.

I'm not asking for every possible mobile API to be supported, just a 80/20. 
Other developers have their own needs, and I'm in favor of us together coming 
up with that list, and having Qt commit to the top item(s) each release. That's 
what I mean when I say I want a transparent roadmap for mobile.



Sent: Monday, February 25, 2019 at 3:20 AM
From: "Tuukka Turunen" 
To: "Bernhard B" , "interestqt-project. org" 

Subject: Re: [Interest] Fwd: vs. Flutter
Hi,

I focused mainly in the tooling and cross-platform features in the roadmap blog 
post. There are other items done as well – more than what reasonably fits into 
a post. Mobile is an area where we are making constant development, just like 
we do on desktop and embedded.

Currently the biggest new investment goes towards tooling and 3D – both of 
which have some benefits for mobile as well. This of course eats some 
development capacity away from other things, but it does not mean nothing else 
would be done.

Many of our desktop and embedded users also address mobile – in addition to 
those who address mobile only (or start with mobile). That is the beauty of the 
cross-platform, with a growing number of users deploying to mobile.

Yours,

Tuukka

From: Interest  on behalf of Bernhard B 

Date: Friday, 22 February 2019 at 14.28
To: "interestqt-project. org" 
Subject: Re: [Interest] Fwd: vs. Flutter

Many thanks to Tuukka for the Qt Roadmap 2019 blog post 
(https://blog.qt.io/blog/2019/02/22/qt-roadmap-2019/) - very much appreciated!

As the mobile part was not explicitly mentioned, I assume that it won't be a 
focusing area for 2019 then? :/

Jean-Michaël Celerier 
mailto:jeanmichael.celer...@gmail.com>> schrieb 
am Fr., 22. Feb. 2019, 12:09:
> They even included, scripts to build the app. I'm not sure you have to go 
> quite that far to be compliant, but awesome nevertheless.

You explicitely have to:

LGPLv3 4. e): Provide Installation Information, but only if you would otherwise 
be required to provide such information under section 6 of the GNU GPL, and 
only to the extent that such information is necessary to install and execute a 
modified version of the Combined Work produced by recombining or relinking the 
Application with a modified version of the Linked Version. (If you use option 
4d0, the Installation Information must accompany the Minimal Corresponding 
Source and Corresponding Application Code. If you use option 4d1, you must 
provide the Installation Information 

Re: [Interest] Fwd: vs. Flutter

[Tuukka Turunen]

Hi,

I focused mainly in the tooling and cross-platform features in the roadmap blog 
post. There are other items done as well – more than what reasonably fits into 
a post. Mobile is an area where we are making constant development, just like 
we do on desktop and embedded.

Currently the biggest new investment goes towards tooling and 3D – both of 
which have some benefits for mobile as well. This of course eats some 
development capacity away from other things, but it does not mean nothing else 
would be done.

Many of our desktop and embedded users also address mobile – in addition to 
those who address mobile only (or start with mobile). That is the beauty of the 
cross-platform, with a growing number of users deploying to mobile.

Yours,

Tuukka

From: Interest  on behalf of Bernhard B 

Date: Friday, 22 February 2019 at 14.28
To: "interestqt-project. org" 
Subject: Re: [Interest] Fwd: vs. Flutter

Many thanks to Tuukka for the Qt Roadmap 2019 blog post 
(https://blog.qt.io/blog/2019/02/22/qt-roadmap-2019/) - very much appreciated!

As the mobile part was not explicitly mentioned, I assume that it won't be a 
focusing area for 2019 then? :/

Jean-Michaël Celerier 
mailto:jeanmichael.celer...@gmail.com>> schrieb 
am Fr., 22. Feb. 2019, 12:09:
> They even included, scripts to build the app. I'm not sure you have to go 
> quite that far to be compliant, but awesome nevertheless.

You explicitely have to:

LGPLv3 4. e): Provide Installation Information, but only if you would otherwise 
be required to provide such information under section 6 of the GNU GPL, and 
only to the extent that such information is necessary to install and execute a 
modified version of the Combined Work produced by recombining or relinking the 
Application with a modified version of the Linked Version. (If you use option 
4d0, the Installation Information must accompany the Minimal Corresponding 
Source and Corresponding Application Code. If you use option 4d1, you must 
provide the Installation Information in the manner specified by section 6 of 
the GNU GPL for conveying Corresponding Source.)

And the corresponding GPL part (section 6, emphasis mine) :

The “Corresponding Source” for a work in object code form means all the source 
code needed to generate, install, and (for an executable work) run the object 
code and to modify the work, including scripts to control those activities. 
However, it does not include the work's System Libraries, or general-purpose 
tools or generally available free programs which are used unmodified in 
performing those activities but which are not part of the work.



On Fri, Feb 22, 2019 at 11:55 AM René Hansen 
mailto:ren...@gmail.com>> wrote:

On Fri, 22 Feb 2019, 13:47 Jean-Michaël Celerier, 
mailto:jeanmichael.celer...@gmail.com>> wrote:
Cisco did it with an app that uses gstreamer (which is under LGPL) : 
https://itunes.apple.com/ua/app/cisco-jabber/id467192391?mt=8.
They send it on request, with the proprietary part in a static lib (see at the 
end here :
https://github.com/GStreamer/gst-plugins-good/blob/master/README.static-linking
)

That is really cool. They even included, scripts to build the app. I'm not sure 
you have to go quite that far to be compliant, but awesome nevertheless. Maybe 
someone can clarify this further. I.e. Are you responsible for providing a, or 
instructions for creating a, working build environment, in order to be LGPL 
compliant.


Best,
Jean-Michaël

On Thu, Feb 21, 2019 at 6:07 PM Sylvain Pointeau 
mailto:sylvain.point...@gmail.com>> wrote:
Do you have one example of someone who put a LGPL app in the app store and 
provided the binary object files?

On Thu, Feb 21, 2019 at 3:58 PM Julius Bullinger 
mailto:julius.bullin...@gmail.com>> wrote:
On 21.02.2019 15:44, Christian Gagneraud wrote:
> Qt is free (on mobile), free as in liberty, as long as your
> application is free, as in liberty.
> That's basic (L)GPL rules.
>
> Now there's the business rules:
> If you want your (mobile) app to be non-free (as in proprietary), then
> you'll have to pay the Qt company for that. Disregarding the fact that
> you want to make money or not.

Please do not spread this misinformation! As long as you adhere to the
terms of LGPL, you can create non-free, proprietary and closed apps with
Qt (or any other LGPL library for that matter). You only need to make
sure that the user can replace all LGPL parts with their own builds.

The fact that the mobile OS's and app stores make it exceptionally hard
to do that is not an issue with the license terms. If you find a way
that enables the user to replace LGPL parts (for example by dynamic
linking or by making all object files and linking instructions available
on request), that's perfectly valid and legal.

_That_ is a basic LGPL rule.

https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1)

https://tldrlegal.com/license/gnu-lesser-general-public-license-v3-(lgpl-3)

Re: [Interest] Priority of bugs

[Tuukka Turunen]

Hi,

Just to note that more than “two minor fixes” were done related to widgets in 
Qt 5.11.2 of the total 262 fixes: https://bugreports.qt.io/issues/?filter=19635

Widgets is an important area and we are actively maintaining those. There is 
less new development than on some other areas, but Widgets are not forgotten.

This is just to point out that situation is not as bad as you said. There is 
always possibility to do more and there are certainly many bugs still to fix in 
Widgets area.

Yours,

Tuukka

From: Interest  on behalf 
of Krzysztof Kawa 
Date: Monday, 1 October 2018 at 16.30
To: "interest@qt-project.org" 
Subject: Re: [Interest] Priority of bugs

I get that. Let me try to be more constructive then - looking at the proportion 
of the number of those long standing unresolved issues to the number of bullet 
points in the release notes by module I'd say a lot of those unlucky ones sit 
in the widgets area (e.g. 2 minor fixes in 5.11.2 is hardly an adequate pace).
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Porting Qt to our RTOS

[Tuukka Turunen]

Hi Kim,

Even partial Posix will help you get going. It is possible to do without, but 
then more work will be needed.

When looking into QPA, perhaps the one for INTEGRITY is the one that you want 
to start with.

What kind of hardware and applications you are thinking about?

Yours,

Tuukka

On 27/09/2018, 6.34, "Interest on behalf of Jason H" 
 wrote:

I think POSIX will make it very l vastly easier. But a graphical raster 
framebuffer should be doable. Look at QPA, the platform plugin architecture and 
see what you can adapt. 

Warning: I've never tried to do it. 

> Sent: Thursday, September 27, 2018 at 2:09 AM
> From: "Kim Hartman" 
> To: "interest@qt-project.org" 
> Subject: [Interest] Porting Qt to our RTOS
>
> I am investigating how to bring Qt to our INtime RTOS. The INtime 
Distributed RTOS runs on standard PC hardware as a multicore AMP OS (no SMP and 
not POSIX compliant). Currently the RTOS has only a text console output based 
on INT10 services. The RTOS is fully preemptive, with strict priority based 
scheduling, managed process services with rich IPC services. The development 
environment is tightly coupled with MS VC (2008 and on) with ANSI C and C++11 
language support. The RTOS is very stable and been commercially deployed for 
decades. It lacks a means for graphical programming, mostly for industrial 
controls application. What is the means to port Qt to this RTOS? We're not 
intending on building out OpenGL ES 2.0 unless absolutely necessary. I've read 
some marketing materials about Qt on MCU, however the details seem very thin. 
It's not Windows, Linux, OSX, Android, QNX, Integrity, or VxWorks... how to go 
about getting this done?
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Code contributions via bug reports and forum posts

[Tuukka Turunen]

Hi,

Contribution of source code is now allowed via Qt systems such as bug reports 
and forums. Traditionally all source code contributions to the Qt Project are 
governed via Contribution License Agreement (CLA), except possibility given to 
the commercial license holders to provide bug fixes and similar small 
modifications that The Qt Company has pushed into Qt. We have now updated the 
Qt Account service terms to more clearly state that source code can be 
contributed via the Qt systems. The preferred way to contribute source code to 
the Qt Project is still via the CLA, according to the contribution guidelines. 
But sometimes a user who has not accepted the CLA has a patch that would, for 
example, fix a bug in Qt. Providing such a patch is now also possible via the 
Qt systems, for example via the bug reports or forum posts.

Please check a blog post for more information: 
http://blog.qt.io/blog/2018/05/16/code-contributions-via-bug-reports-forum-posts/

Note that any existing source code in the systems is not covered, only items 
pushed from now on.

Yours,

Tuukka


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt for AR

[Tuukka Turunen]

Hi,

I fully agree that marker based AR is not the proper way to do tracking. With a 
mobile phone, best is if you can leverage camera for "natural feature tracking" 
and aid the accuracy via sensor fusion. Depending upon the application / use 
case you may be able to use known objects as markers (think amiibo, but with 
visual recognition). There are different algorithms for camera based natural 
feature tracking, some of these freely available. Qt offers a good baseline for 
creating this type of application, but currently you need to do the tracking in 
your application.

Yours,

Tuukka

On 05/03/2018, 23.31, "Interest on behalf of Jason H" 
 wrote:

So QR-code based AR is kinda a joke (to me, see note) but real AR (provide 
visualization overlay) seems quite useful, unfortunately no phone really 
supports this correctly yet in a 3D VR way (It requires a dual camera config 
with separation = eye seperation) However the middle ground AR (sticker free 
scene augmentation) has some promise at this time. 

I'm working on an app that isn't AR (Maybe when Qt3D is ready for phones!) 
but wants the same information the AR app has. You may remember some of my 
posts about the tilt range problem (-45 to 45 of pitch is not enough) and is 
jittery. Also the compass is *extremely* jittery.  I can run these through an 
EMA, but that creates motion-sickening lag. 

What is the "proper" way to get accurate phone position information? 
Android VR certification requires 90fs, which is an 11ms update interval. 

Note: QR-code based AR is disqualified because he orientation is determined 
relative to the QR code, by analyzing its orientation. 
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Future of Qt3d

[Tuukka Turunen]

Hi Christian,

KDAB is a valuable contributor to the Qt project. The biggest one, if not 
counting The Qt Company. According to Qt project statistics, KDAB’s 
contributions are about 15% or all commits to Qt: 
http://www.macieira.org/~thiago/qt-stats/current/qt-all.employer.relative.png 

We all of course hope to have KDAB back contributing, but there is no need to 
be worried about the future of Qt. Everything continues just as before. Also Qt 
3D continues to be a fully supported module of Qt. 

Yours,

Tuukka

On 02/11/2017, 23.22, "Interest on behalf of Christian Gagneraud" 
 wrote:

On 3/11/2017 5:39 AM, Pierre Chicoine wrote:
> Does anyone know the future of Qt3d? After Sean posted his problem with 
> management of Qt, we've heard nothing.

It's not just Qt3d, KDAB is a big contributor and there are many other 
contributors involved.
It would be really nice to have a quick status about this issue.
I do think that the lack of transparency is not good for Qt's own 
reputation (The Qt Project and the Qt Company).

Chris
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] News about Qt on QNX ?

[Tuukka Turunen]

Hi Julien,

Qt 5.9 LTS (and later versions) support QNX 7.0 
(http://doc.qt.io/qt-5/supported-platforms.html). You are right that the HTML5 
engine offering on QNX is somewhat complicated as Qt WebEngine does not work on 
it due to lacking Chromium port for QNX. According to QNX this is something 
they are working on, so perhaps this something to be addressed later 
(http://blogs.blackberry.com/2016/12/blackberry-qnx-partners-with-obigo-to-build-a-better-browser-for-your-car/).
 It is possible to run Qt WebKit, but this needs to be used with care as it is 
also not out of the box supported. If the needs are related to a commercial 
project, there are multiple service partners as well as consulting teams of The 
Qt Company to help reach a solution for the HTML5 needs also on QNX.

Yours,

Tuukka

From: Interest  on behalf 
of Julien Bordes 
Date: Tuesday, 5 September 2017 at 11.48
To: "interest@qt-project.org" 
Subject: Re: [Interest] News about Qt on QNX ?

> > Hello All,
> >
> > I am currently developing a QtQuick/QML based application with Qt 5.9.1 and 
> > QNX 6.6 on a iMX6 platform with a Linux workstation and I have some 
> > difficulties to get fresh informations about Qt on QNX and I don't know 
> > where to look anymore.
>
> (Thiago Macieira)
>
> Qt on QNX is still very well supported, by Blackberry themselves. It's one of
> the platforms tested in the Qt continuous integration system.

I have no doubt about the work of Blackberry but nevertheless there is not much 
fresh news availables about modules compatibility neither on the Qt website and 
wiki nor on QNX website, even our local license sellers weren't able to provide 
us thoses informations.

> I have no clue about iMX6 though.

According ot the (wiki https://wiki.qt.io/QNX_Platform#Reference_boards) a 
Freescale i.MX6Q Sabre Lite, board is use for development and testing.

> > I first searched in the wiki but it was updated for the last time in April 
> > 2015 (http://wiki.qt.io/Qt_Status_on_QNX) and there is no news on the Qt 
> > documentation (http://doc.qt.io/qt-5/platform-notes-qnx.html) and in 
> > Supported platforms (http://doc.qt.io/qt-5/supported-platforms.html).
> >
> > The most recent informations I found are in this presentation from 
> > September 2016 at QtCon by James McDonnel 
> > https://conf.qtcon.org/system/attachments/154/original/Qt_on_QNX_-_2016_-_003.pdf?1474298472)
> >  and in the Qt mailing list archives 
> > (http://lists.qt-project.org/pipermail/development/2017-March/029347.html).
> >
> >
> > I also found out in april 2017 in the Development mailing list 
> > (http://lists.qt-project.org/pipermail/development/2017-April/029597.html) 
> > and in the Maintainers list (https://wiki.qt.io/Maintainers) than James 
> > McDonnel has been nominated as the official maintainer for Qt on QNX.
> >
> > Based on those previous statements I have some questions, regarding Qt on 
> > QNX.
> >
> > - Roadmap and Modules support
> >
> > Does a roadmap about Qt on QNX exist ? If yes where can we find it ?
>
> (Thiago Macieira)
>
> In the same place as the roadmap for all the other platforms.
>
> We don't make roadmaps.

I thought you did :)

http://blog.qt.io/blog/2016/02/22/qt-roadmap-for-2016/
http://blog.qt.io/blog/2017/02/22/qt-roadmap-for-2017/

There is also informations in the wiki in "Release" and "Known issues" about 
current and future versions of Qt, but there is not often mention of QNX.

> > It seems Qt 5.9 is supported by both QNX 6.6 and QNX 7.0, what will it be 
> > for later version of QT (5.10, 5.1x, and later 6.x) ?
>
> (Thiago Macieira)
>
> Most likely we'll need to support 6.6 for some time. The fact that it uses GCC
> 4.7 was a problem, as I wanted to drop it from our supported list for 5.10.
>
> >
> > It there a way to know the list of modules supported for recent versions of 
> > Qt ? I also found there is a Qt Bug about this planned to be fixed for Qt 
> > 5.10 (https://bugreports.qt.io/browse/QTBUG-59976).
>
> (Thiago Macieira)
>
> All of the ones we develop. That excludes qtwebkit and qtwebengine, since they
> are upstream projects.

The question was more QNX oriented as today not all modules are compatible with 
QNX 6.6 (e.g. Virtual keyboard).

> > - Webengine
> >
> > Since Qt5.6 QtWebkit is no more officially supported by Qt. However you can 
> > compile it anyway but it works only with QWidgets and not with QtQuick/QML 
> > because QtDeclarative is not supported, from what I understand.
>
> (Thiago Macieira)
>
> And there's QtWebkit 5.212 if you need an update.

When I checkout QtWebkit version to 5.212 I cannot compile Qt 5.9.1 for QNX 6.6 
with gcc 4.7.3.

The WebKit build was disabled for the following reasons:
* cross-compilation of QtWebKit with qmake is not supported yet
* QNX is not supported.
* Using gcc version 4.7, but at least gcc version 4.9 is required to 

Re: [Interest] Using Widgets for new projects

[Tuukka Turunen]

Hi,

If you make a desktop application widgets are often a solid choice – especially 
if you want the application to look like other apps in that OS and not create 
your own style for the app. Qt Creator, for example, is an application that 
uses widgets extensively.

You may want to check out our on-demand webinar (read: video) about the topic: 
https://www.qt.io/event/the-curse-of-choice-an-overview-of-gui-technologies-in-qt/

Yours,

Tuukka


From: Interest  on behalf 
of Marco Piccolino 
Date: Wednesday, 17 May 2017 at 8.56
To: "interest@qt-project.org" 
Subject: [Interest] Using Widgets for new projects

In what scenarios would it still make sense to use QtWidgets for new projects?

Thanks
Marco Piccolino
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [Development] Testing help needed

[Tuukka Turunen]

Hi,

There were quite many people who expressed interest a few months ago to help in 
making the releases, so hopefully we get a lot of suggestions to better engage 
with the whole community for testing the releases.

Quite many are testing new Qt versions with their applications and reporting 
issues via bugreports. This is really valuable and we hope that with the new 
process of multiple betas available via the online installer this testing 
becomes even easier.

In addition we would like to have people to test new releases for wider 
functionality than just what their app needs. Optimally all, but that is of 
course not possible in practice.

We have automatic testing in place with quite good coverage, but in order to 
catch all the needed issues manual testing is still beneficial. This is what 
Jani is asking volunteers to help with.

The sooner we find issues to fix, the better. So time for testing is now.

Yours,

Tuukka

From: Development  on 
behalf of Jani Heikkinen 
Sent: Tuesday, April 25, 2017 11:39:48 AM
To: developm...@qt-project.org; releas...@qt-project.org
Cc: interest@qt-project.org
Subject: [Development] Testing help needed

Hi all,

There is now wiki page for reporting testing effort and results in 
https://wiki.qt.io/Qt59_release_testing . I also asked you all to take a tour 
for Qt 5.9 beta2 & report the effort via it. As you can see there isn't really 
any reports from community yet. It would be really beneficial for Qt to get 
packages tested early enough & find all release blockers well before official 
release. That would help us to keep the schedules and improve the release 
quality. So do you have some ideas how to get you all better involved to this? 
Is wiki page & table easy enough for this or should we use some other format? 
Getting you involved to this more will help us to do more patch level releases 
in the future as well (which has been the hot topic during this spring)...

br,
Jani




___
Development mailing list
developm...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt for Device Creation installer

[Tuukka Turunen]

Hi,

Please contact support helpdesk, they can assist you in installation issues.

Yours,

Tuukka

> -Original Message-
> From: Interest [mailto:interest-bounces+tuukka.turunen=qt.io@qt-
> project.org] On Behalf Of Nuno Santos
> Sent: perjantaina 3. helmikuuta 2017 13.34
> To: interestqt-project.org 
> Subject: [Interest] Qt for Device Creation installer
> 
> Hi,
> 
> I was aiming to give a try on Qt for Device Creation. I logged in my Qt 
> account
> and downloaded the installer for Qt for Device Creation (which appears to be
> the exact same installer file as for Qt).
> 
> Running the installer didn’t show me any option to install Qt for Device
> Creation. I’m on Ubuntu Linux x64.
> 
> What do I need to install Qt for Device Creation?
> 
> Thanks!
> 
> Regards,
> 
> Nuno
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Tuukka Turunen]

> -Original Message-
> From: Interest [mailto:interest-bounces+tuukka.turunen=qt.io@qt-
> project.org] On Behalf Of Thiago Macieira
> Sent: keskiviikkona 5. lokakuuta 2016 12.34
> To: interest@qt-project.org
> Subject: Re: [Interest] What don't you like about Qt?
> 
> Em quarta-feira, 5 de outubro de 2016, às 19:48:00 CEST, John C. Turnbull
> escreveu:
> > You did mention though that The Qt Company has SLAs and will try to
> > reproduce problems etc., but what if I just want to say things like "I
> > want this feature" or "I don't think this feature is implemented in
> > the best way" or "I think the whole SDLC is being managed in a way
> > that is ineffective and is making using Qt in a production environment
> difficult"
> > or "mobile support is nowhere near good enough to implement serious
> > apps so I can't use Qt as a true cross platform toolkit" or "QML is a
> > great concept but without adequate C++ APIs, it's really only suitable for
> basic forms"?
> >
> > What SLAs or kinds of responses should I expect then?
> 
> I don't know. Your commercial contract with The Qt Company may include
> something about that. Or not. I don't know, I've never read one (not even
> during my time working for Trolltech). I guess that it's during negotiation 
> that
> you get more leverage to make some demands.
> 
> I do remember Trolltech sending yearly surveys to find out what customers
> wanted. I don't know if The Qt Company has kept that practice.
> 

Yes, latest one is actually just closing. In addition, we ask feedback from 
every support case.

> From the Qt Project's point of view, to get a feature in, you can do one of:
>  * do it yourself
>  * convince someone to do it for you
>   (with arguments or by freeing up their time by taking up part of their work)
>  * paying someone to do it
> 

The normal Qt bug priorization is quite efficient in my opinion - we fix first 
the bugs that have highest impact. Mostly these bugs are fixed already during 
the development cycle, but of course sometimes critical bugs may slip through, 
and will be addressed in patch releases.

Like Kai mentioned, in addition to the normal priorization the bugs reported by 
commercial customers get focus. If it is a corner case or bug with a good 
workaround, it may still not get priority over something that would block high 
number of users - but in general we think this works fairly well. So reporting 
bugs via Qt Support will give the issue a boost. 

In general, we are unfortunately not able to fix all issues. I think we do 
quite good work in finding the right priorities, but the fact remains that 
getting more bugs fixed overall would be beneficial. 

Yours,

Tuukka

> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What you don't like about Qt

[Tuukka Turunen]

> -Original Message-
> From: Interest [mailto:interest-bounces+tuukka.turunen=qt.io@qt-
> project.org] On Behalf Of Roland Hughes
> Sent: perjantaina 23. syyskuuta 2016 13.50
> To: interest@qt-project.org
> Subject: Re: [Interest] What you don't like about Qt
> 
> Tried replying to this earlier, but didn't see the content come up so will 
> toss in
> my 0.0003 cents on this thread.
> 
>  >>- C++ is difficult, Qt lacks quality bindings for mainstream languages
> - moc (on build systems that don't automate this step)
> - FUD around licensing
> 
> Well, Digia has itself to thank for FUD. I contacted Digia right after they 
> took
> over Qt for a project I was working on. Yes, yes, we definitely needed a
> license. It was $5000 per developer and there were no royalties. Oh, no, you
> as a consultant cannot buy a commercial license and develop a product for a
> client, whoever's name is on the product must own the license. Less than
> two months later "owner" of the product contacted Digia directly. Yes, yes
> they definitely needed a license. It was many thousands of dollars more than
> what I was quoted AND they had to pay royalties. The bickering went back
> and forth for a while. Keep in mind this project was a front end for a 
> service.
> Anyone could download the software but you had to subscribe to the
> service.
> Finally the person actually funding the project who was rumored to be Bill
> Gates' next door neighbor, contacted some lawyers who contacted Digia. No,
> No you don't need a license, go with God my child.
> 
> Not an isolated case. Client after client tells the same story. The licensing
> team at Digia must be paid on commission because _every_ use requires a
> license when you first contact them.
> 

Many of the common questions about licensing are explained in the FAQ: 
https://www.qt.io/faq 

If the use case is a lot different than common ones, it is possible that 
different persons can provide varying opinions. At the end we do find the right 
model for every case - and most of the cases are fine with the common licensing 
terms: https://www.qt.io/terms-conditions 

There is also an online store for application development licenses: 
https://www.qt.io/buy-product 

Yours,

Tuukka
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Can't build Qt 5.8 alpha (Windows)

[Tuukka Turunen]

> -Original Message-
> From: Interest [mailto:interest-bounces+tuukka.turunen=qt.io@qt-
> project.org] On Behalf Of Thiago Macieira
> Sent: torstaina 22. syyskuuta 2016 4.40
> To: interest@qt-project.org
> Subject: Re: [Interest] Can't build Qt 5.8 alpha (Windows)
> 
> On quarta-feira, 21 de setembro de 2016 23:23:13 PDT Xavier Bigand wrote:
> > I just found a bug report for this build issue :
> > https://bugreports.qt.io/browse/QTBUG-55585
> >
> > Is there already a branch for version 5.8.0 beta?
> 
> Not yet.
> 

Next step is to get pre-beta binary snapshot under 
http://download.qt.io/snapshots/qt/5.8/ 

This should happen quite soon, well before the official Beta release. Jani will 
inform when there are things to test.

Branching to 5.8.0 will happen after Beta, i.e. Qt 5.8 Beta will come from 5.8 
branch.

Yours,

Tuukka

> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt for Integrity

[Tuukka Turunen]

Hi,

Full support for INTEGRITY is still with Qt 4.8 version. There is work ongoing 
by Rolland and others to bring new versions of Qt to support INTEGRITY and 
basics work already. Rather than using Qt 5.5.1, perhaps try 5.8 and help to 
complete the port?

Yours,

 Tuukka

From: Interest [mailto:interest-bounces+tuukka.turunen=qt...@qt-project.org] On 
Behalf Of bharathdwaj royal
Sent: torstaina 15. syyskuuta 2016 11.51
To: interest@qt-project.org
Subject: [Interest] Qt for Integrity

hello,

I would like to know how to do Qt5.5.1 for INTEGRITY. I meant how to port Qt5 
for Itegrity. How to create target platform in Qmakespec?
How to create  qmake file generator for Integrity in qmake??

Which command I have to pass for configuring Qt5.5.1 for Integrity??

--
Best regards,
--
Bharathadwaja Kodanda
Tel ph:+4917683310631
tu-chemnitz
bharathadhwaja.koda...@s2014.tu-chemnitz.de
bharathdwajro...@gmail.com
--
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt 5.6LTS vs 5.7+

[Tuukka Turunen]

> -Original Message-
> From: Interest [mailto:interest-bounces+tuukka.turunen=qt.io@qt-
> project.org] On Behalf Of Roland Hughes
> Sent: sunnuntaina 4. syyskuuta 2016 21.14
> To: 2202873.hgKzyLeXCm@patux.local; Interests Qt  project.org>
> Subject: Re: [Interest] Qt 5.6LTS vs 5.7+
> 
> 
> >Qt 5.6 is for those who cannot upgrade. If you can upgrade, upgrade.
> 
> >>How (un)likely is it that one can remain locked into 5.6 because of
> >>dependent code that doesn't build against 5.7+? Qt's backward
> >>compatibility principle should prevent that, no?
> 
> 
> It is extremely likely for development to remain locked to a version.

This is absolutely true. But what does it mean to keep using an outdated 
version in a connected system? How to ensure that the system remains secure? 
How to be able to bring new functionality (if / when) required by the 
customers? These issues may not happen for every system, but more and more will 
need to consider these. By being able to update the version of Qt framework 
regularly it becomes easier to address these issues, but of course there always 
are pro and cons. When creating a system, it is beneficial to make it so that 
it is feasible to regularly update it's components, including the Qt framework.

Yours,

 Tuukka




___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] GPL violator

[Tuukka Turunen]

Hi,

Yes, please report to le...@qt-project.org with as 
much details as possible, including the product in question, Qt version (if 
known), country (countries) as well as other details available.

Yours,

Tuukka

From: Interest [mailto:interest-bounces+tuukka.turunen=qt...@qt-project.org] On 
Behalf Of Dave Villae
Sent: torstaina 4. elokuuta 2016 15.36
To: interest@qt-project.org
Subject: [Interest] GPL violator

Hello,



Does Qt have a contact for reporting GPL violators to?



Dave
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt LGPLv3 and Qt LGPL Exception

[Tuukka Turunen]

> -Original Message-
> From: Interest [mailto:interest-bounces+tuukka.turunen=qt.io@qt-
> project.org] On Behalf Of Benjamin TERRIER
> Sent: keskiviikkona 29. kesäkuuta 2016 9.13
> To: qt qt 
> Subject: Re: [Interest] Qt LGPLv3 and Qt LGPL Exception
> 
> 2016-06-28 20:53 GMT+02:00 André Somers :
> >
> >
> >
> > Op 28/06/2016 om 11:09 schreef Jean-Michaël Celerier:
> >
> >
> > On Tue, Jun 28, 2016 at 10:39 AM, Benjamin TERRIER
>  wrote:
> >>
> >> The technical reason is that when including Qt headers in proprietary
> >> software, your final binary contains compiled forms of Qt code (e.g
> >> inline function or template classes).
> >
> >
> > From the LGPLv3 :
> >
> > 3. Object Code Incorporating Material from Library Header Files.
> >
> > The object code form of an Application may incorporate material from a
> header file that is part of the Library. You may convey such object code under
> terms of your choice, provided that, if the incorporated material is not 
> limited
> to numerical parameters, data structure layouts and accessors, or small
> macros, inline functions and templates (ten or fewer lines in length), you do
> both of the following:
> >
> > So... How exactly do you use any of the Qt containers using the LGPL3
> libraries? Are they implemented in 10 or less lines of template code?
> >
> > It think the question is valid, and reading the question, you can see that 
> > he
> read that passage.
> >
> > André
> >
> > a) Give prominent notice with each copy of the object code that the Library
> is used in it and that the Library and its use are covered by this License.
> > b) Accompany the object code with a copy of the GNU GPL and this license
> document.
> >
> >
> >
> > Best
> > Jean-Michaël Celerier
> >
> >
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
> >
> >
> >
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
> >
> 
> 
> It appears I misread the LGPLv3 and that there are no issues with Qt.
> 
> I thought the exception was only valid for inline functions of less than 10
> lines. Whereas in reality the exception is always valid, but requires you only
> to give credits if there is such a function.
> 
> It seems I'm not the only one on the Internet to misread this part when
> reading it fast :-/
> 
> Sorry about all the fuss.
> 

It is actually very good that these kind of items are asked. 

No longer needing to have similar LGPL exception with v3 was, of course, known 
and analyzed when the new licensing was decided. But it seems that we have not 
updated the licensing FAQ (http://qt.io/faq) about it and it clearly is not a 
self-evident topic. 

Yours,

Tuukka

> Cheers,
> 
> Benjamin
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt LGPLv3 and Qt LGPL Exception

[Tuukka Turunen]

> -Original Message-
> From: Interest [mailto:interest-bounces+tuukka.turunen=qt.io@qt-
> project.org] On Behalf Of Benjamin TERRIER
> Sent: tiistaina 28. kesäkuuta 2016 11.40
> To: qt qt 
> Subject: [Interest] Qt LGPLv3 and Qt LGPL Exception
> 
> Hi everyone,
> 
> Within the topic "[Development] Scope of source code license files" a
> question came about Qt LGPLv3 licensing which didn't get an answer and I
> would really like to get an answer from someone at Digia or The Qt Company.
> 
> 
> When Qt was licensed under the LGPLv2, Qt came with "The Qt Company Qt
> LGPL Exception version 1.1" which allows to include Qt headers in proprietary
> software. Without this exception Qt would not have been usable to develop
> proprietary software when licensed under LGPLv2.
> The technical reason is that when including Qt headers in proprietary
> software, your final binary contains compiled forms of Qt code (e.g inline
> function or template classes).
> 
> Starting from Qt 5.7, LGPLv2 in no more available and has been replaced by
> LGPLv3. "The Qt Company Qt LGPL Exception version 1.1"
> does not apply anymore as it is an exception to LGPLv2.
> The LGPLv3 has by itself an exception to allow includes in proprietary
> software, but there is an arbitrary limit that the exception does not apply to
> functions of more than 10 lines.
> 
> The direct consequence is that Qt (licensed under LGPLv3)  is not usable to
> develop proprietary software as developers will have to ensure that every Qt
> header does not have any 10+ line long inline or template function.
> 
> However, Qt website states that it is "Possible to keep your application
> private with dynamic linking" when using LGPLv3
> (https://www.qt.io/licensing-comparison/).
> 
> So is there supposed to be an LGPLv3 exception? If there is one and I missed
> it where is it? Or did the Qt Company forget to write one?
> 

Hi,

LGPLv3 already allows similar situation for which LGPLv21 exception was 
created, so having similar LGPLv3 exception is not needed.

Yours,

Tuukka

> Thanks,
> 
> BR
> 
> Benjamin Terrier
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] 5.8 Features?

[Tuukka Turunen]

> -Original Message-
> From: Interest [mailto:interest-bounces+tuukka.turunen=qt.io@qt-
> project.org] On Behalf Of Jason H
> Sent: maanantaina 27. kesäkuuta 2016 21.15
> To: "Daniel França" 
> Cc: interest@qt-project.org
> Subject: Re: [Interest] 5.8 Features?
> 
> 
> Could we possibly come up with a "mobile features" priority list
> and help focus what gets delivered?
> 

That would be very much welcome. It is possible to make suggestions in the 
bugreports.qt.io JIRA for new features. If there already exists a suggestion, 
it is possible to vote for the implementation of the feature.

I do personally believe that a lot of the same value that Qt has as a solid c++ 
toolkit for creating large scale enterprise desktop applications holds true 
also for large scale mobile applications. If you have a large team developing 
with some of the mobile only frameworks over a long period of time, maintenance 
can become a burden. Now, for independent developers it may be a bit less 
challenging, but having a solid and well structured (Qt) framework should 
benefit in the non-trivial applications. 

As I wrote earlier to this thread, we have invested quite a lot into mobile 
lately, but perhaps not visible enough. For example, the WinRT / Windows 10 
support has been created from scratch in the past couple of releases. For many 
focusing to Android and iOS only that probably does not matter, but from the 
whole picture it is important for Qt. Also the creation on lightweight Qt Quick 
Controls 2 as well as renewal of the HighDPI/scalability support have been big 
and important tasks.

Yours,

Tuukka

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] 5.8 Features?

[Tuukka Turunen]

> -Original Message-
> From: Interest [mailto:interest-bounces+tuukka.turunen=qt.io@qt-
> project.org] On Behalf Of Michael R Nelson
> Sent: keskiviikkona 22. kesäkuuta 2016 19.11
> To: interest@qt-project.org
> Subject: Re: [Interest] 5.8 Features?
> 
> I have to say I completely agree with Jason's sentiment here. I'm a
> commercial customer since early Qt 5.0. I bought with the belief mobile
> support would continue to grow, and not require me to step into native
> platform coding, nor require me to build custom versions of Qt to get around
> shortcomings that never get fixed.
> 

Hi,

Perhaps the pace has been slower than you wanted, or maybe the developed items 
different, but the mobile support of Qt has developed steadily with each 
release. Not only are we keeping pace with the mobile developments supporting 
new platform versions as they are available, but there has also been steady 
increase of the API parity and maturity. One of the big investments benefiting 
mobile has been to support WinRT / Windows 10, which of course does not benefit 
those who are only interested in iOS or Android. Qt is well committed in 
keeping and improving the position as the leading cross-platform toolkit across 
desktop-mobile-embedded. 

Yours,

Tuukka


> Mike
> 
> -Original Message-
> From: Interest [mailto:interest-bounces+mnelson=sutron.com@qt-
> project.org] On Behalf Of Jason H
> Sent: Wednesday, June 22, 2016 9:40 AM
> To: Sze Howe Koh 
> Cc: interest@qt-project.org
> Subject: Re: [Interest] 5.8 Features?
> 
> 
> > Subject: Re: [Interest] 5.8 Features?
> >
> > On 22 June 2016 at 09:34, Thiago Macieira 
> wrote:
> > >
> > > On terça-feira, 21 de junho de 2016 22:55:07 PDT Jason H wrote:
> > > > I feel like the last few releases have been run by the trolls, and
> > > > not the users of Qt. I was hoping open governance would enable the
> > > > community to direct Qt development, but I seem to have
> misinterpreted what it means.
> >
> > See https://wiki.qt.io/The_Qt_Governance_Model
> >
> > "Open governance" means that all members of the community can raise
> > proposals and vote on them. It is also a meritocratic system (as
> > opposed to democratic), which means more weight is given to members of
> > higher rank. Put simply, rank is gained through contributions and
> > commitment to the Qt Project.
> 
> Where and when does this voting occur? I've been vocal about improving Qt
> on mobile since mobile was an option. I've been hardcore on the
> shortcomings for about 20 months. During that time, I saw 5.6 get released,
> 5.7 get released at the same time as 5.6.1, and a lot of meaningless (to me)
> modules added. And now 5.8 is only 1.5 months from 5.7? What_the_hell?
> I'd like to see Qt complete it's mobile initiative.
> 
> As for contributing, the past 20 months I've been under _multiple_
> commercial licenses, one that was paying for a Desktop just to use Qt Charts.
> I think that's pretty material.
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
> 
> Please be advised that this email may contain confidential information. If you
> are not the intended recipient, please notify us by email by replying to the
> sender and delete this message. The sender disclaims that the content of
> this email constitutes an offer to enter into, or the acceptance of, any
> agreement; provided that the foregoing does not invalidate the binding
> effect of any digital or other electronic reproduction of a manual signature
> that is included in any attachment.
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Graphical edition of state machines in QT

[Tuukka Turunen]

Hi,

With the new Qt SCXML module you need to use an external editor that can output 
SCXML format, or edit manually your SCXML state machine description. 

Yours,

Tuukka

> -Original Message-
> From: Interest [mailto:interest-bounces+tuukka.turunen=qt.io@qt-
> project.org] On Behalf Of Yuvraaj Kelkar
> Sent: keskiviikkona 15. kesäkuuta 2016 11.44
> To: Interests Qt 
> Subject: Re: [Interest] Graphical edition of state machines in QT
> 
> +1 for question, I'd like to know as well.
> I've always used dia to draw the state machine and then coded it by hand.
> A wysiwyg state machine editor or code generator would have been nice.
> 
> -Uv
> 
> On Wed, Jun 15, 2016 at 1:28 AM, Willy Lambert 
> wrote:
> > Hi all,
> >
> > I'd like to use state machines to implement some of my behaviors. Is
> > there any graphical WYSIWIG editor for state machines in QT (or any
> > side well known project) ?
> >
> > As far as I know the state machine API [1],is not the way to go as [2]
> > would be a better direction in recent versions (according to [3]). As
> > I'm working with version 4.x of QT, solutions for the state machine
> > API [1] are preferred.
> >
> > [1] http://doc.qt.io/qt-5/statemachine-api.html
> > [2] http://doc.qt.io/qt-5/qtqml-statemachine-qmlmodule.html
> > [3]
> > http://lists.qt-project.org/pipermail/development/2016-January/024281.
> > html
> >
> > Regards
> >
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
> >
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest