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

[Roland Hughes]

On 4/2/20 5:00 AM, Tuukka Turunen wrote:
> 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.

No, that was never the point of this thread.

     > 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.

That was the point of this thread. The rest was determining the scope 
because "project" and "company" were tossed around interchangeably.

As to "not answering questions" I assume that was my very relevant 
question about Thiago. If one or more developers at some obscure Intel 
office buy a commercial Qt license does Thiago now have to pay for the 
privilege of working for free?

I haven't noticed an actual answer to that.

As to having all developers on a project using the same IDE, this 
happens almost constantly. In some large companies they let developers 
working on different parts of the project use whatever editor they like 
and they end up with problems. I'm talking about more than just TAB 
sizes and settings.

Code templates come to mind. While in C/C++ world most of these tend to 
be the differing legaleeze comment blocks inserted at the top of Header 
and Source files for other languages they are more involved. Trying to 
keep them consistent across multiple IDEs is a serious issue in the 
medical device world. You can't just paste them in at the end because of 
the formal FDA review process. They had to be in the code and verified 
before QA began formal testing.

Artistic Style (or whatever) coding style enforcement. Many shops use 
the BAAR Standard. If you are using multiple IDEs with multiple hooks 
and required names/locations for the style file they inevitably get out 
of sync and you fail the formal external review, or worse, introduce a 
sleeping bug. Contrary to popular belief those things aren't there just 
to make the code look pretty. Many are there to expose sleeping bugs.

if (a==0)

     do_something();

     do_something_else();

When you use the style manager and BAAR Standard of forcing {} around 
single line blocks it becomes obvious that do_something_else() is 
outside of the if. The indenting seems to indicate someone got in a 
hurry and meant for both to be part of the if. Depending on what 
do_something_else() does this could be a bug that sits out there for 
years in production until it kills someone. Hopefully it does something 
really important and gets caught during formal testing, but I've seen 
too much of this to believe that.

For a time there was a Qt plug-in for Eclipse. Many shops standardized 
on Eclipse, not because it was great, but because it worked well for the 
board level people writing firmware, the device driver developers, and 
with that plugin, well enough for the Qt developers. This meant you 
could formally enforce the coding standards and TAB definitions across 
an entire project. Other shops standardized on Emacs (pre-doxygen wide 
acceptance days) because the word processing capabilities combined with 
template text files that would prompt users for template values when 
creating the document shell, made it easy to keep their project 
documentation complete and in the same source management library.

To really comprehend the importance of this you need to have worked on 
projects in a regulated industry having 50-60 developers. Keeping things 
in sync is mandatory for that approval step where an independent company 
must be able to recreate your development environment from your 
documentation and build your system for deployment. That's an actual 
requirement. For those watching the U.S. News and the invocation of The 
War Powers Act, you can now understand why it exists.

https://www.autoblog.com/2020/03/18/coronavirus-ford-gm-could-build-ventilators/

Automobile manufacturers are being pressed into service to build 
ventilators. They have factories and workers but no medical device 
knowledge. Because of that requirement, in a scant couple of weeks, they 
will be able to build ventilators at the same speed they build Buicks 
and SUVs. Expect a similar order to come down soon for battery powered 
infusion pumps so patients who just need liquid drugs and other fluids 
combined with bed rest can be sent home, freeing up hospital beds and 
reducing hospital risk.

The other question I haven't seen a clear answer on which Andy and 
myself both asked is what about the tools developed with OpenSource Qt 
that are typically used in many software development processes. If part 
of the team has licensed Qt and the other part of the team cannot then 
use the OpenSource IDE because of it, what about these tools?

Can a commercially licensed developer use KDE Neon as their development 
platform or must they all now use a non-KDE desktop due to KDE being 
developed with OpenSource Qt?

There used to be quite a few OpenSource IDE's and plugins for Qt 
development. Each had various levels of goodness and badness to them. As 
QtCreator got better, these projects basically died. There was no reason 
to have multiple OpenSource IDEs for Qt now that the main one had gotten 
good. Do these projects have to be rebooted so there can be a single IDE 
can be used in medical device manufacturing?

I'm asking because these are serious issues in the worlds where I walk. 
The majority of these companies will not pay royalties so it means we 
have to use something other than Qt when creating the device if the 
lawyers cannot figure out the commercial licensing to a level they feel 
comfortable having us move forward with OpenSource. For the 
manufacturers who stopped at 4.8 or earlier OpenSource, this is less of 
an issue but it is still an issue.

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

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog