Is GPLv3 doomed on mobile handsets?

Short answer: no, I don’t think so. But it will take lots of efforts for GPLv3 software to diffuse on handsets, too.

Longer answer. For us at Funambol it’s quite clear that not all of the Funambol clients can be distributed as binaries under the same AGPLv3 license that regulates the source. That’s because for platforms like BlackBerry and iPhone the binaries must be digitally signed with a developer key in order to be executed and run.’  GNU GPLv3 and its sister license Affero GPLv3 require that the recipient of binaries receive from the author the complete and corresponding source code:

Complete Corresponding Source Code also includes any encryption or authorization codes necessary to install and/or execute the source code of the work, perhaps modified by you, in the recommended or principal context of use, such that its functioning in all circumstances is identical to that of the work, except as altered by your modifications.

That is, Funambol cannot distribute the BlackBerry or iPhone binaries under the AGPLv3 without distributing also its own private dev keys, something that clearly cannot be done.

Now many people believe that since handset manufacturers and cell phone network operators are used to keep strong control over their hardware platforms and over their networks, then GPLv3 software will never be able to diffuse in the mobile environment.’  This criticism is not new and has also been discussed during the GPLv3 drafting process.’  But GPLv3 is not necessarily incompatible with embedded devices and with business models attached to them.

Most of the criticisms are either plain FUD or old habits (“that’s how it always was and will always be”). For example, one argument is that regulators like FCC mandate that devices that emit radio signals should not be modifiable; therefore hardware vendors refuse to release software for wireless systems under a free software license.’  Another is that network operators don’t like to give possibility to execute any software on their networks for fears of malware and lawsuits from their users (example: if a program gets out of control and starts sending thousands of sms from a cell phone, who’s going to pay?)

Criticisms like these may be hard to confute, but they must be fought back because we can’t let people believe that things can and should not change.’  We need a more focused effort.’  OpenMoko demonstrates that most of the concerns come from laziness, old habits. FSF can have a stronger role even if RMS doesn’t use a cell phone.

When you renew your support to FSF this year add a request for the High Priority Project: a fully free OS for cell phones. We have the OpenMoko hardware to start hacking, we have lots of software to get started. Lets make it better and put the Freedom word in mobile, too.





  1. Stefano, you might remember that I mentioned this problem in a recent discussion. Funambol as the company which owns the source code can side-step the issue by simply releasing the Funambol client binaries under a proprietary, closed-source license.

    But the open source community doesn’t have that option: it is impossible for anyone in the community to release a client for a platform like the BlackBerry or the iPhone. I don’t think that this is in Funambol’s own interest, is it? Now it is of course a fair and noble goal to appeal for more open platforms where (A)GPLv3 is a valid license, but it doesn’t help with the problem on existing platforms.

    Funambol could do something about it: license your software under the AGPLv3 with the additional permission to not be bound by the anti-tivoization clause. This is legal. I can get you a statement from Intel Legal about it, if necessary.

    What do you think?

  2. Speaking as a free software supporter I’d say that the problem lies in free-depriving platforms and tivoization clauses. Such problem would not go away with removal of the clause. I believe it would be a mistake to assume that Apple or RIM will never change their habits and that the free sw community should adapt instead.

    A much better solution is to stop buying/developing freedom-depriving handsets and start focusing on improving the freedom providing ones… which leaves the question open: is there one? At the moment the most promising looks the OpenMoko, although it seems limited (but so was the GNU/Linux desktop in 1999).

  3. So you are advocating that Funambol stops supporting the iPhone and BlackBerry by not releasing closed-source clients for these platforms? 😉

    I agree with you about the user and the choices that he or she has to make. But companies, including Funambol, simply don’t work like that: they have to put financial success above such questions. In case it wasn’t obvious, I’m now talking with my “commercial software developer” hat on, not as a developer of free software.

    For Funambol the interesting question is: can they ever hand over the maintenance of the iPhone and BlackBerry clients to the community? Not in the current situation and with the current license of the source code.

  4. Sure, companies have different priorities. But consider that for Funambol the community is already contributing to the development of BB and iPhone clients. Distribution of binaries will always be an issue that will need to be sorted out. Relaxing the terms of the license IMHO is not a good option, though, not for business neither for the community.