Qt wiki will be updated on October 12th 2023 starting at 11:30 AM (EEST) and the maintenance will last around 2-3 hours. During the maintenance the site will be unavailable.

Licensing-talk-about-mobile-platforms: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
Line 1: Line 1:
{{Cleanup | reason=Auto-imported from ExpressionEngine.}}
{{Cleanup | reason=Auto-imported from ExpressionEngine.}}
<font color="red">'''This information in this page is really really old. Don't rely on it.''' </font>


= Licensing Talk about Mobile Platforms =
= Licensing Talk about Mobile Platforms =

Latest revision as of 00:01, 11 May 2018

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine.
Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

This information in this page is really really old. Don't rely on it.

Licensing Talk about Mobile Platforms

This discussion revolved around licensing issues (if any) for app developers using the different mobile ports of Qt, mainly focusing on iOS and Android.

Who: Lars, Christy, Tukka, Ian, Markus, Espen (and some more I didn't catch the name of)

Qt for Android / Necessitas

As Qt for Android uses the LGPL version of Qt, and it's perfectly possible (and also recommended and supported) to dynamically link in the Qt libraries when creating an app - there are no problems for app developers using Qt for Android. The app developers can develop closed source code and publish the app - no worries.

Only if you statically link with the Qt libs could there be a problem with closed source apps.

Qt for iOS

On iOS it is possible to use a dynamically linked version of the Qt libraries, and have them bundled with the application. This allows the app to use the LGPL license for Qt whilst allowing the app itself to be closed source. It remains to be seen whether Apple will accept applications that bundle dylibs into the iOS App Store. If Apple does not accept applications that use bundled dylibs into the App Store, then it will be necessary to link Qt statically to the application. And as the Qt for iOS port uses the LGPL version of Qt, the rules for statically linking with LGPL will kick in - this can be a problem for closed source apps.

Commercial edition of iOS or Android etc?

Update: With Qt version 5.1 Digia is offering commercial license to develop for iOS and Android, thus it is now possible to purchase a commercial (Qt Enterprise) license when needed.

Would it be possible to have a commercial license of Qt that one could buy and use for Android and iOS? At the moment that is in question. The official company line from Digia (the company that has the right to sell Qt Commercial licenses) is that it is not permitted. Digia says they have an agreement with Nokia that excludes Qt on mobile phones or mobile tablets*.

Even if they had the right, as QML and QtWebKit at the moment uses LGPL code that Qt does not own the copyright for, it would still not be possible (for most modern apps) to avoid the rules that apply when statically linking with LGPL libs.

  • the exact wording of the agreement between Nokia and Digia is unknown. Qt licensees are bound by the terms of their Qt commercial license. A detailed discussion of these is given in the "commercial license analysis" section below.

Worst case scenario for LGPL usage

There is no legal ruling on what statical linking with an LGPL lib actually means in terms of open sourcing your code, but there are basically two camps:

Camp 1 means: If you statically link with an LGPL lib you have to provide the object files of your app so that other people can relink.

Camp 2 means: You have to provide the source code of your app.

If you are creating an open source app this is not a problem - but if you are creating a closed source on (for either yourself, or another company) this can be a big problem, especially if the way that Camp 2 interprets the LGPL ends up being what is ruled (in case of a lawsuit).

This means that a possible worst case scenario for an app developer using the Qt for iOS port at the moment might be he has to share his code with any recipient of his app (anyone who bought/downloaded it) if they so request. This might be a problem to explain to a customer who wants you to develop an iOS app for them :)

Qt for Windows 8

Tukka mentioned there might be some issues with Windows 8 but no one knew any details.

Qt5 license changes

With Qt5 the JavaScript engine for QML will change to use V8 which is not LGPL but BSD. This could help the current situation with iOS and static linking if the rest of Qt had some exemption for iOS (and other OS'es where dynamic linking was disabled).

Note: Summary written by Espen who is not a lawyer at all, and supplemented by Ian, who is not a lawyer either.

Legal advice on statically linking Qt and the LGPL license

There is debate in the legal and open source communities about whether static linking is permissible and this debate primarily centers around an inconsistency and circular reference contained in the license itself. Under the LGPL v. 2.1 a "Work that is based on the Library" is defined as either the Library itself or any derivative work thereof. As you are likely aware, the legal concept of a "derivative work" is largely a U.S. concept and many European jurisdictions don't use the derivative work concept. In the U.S. an application statically linked to a library would generally be considered to be a derivative work of the Library. The LGPL, however, also includes Section 5 which states that even though an application statically linked to the library may be a derivative work it is subject to Section 6 of the agreement which covers the requirements that must be met for a "Work that uses the Library" (i.e. application code).

The static linking issue has never been addressed by any courts in any jurisdictions that we are aware of, so it is impossible to provide concrete information on this issue. Additionally, there is certainly a substantial constituency in Open Source who believe that static linking is permissible.

From a Qt perspective, Nokia would like the Qt community to be a widely inclusive and diverse community, so it is highly unlikely they would want to test the static linking issue in court, provided that the licensee is otherwise complying with the LGPL.

Therefore, the static linking issue comes down to one of risk and how much risk you are willing to take. If you are willing to comply with the license by providing the complete corresponding machine readable source code for the Library and the application code in source or object code form (as required by Section 6(a) of the LGPL v.2.1) then you should be relatively safe.

Summary: Static linking with LGPL will typically cause your application to become a derivative work, and thus you need to license it under LGPL. In cases where you do not want to share the full source code of your application, it is typically the easiest solution to use commercial license of Qt.

Closer analysis of the "All OS" commercial Qt license terms

Update: From Qt version 5.1 Digia has modified the licensing terms of Qt Enterprise, and deployment to mobile platforms, including iOS and Android is possible.

There does not appear to be anything that would prevent the use of an "All OS" Qt license to build the Qt library for any mobile platform and distribute applications based on it.

Here are the sections of the "All OS" commercial Qt license agreement that may be applicable:

5.2 b) Licensee may not distribute, transfer, assign or otherwise dispose of Applications and/or Redistributables, in binary/compiled form, or in any other form, if such action is part of a joint software and hardware distribution, except as provided by a separate runtime distribution license with Digia or one of its authorized distributors. A joint hardware and software distribution shall be defined as either:

(i) distribution of a hardware device where, in its final end user configuration, the main user interface of the device is provided by Application(s) created by Licensee or others, using a commercial version of a Qt or Qt-based product, and depends on the Licensed Software or an open source version of any Qt or Qt-based software product; or

(ii) distribution of the Licensed Software with a device designed to facilitate the installation of the Licensed Software onto the same device where the main user interface of such device is provided by Application(s) created by Licensee or others, using a commercial version of a Qt or Qt-based product, and depends on the Licensed Software.

The distribution of Qt applications to end-user mobile devices through an "app store" does not in any way constitute "distribution of a hardware device", or "distribution of the Licensed Software with a device" - the very nature of distributing an application through an "app store" prevents its distribution with a hardware device.

5.2 c) Licensee's distribution of Licensed Software and/or Modified Software or Applications on Deployment Platforms requires a separate distribution license from Digia. Notwithstanding the above limitation, Licensee may distribute the Application in binary/compiled form onto devices running Windows CE provided the core functionality of the device does not depend on either the Licensed Software or the Application.

"Deployment Platforms" shall mean the Embedded Linux, Windows CE operating system(s).

The "Mac OS X" operating system is not based on Linux or Windows in either desktop or mobile form, and so is not covered by this limitation. Android is based on Embedded Linux, and so requires a separate distribution license from Digia. Windows Phone is based on Windows CE, and so also requires a separate distribution license from Digia (both provided with the "All OS" commercial license).

5.3 Further Requirements The Licensee is prohibited for using the Licensed Software for development of mobile phones, telecommunications devices or tablet devices focused at end-user consumers. The licenses granted in this Section 5 by Digia to Licensee are subject to Licensee's compliance with Section 8 of this Agreement.

The development of Qt applications for distribution to end-user mobile devices through an "app store" does not constitute "development of mobile phones, telecommunications devices or tablet devices focused at end-user consumers". The prohibition here is specifically for "development of (specific types of) devices focused at end-user consumers", not "development of applications for distribution to devices focused at end-user consumers" (ie. the licensee is prohibited from using Qt to develop hardware devices, either as or on behalf of a device manufacturer, and not from using Qt to develop software applications for hardware devices, as a 3rd party software developer).

Analysis of the terms on the Digia Qt License Certificate (for the "All OS" commercial license)

In addition to the "All OS" license terms (supplied with the commercial release of Qt 4.8.0), there is also applicable wording on the Qt License Certificate:

Development Platform(s) and Restrictions This certificate entitles a single developer to use the software for development on the following platform(s): X11, Windows, Mac, Embedded Linux, Windows CE, Symbian and as specified in the LICENSE FILE

The development platform used is "Mac OS X" on an Apple "Macintosh" computer for iOS, "Linux X11", "Windows" or "Mac OS X" for Android, and "Windows" for Windows Phone.

Deployment Platform(s) and Restrictions If permitted by the license agreement, developer may distribute applications on the following platform(s): X11, Windows, Mac, Embedded Linux, Windows CE, Symbian.

As per the analysis in the previous section, the "All OS" license agreement permits the licensee to "distribute applications" to any mobile platform provided that the Qt library is not used in a "joint hardware and software distribution", used for "development of mobile phones, telecommunications devices or tablet devices focused at end-user consumers", or to develop applications on which the "core functionality of the device" depends, and that an application that is deployed to Embedded Linux or Windows CE "requires a separate distribution license from Digia". The "All OS" commercial license includes "a separate distribution license from Digia" for those platforms.

iOS:

The deployment platform "Mac" listed above does not refer to a product name, either for an operating system, or a hardware device. The product name given to 68K/PPC/x86 architecture-based computers sold by Apple Computers is "Macintosh" or "The Macintosh personal computer". The operating system for the Apple Macintosh line of computers is called "Mac System" or "Mac OS". In the context above it is taken that "Mac" is intended to refer to "Mac OS", and not "Macintosh" computers (even though they are informally referred to as "Mac" computers), as all other terms listed as platforms refer to names of software, and not hardware products, and "Mac" computers are able to run many operating systems, including "Mac OS", "X11" (Posix-compliant OS with X-Windows server) and "Windows".

The only version of "Mac OS" that has ever been supported by Qt is "Mac OS X", hence "Mac" in this context is taken to imply "Mac OS X", also referred to as "OS X" by Apple Computers (on their website - http://www.apple.com/macosx ). Apple's product page for the original iPhone (on their website Jan 11, 2008 - archived at http://web.archive.org/web/20080111051348/http://www.apple.com/iphone/features/index.html ) states "iPhone uses OS X, the world's most advanced operating system". The iPhone version of "OS X" is known as "iPhone OS" or "iOS". The Apple iPhone, iPod, iPad and AppleTV product lines all use "iOS" for an operating system.

When building Qt for any version of "OS X" (including iOS), the target platform is set as 'macx' and the OS is set to Q_OS_MAC by the Qt build system. The Apple developer tools refer to "Mac OS X" on Macintosh computers as "i386-apple-darwin" and "iOS" as "arm-apple-darwin" ("Darwin" is the product name of the underlying operating system marketed as "Mac OS X" and "iOS"). When connecting to an iOS device, the Apple developer tools refer to the device as "remote-macosx".

As there are no particular definitions of "Mac" that exclude mobile "OS X" devices, or any other exclusions that prevent deployment of applications to iOS devices, the view is that "iOS" falls under the definition of "OS X", "Mac OS X" and hence "Mac" (which apart from branding is technically the same operating system product, "Darwin") and is hence is an allowed deployment platform.

As using a Qt commercial license doesn't require any disclosure on the part of the application developer as to whether Qt is used or not, and the "All OS" license can be viewed to cover iOS application development, it is really up to Nokia/Digia to discover the (otherwise licensed) application and take the (commercial) developer to court to contest this interpretation of the meaning of the term "Mac". Once again it comes down to risk, and the best advice is not to publicise that you are using Qt commercial for your iOS application, and you should be safe (as long as you adhere to all other license terms).

Android:

The Google Android operating system is based on Embedded Linux. Therefore it is permitted as an application deployment platform, as long as the developer has an "Embedded Linux" license.

Windows Mobile/Windows Phone:

The Microsoft Windows Mobile and Windows Phone operating systems are based on Windows CE. Therefore it is permitted as an application deployment platform, as long as the developer has a "Windows CE" license.

How to proceed?

As it appears that Digia's (and Nokia's) hands are tied regards making any official comment on or endorsement of Qt on iOS, Android or Windows Phone, it is recommended that one does not complicate matters by mentioning any of these platforms and Qt in the same context when either purchasing licenses or requesting support from Digia. Their employees are prohibited from making statements which could be interpreted as them allowing use of these platforms.