top | item 42079460

QNX is now free for anything non-commercial, plus there's an RPi image

658 points| JohnAtQNX | 1 year ago |blackberry.qnx.com

Hiya folks!

I'm John from the Developer Relations team at QNX. I'm a loooong time lurker of this forum and excited to make my first post.

I just wanted to let you know that we've kicked off a new program to start opening the doors to QNX like things used to be. Many of you probably used or tinkered with (the very open) QNX back in the day. You can now easily get a free non-commercial license to use the newest QNX. We've also just released some sample apps and a ready-to-go QNX 8.0 quick start target image for Raspberry Pi. So you can get QNX and the development tools for free now to learn, experiment, and build.

It's been a long time in the making, so I'm really excited to get to post about this first phase of the QNX Everywhere initiative. My team and management have open ears, so please share feedback about what more we can do to open things up, be more transparent, and get you what you need to create an awesome embedded QNX project.

Cheers!

357 comments

order
[+] Animats|1 year ago|reply
If only you could believe them.

QNX has been "opened" twice before. Each time, there was a rug pull, and it went closed again.

Before the first rug pull, open source groups routinely added QNX to their target list. There was a Firefox for QNX. Eclipse had QNX as a target. GCC and most of the Gnu command line tools could be built for QNX. There was a desktop environment, Photon. I used that as a primary desktop for three years when working on a DARPA Grand Challenge vehicle.

All of that went away after the Harman acquisition of QNX in 2004.

Then, in 2007, QNX went open source. You could even look at the microkernel. It wasn't openly licensed, but you could look inside and build it.

In 2010, RIM acquired QNX, and, with no warning, closed the source. All open source development related to QNX ceased, and QNX lost all credibility in the community. So QNX shot itself in the foot. Twice.

Note the contractual terms.[1] "TERMINATION. This Agreement and licenses granted hereunder may be terminated by either Party upon written notice to the other Party". QNX can pull the plug at any time. Since they've done so twice in the past, there's a good chance that will happen again.

Now, if QNX is serious about this, the way to go is to use the licensing model Epic uses for Unreal Engine. Unreal Engine is behind most AAA game titles. The basic terms are that you can download the source and use it for anything you want, and there's no charge until you get the first $1 million in revenue from your product. Then Epic takes a 5% royalty.[2] This has been extremely successful for Epic. There's not much of a piracy problem, because if your game gets enough revenue to matter, it has enough visibility that their licensing people will notice. Meanwhile, there's a large pool of people using Unreal Engine.

That's the way to do it if you want more adoption of QNX. Take the Epic term sheet to your lawyers and management. And have them take a look at Unreal Engine's revenue growth vs. QNX.

As I once told a QNX sales rep, your problem isn't that you're being pirated. It's that you're being ignored.

[1] http://www.qnx.com/download/feature.html?programid=51624

[2] https://cdn2.unrealengine.com/UnrealEngine/faq/UnrealEngineE...

[+] relistan|1 year ago|reply
I worked for a startup in Germany that was acquired by RIM/Blackberry in 2011. The company tried to get all the employees to sign new contracts for their existing roles and pay. The new contracts put severe IP limitations on everyone. All open source was forbidden. Many of us were very active in open source at the time. (I had worked for the Eclipse Foundation). A friend who wrote fiction was told he’d need written permission for each story he wanted to post or publish. They insisted that German engineers sign contracts where the binding language was English even though it was provided with a German translation. Many of us just left instead. My favorite line from the transition team sent from Canada was about how lucky we were going to be that they’d let us keep our awesome office in Munich because everyone at RIM worked in dark concrete dungeons. Yeah, how lucky we were that we could keep what we had.

Open anything is just completely foreign to that company’s DNA. I would not trust them an inch.

[+] yjftsjthsd-h|1 year ago|reply
> Now, if QNX is serious about this, the way to go is to use the licensing model Epic uses for Unreal Engine. Unreal Engine is behind most AAA game titles. The basic terms are that you can download the source and use it for anything you want, and there's no charge until you get the first $1 million in revenue from your product. Then Epic takes a 5% royalty.[2] This has been extremely successful for Epic. There's not much of a piracy problem, because if your game gets enough revenue to matter, it has enough visibility that their licensing people will notice. Meanwhile, there's a large pool of people using Unreal Engine.

One option: Dual-license as GPLv3 (the 3 is important!) or commercial license. Hobbyists and FOSS projects will be quite happy to use a GPLv3 OS. The big commercial users - traditionally cars and other embedded uses - will not want to be legally obligated to give users the ability to install custom firmware (which GPLv3 basically requires), so they'll still pay for it. Everyone wins.

(IANAL, this is not legal advice, interpret licenses yourself.)

[+] stackghost|1 year ago|reply
Shitty dx is baked into RIM/Blackberry's institutional DNA.

I had a long conversation with their engineering people way back before BB10 came out. At the time you had to apply to get access to the full blackberry SDK, and IIRC you also had to sign an NDA. Meanwhile Android and iOS were in full swing and wouldn't you know it, the platforms that had better developer experience, that prioritized making it easy to write apps, were successful.

Blackberry is just institutionally incapable of handling this sort of relationship with the community. It's that legacy telco "us vs them" mindset at the top of the org, and it filters down whether implicitly or explicitly.

[+] wakeupcall|1 year ago|reply
Back before 2004, QNX could have still been relevant as there was still a lot of OS experimentation from the user/developer themsevels. They could have attracted enough people to carve a niche even in the desktop space at that time.

After beos failed, I played/developed with QNX until they pulled the rug. I was on it full time on my main dev machine. I loved it.

When they closed it I got severely burned to the point that I will not touch a any closed development platform. I see from the license they didn't change a bit.

Not that it matters anymore.. they're largely irrelevant today except for whatever existing markets they already have. It would be fooling to choose QNX today: we now have good alternatives, and all of them with open licenses.

[+] PaulHoule|1 year ago|reply
Also I wonder how many applications really need more real time responsiveness than you can get out of Linux. We even have

https://arstechnica.com/gadgets/2024/09/real-time-linux-is-o...

If I use Linux I know I won't have to have a discussion about licensing, I know I won't get rug pulled, etc.

Also the ban on commercial use is heinous. I am going through this with Arangodb right now. I love the product, but I have no budget for a cloud instance they manage and I have no budget to talk with their sales people about a commercial license. I have several systems that use it (including one that's about 80% of a way to a "too big for free" database) and I don't know if their fate will be (a) open sourcing, (b) a product or (c) a system that makes money for me directly but for me the short path is to switch to postgres, not talk to people whose business model doesn't necessarily allow my business model.

[+] snvzz|1 year ago|reply
>QNX went open source.

Not open source. Those words have a specific definition[0], which QNX never met.

0. https://opensource.org/osd

[+] apitman|1 year ago|reply
Even getting the licensing right isn't sufficient. They could license it as MIT today, close source it again tomorrow, and within a few releases no one would be using the MIT version.

Unless someone is interested in maintaining a full fork. It's the same reason Google can do whatever they want with Chromium even though it's technically open source. No one else has the resources/will to maintain it so there's no credible threat of a fork.

[+] johnklos|1 year ago|reply
So it's not just me. I asked for a license to do pkgsrc package building on QNX, got rejected, and couldn't even get a human to respond to my messages with anything that didn't resemble a copied-and-pasted form response.

They gave the impression at the time that they really couldn't be bothered with open source. This just happened to be not long after 2010.

[+] hulitu|1 year ago|reply
> As I once told a QNX sales rep, your problem isn't that you're being pirated. It's that you're being ignored.

Microsoft realized that a long time ago. That's why you could always get Windows for free if you knew where to look.

QNX will lose even more since linux merged the RT patches. There is almost no reason to use QNX on an embedded system where linux is also available.

It is sad. With GNU it could have been something interesting.

[+] altairprime|1 year ago|reply
For QNX 8.0, here’s a saved-you-five-minutes direct link to the developer terms associated with noncommercial use:

https://support7.qnx.com/download/download/51624/BB_QNX_Deve...

(I am not your lawyer, this is not legal advice. This is not a comprehensive review, assessment, or summary of possible interpretations of that license. Seek professional counsel from a lawyer before acting on anything stated below.)

These terms open with a ‘user did not have an opportunity to review and agree before binding themselves, their business, and/or their institution’ clause that may well wholly invalidate the entire document in the US, so please review these with your lawyer before use, so that your usage is not put at risk due to legalese overreach.

Academics, only students and faculty of your institution qualify, and your usage under this license will be viewed by your legal team as you signing a binding agreement on behalf of your employer; make sure you’re not exposed to liability through open source contributors or at risk of being fired for misrepresenting yourself as a signing authority for your institution.

Cloud users, your license is restricted to AWS per their terms; use on GCP, Heroku, or any other server instance not under your personal contractual control may result in owing licensing fees.

Only OSI definitions of “Open Source” are permissible here; this disqualifies anyone licensing software under a restrictive non-commercial license from making use of the QNX non-commercial license, as per OSI, all such restrictions are not “open source”.

Social apps are excluded by the “high risk” clause, which prohibits any use under these terms to develop applications that could harm society. Take care not to create viral applications that violate this clause.

They collect and retain all serial numbers identifiable on all hardware you use in association with this product.

Your noncommercial license may be severed unconditionally at any time without recourse, regardless of whether you have faithfully complied with the terms; at which time you may be compelled under contract to provide an undefined ‘certification’ of indeterminate cost that you deleted all QNX code provided to you.

Stay safe, folks.

[+] gmueckl|1 year ago|reply
Since when are social apps high risk? The high risk clause is clearly targeted at applications that have safety requirements (IEC 61508, ISO 26262 etc.). A crashing Twitter client won't injure or kill anyone.
[+] parl_match|1 year ago|reply
Why would I use QNX for any project when RTOS Linux is mature? Why would I care? So you can rug-pull license changes?

Should I use it because it's cute? It's academically interesting? Sure, I've used QNX in the past for those reasons. The next time I pick a soc for a project, and its associated bsp, I'm not going to look for QNX. I'm either going to use whatever freertos distro they include or install the android build tools so i can push an apk to its wackity ass android fork.

I suppose if i was doing automotive or medical, the story would be different. But I know the space well enough to know that you have many competitors all nipping at your heels, and with the linux rtos changes, it's not going to get better.

This is not 2010. There are options. While QNX has languished behind obscure and annoying licensing requirements, literally dozens of companies have been developing alternatives. Some of them are quite big, and in some cases, have gone to space.

At this point, if you want QNX to be taken seriously, you're going to have to do better than "start opening the doors to QNX like things used to be".

I'll take it one step further - if it's not completely open source for commercial use, I have no interest in using it. I could be enticed to put up with an Epic-style license if the associated tooling and bsp support was worth my time. I have zero interest in paying a license to get started. Again - not 2010.

Your product has been commoditized and now it's a curiosity. The only way it gets enough active development and adoption is if its a community effort.

[+] EasyMark|1 year ago|reply
Name/reputation still means a lot to some people, as does not learning yet another OS. Not everyone cares if something is FOSS or not. Different people have different leaning when it comes to this stuff, and that shouldn't be surprising.
[+] gosub100|1 year ago|reply
You would use it if you wanted to get a job doing RTOS dev and wanted to show you had some skin in the game.
[+] vundercind|1 year ago|reply
QNX and BeOS were the only operating systems I tried in the early '00s that could make old single-core mid-90s Pentiums feel excellent and snappy to use. Far, far better than any Windows version, or Linux.

I assume it's mostly scheduler stuff and much better multimedia stacks, in both cases. I always hoped the operating systems of the future would feel more like that. Closest we've got is probably iOS and it cheats by killing processes all the time. The future is lame.

[+] smallstepforman|1 year ago|reply
BeOS was “pervasively” multithreaded, which in non marketing speak means the kernel did not have a giant lock (since it was designed as a many core system from day #1). Its contemporary OS’s at the time had a giant single lock. BeOS also had 750ms preemption interval (or was it 3ms, I dont remember) while Linux and Windows had 20ms, then later 10ms, so this is what you fealt. A couple of decades later and most OS’s matched the finer locking granuality in kernel space, minus the premption interval (argument being throughput vs latency, since scripted OS benchmarks measure overall throughput, not GUI responsiveness). A perfect example is media buffers that benefit from smaller buffer sizes, at the cost of less throughput. Musicians notice better responsiveness in BeOS, hence the monicker “Media OS”.

Also, in GUI space, the BeOS/Haiku app server still offers a more distributed workload compared to other desktop environments. Every windows is assigned its own thread, the app gets its own thread, and the app and application server have 1 thread per app and window to ensure they are not blocked waiting for slow app message parsing. So minimum BeOS app with graphical “Hello World” window is 4 threads. So even if the app is busy, the rest of the system still feels responsive.

All this comes at a throughput cost, as well as an app development complexity cost, especially for ported apps. Haiku needs to marshall Qt/Gtk/toolkit messages from many windows into a single message queue to prevent multithreaded bugs from popping up (since in their original environment, all app message loopers were not multithreaded). This marshalling needs additional lock/unlock calls in Haiku even when not needed (messages to same window).

Haiku native apps, on the other hand, are smooth as ice. See this screenshot of Medo video editor where all windows are working in their own threads (https://raw.githubusercontent.com/smallstepforman/Medo/refs/...). On modern systems, this app is smooth as ice, which for a video editor is heresy. Disclaimer: I wrote the linked Haiku app.

[+] Baeocystin|1 year ago|reply
I non-ironically dream for the day that a modern computer is as snappy booting as my old Commodore 128, as fast to reset, and as responsive to all keystrokes.
[+] Aurelius108|1 year ago|reply
Although they’re cheating, I give them props for trying. I abandoned Android when even Samsung didn’t make an honest effort to make their phones responsive. It’s nice that Apple consistently values responsiveness because then Google, Samsung and Microsoft have some incentive to address their bloated products.
[+] workfromspace|1 year ago|reply
As someone also have used BeOS and OS/2 Warp, I miss the snappiness of old systems. (I never got my hands on QNX)

What OS nowadays is the closest to that snappiness? Haiku OS? (I'm a happy M1 Macbook user, but it sometimes feel note nough.)

[+] ddingus|1 year ago|reply
I never ran QNX, but my experience with BeOS were similar to yours in that a Pentium 90 felt great!

Another data point:

SGI IRIX has an unusually good scheduler. I ran a 30Mhz machine for a while and it's desktop was pretty snappy.

One day, I compiled AMP and fed it a list of .mp3 files, most being 192kbps. The program could decode 256kbps without skipping, just FYI.

Those files were on an NFS share.

When I ran the gr_osview program, CPU was 95 percent utilized, and still the file manager was responsive and that music did not skip.

Frankly, just decoding higher bitrate > 192kbps mp3 files at 30Mhz was impressive.

Doing it with a full X Window system desktop, while playing he files off an NFS share, while remaining responsive speaks to a lean and mean network stack and scheduler that performed even on low spec hardware.

Was IRIX 5.3 FYI. Indigo Elan

A friend and I enjoyed operating systems and ran Be on an old Pentium 90, and like the parent comment says, it was snappy!

Linux also has a part in this:

After a water event, that Pentium 90 was no longer reliable. Used non parity RAM and Windows NT would go slowly senile eventually blue screening over and over.

For funzies, we put Red Hat 5.2 on that box and it ran fine! The syllog had a bunch of entries every second too. Open X console, and just watch them go by...

That box served up the company web page for a coupla weeks just for fun too.

Good times.

[+] xarope|1 year ago|reply
I feel sad that people don't remember OS/2 anymore. It was also able to run multiple dos windows, have video running in the background etc, and that was in the late 90's.
[+] KerrAvon|1 year ago|reply
iOS has very strict process/resource management because it wants to preserve both available RAM (for responsiveness) and your battery life. I wouldn't call it cheating (even in jest); it's a very deliberately and carefully designed feature of the OS.
[+] johndoe0815|1 year ago|reply
To add some details - the source code for QNX was available from 2007 until the takeover by RIM/Blackberry in 2010.

So do you plan to offer access to QNX source code again in the future?

https://www.qnx.com/news/pr_2471_1.html

[+] JohnAtQNX|1 year ago|reply
Don't hold me to timelines, but we're definitely headed in the direction of being more open and transparent. We're hearing that this is important to our customers and the community alike. Stay tuned!
[+] AceJohnny2|1 year ago|reply
My previous company, which made high-availability (Active/Standby) routers for mobile networks, used QNX as the OS. I remain impressed by its capabilities.

My memory is rusty, but we ran QNX on the control-plane processors, and it natively allowed launching processes on remote processors over the internal network of the router. That is: their low-level IPC was IP-capable. QNX's IPC was essential for our HA failover functionality.

Also, device drivers as user-space processes that you could restart on crash was great (we were developing our network drivers, so this would occasionally happen). Also, better respect for devices actually showing up in the /dev/ tree, unlike Linux where network devices are a notable exception.

One funny story, I once spent days debugging an issue which turned out to be due to me accidentally marking const the return values of some IPC, which caused my process to crash in between QNX's IPC function and mine! Whatever level of debugger (C/userspace) I was using at the time could not catch the error ^^;

[+] ahoka|1 year ago|reply
I also worked on routes for mobile networks. Everything ran Linux, especially the control plane. Line cards were also linux, but the only task they had to do is to program the ASICS as the control plane told them to do. None of those features are relevant, you could do the IPC over HTTP or whatever you wanted.
[+] nrclark|1 year ago|reply
@JohnAtQNX can you remove the "everybody needs an account" restriction from your website downloads, and also remove the license mechanism from qcc? That would go a long way towards encouraging hobbyists to try it out.

Your money comes from high-volume licensing deals, where you presumably get a per-unit license fee. That revenue stream is jeopardized by pissing off the CI/CD teams that have to support QNX product lines.

[+] JohnAtQNX|1 year ago|reply
Hiya! We've discussed how to make that work. It's good to hear the same thing from an outside voice. I'll bring it back to the table to inch it along. Thanks!
[+] ksaj|1 year ago|reply
Or at the very least, allow people to log in using other services, like Google, et al, that plenty of other sites are using.

I'm loathe to keep adding new logins every time something new comes about. Same with news feeds, where nearly half of all news sites want you to log in, even if it is "free." At least in that case, it's easy to just go elsewhere for the same story.

[+] chrsw|1 year ago|reply
Exactly. I'm more likely to go somewhere else with less friction.
[+] Baeocystin|1 year ago|reply
I still remember being blown away by the single-floppy QNX demo that included a web browser. It was so fast.

I wish you guys the best. I can only imagine what a gordian knot it must be getting all the legal ducks in a row to actually open things up. Like others have mentioned, after two rug pulls, we're all wary, but there's so much to enjoy about QNX, I hope you manage to get traction with this.

[+] tlack|1 year ago|reply
Kudos on your bold undertaking! I've been a side-lined QNX admirer for some time, though not a potential user in most cases. A good next step would be a series of blog posts where the author takes on common types of enthusiast projects and unpacks how QNX's strengths can be applied in those scenarios.
[+] steve_adams_86|1 year ago|reply
I’d love to see this. I’m curious about QNX but at a loss as to how it could benefit me as someone who tinkers with robotics at home.

I also work for a non-profit org which does coastal margin research. We have several people working on custom hardware. Could this benefit us?

[+] xvilka|1 year ago|reply
We (Rizin) would love to improve QNX support of our FOSS reverse engineering and debugging framework. We already support[1][2][3][4] it, but can't reliably test. Would be awesome to have the QEMU image out of the box, just like Windows provides ready to use limited VMs for testing[5].

[1] https://github.com/rizinorg/rizin/tree/dev/librz/bin/format/...

[2] https://github.com/rizinorg/rizin/blob/dev/librz/bin/p/bin_q...

[3] https://github.com/rizinorg/rizin/blob/dev/librz/debug/p/deb...

[4] https://github.com/rizinorg/rizin/tree/dev/subprojects/rzqnx

[5] https://developer.microsoft.com/en-us/windows/downloads/virt...

[+] bexsella|1 year ago|reply
I’ve had a lot of experience in developing on QNX over the years, and with each successive year, the call to migrate to Linux got stronger. The day to day developer experience is great, you can very easily setup a CMake toolchain and bypass the need for QNX’s Momentics, which if you’re just developing for QNX is something you will want to do. But, in my experience the driver support simply isn’t there, and that became painful. A fair few major board manufacturers treat QNX integration as a complete afterthought, and at a point you start to feel that this is directly related to RIM’s decision to shutdown source access to QNX. I’ve since left that company, but I imagine there is still a call to use Linux.
[+] brynet|1 year ago|reply
I don't have great expectations for this, we've been rug pulled before.

https://www.osnews.com/story/23565/qnx6-is-closed-source-onc...

They then killed the self-hosted QNX entirely, no downloadable .ISOs after 6.5. No working toolchain, so porting software became difficult, pkgsrc abandoned.

They are completely noncommittal, nothing short of actually open-sourcing it, MIT/BSD, would convince me otherwise.

[+] graymatters|1 year ago|reply
QNX is squeezed from above by Linux, especially as real time patches have finally been fully accepted. And from below by FreeRTOS and Zephyr. Current attempt to open source is a desperate move by QNX as their market share is disappearing. Why would anyone in their right mind step on the same landmine, called QNX, which already pulled a rug from under the developers feet once? Absolutely no trust in QNX ecosystem. Save yourself pain and aggregation. Don’t use QNX.
[+] ksaj|1 year ago|reply
Please consider bringing back some legacy software.

When I was learning computers, we learned on QNX (poor kids younger than I started on Windows!) and there were some very interesting software packages that I think don't exist anymore.

For example, QPaint. What made it interesting, is that you could save your image in a few image formats, or as a C header for inclusion in a C program. It could also import/export Logo generated images.

There was also a software voice module. I assume it had different voices because when it was demoed to us, it was a robot guy voice, but later there was an educational graphical interface that looked like a girl's face, and it of course had a female voice when it spoke. It would be strange to have two things do exactly the same thing, so I suspect they were the same software for speech.

I think it was simply invoked with 'speak'. We used to prank other students by speak -something- /dev/tty.... where the tty pointed to other people's nodes on the server network. Fun times!

[+] supermatt|1 year ago|reply
15 years too late (since you last snatched QNX away from us), and with a license that you can revoke at any time. What are you blackberry folk smoking?

I guess your "benevolence" is no coincidence given that real-time support was merged into the linux kernel a month ago...

[+] GuestFAUniverse|1 year ago|reply
Typical marketing euphemism: "Built-in Support for Open-Source Components"

Read: we take free things thankfully, but we don't live by the same standards.

[+] farseer|1 year ago|reply
With linux options in embedded space aplenty, who would want to move to a propriety os? QNX's big brother Vxworks has already been pushed out of most consumer embedded devices and is now limited to space probes and critical medical equipment. I just don't see a future for QNX anywhere.
[+] rw_grim|1 year ago|reply
> Develop open-source software (OSS) that is interoperable with QNX software, provided you make the resulting OSS publicly available at no charge.

Even the GPL doesn't have this restriction...