Work-in-progress snapshot of the source.android.com (formerly PDK) site
refresh.
diff --git a/pdk/docs/source/licenses.jd b/pdk/docs/source/licenses.jd
new file mode 100644
index 0000000..f1f646b
--- /dev/null
+++ b/pdk/docs/source/licenses.jd
@@ -0,0 +1,87 @@
+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>