Android - Opportunity, Complexity, and Abundance

Management is the challenge

Black Duck Software White Paper

Executive Summary
The Android mobile operating system is an excellent example of the power of open source software. Androids ascent is attributable not only to demand for feature-rich mobile devices but also to the flexibility, extensibility, and developer-friendly openness of the core Android project, which has brought similar and rich functionality to a wide variety of mobile devices, available from many carriers. Android is about abundance and opportunity for carriers, developers and consumers. Yet with opportunity and abundance comes complexity: managing development of software designed to extend an open-source operating system with parallel development forks, governed by multiple licenses, with rapid development cycles and frequent commits is not a simple task. In addition, because the core Android project is licensed under the permissive Apache license, misperceptions abound as to what it takes to comply with license requirements. Manufacturers that integrate Android into their products in a multi-source development process are combining open source with closed source code, and must manage that complexity at several stages as multi-source products flow through extensive supply chains with features (and complexity) added at every stage. In this white paper we describe the opportunity and challenge of developing for Android, look at its history, review licensing and IP issues and present a solution for managing its abundance and complexity.

Introduction
Blackberry and Palm paved the way for business, but the Apple iPhone revolutionized smartphones to the benefit of business and consumers alike. However, in July 2010, sales of mobile devices running the open-source Android operating system outstripped Apples
1

iPhone. Carriers activated more than 160,000 Android handsets a day - an estimated four million for the month - while Apple, with its closed-OS iPhone 4, reported activating a mere 70,000 units a day - roughly half as many.1 The real story here is not which carrier or company is dominating the market for mobile

devices. The big news is the shift in trends in mobile application development: Closed-source mobile devices (e.g. Blackberry, Palm) are rapidly losing share Some 60 percent of mobile devices run on an open-source platform (e.g., Android, Symbian, MeeGo, LiMo, Linux Mobile)
2

Alliance, a consortium of companies which included handset manufacturers, carriers and Google, was created to develop open standards for mobile devices. The consortium also announced its first project, Android, described as a platform for mobile devices based on the Linux kernel version 2.6. The Android operating system for mobile devices was made available as open source software under an Apache license in 2008. Android contains internal components (the platform) and external components (the Linux kernel and WebKit, under the GPL and LGPL licenses and various other components or projects, copyrighted by other owners). Android is also, in the tradition of open source, a community of developers taking advantage of what they see as free, open software upon which to build mobile applications.

Increasingly the platform of choice is Googles Android operating system. The Android success story is evidence of a shift away from a model where developers choices were constrained by the limited number of devices and operating systems to one where open source options have created unlimited potential for innovation, faster time to solution, and flexibility. This scenario favors Android, a Linux-based operating system with a burgeoning app market fed by open source software.

Androids Evolution to Open Source

Android began life as Android Inc., a start-up founded in 2003 by veterans of Danger, Wildfire Communications, T-Mobile and WebTV. The privately-held company, launched to develop software for mobile phones, was acquired by Google in 2005. In 2007, the Open Handset

Android Trends
Despite its recent successes against the iPhone, Android holds a small - albeit growing - share of the mobile device OS market. Symbian, the open source mobile OS which in 2009 held 51% market share, has seen erosion of its position to
1 http://tech.fortune.cnn.com/2010/07/16/steve-jobs-confirms-android-outsellingiphone/ 2 Gartner chart, as shown in http://www.linuxfordevices.com/c/a/News/Gartner-2Qreport-and-AndroidLinux-fork/

a 41.2% share. Similarly, RIM, which in 2009 held 19% of the market, saw its hold chipped to 17.2%. In the same time period, driven by sales of smartphones, Android moved from a 1.9% share to 17.2%, stunning growth in a segment long dominated by Symbian and RIM.
3

Android: The complexity inside

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, Androids collection of ~185 different subcomponents (see Figure 1: Android Architecture) 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.

Although smartphones started the ball rolling - the operating system has been used in more than 60 mobile phone models - use of Android is branching out to other portable and embedded devices (tablet computers, e-readers, netbooks, HDTVs etc.)

Figure 1: The Android Architecture

Source: //developer.android.com/guide/basics/what-is-android.html

3
3 Gartner, as cited in http://www.linuxfordevices.com/c/a/News/Gartner-2Qreport-and-AndroidLinux-fork/

Androids 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 complexity involved with managing the hundreds of components and multiple licenses and associated obligations presents challenges for mobile application developers, handset manufacturers that use Android, and third-party companies that develop software components for device manufacturers.

Rapid changes add functionality and richness, but forks create complexity
The Android project is continually evolving (see Figure 2: Android Code lines.) Android code

Figure 2: Android Code Lines

Source: //source.android.com/source/code-lines.html

developed by Google includes changes outside the Linux kernel, which created an initial fork. From 2009s V 1.5 Cupcake release to todays V 2.2 Froyo release, bug fixes, enhancements and patches have been added to the main project. Development occurs at such a rapid pace that there is an acknowledged large backlog of patches from Android back upstream to the Linux kernel which keeps the Linux kernel and Androids fork out of sync.
The Android project uses git as its SCM system. The project is split into over 242 git repositories, of which over 90 also have been forked from upstream projects. At any time there may be multiple active branches off of a number of code-lines separating stable code from experimental work. A wide ecosystem of OEMs and device builders make contributions into these hundreds of branches, while Google maintains a private code-line for deep development of sensitive future features involving confidential third party information. Android OEMs and device builders must continuously update their local copies with

may be specific to other OEMs devices. These changes need to be reviewed and tested for compatibility - and assessed for compliance. With this much development going on in parallel, it is imperative to have a strategy to manage the complexity, and to identify and approve changes going into products.

Multi-source development and what it means for the Android ecosystem

The Android community includes Google, independent application developers, third-party companies which develop software for mobile and embedded devices, and manufacturers that adopt Android as the OS for a given mobile or embedded device. The multi-tiered ecosystem represents multisource development at its best, yet it adds complexity to the Android platform. Independent developers may contribute code under a variety of licenses. Handset manufacturers may develop software IP to run on top of the Android OS, in addition to modifying and augmenting the Android codebase to suit a particular hardware or software design. Commercial software development companies creating 3rd-party applications may do all of the above: add IP to Android components, use a variety of licenses,

the latest ongoing developments to stay in a position to release their products immediately after Android releases. Daily commits from the
5

community introduce new code, some of which

and modify or augment the Android code base. With this complexity come license and IP management challenges. For example: With Android, the supply chain starts with Google. If youre a handset manufacturer that has modified Android code to take advantage of software or hardware feature designs, not knowing how the code and various components are integrated with your proprietary code may be an issue. Any enhancements or changes a company makes to the Android code could be considered intellectual property. Not knowing if your code is being re-used and/or mingled with another companys Android application will potentially expose a companys IP. If the Android application a developer creates contains other commercial 3rd party proprietary code, the developer might be in danger of exposing proprietary code. This may cause damage to customers (e.g., device vendors) and may require the developer to compensate its customers for their losses. If the application a software developer creates for the Android platform is not a final product but is to be integrated as a component in a customers final product (e.g., a mobile phone), the developer may be endangering its

customers product (via viral effect, injunctions, etc.), if the integration with the Android platform was not correctly managed. Clearly, managing compliance with the abundance of code and open source licenses used in the Android platform is a significant challenge.

Obligations in Android
The Android project contains over 19 different license types in over 185 different projects (or components.) Assuming each license is broken out into its respective obligations and those obligations are assigned to each component usage, over 1,700 obligations come into play. Of these over 1,000 are legal type obligations, while around 700 are developer type obligations. Fortunately most companies dont need to confirm compliance to over 1,700 obligations; many of the legal obligations can be reviewed once during internal license review. Legal obligations typically involve accepting a disclaimer of warranty, limiting liability, protection of trademarks or other items that generally do not add work for the developer. However, even the most permissive license typically has an obligation of acknowledgement and other obligations (marking modification, redistribution requirements, documentation
6

All companies that use open source software, including those that use Android, should follow basic best practices for ensuring license compliance:

Best Practices

requirements, etc.) that can add work to the software developers backlog of tasks. And, in fact, developer-level obligations often need to be managed, not at the component level, but at the file level. In a highly dynamic environment like Android development, where files are frequently updated from web repositories, keeping track of all these obligations can be daunting. For example, the Android-based Samsung Vibrant (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. Any files that do not comply with file-level obligations (such as removing copyright statements, incorrectly adding copyright statements, not documenting modifications and others), could be relatively apparent to the copyright holders and/or others. For many contributors to the open source

Adopt and enforce an open source and third party code policy.
Know what you are trying to do with open source, and develop a disciplined, written OSS policy and set of practices.

Identify and track all third party code that is used.

Check all sources for open source code. Develop a best practice that describes how to manage inbound code, an institutionalized policy for managing third-party and OSS code, and a documented process that the entire organization can understand and support.

Automate validation at the point of acquisition and in development.

Manual processes are not fast enough to aid in the discovery of hidden or potentially encumbered code. The more automation is in place, the better able a developer will be to take advantage of OSS code. Automation also minimizes the impact of OSS compliance policies on developers, who can stay focused on developing rather than tracking code provenance.

Automate monitoring and tracking of Android and its components.

Establish a workflow that makes tracking a simple, automated part of your development processes Dont forget to integrate with other systems, especially build and change management tools -a build system is a natural and convenient place to scan for third-party and OSS code and identify conflicts early.

Control component re-use and standardization.

Create an approved set of components that is accessible and usable by the entire development organization. Who needs 5 different parsers in one application?. 7

community, this acknowledgement is all they ask in return for the use of their software. Companies should - and can easily - put together tools and processes to make sure this acknowledgement happens. In the end, best practice stipulates that a developer or development organization understands which licenses, components, copyrights and files are in their code and what obligations result from that mix of third party software. Managing this with tooling that provides automated code scanning and reviews can increase the efficiency of development
organizations and reduce risk in an otherwise complex process.

outcomes, such as legal action, loss of good will in the open source community and unfavorable coverage in media channels may result.

Conclusion
Multi-source development with open source is inevitable in todays mobile development environments which put a premium on timeto-market, low cost, code reduction and re-use and flexibility. In mobile, where new device platforms are announced monthly and pressure to innovate is extreme, open source - especially Android - is the fast track to opportunity. Android is a complex open source project, with more than 185 components, 19 licenses and a rapidly evolving code base to which many are contributing. To benefit from the abundance and opportunity of Android, developers and development organizations need an automation platform and processes to manage complexity and provide visibility, control and compliance. Black Duck Software has the leading solution for automating the management of open source use
in a multi-source development environment.

The good news - managing complexity is a straightforward process

Many companies that use Android publish or make code available to the broader community, so any mistakes made in complying with open source licenses can be discovered by a review of the published code. This step is critical - if developers accidentally remove copyrights, add improper proprietary copyrights or fail to comply with other requirements of the license(s), undesired

The Black Duck Suite allows your software development organization to benefit from open source and manage the complexity of Android
8

while also allowing other stakeholders including legal, IT, security, export and purchasing personnelto access timely and relevant information to effectively manage business risks. With the Black Duck Suite, its simple to implement best practices while streamlining development and making the most efficient use of development resources. The Black Duck Suite addresses complexity - including the broad set of management, compliance, and security problems that surface when open source components are used at significant scale in software development. Features that address these problems include a searchable internal catalog, a customizable approval workflow, and the industrys most comprehensive KnowledgeBase (http://www.blackducksoftware. com/knowledgebase) of open source information. With the Black Duck Suite, mobile developers and development organizations can choose from an array of features to tailor a solution to their individual requirements. Unlike competitive offerings that focus on narrow aspects of licensing or security for individual users, the Black Duck Suite scales to provide an automation platform for open source management and compliance across global
9

enterprises. The Black Duck Suite includes a robust SDK which enables integration with IBM Rational, Microsoft and many other development tools and environments. All participants in the mobile ecosystem developers, carriers and device manufacturers - benefit from the abundance and opportunity of open source. With those benefits comes the need to manage its complexity, especially the responsibility for appropriate management and control of Android and all open source code before it makes its way into a final product. Black Duck Software minimizes complexity and opens mobile development to the abundance and opportunity of open source.

About Black Duck Software

Black Duck Software is the leading provider of products and services for automating the management, governance and secure use of free and open source software, at enterprise scale, in a multi-source development process. Black Duck enables companies to shorten time-tosolution and reduce development costs while mitigating the management, compliance and security challenges associated with free and open source software. Black Duck Software powers Koders.com, the industrys leading code search engine for open source, Ohloh.net, the largest community for and free public directory of open source, and The Olliance Group, the leading open source business and strategy consulting firm. Among the 400 largest software companies in the world, according to Softwaremag.com, the company is headquartered near Boston and has offices in San Mateo, California, London, Paris, Frankfurt, Hong Kong, Tokyo and Beijing. For more information, visit www.blackducksoftware.com.
2011 Black Duck, Know Your Code, Ohloh, SpikeSource, Spike, and the Black Duck logo are registered trademarks of Black Duck Software, Inc. in the United States and/or other jurisdictions. Koders is a trademark of Black Duck Software, Inc. All other trademarks are the property of their respective holders.

United Kingdom & Ireland

To learn more, please contact: info-uk@blackducksoftware.com or call +44 (0)208.582.1081

DACH
To learn more, please contact: info-germany@blackducksoftware.com or call +49 (69) 67733-196

France
To learn more, please contact: info-france@blackducksoftware.com or call +33 (0) 6 28 07 77 39 Additional information is available at Black Ducks web site: www.blackducksoftware.com
WP-ADN-0910-A4EUR-AD