Fixing 2 of the remaining broken links.
Change-Id: I5cdfb83be4fa30574c807eff668f95e26a1cba8c
diff --git a/src/source/licenses.md b/src/source/licenses.md
new file mode 100644
index 0000000..677abcc
--- /dev/null
+++ b/src/source/licenses.md
@@ -0,0 +1,87 @@
+# Licenses #
+
+The Android Open Source Project uses a few [open source initiative](http://www.opensource.org/)
+approved open source licenses for our software.
+
+## Android Open Source Project license ##
+
+The preferred license for the Android Open Source Project is the [Apache
+Software License, 2.0](http://www.apache.org/licenses/LICENSE-2.0) ("Apache 2.0"),
+and the majority of the Android software is licensed
+with Apache 2.0. 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 [kernel.org](http://www.kernel.org/pub/linux/kernel/COPYING).
+
+## Contributor License Grants ##
+
+All *individual* 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 [Individual
+Contributor License Grant](cla-individual.html). The grant can be executed online through the
+[code review tool](https://review.source.android.com/#settings,agreements).
+The grant 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.
+
+For a *corporation* (or other entity) that has assigned employees to
+work on the Android Open Source Project, a [Corporate
+Contributor License Grant](cla-corporate.html) 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 *not* owned by the corporation signing the
+Corporate Contributor License Grant.
+
+Please note that we based our grants on the ones that the
+[Apache Software Foundation](http://www.apache.org) uses, which can
+be found on [the Apache web site](http://www.apache.org/licenses/).
+
+## Why Apache Software License? ##
+
+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.
+
+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.
+
+Here are some of our specific concerns:
+
+- 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.)
+
+- LGPL requires allowance of customer modification and reverse
+engineering for debugging those modifications. Most device makers do
+not want to have to be bound by these terms, so to minimize the burden on
+these companies we minimize usage of LGPL software in userspace.</li>
+
+- Historically, LGPL libraries have been the source of a large number
+of compliance problems for downstream device makers and application
+developers. Educating engineers on these issues is difficult and slow-going,
+unfortunately. It's critical to Android's success that it be as easy as
+possible for device makers to comply with the licenses. Given the
+difficulties with complying with LGPL in the past, it is most prudent to
+simply not use LGPL libraries if we can avoid it.
+
+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.
+
diff --git a/src/source/roles.md b/src/source/roles.md
new file mode 100644
index 0000000..1badf26
--- /dev/null
+++ b/src/source/roles.md
@@ -0,0 +1,79 @@
+# People and Roles #
+
+The Android Open Source Project (AOSP) includes individuals working in a variety
+of roles. As noted in [Our Philosophy](about/philosophy.html), Google is responsible for Android product management
+and the engineering process for the core framework and platform; however,
+the project considers contributions from any source, not just Google. This
+page describes the kinds of roles that interested parties can take on.
+
+Anyone who is interested in exploring and contributing to Android can use the
+Android Open Source Project resources. Anyone can join the mailing lists, ask
+questions, contribute patches, report bugs, look at submitted patches, and use
+the tools. To get started with the Android code, see [Get Involved](source/index.html).
+
+## Contributor ##
+
+A "Contributor" is anyone making contributions to the AOSP source code,
+including both employees of Google or other companies, as well as external
+developers who are contributing to Android on their own behalf. There is no
+distinction between Contributors who are employed by Google, and those who are
+not: all engineers use the same tools (git, repo, and gerrit),
+follow the same code review process, and are subject
+to the same requirements on code style and so on.
+
+## Developer ##
+
+A "Developer" is an engineer writing applications that run on Android
+devices. There is, of course, no difference in skillset between a "Developer"
+and a "Contributor", but AOSP uses "Developer" to distinguish between
+engineers using the platform and those contributing to it. Developers are
+(along with end users) the "customers" of the platform that the Contributors
+create. As such, we talk about Developers a lot, though this isn't technically
+a separate role in the AOSP per se.
+
+## Verifier ##
+
+"Verifiers" are responsible for testing change requests. After individuals
+have submitted a significant amount of high-quality code to the project, the
+Project Leads might invite them to become Verifiers. *Note: at this
+time, generally Verifiers are the same as Approvers.*
+
+## Approver ##
+
+"Approvers" are experienced members of the project who have demonstrated their
+design skills and have made significant technical contributions to the
+project. In the code-review process, an Approver decides whether to include or
+exclude a change. Project Leads (who are typically employed by Google) choose
+the Approvers, sometimes promoting to this position Verifiers who have
+demonstrated their expertise within a specific project.
+
+## Project Leads ##
+
+Android consists of a number of sub-projects; you can see these in the git
+repository, as individual .git files. Tech Leads are senior Contributors who
+oversee the engineering for individual Android projects. Typically these tech
+leads will be Google employees. A Project Lead for an individual project is
+responsible for the following:
+
+- Lead all technical aspects of the project; for example, the project roadmap,
+ development, release cycles, versioning, and QA.
+
+- Ensure that the project is QA-ed in time for scheduled Android platform
+ releases.
+
+- Designate Verifiers and Approvers for submitted patches.
+
+- Be fair and unbiased while reviewing changes. Accept or reject patches
+ based on technical merit and alignment with the Android strategy.
+
+- Review changes in a timely manner and make best efforts to communicate
+ when changes are not accepted.
+
+- Optionally maintain a web site for the project for information and
+ documents specific to the project.
+
+- Act as a facilitator in resolving technical conflicts.
+
+- Be a public face for the project and the go-to person for questions
+ related to the project.
+
diff --git a/src/source/submit-patches.md b/src/source/submit-patches.md
index 01e7430..d663727 100644
--- a/src/source/submit-patches.md
+++ b/src/source/submit-patches.md
@@ -11,10 +11,10 @@
- For details about Repo and Git, see [Version Control](version-control.html).
- For information about the different roles you can play within the Android
-Open Source community, see [Project roles](/about/roles.html).
+Open Source community, see [Project roles](/source/roles.html).
- If you plan to contribute code to the Android platform, be sure to read
-the [AOSP's licensing information](/about/licenses.html).
+the [AOSP's licensing information](/source/licenses.html).
- Note that changes to some of the upstream projects used by Android should be
made directly to that project, as described in [Upstream Projects](#upstream-projects).
@@ -101,7 +101,7 @@
In short, contribute high-quality code to one or more of the Android projects.
For details about the different roles in the Android Open Source community and
-who plays them, see [Project Roles](/about/roles.html).
+who plays them, see [Project Roles](/source/roles.html).
## Using GitWeb to track patch histories ##