Like many, I have watched with satisfaction the rise and rise of the Android mobile phone platform. After all, at its heart lies Linux, and much of it is open source. But not all: leading phones contain major proprietary elements that mean that Android is not the perfect free software system we have all been waiting for. It is, however, one of the best we have got at the moment, and a good place to start from.
Aside from that contentious issue of just how free Android really is, there's another that's not talked about so much. This stems from the fact that Android is not a monolithic system, but is put together from literally hundreds of smaller pieces, most of which are open source. Of course, that's great news: this is how its supposed to happen in a world where you can mix and match elements. But as a fascinating new report [.pdf] from Black Duck makes clear, that code soup takes the complexity in dealing with licence proliferation to the next level:
Created using the GPLv2 licensed Linux kernel, Android is a Google project, and represents a fork in the Linux kernel. Despite its roots in the GPL, Android's collection of ~185 different sub-components is written under ~19 different open source licenses – most reciprocal, and not all OSI-approved. While the majority of Android code contributed by Google is governed by the Apache 2.0 license, a number of components mobile developers rely on are governed by other licenses.
Android's rich variety of open source software assets are grouped into external and internal categories. Two major external components the Linux kernel and WebKit – are governed by reciprocal licenses (GPLv2, LGPL.) In addition to the two major external components an additional 30+ internal components (dbus, grub, emma, e2fsprogs, bluez, Bison, etc.) also use reciprocal licenses (GPL, LGPL, CPL, etc.) Twenty-eight components use the GPL and five use the LGPL while others use non-OSI licenses such as the OpenSSL combined license and the Bzip2 license.
The problem, of course, is managing this huge diversity of licenses, taking into account all the different requirements. Even the simplest ones – like listing copyright holders – can be a major undertaking:
the Android-based Samsung VibrantTM (SGH-t959) phone has a legal acknowledgement section for all open source in the phone – and it is over 8,000 lines long. It specifically acknowledges hundreds of copyright holders; for many, this acknowledgement is specific to individual files or to a list of files. To comply with its publishing obligations, Samsung provides a download of the files on its Open Source Release Center website (http://opensource.samsung.com/) where anyone can access the files.
This is a problem that will get worse, not better, as open source moves ever-closer to the heart of consumer electronics, and as more large-scale projects start to put together open source components with many different licences. Android shows how powerful that can be – and the kind of challenges it brings with it. Now that this digital Pandora's box has been opened, the open source community needs to start thinking about how to manage the consequences in a more structured, scalable way.
Update: there are some interesting projects and tools listed here that might well help.