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
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
