[Interest] the path forward - that 7 year thing - was, , willy-nilly

Sun Mar 28 20:44:40 CEST 2021

Yeah,

hush-hush "call for pricing" is a truly bogus business practice usually 
utilized by scams and used car dealers.

This "gouge them for all they are worth in private" business model 
really isn't valid. Even if you adamantly claim that isn't what is going 
on, that is __exactly__ what it looks like from the outside.

You need published bankable ****perpetual**** prices.

__AND__ you need a Qt that doesn't drop platforms mid-major release.

On 3/28/21 1:15 PM, Jason H wrote:
> Tukka,
>
> I'm open to being wrong, but I just spoke with them. One of us three is obviously in error, but I pushed back on the lack of the perpetuity clause, (it was present at my last company) and sales was clear, it was removed...
>
> What would really help, is to get this documented out in the open... None of this "contact sales for pricing"
>
>
>
>> Sent: Sunday, March 28, 2021 at 7:53 PM
>> From: "Tuukka Turunen" <tuukka.turunen at qt.io>
>> To: "Jason H" <jhihn at gmx.com>
>> Cc: "Roland Hughes" <roland at logikalsolutions.com>, "interest at qt-project.org" <interest at qt-project.org>, "mike.jackson at bluequartz.net" <mike.jackson at 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 <jhihn at gmx.com>
>> Lähetetty: sunnuntaina, maaliskuuta 28, 2021 4:52 ip.
>> Vastaanottaja: Tuukka Turunen
>> Kopio: Roland Hughes; interest at qt-project.org; mike.jackson at 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.turunen at qt.io>
>> To: "Roland Hughes" <roland at logikalsolutions.com>, "interest at qt-project.org" <interest at qt-project.org>, "mike.jackson at bluequartz.net" <mike.jackson at 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-bounces at qt-project.org> käyttäjän Roland Hughes <roland at logikalsolutions.com> puolesta
>> Lähetetty: Friday, March 26, 2021 10:47:34 PM
>> Vastaanottaja: interest at qt-project.org <interest at qt-project.org>; mike.jackson at bluequartz.net <mike.jackson at 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 at qt-project.org
>> https://lists.qt-project.org/listinfo/interest
>> _______________________________________________ Interest mailing list Interest at qt-project.org https://lists.qt-project.org/listinfo/interest
>>
-- 
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