pdk/docs/source/licenses.jd - platform/development - Git at Google

 page.title=Licenses
 doc.type=source
 @jd:body
 <div>
 <p>The Android Open Source Project uses a few <a
 href="http://www.opensource.org/">open source initiative</a> approved open
 source licenses to enable availability of source code and to accept
 contributions from individuals and corporations.</p>
 <h2>Android Open Source Project license</h2>
 <p>The preferred license for the Android Open Source Project is <a
 href="http://www.apache.org/licenses/LICENSE-2.0">Apache 2.0</a>. Apache 2.0
 is a commercial and open source friendly open source license. The majority of
 the Android platform is licensed under the<a
 href="http://www.apache.org/licenses/">Apache 2.0 license</a>. While the
 project will strive to adhere to the preferred license, there may be
 exceptions which will be 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 <a
 href="http://www.kernel.org/pub/linux/kernel/COPYING">kernel.org</a>.
 </p>
 <h2>Contributor License Grants</h2>
 <p>All <b>individual</b> contributors (that is, contributors making contributions
 only on their own behalf) of ideas, code, or documentation to the Android Open
 Source Project will be required to complete, sign, and submit an <a
 href="{@docRoot}source/cla-individual.html">Individual
 Contributor License Grant</a>. The grant can be executed online through the <a
 href="http://review.source.android.com/Gerrit#settings,agreements">code review
 tool</a>. The agreement clearly defines the terms under which intellectual
 property has been contributed to the Android Open Source Project.This license
 is for your protection as a contributor as well as the protection of the
 project; it does not change your rights to use your own contributions for any
 other purpose.</p>
 <p>For a <b>corporation</b> (or other entity) that has assigned employees to
 work on the Android Open Source Project, a <a
 href="{@docRoot}source/cla-corporate.html">Corporate
 Contributor License Grant</a> is available. This version of the Grant allows a
 corporation to authorize contributions submitted by its designated employees
 and to grant copyright and patent licenses. Note that a Corporate Contributor
 License Grant does not remove the need for any developer to sign their own
 Individual Contributor License Grant as an individual, to cover any of their
 contributions which are <b><i>not</i></b> owned by the corporation signing the
 Corporate Contributor License Grant.
 </p>
 <p>Please note that we based our grants on the ones that the <a
 href="http://www.apache.org/">Apache Software Foundation</a> uses, which can
 be found on <a href="http://www.apache.org/licenses/">the Apache web site</a>.</p>
 <h2>Why Apache Software License?</h2>
 <p>We are sometimes asked why Apache Software License 2.0 is the preferred
 license for Android. For userspace (that is, non-kernel) software, we do in
 fact prefer ASL2.0 (and similar licenses like BSD, MIT, etc.) over other
 licenses such as LGPL.</p>
 <p>Android is about freedom and choice. The purpose of Android is promote
 openness in the mobile world, but we don't believe it's possible to predict or
 dictate all the uses to which people will want to put our software. So, while
 we encourage everyone to make devices that are open and modifiable, we don't
 believe it is our place to force them to do so. Using LGPL libraries would
 often force them to do so.</p>
 <p>Here are some of our specific concerns:</p>
 <ol>
 <li>LGPL (in simplified terms) requires either: 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.
 Since Android software is typically shipped in the form of a static system
 image, complying with these requirements ends up restricting OEMs' designs.
 (For instance, it's difficult for a user to replace a library on read-only
 flash storage.)</li>
 <li>LGPL requires allowance of customer modification and reverse
 engineering for debugging those modifications.  Most app producers do
 want to have to be bound by these terms, and the more userspace libs
 that are LGPL, the more they would have to be to use Android
 userspace.</li>
 <li>Historically, LGPL libraries have been the source of a large number
 of compliance problems for downstream device makers and application
 developers (due to ignorance and disbelief, usually).  Education is
 slow going, sadly.  Part of android being successful as a platform is
 that we want to make it easy for our device makers to comply with the
 licenses in Android.  Given the difficulties with complying with LGPL
 in the past, it is easiest to simply not use LGPL libraries if we can
 avoid it.</li>
 </ol>
 <p>The issues discussed above are our reasons for preferring ASL2.0 for
 our own code. They aren't criticisms of LGPL or other licenses. We do
 feel strongly on this topic, even to the point where we've gone out of our
 way to make sure as much code as possible is ASL2.0. However, we love all free
 and open source licenses, and respect others' opinions and preferences. We've
 simply decided that ASL2.0 is the right license for our goals.</p>
 </div>
	page.title=Licenses
	doc.type=source
	@jd:body
	<div>
	<p>The Android Open Source Project uses a few <a
	href="http://www.opensource.org/">open source initiative</a> approved open
	source licenses to enable availability of source code and to accept
	contributions from individuals and corporations.</p>
	<h2>Android Open Source Project license</h2>
	<p>The preferred license for the Android Open Source Project is <a
	href="http://www.apache.org/licenses/LICENSE-2.0">Apache 2.0</a>. Apache 2.0
	is a commercial and open source friendly open source license. The majority of
	the Android platform is licensed under the<a
	href="http://www.apache.org/licenses/">Apache 2.0 license</a>. While the
	project will strive to adhere to the preferred license, there may be
	exceptions which will be 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 <a
	href="http://www.kernel.org/pub/linux/kernel/COPYING">kernel.org</a>.
	</p>
	<h2>Contributor License Grants</h2>
	<p>All <b>individual</b> contributors (that is, contributors making contributions
	only on their own behalf) of ideas, code, or documentation to the Android Open
	Source Project will be required to complete, sign, and submit an <a
	href="{@docRoot}source/cla-individual.html">Individual
	Contributor License Grant</a>. The grant can be executed online through the <a
	href="http://review.source.android.com/Gerrit#settings,agreements">code review
	tool</a>. The agreement clearly defines the terms under which intellectual
	property has been contributed to the Android Open Source Project.This license
	is for your protection as a contributor as well as the protection of the
	project; it does not change your rights to use your own contributions for any
	other purpose.</p>
	<p>For a <b>corporation</b> (or other entity) that has assigned employees to
	work on the Android Open Source Project, a <a
	href="{@docRoot}source/cla-corporate.html">Corporate
	Contributor License Grant</a> is available. This version of the Grant allows a
	corporation to authorize contributions submitted by its designated employees
	and to grant copyright and patent licenses. Note that a Corporate Contributor
	License Grant does not remove the need for any developer to sign their own
	Individual Contributor License Grant as an individual, to cover any of their
	contributions which are <b><i>not</i></b> owned by the corporation signing the
	Corporate Contributor License Grant.
	</p>
	<p>Please note that we based our grants on the ones that the <a
	href="http://www.apache.org/">Apache Software Foundation</a> uses, which can
	be found on <a href="http://www.apache.org/licenses/">the Apache web site</a>.</p>
	<h2>Why Apache Software License?</h2>
	<p>We are sometimes asked why Apache Software License 2.0 is the preferred
	license for Android. For userspace (that is, non-kernel) software, we do in
	fact prefer ASL2.0 (and similar licenses like BSD, MIT, etc.) over other
	licenses such as LGPL.</p>
	<p>Android is about freedom and choice. The purpose of Android is promote
	openness in the mobile world, but we don't believe it's possible to predict or
	dictate all the uses to which people will want to put our software. So, while
	we encourage everyone to make devices that are open and modifiable, we don't
	believe it is our place to force them to do so. Using LGPL libraries would
	often force them to do so.</p>
	<p>Here are some of our specific concerns:</p>
	<ol>
	<li>LGPL (in simplified terms) requires either: 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.
	Since Android software is typically shipped in the form of a static system
	image, complying with these requirements ends up restricting OEMs' designs.
	(For instance, it's difficult for a user to replace a library on read-only
	flash storage.)</li>
	<li>LGPL requires allowance of customer modification and reverse
	engineering for debugging those modifications. Most app producers do
	want to have to be bound by these terms, and the more userspace libs
	that are LGPL, the more they would have to be to use Android
	userspace.</li>
	<li>Historically, LGPL libraries have been the source of a large number
	of compliance problems for downstream device makers and application
	developers (due to ignorance and disbelief, usually). Education is
	slow going, sadly. Part of android being successful as a platform is
	that we want to make it easy for our device makers to comply with the
	licenses in Android. Given the difficulties with complying with LGPL
	in the past, it is easiest to simply not use LGPL libraries if we can
	avoid it.</li>
	</ol>
	<p>The issues discussed above are our reasons for preferring ASL2.0 for
	our own code. They aren't criticisms of LGPL or other licenses. We do
	feel strongly on this topic, even to the point where we've gone out of our
	way to make sure as much code as possible is ASL2.0. However, we love all free
	and open source licenses, and respect others' opinions and preferences. We've
	simply decided that ASL2.0 is the right license for our goals.</p>
	</div>