Consider this: the Android-based Samsung Vibrant (SGH-t959) phone has a section containing legal acknowledgements of all the open source code on 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 Centre website, 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 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 easily can, put together tools and processes to make sure this acknowledgement happens. The best practice is to carefully stipulate which licenses, components, copyrights and files are in their code, and what obligations result from that mix of third-party software. But this task is easier said than done.
In the previous article, we had explored how managing these complex source-code reviews can become a straightforward process with tools such as Black Duck software.
Now, since the subject of this article is Android development, let’s first focus on the licensing complexities, and the issues that necessitate tracking the source code and addressing the related obligations. It would then be worthwhile to evaluate how, with a tool like Black Duck’s Android Fast Start, a bundled software and service, you can manage the continual changes and associated operational, legal, and security challenges in a seamless process integrated into your Android development environment.
Android: The complexity within
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, apart from various other components or projects, copyrighted by different owners). While Android is feature-rich and free in terms of acquisition costs, it’s not immune to obligations, and requires proper management and control, says Rohit Sharma, vice president, Lyra Infosystems (P) Limited, the official representative partner of Black Duck Software Inc, in the Indian subcontinent.
Let’s explore this technical complexity at length, looking at it from the perspective of developers — third-party companies that develop software components for device manufacturers and OEMs. The Android open source project is sponsored by Google, created using the GPLv2-licensed Linux kernel, 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 that mobile developers rely on are governed by other licenses, explains Sharma.
“Android’s open source software assets are grouped into external and internal categories. Android’s two major external components — the Linux kernel and WebKit — are governed by reciprocal licenses (GPLv2 and 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,” he adds.
Thus, 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.
Multi-source development and obligations in Android
The Android community includes Google, independent application developers, third-party companies that 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. Manufacturers may develop software IP to run on top of the Android OS, in addition to modifying and augmenting the Android code base to suit a particular hardware or software design. Commercial software development companies creating third-party applications may do all of the above, and add IP to Android components, use a variety of licenses, and modify or augment the Android code base.
With this complexity comes the license and IP management challenges. For instance: if the application software created/developed 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), then the company may be putting its customer’s product at risk if the integration with the Android platform was not correctly managed.
Handling the updates
Android code developed by Google includes changes outside the Linux kernel, which created an initial fork. From 2009’s version 1.5 “Cupcake” release to today’s version 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 that are headed back upstream to the Linux kernel — which keeps the Linux kernel and Android’s fork out of sync.
“Therefore, the Android OEMs and device builders must continuously update their local copies with the latest ongoing developments, to stay in position to release their products immediately after Android releases. These changes need to be reviewed and tested for compatibility — and assessed for compliance. With substantial development going on in parallel, it is imperative to have a strategy to manage the complexity, and to identify and approve the changes being incorporated in products,” advises Sharma.
The obligations
The Android project contains over 19 different license types in over 185 different projects (or components). Assuming each license is broken down 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 all 1,700 obligations. 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, 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 the Web repositories, keeping track of all these obligations can be daunting,” explains Sharma.
Using Black Duck’s Android Fast Start makes managing all these complexities related to source-code reviews a straightforward process, he affirms.
The software allows your software-development activity to benefit from open source, and manage the complexity of Android, while allowing legal, IT, security and export personnel to access timely and relevant information to effectively manage business risks. The tool can also address a broad set of management, compliance, and security problems that surface when open source components are used on a significant scale in software development. So, if you are in software development, the best route to write safe code and minimise the complexity that may arise from the use of open source would be to look for a tool like Black Duck.
