I was just in contact with them, and shocked that the perpetual nature was removed...
I don't think I'm mistaken. > Sent: Sunday, March 28, 2021 at 7:53 PM > From: "Tuukka Turunen" <tuukka.turu...@qt.io> > To: "Jason H" <jh...@gmx.com> > Cc: "Roland Hughes" <rol...@logikalsolutions.com>, "interest@qt-project.org" > <interest@qt-project.org>, "mike.jack...@bluequartz.net" > <mike.jack...@bluequartz.net> > Subject: Re: [Interest] the path forward - that 7 year thing - was, , > willy-nilly > > > Hi Jason, > > Please contact our sales to discuss commercial licensing. Based on the email > below you seem to misunderstand the commercial development and distribution > licensing at least partially. > > Yours, > > Tuukka > > ________________________________ > Lähettäjä: Jason H <jh...@gmx.com> > Lähetetty: sunnuntaina, maaliskuuta 28, 2021 4:52 ip. > Vastaanottaja: Tuukka Turunen > Kopio: Roland Hughes; interest@qt-project.org; mike.jack...@bluequartz.net > Aihe: Re: [Interest] the path forward - that 7 year thing - was, , willy-nilly > > Tukka, you (Digia, aka "QtCo") no longer offer the perpetuity clause of the > license. Which is absolutely insane for a commercial customer. If we are no > longer developing that code, we should still be able to "distribute" that > code. The revocation of the perpetuity clause in new licenses means we can no > longer do that. We aren't even asking for support in perpetuity, just the > ability to distribute what we had been... > > The developers at Qt Co need to push back and tell Digia "that's not how this > works" before we get to the points of users revolting in threads on the > forums / lists. It's a bad look. Anyone investigating Qt would be throughly > turned off by now, and I can't say I would blame them. > > It's really sad it's gotten this far. I've been licensing Qt off and on since > 2005 and watching it erode this whole time. I still think it's the greatest > tech, but the licensing is quickly becoming the limiting factor. So much so, > that I have Qt in consideration at another company, and I am about to pull > the plug because the licensing has changed so much. > > At some point the business people have to realize that they are selling to > engineers, and this is a much more nuanced field, and this license erosion is > noticed. > > Yeah, we noticed when QtPdf license changed: > https://www.qt.io/blog/2017/01/30/new-qtpdf-qtlabs-module (LGPLv3) > https://www.qt.io/blog/change-in-open-source-licensing-of-qt-wayland-compositor-qt-application-manager-and-qt-pdf > (Tukka's own post) > https://lists.qt-project.org/pipermail/development/2019-October/037698.html > (Not everyone was on board with the license change) > But it's now under the marketplace license? > https://marketplace.qt.io/collections/most-popular/products/qtpdf ($49/ > Marketplace license) > > > Shenannigans. I declare shenannigans. > > Sent: Saturday, March 27, 2021 at 4:23 AM > From: "Tuukka Turunen" <tuukka.turu...@qt.io> > To: "Roland Hughes" <rol...@logikalsolutions.com>, "interest@qt-project.org" > <interest@qt-project.org>, "mike.jack...@bluequartz.net" > <mike.jack...@bluequartz.net> > Subject: Re: [Interest] the path forward - that 7 year thing - was, , > willy-nilly > > “When Qt chased these markets it knew what the lifetimes would be. Now it has > abandoned them.” > > I would like to point out that this is not a true statement. We do offer long > term support and also extended support for those customers who need it. There > are some who every now and then still need something related to Qt 3. > Somewhere Qt 2 is still in use. Perhaps Qt 1 even, but personally not certain > about that. Qt 4 based systems of course and majority of customers are with > Qt 5 currently. > > Each of these versions has changed API and we have tried our best to make the > transition from Qt 5 to Qt 6 smooth. We are happy to get suggestions and > feedback to it still and help in the transition. > > Yours, > > Tuukka > > ________________________________ > Lähettäjä: Interest <interest-boun...@qt-project.org> käyttäjän Roland Hughes > <rol...@logikalsolutions.com> puolesta > Lähetetty: Friday, March 26, 2021 10:47:34 PM > Vastaanottaja: interest@qt-project.org <interest@qt-project.org>; > mike.jack...@bluequartz.net <mike.jack...@bluequartz.net> > Aihe: Re: [Interest] the path forward - that 7 year thing - was, , willy-nilly > > > On 3/26/21 1:39 PM, Michael Jackson wrote: > > I'll start off by acknowledging your points, but we will just agree to > > disagree. I acknowledge that you have a*lot* of years making/maintaining > > software for medical devices. But I'm with Hamish on this. I don't > > understand. > > > > What you are saying is that Qt was designed "perfectly" from day one with > > no extra API, not one bad API implementation and no cruft. Qt should never > > be updated to run on modern compilers against modern C++ specifications. > > Updated to run on modern operating systems. Qt should not explore adding > > APIs/Toolkits to the Qt ecosystem to allow Qt to be used on the billions of > > devices that we use every day. Qt should just stick with its technology > > from 20 years ago. TQtC shouldn't go after paying customers in order to, > > you know, pay its developers. TQtC should rely solely on an industry that, > > by your own writings, have a 15 year horizon. Not much of a business case > > for that. (For the record, I don't particularly agree with TQtC current > > licensing or LTS strategy.) > > No. Not what I'm saying at all. I have no idea how you got there from > what I've said. > > Stable API. Nothing ever gets deleted until it has a direct or mostly > replacement *within* the existing product. > > When Qt chased these markets it knew what the lifetimes would be. Now it > has abandoned them. > > > I also don't understand your argument that you want to update a medical > > device from 20 years ago with the latest and greatest toolkits. I can't > > imagine anything electronic from 20 years ago being able to actually load > > and run anything like Qt? How is the hardware even powerful enough to do > > this? You can't convince me that the medical hardware device manufacturers > > were thinking 15 years into the future for the next upgrade, 15 years ago. > The surgical robots being sold today will require 20 year support > lifespans. Many of the devices sold over the past decade were sold with > a minimum 10 year support and maintenance requirement. The development > effort on these devices runs into the millions. You can't make a bet > like that and find out a year later the supplier flew off to the Cayman > Islands with Ted Cruz and your money. > > 50 Year Old equipment. You make the case even more for TQtC to pursue > > customers with a much shorter timeline. If TQtC concentrated on markets > > with 20-50 year timelines for updates how much revenue do you think they > > would make? Enough to sustain Qt development in any real capacity? Doubtful. > > Okay. There's an education situation here. > > I've never worked for a one-trick-pony medical device company. For > certain there are the grant/research funded things coming out of college > labs. That Phd. student doesn't take it to production. A Baxter, > Hill-Rom, GE, etc. type player will be who said thing gets sold to. They > will take it through FDA approval and to full production. Usually they > end up hiring the person or small college team that created it. > > Baxter (and I imagine all the rest) actually invest in many tiny startup > medical device companies if there is a good idea that has already had > some fundamental work. They invest with the intent of consuming some/all > of it when it is obvious the thing will work. Here, this might help. > > https://www.gehealthcare.com/products/accessories-and-supplies/clinical-accessories-and-supplies > > Click on Products & Services and then click Equipment and follow across. > Those are just the devices GE puts out under its *own* brand. It owns > whole or in part lots of other little companies putting out medical > devices under their own brand. Hill-Rom is much the same from that > perspective. > > You are thinking in terms of the x86 world where there are oceans of > one-trick-ponies. Companies like Install-Shield that had one big hit > followed by some flame-outs. Last I heard they were still just a one > product company. It's a cultural thing tied to that platform. > > Here's reality in the medical device world. > > Year one you get told to create a new patient monitor that looks like > any of the ones in this list of images. > > https://duckduckgo.com/?t=canonical&q=patient+monitor+image&iax=images&ia=images > > It has a pump for blood pressure cuff, SP/O2, thermometer, and ability > to record/display some patient info like weight and body mass. The UX > team comes up with a style, fantastic graphics, even a custom font to > support all of the supported languages. Management tells you what they > are going to buy for a processor and RAM. They put a stake in the ground > on battery life and recharge time, etc. > > You work like dog for 6-8 months. Product goes off for FDA approval. The > day __after__ everybody goes out for drinks management team tells > hardware team to split into two groups. > > Group 1: Design and build a new & improved hospital bed with built in > scale so nursing homes don't have to get immobile people up to weigh > them. (For those who don't know, they are required to record resident > weight at least monthly. One of the dead give-aways for abuse is > significant weight loss without doctor visit.) > > Group 2: Design a mattress or mattress cover to be a patient monitor for > burn victims and other people whose skin is in such a condition you > cannot use a blood pressure cuff or the SP/O2 finger clip. > > Group 1 won't need much for software people. None if they purchase a > prepacked scale display. Group 2 is going to re-use much of the source > code from the just completed patient monitor for the UI and device > messaging. If they've never built one of these before the real work is > in the mattress or mattress pad. I don't know how they do it, but some > of them manage to get blood pressure. > > When you are just about done with that product management pulls the bulk > of the software team off to work on a surgical robot. > > These companies purchase a tool set and usually purchase support > contracts for it. They pay lots more for tool sets that have already > done all of the paperwork for the FDA. When it is a tool set suffering > "massive churn" the constant testing and re-certification gets > prohibitively expensive. > > BlackBerry makes a lot of money with its certified QNX. > > https://blackberry.qnx.com/en/software-solutions/embedded-software/medical > > I think there is also someone selling a certified version of FreeRTOS. > > If the tool(s) you use don't already have this proof and haven't already > been blessed by the FDA, you have to get it done. Here is a write-up > that I just quickly skimmed and won't be offended if you don't actually > read. > > https://www.integrasources.com/blog/linux-os-for-medical-devices/ > > The only phrase you have to worry about is SOUP. Software Of Unknown > Provenance. Your Yocto build of Linux falls under that. If Qt is > churning, it also falls under that unless QtC is continually going > through FDA approval. CI has to include FDA approval process which is > neither automated nor quick. > > In a previous message I gave you the different layers going up from bare > metal to RTOS (hard certifications required, no dynamic memory, etc.) > Then I told you about the COMM module most manufacturers are moving to. > This is a physical thing that can be certified independently then used > on any number of devices. It removes all penetration threat because > there now is no outside world connection for the device. It has a serial > connection that accepts only a fixed group of messages throwing the rest > away. Your Yocto build doesn't have a network stack, just the PPP type > driver. > > So, putting this into a shot glass for everyone, when you are working > for a medical device company you are on something of a device treadmill. > Once a device is launched it is expected to have a 15+ year life. You > **will** have to support it for 15+ years, but you won't re-engineer it > until then. > > While that device is out there making lots of money and saving lives, > you will use the same tools to work on many other devices. > > You can't keep re-introducing SOUP every few months. Someone either has > to get SOUP certified __or__ you have to mitigate RISK by removing all > potential for SOUP to cause patient harm. One of the main mitigations is > the message based design. Another main mitigation is the inclusion of an > "easily accessible during emergency yet physically protected" physical > off switch. You can't have a touch screen power down icon be your only > method of shutting something off. > > It is impossible to mitigate all RISK with something like an infusion > pump. You can have the most perfect drug library in the world. It can > have the most perfect of rules for dosages and one stupid bug that > slipped through testing could send down 7L/hr instead of 7ml/hr. The > driver for the pump motor has to have safety built into it that caps > volume at a safe level. 7L/hr is going to blow a vein. > > > Because of SOUP and certification costs these companies tend to pay big > bucks up front for good tools and they also tend to purchase support > contracts. > > The *do not* do subscription licensing. They generally don't do per-seat > licensing. > > When they pay for something like a support contract they expect > **actual** support, not bugs rotting in a bug database for 12+ years and > definitely don't take kindly being told "it's too hard to fix" or "if we > fix it then other things will break." > > If they pay for support on RHEL 6, you don't get to just drop the > platform because it is inconvenient. > > The entire purpose of choosing a high level application framework is so > the kernel doesn't matter. The stable API remains the stable API. Under > the hood remains under the hood. > > -- > > Roland Hughes, President > Logikal Solutions > (630)-205-1593 > > http://www.theminimumyouneedtoknow.com > http://www.infiniteexposure.net > http://www.johnsmith-book.com > http://www.logikalblog.com > http://www.interestingauthors.com/blog > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > _______________________________________________ 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
