Why Is There No Version of Pidgin for iOS in the App Store?

We often see people asking why Pidgin isn't available for their iPhone, iPod Touch, or iPad. In fact, we see this question enough that it overshadows some of our most-asked FAQ's. Here's an attempt to explain it.

The Apple Developer Agreement

In a nutshell, the Apple Developer Agreement is the biggest "problem" preventing a Pidgin build for iOS devices. We won't quote the exact text here, but the Agreement requires that developers allow Apple to impose additional restrictions on applications above and beyond the application's own license. Among these additional restrictions are the well-known "5-device limit" and a prohibition on redistribution of the application. It is also quite clear from the terms of the Agreement that the developer of an application is not the distributor of the application in the App Store--Apple is.

The additional restrictions required by Apple directly violate the GPL Pidgin is licensed under (Pidgin is licensed as "GPLv2 or later," and cannot transition to GPLv3 for a number of reasons not suited for this topic). GPLv2 forbids adding restrictions above and beyond those included in the GPL's own text, thus any distribution via Apple's App Store is a direct violation of the GPL. This is the root of the problem.

Aren't There Workarounds For This?

Quite simply, no, there aren't.

Once the GPL incompatibility is explained, some people invariably ask a number of follow up questions or make statements intending either to make us think we missed something in declaring it impossible to have an iOS build or to call us idiots. Really, we know what we're doing with respect to our license, and we didn't overlook anything. We'll explain the common examples:

  1. But you wrote it; you can grant exceptions to the license - Sure, the people listed in the Developer Information window wrote the bulk of the Pidgin code, but we didn't write all of the Pidgin (or libpurple) code. Take a look at the COPYRIGHT file in the root of a Pidgin source repository or release tarball. Every person or company listed there holds copyright over some portion of the Pidgin and libpurple code, and we know for a fact that the list is not at all exhaustive--there are people who are missing from that list. The only (legal) way we can grant an exception to the license is for every copyright holder to agree to the exception, which both cannot and will not happen (some Pidgin developers are philosophically opposed to Apple's Developer Agreement and will never allow the necessary exception(s)). Also, since Pidgin relies on a number of external dependencies, these dependencies would have to be distributed in the app as well, thus an exception from each of the GPL'ed or LGPL'ed dependencies' copyright holders would be necessary as well. The likelihood of this happening is quite effectively zero. (The alternative, of course, would be to port libpurple and Pidgin to the iOS such that they do not require external dependencies, but the Pidgin and libpurple copyright holders would still have to grant GPL exceptions, which is a non-starter.)
  2. Apple isn't distributing the app, you are - Not quite. In the App Store model, the developer submits the application to Apple for review. That is the end of the developer's distribution of the application. As stated above, the Developer Agreement is quite clear on the matter--Apple is the distributor of the application to the end user, thus all distribution and redistribution terms of the GPL apply to Apple. Since Apple levies and enforces GPL-incompatible restrictions on applications, distribution of Pidgin through the App Store is a violation of the GPL.
  3. Fork it, then you can do whatever you want - That sounds great on the surface, but everyone who holds copyright on Pidgin and libpurple hold copyright over forks, as well, because the fork is a derivative work (from a copyright perspective, and yes, we realize this is an oversimplification, but it works for the purpose of this discussion). So every copyright holder for Pidgin and libpurple would still have to agree to an exception to the portions of the GPL incompatible with the App Store, even for the forked project.
  4. What if you wrote a new interface from scratch and just used libpurple? - The interface itself could be licensed in an App Store compatible manner in this case, or GPL exceptions could be made. Libpurple, however, would still be subject to the same trap of being impossible to grant exceptions on.
  5. (related to previous item) Rewrite it all from scratch - That would be a viable option, except none of us are insane enough to be willing to maintain two completely separate codebases. In addition, to some extent we, as Pidgin and libpurple developers, are "tainted"--it could be argued that similar code constructs in a hypothetical from-scratch reimplementation are derivative works of Pidgin and libpurple because of our knowledge of the Pidgin and libpurple code. Other clients already exist for the platform; users will just have to get along with what's already available there.

Refusal to Grant GPL Exceptions

The following developers (and possibly others) refuse to grant GPL exceptions for the purpose of App Store compatibility:

  • John Bailey
  • Ethan Blanton
  • Mark Doliner
  • Gary Kramlich

What If Someone Else Submits Pidgin to the App Store?

Anyone who holds copyright on Pidgin or libpurple would have the legal right to compel Apple to remove builds of Pidgin (or any application that uses libpurple) from the App Store, and it's 100% certain that at least one person who refuses to grant GPL exceptions would do so.

What About Other App Stores?

Other application distribution mechanisms, such as Cydia, may be a viable option for those willing to jailbreak their iOS devices. At the current time, no Pidgin developers have interest in making an iOS app that alternative mechanisms could distribute. We won't stop anyone who tries to make this happen, as long as the GPL is not violated in the attempt.

Last modified 4 years ago Last modified on 03/29/13 00:53:53
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!