Locked devices, GPLv3 and the path to mobile freedom

iPhone lockedIn a recent discussion with friends I realized that tivoization is a sub-optimal world to describe the problem that the Free Software community has with freedom being controlled by those that control the hardware.  The word clearly targets one specific company, so the problem gets somewhat reduced in scope. The real issue is not limited to companies exploiting the hard work of free developers, removing with hardware constraints the very freedom that developers wanted to grant to all users. There is more than that, and this is especially visible in the mobile environment.

Almost all existing handsets require applications to be signed before they can be executed. Depending on the mobile platform, these signing keys can be cheap or expensive and given to all or only to selected people. All of them are personal and they’re not supposed to be shared with third party. GPLv3 and its sister licenses, Affero GPLv3 and Lesser GPLv3, require developers to release the full installation instructions which include the private keys to sign the application. This is not requested by the license only to the manufacturers of User Products, like the word tivoization seems to suggest, but to everybody distributing GPLv3 software on locked down devices, like iPhone or BlackBerry.

Free Software Developers that want to re-use or release new code under the GPLv3 licenses face a dilemma: decide not to support locked devices or circumvent the GPLv3 requirement to distribute the signing keys with an additional permission. Option one means that almost all of cell phone users out there (over 2 billion people in 2005) won’t get to know Mobile Free Software. Option 2 means surrendering to the power of AT&T, Verizon, Apple, Microsoft and the like. Funambol requires copyright assignment for all contributions, so it can distribute the source code of its mobile clients under the vanilla AGPLv3 license, and the binaries are under a different license. It’s a hack that works as long as developers trust the company not to breach the social contract and it has limitations.

On the other hand, the GPLv3 anti-lock provision is there to protect Free Software Users from the risk to be bullied by the network operators, since you can lose the warranty or be kicked out of the network if you run software that is not blessed by the gate keepers of the mobile cloud.

Is there a third option? Does relaxing the GPLv3 provision really mean surrendering to the powers of the telecom operators, who twist the arms of the proprietary manufacturers? How can the Free Software community change the broken rules dictated by the Evil Lords of the Wireless Cloud?

7 thoughts on “Locked devices, GPLv3 and the path to mobile freedom

  1. I firmly believe that everyone who values freedom should completely reject platforms that don’t respect freedom through lock-down. Your question, however, comes up legitimately when thinking of users who already own a locked-down device. Should we tell them to throw it away entirely? If nothing else, that’s bad for the environment!

    I am starting to believe that the right answer is we should encourage (A)GPLv3’d applications that require the user to jailbreak the device to use it. If we had enough such applications, we could convince users to refuse un-jail-broken phones.

    The problem is that it’s likely a violation of your developer agreements with the phone providers to encourage a user to jailbreak to install a new application. If you have thoughts on how to solve that problem, I’m interested to hear them.

  2. I share the same belief. The problem with mobile devices is that I have yet to see one device that respects user’s freedom to make a phone call with free software. OpenMoko is showing the way, but it is still just a little more than a working prototype.

    The jailbreak option is only available on one platform, afaik, while for others it is either way too difficult and risky or not possible at all.

    Lets look at history: when GNU system was not finished, our community had to develop software for non-free platforms. We had to keep developing for non-free platforms until there was a critical mass of software available that makes it unnecessary to support non-free platforms. On mobile the main issue I see is that there are too many hardware platforms, making it very very complicated to reach that critical mass of useful free software.

    BTW Funambol is looking for a maintainer for the Cydia version of its iPhone client.

  3. Hi Drew, you can decide to trust or not another person or a company based on many reasons and it’s very difficult to generalize. Trust cannot be bought or sold and it cannot really be put down in a legal document like a contract.

    In this particular case, why not to trust Funambol?

  4. I don’t know enough about the architecture of mobile systems, but it strikes me that there ought to be some middle ground between “jailbreaking” (which I agree with bradley, seems like the best option out of a field of rather lousy options) and refusing to use the technology we already have or can afford. Furthermore the suggestion of looking at the history of GNU before the linux kernel, or before the viability of the linux desktop for a more general audience, seems like a good move.

    Is there an (effective) way to run some sort of sandbox or operating environment on these locked phones that could be released separately as binary and source (a la the Funabol example) that could then run unsigned apps, without breaking the agreement with the service provider. Or is this not technologically feasible?

    1. It depends: some mobile os allow unsigned applications to be installed and even to run on phones. The issue is that when this happens, the amount of things that the unsigned app can do is limited. For example, an unsigned app is often prevented to access the addressbook of the phone, or to access the network. And that may depend also on the customizations done by the network operator, since they can change the default behaviour. It’s a very complicated environment. Running a sandbox would incur into the same limitations: Java applet, for example, often suffer limited functionality for the same reasons.

Leave a Reply

Your email address will not be published. Required fields are marked *