Qt開発者が知っておくべきライセンスの話

はじめに

Qtは、デスクトップ、モバイル、組み込みシステムなど、多様なプラットフォームで動作するアプリケーションを開発するための強力なクロスプラットフォームフレームワークです。その柔軟性と豊富な機能セットにより、世界中の多くの開発者や企業に利用されています。しかし、Qtを効果的に、そして法的に安全に利用するためには、そのライセンスモデルを深く理解することが不可欠です。

Qtは「デュアルライセンス」モデルを採用しており、商用ライセンスとオープンソースライセンス（LGPLおよびGPL）の両方を提供しています。このモデルはQtのビジネスモデルの基盤であると同時に、開発者にとってはプロジェクトの性質や目的によって最適なライセンスを選択する必要があるという責任を伴います。適切なライセンスの選択と遵守は、法的な問題を回避し、知的財産を保護し、プロジェクトを円滑に進める上で極めて重要です。

この記事では、Qt開発者が知っておくべきQtのライセンスについて、その種類、それぞれの特徴、選択の基準、そしてライセンス条項を遵守するための具体的な方法を詳細に解説します。約5000語をかけて、Qtライセンスに関する疑問を解消し、自信を持ってQt開発に取り組めるようになることを目指します。ただし、本記事は一般的な情報提供を目的としており、法的な助言ではありません。具体的なプロジェクトにおけるライセンスの判断については、必ず法律専門家やQt Companyに相談してください。

Qtとは

QtはC++で記述された、クロスプラットフォームのUIツールキットおよびアプリケーションフレームワークです。以下のような特徴を持ちます。

クロスプラットフォーム: Windows, macOS, Linux, iOS, Android, 組み込みLinux, RTOSなど、広範なプラットフォームをサポートします。一度コードを書けば、異なるプラットフォーム向けにビルドできます。
豊富な機能: GUI開発のためのウィジェットやQML、ネットワーク、データベース、マルチメディア、XML/JSON処理、OpenGL/Vulkanによるグラフィックス、組み込みシステム向け機能など、多岐にわたる機能を提供します。
使いやすさ: 一貫性のあるAPI設計と、シグナル＆スロット機構による直感的なイベント処理により、開発効率が高いとされています。
高性能: C++ベースであるため、高いパフォーマンスを要求されるアプリケーションにも適しています。
活発なコミュニティ: 世界中に多くの開発者がおり、情報交換や問題解決が活発に行われています。

Qtのこれらの優れた特徴を享受するためには、その基盤となるライセンスについて正しく理解することが第一歩となります。

Qtのデュアルライセンスモデル

Qtは「デュアルライセンス」モデルを採用しています。これは、同じQtソフトウェアに対して、異なる2種類のライセンスオプションを提供するビジネスモデルです。

商用ライセンス (Commercial License): 有償で提供されるライセンスです。このライセンスを選択することで、ライセンス条項に定められた範囲で、開発したアプリケーションのソースコードを非公開にすることができます。主に商用製品としてQtアプリケーションを開発・配布する企業や個人が利用します。
オープンソースライセンス (Open Source Licenses): 無償で提供されるライセンスです。主にLGPL (GNU Lesser General Public License) と GPL (GNU General Public License) が利用されます。これらのライセンスを選択した場合、開発したアプリケーションやその配布方法に対して、オープンソースライセンス特有の制約（ソースコードの公開義務など）が発生します。

このデュアルライセンスモデルが存在する理由は、Qt開発を継続的にサポートするための資金を確保しつつ、オープンソースコミュニティによる開発への貢献や、無償でのQt利用を可能にするためです。開発者は、プロジェクトの目的、配布形態、予算などを考慮して、最適なライセンスを選択する必要があります。

商用ライセンスの詳細

Qtの商用ライセンスは、主にQt Companyによって提供されるサブスクリプション形式のライセンスです。オープンソースライセンスと比較して、以下のような特徴と利点があります。

特徴と利点:

ソースコード非公開の自由: 商用ライセンスの最大の利点は、開発したアプリケーションのソースコードを非公開にできる点です。オープンソースライセンス（特にGPL）では、開発したアプリケーションのソースコード公開義務が発生することがありますが、商用ライセンスではこの義務がありません。企業にとって、独自の技術やビジネスロジックが詰まったソースコードを秘匿できることは非常に重要です。
サポート: Qt Companyから公式サポートを受けることができます。技術的な問題が発生した場合に、専門家からのサポートを受けられることは、開発効率や問題解決のスピードに大きく貢献します。
メンテナンスとアップデート: 商用ライセンスには、長期的なメンテナンスとアップデートが含まれます。セキュリティ修正やバグ修正、新機能の追加などが継続的に提供されます。
追加モジュールとツール: 一部のQtモジュールやツールは、商用ライセンスでなければ利用できないか、または商用ライセンスでの利用がより容易な場合があります。（例: 特定の組み込み向け機能、追加ツールなど）
ロイヤリティフリー: Qt商用ライセンスでは、通常、開発したアプリケーションを配布する際にQtの使用に対して別途ロイヤリティを支払う必要はありません。ライセンス費用は開発者や利用者の数に応じて発生します。
組み込みシステム向け機能: 組み込みシステム開発向けの機能（Qt for Device Deploymentなど）やライセンスは、商用ライセンスとして提供されます。
明確な契約: 商用ライセンスはQt Companyとの契約に基づいています。これにより、ライセンスの範囲や義務が明確になり、法的なリスクを管理しやすくなります。

サブスクリプションモデル:

Qt Companyの商用ライセンスは、一般的にサブスクリプション形式で提供されます。提供されるプランは、対象となるプラットフォームや必要なサポートレベル、利用人数などによって異なります。代表的なものとしては、以下のような分類があります（名称や内容は変更されることがあります）。

Qt for Small Business: 中小企業向けのプラン。特定の年間収益や資金調達額以下の企業が対象となることが多いです。コストを抑えつつ商用ライセンスの利点を享受できます。
Qt for Startups: スタートアップ向けのプラン。Small Businessと同様に規模に制限がある場合があります。
Qt for MCUs: マイコン (Microcontroller Units) 向けのプラン。メモリやCPUリソースが限られた組み込みデバイス向けの開発に特化しています。
Qt for Embedded Linux: 組み込みLinuxシステム向けのプラン。デバイスへのデプロイメントに関連するライセンスや機能が含まれます。
Qt for Digital Cockpits: 自動車のインフォテインメントシステムなど、特定の産業向けソリューションに特化したプラン。
Qt for Medical Devices: 医療機器開発向けのプラン。特定の規制遵守に役立つ機能やドキュメントが含まれることがあります。
Qt for Automation: 産業用オートメーション分野向けのプラン。
エンタープライズ向けカスタマイズプラン: 大規模企業向けに、特定の要件に合わせてカスタマイズされたライセンスやサポートが提供される場合があります。

また、ライセンスのカウント方法にも種類があります。

Named User: 特定の個人に割り当てられるライセンス。その個人だけがQt開発ツールを使用できます。
Floating User: 組織内で複数の開発者がQt開発ツールを利用できますが、同時に利用できる人数に制限があります。開発者間でライセンスを共有する形になります。

商用ライセンスの費用は、プランや利用人数、期間によって大きく異なります。正確な費用や詳細については、Qt Companyに見積もりを依頼する必要があります。

商用ライセンスは、開発したアプリケーションをクローズドソースの商用製品として販売・配布したい場合や、公式サポート、特定の商用専用機能が必要な場合に最適な選択肢となります。

オープンソースライセンスの詳細

Qtは商用ライセンスと並行して、オープンソースライセンスのもとでも提供されています。主に利用されるのは、GPL (GNU General Public License) と LGPL (GNU Lesser General Public License) です。これらのライセンスは、フリーソフトウェア財団 (FSF) によって策定された、ソフトウェアの自由な利用、改変、配布を保証するためのライセンスです。

GNU General Public License (GPL)

GPLは、最も有名なフリーソフトウェアライセンスの一つです。QtではGPLv2とGPLv3の両方のバージョンが使用されています。

特徴: GPLの主要な特徴は、「コピーレフト」の原則です。GPLライセンスのソフトウェア（またはそれを基にした派生成果物）を配布する場合、そのソフトウェア全体のソースコードもGPLライセンスで公開しなければならないという強い拘束力があります。これは「GPL汚染」と呼ばれることもあります。
適用範囲: Qtにおいては、Qt Creatorのような開発ツール自体や、特定のQtモジュール（例: 一部のグラフィックスモジュール、組み込み向けの一部のモジュールなど、バージョンによって異なります。利用を検討しているモジュールのライセンスを個別に確認することが重要です）がGPLライセンスで提供されている場合があります。
開発への影響: GPLライセンスのQtモジュールを、開発するアプリケーションに静的リンクまたは動的リンクして使用した場合、そのアプリケーション全体がGPLの適用を受ける可能性が高くなります。つまり、アプリケーションのソースコードをGPLライセンスで公開する必要が出てくる可能性があります。
配布の義務: GPLライセンスのアプリケーションを配布する場合、要求に応じてソースコードを提供する必要があります。提供方法には、物理メディアによる配布や、ダウンロード可能な形式での提供などがあります。

GPLv2 vs GPLv3:

GPLv3はGPLv2の後継であり、いくつかの重要な変更点があります。

Tivoization対策: GPLv3は、ユーザーがソフトウェアの改変版を実行できないようにする技術（Tivoization）を防止するための条項を含んでいます。
特許条項: GPLv3は、特許によってフリーソフトウェアの利用が妨げられることを防ぐための条項を含んでいます。
互換性: GPLv3は、特定の他のライセンス（Apache License 2.0など）との互換性を改善しています。

GNU Lesser General Public License (LGPL)

LGPLはGPLの「より緩やかな」バージョンであり、QtではLGPLv2.1とLGPLv3の両方のバージョンが使用されています。LGPLの目的は、ライブラリとして利用されるソフトウェアの利用を促進しつつ、改変版のソースコード公開を義務付けることです。

特徴: LGPLライセンスのソフトウェア（ライブラリ）を動的リンクして使用するアプリケーションは、必ずしもLGPLまたはGPLでライセンスされる必要はありません。アプリケーション自体のソースコードを非公開にすることも可能です。これが、多くの商用アプリケーションでLGPLライブラリが利用される理由です。
適用範囲: Qtフレームワークの主要部分（GUIウィジェット、Coreモジュールなど）は、LGPLライセンスで提供されています。
開発への影響: 開発するアプリケーションがLGPLライセンスのQtライブラリに動的リンクする場合、通常、アプリケーションのソースコードを公開する義務は発生しません。ただし、Qtライブラリ自体を改変した場合は、改変したライブラリのソースコードをLGPLで公開する必要があります。
配布の義務: LGPLライブラリを使用するアプリケーションを配布する場合、いくつかの義務が発生します。
1. 通知義務: ユーザーに対して、アプリケーションがLGPLライブラリを使用していること、LGPLのライセンス条項、およびLGPLライブラリのソースコードを入手できることを通知する必要があります。アプリケーションの「バージョン情報」やドキュメントに記載するのが一般的です。
2. ライブラリ置換可能性: ユーザーがアプリケーションで使用されているLGPLライブラリのコピーを、ユーザー自身の改変版に置き換えることができるようにする必要があります。動的リンクはこの要件を満たす最も一般的な方法です。静的リンクの場合、この要件を満たすためには、アプリケーションのオブジェクトファイルまたはリンクに必要な他のファイルをユーザーに提供するなどの追加の措置が必要になる場合があります。LGPLv3では、静的リンクでこの要件を満たすことがより困難になる可能性があります。
3. ソースコード提供義務: アプリケーションがLGPLライブラリを静的リンクしている場合、またはLGPLライブラリを改変して使用している場合、LGPLライブラリ（改変版を含む）のソースコードをユーザーに提供する義務が発生します。動的リンクの場合は、Qt公式のソースコードの入手先（Qtダウンロードサイトなど）を通知することで済むことが多いです。

LGPL v2.1 vs LGPL v3:

LGPLv3はLGPLv2.1の後継であり、GPLv3と同様にTivoization対策や特許条項などの変更が含まれています。静的リンクに関する条項の解釈についても議論があり、LGPLv3で静的リンクを使用する場合、LGPLv2.1よりもユーザーによるライブラリ置き換え可能性の保証が厳しくなる可能性があります。

FSFによるライセンス分類:

GPLやLGPLはFSFによって策定されたフリーソフトウェアライセンスです。これらのライセンスの主な目的は、以下の4つの自由を保証することです。

プログラムを、目的に関係なく実行する自由 (Freedom 0)。
プログラムがどのように動作するかを研究し、必要に応じて改造する自由。ソースコードが利用可能であることは、この自由のための前提条件です (Freedom 1)。
プログラムのコピーを再頒布し、したがって隣人を助ける自由 (Freedom 2)。
プログラムを改変し、その改変を公開して、コミュニティ全体がその恩恵を受けられるようにする自由。ソースコードが利用可能であることは、この自由のための前提条件です (Freedom 3)。

GPLはこの4つの自由を強く保護するために、派生成果物にもライセンスの継承を要求します（コピーレフト）。LGPLは、ライブラリとして使用される場合に限り、アプリケーション自体へのコピーレフトの影響を軽減しています。

Qt Companyのオープンソース定義とポリシー（2018年以降）

Qt Companyは、Qtのオープンソース版の利用について、そのポリシーを明確化しています。特に2018年以降、商用目的でQtのオープンソース版を利用する場合の条件について、より厳格なスタンスを取るようになりました。

Qt Companyは、Qtのオープンソース版は「真のオープンソースプロジェクト」での利用を想定していると表明しています。彼らの定義における「真のオープンソースプロジェクト」とは、以下のような性質を持つプロジェクトを指します。

アプリケーションのソースコード全体がオープンソースライセンスで公開されていること: LGPLまたはGPL（または互換性のある他のオープンソースライセンス）で開発したアプリケーション全体のソースコードを公開している必要があります。
一般に広く利用可能であること: プロジェクトのソースコードは誰でもアクセス、利用、改変、配布できる状態である必要があります。
コミュニティによる貢献を奨励していること: プロジェクトはオープンな開発モデルを採用しており、外部からの貢献を受け入れている必要があります。

このポリシーに基づくと、以下のようなプロジェクトは、Qt Companyによって「真のオープンソースプロジェクト」とは見なされない可能性が高いです。

クローズドソースの商用製品: 開発したアプリケーションのソースコードを顧客や一般に公開しないプロジェクト。
社内ツール: 特定の企業内でだけ使用され、ソースコードが外部に公開されないツール。
非公開の学術研究プロジェクト: 特定の研究室や大学内でだけ使用され、ソースコードが公開されないプロジェクト。
フリーミアムモデル: 基本機能は無償（オープンソース）で提供し、有料機能はクローズドソースで提供するようなモデル（全体がオープンソースではない）。

もし、これらの「真のオープンソースプロジェクト」に該当しないプロジェクトでQtのオープンソース版を利用して開発した場合、Qt Companyは商用ライセンスの取得を推奨、あるいは必須としています。これは、たとえLGPLで開発し、技術的にはLGPLの条項（動的リンクや通知義務など）を遵守しているとしても、Qt Companyのポリシーに反する可能性があることを意味します。

このポリシー変更の背景には、オープンソース版を商用製品開発に利用しつつ、Qt Companyに収益をもたらさない利用者が増加したことへの対策があります。Qt Companyは、商用目的でQtを利用する企業には商用ライセンスを取得してもらい、そこからの収益でQtの開発・メンテナンスを継続するというビジネスモデルを強化しています。

したがって、Qtのオープンソース版を利用して開発する場合、開発するアプリケーションが「真のオープンソースプロジェクト」の定義に合致するかどうかを慎重に判断する必要があります。もし少しでもクローズドソースでの配布や、特定の組織内でのみ使用する予定がある場合は、商用ライセンスの取得を真剣に検討すべきです。

商用ライセンス vs オープンソースライセンスの選択基準

Qtのライセンスを選択する際には、プロジェクトの性質、目的、配布形態、予算などを総合的に考慮する必要があります。以下に主な選択基準をまとめます。

商用ライセンスを選択すべきケース:

開発するアプリケーションがクローズドソースの商用製品である: 最も一般的なケースです。独自のソースコードを公開せずに販売・配布したい場合は、商用ライセンスが必須です。
開発するアプリケーションが社内ツールであり、ソースコードを公開しない: Qt Companyのポリシーに基づけば、「真のオープンソースプロジェクト」ではないため、商用ライセンスが推奨されます。
公式の技術サポートが必要: Qt Companyからの直接的なサポートは商用ライセンスに含まれます。これは開発中の問題解決やリスク低減に繋がります。
長期的な安定供給とメンテナンスが必要: 特定のQtバージョンに対する長期サポートや、迅速なバグ修正・セキュリティアップデートが必要な場合は、商用ライセンスが適しています。
特定の商用専用機能やモジュールが必要: 一部の機能やアドオンは商用ライセンスでのみ提供されます。
組み込みシステム開発: 組み込みデバイスへのデプロイメントに関連するライセンス（Qt for Device Deploymentなど）は商用ライセンスとして提供されます。

オープンソースライセンス（LGPL/GPL）を選択できるケース:

開発するアプリケーション自体もオープンソースとして公開する: アプリケーション全体のソースコードをLGPLやGPLなどのオープンソースライセンスで公開する場合です。これはQt Companyが想定する「真のオープンソースプロジェクト」に該当します。
非営利目的での利用: 研究目的、教育目的など、収益を伴わない活動でQtを利用する場合。ただし、ここでも開発した成果物の公開義務（特にGPLの場合）には注意が必要です。
個人開発者が趣味や学習目的で使用する: 個人が学習や趣味でQtを使用し、開発したアプリケーションをオープンソースとして公開する場合は、オープンソースライセンスで十分な場合があります。

LGPL vs GPL の選択:

Qtのオープンソース版を利用する場合、LGPLかGPLかを選択する必要があります。

LGPL: アプリケーションのソースコードをクローズドにしたいが、Qtライブラリは無償で利用したい場合（ただし、Qt Companyのポリシーに注意が必要）。または、アプリケーション自体もオープンソースだが、より制限の緩やかなLGPLで公開したい場合。LGPLの義務（動的リンク、通知、ライブラリ置換可能性）を遵守する必要があります。
GPL: 開発するアプリケーション全体をGPLとして公開する場合。QtのGPLモジュールを使用したい場合も、アプリケーション全体がGPLの適用を受ける可能性が高いため、必然的にGPLを選択することになります。

選択の際の注意点:

Qt Companyのポリシー: オープンソース版Qtを商用利用（クローズドソースでの配布、社内利用など）する場合、Qt Companyのポリシーに反する可能性が高いことを理解しておく必要があります。ポリシー違反が発覚した場合、商用ライセンスのバックペイメントや法的措置を求められるリスクがあります。
特定のモジュールのライセンス: Qtの全てのモジュールがLGPLまたはGPLの両方で提供されているわけではありません。一部のモジュールはGPLのみで提供されている場合があります。開発で特定のモジュールが必要な場合は、そのモジュールのライセンスを確認することが重要です。GPLモジュールを使用すると、アプリケーション全体がGPLの適用を受ける可能性が非常に高くなります。
将来の計画: 現在はオープンソースで開発していても、将来的に商用化やクローズドソース化を検討する可能性がある場合は、最初から商用ライセンスを選択しておく方が無難です。後からライセンスを変更するのは、特に開発が進んでからでは困難な場合があります。

結論として、クローズドソースの商用製品として配布する場合や、社内ツールとして利用する場合、そしてQt Companyからのサポートや特定の商用機能が必要な場合は、商用ライセンスの取得が強く推奨されます。「真のオープンソースプロジェクト」としてアプリケーション全体をオープンソースで公開するのであれば、オープンソースライセンスを選択できますが、その場合でもLGPL/GPLの義務を正しく理解し、遵守する必要があります。

ライセンス条項の詳細と実践

ここでは、LGPLとGPLの主要な条項と、それを遵守するための具体的な実践方法について掘り下げます。

GNU Lesser General Public License (LGPL) の詳細と実践

LGPLを遵守するために最も重要なのは、「ライブラリの利用方法」と「ユーザーへの情報提供」です。

LGPL v2.1:

Section 6 (b) – ライブラリ置換可能性:
- 条文の要旨: LGPLライブラリを含む実行可能形式を頒布する場合、ユーザーが頒布者提供のライブラリのコピーを、ユーザー自身の改変版で置き換えることができるようにしなければならない。
- 実践方法（動的リンク）: LGPLライブラリ（.dll, .so, .dylibなど）とアプリケーションの実行可能形式を別々に提供し、アプリケーションが実行時にこれらのライブラリを動的にロードするようにします。これにより、ユーザーはLGPLライブラリのファイルをダウンロードサイトなどから入手した別のバージョンや改変版で置き換えることが可能になります。Qt開発においては、ビルド設定でQtを共有ライブラリとしてリンク（動的リンク）することが標準的であり、これがLGPL遵守の推奨方法です。
- 実践方法（静的リンク）: LGPLライブラリをアプリケーションに静的にリンクする場合、通常、Section 6(b)を満たすためには、以下のいずれかを行う必要があります。
  - アプリケーションをオブジェクトファイル形式で提供し、ユーザーが自分のLGPLライブラリのコピーとリンクして実行可能形式を生成できるようにする。
  - または、ユーザーがライブラリのコピーを改変し、その改変版とアプリケーションの既存のオブジェクトファイル（またはそれに類するもの）を再リンクして実行可能形式を生成するために必要な情報やファイルを提供する。
  - これらの要件を満たすのは非常に手間がかかり、実質的にアプリケーションのソースコードに近いものを公開する必要が生じる場合があります。そのため、LGPLライブラリを静的リンクしてクローズドソースのアプリケーションを配布することは、非常に困難であり、避けるべきです。
Section 6 (d) – 通知義務:
- 条文の要旨: アプリケーションがLGPLライブラリを使用していることを通知し、ユーザーにLGPLv2.1のライセンス条項のコピーを提供し、LGPLライブラリのソースコードを入手できる場所または方法を通知しなければならない。
- 実践方法:
  - アプリケーションの「バージョン情報」「アバウトボックス」「ヘルプ」メニューなどに、使用しているLGPLライブラリ（例: Qt Libraries）のリスト、著作権表示、および「本ソフトウェアはLGPLv2.1のもとで提供されるQtライブラリを使用しています」といった文言を記載します。
  - アプリケーションの配布物（インストーラーに含まれる、または別途ダウンロード可能にするなど）に、LGPLv2.1のライセンス条項全文をテキストファイルなどで含めます。Qtの配布物にはLICENSES/LGPL-2.1-only.txtなどのファイルが含まれています。
  - Qtライブラリのソースコードの入手先として、Qt公式のダウンロードサイト（https://www.qt.io/download など）のURLを通知します。もしQtライブラリを改変して使用している場合は、改変版ライブラリのソースコードを提供する必要があります（自身のウェブサイトでの公開、要望に応じた提供など）。
Section 11 & 12 – 無保証および責任の制限: LGPLライブラリは無保証で提供され、利用による損害について頒布者は責任を負わないことが記載されています。これは開発者だけでなく、エンドユーザーも認識しておくべき点です。

LGPL v3:

LGPLv3の主な変更点はGPLv3と共通しており、Tivoization対策や特許条項などが含まれます。静的リンクに関するSection 4(d)の解釈も、LGPLv2.1より厳しく、静的リンクを使用する場合の義務履行がさらに困難になると考えられています。LGPLv3でも、動的リンクがLGPL遵守の最も安全で推奨される方法であることに変わりはありません。

GNU General Public License (GPL) の詳細と実践

GPLは「コピーレフト」により強い制約を課します。

派生成果物 (Derivative Work) の概念: GPLライブラリに静的リンクまたは動的リンクされたアプリケーションは、通常、GPLライブラリの「派生成果物」と見なされます。この派生成果物全体がGPLライセンスの適用を受けるというのがGPLの原則です。
配布の義務:
- 条文の要旨: GPLライセンスのプログラム、またはその派生成果物を配布する場合、配布先に対してプログラムのソースコードを提供する義務が発生します。
- 実践方法:
  - ソースコードの同梱: アプリケーションの実行可能形式と一緒にソースコードを配布物に含めます。
  - ソースコード提供の申し出: アプリケーションの配布物に、特定の場所（例: ウェブサイトのURL）からソースコードをダウンロードできること、または要望に応じてソースコードを物理メディアで提供する旨を記載した書面を添付します。この提供は、実行可能形式の配布から一定期間（GPLv2では3年、GPLv3では配布停止から3年）行う必要があります。
  - ネットワーク経由での配布: ネットワーク上でプログラムを提供する（ウェブサービスなど、ただしAGPLがより適している場合もある）場合も、ソースコード提供義務が発生します。
ライセンスの適用: GPLライブラリを使用するアプリケーション全体をGPLライセンスで配布する必要があります。これは、アプリケーション独自のソースコードも含めてGPLで公開することを意味します。
GPLv2 vs GPLv3: GPLv3は、Tivoization対策や特許条項などにより、GPLv2よりもさらに強いコピーレフトや制約を持ちます。Qtの一部のGPLモジュールはGPLv3でのみ提供されている場合があります。

ライセンス遵守のチェックリスト（LGPLの場合）

LGPLでQtを使用する場合、アプリケーションを配布する前に以下の点を確認しましょう。

Qtを動的リンクしているか？（静的リンクは避けるべき）
アプリケーションの「バージョン情報」などに、Qtを使用している旨、著作権表示、ライセンス（LGPLv2.1またはLGPLv3）を通知しているか？
アプリケーションの配布物に、LGPLのライセンス条項全文（LICENSES/LGPL-2.1-only.txtなど）を含めているか？
ユーザーがQtライブラリのソースコードを入手できる場所（Qt公式ダウンロードサイトのURLなど）を通知しているか？
もしQtライブラリ自体を改変している場合、改変版ライブラリのソースコードをLGPLで公開しているか？
Qt Companyのオープンソースポリシー（「真のオープンソースプロジェクト」であること）を満たしているか？（特に商用利用の場合）

これらの義務を怠ると、ライセンス違反となります。

開発者が陥りやすい落とし穴

Qt開発者がライセンスに関して陥りやすい落とし穴をいくつか挙げ、その対策を考えます。

ライセンス条項を読まずに使用する:
- 落とし穴: Qtをダウンロードし、すぐに開発を始めてしまう。どのライセンスが適用されているか、その条項が何であるかを理解しないまま使用を続ける。
- 対策: プロジェクト開始前、またはQtの利用を検討する初期段階で、Qtのライセンスモデルについて学習し、プロジェクトに適用されるライセンス（商用かOSSか）および具体的なライセンス条項（LGPLv2.1, LGPLv3, GPLv2, GPLv3など）を必ず確認する。Qt Companyのウェブサイトや公式ドキュメントを参照する。
動的リンクの要件を理解していない（LGPL）:
- 落とし穴: LGPLはクローズドソースで使えるらしい、と聞きかじり、深く考えずにQtライブラリをアプリケーションに静的リンクしてしまう。
- 対策: LGPLライブラリをクローズドソースのアプリケーションで利用する場合、原則として動的リンクが必須であること、静的リンクではユーザーによるライブラリ置換可能性の保証が非常に困難になることを理解する。Qt開発においては、ビルドシステム（qmake, CMake）の設定で、Qtライブラリが共有ライブラリとしてリンクされるようにする。デフォルト設定では通常動的リンクになりますが、設定を変更した場合は注意が必要です。
OSS版Qtで開発した商用製品を、ライセンス違反の状態で販売してしまう:
- 落とし穴: LGPLで開発すれば商用製品として販売できる、と誤解し、LGPLの義務（通知、ソースコード提供の申し出、ライブラリ置換可能性など）を怠ったまま、またはQt Companyの「真のオープンソースプロジェクト」ポリシーを満たさない状態で製品を配布してしまう。
- 対策: クローズドソースの商用製品を開発・配布する場合は、商用ライセンスを取得するのが最も安全で推奨される方法です。もしLGPLで配布する場合は、前述のLGPL遵守チェックリストの項目をすべて満たしていることを確認し、さらにQt CompanyのOSSポリシーとの整合性について検討する。リスクを避けたいのであれば、迷わず商用ライセンスを選択する。
特定のQtモジュールがGPLであることを知らずに使用してしまう:
- 落とし穴: Qtには多数のモジュールがあり、その中にはGPLライセンスでのみ提供されているものがある。開発中にこれらのGPLモジュールを安易に使用してしまい、アプリケーション全体がGPLの適用を受けてしまう可能性があることに気づかない。
- 対策: 開発で使用するQtモジュールについて、それぞれのライセンスを確認する。QtのドキュメントやインストールされているQtのLICENSEファイルを参照する。もしGPLモジュールを使用する必要がある場合、アプリケーション全体をGPLで公開する覚悟が必要となるか、または商用ライセンスでそのモジュールが提供されているかを確認し、必要に応じて商用ライセンスを取得する。
ビルドツールやIDE（Qt Creatorなど）のライセンスと、生成されるアプリケーションのライセンスを混同する:
- 落とし穴: Qt Creator自体はGPLで提供されているが、これは開発ツール（IDE）のライセンスであり、通常、Qt Creatorを使って開発したアプリケーションのライセンスには影響しません。しかし、これを混同して、Qt Creatorを使ったらアプリケーションもGPLになると思い込んだり、逆にQt CreatorがGPLだからQtのオープンソース版は自由に使えると誤解したりする。
- 対策: 開発ツール（Qt Creator, qmake, CMakeなど）のライセンスは、生成されるアプリケーションのライセンスとは独立して考える。アプリケーションのライセンスは、アプリケーションがリンクまたは使用するQtライブラリやモジュールのライセンスによって決定されます。
Qt CompanyのOSS定義変更（2018年以降）への理解不足:
- 落とし穴: 過去の情報に基づき、「LGPLなら商用利用OK」と信じ込み、現在のQt CompanyのOSSポリシー（「真のオープンソースプロジェクト」以外は商用ライセンス推奨）を把握していない。
- 対策: Qt Companyの最新のライセンスポリシー、特にオープンソース版の利用に関する定義を理解する。公式ウェブサイトのライセンスFAQやドキュメントを確認する。疑問点があればQt Companyに直接問い合わせる。

これらの落とし穴を避けるためには、Qtライセンスに関する情報を常に最新の状態に保ち、プロジェクトの計画段階でライセンス戦略を明確にすることが最も重要です。

組み込みシステムにおける考慮事項

組み込みシステム開発においてQtは非常に人気がありますが、そのライセンスについてはデスクトップやモバイル開発とは異なる考慮事項があります。

デプロイメントライセンス: 組み込みデバイスにQtアプリケーションをデプロイする場合、通常、Qt for Device Deploymentのような特定の商用ライセンスが必要です。これは、LGPLの「ユーザーによるライブラリ置換可能性」の要件を組み込みデバイスで満たすのが困難であることや、デバイスメーカー向けの特定のライセンスモデルが必要となるためです。Qt Companyは、組み込み製品へのQtデプロイメントに対しては、商用ライセンスを必須としています。
静的リンクの可能性: 組み込みシステムでは、リソースの制約からライブラリを静的リンクしたい場合があります。しかし、LGPLライブラリを静的リンクしてクローズドソースの組み込みファームウェアとして配布する場合、前述のようにLGPLの義務（特にライブラリ置換可能性の保証）を遵守するのが非常に困難です。これは商用ライセンスが必要とされる大きな理由の一つです。
OSのライセンス: 組み込みシステムでは、LinuxのようなオープンソースOSが使われることが多いです。OS自体のライセンス（GPL, LGPLなど）と、その上で動作するQtアプリケーションのライセンスの互換性にも注意が必要です。
特定の組み込み向けモジュール: QtにはQt for Embedded Linuxなど、組み込みシステムに特化したモジュールや機能があります。これらのモジュールの一部は、商用ライセンスでのみ提供されている場合があります。
長期サポート: 組み込み製品は長期にわたってメンテナンスされることが多いため、使用するQtバージョンに対する長期的なサポートが必要になります。これは商用ライセンスの大きな利点の一つです。

組み込みシステムでQtを利用する場合は、特にQt Companyに相談し、適切な商用ライセンスを取得することが強く推奨されます。

ライセンス違反のリスク

Qtのライセンス条項を遵守しないままアプリケーションを開発・配布した場合、以下のようなリスクに直面する可能性があります。

Qt Companyからのライセンス監査 (Audit): Qt Companyは、企業が適切なライセンスを使用しているかを確認するためにライセンス監査を行うことがあります。監査の結果、ライセンス違反が判明する可能性があります。
バックペイメント: ライセンス違反が判明した場合、過去に遡って適切な商用ライセンス費用（およびペナルティ）の支払いを求められることがあります。これは高額になる可能性があります。
法的措置: ライセンス契約違反として、Qt Companyから差止請求や損害賠償請求などの法的措置を取られる可能性があります。
レピュテーションの低下: ライセンス違反の事実が明らかになった場合、企業や個人の信頼性が失墜し、レピュテーションが大きく損なわれる可能性があります。
製品の販売停止: ライセンス問題を解決するまで、対象となる製品の販売や配布を停止せざるを得なくなる可能性があります。

これらのリスクを避けるためにも、Qtのライセンスについては常に注意を払い、適切なライセンスを選択し、その条項を確実に遵守することが不可欠です。

まとめ

Qtは非常に強力で柔軟なフレームワークですが、そのデュアルライセンスモデルは開発者にとって理解が必須の要素です。商用ライセンスは、クローズドソース製品の開発、公式サポート、特定の機能へのアクセスなど、商用目的での利用に多くの利点を提供します。一方、オープンソースライセンス（LGPL/GPL）は、真のオープンソースプロジェクトでの利用を可能にしますが、特にLGPLの動的リンク要件や通知義務、GPLの強いコピーレフトなど、厳格な条項の遵守が必要です。

特に、Qt Companyの2018年以降のポリシーでは、オープンソース版Qtは「真のオープンソースプロジェクト」での利用を想定しており、クローズドソースの商用製品や社内ツールでの利用には商用ライセンスが強く推奨されている点を理解しておくことが重要です。LGPLで開発する場合でも、Qt Companyのポリシーとの整合性を慎重に判断する必要があります。

Qtをプロジェクトに採用する際は、開発の目的、配布形態、予算、必要なサポートレベルなどを総合的に考慮し、最適なライセンスを選択してください。そして、選択したライセンスの条項（特にLGPLの動的リンク、通知、ソースコード提供に関する義務）を正確に理解し、開発プロセス全体で確実に遵守するように努めてください。迷った場合は、必ずQt Companyの担当者や法律専門家に相談することをお勧めします。

適切なライセンス管理は、プロジェクトの成功と法的な安全性を確保するための重要なステップです。本記事が、Qt開発者の皆様がQtライセンスについて深く理解し、自信を持ってQt開発に取り組むための一助となれば幸いです。

免責事項

本記事はQtライセンスに関する一般的な情報を提供することを目的としており、法的な助言ではありません。具体的なプロジェクトにおけるライセンスの選択、条項の解釈、および遵守方法については、必ずQt Companyの担当者または法律専門家にご相談ください。本記事の内容に基づいて行われたいかなる行為についても、筆者は責任を負いかねます。