Re: [Interest] Qt free software policy

[Jérôme Godbout]

1) Compilation method which removes 100% of QML, including QML support from 
non-QML classes.

> While my correct views of QML are widely known, the reality is that many 
> embedded and IoT systems have no UI or correctly choose not to use QML 
> because they are running on battery without a GPU. Unless these systems fall 
> back to a pre-QML version of Qt, they cannot get rid of the buggy baggage.

If you design your software right nothing in Qml should be seen into your C++ 
except the module registration. Your C++ code expose to the meta object with 
properties and signal and that's about it.Qml use the meta exposition, you can 
still use the meta calls without Qml. This is one thing I really like about 
Qml, it doesn't invade the application code, it sit above it and you can use 
the javascript for view model adaptor/converter. I have give up on QWidget and 
looking at my code base now I would not go back, the automatic binding re 
evaluation is such a connect() call saver. 

-Original Message-
From: Interest  On Behalf Of Roland Hughes
Sent: August 22, 2019 11:21 AM
To: interest@qt-project.org
Subject: Re: [Interest] Qt free software policy


On 8/22/19 5:00 AM, James Ross-Smith wrote:
> This a quite a timely thread, as I, like several others in here, am 
> trying to decide on a Commercial or non-Commercial licensing approach with Qt.
> I've submitted numerous contact/quote/trial requests on the TQtC 
> website over the last couple of weeks but never hear back, so it's 
> very helpful to stumble across this discussion.

You are welcome. We do try to be of assistance in here.

To answer the other question I didn't cut and paste . . . For whatever reason 
Qt Company didn't follow the Cannonical (Ubuntu) model. The ex-wife alimony 
fixation on royalties makes me believe they have a whole lot of Dire Straights 
Syndrome going on.

https://www.youtube.com/watch?v=JRDgihVDEko

While it was a great tune, it was not a good business model.

I just finished up at a client site where commercial license was purchased. I 
wasn't there or it never would have happened as they certainly had no need for 
the "latest" anything. Be that as it may, the negotiations started and happened 
many states away.

The way our "support" was explained to me by our boss was this (it might be 
different for every negotiation):

"If we have trouble with installation of the development software, 
configuration of the development environment or cross compiling for the target 
system we can call and get help right away. If we find a bug we have to file a 
bug report and get in the queue with everyone else."

When someone mentions "software support" a large chunk of the industry, 
especially those of us who are older and have worked on large systems from 
Digital Equipment Corporation, Oracle, IBM, etc., we expect a sev-level 
escalation tree. You start somewhere down at the 4 or 5 level (normally the 
bottom) and unresolved problems keep getting kicked up the tree until it 
becomes a sev-1 (it can start at sev-1 if you have a complete production 
outage). At sev-1 the vendor assembles a trauma-1 team which generally includes 
one or more of the developers who actually developed the particular piece of 
hardware or software which is suspect.

Mileage may vary, but that has not been my experience in the Qt world. I 
believe that is partially due to the distributed (OpenSource) nature of the 
development. There are big chunks of Qt which Qt Company had basically nothing 
to do with. I'm thinking the 3-D stuff might be a good example given a message 
thread on this list from some months back. A company of some size, be it one or 
more, developed the package and donated some or all of it to the community. 
Unless Qt Company was to pay that company for sev-level support, how could Qt 
Company ever provide support for it? Sure, coders who never wrote any of it 
could dig through the code and hopefully find something, but that's not exactly 
the level of support one thinks of when they hear "support contract."

A much larger part of the issue has been, in my opinion, not sufficiently 
pursuing a large embedded systems consulting group. I'm talking about an 
embedded system in a box type consulting company where they could do project 
level stuff from hardware design all the way through setting up factory 
production. When people "went to the bench" 
they would be working on Qt itself and providing support. This is how the old, 
successful, companies did it. Albeit they were working on mid-range and 
mainframe systems at the time.

The "device in a box" type companies are growing at alarming rates. Once they 
bring in the correct heavy hitters (both high architectural level and low 
firmware/algorithm level) they go from startup to nearly $20Million in just a 
couple of years. The one problem

Re: [Interest] Qt free software policy

[Roland Hughes]

On 8/23/19 1:59 AM, Kai Köhne wrote:

-Original Message-
From: Interest  On Behalf Of Roland
Hughes
[...]
The way our "support" was explained to me by our boss was this (it might be
different for every negotiation):

"If we have trouble with installation of the development software,
configuration of the development environment or cross compiling for the
target system we can call and get help right away. If we find a bug we have to
file a bug report and get in the queue with everyone else."

That's not true (unless "everyone else" means all people with the same support 
level). The people in Qt support will also try to directly provide you with a patch 
and/or workaround, if possible. Also the internal development teams in the Qt Company 
will prioritize bugs coming from commercial customers. That's why it's actually advised 
to file a bug through Qt Support, or at least inform Qt Support that you filed a bug in 
JIRA if you are a commercial customer.


Prioritize != Ride Bug to Extinction

At some point I expect "that guy again" to chime in here about the 
REGRESSION bugs he filed which have been rotting for years. Their bits 
may have turned to dust by now.


I always have trouble communicating this to people who have never worked 
with real computers. They have no concept of what real sev-level support 
is. They believe throwing bugs into JIRA and watching them age like 
Bourbon is "support." It can't even buy a ticket to watch real support 
happen.


My first IT job was a midnight computer operator at Airfone, Inc. They 
put credit card telephones in airplanes long before anyone had cell 
phones. They were dead broke from building all of the ground stations 
and installing the phones we had installed. Had even missed payroll so 
we were all working for free. The only bill which was religiously paid 
was our sev-level support contract with DEC.


It was about 11:30 at night when we had a major outage. I forget what it 
was. I called the systems analyst who had me boot/load the Colorado 
software on the system console. Then phone in to the Colorado voice 
support line.


I was on the phone with Colorado when I had to set the phone down to 
sign for someone with the security guard. The person I had to sign in 
was from DEC support. Colorado had dispatched them from a regional 
office once their diagnostics firmware identified the problem area from 
the OPCOM and AUDIT logs.


He stayed until some time after 4a.m. We were fully functional when he left.

I wasn't on-site for this one but worked with the individual who was. He 
used to love telling me this story.


When Oracle first introduced RAC it was an even bigger hand polished 
turd than QML. I know that is difficult to wrap one's mind around if 
you've been exposed to QML, but, there it is.


Oracle convinced a major downstate heavy equipment manufacturer to roll 
out a new critical system based on Oracle RAC on some flavor of *nix 
instead of basing it on the already proven RDB running on OpenVMS.


The only OS then or now which well and truly clusters is OpenVMS. 
Everything else claims whatever sad and pathetic thing they are capable 
of, clustering. It's as night and day different as real support and 
filing a JIRA ticket.


This system was production critical when it went online. The database 
was completely corrupted multiple times. I'm told Oracle had an entire 
team on-site for weeks, all as part of the support contract.


Big companies are willing to take big chances on unproven technologies 
when they can get sev-level support. "Filing a ticket" isn't sev-level 
support. When there is no written promise that however many bodies 
necessary will be allocated 100%, even on-site 100% when needed, all as 
part of the support contract, it isn't sev-level support.


Here's another one I was on-site for.

Payroll conversion project at Quaker Oats. They were kicking ADP to the 
curb and bringing payroll in-house with PeopleSoft. All of the mills and 
plants were still running Cyborg payroll. The feed from Cyborg had to 
create a different file for transmission to PeopleSoft at the corporate 
office. At the time Cyborg was 1970s style COBOL using the card format 
with line numbers and it was distributed in source. They also had their 
own "4GL" called Generator which was supposed to be platform independent 
but used COBOL underneath.


Someone, whom I can only assume is either the worst human being ever or 
the most unfortunate one, worked at one of the east coast pet food 
factories. The exact number escapes me. I can't remember if it was 25 or 
27 wage garnishments they had, just that it was north of 20 and one more 
than the Cyborg payroll system could handle. It crashed payroll. Factory 
workers tend to live paycheck to paycheck and nobody was getting paid 
until that bug was fixed.


Cyborg sent the head or one of the head/lead developers to our office. 
He patched the software with us sitting there. We compiled it, tested 
it, and payro

Re: [Interest] Qt free software policy

[Kai Köhne]

> -Original Message-
> From: Interest  On Behalf Of Roland
> Hughes
> [...]
> The way our "support" was explained to me by our boss was this (it might be
> different for every negotiation):
> 
> "If we have trouble with installation of the development software,
> configuration of the development environment or cross compiling for the
> target system we can call and get help right away. If we find a bug we have to
> file a bug report and get in the queue with everyone else."

That's not true (unless "everyone else" means all people with the same support 
level). The people in Qt support will also try to directly provide you with a 
patch and/or workaround, if possible. Also the internal development teams in 
the Qt Company will prioritize bugs coming from commercial customers. That's 
why it's actually advised to file a bug through Qt Support, or at least inform 
Qt Support that you filed a bug in JIRA if you are a commercial customer.

https://www.qt.io/qt-support/


Kai

--
Kai Köhne, Senior Manager R&D | The Qt Company

The Qt Company GmbH, Erich-Thilo-Str. 10, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, 
HRB 144331 B
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt free software policy

[Roland Hughes]

On 8/22/19 5:00 AM, James Ross-Smith wrote:

This a quite a timely thread, as I, like several others in here, am trying
to decide on a Commercial or non-Commercial licensing approach with Qt.
I've submitted numerous contact/quote/trial requests on the TQtC website
over the last couple of weeks but never hear back, so it's very helpful to
stumble across this discussion.


You are welcome. We do try to be of assistance in here.

To answer the other question I didn't cut and paste . . . For whatever 
reason Qt Company didn't follow the Cannonical (Ubuntu) model. The 
ex-wife alimony fixation on royalties makes me believe they have a whole 
lot of Dire Straights Syndrome going on.


https://www.youtube.com/watch?v=JRDgihVDEko

While it was a great tune, it was not a good business model.

I just finished up at a client site where commercial license was 
purchased. I wasn't there or it never would have happened as they 
certainly had no need for the "latest" anything. Be that as it may, the 
negotiations started and happened many states away.


The way our "support" was explained to me by our boss was this (it might 
be different for every negotiation):


"If we have trouble with installation of the development software, 
configuration of the development environment or cross compiling for the 
target system we can call and get help right away. If we find a bug we 
have to file a bug report and get in the queue with everyone else."


When someone mentions "software support" a large chunk of the industry, 
especially those of us who are older and have worked on large systems 
from Digital Equipment Corporation, Oracle, IBM, etc., we expect a 
sev-level escalation tree. You start somewhere down at the 4 or 5 level 
(normally the bottom) and unresolved problems keep getting kicked up the 
tree until it becomes a sev-1 (it can start at sev-1 if you have a 
complete production outage). At sev-1 the vendor assembles a trauma-1 
team which generally includes one or more of the developers who actually 
developed the particular piece of hardware or software which is suspect.


Mileage may vary, but that has not been my experience in the Qt world. I 
believe that is partially due to the distributed (OpenSource) nature of 
the development. There are big chunks of Qt which Qt Company had 
basically nothing to do with. I'm thinking the 3-D stuff might be a good 
example given a message thread on this list from some months back. A 
company of some size, be it one or more, developed the package and 
donated some or all of it to the community. Unless Qt Company was to pay 
that company for sev-level support, how could Qt Company ever provide 
support for it? Sure, coders who never wrote any of it could dig through 
the code and hopefully find something, but that's not exactly the level 
of support one thinks of when they hear "support contract."


A much larger part of the issue has been, in my opinion, not 
sufficiently pursuing a large embedded systems consulting group. I'm 
talking about an embedded system in a box type consulting company where 
they could do project level stuff from hardware design all the way 
through setting up factory production. When people "went to the bench" 
they would be working on Qt itself and providing support. This is how 
the old, successful, companies did it. Albeit they were working on 
mid-range and mainframe systems at the time.


The "device in a box" type companies are growing at alarming rates. Once 
they bring in the correct heavy hitters (both high architectural level 
and low firmware/algorithm level) they go from startup to nearly 
$20Million in just a couple of years. The one problem all of them seem 
to have is pursuing 100% billable time for all employees. If you are a 
100% billable you are 100% failure, it just may take you a while to 
realize it. Really successful ones rarely exceed 60% billable for a 
year. Skills enhancement. Pre and post sales customer hand holding. 
Numerous things which must happen aren't billable. If you are 100% 
billable then you aren't doing those things. Employees will only learn 
new skills on their own time and at their own expense for a short while.


Where Qt Company could thrive here is focusing on "no more than 60% 
billable" with the rest of the time spent on Qt bug fixes, support and 
new Qt development. What they would gain is an actual industry 
perspective, not one which was created from reading surveys with an 
agenda so their outcome was predetermined.


From that real world perspective they would learn the reality of things 
which have been asked for by others in this mailing list for a very long 
time and some new ones.


1) Compilation method which removes 100% of QML, including QML support 
from non-QML classes.


While my correct views of QML are widely known, the reality is that many 
embedded and IoT systems have no UI or correctly choose not to use QML 
because they are running on battery without a GPU. Unless these systems 
fall

Re: [Interest] Qt free software policy

[James Ross-Smith]

This a quite a timely thread, as I, like several others in here, am trying
to decide on a Commercial or non-Commercial licensing approach with Qt.
I've submitted numerous contact/quote/trial requests on the TQtC website
over the last couple of weeks but never hear back, so it's very helpful to
stumble across this discussion.

On Thu, Aug 22, 2019 at 3:37 AM Adam Light  wrote:

> On Wed, Aug 21, 2019 at 7:17 AM Matthew Woehlke 
> wrote:
>
>> On 14/08/2019 16.22, John Weeks wrote:
>> > We are a small company selling a very large and complex application
>> which is now based on Qt open source. At the time we first considered
>> porting to Qt (version 4.3?) the license was very expensive for small
>> company (six programmers) and the evaluation period simply wasn't adequate
>> to deciding if it was the right way to go. So we went open-source when it
>> became available when Nokia took over.
>> >
>> > Since then, we have wished that we had a commercial license in order to
>> get a bit more traction on some bugs. The Qt Company wanted us to pay for
>> all the  licensing that had accrued since we started using the LGPL
>> version. That up-front cost is prohibitive, so we haven't done it.
>>
>> Does TQtC *not* sell commercial-level *support* without the additional
>> commercial licensing rights (and retroactive costs)? If not, that seems
>> like an idiotic missed opportunity...
>>
>>
> If I recall correctly, we looked into this a few years ago and the answer
> was no. So we hired one of the big Qt consulting firms to work on an issue
> for us instead. Since we don't actually have any need for the commercial
> license (LGPL is just fine for what we use Qt for) there's really no
> incentive for us to purchase a commercial license other than for the
> support, but the pricing on the commercial license was close to an order of
> magnitude more than the value of the support we would get (again, this was
> years ago, so perhaps things have changed).
>
> Adam
> ___
> 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

[Adam Light]

On Wed, Aug 21, 2019 at 7:17 AM Matthew Woehlke 
wrote:

> On 14/08/2019 16.22, John Weeks wrote:
> > We are a small company selling a very large and complex application
> which is now based on Qt open source. At the time we first considered
> porting to Qt (version 4.3?) the license was very expensive for small
> company (six programmers) and the evaluation period simply wasn't adequate
> to deciding if it was the right way to go. So we went open-source when it
> became available when Nokia took over.
> >
> > Since then, we have wished that we had a commercial license in order to
> get a bit more traction on some bugs. The Qt Company wanted us to pay for
> all the  licensing that had accrued since we started using the LGPL
> version. That up-front cost is prohibitive, so we haven't done it.
>
> Does TQtC *not* sell commercial-level *support* without the additional
> commercial licensing rights (and retroactive costs)? If not, that seems
> like an idiotic missed opportunity...
>
>
If I recall correctly, we looked into this a few years ago and the answer
was no. So we hired one of the big Qt consulting firms to work on an issue
for us instead. Since we don't actually have any need for the commercial
license (LGPL is just fine for what we use Qt for) there's really no
incentive for us to purchase a commercial license other than for the
support, but the pricing on the commercial license was close to an order of
magnitude more than the value of the support we would get (again, this was
years ago, so perhaps things have changed).

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

Re: [Interest] Qt free software policy

[Matthew Woehlke]

On 14/08/2019 16.22, John Weeks wrote:
> We are a small company selling a very large and complex application which is 
> now based on Qt open source. At the time we first considered porting to Qt 
> (version 4.3?) the license was very expensive for small company (six 
> programmers) and the evaluation period simply wasn't adequate to deciding if 
> it was the right way to go. So we went open-source when it became available 
> when Nokia took over.
> 
> Since then, we have wished that we had a commercial license in order to get a 
> bit more traction on some bugs. The Qt Company wanted us to pay for all the  
> licensing that had accrued since we started using the LGPL version. That 
> up-front cost is prohibitive, so we haven't done it.

Does TQtC *not* sell commercial-level *support* without the additional
commercial licensing rights (and retroactive costs)? If not, that seems
like an idiotic missed opportunity...

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

Re: [Interest] Qt free software policy

[Thiago Macieira]

On Monday, 19 August 2019 00:28:37 PDT Vadim Peretokin wrote:
> Which was actually a very, very bad surprise that was pretty poorly
> documented. Please don't do that again.

We should have made the change before 5.12 come out, since we were already 
aware of OpenSSL's timelines at that point. It just didn't occur to us that we 
needed to pay attention to that detail.

We'll try to ensure we don't make the same mistake in 5.15.

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

Re: [Interest] Qt free software policy

[Roland Hughes]

On 8/19/19 5:00 AM, Thiago Macieira wrote:

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.

Honestly, it is a_completely_  accurate statement. Hopefully you had
time to watch the "60 Minutes" report on "Pegasus" tonight.

https://www.cbsnews.com/video/ceo-of-israeli-spyware-maker-nso-on-fighting-t
error-khashoggi-murder-and-saudi-arabia-60-minutes/

You're going from disingenuous to actively counterproductive.
No, I'm being highly productive. I'm sorry if it is an inconvenient 
truth, but SSL is not secure. Too many in here are buying the BS in the 
name "Secure Socket Layer" and knee-jerk using it then claiming their 
application is "secure." The truth is they haven't even attempted security.


We know OpenSSL has problems. My point is that all problems are fixed as soon
as they are known. We can't prove mathematically that there are no problems,
so the best we can do is fix as soon as possible and upgrade.
It has an architectural flaw which cannot be fixed. Flaws in OpenSource 
have a history of going multiple decades before being outed to the 
general public (ala the Bash bug which allowed anyone with access to a 
Guest account to become root user on the machine.)


And there's no better option.


There are many better options. None of them are one and done unless you 
purchase a security package of some sort, be it a private VPN or a 
library which allows your app to create its own private VPN.


For the no-license-no-money you have to roll your own rotating book code 
and recipe servers. No two packets in any transmission use the same key. 
No consecutive packets use the same encryption. Taking it to the 
extreme, none of the data is sent complete or logically grouped. At the 
end of each book is the server and creds to obtain the next book. Please 
don't confuse "book" with there being a requirement for using an actual 
published book.




I never claimed that using OpenSSL will make your software magically secure.


No you haven't and thank you for that. Others, two in particular who 
know less than nothing about most things, especially security, have made 
such a claim to someone who actually asked the question. Others will 
find that thread, read it, and release an insecure system.




The crypto itself has never been broken.


That would be an incorrect statement.



Quick note: before reading any patents, consult your lawyer.

Actually, I have the lawyer read the patents. 

I somehow think that 25 years of knowledge of the segment and close
relationship with very big consulting companies like KDAB and ICS would have
told them if it was enough.

So I think you're wrong. You're probably underestimating how much money they
could make off consulting alone.


No. I'm thinking your definition of "very big" needs to be upgraded. 
Assuming


https://www.kdab.com/

https://www.owler.com/company/kdab

Estimated Annual Revenue
$ < 1M

I consider the one I like to deal with "small"

https://www.tripleco.com/

https://www.owler.com/company/tripleco

Estimated Annual Revenue
$16.2M

Having said that, I can say that the "consulting" services provided to 
one of my clients before I joined the project (at no small fee) 
attempted to use a state machine (because it was brand new) to solve a 
problem which was so completely inappropriate for a state machine even a 
first year IT student wouldn't have tried to use it. The code, if 
printed on Charmin, still wouldn't have served a purpose.


The reason I bring that up is that yes, if that is the level of 
"consulting" the "new" owners of Qt are still providing they won't earn 
a plug nickle and rightly so.




PS: Electron, containing Chromium, has FAR MORE licenses inside than Qt.
Including a copy of FFMPEG, which contains multimedia codecs that may be
patented.


Yeah, but the Script Kiddies creating idiot phone apps never bother 
reading them. They just hack something out and hurl it up on the Google 
App store, firmly believing that Google, the largest copyright infringer 
and book pirate in the known universe (google books) won't press the 
issue. If they do then it is possible that __finally__ Google execs and 
board of directors will go to prison where they should very well be.


PS. The Internet Archive is now attempting to take the copyright 
infringement and piracy crown from Google.


http://www.interestingauthors.com/blog/publishing/controlled-digital-lending-book-piracys-new-name/


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com

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

Re: [Interest] Qt free software policy

[Vadim Peretokin]

Which was actually a very, very bad surprise that was pretty poorly
documented. Please don't do that again.

We saw the openssl change and didn't think anything big of it - well, it
turned out that a minor upgrade to an TLS release completely broke secure
web downloads, secure TLS connections, and our updater: so our software
self-upgraded to a version it can't self-upgrade from. Horribly nasty
experience all in all :( there should have been a bigger warning on this.

On Mon, Aug 19, 2019 at 2:06 AM Hamish Moffatt 
wrote:

> On 15/8/19 6:28 am, Thiago Macieira wrote:
> > PS: Qt 5.12 will switch to OpenSSL 1.1 in the binary builds.
>
>
> Indeed 5.12.4 already did.
>
>
>
> Hamish
>
> ___
> 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

[Thiago Macieira]

On Sunday, 18 August 2019 17:16:17 PDT Roland Hughes wrote:
> >> 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.
> 
> Honestly, it is a _completely_ accurate statement. Hopefully you had
> time to watch the "60 Minutes" report on "Pegasus" tonight.
> 
> https://www.cbsnews.com/video/ceo-of-israeli-spyware-maker-nso-on-fighting-t
> error-khashoggi-murder-and-saudi-arabia-60-minutes/

You're going from disingenuous to actively counterproductive.

We know OpenSSL has problems. My point is that all problems are fixed as soon 
as they are known. We can't prove mathematically that there are no problems, 
so the best we can do is fix as soon as possible and upgrade.

And there's no better option.

I never claimed that using OpenSSL will make your software magically secure. 
Flaws elsewhere in your software or in other software can be attack vectors 
and bypass the best security that OpenSSL can provide.

I'm saying that using an old version that has known security issues would be 
irresponsible (unless you mitigated them yourself).

> There are others out there which cut through SSL like a hot knife
> through warm butter.

Indeed. Almost all attacks against SSL have been side-channel attacks of one 
form or another. The crypto itself has never been broken.

But that's not a reason to throw your arms up and give up.

> You can create your own without an ocean of effort. I've explained _how_
> to do it several times in this group. JUST BE SURE TO READ THE PATENTS
> BEFORE YOU RELEASE ANYTHING.

Quick note: before reading any patents, consult your lawyer.

> > 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.
> 
> It could/would/should be but from what I've seen Qt Company has no idea
> how to do it. There are thousands of consulting companies scanning job
> boards and slapping Qt consultants like me into very profitable
> projects. I've been working with one (mostly) for close to a decade now.
> They keep opening new offices in new cities. Gotta pay that rent somehow.

I somehow think that 25 years of knowledge of the segment and close 
relationship with very big consulting companies like KDAB and ICS would have 
told them if it was enough.

So I think you're wrong. You're probably underestimating how much money they 
could make off consulting alone.

> Getting back the actual topic of this particular thread though, besides
> the relentless ex-wife grubbing for alimony commercial licensing
> situation, the mish-mash of OpenSource licensing is really killing Qt as
> an option at companies who don't have an in-house legal department. Most
> who talk to me about it take one look at the pages which have been
> linked in this thread and say "that's it, we'll use Electron or
> insert-competitor-here."

I wouldn't mind a simpler. clearer model.

> Most everybody wants one single license to read. At 2 they start tuning
> out, at 3 they quit.

Right,

PS: Electron, containing Chromium, has FAR MORE licenses inside than Qt. 
Including a copy of FFMPEG, which contains multimedia codecs that may be 
patented.

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

Re: [Interest] Qt free software policy

[Roland Hughes]

On 8/18/19 5:00 AM, Thiago Macieira 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.
In many/most cases they are shared across products under the same 
mega-parent corporation or were until some units got spun-out or sold off.



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.


Honestly, it is a _completely_ accurate statement. Hopefully you had 
time to watch the "60 Minutes" report on "Pegasus" tonight.


https://www.cbsnews.com/video/ceo-of-israeli-spyware-maker-nso-on-fighting-terror-khashoggi-murder-and-saudi-arabia-60-minutes/

This is one of many, but is the most widely known. It doesn't need super 
computers, just a cheap-ass PC running as a server on the Internet. It 
can pull and decrypt _all_ of the data on any current idiot phone.


Admittedly this one typically requires a "link." Please pay close 
attention when watching the "60 Minutes" piece. Most of you have 
probably received those "DHL You have a package" emails.


There are others out there which cut through SSL like a hot knife 
through warm butter.


It is in the best interest of those using the penetration software to 
appear on every medium possible and tout the "security" of Secure Socket 
Layer. When one repeats a lie often enough even otherwise intelligent 
people will start to believe it.




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.


Actually there is quite a bit of software which is "proven" by the "Holy 
Trinity" to be completely unhackable. I don't remember the names of the 
3 companies but it's the same 3 companies using both mathematical and 
black hat physical attempts both with and without viewing source. You 
have to be blessed by all 3. This is the type of software securing the 
U.S. Passport system and at least one personal VPN.


It is not OpenSource, it is patented. At least all of the ones I've been 
exposed to are. Getting a blessing from the "Holy Trinity" is a long way 
from cheap. Lots of companies pay money and get shredded.


You can create your own without an ocean of effort. I've explained _how_ 
to do it several times in this group. JUST BE SURE TO READ THE PATENTS 
BEFORE YOU RELEASE ANYTHING.





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.999% 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.999% = 1 in one billion, my 99.999% is only 1 in ten thousand]


Before either of us can claim any high ground there we need to define 
"companies." I'm including every 12 year old Script Kiddie who hurls a 
completely insecure idiot phone app up to any app store which will let 
them. They are using Electron, Flutter and a rash of other non-royalty 
based tools. Okay, I probably should have left the last 9 off the end so 
it was one in every hundred million.



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, 

Re: [Interest] Qt free software policy

[Hamish Moffatt]

On 15/8/19 6:28 am, Thiago Macieira wrote:
PS: Qt 5.12 will switch to OpenSSL 1.1 in the binary builds. 



Indeed 5.12.4 already did.



Hamish

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

Re: [Interest] Qt free software policy

[Thiago Macieira]

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.999% 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.999% = 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



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

Re: [Interest] Qt free software policy

[Benjamin TERRIER]

Le ven. 16 août 2019 à 08:41, Tuukka Turunen  a
écrit :

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

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

[Roland Hughes]

+5

At the time I was working on the IP Ghoster project (don't remember 
year) I inquired. They wanted $5K +- _and_ royalties. There was no 
license which would allow a lone developer to deliver a project to a 
client. You had to use the client's license and the client had to pay 
royalties and having to use client provided resources gets many people 
in trouble with the I and the R and the S.



https://www.regent.edu/admin/busoff/pdf/20-questions1099test.pdf

Scroll down to number 14.


On 8/14/19 11:15 PM, David M. Cotter wrote:
i’m in a similar boat. i’m sure there are others who are NOT on this 
list who are also in the same boat.

On Aug 14, 2019, at 1:22 PM, John Weeks  wrote:

We are a small company selling a very large and complex application which is 
now based on Qt open source. At the time we first considered porting to Qt 
(version 4.3?) the license was very expensive for small company (six 
programmers) and the evaluation period simply wasn't adequate to deciding if it 
was the right way to go. So we went open-source when it became available when 
Nokia took over.

Since then, we have wished that we had a commercial license in order to get a 
bit more traction on some bugs. The Qt Company wanted us to pay for all the  
licensing that had accrued since we started using the LGPL version. That 
up-front cost is prohibitive, so we haven't done it.

Perhaps, if you are trying to nudge folks toward commercial licensing, you 
could provide a path that isn't so expensive. Or maybe you have? We haven't 
bothered to look into it lately.

-John


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com

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

Re: [Interest] Qt free software policy

[Roland Hughes]

On 8/14/19 11:15 PM, Thiago Macieira wrote:

On Wednesday, 14 August 2019 12:09:02 PDT Roland Hughes wrote:

If you do not need the latest bells and whistles, drop back to Qt 4.8

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.


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


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.


Most medical devices I've been exposed to don't even allow "the 
application" to perform any communication. Yes, a patient monitor can 
transmit but the application doesn't do it. A "Comm Module" which is not 
field flashable and is written with some other tool set, usually running 
an RTOS contains all of the communications and security. It can only 
communicate with the host which has been "burned" into it if and only if 
that host has the proper set of keys. You cannot take a vitals monitor 
from Hospital A and have it "just work" at Hospital B because it has the 
wrong "Comm Module."


A proprietary (and severely limited) API exists between the application 
and the "Comm Module." The outside world generally cannot pull data from 
the device, only announce that it is available and ready to receive. 
When "the application" sends data to the "Comm Module" it munges it up 
per the API and the "Comm Module" handles the multiple levels of 
security between itself and the paired host module.


This optical isolation is done for many reasons, not the least of which 
is that the "Comm Module" gets re-used on many different devices. When 
you want to change something in the communication (add a 7 level book 
code, 4 more encryption routines, whatever) it is an incredibly simpler 
FDA approval process. You just have to prove you didn't change the 
application API and that the "Comm Module" still communicates with the 
"Host Module."


As far as the divide by zero error mentioned later in the thread, all of 
the repeatable testing for a device will shake out if that is even in 
any execution path. Depending on where it is, those classes may not even 
be part of the application.


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


In my new book with the working title "The Phallus of AGILE and Other 
Ruminations" I have an essay titled "Royalties - Every Stupid Idea Comes 
Around Again." It's pretty good. One of the case studies used is that of 
RTLINK vs. Blinker. RTLINK was massively expensive. It had a lot of 
library functions which could make things great, but it would only 
overlay at the OBJ level. Blinker did wonderful things, was less 
expensive and would overlay at the memory page level. RLINK decided it 
wasn't making enough from its massively expensive (2-3 times the price 
of Blinker) so it went to a royalty model. RTLINK basically went under, 
got consumed by CA and rolled into Clipper before disappearing from the 
marketplace. Blinker is still being sold and used in the embedded DOS 
world today. There is even a cottage/niche desktop DOS industry.


Before anybody poo-hoos embedded DOS let me inform them that AGCO uses 
embedded DOS in pretty much all its Combines. Possibly all of their ag 
equipment, I only know about the combines designed in Kansas. They have 
a $5+ Billion market cap.


https://finance.yahoo.com/quote/AGCO/

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.


There is a 6 month gig in St. Paul, MN for a system running on RHEL 
where they are looking to dump Qt, ostensibly over the licensing. 
Swanktek is shopping the gig around for those interested. I'm not. I 
just got back from a winter project in Minnesota.



--
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com

___
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

[Thiago Macieira]

On Thursday, 15 August 2019 02:14:52 PDT Benjamin TERRIER wrote:
> 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)

Crap, the timer job to update the certificate isn't working. The Perl Net::DNS 
API changed... anyway, the cert expired yesterday, so it was down for only a 
day.

Fixed.

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

Re: [Interest] Qt free software policy

[Giuseppe D'Angelo via Interest]

Il 15/08/19 11:14, Benjamin TERRIER ha scritto:
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'd say that the decision is always going to be on a module-by-module 
basis. If you want to read something between the lines wrt TQC's 
commercial interests, feel free to do so, but that's not the Qt 
Project's policy.


My 2 c,
--
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



smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt free software policy

[Benjamin TERRIER]

Le jeu. 15 août 2019 à 09:18, Vadim Peretokin  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 
> 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

[Vadim Peretokin]

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.

On Thu, Aug 15, 2019 at 6:17 AM Tuukka Turunen  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.
>
>
>
> 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  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
>
___
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

[Thiago Macieira]

On Wednesday, 14 August 2019 14:36:18 PDT Benjamin TERRIER wrote:
> Le mer. 14 août 2019 à 22:05, Thiago Macieira  a
> écrit :
> > On Wednesday, 14 August 2019 12:17:44 PDT Benjamin TERRIER wrote:
> > > The new add-ons modules could be provided as GPLv3 + GPLv2 + LGPLv3.
> > 
> > Just a nitpick: there's no need to have GPL-3.0 and LGPL-3.0 at the same
> > time.
> > So the combinations are GPL-2.0+LGPL-3.0 and GPL-2.0+GPL-3.0.
> 
> You are right.
> However; the KDE agreement explicitly states that Qt add-ons must be
> available under GPLv3.
> So I am wondering if there could be issues with licensing under LGPLv3 but
> not under GPLv3, even if for KDE it is equivalent.

LGPL-3.0 is the GPL-3.0 plus an exception, so it counts.

I haven't read the agreement in years, but last I checked it didn't specify 
which licence, only that it had to be open source. But I may be remembering 
incorrectly.

> > I don't know if there's anything that is GPL-3.0 (without 2.0). There may
> > be.
> 
> All recent and upcoming modules, except Qt 3D, are GPLv3, but not GPLv2.

I stand corrected. Thanks (and to Peppe).

> The reason I started this thread is that I needed an http server for a Qt
> project under GPLv2,
> I started to play with the QHttpServer (still work in progress, but working
> nice) until I realized
> I would not be able to use it because it is GPLv3 only.

I understand. This is the case when you have GPL-2.0 only code that you need 
to use. Even 12 years after GPL-3.0 there's still a lot of GPL-2.0 only out 
there.

I wonder if there's a way to allow the GPL-2.0 & GPL-3.0 combination work, 
without allowing the reason that GPL-3.0 was chosen in the first place 
(bypassing the TiVo clause). Probably not, because that and the Patent clause 
are the reason why 2.0 and 3.0 are incompatible in the first place.

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

Re: [Interest] Qt free software policy

[Benjamin TERRIER]

Le mer. 14 août 2019 à 22:05, Thiago Macieira  a
écrit :

> On Wednesday, 14 August 2019 12:17:44 PDT Benjamin TERRIER wrote:
> > The new add-ons modules could be provided as GPLv3 + GPLv2 + LGPLv3.
>
> Just a nitpick: there's no need to have GPL-3.0 and LGPL-3.0 at the same
> time.
> So the combinations are GPL-2.0+LGPL-3.0 and GPL-2.0+GPL-3.0.
>

You are right.
However; the KDE agreement explicitly states that Qt add-ons must be
available under GPLv3.
So I am wondering if there could be issues with licensing under LGPLv3 but
not under GPLv3, even if for KDE it is equivalent.


> I don't know if there's anything that is GPL-3.0 (without 2.0). There may
> be.
>

All recent and upcoming modules, except Qt 3D, are GPLv3, but not GPLv2.
The reason I started this thread is that I needed an http server for a Qt
project under GPLv2,
I started to play with the QHttpServer (still work in progress, but working
nice) until I realized
I would not be able to use it because it is GPLv3 only.

BR

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

Re: [Interest] Qt free software policy

[Giuseppe D'Angelo via Interest]

Il 14/08/19 22:05, Thiago Macieira ha scritto:

I don't know if there's anything that is GPL-3.0 (without 2.0). There may be.


Quick, incomplete list, from the back of my head:

* QtVirtualKeyboard
* The WebGL QPA plugin
* The WebAssembly QPA plugin
* QtCharts

are all GPL3 (not 2).

My 2 c,

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



smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt free software policy

[Scott Bloom]

Same here.. Used to be commercial with a previous company.

Couldn’t justify the rates for commercial licenses...  And could never justify 
the "back license" fee

Scott
-Original Message-
From: Interest  On Behalf Of David M. Cotter
Sent: Wednesday, August 14, 2019 1:42 PM
To: John Weeks 
Cc: Interest 
Subject: Re: [Interest] Qt free software policy

i’m in a similar boat. i’m sure there are others who are NOT on this list who 
are also in the same boat.

> On Aug 14, 2019, at 1:22 PM, John Weeks  wrote:
> 
> We are a small company selling a very large and complex application which is 
> now based on Qt open source. At the time we first considered porting to Qt 
> (version 4.3?) the license was very expensive for small company (six 
> programmers) and the evaluation period simply wasn't adequate to deciding if 
> it was the right way to go. So we went open-source when it became available 
> when Nokia took over.
> 
> Since then, we have wished that we had a commercial license in order to get a 
> bit more traction on some bugs. The Qt Company wanted us to pay for all the  
> licensing that had accrued since we started using the LGPL version. That 
> up-front cost is prohibitive, so we haven't done it.
> 
> Perhaps, if you are trying to nudge folks toward commercial licensing, you 
> could provide a path that isn't so expensive. Or maybe you have? We haven't 
> bothered to look into it lately.
> 
> -John
> 
> ___
> 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 free software policy

[David M. Cotter]

i’m in a similar boat. i’m sure there are others who are NOT on this list who 
are also in the same boat.

> On Aug 14, 2019, at 1:22 PM, John Weeks  wrote:
> 
> We are a small company selling a very large and complex application which is 
> now based on Qt open source. At the time we first considered porting to Qt 
> (version 4.3?) the license was very expensive for small company (six 
> programmers) and the evaluation period simply wasn't adequate to deciding if 
> it was the right way to go. So we went open-source when it became available 
> when Nokia took over.
> 
> Since then, we have wished that we had a commercial license in order to get a 
> bit more traction on some bugs. The Qt Company wanted us to pay for all the  
> licensing that had accrued since we started using the LGPL version. That 
> up-front cost is prohibitive, so we haven't done it.
> 
> Perhaps, if you are trying to nudge folks toward commercial licensing, you 
> could provide a path that isn't so expensive. Or maybe you have? We haven't 
> bothered to look into it lately.
> 
> -John
> 
> ___
> 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

[Thiago Macieira]

On Wednesday, 14 August 2019 13:18:12 PDT André Pönitz wrote:
> On Wed, Aug 14, 2019 at 12:57:27PM -0700, Thiago Macieira wrote:
> > On Wednesday, 14 August 2019 12:09:02 PDT Roland Hughes wrote:
> > > If you do not need the latest bells and whistles, drop back to Qt 4.8
> > 
> > No, don't. That is not receiving security fixes.
> 
> To make this a valid line of reasoning you would need to provide
> an overview on what kind on issues have been found and fixed, what
> issues have been introduced, found and fixed, and estimates on
> what kind of issues have not been found so far, and perhaps even
> on the impact those issues have on typical usage patterns.

We get a division by zero. So I can claim 100% of the issues found weren't 
fixed and be correct :-)

More seriously, the fact that no one is even checking to see if there are or 
have been any issues is sufficient reason to declare insecure.

Do not use insecure software.

Stop using Qt 4.8 right now.
Stop using Python2 by the end of the year.
Stop using OpenSSL 1.0 by the end of year.

PS: Qt 5.12 will switch to OpenSSL 1.1 in the binary builds.

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

Re: [Interest] Qt free software policy

[John Weeks]

We are a small company selling a very large and complex application which is 
now based on Qt open source. At the time we first considered porting to Qt 
(version 4.3?) the license was very expensive for small company (six 
programmers) and the evaluation period simply wasn't adequate to deciding if it 
was the right way to go. So we went open-source when it became available when 
Nokia took over.

Since then, we have wished that we had a commercial license in order to get a 
bit more traction on some bugs. The Qt Company wanted us to pay for all the  
licensing that had accrued since we started using the LGPL version. That 
up-front cost is prohibitive, so we haven't done it.

Perhaps, if you are trying to nudge folks toward commercial licensing, you 
could provide a path that isn't so expensive. Or maybe you have? We haven't 
bothered to look into it lately.

-John

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

Re: [Interest] Qt free software policy

[André Pönitz]

On Wed, Aug 14, 2019 at 12:57:27PM -0700, Thiago Macieira wrote:
> On Wednesday, 14 August 2019 12:09:02 PDT Roland Hughes wrote:
> > If you do not need the latest bells and whistles, drop back to Qt 4.8
> 
> No, don't. That is not receiving security fixes.

To make this a valid line of reasoning you would need to provide
an overview on what kind on issues have been found and fixed, what
issues have been introduced, found and fixed, and estimates on
what kind of issues have not been found so far, and perhaps even
on the impact those issues have on typical usage patterns.

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

Re: [Interest] Qt free software policy

[Thiago Macieira]

On Wednesday, 14 August 2019 12:17:44 PDT Benjamin TERRIER wrote:
> The new add-ons modules could be provided as GPLv3 + GPLv2 + LGPLv3.

Just a nitpick: there's no need to have GPL-3.0 and LGPL-3.0 at the same time. 
So the combinations are GPL-2.0+LGPL-3.0 and GPL-2.0+GPL-3.0.

I don't know if there's anything that is GPL-3.0 (without 2.0). There may be.

There may also be some old code that is LGPL-2.1 because it was lacking an 
upgrade path. Probably the web engines.

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

Re: [Interest] Qt free software policy

[Thiago Macieira]

On Wednesday, 14 August 2019 12:09:02 PDT Roland Hughes wrote:
> If you do not need the latest bells and whistles, drop back to Qt 4.8

No, don't. That is not receiving security fixes.

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

Re: [Interest] Qt free software policy

[Benjamin TERRIER]

Le mer. 14 août 2019 à 20:36, Tuukka Turunen  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

[Roland Hughes]

Not so unusual given the license Roulette which was going on.

On 8/14/19 1:36 PM, interest-requ...@qt-project.org wrote:

Sorry but I'll ask the obvious question: you bet your entire business
without paying for a license?

Have I misunderstood you?


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com

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

Re: [Interest] Qt free software policy

[Roland Hughes]

If you do not need the latest bells and whistles, drop back to Qt 4.8

https://doc.qt.io/archives/qt-4.8/opensourceedition.html

That version is rather prominent in the medical device world, because of 
the issues you bring up here.


On 8/14/19 1:36 PM, David M. Cotter wrote:

+1 on this

i am in the process of porting my legacy project to Qt and am afraid that i’ve 
made the wrong choice.  i’m just one guy and i bet my whole business on the 
availability of what  i need from Qt under LGPL

i’m already using a third party HTTP server so i’m not affected by this but 
it’s a worrying sign. I too agree that the HTTP server really should be LGPL.

What’s going to happen? It’s taken me over a year’s worth of work to get this 
far with Qt and i’m only half done. did i make the wrong choice?

-dave


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com

___
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 free software policy

[Konstantin Tokarev]

14.08.2019, 21:04, "David M. Cotter" :
>i’m ALLOWED to use the free version, right? or did i misunderstand how LGPL 
>works?

You are allowed to use it if you comply with LGPL terms.

In case new modules are licensed as GPL-only and you don't want/can't comply 
with GPL,
you won't be allowed to use that new modules (note that there are certain cases 
when
complying with GPL does not require you to releasing your code, for example if 
your
application runs on the server controlled by you and users interact with it 
only by means
of network connection).

Even in the case (very unlikely) that existing Qt modules are relicensed to 
GPL-only, you
can continue using previous version under LGPL terms, or make a fork.


>
>> On Aug 14, 2019, at 10:11 AM, Vadim Peretokin  wrote:
>>
>> Sorry but I'll ask the obvious question: you bet your entire business 
>> without paying for a license?
>>
>> Have I misunderstood you?
>>
>> On Wed, 14 Aug. 2019, 7:01 pm David M. Cotter,  wrote:
>>> +1 on this
>>>
>>> i am in the process of porting my legacy project to Qt and am afraid that 
>>> i’ve made the wrong choice.  i’m just one guy and i bet my whole business 
>>> on the availability of what  i need from Qt under LGPL
>>>
>>> i’m already using a third party HTTP server so i’m not affected by this but 
>>> it’s a worrying sign. I too agree that the HTTP server really should be 
>>> LGPL.
>>>
>>> What’s going to happen? It’s taken me over a year’s worth of work to get 
>>> this far with Qt and i’m only half done. did i make the wrong choice?
>>>
>>> -dave
>>>
 On Aug 14, 2019, at 9:18 AM, Benjamin TERRIER  wrote:

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


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

Re: [Interest] Qt free software policy

[David M. Cotter]

it’s a labor of love, i make about $2000 per month on it, so about $24k per 
year, and that just about covers my expenses and let’s me eat out sometimes. I 
occasionally have 2 others help me (3 developers).  if i had to pay, it would 
cost $16k per year? that makes the business pointless.  i’m ALLOWED to use the 
free version, right? or did i misunderstand how LGPL works?

> On Aug 14, 2019, at 10:11 AM, Vadim Peretokin  wrote:
> 
> Sorry but I'll ask the obvious question: you bet your entire business without 
> paying for a license? 
> 
> Have I misunderstood you?
> 
> On Wed, 14 Aug. 2019, 7:01 pm David M. Cotter,  > wrote:
> +1 on this
> 
> i am in the process of porting my legacy project to Qt and am afraid that 
> i’ve made the wrong choice.  i’m just one guy and i bet my whole business on 
> the availability of what  i need from Qt under LGPL
> 
> i’m already using a third party HTTP server so i’m not affected by this but 
> it’s a worrying sign. I too agree that the HTTP server really should be LGPL.
> 
> What’s going to happen? It’s taken me over a year’s worth of work to get this 
> far with Qt and i’m only half done. did i make the wrong choice? 
> 
> -dave
> 
> > On Aug 14, 2019, at 9:18 AM, Benjamin TERRIER  > > wrote:
> > 
> > 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 
> > 
> 
> ___
> 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

[Thiago Macieira]

On Wednesday, 14 August 2019 09:18:05 PDT Benjamin TERRIER wrote:
> 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.

It's decided on a per-module basis, based on the authors of the module's 
wishes.

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

Re: [Interest] Qt free software policy

[Vadim Peretokin]

Sorry but I'll ask the obvious question: you bet your entire business
without paying for a license?

Have I misunderstood you?

On Wed, 14 Aug. 2019, 7:01 pm David M. Cotter,  wrote:

> +1 on this
>
> i am in the process of porting my legacy project to Qt and am afraid that
> i’ve made the wrong choice.  i’m just one guy and i bet my whole business
> on the availability of what  i need from Qt under LGPL
>
> i’m already using a third party HTTP server so i’m not affected by this
> but it’s a worrying sign. I too agree that the HTTP server really should be
> LGPL.
>
> What’s going to happen? It’s taken me over a year’s worth of work to get
> this far with Qt and i’m only half done. did i make the wrong choice?
>
> -dave
>
> > On Aug 14, 2019, at 9:18 AM, Benjamin TERRIER 
> wrote:
> >
> > 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
>
> ___
> 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

[David M. Cotter]

+1 on this

i am in the process of porting my legacy project to Qt and am afraid that i’ve 
made the wrong choice.  i’m just one guy and i bet my whole business on the 
availability of what  i need from Qt under LGPL

i’m already using a third party HTTP server so i’m not affected by this but 
it’s a worrying sign. I too agree that the HTTP server really should be LGPL.

What’s going to happen? It’s taken me over a year’s worth of work to get this 
far with Qt and i’m only half done. did i make the wrong choice? 

-dave

> On Aug 14, 2019, at 9:18 AM, Benjamin TERRIER  wrote:
> 
> 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

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