[Interest] Qt free software policy

Thiago Macieira thiago.macieira at intel.com
Sat Aug 17 07:34:21 CEST 2019


On Friday, 16 August 2019 14:49:38 PDT Roland Hughes wrote:
> > No, don't. That is not receiving security fixes.
> 
> That's exactly what is happening in many places and it should be done. A
> number of shops have their own forks of 4.8, some have shared forks.

And that's great, that's their right under open source licences and I'm glad 
they're exercising it. But the most important fact in your entire email is 
"they have shared forks". That means there is active development between some 
companies, who fix the issues that are important to them, including any 
security ones that can exist.

> "not receiving security fixes" is a bit of FUD. I'm not challenging you
> or calling you a liar, it just is a bit of FUD. For many (possibly most)
> embedded systems, at least in the FDA regulated world, it does not apply.

Not exactly FUD. It is a fact that the official Qt 4.8 is not receiving 
security fixes nor any analysis to see if there are security issues that need 
fixing. The one that your customers and acquaintances have does not appear to 
be public. Even if it were, the fact that they are securing it only for the 
conditions you outlined in your email, which are quite strict, would mean it's 
not suitable for the general public.

> To start with, there is no version of OpenSSL which is secure. Whoever
> is using Qt just because it makes using SSL easy(ier) shouldn't be using
> Qt anyway because they are releasing an insecure app they incorrectly
> feel is secure.

That's very disingenuous.

There's very little software that can be proven by mathematical means that it 
is secure beyond a doubt. Complex software like Qt, OpenSSL, Linux kernel, and 
99.999% of all the software can't. Instead, security is practiced --among 
other things-- by quickly fixing what is known, when it is known, Under those 
guidelines, the last version of OpenSSL is secure *as far as we know it*.

More importantly, any past version is *known* to be have security issues. 
Whether those issues affect your product or not, only you can determine. So, 
yes, removing networking capabilities mitigates quite a lot.

> Pretty much everyone should be falling back to Qt 4.8 and staying there
> until this ex-wife alimony licensing mentality gives Qt yet another new
> owner. 99.9999999% of all companies refuse to pay royalties. No,
> negotiating an up-front buy out for a license isn't paying royalties.
> That's what my last customer did, but it was touch and go. They were
> ready to kick Qt to the curb despite all of the proof of concept work
> done with it.

You may want to cut back on your exaggeration. You're off reality by a few 
orders of magnitude. 

[99.9999999% = 1 in one billion, my 99.999% is only 1 in ten thousand]

> While we are on the royalty topic I'm fielding an increasing number of
> contacts from companies looking for Qt consultants willing to port
> projects OFF Qt because of the licensing.

That's a shame.

For me, I can only hope that the Qt Company knows what it is doing. I don't 
doubt you're right that there are a lot of companies that don't want to pay 
according to the Qt Company's fee schedule. There are two questions that they 
need to answer:
 1) does this fee schedule allow for growth of their business, engineering 
    team and ecosystem?
 2) is there a better, viable alternative?

During Nokia days, there was a better alternative because the income wasn't 
tied to licensing. I don't think the only other source of income (consulting) 
is sufficient to make it an option.

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






More information about the Interest mailing list