The Android Open Source Project (AOSP) uses a few open source initiative approved open source licenses for our software.
Apache License, Version 2.0 (Apache 2.0) is the preferred license for AOSP, and the majority of Android software is licensed with Apache 2.0. While the project strives to adhere to the preferred license, there are exceptions, which are handled on a case-by-case basis. For example, the Linux kernel patches are under the GPLv2 license with system exceptions, which can be found on kernel.org.
Contributor license agreements
All individual contributors (those making contributions only on their own behalf) of ideas, code, or documentation to AOSP are required to complete, sign, and submit an Individual Contributor License Agreement. The agreement can be executed online through the code review tool. The agreement clearly defines the terms for contributing intellectual property to AOSP. This license is for your protection as a contributor as well as the protection of the project; it doesn't change your rights to use your own contributions for any other purpose.
A Corporate Contributor License Agreement is available for a corporation (or other entity) with employees working on AOSP. This version of the agreement allows a corporation to authorize contributions submitted by its designated employees and to grant copyright and patent licenses.
Why Apache Software License?
For userspace (non-kernel) software, we prefer Apache 2.0 (and similar licenses such as BSD and MIT) over other licenses such as the Lesser General Public License (LGPL). Here's why.
Android is about freedom and choice. The purpose of Android is to promote openness in the mobile world, and we can't predict or dictate all the uses for our software. So, while we encourage everyone to make open and modifiable devices, we don't think it's our place to force them to do so. Using LGPL libraries could be restrictive. Here are some of our specific concerns:
- In simplified terms, LGPL requires shipping of source to the application; a written offer for source; or linking the LGPL-ed library dynamically and allowing users to manually upgrade or replace the library. Android software is typically shipped as a static system image, so complying with these requirements restricts device manufacturer designs. For instance, it's difficult for a user to replace a library on read-only flash storage.
- LGPL requires the allowance of customer modification and reverse engineering for debugging those modifications. Most device makers don't want to be bound by these terms.
- Historically, LGPL libraries have been the source of many compliance problems for downstream device makers and application developers. Educating engineers on these issues is difficult and time consuming. It's critical to Android's success that device makers can easily comply with the licenses.
The issues discussed above are our reasons for preferring Apache 2.0 for our code. They aren't criticisms of LGPL or other licenses. We appreciate all free and open source licenses, and respect others' license preferences. We've simply decided that Apache 2.0 is right for our goals.