| | 1 | = Why Is There No Version of Pidgin for iOS? = |
| | 2 | |
| | 3 | 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. |
| | 4 | |
| | 5 | == The Apple Developer Agreement == |
| | 6 | |
| | 7 | 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. |
| | 8 | |
| | 9 | The additional restrictions required by Apple directly violate the GPL Pidgin is licensed under (Pidgin is licensed as GPLv2, 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. |
| | 10 | |
| | 11 | == Aren't There Workarounds For This? == |
| | 12 | |
| | 13 | Quite simply, no, there aren't. |
| | 14 | |
| | 15 | 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: |
| | 16 | |
| | 17 | 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.) |
| | 18 | 1. '''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. |
| | 19 | 1. '''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. |
| | 20 | 1. '''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. |
| | 21 | 1. ''(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. |
