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. Android’s 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 The real story here is not which carrier or

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 Apple’s
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
1
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 2 of mobile devices run
on an open-source platform (e.g., Android,
Symbian, MeeGo, LiMo, Linux Mobile)
• Increasingly the platform of choice is
Google’s 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.
Android‘s 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
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.
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 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
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.)
1 http://tech.fortune.cnn.com/2010/07/16/steve-jobs-confirms-android-outselling-
iphone/
2
2 Gartner chart, as shown in http://www.linuxfordevices.com/c/a/News/Gartner-2Q-
report-and-AndroidLinux-fork/
 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, Android’s collection of ~185 different
sub-components (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.
Android’s rich variety of open source software
assets are grouped into external and internal
categories. Two major external components -
Figure 1: The Android Architecture
3 Source: //developer.android.com/guide/basics/what-is-android.html
3 Gartner, as cited in http://www.linuxfordevices.com/c/a/News/Gartner-2Qreport-and-AndroidLinux-fork/
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
developed by Google includes changes outside
the Linux kernel, which created an initial fork.
From 2009’s V 1.5 ‘Cupcake’ release to today’s
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 Android’s fork out of sync.
Figure 2: Android Code Lines
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
Source: //source.android.com/source/code-lines.html
4
 the latest ongoing developments to stay in a
position to release their products immediately
after Android releases. Daily commits from the
community introduce new code, some of which
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 multi-
source 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,
5 managed.
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 you’re 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 company’s Android application
will potentially expose a company’s 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 customer’s final product
(e.g., a mobile phone), the developer may be
endangering its customer’s product (via viral
effect, injunctions, etc.), if the integration
with the Android platform was not correctly
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
don’t 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
requirements, etc.) that can add work to the
software developer’s 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
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. 6
 Best Practices
All companies that use open source software, including
those that use Android, should follow basic best
practices for ensuring license compliance:
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 Don’t 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 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
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 today’s mobile development
environments which put a premium on time-
to-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
The Black Duck Suite allows your software enterprises. The Black Duck Suite includes a
development organization to benefit from open robust SDK which enables integration with IBM
source and manage the complexity of Android Rational, Microsoft and many other development
while also allowing other stakeholders— tools and environments.
including legal, IT, security, export and
All participants in the mobile ecosystem -
purchasing personnel—to access timely and
developers, carriers and device manufacturers
relevant information to effectively manage
- benefit from the abundance and opportunity
business risks. With the Black Duck Suite,
of open source. With those benefits comes the
it’s simple to implement best practices while
need to manage its complexity, especially the
streamlining development and making the most
responsibility for appropriate management and
efficient use of development resources.
control of Android and all open source code
The Black Duck Suite addresses complexity before it makes its way into a final product.
- including the broad set of management, Black Duck Software minimizes complexity and
compliance, and security problems that surface opens mobile development to the abundance
when open source components are used at and opportunity of open source.
significant scale in software development.
Features that address these problems include
a searchable internal catalog, a customizable
approval workflow, and the industry’s 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
8
 About Black Duck Software
Black Duck Software is the leading global provider
of products and services for accelerating software
development through the managed use of open source
and third-party code. Black Duck™ enables companies
to shorten time-to-market and reduce development
and maintenance costs while mitigating the risks and
challenges associated with open source reuse, including
hidden license obligations, security vulnerabilities and
version proliferation.The company is headquartered near
Boston and has offices in San Francisco, Frankfurt, Paris,
Tokyo and Hong Kong, as well as distribution partners
throughout the world. For more information, visit www.
blackducksoftware.com.

Contact
To learn more, please contact:
sales@blackducksoftware.com
or call +1 781.891.5100
®

Additional information is available

at Black Duck’s web site:
www.blackducksoftware.com
WP-ADN-0910-UL-AB