8/6/2019 Android UL

1/12

Android - Opportunity, Complexity,and AbundanceManagement is the challenge

Black Duck Software White Paper

8/6/2019 Android UL

2/12

Introduction

Blackberry and Palm paved the way or

business, but the Apple iPhone revolutionized

smartphones to the benet o business and

consumers alike. However, in July 2010, sales

o mobile devices running the open-source

Android operating system outstripped Apples

iPhone. Carriers activated more than 160,000

Android handsets a day - an estimated our

million or the month - while Apple, with its

closed-OS iPhone 4, reported activating a mere

70,000 units a day - roughly hal as many.1

The real story here is not which carrier or

company is dominating the market or mobile1

Executive SummaryThe Android mobile operating system is an excellent example o the power o open source

sotware. Androids ascent is attributable not only to demand or eature-rich mobile devices but

also to the fexibility, extensibility, and developer-riendly openness o the core Android project,

which has brought similar and rich unctionality to a wide variety o mobile devices, available

rom many carriers.

Android is about abundance and opportunity or carriers, developers and consumers. Yet with

opportunity and abundance comes complexity: managing development o sotware designed

to extend an open-source operating system with parallel development orks, governed by

multiple licenses, with rapid development cycles and requent 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.

Manuacturers 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 fow through extensive supply chains with eatures (and

complexity) added at every stage.

In this white paper we describe the opportunity and challenge o developing or Android,

look at its history, review licensing and IP issues and present a solution or managing its

abundance and complexity.

8/6/2019 Android UL

3/12

devices. The big news is the shit in trends in

mobile application development:

Closed-source mobile devices (e.g.

Blackberry, Palm) are rapidly losing share

Some 60 percent 2 o mobile devices run

on an open-source platorm (e.g., Android,

Symbian, MeeGo, LiMo, Linux Mobile)

Increasingly the platorm o choice is

Googles Android operating system.

The Android success story is evidence o a shit

away rom a model where developers choices

were constrained by the limited number o

devices and operating systems to one where

open source options have created unlimited

potential or innovation, aster time to solution,

and fexibility. This scenario avors Android, a

Linux-based operating system with a burgeoning

app market ed by open source sotware.

Androids Evolution to Open Source

Android began lie as Android Inc., a start-up

ounded in 2003 by veterans o Danger, Wildre

Communications, T-Mobile and WebTV. Theprivately-held company, launched to develop

sotware or mobile phones, was acquired by

Google in 2005. In 2007, the Open Handset

Alliance, a consortium o companies which

included handset manuacturers, carriers and

Google, was created to develop open standards

or mobile devices. The consortium also

announced its rst project, Android, described as

a platorm or mobile devices based on the Linux

kernel version 2.6.

The Android operating system or mobile devices

was made available as open source sotware

under an Apache license in 2008. Android

contains internal components (the platorm)

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 o open source,

a community o developers taking advantage o

what they see as ree, open sotware upon which

to build mobile applications.

Android Trends

Despite its recent successes against the iPhone,

Android holds a small - albeit growing - shareo the mobile device OS market. Symbian, the

open source mobile OS which in 2009 held 51%

market share, has seen erosion o its position to

1 http://tech.ortune.cnn.com/2010/07/16/steve-jobs-conrms-android-outselling-

iphone/

2 Gartner chart, as shown in http://www.linuxordevices.com/c/a/News/Gartner-2Q-

report-and-AndroidLinux-ork/

2

8/6/2019 Android UL

4/12

a 41.2% share. Similarly, RIM, which in 2009

held 19% o the market, saw its hold chipped to

17.2%. In the same time period, driven by sales

o smartphones, Android moved rom 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 o

Android is branching out to other portable

and embedded devices (tablet computers,

e-readers, netbooks, HDTVs etc.)

Android: The complexity inside

Created using the GPLv2 licensed Linux kernel,

Android is a Google project, and represents a

ork in the Linux kernel. Despite its roots in the

GPL, Androids collection o ~185 dierent sub-

components (see Figure 1: Android Architecture) is

written under ~19 dierent open source licenses

- most reciprocal, and not all OSI-approved. While

the majority o Android code contributed by Google

is governed by the Apache 2.0 license, a number

o components mobile developers rely on are

governed by other licenses.

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

Figure 1: The Android Architecture

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

3

8/6/2019 Android UL

5/12

Androids rich variety o open source sotware

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,

e2sprogs, bluez, Bison, etc.) also use reciprocal

licenses (GPL, LGPL, CPL, etc.) Twenty-eight

components use the GPL and ve 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 o components and multiple licenses

and associated obligations presents challenges

or mobile application developers, handset

manuacturers that use Android, and third-party

companies that develop sotware components or

device manuacturers.

Rapid changes add unctionality and

richness, but orks create complexityThe 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.html4

8/6/2019 Android UL

6/12

developed by Google includes changes outside

the Linux kernel, which created an initial ork.

From 2009s V 1.5 Cupcake release to todays

V 2.2 Froyo release, bug xes, enhancements

and patches have been added to the main

project. Development occurs at such a rapid

pace that there is an acknowledged large

backlog o patches rom Android back upstream

to the Linux kernel which keeps the Linux kernel

and Androids ork out o sync.

The Android project uses git as its SCM system.

The project is split into over 242 git repositories, o

which over 90 also have been orked rom upstream

projects. At any time there may be multiple active

branches o o a number o code-lines separating

stable code rom experimental work. A wide

ecosystem o OEMs and device builders make

contributions into these hundreds o branches,

while Google maintains a private code-line or deep

development o sensitive uture eatures involving

condential third party inormation.

Android OEMs and device builders must

continuously update their local copies with

the latest ongoing developments to stay in a

position to release their products immediately

ater Android releases. Daily commits rom the

community introduce new code, some o which

may be specic to other OEMs devices. These

changes need to be reviewed and tested or

compatibility - and assessed or compliance.

With this much development going on in parallel

it is imperative to have a strategy to manage the

complexity, and to identiy and approve changes

going into products.

Multi-source development and what it

means or the Android ecosystemThe Android community includes Google,

independent application developers, third-party

companies which develop sotware or mobile

and embedded devices, and manuacturers that

adopt Android as the OS or a given mobile or

embedded device.

The multi-tiered ecosystem represents multi-

source development at its best, yet it adds

complexity to the Android platorm. Independent

developers may contribute code under a variety

o licenses. Handset manuacturers may develop

sotware IP to run on top o the Android OS,

in addition to modiying and augmenting theAndroid codebase to suit a particular hardware

or sotware design. Commercial sotware

development companies creating 3rd-party

applications may do all o the above: add IP to

Android components, use a variety o licenses,5

8/6/2019 Android UL

7/12

and modiy 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. I youre a handset manuacturer

that has modied Android code to take

advantage o sotware or hardware eature

designs, not knowing how the code and

various components are integrated with yourproprietary code may be an issue.

Any enhancements or changes a company

makes to the Android code could be

considered intellectual property. Not knowing

i 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 o exposing proprietary code.

This may cause damage to customers

(e.g., device vendors) and may require the

developer to compensate its customers or

their losses.

If the application a software developer

creates or the Android platorm is not a nal

product but is to be integrated as a component

in a customers nal product (e.g., a mobile

phone), the developer may be endangering its

customers product (via viral eect, injunctions,

etc.), i the integration with the Android

platorm was not correctly managed.

Clearly, managing compliance with the abundance

o code and open source licenses used in the

Android platorm is a signicant challenge.

Obligations in Android

The Android project contains over 19 dierent

license types in over 185 dierent 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. O these over 1,000 are legal type

obligations, while around 700 are developer

type obligations. Fortunately most companiesdont need to conrm compliance to over 1,700

obligations; many o the legal obligations can

be reviewed once during internal license review.

Legal obligations typically involve accepting

a disclaimer o warranty, limiting liability,

protection o trademarks or other items that

generally do not add work or the developer.

However, even the most permissive license

typically has an obligation o acknowledgement

and other obligations (marking modication,

redistribution requirements, documentation

6

8/6/2019 Android UL

8/12

requirements, etc.) that can add work to the

sotware developers backlog o tasks. And, in

act, developer-level obligations oten need to be

managed, not at the component level, but at the

le level. In a highly dynamic environment like

Android development, where les are requently

updated rom web repositories, keeping track o

all these obligations can be daunting.

For example, the Android-based Samsung

Vibrant (SGH-t959) phone has a legal

acknowledgement section or all open source

in the phone - and it is over 8,000 lines long. It

specically acknowledges hundreds o copyright

holders; or many, this acknowledgement is

specic to individual les or to a list o les.

To comply with its publishing obligations,

Samsung provides a download o the les on

its Open Source Release Center website (http://

opensource.samsung.com/) where anyone

can access the les. Any les that do not

comply with le-level obligations (such as

removing copyright statements, incorrectlyadding copyright statements, not documenting

modications and others), could be relatively

apparent to the copyright holders and/or others.

For many contributors to the open source

Best PracticesAll companies that use open source sotware, including

those that use Android, should ollow basic best

practices or 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 o practices.

Identify and track all third party

code that is used.

Check all sources or open source code. Develop

a best practice that describes how to manageinbound code, an institutionalized policy or

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 ast enough to

aid in the discovery o hidden or potentially

encumbered code. The more automation is

in place, the better able a developer will beto take advantage o OSS code. Automation

also minimizes the impact o OSS compliance

policies on developers, who can stay ocused on

developing rather than tracking code provenance.

Automate monitoring and tracking of

Android and its components.

Establish a worklow that makes tracking a

simple, automated part o your development

processes Dont orget to integrate with

other systems, especially build and change

management tools -a build system is a natural

and convenient place to scan or third-party and

OSS code and identiy conlicts early.

Control component re-use and standardization.

Create an approved set o components that is accessible

and usable by the entire development organization. Who

needs 5 dierent parsers in one application?.

7

8/6/2019 Android UL

9/12

community, this acknowledgement is all they

ask in return or the use o their sotware.

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 les are in their code and what

obligations result rom that mix o third party

sotware. Managing this with tooling that

provides automated code scanning and reviews

can increase the eciency o development

organizations and reduce risk in an otherwise

complex process.

The good news - managing complexity

is a straightorward 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 reviewo the published code. This step is critical - i

developers accidentally remove copyrights, add

improper proprietary copyrights or ail to comply

with other requirements o the license(s), undesired

outcomes, such as legal action, loss o good will

in the open source community and unavorable

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 time-

to-market, low cost, code reduction and re-use

and fexibility. In mobile, where new deviceplatorms are announced monthly and pressure

to innovate is extreme, open source - especially

Android - is the ast 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 benet rom the abundance

and opportunity o Android, developers and

development organizations need an automation

platorm and processes to manage complexity

and provide visibility, control and compliance.

Black Duck Sotware has the leading solution or

automating the management o open source use

in a multi-source development environment.

The Black Duck Suite allows your sotware

development organization to benet rom open

source and manage the complexity o Android

8

8/6/2019 Android UL

10/12

enterprises. The Black Duck Suite includes a

robust SDK which enables integration with IBM

Rational, Microsot and many other developmen

tools and environments.

All participants in the mobile ecosystem -

developers, carriers and device manuacturers

- benet rom the abundance and opportunity

o open source. With those benets comes the

need to manage its complexity, especially the

responsibility or appropriate management and

control o Android and all open source code

beore it makes its way into a nal product.

Black Duck Sotware minimizes complexity and

opens mobile development to the abundance

and opportunity o open source.

while also allowing other stakeholders

including legal, IT, security, export and

purchasing personnelto access timely and

relevant inormation to eectively manage

business risks. With the Black Duck Suite,

its simple to implement best practices while

streamlining development and making the most

ecient use o development resources.

The Black Duck Suite addresses complexity

- including the broad set o management,

compliance, and security problems that surace

when open source components are used at

signicant scale in sotware development. Features

that address these problems include a searchable

internal catalog, a customizable approval

workfow, and the industrys most comprehensiveKnowledgeBase (http://www.blackducksotware.

com/knowledgebase) o open source inormation.

With the Black Duck Suite, mobile developers

and development organizations can choose rom

an array o eatures to tailor a solution to their

individual requirements.

Unlike competitive oerings that ocus on

narrow aspects o licensing or security or

individual users, the Black Duck Suite scales to

provide an automation platorm or open source

management and compliance across global

9

8/6/2019 Android UL

11/12

8/6/2019 Android UL

12/12

WP-ADN-0910-UL-AD

ContactTo learn more, please contact:

sales@blackducksotware.com o

call +1 781.810.5100

Additional inormation is availabl

at Black Ducks web site:

www.blackducksotware.com

About Black Duck SotwareBlack Duck Sotware is the leading provider o productand services or automating the management, governa

and secure use o ree and open source sotware, at

enterprise scale, in a multi-source development proce

Black Duck enables companies to shorten time-to-

solution and reduce development costs while mitigatin

the management, compliance and security challenges

associated with ree and open source sotware. Black

Duck Sotware powers Koders.com, the industrys lead

code search engine or open source, Ohloh.net, the

largest community or and ree public directory o ope

source, and The Olliance Group, the leading open sourc

business and strategy consulting rm. Among the 400

largest sotware companies in the world, according to

Sotwaremag.com, the company is headquartered nea

Boston and has oces in San Mateo, Caliornia, Londo

Paris, Frankurt, Hong Kong, Tokyo and Beijing. For mo

inormation, visit www.blackducksoftware.com.

2011 Black Duck, Know Your Code, Ohloh, SpikeSource, Spike, and

Black Duck logo are registered trademarks o Black Duck Sotware, Inc. in t

United States and/or other jurisdictions. Koders is a trademark o Black D

Sotware, Inc. All other trademarks are the property o their respective holde