OSCON: That "open phone" is not so open
Think that your Android smartphone is fully open? Aaron Williamson delivered some bad news to the audience at OSCON with his presentation Your Smartphone May Not Be as Open as You Think. Williamson, counsel for the Software Freedom Law Center, explained to the audience what components were still proprietary, and the problems with replacing those with open source components. Unfortunately, it doesn't look like a fully open phone is likely in the very near future.
Many LWN readers are already aware that Android phones contain proprietary components. However, the larger open source community, and certainly the consumer public that is not well-informed about goings on in open source development, are usually not aware how much proprietary software the Android phones depend on.
So what's open and what's not? Everything that's shipped by the Android Project is fine, but Williamson pointed out that manufacturers ship more than just Android with their phones. The phone manufacturers, companies like HTC, Motorola, and Samsung, produce the software to meld Android to the hardware it's shipping on. So it's not possible to ship an Android distribution that's completely open source that will work on any specific phone.
Some packagers do ship Android distributions, but they're not likely to have permission to ship all of the software that they include. For instance, there's CyanogenMod, which adds features not found in Android, but it's hard to ship such a distribution and stay on the right side of all the proprietary licenses. As a result, a typical CyanogenMod installation requires saving the proprietary code shipped with the phone to the side at the beginning, then reinstalling that software as one of the final steps.
What do you get if you remove most of the proprietary software? Williamson has done the research and managed to compile Android for an HTC Dream with as little proprietary software as possible. He kept three components necessary for making phone calls, and left the rest out. Without the proprietary components, the HTC Dream isn't quite a brick, but it might as well be. It's unable to take pictures or record video, connect to WiFi, connect to Bluetooth devices, or use GPS. This also leaves out the accelerometer, so the landscape mode doesn't work.
Of course that leaves plenty of functionality as well, but the phone is hardly as functional without the software as with. Unless a user is deeply committed to software freedom, they're unlikely to go to that extreme. So the goal should be to convince companies to open the software as much as possible.
Why They're Closed
Williamson pointed out that this problem is unlikely to be specific to Android, and when MeeGo or open source Symbian devices ship, they're likely to have the same problems. He also gave Google credit for working with the manufacturers and trying to get as much software available as open source as possible.
For the most part, Williamson says that mobile component manufacturers largely give the same reasons for proprietary licensing that PC component manufacturers used to avoid providing free drivers for video cards, sound cards, etc. The manufacturers are concerned that they'll lose the edge against competitors or will give away intellectual property. Manufacturers see little competitive value in being open. They don't want to use licenses (like the GPLv3) that would harm their ability to pursue patent infringement suits.
There's also the issue of regulatory agencies and their influence on radio components for Bluetooth, GSM, and WiFi. Whether that's a legitimate issue is debatable, but it does seem to concern quite a few parties. The result of these regulatory concerns isn't debatable, however: You're unlikely to find open source drivers for most of the radio components of phones, which makes it difficult to operate a phone with 100% open source software.
Williamson also said he didn't see it likely that the community could keep up with maintaining open source drivers without the cooperation of the hardware manufacturers. The device updates tend to move so quickly, and the skills required to develop and maintain the drivers without assistance, make it unlikely that the community would be able to maintain a 100% free Android system with drivers. Of course, Linux developers, who have managed to keep up with a lot of fast-changing hardware over the years, might just disagree.
What to Do?
For users who are concerned with software freedom, what can be done to acquire fully (or more) open phones or inspire vendors to sell them? Williamson said that it requires educating the vendors and, more or less, walking through the same process that the community went through with Intel, ATI, and other hardware vendors that have come a long way towards supporting software freedom.
He pointed out that the community can reward vendors that are relatively open. For instance he pointed out that enthusiasts should be avoiding Motorola phones as long as the company continues trying to block mods as it does with the Droid X. Aside from that, Williamson says there's not much for end users to do. The good news is that Williamson thinks we can move faster than with PC hardware, because we've been down the road before and the community knows how to talk to vendors.
When I spoke to Williamson after OSCON, he indicated that tablets are likely to have the same problems as handsets, and some additional issues as well. Because most of the tablet manufacturers to date are not working directly with Google or as part of the Android community, they are not only shipping a lot of proprietary software, but also likely to produce lower quality products and violate licenses. The last is almost certainly true as shipping tablets are rarely found to be in compliance with the GPL. Even though most of Android's licensing doesn't require much in the way of compliance, few vendors seem to be living up to the GPL'ed components.
For now, a truly open smartphone seems elusive, but the prospects over time look positive. Until then, users have to decide between seriously crippled devices or devices that are only largely free.
Index entries for this article | |
---|---|
GuestArticles | Brockmeier, Joe |
Conference | OSCON/2010 |
Posted Jul 29, 2010 1:09 UTC (Thu)
by karim (subscriber, #114)
[Link] (5 responses)
Posted Jul 29, 2010 1:49 UTC (Thu)
by yokem_55 (guest, #10498)
[Link]
Posted Jul 29, 2010 12:59 UTC (Thu)
by Webexcess (guest, #197)
[Link] (1 responses)
http://www.linuxsymposium.org/2010/view_abstract.php?cont...
Posted Jul 29, 2010 16:58 UTC (Thu)
by karim (subscriber, #114)
[Link]
I actually didn't attend this year, but I did ask Tim for his slides and they were excellent. I thought code drops were bad, but this ...
Posted Jul 29, 2010 21:30 UTC (Thu)
by jzb (editor, #7867)
[Link] (1 responses)
Posted Jul 29, 2010 21:37 UTC (Thu)
by karim (subscriber, #114)
[Link]
Posted Jul 29, 2010 2:24 UTC (Thu)
by smoogen (subscriber, #97)
[Link]
=======
The difference being is that PC hardware tends to live longer than phone hardware. A phone may only be in production for 6-18 months and the chips in it may not stay the same through the entire run. Then the lifetime of a phone for many people is 1-2 years at most. So by the time you have a driver, your phone is no longer sold, most people aren't using it, AND you can't be sure the driver will work for all of that model phone.
It takes the hardness of supporting Laptops due to constantly changing specs and increases it quite a bit. It is not an impossible task but I can see where it would be a lot more draining that dealing with even nVidia cards.
Posted Jul 29, 2010 7:35 UTC (Thu)
by tajyrink (subscriber, #2750)
[Link] (2 responses)
Still, the GPLv3 resistance seems relatively large because of the patent weapons that are wanted to be kept, and drivers surely will need more lobbying and educating. Not to mention the graphics chips part of the story.
Posted Jul 29, 2010 10:51 UTC (Thu)
by laf0rge (subscriber, #6469)
[Link] (1 responses)
For old GSM/GPRS devices it typically was a serial line with AT commands and a 3GPP-specified multiplex protocol (TS 07.10). In that case, anyone could write code to drive that modem.
But the modern high-end 3G chipsets typically have proprietary RPC interfaces that are running on top of a dual-ported RAM of some sort. So you end up having proprietary components speaking a proprietary protocol to a proprietary GSM/3G modem, rather than _only_ a proprietary modem.
Posted Jul 29, 2010 15:17 UTC (Thu)
by martinfick (subscriber, #4455)
[Link]
Posted Jul 29, 2010 12:27 UTC (Thu)
by cesarb (subscriber, #6266)
[Link]
Posted Jul 29, 2010 15:56 UTC (Thu)
by ssam (guest, #46587)
[Link]
the tricky bit is initial costs, and the volume to keep manufacturing costs down. but the opensource hardware people seem to be getting better at this (look at things like arduino and beagleboard)
OSCON: That "open phone" is not so open
OSCON: That "open phone" is not so open
OSCON: That "open phone" is not so open
OSCON: That "open phone" is not so open
OSCON: That "open phone" is not so open
OSCON: That "open phone" is not so open
OSCON: That "open phone" is not so open
OSCON: That "open phone" is not so open
OSCON: That "open phone" is not so open
OSCON: That "open phone" is not so open
gta02-core
OSCON: That "open phone" is not so open