QNX、非商用利用を無料提供し Raspberry Pi イメージを追加
(blackberry.qnx.com)- 組み込み・リアルタイムOS開発者がQNX SDP 8.0を学生・趣味・プロトタイプ用途で無料で試せるようになり、従来の商用中心の参入障壁が下がる
- ユーザーはmyQNXアカウントでライセンスフォームを送信する必要があり、リクエスト処理後に非商用向けQNXソフトウェアライセンスを受け取る
- 提供範囲には QNX SDP 8.0、QNX Developer Desktop、QNX Hypervisor が含まれ、OS学習からセルフホスト開発、仮想化実験まで進められる
- 開始用リソースとして Quick Start Guide、Raspberry Pi 向け QNX 8.0 イメージ、QNX Everywhere 動画、Self-Hosted Developer Desktop Guide が提供される
- 無料ライセンスは教育・個人プロジェクト・RTOS学習に限定され、商用目的の評価・開発には別途30日間の評価ライセンスを申請する必要がある
非商用向けQNX開発環境の提供
- QNX Everywhereは、学生、ホビー開発者、プロトタイパーがQNXソフトウェアを非商用目的で無料利用できるようにするプログラム
- 提供対象はQNXの次世代OS、開発ツール、リアルタイム機能で、学習・実験・高性能組み込みプロジェクトの制作に活用できる
- 公開されている数値として、QNX Everywhere ライセンスのダウンロード数は 15K+、登録済みオンライン教育受講者は 6K+、提携学術機関は 100+ がある
ライセンス申請の流れ
- 非商用ライセンスを受け取るにはmyQNXアカウントが必要
- 既存アカウントがあればログインする
- QNXを初めて使う場合は myQNX アカウントを作成する
- ログイン後、QNX Everywhere ライセンスフォームにライセンスデータを入力して申請を開始する
- リクエスト処理が完了すると、非商用利用向けのQNXソフトウェアライセンスを受け取る
- ライセンスは申請後、myQNXプロフィールに表示されるまで最大1時間かかる場合がある
含まれるプラットフォームとツール
- QNX SDP 8.0は次世代SoC向けの基盤開発プラットフォーム
- 次世代QNX Operating Systemを含む
- 将来のシリコン進化を活用できるよう設計されたアーキテクチャを掲げる
- IoT全般の計算集約型システムで一貫したリアルタイム性能を提供することを目指す
- 更新されたツールチェーン、デバッグ・プロファイリング用の新ユーティリティ、オープンソースユーティリティが含まれる
- QNX Everywhere には次のアクセス権が含まれる
- QNX SDP 8.0: 高性能でセーフティ対応可能なマイクロカーネルRTOSプラットフォーム
- QNX Developer Desktop: QNX OS 8.0 でアプリケーションをビルドするセルフホスト型デスクトップ
- QNX Hypervisor: ミックスドクリティカルシステム向けの決定論的ハイパーバイザー
教育、コミュニティ、オープンソース
- QNX は QNX OS 開発者向けに無料のオンライン教育コースを提供している
- 開発者はオンライン開発者コミュニティでQNXエンジニアとつながり、問題解決・アイデア議論・オープンソースプロジェクト協業を行える
- POSIX互換OSであるため、POSIXオペレーティングシステム向けソフトウェアのかなりの部分をほぼ修正なしでQNX向けにコンパイルできる
- QNX はオープンソース移植のソースコードを元のライセンスに従って公開しており、開発者が利用できるポートを GitHub repository で維持している
- ポート、テストレベル、ホスティングの詳細は Open-Source Dashboard で確認できる
ドキュメントと Raspberry Pi イメージで始める
- QNX Everywhere のドキュメントは、最初のアプリケーションから高度なQNXソリューションまで構築するために必要なツールとガイダンスを提供する
- 提供リソースは次のとおり
- QNX SDP 8.0 Quick Start Guide: QNX開発のスタートガイド
- QNX Quick Start Target Image for Raspberry Pi: Raspberry Pi向け QNX 8.0 クイックスタートターゲットイメージ
- Get Started With QNX Everywhere: QNX Everywhere 入門動画
- Self-Hosted Developer Desktop Guide: セルフホスト型開発者デスクトップガイド
- Raspberry Pi 5 ユーザーは、用意されたQNX SDP 8.0 イメージを書き込んで利用できる
- イメージには複数のオープンソースのデモアプリケーションが含まれる
- デモアプリケーションはクローン、修正、再ビルドできる
利用条件と対象外
- 無料ライセンスはQNX Software Development Platform 8.0の個人非商用ユーザー向け
- 許可される利用は、教育目的、個人プロジェクト、収益化や事業運営を伴わない活動
- 非商用利用には、学術環境、ホビー開発者、リアルタイムオペレーティングシステムの学習者が含まれる
- 商用目的の評価や開発は含まれない
- 商用活動には収益化または事業運営が含まれる
- 商用向けの30日間評価ライセンスは別途申請対象
- QNX SDP 7.1 はこのプログラムに含まれない
- QNX SDP 8.0 は CPU コアが4個以上のSoCベース次世代ソフトウェアプラットフォーム向けに提供される
教育機関での複数インストール
- 実習室や教室に複数のワークステーションを設定するには、QNX in Education プログラムで複数ユーザーライセンスを取得できる
- 対象には QNX Software Development Platform 8.0 と QNX Software Development Platform 7.1 が含まれる
- 一度に1つのインスタンスだけをインストールする場合は、QNX Everywhere ライセンスの利用が推奨される
アカウントとライセンスのトラブルシューティング
- 新しい myQNX アカウント登録後にログイン問題がある場合は、myqnx@blackberry.com に問い合わせる
- ライセンスと製品の配布状況はmyQNX License Managerで確認および承認できる
- myQNX アカウントプロフィールの Registered Products セクションには、配布済み製品ごとのライセンスキー、シリアル番号、ライセンス証明書、ライセンスマネージャーが表示される
- QNX Software Center をダウンロードするには、myQNX ユーザーに QNX 製品ライセンスが割り当てられている必要がある
1件のコメント
Hacker News の意見
信じられるなら良いのだが、QNX は過去に二度も「開かれた」あとまた閉じられた経緯がある
最初に撤回される前は、オープンソースプロジェクトが QNX をビルドターゲットに含めることがよくあり、QNX 向け Firefox と Eclipse のターゲットサポート、GCC や GNU コマンドラインツールのビルドも可能だった
Photon というデスクトップ環境もあり、DARPA Grand Challenge の車両を作っていたときには3年間メインのデスクトップとして使っていた
しかし 2004年に Harman が QNX を買収した後、それらはすべて消えた。2007年に再びソースが開かれ、マイクロカーネルまで中身を見てビルドできたが、公開ライセンスではなかった
2010年に RIM が QNX を買収すると、何の予告もなくソースを閉じ、QNX 関連のオープンソース開発はすべて止まり、コミュニティの信頼も失った
契約条件も問題だ: http://www.qnx.com/download/feature.html?programid=51624 には “TERMINATION. This Agreement and licenses granted hereunder may be terminated by either Party upon written notice to the other Party” とあり、QNX がいつでも打ち切れる
QNX が本気なら、Unreal Engine 式のライセンスに倣うのが妥当に見える。ソースをダウンロードして自由に使い、製品売上が100万ドルに達するまでは無料、その後は Epic が5%のロイヤリティを受け取る方式だ: https://cdn2.unrealengine.com/UnrealEngine/faq/UnrealEngineE...
違法コピーの問題も大きくない。ゲームが意味のある売上を出せば十分目立つので、ライセンス担当者の目に入るからだ
QNX の採用を増やしたいなら、Epic の条件表を法務チームと経営陣に持っていき、Unreal Engine の売上成長と QNX を比較してみるとよい
以前 QNX の営業担当者に言ったように、QNX の問題は違法コピーではなく、無視されていることだ
すべてのオープンソース活動が禁止されており、当時われわれの多くはオープンソースに活発に参加していた。私自身、Eclipse Foundation で働いたこともあった
小説を書いていた友人は、文章を一つ投稿したり出版したりするたびに書面での許可が必要だと言われた
ドイツ語訳が添付されていたにもかかわらず、拘束力を持つ言語は英語である契約にドイツ人エンジニアたちが署名するよう強いられ、結局われわれの多くはそのまま去った
カナダから来た移行チームが「RIM の社員は暗いコンクリートの地下牢で働いているのだから、ミュンヘンの素晴らしいオフィスを使い続けられるのがどれほど幸運か」と言っていたのが最も記憶に残っている
あの会社の DNA には、オープンなやり方というものが完全に異質に見えたし、少しも信用しない
趣味の開発者や自由・オープンソースプロジェクトは GPLv3 のオペレーティングシステムを喜んで使うだろうし、従来型の自動車・組み込み系の大口商用顧客は、ユーザーがカスタムファームウェアをインストールできるようにしなければならない GPLv3 の義務を望まないだろうから、引き続き費用を払うはずだ
すべての人にとって利益になり得る
法的助言ではなく、ライセンスの解釈は各自ですべきだ
BB10 が出る前にエンジニアたちと長く話したことがあるが、当時は Blackberry SDK 全体にアクセスするには申請が必要で、NDA にも署名しなければならなかったと記憶している
一方で Android と iOS はすでに勢いに乗っており、アプリを書きやすいプラットフォームを優先した側が成功した
Blackberry は、コミュニティとのこうした関係を扱うことに組織的に無能に見える。通信事業者的な「われわれ対彼ら」という考え方が組織の上層部にあり、明示的であれ暗黙的であれ下へ染み出している
BeOS が失敗した後、QNX をいじって開発し、メインの開発マシンでフルタイムに使うほど気に入っていた
ところが閉じられてひどく痛い目を見たため、それ以降はどんな閉じた開発プラットフォームにも手を出さなくなった
今ライセンスを見ると少しも変わっておらず、今では既存市場を除けば QNX はおおむね関連性が低くなっている
今日 QNX を選ぶのは愚かに見える。今は良い代替があり、それらはすべてオープンなライセンスを持っている
今では https://arstechnica.com/gadgets/2024/09/real-time-linux-is-o... もある
Linux を使えばライセンスの議論をする必要がなく、突然裏切られて閉じられる心配もない
商用利用禁止はひどい。今 ArangoDB で似たようなことを経験しているが、製品は良いものの、彼らが管理するクラウドインスタンスの予算も、商用ライセンスを営業チームと話し合う予算もない
複数のシステムで使っており、そのうち一つは「無料で使うには大きすぎる」データベースの80%くらいまで来ているが、その行く末がオープンソースになるのか、製品になるのか、直接収益を生むシステムになるのかは分からない
だから当面の近道は、自分のビジネスモデルを許可しないかもしれない人たちと話すことではなく、PostgreSQL に移行することだ
QNX 8.0 の非商用利用に関連する開発者規約を直接確認するならこちら: https://support7.qnx.com/download/download/51624/BB_QNX_Deve...
法的助言ではなく、このライセンスの包括的なレビューや解釈の要約でもない。以下の内容に基づいて行動する前に、弁護士から専門的な助言を受けるべき
規約は、ユーザーが自分自身・事業体・機関を拘束する前に確認して同意する機会がなかった、という趣旨の条項から始まっているが、米国では文書全体を無効にする可能性もありそうなので、使用前に弁護士と確認するのが安全
学術界では、その機関の学生と教員だけが資格を持ち、このライセンスの使用は法務部門の観点では雇用主を代表して拘束力のある契約に署名したものと見なされる可能性がある
オープンソース貢献者のせいで責任を負ったり、機関の署名権限者として自分を誤って表示したという理由で解雇されるリスクがないか確認する必要がある
クラウド利用者は規約上 AWS に限定されており、GCP、Heroku、または個人契約の管理下にない他のサーバーインスタンスで使うとライセンス料を請求される可能性がある
ここで許可される「Open Source」は OSI 定義のみなので、制限的な非商用ライセンスでソフトウェアを配布する人は QNX 非商用ライセンスを使用できない
「高リスク」条項は社会に害を及ぼし得るアプリケーションの開発を禁止しているため、ソーシャルアプリも除外される可能性がある。バイラルなアプリケーションを作っていてこの条項に違反しないよう注意が必要
この製品に関連して使用するすべてのハードウェアから、識別可能なすべてのシリアル番号を収集・保管する
非商用ライセンスは、条件を誠実に守っていたとしても、いつでも無条件で終了される可能性があり、その際には提供されたすべての QNX コードを削除したという、定義されていない「認証」を不明な費用で提供しなければならない場合がある
Twitter クライアントが落ちても、人がけがをしたり死んだりはしない
リアルタイム Linux が成熟している状況で、どんなプロジェクトで QNX を使う理由があるのか疑問。ライセンスを突然変えられて不意打ちを食らうことを気にしなければならないのか？
かわいくて学術的に興味深いという理由なら、過去に QNX を使ったことはある
だが次にプロジェクト用の SoC と付属の BSP を選ぶときに QNX を探すことはないだろう。同梱の FreeRTOS ディストリビューションを使うか、Android ビルドツールをインストールして、妙な Android フォークに APK を押し込むことになりそう
自動車や医療の分野なら話は違うだろうが、その分野でも競合は追い上げ続けており、Linux のリアルタイム対応によって状況はさらに厳しくなるはず
今は 2010 年ではない。選択肢は多く、QNX が不明瞭で厄介なライセンス要件の背後にとどまっている間に、何十社もの企業が代替を開発してきた。その中にはかなり大きいものもあり、宇宙まで行ったものもある
今や QNX が真剣に受け止められるには、「昔のように QNX の扉を開き始める」程度では足りない
商用利用まで含めた完全なオープンソースでないなら、使う気はない。ツールと BSP サポートが時間に見合うなら Epic 方式のライセンスは受け入れられるかもしれないが、始めるためにライセンス料を払うことにはまったく興味がない
製品はコモディティ化し、今では好奇心の対象でしかない。十分に活発な開発と採用を得る唯一の道は、コミュニティプロジェクトになること
誰もが自由・オープンソースかどうかを気にするわけではなく、こうした問題で人によって傾く方向が違うのは驚くことではない
2000年代初めに使ってみたOSの中で、古いシングルコアの90年代半ばのPentiumを見事にきびきび感じさせてくれたのは、QNXとBeOSだけだった
どのWindows版やLinuxよりもはるかに良かった
どちらの場合も、主にスケジューラと、ずっと優れたマルチメディアスタックのおかげだったのだと思う
未来のOSはそういう感触であってほしいとずっと願っていたが、最も近いのはたぶんiOSで、それもプロセスを次々に殺すという抜け道を使っている。未来はあまり良くない
当時の同時代のOSには巨大な単一ロックがあった
BeOSのプリエンプション間隔も750msだったか3msだったか記憶は曖昧だが、LinuxやWindowsの20ms、その後の10msより短く、それで違いを感じたのだろう
数十年後、ほとんどのOSはカーネル空間でより細かいロック粒度に追いついたが、プリエンプション間隔はスループット対レイテンシの議論のため、今も異なる。スクリプトベースのOSベンチマークは全体スループットを測るだけで、GUIの応答性を測らないからだ
小さなバッファサイズで恩恵を受けるメディアバッファが良い例で、スループットは落ちても音楽家たちはBeOSのより良い応答性に気づき、それで「Media OS」という異名が付いた
GUI空間でも、BeOS/Haikuのアプリサーバーは他のデスクトップ環境より分散されたワークロードを提供する。各ウィンドウは独自のスレッドを受け取り、アプリも独自のスレッドを受け取り、アプリとアプリケーションサーバーはアプリごと・ウィンドウごとに1つずつスレッドを持つことで、遅いアプリのメッセージ解析を待ってブロックされないようにしている
そのため、グラフィカルな「Hello World」ウィンドウを持つ最小のBeOSアプリでもスレッドは4つある。アプリが忙しくても、残りのシステムはなお応答性が高く感じられる
その代わりスループットのコストとアプリ開発の複雑さのコストがあり、特に移植アプリでは大きい
Haikuは、マルチスレッドのバグを防ぐため、Qt/Gtk/ツールキットのメッセージを複数のウィンドウから単一のメッセージキューへ整列させる必要がある。元の環境ではアプリのメッセージループがマルチスレッドではなかったからだ
この整列のため、不要な場合、例えば同じウィンドウ宛てのメッセージでも、Haikuでは追加のロック/アンロック呼び出しが必要になる
一方でHaikuネイティブアプリは氷のように滑らかだ。すべてのウィンドウが独自スレッドで動作するMedo動画エディタのスクリーンショットがここにある: https://raw.githubusercontent.com/smallstepforman/Medo/refs/...
現代のシステムではこのアプリは氷のように滑らかで、動画エディタとしては異端に近い。リンク先のHaikuアプリは私が書いた
Samsungでさえスマートフォンの応答性を真剣に改善しようとしなかった時期に、私はAndroidを捨てた
Appleが一貫して応答性を重視しているのは良いことで、そのおかげでGoogle、Samsung、Microsoftも肥大化した製品を見直す動機が生まれる
最近のOSの中で、そのきびきび感に最も近いのは何だろう？ Haiku OSだろうか？
M1 MacBookを快適に使っているが、時々十分ではないように感じる
もう一つの例として、SGI IRIXはスケジューラが例外的に良かった。30MHzのマシンをしばらく使っていたが、デスクトップはかなりきびきびしていた
ある日AMPをコンパイルし、ほとんどが192kbpsのMP3リストを入れた。ちなみにこのプログラムは256kbpsも途切れなくデコードできた
ファイルはNFS共有上にあり、gr_osviewを実行してみるとCPU使用率は95%だったのに、ファイルマネージャは反応し、音楽は途切れなかった
30MHzで192kbpsを超える高ビットレートMP3をデコードするだけでも印象的だった
X Window Systemのデスクトップ全体を立ち上げ、NFS共有からファイルを再生しながらも応答性を維持していたことは、低スペックのハードウェアでもうまく動作した軽量で強力なネットワークスタックとスケジューラを示している
IRIX 5.3、Indigo Elanだった
友人と私はOSが好きで、古いPentium 90でBeOSを動かし、上で述べたようにきびきびしていた
Linuxも一役買った。水濡れ被害の後、そのPentium 90はもう安定せず、パリティなしRAMを使っていたためWindows NTは徐々におかしくなってブルースクリーンを繰り返した
面白半分でRed Hat 5.2を入れたらうまく動いた。システムログには毎秒多くの項目が記録され、Xコンソールを開いてただ流れていくのを見ることができた
そのマシンは遊びで会社のWebページも数週間配信していた。良い時代だった
詳細を補足すると、QNXのソースコードは2007年から2010年のRIM/BlackBerryによる買収前までアクセス可能だった
今後QNXのソースコードへのアクセスを再び提供する計画はあるのか？
https://www.qnx.com/news/pr_2471_1.html
顧客とコミュニティの双方から、これが重要だという話を聞いている。引き続き見守ってほしい
以前の会社では、モバイルネットワーク向けの高可用性 Active/Standby ルーターを作っていて、OS に QNX を使っていた。その能力はいまでも印象的
記憶は曖昧だが、制御プレーンのプロセッサで QNX を動かし、ルーター内部ネットワーク経由でリモートプロセッサ上にプロセスを起動することをネイティブにサポートしていた
つまり低レベルのプロセス間通信が IP を使え、QNX の IPC は高可用性フェイルオーバー機能に不可欠だった
デバイスドライバがユーザー空間プロセスなので、クラッシュ時に再起動できるのも素晴らしかった。ネットワークドライバを開発中だったので、たまに実際にそういうことが起きた
Linux ではネットワークデバイスが例外的に /dev/ ツリーにきちんと現れないのと違い、デバイスが実際に /dev/ ツリーに見える点もより良かった
面白い逸話として、あるとき IPC の戻り値に誤って const を付けたせいで問題が起き、自分のプロセスが QNX の IPC 関数と自分の関数の間で死んだ
何日もデバッグしたが、当時使っていた C/ユーザー空間デバッガのレベルではそのエラーを見つけられなかった
ラインカードも Linux だったが、制御プレーンの指示どおりに ASIC をプログラムするだけだった
そうした機能は特に関係なく、IPC は HTTP でも好きな方法でもできた
@JohnAtQNX ウェブサイトのダウンロードですべてアカウントが必要という制限をなくし、qcc のライセンス機構も取り除けないだろうか？
趣味の開発者に試してもらう後押しとして大きな助けになるはず
収益はおそらく大量ライセンス契約から出ていて、端末ごとにライセンス料を取る構造だと思う
QNX 製品群をサポートしなければならない CI/CD チームを怒らせると、その収益源が危うくなる
外部からも同じ話を聞けるのはよいことで、もう一度議題に載せて少しずつ進めてみる
何か新しいものが出るたびに新しいログインを増やし続けるのが本当に嫌だ
ニュースフィードも同じで、ニュースサイトのほぼ半分が「無料」と言いながらログインを要求する。その場合は同じ記事を他で見つけやすいので、まだましではある
ウェブブラウザまで入っていた単一フロッピーの QNX デモに驚いた記憶がいまでも残っている。本当に速かった
うまくいってほしい。実際に何かを開放するために法的問題をすべて整理するのが、どれほど難しいゴルディアスの結び目なのかは想像するしかない
他の人たちが言っているように、二度も痛い目に遭った後なのでみんな慎重だが、QNX には楽しめる点が多いので、今回は勢いを得てほしい
それ以来 QNX にはある程度好印象を持っていたが、その間の所有権の変化や公開/商用状態の変更のせいで、ずっと距離を置いてきた
残念ながら今回の「開放」も見慣れた感じで、本当に開かれた GPL ライセンスと、フォークを維持できるほど大きな自由・オープンソースコミュニティが生まれない限り、また撤回されるように思える
大胆な試みは良い。昔から QNX を横目に興味深く見てきたが、ほとんどの場合、潜在ユーザーではなかった
良い次の一手は、よくある趣味プロジェクトのタイプを選び、その状況でQNX の強みをどう活かせるかを解説するブログ記事シリーズだと思う
沿岸警備の研究をする非営利団体でも働いていて、カスタムハードウェアを作っている人が数人いる。私たちにも役立つだろうか？
私たち Rizin は、自由・オープンソースのリバースエンジニアリングおよびデバッグフレームワークにおける QNX サポートを改善したい
すでにサポートはしているが[1][2][3][4]、安定してテストできない
Windows がテスト用の制限付き VM をすぐ提供しているように[5]、QEMU イメージが標準提供されるとよい
[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...
ただし Windows イメージのようにワンクリックでダウンロードできるほうが簡単だという点は理解しており、そのフィードバックは持ち帰る
QNX サポートを可能にするために他の形で手伝えることがあれば、DM するか qnxcommunityengagement at qnx dot com まで連絡してほしい